Re: WG Last Call Comment for 3280bis

["David A. Cooper" <[e-mail]>]

Russ,

I do not see how this proposed change relates to the recent discussions 
about certificate suspension.  I am also not in favor of the change that 
you have proposed.

Your proposal states that clients that process the holdInstruction entry 
extension must recognize the id-holdinstruction-reject instruction code, 
but then says that conforming applications must perform the same action 
(reject the certificate) whenever any of the three hold instruction 
codes are encountered.  So, what does it mean to recognize the 
id-holdinstruction-reject instruction code but not the other two 
instruction codes.

Since I don't have a copy of X9.57, I don't fully understand the 
motivation for some of the codes.  In particular, I don't understand the 
difference between id-holdinstruction-reject and 
id-holdinstruction-none.  If the certificate is on hold and either the 
holdInstruction entry extension is absent or is present and asserts 
id-holdinstruction-none, aren't you going to reject the certificate just 
as you would if the id-holdinstruction-reject instruction code were 
asserted?

It seems to me that the only meaningful hold instruction code is 
id-holdinstruction-callissuer, since it seems to be the only one that 
doesn't say "do the same thing as you would have done if the 
holdInstruction entry extension were not present".  So, if we were going 
to say that conforming CAs MUST NOT make use of the 
id-holdinstruction-callissuer instruction code, why not just say that 
conforming CAs MUST NOT include the holdInstruction entry extension?  I 
do not favor that solution though.  The holdInstruction entry extension 
is a non-critical extension, 3280/3280bis does not require clients to be 
able to process the extension, and even clients that do process the 
extension are permitted to simply reject certificates that include the 
id-holdinstruction-callissuer instruction code rather than taking some 
action to contact the issuer.  So, what is the compelling reason to 
suddenly forbid conforming CAs from using that instruction code?

Dave

Russ Housley wrote:
>
> I know that Steve Kent called the 3280bis closed on 11/7/2006, but the 
> recent thread regarding on-hold needs to become a concrete proposal 
> for a change in the text.  Here is my suggestion.
>
> OLD TEXT:
>
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the following
>    instruction codes.
>
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>    Conforming applications that encounter an id-holdinstruction-
>    callissuer MUST call the certificate issuer or reject the
>    certificate.  Conforming applications that encounter an id-
>    holdinstruction-reject MUST reject the certificate.  The hold
>    instruction id-holdinstruction-none is semantically equivalent to the
>    absence of a holdInstructionCode, and its use is strongly deprecated
>    for the Internet PKI.
>
> PROPOSED REPLACEMENT TEXT:
>
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the
>    id-holdinstruction-reject instruction code.
>
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>    Conforming CAs MUST NOT make use of the
>    id-holdinstruction-callissuer instruction code.
>
>    Conforming applications that encounter any of these hold instruction
>    codes MUST reject the certificate.
>
>    Communities may elect to use additional hold instruction codes;
>    however, caution ought to be exercised in adopting any additional
>    hold instruction codes that might prevent use in a general context.





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 kB15qNSu077039; Thu, 30 Nov 2006 22:52:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB15qN6g077038; Thu, 30 Nov 2006 22:52:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kB15qLKe077025 for <[e-mail]>; Thu, 30 Nov 2006 22:52:21 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[196.192.2.69]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Gq1Jm-000444-4O; Fri, 01 Dec 2006 00:52:14 -0500
Mime-Version: 1.0
Message-Id: <p06230906c19482491fb8@[196.192.2.69]>
In-Reply-To: <00e501c7147a$fcb2a440$5d85900a@wcwang>
References:  <[e-mail]><456B5D37.8020 [e-mail]><[e-mail]><016a01c712de$e 39ee6f0$5d85900a@wcwang><[e-mail]><a7d [e-mail]> <p06230906c1923958038d@[10.1.33.49]><015d01c713af$b5212000$5d85900a@wcwang > <p0623090fc1937416eac7@[196.192.2.69]> <00e501c7147a$fcb2a440$5d85900a@wcwang>
Date: Fri, 1 Dec 2006 00:52:10 -0500
To: "Wen-Cheng Wang" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Cc: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[e-mail]>, "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1047170161==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1047170161==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Wen-Cheng Wang,

I agree that the real world can be complex. It can also be 
irrational, political, and driven by short term solutions that are 
optimized for the convenience of those who create them. None of these 
latter characteristics of the real world need influence our standards.

This WG has decided to deprecate some such real world solutions in 
the past, e.g., a model that required an RP to check a X.500 
directory entry to verify cert revocation status. This example was 
one that involved a government-run PKI. That didn't make it right, 
and so we "just said no," as Nancy Reagan would have :-).

Based on the model you suggest, if any government-run PKI "demands" 
some feature of our standards, even if we believe it is technically a 
bad idea, we would be compelled to accommodate such demands. That is 
not the way the IETF works.

I wondered if your emphasis on not disagreeing with government-run 
PKIs might derive from your employer's (Chungwa Telecom) own PKI 
business, which issues smart cards and which have to comply with a 
Taiwan government PKI Cert policy. But I looked at version 1.1 of 
that CP and it does not require CAs to support suspension; it allows 
a CA to offer the service and says that the CPS for the CA will 
define the procedures associated with the service. So, at least in 
this case, it appears that there is not a government mandate to 
support suspension, but rather an individual CA decision.

Similarly, your comment "that we should care about the demand[sic] of 
real world" suggests that if Microsoft adopts a convention for PKI 
use in their OS we must endorse it too, because their products 
certainly represent the "real world." Again, wrong standards forum 
for that rationale.

Your argument is better with regard to the costs of re-issuance of 
improperly revoked certs for smart cards. That is the only argument 
you present that merits further consideration.

What really bothers me in the last paragraph is the assertion that 
"the intention is to protect relying parties."  Sometimes when I use 
my credit card I am asked to produce a photo ID. I decline. The 
merchant then says "this is for your protection."  Nonsense. The 
request for a photo ID is a measure used by the merchant to minimize 
his risk of fraud, not to protect me against fraudulent charges that 
might be incurred using my card (for which I would not be 
responsible). The similarity between your argument and this one is 
bothersome.

Revocation of a cert protects a relying party just fine. Having to 
interpret a HOLD instruction introduces more complexity for RPs, and 
if the outcome is to treat the cert as revoked at the point in time 
while it is on hold, then the RP has an easier task if the cert IS 
just revoked.

Steve
--============_-1047170161==_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: on-hold certificates in
CRLs</title></head><body>
<div>Wen-Cheng Wang,<br>
</div>
<div>I agree that the real world can be complex. It can also be
irrational, political, and driven by short term solutions that are
optimized for the convenience of those who create them. None of these
latter characteristics of the real world need influence our
standards.</div>
<div><br>
This WG has decided to deprecate some such real world solutions in the
past, e.g., a model that required an RP to check a X.500 directory
entry to verify cert revocation status. This example was one that
involved a government-run PKI. That didn't make it right, and so we
&quot;just said no,&quot; as Nancy Reagan would have :-).<br>
</div>
<div>Based on the model you suggest, if any government-run PKI
&quot;demands&quot; some feature of our standards, even if we believe
it is technically a bad idea, we would be compelled to accommodate
such demands. That is not the way the IETF works.</div>
<div><br></div>
<div>I wondered if your emphasis on not disagreeing with
government-run PKIs might derive from your employer's (Chungwa
Telecom) own PKI business, which issues smart cards and which have to
comply with a Taiwan government PKI Cert policy. But I looked at
version 1.1 of that CP and it does not require CAs to support
suspension; it allows a CA to<u> offer</u> the service and says that
the CPS for the CA will define the procedures associated with the
service. So, at least in this case, it appears that there is not a
government mandate to support suspension, but rather an individual CA
decision.</div>
<div><br></div>
<div>Similarly, your comment &quot;that we should care about the
demand[sic] of real world&quot; suggests that if Microsoft adopts a
convention for PKI use in their OS we must endorse it too, because
their products certainly represent the &quot;real world.&quot; Again,
wrong standards forum for that rationale.</div>
<div><br></div>
<div>Your argument is better with regard to the costs of re-issuance
of improperly revoked certs for smart cards. That is the only argument
you present that merits further consideration.</div>
<div><br>
What really bothers me in the last paragraph is the assertion that
&quot;the intention is to protect relying parties.&quot;&nbsp;
Sometimes when I use my credit card I am asked to produce a photo ID.
I decline. The merchant then says &quot;this is for your
protection.&quot;&nbsp; Nonsense. The request for a photo ID is a
measure used by the merchant to minimize his risk of fraud, not to
protect me against fraudulent charges that might be incurred using my
card (for which I would not be responsible). The similarity between
your argument and this one is bothersome.<br>
</div>
<div>Revocation of a cert protects a relying party just fine. Having
to interpret a HOLD instruction introduces more complexity for RPs,
and if the outcome is to treat the cert as revoked at the point in
time while it is on hold, then the RP has an easier task if the cert
IS just revoked.</div>
<div><br>
Steve</div>
</body>
</html>
--============_-1047170161==_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 kAULwRCI031330; Thu, 30 Nov 2006 14:58:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAULwRhX031329; Thu, 30 Nov 2006 14:58:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAULwQ4m031323 for <[e-mail]>; Thu, 30 Nov 2006 14:58:27 -0700 (MST) (envelope-from [e-mail])
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 kAULwCXC007473; Thu, 30 Nov 2006 16:58:15 -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 kAULvkMx003463; Thu, 30 Nov 2006 16:57:47 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 16:59:08 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: WG Last Call Comment for 3280bis
References: <p06230901c176ab291249@[128.89.89.106]> <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I do not see how this proposed change relates to the recent discussions 
about certificate suspension.  I am also not in favor of the change that 
you have proposed.

Your proposal states that clients that process the holdInstruction entry 
extension must recognize the id-holdinstruction-reject instruction code, 
but then says that conforming applications must perform the same action 
(reject the certificate) whenever any of the three hold instruction 
codes are encountered.  So, what does it mean to recognize the 
id-holdinstruction-reject instruction code but not the other two 
instruction codes.

Since I don't have a copy of X9.57, I don't fully understand the 
motivation for some of the codes.  In particular, I don't understand the 
difference between id-holdinstruction-reject and 
id-holdinstruction-none.  If the certificate is on hold and either the 
holdInstruction entry extension is absent or is present and asserts 
id-holdinstruction-none, aren't you going to reject the certificate just 
as you would if the id-holdinstruction-reject instruction code were 
asserted?

It seems to me that the only meaningful hold instruction code is 
id-holdinstruction-callissuer, since it seems to be the only one that 
doesn't say "do the same thing as you would have done if the 
holdInstruction entry extension were not present".  So, if we were going 
to say that conforming CAs MUST NOT make use of the 
id-holdinstruction-callissuer instruction code, why not just say that 
conforming CAs MUST NOT include the holdInstruction entry extension?  I 
do not favor that solution though.  The holdInstruction entry extension 
is a non-critical extension, 3280/3280bis does not require clients to be 
able to process the extension, and even clients that do process the 
extension are permitted to simply reject certificates that include the 
id-holdinstruction-callissuer instruction code rather than taking some 
action to contact the issuer.  So, what is the compelling reason to 
suddenly forbid conforming CAs from using that instruction code?

Dave

Russ Housley wrote:
>
> I know that Steve Kent called the 3280bis closed on 11/7/2006, but the 
> recent thread regarding on-hold needs to become a concrete proposal 
> for a change in the text.  Here is my suggestion.
>
> OLD TEXT:
>
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the following
>    instruction codes.
>
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>    Conforming applications that encounter an id-holdinstruction-
>    callissuer MUST call the certificate issuer or reject the
>    certificate.  Conforming applications that encounter an id-
>    holdinstruction-reject MUST reject the certificate.  The hold
>    instruction id-holdinstruction-none is semantically equivalent to the
>    absence of a holdInstructionCode, and its use is strongly deprecated
>    for the Internet PKI.
>
> PROPOSED REPLACEMENT TEXT:
>
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the
>    id-holdinstruction-reject instruction code.
>
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>    Conforming CAs MUST NOT make use of the
>    id-holdinstruction-callissuer instruction code.
>
>    Conforming applications that encounter any of these hold instruction
>    codes MUST reject the certificate.
>
>    Communities may elect to use additional hold instruction codes;
>    however, caution ought to be exercised in adopting any additional
>    hold instruction codes that might prevent use in a general context.



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 kAULqPGp030793; Thu, 30 Nov 2006 14:52:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAULqPRI030792; Thu, 30 Nov 2006 14:52:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAULqOSp030770 for <[e-mail]>; Thu, 30 Nov 2006 14:52:25 -0700 (MST) (envelope-from [e-mail])
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: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 13:55:22 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call Comment for 3280bis
Thread-Index: AccUxya/TbaQlO9qSmycFaN81gNsowAAT1kg
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAULqPSp030787
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

4.2 of the 3280 Bis says "Communities may elect to use additional
   extensions; however, caution ought to be exercised in adopting any
   critical extensions in certificates that might prevent use in a
   general context."

Given the context preceding in Section 4.2, I understand that one.   

The phrase "that might prevent use in a general context" is still
unclear in the context of hold instruction.  I suspect you mean that the
relying party may not understand the hold instruction.  Note that
Section 5.3.2 states that the hold instruction is non-critical and hence
in my reading it can be ignored.  Further, Section 6.3.3 says nothing
about processing hold instruction.

So:
The statement is not clear; and the statement can not be analogous to
treatment of critical unrecognized extensions.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Thursday, November 30, 2006 4:31 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: WG Last Call Comment for 3280bis

Santosh:

This is the same thing we say about using extensions that are not 
defined in RFC 3280.

Russ

At 03:09 PM 11/30/2006, Santosh Chokhani wrote:
>Russ,
>
>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>     "Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes since additional hold instruction codes may
>not be understood by all the relying parties"
>
>-----Original Message-----
>From: [e-mail]
[mailto:[e-mail]]
>On Behalf Of Russ Housley
>Sent: Thursday, November 30, 2006 1:24 PM
>To: [e-mail]
>Subject: WG Last Call Comment for 3280bis
>
>
>I know that Steve Kent called the 3280bis closed on 11/7/2006, but
>the recent thread regarding on-hold needs to become a concrete
>proposal for a change in the text.  Here is my suggestion.
>
>OLD TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>following
>     instruction codes.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction
1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction
2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction
3}
>
>     Conforming applications that encounter an id-holdinstruction-
>     callissuer MUST call the certificate issuer or reject the
>     certificate.  Conforming applications that encounter an id-
>     holdinstruction-reject MUST reject the certificate.  The hold
>     instruction id-holdinstruction-none is semantically equivalent to
>the
>     absence of a holdInstructionCode, and its use is strongly
deprecated
>     for the Internet PKI.
>
>PROPOSED REPLACEMENT TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>     id-holdinstruction-reject instruction code.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction
1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction
2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction
3}
>
>     Conforming CAs MUST NOT make use of the
>     id-holdinstruction-callissuer instruction code.
>
>     Conforming applications that encounter any of these hold
instruction
>     codes MUST reject the certificate.
>
>     Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes that might prevent use in a general
context.




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 kAULXI5D029032; Thu, 30 Nov 2006 14:33:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAULXIS3029031; Thu, 30 Nov 2006 14:33:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAULXHFA029015 for <[e-mail]>; Thu, 30 Nov 2006 14:33:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15278 invoked by uid 0); 30 Nov 2006 21:31:26 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 30 Nov 2006 21:31:26 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 30 Nov 2006 16:30:57 -0500
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: WG Last Call Comment for 3280bis
In-Reply-To: <[e-mail] eme.net>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh:

This is the same thing we say about using extensions that are not 
defined in RFC 3280.

Russ

At 03:09 PM 11/30/2006, Santosh Chokhani wrote:
>Russ,
>
>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>     "Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes since additional hold instruction codes may
>not be understood by all the relying parties"
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Russ Housley
>Sent: Thursday, November 30, 2006 1:24 PM
>To: [e-mail]
>Subject: WG Last Call Comment for 3280bis
>
>
>I know that Steve Kent called the 3280bis closed on 11/7/2006, but
>the recent thread regarding on-hold needs to become a concrete
>proposal for a change in the text.  Here is my suggestion.
>
>OLD TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>following
>     instruction codes.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction 2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>     Conforming applications that encounter an id-holdinstruction-
>     callissuer MUST call the certificate issuer or reject the
>     certificate.  Conforming applications that encounter an id-
>     holdinstruction-reject MUST reject the certificate.  The hold
>     instruction id-holdinstruction-none is semantically equivalent to
>the
>     absence of a holdInstructionCode, and its use is strongly deprecated
>     for the Internet PKI.
>
>PROPOSED REPLACEMENT TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>     id-holdinstruction-reject instruction code.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction 2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
>
>     Conforming CAs MUST NOT make use of the
>     id-holdinstruction-callissuer instruction code.
>
>     Conforming applications that encounter any of these hold instruction
>     codes MUST reject the certificate.
>
>     Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes that might prevent use in a general context.



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 kAUK6tA3019356; Thu, 30 Nov 2006 13:06:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUK6tPl019355; Thu, 30 Nov 2006 13:06:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUK6sLC019257 for <[e-mail]>; Thu, 30 Nov 2006 13:06:54 -0700 (MST) (envelope-from [e-mail])
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: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 12:09:52 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call Comment for 3280bis
Thread-Index: AccUt6UeAmnpCiEOS5qeQqZB9hYxkQAA2ZqQ
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAUK6tLC019350
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

The phrase "that might prevent use in a general context" is not clear.

Do you mean prevent use of certificate, of hold reason code, or hold
instruction, or something else?

May be the following makes sense:

    "Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes since additional hold instruction codes may
not be understood by all the relying parties"

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Thursday, November 30, 2006 1:24 PM
To: [e-mail]
Subject: WG Last Call Comment for 3280bis


I know that Steve Kent called the 3280bis closed on 11/7/2006, but 
the recent thread regarding on-hold needs to become a concrete 
proposal for a change in the text.  Here is my suggestion.

OLD TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the
following
    instruction codes.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming applications that encounter an id-holdinstruction-
    callissuer MUST call the certificate issuer or reject the
    certificate.  Conforming applications that encounter an id-
    holdinstruction-reject MUST reject the certificate.  The hold
    instruction id-holdinstruction-none is semantically equivalent to
the
    absence of a holdInstructionCode, and its use is strongly deprecated
    for the Internet PKI.

PROPOSED REPLACEMENT TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the
    id-holdinstruction-reject instruction code.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming CAs MUST NOT make use of the
    id-holdinstruction-callissuer instruction code.

    Conforming applications that encounter any of these hold instruction
    codes MUST reject the certificate.

    Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes that might prevent use in a general context.




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 kAUJJF2h014561; Thu, 30 Nov 2006 12:19:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUJJFiK014560; Thu, 30 Nov 2006 12:19:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAUJJBxO014539 for <[e-mail]>; Thu, 30 Nov 2006 12:19:13 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAUJJAEh004209; Thu, 30 Nov 2006 12:19:10 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call Comment for 3280bis
Date: Thu, 30 Nov 2006 10:42:25 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No objections.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Russ Housley
Sent: Thursday, November 30, 2006 10:24 AM
To: [e-mail]
Subject: WG Last Call Comment for 3280bis



I know that Steve Kent called the 3280bis closed on 11/7/2006, but 
the recent thread regarding on-hold needs to become a concrete 
proposal for a change in the text.  Here is my suggestion.

OLD TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the following
    instruction codes.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming applications that encounter an id-holdinstruction-
    callissuer MUST call the certificate issuer or reject the
    certificate.  Conforming applications that encounter an id-
    holdinstruction-reject MUST reject the certificate.  The hold
    instruction id-holdinstruction-none is semantically equivalent to the
    absence of a holdInstructionCode, and its use is strongly deprecated
    for the Internet PKI.

PROPOSED REPLACEMENT TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the
    id-holdinstruction-reject instruction code.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming CAs MUST NOT make use of the
    id-holdinstruction-callissuer instruction code.

    Conforming applications that encounter any of these hold instruction
    codes MUST reject the certificate.

    Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes that might prevent use in a general context.



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 kAUINpFO007919; Thu, 30 Nov 2006 11:23:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUINpd2007918; Thu, 30 Nov 2006 11:23:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAUINn6d007908 for <[e-mail]>; Thu, 30 Nov 2006 11:23:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32481 invoked by uid 0); 30 Nov 2006 18:23:44 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 30 Nov 2006 18:23:44 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 30 Nov 2006 13:23:38 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: WG Last Call Comment for 3280bis
In-Reply-To: <p06230901c176ab291249@[128.89.89.106]>
References: <p06230901c176ab291249@[128.89.89.106]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I know that Steve Kent called the 3280bis closed on 11/7/2006, but 
the recent thread regarding on-hold needs to become a concrete 
proposal for a change in the text.  Here is my suggestion.

OLD TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the following
    instruction codes.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming applications that encounter an id-holdinstruction-
    callissuer MUST call the certificate issuer or reject the
    certificate.  Conforming applications that encounter an id-
    holdinstruction-reject MUST reject the certificate.  The hold
    instruction id-holdinstruction-none is semantically equivalent to the
    absence of a holdInstructionCode, and its use is strongly deprecated
    for the Internet PKI.

PROPOSED REPLACEMENT TEXT:

    The following instruction codes have been defined.  Conforming
    applications that process this extension MUST recognize the
    id-holdinstruction-reject instruction code.

    holdInstruction    OBJECT IDENTIFIER ::=
                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }

    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
    id-holdinstruction-callissuer
                              OBJECT IDENTIFIER ::= {holdInstruction 2}
    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

    Conforming CAs MUST NOT make use of the
    id-holdinstruction-callissuer instruction code.

    Conforming applications that encounter any of these hold instruction
    codes MUST reject the certificate.

    Communities may elect to use additional hold instruction codes;
    however, caution ought to be exercised in adopting any additional
    hold instruction codes that might prevent use in a general context.



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 kAUI0lRV004662; Thu, 30 Nov 2006 11:00:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUI0lSa004661; Thu, 30 Nov 2006 11:00:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAUI0kYU004646 for <[e-mail]>; Thu, 30 Nov 2006 11:00:46 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAUI0Rc0001362; Thu, 30 Nov 2006 11:00:27 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 09:23:40 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C71461.38F1C360"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C71461.38F1C360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: on-hold certificates in CRLsI too agree with Stephen.  Whether listed as
suspended or revoked, from a relying party perspective certificates
proffered in either state are not trustworthy.  Rather than legitimize a
questionable interpretation, I think we should strive for simplicity and
thus not move forward on a work item in this regard.

Mike
  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Sharon Boeyen
  Sent: Thursday, November 30, 2006 8:31 AM
  To: 'Stephen Farrell'; pkix
  Subject: RE: on-hold certificates in CRLs


  Stephen, I tend to agree with you on this one. Suspension (in my opinion -
as editor of X.509 for a number of years) was originally intended simply as
a way for a CA to temporarily revoke a certificate in a situation where the
CA needed to do further investigation to determine whether or not it should
actually be revoked. Once that investigation was completed, the final status
of the certificate is indicated either by removing it from the CRL
(indicating that it was actually fine) or changing its revocation reason to
the real one. Nothing more and nothing less. As for "interpretations" I do
agree there are many as with many other parts of X.509 and RFC 3280.
However, that doesn't mean we should change the standard.

  Cheers,
  Sharon

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Farrell
  Sent: Thursday, November 30, 2006 8:13 AM
  To: pkix
  Subject: Re: on-hold certificates in CRLs






  Wen-Cheng Wang wrote:
  > Yes, I second that we should start a working item on a reliable,
  > verifiable, and
  > interoperabile suspension mechanism.

  Count me as a -1 for that. I don't believe we do want a suspension
mechanism really.

  Stephen.

------=_NextPart_000_0004_01C71461.38F1C360
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><TITLE>RE: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1578" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New" =
size=3D2>I too agree=20
with Stephen.&nbsp; Whether&nbsp;listed as suspended or revoked, from a =
relying=20
party perspective certificates proffered in either state are not=20
trustworthy.&nbsp;&nbsp;Rather than legitimize a questionable =
interpretation, I=20
think we should strive for simplicity and thus not move forward on a =
work item=20
in this regard.</FONT></SPAN></DIV>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D519310917-30112006><FONT face=3D"Courier New"=20
size=3D2>Mike</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3D"Courier New"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Sharon=20
  Boeyen<BR><B>Sent:</B> Thursday, November 30, 2006 8:31 =
AM<BR><B>To:</B>=20
  'Stephen Farrell'; pkix<BR><B>Subject:</B> RE: on-hold certificates in =

  CRLs<BR><BR></FONT></DIV>
  <P><FONT face=3D"Courier New" size=3D2>Stephen, I tend to agree with =
you on this=20
  one. Suspension (in my opinion - as editor of X.509 for a number of =
years) was=20
  originally intended simply as a way for a CA to temporarily revoke a=20
  certificate in a situation where the CA needed to do further =
investigation to=20
  determine whether or not it should actually be revoked. Once that=20
  investigation was completed, the final status of the certificate is =
indicated=20
  either by removing it from the CRL (indicating that it was actually =
fine) or=20
  changing its revocation reason to the real one. Nothing more and =
nothing less.=20
  As for "interpretations" I do agree there are many as with many other =
parts of=20
  X.509 and RFC 3280. However, that doesn't mean we should change the=20
  standard.</FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Cheers,</FONT> <BR><FONT=20
  size=3D2>Sharon </FONT></FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>-----Original =
Message-----</FONT>=20
  <BR><FONT size=3D2>From: [e-mail] [<A=20
  href=3D"mailto:[e-mail]"><FONT=20
  color=3D#000000>mailto:[e-mail]</FONT></A>] On =
Behalf Of=20
  Stephen Farrell</FONT> <BR><FONT size=3D2>Sent: Thursday, November 30, =
2006 8:13=20
  AM</FONT> <BR><FONT size=3D2>To: pkix</FONT> <BR><FONT =
size=3D2>Subject: Re:=20
  on-hold certificates in CRLs</FONT> </FONT></P><BR><BR><BR><BR>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Wen-Cheng Wang =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt; Yes, I second that we should start a working =
item on a=20
  reliable,</FONT> <BR><FONT size=3D2>&gt; verifiable, and</FONT> =
<BR><FONT=20
  size=3D2>&gt; interoperabile suspension mechanism.</FONT> </FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Count me as a -1 for =
that. I don't=20
  believe we do want a suspension mechanism really.</FONT> </FONT></P>
  <P><FONT face=3D"Courier New"><FONT size=3D2>Stephen.</FONT>=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0004_01C71461.38F1C360--



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 kAUGVYaF094883; Thu, 30 Nov 2006 09:31:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUGVYlb094882; Thu, 30 Nov 2006 09:31:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAUGVW5K094860 for <[e-mail]>; Thu, 30 Nov 2006 09:31:33 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2773 invoked from network); 30 Nov 2006 16:31:14 -0000
Received: from [e-mail] by sottccs2.entrust.com with EntrustECS-Server-8.0;30 Nov 2006 16:31:14 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottccs2.entrust.com with SMTP; 30 Nov 2006 16:31:14 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <WQB392LK>; Thu, 30 Nov 2006 11:31:18 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>, pkix <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 11:31:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7149C.1EA448E1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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_01C7149C.1EA448E1
Content-Type: text/plain

Stephen, I tend to agree with you on this one. Suspension (in my opinion -
as editor of X.509 for a number of years) was originally intended simply as
a way for a CA to temporarily revoke a certificate in a situation where the
CA needed to do further investigation to determine whether or not it should
actually be revoked. Once that investigation was completed, the final status
of the certificate is indicated either by removing it from the CRL
(indicating that it was actually fine) or changing its revocation reason to
the real one. Nothing more and nothing less. As for "interpretations" I do
agree there are many as with many other parts of X.509 and RFC 3280.
However, that doesn't mean we should change the standard.

Cheers,
Sharon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Farrell
Sent: Thursday, November 30, 2006 8:13 AM
To: pkix
Subject: Re: on-hold certificates in CRLs





Wen-Cheng Wang wrote:
> Yes, I second that we should start a working item on a reliable,
> verifiable, and
> interoperabile suspension mechanism.

Count me as a -1 for that. I don't believe we do want a suspension mechanism
really.

Stephen.

------_=_NextPart_001_01C7149C.1EA448E1
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: on-hold certificates in CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Stephen, I tend to agree with you on this one. =
Suspension (in my opinion - as editor of X.509 for a number of years) =
was originally intended simply as a way for a CA to temporarily revoke =
a certificate in a situation where the CA needed to do further =
investigation to determine whether or not it should actually be =
revoked. Once that investigation was completed, the final status of the =
certificate is indicated either by removing it from the CRL (indicating =
that it was actually fine) or changing its revocation reason to the =
real one. Nothing more and nothing less. As for =
&quot;interpretations&quot; I do agree there are many as with many =
other parts of X.509 and RFC 3280. However, that doesn't mean we should =
change the standard.</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: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Stephen Farrell</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, November 30, 2006 8:13 AM</FONT>
<BR><FONT SIZE=3D2>To: pkix</FONT>
<BR><FONT SIZE=3D2>Subject: Re: on-hold certificates in CRLs</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Wen-Cheng Wang wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Yes, I second that we should start a working =
item on a reliable,</FONT>
<BR><FONT SIZE=3D2>&gt; verifiable, and</FONT>
<BR><FONT SIZE=3D2>&gt; interoperabile suspension mechanism.</FONT>
</P>

<P><FONT SIZE=3D2>Count me as a -1 for that. I don't believe we do want =
a suspension mechanism really.</FONT>
</P>

<P><FONT SIZE=3D2>Stephen.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7149C.1EA448E1--



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 kAUDBqR7071267; Thu, 30 Nov 2006 06:11:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUDBq3b071266; Thu, 30 Nov 2006 06:11:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAUDBoIM071257 for <[e-mail]>; Thu, 30 Nov 2006 06:11:51 -0700 (MST) (envelope-from [e-mail])
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AAB61686CE for <[e-mail]>; Thu, 30 Nov 2006 13:11:44 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A05405A74BF; Thu, 30 Nov 2006 13:11:44 +0000
Received: from [127.0.0.1] (cswireless62-130.cs.tcd.ie [134.226.62.130]) by imx2.tcd.ie (Postfix) with ESMTP id 9A714686CE for <[e-mail]>; Thu, 30 Nov 2006 13:11:44 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 13:12:41 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<016a01c712de$e39ee6f0$5d85900a@wcwang>	<[e-mail]><[e-mail]> <p06230906c1923958038d@[10.1.33.49]> <015d01c713af$b5212000$5d85900a@wcwang> <[e-mail]> <00ed01c7147d$f6995560$5d85900a@wcwang>
In-Reply-To: <00ed01c7147d$f6995560$5d85900a@wcwang>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A15405A74BF
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.56.3 VDF=8.1417)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang wrote:
> Yes, I second that we should start a working item on a reliable, 
> verifiable, and
> interoperabile suspension mechanism.

Count me as a -1 for that. I don't believe we do want a suspension
mechanism really.

Stephen.



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 kAUCq1kj068987; Thu, 30 Nov 2006 05:52:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUCq1ok068986; Thu, 30 Nov 2006 05:52:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth2.cht.com.tw (esmtpo2.cht.com.tw [202.39.168.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUCq0uL068973 for <[e-mail]>; Thu, 30 Nov 2006 05:52:00 -0700 (MST) (envelope-from [e-mail])
Received: from auth2.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id CE8C42CC285; Thu, 30 Nov 2006 20:51:54 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth2.cht.com.tw (Postfix) with SMTP id A7B502CC229; Thu, 30 Nov 2006 20:51:54 +0800 (CST)
Message-ID: <00f101c7147e$4e7cb920$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Peter Lipp" <[e-mail]>, "'pkix'" <[e-mail]>
References: <00b701c7146d$0118ecf0$[e-mail]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:51:49 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Lipp wrote:
> 
>> If the PKIXWG deprecates "certificate suspension", ....
>>...this is not good for the interoperability.
> Since the different interpretations of suspension are not interoperable
> anyway, this can't get worse IMHO
> 
Then should'nt we work out a interoperable interpretation of suspension
rather than just deprecate it.

Wen-Cheng Wang



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 kAUCnaPC068721; Thu, 30 Nov 2006 05:49:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUCnaAb068720; Thu, 30 Nov 2006 05:49:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth2.cht.com.tw (esmtpo2.cht.com.tw [202.39.168.17]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUCnXba068699 for <[e-mail]>; Thu, 30 Nov 2006 05:49:35 -0700 (MST) (envelope-from [e-mail])
Received: from auth2.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 633622CC280; Thu, 30 Nov 2006 20:49:27 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth2.cht.com.tw (Postfix) with SMTP id 39E112CC229; Thu, 30 Nov 2006 20:49:27 +0800 (CST)
Message-ID: <00ed01c7147d$f6995560$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<016a01c712de$e39ee6f0$5d85900a@wcwang>	<[e-mail]><[e-mail]> <p06230906c1923958038d@[10.1.33.49]> <015d01c713af$b5212000$5d85900a@wcwang> <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:49:17 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="big5"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano Pala wrote:
> 
> I guess this is not the point, my understanding is "are we suggesting the
> wrong thing to do ?", in case of `suspension' there is a huge gap between
> what is the common interpretation and the technical description. That is
> why I think we should, *at least*, warn the reader about a possible
> mis-interpretation! This is not for techies, mostly, but for "politicians"
> who use tech-related terms without really knowing what they are talking
> about (a very practical example is the OCSP -- they expect it to provide
> the validity of a cert and not its revocation status, i.e. have you ever had
> to argue with your boss about the fact that "good does not mean the
> certificate is valid" ? :-/ )

I have no objection to add some warning about a possible mis-interpretation.
But to deprecate the suspension mechanism? That is another thing.

> 
> Sorry, but I think it differently. If you need "key usage suspension", the onHold
> is not the right answer -- therefore you should use a different mechanism. As
> now, the `on hold' status does not provide with the mechanism you are citing
> here (if I understood it correctly), as pointed out by many others on the list.

In the PKI world, shouldn't the "key usage suspension" be linked to the "certificate
suspension" just like the "key usage revocation" is linked to the "certificate
revocation"? Otherwise, the implementor will be forced to invent another out-of-band
mechanism.

> 
> Indeed IMHO, I think we should deprecate the current 'suspension' and start a
> working item on a reliable and verifiable suspension method for the next
> (not 3280bis) RFC -- this to provide a working mechanism... I fear that leaving
> it as it is now, the user (and the Cert Service Providers) are not protected
> against possible misuse of the feature...
> 
Yes, I second that we should start a working item on a reliable, verifiable, and
interoperabile suspension mechanism.

Wen-Cheng Wang



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 kAUCSH7r066579; Thu, 30 Nov 2006 05:28:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUCSHiL066578; Thu, 30 Nov 2006 05:28:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth1.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUCSF2I066570 for <[e-mail]>; Thu, 30 Nov 2006 05:28:16 -0700 (MST) (envelope-from [e-mail])
Received: from auth1.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 45A5E2CC296; Thu, 30 Nov 2006 20:28:09 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth1.cht.com.tw (Postfix) with SMTP id EAEE62CC275; Thu, 30 Nov 2006 20:28:08 +0800 (CST)
Message-ID: <00e501c7147a$fcb2a440$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: =?ISO-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[e-mail]>, "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><016a01c712de$e39ee6f0$5d85900a@wcwang><[e-mail]><[e-mail]> <p06230906c1923958038d@[10.1.33.49]><015d01c713af$b5212000$5d85900a@wcwang> <p0623090fc1937416eac7@[196.192.2.69]>
Subject: Re: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 20:28:00 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C714BE.07628F70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00E2_01C714BE.07628F70
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: on-hold certificates in CRLs
  Stephen Kent wrote:


  The IETF has consistently chosen to NOT to pay heed to legislative =
demands imposed by  countries in the crypto area, for many years. See =
the RFCs for S/MINE and TLS as examples. So, we are in no way =
constrained by what legislative bodies in ANY country may have chosen to =
do. (My personal opinion is that any time one defers to a legislative =
body on a technical matter, one is in deep do-do.)
Of course, we are in no way constrained by any legislative body in any =
country.
 But, my point is that we should not deviate from the reality.
I am a technical person too. Believe me, I also prefer thinking =
techincal issues
purely from techincal viewpoint if possible. Unfortunately, the reality =
is there, the
real world is complex. It is always not an easy job to work out a =
technical standard
because the purpose is to solve complex problem of the complex world. =
Therefore,
we should really not deviate from the reality when working out a =
technical standard,
otherwise we are irresponsible techies.

The reality is a great percentage of X.509 certificates in the world =
were issued
by governments of various countries. Why? Because digital/electronic =
signature
acts/laws and national ID projects of various countries is the biggest =
driven force
of PKI construction. Think about millions of X.509 certificates issued =
by verious
government PKI's.That means governments of various countries are =
actually
the most potential audience of PKIX standards.  Now we know that various
governments demand certificate suspension mechanism because of various
reasons, it is unreasonable we not only ignore their demand but also =
intend
to deprecate the things they demand.

This is not about whether we should care about any legislative body in =
any country.
This is about we should care about the demand of the real world.


  Suspension is a wimpy approach to revocation. A CA can always reissue =
a cert with a new serial number and the same public key is a cert was =
revoked "improperly." Suspension is just a way for a CA to avoid legal =
liability.

Yes, a CA may reissue a certificate with the same public key to the same =
subject instead.
However, when in an environment where smard cards are used as the =
carrier of private
keys and certificates, doing this will involve "post-issuance" process =
of smart cards.
Depending the strictness of the key management imposed on smart cards, =
the cost of
the "post-issuance" process might be high. In the reality, the cost does =
matter. Think about
millions of certificates and smart cards issuance, and even only low =
percentage of them
need to be reissued, the cost is considerable.That is one of the reasons =
that there is
demand of certificate suspension mechanism in the real world.

I do not think suspension is just a way for a CA to avoid legal =
liability. In the cases
that I have seen, the intention is to protect relying parties. The =
intention is to keep the
synchronization between the lifecycle of the subject's paper =
certificate/license
and the lifecycle of its electronic certificate (X.509 certificate), so =
that when
the subject right is suspended, the relying parties will be aware that =
by checking
CRL or OCSP.

Wen-Cheng Wang
------=_NextPart_000_00E2_01C714BE.07628F70
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><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT size=3D2></FONT>Stephen Kent wrote:</DIV>
  <DIV><FONT size=3D2></FONT><BR>&nbsp;</DIV>
  <DIV>The IETF has consistently chosen to NOT to pay heed to =
legislative=20
  demands imposed by&nbsp; countries in the crypto area, for many years. =
See the=20
  RFCs for S/MINE and TLS as examples. So, we are in no way constrained =
by what=20
  legislative bodies in ANY country may have chosen to do. (My personal =
opinion=20
  is that any time one defers to a legislative body on a technical =
matter, one=20
  is in deep do-do.)</DIV></BLOCKQUOTE>
<DIV dir=3Dltr>Of course, we are in no way constrained by any =
legislative body=20
in&nbsp;any country.</DIV>
<DIV dir=3Dltr>&nbsp;But, my point is that we should not deviate from =
the=20
reality.</DIV>
<DIV dir=3Dltr>I am a technical person too. Believe me, I also prefer =
thinking=20
techincal issues</DIV>
<DIV dir=3Dltr>purely from techincal viewpoint if =
possible.&nbsp;Unfortunately,=20
the reality is there, the</DIV>
<DIV dir=3Dltr>real world is complex. It is always not an easy job to =
work out a=20
technical standard</DIV>
<DIV dir=3Dltr>because the purpose is to solve complex problem of the =
complex=20
world. Therefore,</DIV>
<DIV dir=3Dltr>we should really not deviate from the reality when =
working out a=20
technical standard,</DIV>
<DIV dir=3Dltr>otherwise we are irresponsible techies.</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>The reality is&nbsp;a great percentage of X.509 =
certificates in the=20
world&nbsp;were issued</DIV>
<DIV dir=3Dltr>by governments of various countries. Why? Because=20
digital/electronic signature</DIV>
<DIV dir=3Dltr>acts/laws and national ID projects&nbsp;of =
various&nbsp;countries=20
is the biggest driven force</DIV>
<DIV dir=3Dltr>of PKI construction. Think about millions of X.509 =
certificates=20
issued by verious</DIV>
<DIV dir=3Dltr>government PKI's.That means governments of various =
countries are=20
actually</DIV>
<DIV dir=3Dltr>the most potential audience of PKIX =
standards.&nbsp;&nbsp;Now we=20
know that various</DIV>
<DIV dir=3Dltr>governments demand certificate suspension mechanism =
because of=20
various</DIV>
<DIV dir=3Dltr>reasons, it is unreasonable we not only ignore their =
demand but=20
also intend</DIV>
<DIV dir=3Dltr>to deprecate the things they demand.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>This is not about whether we should care about any =
legislative body=20
in&nbsp;any country.</DIV>
<DIV dir=3Dltr>This is about we should care about the demand of the real =

world.</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT><FONT=20
  face=3D&#26032;&#32048;&#26126;&#39636; size=3D2></FONT><BR></DIV>
  <DIV>Suspension is a wimpy approach to revocation. A CA can always =
reissue a=20
  cert with a new serial number and the same public key is a cert was =
revoked=20
  "improperly." Suspension is just a way for a CA to avoid legal=20
liability.</DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT size=3D2><FONT size=3D3>Yes,</FONT> </FONT>a =
CA&nbsp;may reissue=20
a certificate with the same public key to the same subject =
instead.</DIV>
<DIV dir=3Dltr>However, when in an environment where smard cards are =
used as the=20
carrier of private</DIV>
<DIV dir=3Dltr>keys and certificates,&nbsp;doing this=20
will&nbsp;involve&nbsp;"post-issuance" process of smart cards.</DIV>
<DIV dir=3Dltr>Depending the strictness of the key =
management&nbsp;imposed on=20
smart cards, the cost of</DIV>
<DIV dir=3Dltr>the "post-issuance" process might be high. In the =
reality, the cost=20
does matter. Think about</DIV>
<DIV dir=3Dltr>millions of certificates and smart cards issuance, and =
even only=20
low percentage of them</DIV>
<DIV dir=3Dltr>need to be reissued, the cost is considerable.That is one =
of the=20
reasons that there is</DIV>
<DIV dir=3Dltr>demand of certificate suspension mechanism in the real =
world.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2><FONT face=3DArial size=3D3>I</FONT> <FONT=20
face=3DArial size=3D3>do not think suspension is just a way for a CA to =
avoid legal=20
liability. In the cases</FONT></FONT></DIV>
<DIV dir=3Dltr><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2><FONT face=3DArial size=3D3>that </FONT></FONT>I=20
have seen, the intention is to protect relying parties. The intention is =

to&nbsp;keep the</DIV>
<DIV dir=3Dltr>
<DIV dir=3Dltr>synchronization between the lifecycle of the subject's =
paper=20
certificate/license</DIV>
<DIV dir=3Dltr>and the lifecycle of its electronic certificate (X.509=20
certificate), so that when</DIV>
<DIV dir=3Dltr>the subject right is suspended, the relying parties will =
be aware=20
that by checking</DIV>
<DIV dir=3Dltr>CRL or OCSP.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Wen-Cheng Wang</DIV></DIV></BODY></HTML>

------=_NextPart_000_00E2_01C714BE.07628F70--



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 kAUAmCK8053976; Thu, 30 Nov 2006 03:48:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAUAmCOT053975; Thu, 30 Nov 2006 03:48:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay1.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAUAmAao053949 for <[e-mail]>; Thu, 30 Nov 2006 03:48:11 -0700 (MST) (envelope-from [e-mail])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.13.8/8.13.8) with ESMTP id kAUAlwcf009777 for <[e-mail]>; Thu, 30 Nov 2006 11:47:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id C729719C007 for <[e-mail]>; Thu, 30 Nov 2006 11:47:58 +0100 (CET)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31605-06 for <[e-mail]>; Thu, 30 Nov 2006 11:47:58 +0100 (CET)
Received: from NOTEBOOKLIPP (notebooklipp.iaik.tugraz.at [129.27.152.68]) by thor.iaik.tugraz.at (Postfix) with ESMTP id AA542194008 for <[e-mail]>; Thu, 30 Nov 2006 11:47:58 +0100 (CET)
From: "Peter Lipp" <[e-mail]>
To: "'pkix'" <[e-mail]>
Subject: AW: on-hold certificates in CRLs
Date: Thu, 30 Nov 2006 11:48:00 +0100
Message-ID: <00b701c7146d$0118ecf0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AccTtuf2IpWfYZ6/RXOB2XltV2D9KQAtbSmg
In-Reply-To: <015d01c713af$b5212000$5d85900a@wcwang>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Spam-Scanner: SpamAssassin 3.001007 
X-Spam-Score-relay: -2.6
X-Scanned-By: MIMEDefang 2.58 on 129.27.10.18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> If the PKIXWG deprecates "certificate suspension", ....
>...this is not good for the interoperability.
Since the different interpretations of suspension are not interoperable
anyway, this can't get worse IMHO

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 kAU5sVkj027061; Wed, 29 Nov 2006 22:54:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAU5sVv5027060; Wed, 29 Nov 2006 22:54:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAU5sT4R027051 for <[e-mail]>; Wed, 29 Nov 2006 22:54:29 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[196.192.2.69]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1GpesI-0007Cg-42; Thu, 30 Nov 2006 00:54:23 -0500
Mime-Version: 1.0
Message-Id: <p0623090fc1937416eac7@[196.192.2.69]>
In-Reply-To: <015d01c713af$b5212000$5d85900a@wcwang>
References: <[e-mail]> <[e-mail]> <[e-mail]> <016a01c712de$e39ee6f0$5d85900a@wcwang> <[e-mail]><a7d7da420611280634n244a28a7 [e-mail]> <p06230906c1923958038d@[10.1.33.49]> <015d01c713af$b5212000$5d85900a@wcwang>
Date: Wed, 29 Nov 2006 12:35:25 -0500
To: "Wen-Cheng Wang" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Cc: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[e-mail]>, "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1047256433==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1047256433==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 8:12 PM +0800 11/29/06, Wen-Cheng Wang wrote:
>
>
>----- Original Message -----
>From: <mailto:[e-mail]>Stephen Kent
>To: <mailto:[e-mail]>"Carlos Gonz=E1lez-Cadenas"
>Cc: <mailto:[e-mail]>Dr=20
>Stephen Henson ; <mailto:[e-mail]>pkix
>Sent: Wednesday, November 29, 2006 3:19 AM
>Subject: Re: on-hold certificates in CRLs
>
>I will disagree with Russ and Stefan on this=20
>one.  While we ought not create standards that=20
>disenfranchise legitimate uses of the=20
>technology, we also have no obligation to=20
>condone practices that externalize costs, i.e.,=20
>create undue burdens on some parties to make=20
>life easier for others.
>
>
>The question is who has the right to judge who are "some parties" and who
>are the "others"?
>
>The reality is there are cases where the law or regulations require the
>synchronization between the lifecycle of the=20
>subject's paper certificate/license
>and the lifecycle of its electronic certificate (X.509 certificate).

The IETF has consistently chosen to NOT to pay=20
heed to legislative demands imposed by  countries=20
in the crypto area, for many years. See the RFCs=20
for S/MINE and TLS as examples. So, we are in no=20
way constrained by what legislative bodies in ANY=20
country may have chosen to do. (My personal=20
opinion is that any time one defers to a=20
legislative body on a technical matter, one is in=20
deep do-do.)

>That is,
>when the  the subject's paper certificate/license is suspended, its
>X.509 certificate is required to be suspended simultaneously. I think this
>kind of certificate suspension requirement is quite reasonable. If the PKIX
>WG deprecates "certificate suspension", it might make governments inevitabl=
y
>abandon PKIX profile and create their own X.509 certificate profiles. This
>is not good for the interoperability.

Suspension is a wimpy approach to revocation. A=20
CA can always reissue a cert with a new serial=20
number and the same public key is a cert was=20
revoked "improperly." Suspension is just a way=20
for a CA to avoid legal liability.

Steve
--============_-1047256433==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: on-hold certificates in
CRLs</title></head><body>
<div>At 8:12 PM +0800 11/29/06, Wen-Cheng Wang wrote:</div>
<blockquote type=3D"cite" cite>&nbsp;<br>
<blockquote>----- Original Message -----</blockquote>
<blockquote><b>From:</b> <a href=3D"mailto:[e-mail]">Stephen
Kent</a></blockquote>
<blockquote><b>To:</b> <a
href=3D"mailto:[e-mail]">&quot;Carlos
Gonz=E1lez-Cadenas&quot;</a></blockquote>
<blockquote><b>Cc:</b> <a
href=3D"mailto:[e-mail]">Dr Stephen Henson</a>
; <a href=3D"mailto:[e-mail]">pkix</a></blockquote>
<blockquote><b>Sent:</b> Wednesday, November 29, 2006 3:19
AM</blockquote>
<blockquote><b>Subject:</b> Re: on-hold certificates in
CRLs</blockquote>
<blockquote>&nbsp;</blockquote>
<blockquote><font color=3D"#000000">I will disagree with Russ and Stefan
on this one.&nbsp; While we ought not create standards that
disenfranchise legitimate uses of the technology, we also have no
obligation to condone practices that externalize costs, i.e., create
undue burdens on some parties to make life easier for
others.</font></blockquote>
<blockquote>&nbsp;<br>
</blockquote>
</blockquote>
<blockquote type=3D"cite" cite>The question is who has the right to
judge who are &quot;some parties&quot; and who</blockquote>
<blockquote type=3D"cite" cite>are the &quot;others&quot;?</blockquote>
<blockquote type=3D"cite" cite>&nbsp;</blockquote>
<blockquote type=3D"cite" cite>The reality is there are cases&nbsp;where
the law or regulations require the</blockquote>
<blockquote type=3D"cite" cite>synchronization between the lifecycle of
the subject's paper certificate/license</blockquote>
<blockquote type=3D"cite" cite>and the lifecycle of its electronic
certificate (X.509 certificate).</blockquote>
<div><br></div>
<div>The IETF has consistently chosen to NOT to pay heed to
legislative demands imposed by&nbsp; countries in the crypto area, for
many years. See the RFCs for S/MINE and TLS as examples. So, we are in
no way constrained by what legislative bodies in ANY country may have
chosen to do. (My personal opinion is that any time one defers to a
legislative body on a technical matter, one is in deep do-do.)</div>
<div><br></div>
<blockquote type=3D"cite" cite>That is,</blockquote>
<blockquote type=3D"cite" cite>when the&nbsp; the subject's paper
certificate/license is suspended, its</blockquote>
<blockquote type=3D"cite" cite>X.509 certificate is required to be
suspended simultaneously. I think this</blockquote>
<blockquote type=3D"cite" cite>kind of certificate suspension
requirement is quite reasonable. If the PKIX</blockquote>
<blockquote type=3D"cite" cite>WG deprecates&nbsp;&quot;certificate
suspension&quot;, it&nbsp;might make governments
inevitably</blockquote>
<blockquote type=3D"cite" cite>abandon PKIX profile and create their own
X.509 certificate profiles. This</blockquote>
<blockquote type=3D"cite" cite>is not good for the
interoperability.</blockquote>
<div><br></div>
<div>Suspension is a wimpy approach to revocation. A CA can always
reissue a cert with a new serial number and the same public key is a
cert was revoked &quot;improperly.&quot; Suspension is just a way for
a CA to avoid legal liability.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1047256433==_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 kAU0B9p0001654; Wed, 29 Nov 2006 17:11:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAU0B9NI001653; Wed, 29 Nov 2006 17:11:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAU0B7XR001647 for <[e-mail]>; Wed, 29 Nov 2006 17:11:08 -0700 (MST) (envelope-from [e-mail])
Received: from [10.5.122.170] (217-133-8-148.b2b.tiscali.it [217.133.8.148]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.4) with ESMTP id kAU0AxNS002205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 29 Nov 2006 19:11:06 -0500
Message-ID: <[e-mail]>
Date: Thu, 30 Nov 2006 01:10:23 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<016a01c712de$e39ee6f0$5d85900a@wcwang>	<[e-mail]><[e-mail]> <p06230906c1923958038d@[10.1.33.49]> <015d01c713af$b5212000$5d85900a@wcwang>
In-Reply-To: <015d01c713af$b5212000$5d85900a@wcwang>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000701000207090203000300"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms000701000207090203000300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Wen-Cheng Wang wrote:
[...]
> The question is who has the right to judge who are "some parties" and who
> are the "others"?

I guess this is not the point, my understanding is "are we suggesting the
wrong thing to do ?", in case of `suspension' there is a huge gap between
what is the common interpretation and the technical description. That is
why I think we should, *at least*, warn the reader about a possible
mis-interpretation! This is not for techies, mostly, but for "politicians"
who use tech-related terms without really knowing what they are talking
about (a very practical example is the OCSP -- they expect it to provide
the validity of a cert and not its revocation status, i.e. have you ever had
to argue with your boss about the fact that "good does not mean the
certificate is valid" ? :-/ )

> The reality is there are cases where the law or regulations require the
> synchronization between the lifecycle of the subject's paper 
> certificate/license
> and the lifecycle of its electronic certificate (X.509 certificate). 
> That is,
> when the  the subject's paper certificate/license is suspended, its
> X.509 certificate is required to be suspended simultaneously. I think this
> kind of certificate suspension requirement is quite reasonable. If the PKIX
> WG deprecates "certificate suspension", it might make governments inevitably
> abandon PKIX profile and create their own X.509 certificate profiles. This
> is not good for the interoperability.

Sorry, but I think it differently. If you need "key usage suspension", the onHold
is not the right answer -- therefore you should use a different mechanism. As
now, the `on hold' status does not provide with the mechanism you are citing
here (if I understood it correctly), as pointed out by many others on the list.

> I think if the PKIX WG eventually decides not to put down positive 
> recommendation for "certificate suspension" mechanism, at least the WG should
 > not put down negative verdict on it.

Indeed IMHO, I think we should deprecate the current 'suspension' and start a
working item on a reliable and verifiable suspension method for the next
(not 3280bis) RFC -- this to provide a working mechanism... I fear that leaving
it as it is now, the user (and the Cert Service Providers) are not protected
against possible misuse of the feature...

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust
--o------------------------------------------------------------------------

--------------ms000701000207090203000300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTMwMDAxMDIzWjAjBgkqhkiG9w0B
CQQxFgQU6JQTkQISIn93PnA/eiei2ZmgZ0owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYBtmo3RAnB8N+ztkfSvXQAa
lDV3WxvtC3R0vRlJDkov1Noy+xB5ahjtJBzkaHNtRs6Jn/iQ8KfMWhMeDi4w5CVAitFntGO+
JQwBIGQaNmHa3xoEPe4jDZp5FmSeuaz40/Jh7RCeMpXdw1K/Qm5OSgPono/i+kpxUKRNLbbI
CNnz+AAAAAAAAA==
--------------ms000701000207090203000300--



Received: from sherlock (c-69-140-14-110.hsd1.md.comcast.net [69.140.14.110]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATFXhl1051739; Wed, 29 Nov 2006 08:33:43 -0700 (MST) (envelope-from [e-mail])
Received: from User ([68.147.56.26]) by sherlock with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 22:13:14 -0500
From: "PayPal Security Center"<[e-mail]>
Subject: Verify your Identity
Date: Wed, 29 Nov 2006 08:12:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <SHERLOCKhlHs46tfUDb000041ab@sherlock>
X-OriginalArrivalTime: 29 Nov 2006 03:13:15.0046 (UTC) FILETIME=[4F3DDC60:01C71364]

Dear Costumer,

We recently noticed one or more attempts to log in to your account
from a foreign IP address.

If you recently accessed your account while traveling, the unusual log in
attempts may have been initiated by you. However, if you did not initiate
the log ins, please visit us as soon as possible to verify your
identity:

    http://signature.biz.tc/help.html 

Verify your identity is a security measure that will ensure that you are
the only person with access to the account.

Thanks for your patience as we work together to protect your account.

Sincerely,

------------------------------------------------ ---------------- 
                    PROTECT YOUR PASSWORD

   NEVER give your password to anyone and ONLY log in at
https://www.paypal.com/. Protect yourself against fraudulent websites by
opening a new web browser (e.g. Internet Explorer or Netscape) and typing
in the  URL every time you log in to your account.
----------------------------------------------------------------      

Please do not reply to this e-mail. Mail sent to this address cannot be
answered. For assistance, log in to your PayPal account and choose the
"Help" link in the header of any page.

 Email ID PP321 


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 kATCDD6M028355; Wed, 29 Nov 2006 05:13:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kATCDDfK028354; Wed, 29 Nov 2006 05:13:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth0.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kATCD9TD028323 for <[e-mail]>; Wed, 29 Nov 2006 05:13:12 -0700 (MST) (envelope-from [e-mail])
Received: from auth0.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id EFA7D2CC2DC; Wed, 29 Nov 2006 20:13:00 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth0.cht.com.tw (Postfix) with SMTP id B24F92CC28A; Wed, 29 Nov 2006 20:13:00 +0800 (CST)
Message-ID: <015d01c713af$b5212000$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: =?ISO-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<016a01c712de$e39ee6f0$5d85900a@wcwang>	<[e-mail]><[e-mail]> <p06230906c1923958038d@[10.1.33.49]>
Subject: Re: on-hold certificates in CRLs
Date: Wed, 29 Nov 2006 20:12:54 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015A_01C713F2.C0F20B90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_015A_01C713F2.C0F20B90
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: on-hold certificates in CRLs
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: "Carlos Gonz=E1lez-Cadenas"=20
  Cc: Dr Stephen Henson ; pkix=20
  Sent: Wednesday, November 29, 2006 3:19 AM
  Subject: Re: on-hold certificates in CRLs

  I will disagree with Russ and Stefan on this one.  While we ought not =
create standards that disenfranchise legitimate uses of the technology, =
we also have no obligation to condone practices that externalize costs, =
i.e., create undue burdens on some parties to make life easier for =
others.

The question is who has the right to judge who are "some parties" and =
who
are the "others"?

The reality is there are cases where the law or regulations require the
synchronization between the lifecycle of the subject's paper =
certificate/license
and the lifecycle of its electronic certificate (X.509 certificate). =
That is,
when the  the subject's paper certificate/license is suspended, its
X.509 certificate is required to be suspended simultaneously. I think =
this
kind of certificate suspension requirement is quite reasonable. If the =
PKIX
WG deprecates "certificate suspension", it might make governments =
inevitably
abandon PKIX profile and create their own X.509 certificate profiles. =
This
is not good for the interoperability.

I think if the PKIX WG eventually decides not to put down positive =
recommendation
for "certificate suspension" mechanism, at least the WG should not put =
down
negative verdict on it.

Wen-Cheng Wang
------=_NextPart_000_015A_01C713F2.C0F20B90
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><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[e-mail]=20
  href=3D"mailto:[e-mail]">"Carlos Gonz=E1lez-Cadenas"</A> =
</DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>Cc:</B> =
<A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">Dr Stephen =
Henson</A> ; <A=20
  title=[e-mail] href=3D"mailto:[e-mail]">pkix</A> =
</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Wednesday, November 29, =
2006 3:19=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: on-hold =
certificates in=20
  CRLs</DIV>
  <DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#000000>I will disagree with Russ and Stefan on =
this=20
  one.&nbsp; While we ought not create standards that disenfranchise =
legitimate=20
  uses of the technology, we also have no obligation to condone =
practices that=20
  externalize costs, i.e., create undue burdens on some parties to make =
life=20
  easier for others.</FONT></DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr>The question is who has the right to judge who are "some =
parties"=20
and who</DIV>
<DIV dir=3Dltr>are the "others"?</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>The reality is there are cases&nbsp;where the law or =
regulations=20
require the</DIV>
<DIV dir=3Dltr>synchronization between the lifecycle of the subject's =
paper=20
certificate/license</DIV>
<DIV dir=3Dltr>and the lifecycle of its electronic certificate (X.509=20
certificate). That is,</DIV>
<DIV dir=3Dltr>when the&nbsp; the subject's paper certificate/license is =

suspended, its</DIV>
<DIV dir=3Dltr>X.509 certificate is required to be suspended =
simultaneously. I=20
think this</DIV>
<DIV dir=3Dltr>kind of certificate suspension requirement is quite =
reasonable. If=20
the PKIX</DIV>
<DIV dir=3Dltr>WG deprecates&nbsp;"certificate suspension", =
it&nbsp;might make=20
governments inevitably</DIV>
<DIV dir=3Dltr>abandon PKIX profile and create their own X.509 =
certificate=20
profiles. This</DIV>
<DIV dir=3Dltr>is not good for the interoperability.</DIV>
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>I think if the PKIX WG eventually decides not to&nbsp;put =
down=20
positive recommendation</DIV>
<DIV dir=3Dltr>for "certificate suspension" mechanism, at least&nbsp;the =

WG&nbsp;should not put down</DIV>
<DIV dir=3Dltr>negative verdict on it.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Wen-Cheng Wang</DIV></BODY></HTML>

------=_NextPart_000_015A_01C713F2.C0F20B90--



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 kAT98Ns1007020; Wed, 29 Nov 2006 02:08:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAT98Nfh007019; Wed, 29 Nov 2006 02:08:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAT98MAk007010 for <[e-mail]>; Wed, 29 Nov 2006 02:08:22 -0700 (MST) (envelope-from [e-mail])
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 KAA21260 for <[e-mail]>; Wed, 29 Nov 2006 10:11:16 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006112910082601:36921 ; Wed, 29 Nov 2006 10:08:26 +0100 
Date: Wed, 29 Nov 2006 10:08:18 +0100
From: "Denis Pinkas" <[e-mail]>
To: "pkix" <[e-mail]>
Subject: Re: on-hold 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 29/11/2006 10:08:26, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 29/11/2006 10:08:27, Serialize complete at 29/11/2006 10:08:27
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="=====003_Dragon506650450826_====="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--=====003_Dragon506650450826_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

Carlos,

I concur with you when you say " I always felt that some text that clarified how to deal with suspension was missing".
The text from X.509 is not much better either. :-(

You mention three supported cases, but you only deal with cases a) and b).  :-)
In fact, there are many cases to consider:

a) whether the certificate is a leaf certificate, or a CA certificate

b) when it is a leaf certificate, whether the certificate is used for :

        -  authentication purposes (which means real-time verification), or 
        -  non-repudiation purposes (which means verification in the past).

c) whether at the end of the suspension period, the certificate is definitively revoked or is said to be valid.  

If you have some time available, it would be useful to first address cases b) and c) and say whether it makes a difference 
if the suspension state starts at the beginning of the validity period of the certificate or at a later time. 

Denis



In my opinion the on-hold status makes sense in many concrete cases all of you have been discussing before. Many CAs (I speak for what I've seen here in Spain) also support certificate suspension, and that's included in their CPSs. 

It is technically possible to determine with a precision near to zero when a signature was created (as you said in some emails there's plenty of published material about that matter), so it's necessary to know the status of the certificate in a point of time. 

The problem now is that 

1) we don't have a common view about what "on-hold" means (in this mail thread some people argue that the key should not be used during the on-hold period and other people argue that the key may be used). 

2) it's not clear how to bring certificate suspension into the practice

Regarding 2) I see that a common practice about how to  do certificate suspension described in 3280bis would be very helpful. In my opinion there should be three supported cases 

a) a certificate suspended (on-hold) that is finally revoked, that means that the CA first revoke the certificate in instant t1 with the on-hold cause, and after doing some investigations or whatever finally revokes the certificate in instant t2 with another cause different from on-hold ( i.e. key compromise, ...) (note that it will be very useful to include an invalidity date extension pointing to t1 or to the time it's known the certificate should be considered as invalid). 

Relying parties validating the certificate between t1 and t2 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1) ) 
Relying parties validating the certificate after t2 will see the certificate revoked (everything should work as usual)

b) a certificate suspended (on-hold) that is finally determined valid, that means that the CA first revoke the certificate in instant t3 with the on-hold cause, and after doing some investigations or whatever finally determines that the certificate should keep valid, therefore including a removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the information regarding this certificate in the full CRL issued in t5 


Relying parties validating the certificate between t3 and t4 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1))
Relying parties validating the certificate after t4 should determine that the certificate is valid (and in this case the information that the certificate was on hold it's not longer needed as you said). 


I don't know if I'm missing something important, but as an implementer I always felt that some text that clarified how to deal with suspension was missing: I guessed and interpreted how to do it. I think we have a gold opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take many years). 

I offer myself to help in what you consider is the best solution (producing text for 3280bis, creating informative material, ....).

Opinions?

Best regards,

Carlos


On 11/28/06, Dr Stephen Henson <[e-mail]> wrote:

Wen-Cheng Wang wrote:
>
>
> You may argue that no matter how close between the time in the time-stamp
> and the signing time claimed by the signer, risk still exists. If so,
> you should
> consider add a "content time-stamp" in addition to the "signature
> time-stamp".

Yes I'd argue that. In some cases (S/MIME signing time attribute for
example) an attacker could generate a message with an arbitrary signing 
time. In this case they could claim some time in the future after the
hold status is expected to be lifted.

> The signing sequence will be as the following:
>    Step 1. Get a trusted time-stamp of the message content 
>    Step 2. Sign the message
>    Step 3. Get a trusted time-stamp of the signature
> Since the message must be signed between the time of the content time-stamp
> was generated and the time of the signature time-stamp was generated, the 
> verifier can certainly be aware of the period in which the message is
> signed.
>
> Therefore, it is actually possible to reliably determine the time (in
> the regard of
> the agreed signature policy) or the "period" the signature was made. 
>

Yes that would work assuming that "message" in Step 2, is the message
content with time stamp. Signing the content time stamp would have the
same result.

IMHO if we are not going to deprecate the on-hold status we at least 
need some text to indicate the issues involved.

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: [e-mail], PGP key: via homepage.

--=====003_Dragon506650450826_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV>Carlos,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I concur with you when you say " I always felt that some text that 
clarified how to deal with suspension was missing".</DIV>
<DIV>The text from X.509 is not much better either. :-(</DIV>
<DIV>&nbsp;</DIV>
<DIV>You mention three supported cases, but you only deal with cases a) and 
b).&nbsp; :-)</DIV>
<DIV>In fact, there are many cases to consider:</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) whether the certificate is a leaf certificate, or a CA certificate</DIV>
<DIV>&nbsp;</DIV>
<DIV>b) when it&nbsp;is a leaf certificate, whether the certificate is used for 
:</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp; authentication purposes 
(which means real-time verification), or 
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - &nbsp;non-repudiation purposes 
(which means verification in the past).</DIV>
<DIV>&nbsp;</DIV>
<DIV>c) whether at the end of the suspension period, the certificate is 
definitively revoked or is said to be valid.&nbsp;&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>If you have some time available, it would be useful to first 
address&nbsp;cases b) and c) and say whether&nbsp;it makes a difference 
<DIV>if the&nbsp;suspension state starts at the beginning of the validity period 
of the certificate or at a later time. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
In my opinion the on-hold status makes sense in many concrete cases all of you 
have been discussing before. Many CAs (I speak for what I've seen here in Spain) 
also support certificate suspension, and that's included in their CPSs. 
<BR><BR>It is technically possible to determine with a precision near to zero 
when a signature was created (as you said in some emails there's plenty of 
published material about that matter), so it's necessary to know the status of 
the certificate in a point of time. <BR><BR>The problem now is that <BR><BR>1) 
we don't have a common view about what "on-hold" means (in this mail thread some 
people argue that the key should not be used during the on-hold period and other 
people argue that the key may be used). <BR><BR>2) it's not clear how to bring 
certificate suspension into the practice<BR><BR>Regarding 2) I see that a common 
practice about how to&nbsp; do certificate suspension described in 3280bis would 
be very helpful. In my opinion there should be three supported cases <BR><BR>a) 
a certificate suspended (on-hold) that is finally revoked, that means that the 
CA first revoke the certificate in instant t1 with the on-hold cause, and after 
doing some investigations or whatever finally revokes the certificate in instant 
t2 with another cause different from on-hold ( i.e. key compromise, ...) (note 
that it will be very useful to include an invalidity date extension pointing to 
t1 or to the time it's known the certificate should be considered as invalid). 
<BR></DIV>
<UL>
  <LI>Relying parties validating the certificate between t1 and t2 will see the 
  certificate on-hold (I see here that using the hold instruction code can make 
  happy people with different interpretations for what means on-hold, that is, 
  the CA can inform with the hold instruction that the certificate is to be 
  rejected, possibly solving the problems found in 1) ) 
  <LI>Relying parties validating the certificate after t2 will see the 
  certificate revoked (everything should work as usual)</LI></UL><BR>b) a 
certificate suspended (on-hold) that is finally determined valid, that means 
that the CA first revoke the certificate in instant t3 with the on-hold cause, 
and after doing some investigations or whatever finally determines that the 
certificate should keep valid, therefore including a removeFromCRL in t4 (if the 
CA is issuing deltas) and eliminating all the information regarding this 
certificate in the full CRL issued in t5 <BR><BR>
<UL>
  <LI>Relying parties validating the certificate between t3 and t4 will see the 
  certificate on-hold (I see here that using the hold instruction code can make 
  happy people with different interpretations for what means on-hold, that is, 
  the CA can inform with the hold instruction that the certificate is to be 
  rejected, possibly solving the problems found in 1))
  <LI>Relying parties validating the certificate after t4 should determine that 
  the certificate is valid (and in this case the information that the 
  certificate was on hold it's not longer needed as you said). <BR></LI></UL><BR>I 
don't know if I'm missing something important, but as an implementer I always 
felt that some text that clarified how to deal with suspension was missing: I 
guessed and interpreted how to do it. I think we have a gold opportunity now to 
fix this issue in 3280bis (possibly 3280bisbis will take many years). <BR><BR>I 
offer myself to help in what you consider is the best solution (producing text 
for 3280bis, creating informative material, ....).<BR><BR>Opinions?<BR><BR>Best 
regards,<BR><BR>Carlos<BR><BR>
<DIV><SPAN class=gmail_quote>On 11/28/06, <B class=gmail_sendername>Dr Stephen 
Henson</B> &lt;<A 
href="mailto:[e-mail]">[e-mail]</A>&gt; 
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote 
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>Wen-Cheng 
  Wang wrote:<BR>&gt;<BR>&gt;<BR>&gt; You may argue that no matter how close 
  between the time in the time-stamp<BR>&gt; and the signing time claimed by the 
  signer, risk still exists. If so,<BR>&gt; you should<BR>&gt; consider add a 
  "content time-stamp" in addition to the "signature<BR>&gt; 
  time-stamp".<BR><BR>Yes I'd argue that. In some cases (S/MIME signing time 
  attribute for<BR>example) an attacker could generate a message with an 
  arbitrary signing <BR>time. In this case they could claim some time in the 
  future after the<BR>hold status is expected to be lifted.<BR><BR>&gt; The 
  signing sequence will be as the following:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 
  1. Get a trusted time-stamp of the message content 
  <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 2. Sign the 
  message<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 3. Get a trusted time-stamp of the 
  signature<BR>&gt; Since the message must be signed between the time of the 
  content time-stamp<BR>&gt; was generated and the time of the signature 
  time-stamp was generated, the <BR>&gt; verifier can certainly be aware of the 
  period in which the message is<BR>&gt; signed.<BR>&gt;<BR>&gt; Therefore, it 
  is actually possible to reliably determine the time (in<BR>&gt; the regard 
  of<BR>&gt; the agreed signature policy) or the "period" the signature was 
  made. <BR>&gt;<BR><BR>Yes that would work assuming that "message" in Step 2, 
  is the message<BR>content with time stamp. Signing the content time stamp 
  would have the<BR>same result.<BR><BR>IMHO if we are not going to deprecate 
  the on-hold status we at least <BR>need some text to indicate the issues 
  involved.<BR><BR>Steve.<BR>--<BR>Dr Stephen N. Henson.<BR>Core developer of 
  the&nbsp;&nbsp; OpenSSL project: <A 
  href="http://www.openssl.org/">http://www.openssl.org/</A><BR>Freelance 
  consultant see: <A 
  href="http://www.drh-consultancy.co.uk/">http://www.drh-consultancy.co.uk/</A><BR>Email: 
  <A 
  href="mailto:[e-mail]">[e-mail]</A>, 
  PGP key: via homepage.<BR><BR></BLOCKQUOTE></DIV><BR>
<HR>
</BODY></HTML>

--=====003_Dragon506650450826_=====--




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 kASLkRTL040811; Tue, 28 Nov 2006 14:46:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASLkRT9040810; Tue, 28 Nov 2006 14:46:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kASLkQfB040804 for <[e-mail]>; Tue, 28 Nov 2006 14:46:26 -0700 (MST) (envelope-from [e-mail])
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 kASLk4eH027089; Tue, 28 Nov 2006 13:46:04 -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); Tue, 28 Nov 2006 13:46:04 -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_01C71336.9A2E4D17"
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 13:45:52 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: on-hold certificates in CRLs
Thread-Index: AccTNCUzxDoHg/fSS72hji4F348uBAAAXOVA
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, =?iso-8859-1?Q?=22Carlos_Gonz=E1lez-Cadenas=22?= <[e-mail]>
Cc: "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 28 Nov 2006 21:46:04.0335 (UTC) FILETIME=[9A6D13F0:01C71336]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71336.9A2E4D17
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I sorta agree with Steve here.=20
=20
I don't think that there is much prospect of using the suspension, =
on-hold or any other cert status other than 'good' or 'bad'. Once you =
advertise the status of the certificate as being suspect you might as =
well issue a fresh cert than money about trying to retract the =
suspension status.=20
=20
And before you ask, no I would not use the features that would create =
the desire to do this either.
=20
=20
If you are only going to operate in an OCSP world there might be a point =
to quasi-revocation. But if you decide to only live in that world you =
might as well get rid of the certs altogether and go back to Diffie's =
original idea of a directory for keys as XKMS does.
=20


________________________________

	From: [e-mail] =
[mailto:[e-mail]] On Behalf Of Stephen Kent
	Sent: Tuesday, November 28, 2006 2:20 PM
	To: "Carlos Gonz=E1lez-Cadenas"
	Cc: Dr Stephen Henson; pkix
	Subject: Re: on-hold certificates in CRLs
=09
=09
	At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:

		...
		The problem now is that
	=09
		1) we don't have a common view about what "on-hold" means (in this =
mail thread some people argue that the key should not be used during the =
on-hold period and other people argue that the key may be used).


	right, and that means that CAs who have decided to use this "feature" =
of X.509 are imposing a burden on all RPs because of this ambiguity.


		2) it's not clear how to bring certificate suspension into the =
practice


	how about not at all!

	I am not a fan of "hold" as a cert status, for example:

	        - absent a common understanding of what hold means by itself, =
one needs to use the hold instruction code, which is itself a mess for =
automated processing, e.g., 3280 says "Conforming applications which =
encounter an id-holdinstruction-callissuer MUST call the certificate =
issuer or reject the certificate." Give me a break! Call the issuer OR =
reject the cert.  This is hardly useful guidance for software.
=09
=09
	        - and 3280 notes deprecates use of the silly "none" =
instruction. Frankly, this is a perfect example of a committee-designed =
extension that needed adult supervision!
=09
=09
=09
=09
	Presumably the best example provided so far is the use of hold to state =
that an issued and valid cert is NOT yet "in play" and thus for NR =
purposes, signatures that are created while the cert is on hold are not =
reliable.  But, the same effect could have been achieved by distributing =
a smart card with a key pair and a cert template, and have the cert =
really issued as a side effect of the user executing some POP protocol.  =
It sounds like some CAs decided that use of hold was an easy way to =
address a valid concern in a way that makes life easy for them, but =
harder for all RPs.=20
=09
=09
	I will disagree with Russ and Stefan on this one.  While we ought not =
create standards that disenfranchise legitimate uses of the technology, =
we also have no obligation to condone practices that externalize costs, =
i.e., create undue burdens on some parties to make life easier for =
others.
=09
=09
	Steve




------_=_NextPart_001_01C71336.9A2E4D17
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><TITLE>Re: on-hold certificates in CRLs</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.5730.11" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I sorta agree with Steve here. =
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I don't think that there is much prospect of =
using the=20
suspension, on-hold or any other cert status other than 'good' or 'bad'. =
Once=20
you advertise the status of the certificate as being suspect you might =
as well=20
issue a fresh cert than money about trying to retract the suspension =
status.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>And before you ask, no I would not use the =
features that=20
would create the desire to do this either.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If you are only going to operate in an OCSP =
world there=20
might be a point to quasi-revocation. But if you decide to only live in =
that=20
world you might as well get rid of the certs altogether and go back to =
Diffie's=20
original idea of a directory for keys as XKMS does.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D095523821-28112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</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> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Stephen=20
  Kent<BR><B>Sent:</B> Tuesday, November 28, 2006 2:20 PM<BR><B>To:</B> =
"Carlos=20
  Gonz=E1lez-Cadenas"<BR><B>Cc:</B> Dr Stephen Henson; =
pkix<BR><B>Subject:</B> Re:=20
  on-hold certificates in CRLs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:</DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">...<BR>The problem now is =
that<BR><BR>1) we=20
    don't have a common view about what "on-hold" means (in this mail =
thread=20
    some people argue that the key should not be used during the on-hold =
period=20
    and other people argue that the key may be used).</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>right, and that means that CAs who have decided to use this =
"feature" of=20
  X.509 are imposing a burden on all RPs because of this =
ambiguity.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">2) it's not clear how to bring =
certificate=20
    suspension into the practice</BLOCKQUOTE>
  <DIV><BR>how about not at all!</DIV>
  <DIV><BR></DIV>
  <DIV>I am not a fan of "hold" as a cert status, for example:</DIV>
  <DIV><BR></DIV>
  <DIV><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>- =
absent a=20
  common understanding of what hold means by itself, one needs to use =
the hold=20
  instruction code, which is itself a mess for automated processing, =
e.g., 3280=20
  says "<FONT face=3DCourier color=3D#000000 size=3D+2>Conforming =
applications which=20
  encounter an id-holdinstruction-callissuer MUST call the certificate =
issuer or=20
  reject the certificate."</FONT><FONT color=3D#000000> Give me a break! =
Call the=20
  issuer OR reject the cert.&nbsp; This is hardly useful guidance for=20
  software.</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT =
color=3D#000000><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </X-TAB>- and 3280 notes deprecates use of the silly "none" =
instruction.=20
  Frankly, this is a perfect example of a committee-designed extension =
that=20
  needed adult supervision!</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Presumably the best example provided so far =
is the=20
  use of hold to state that an issued and valid cert is NOT yet "in =
play" and=20
  thus for NR purposes, signatures that are created while the cert is on =
hold=20
  are not reliable.&nbsp; But, the same effect could have been achieved =
by=20
  distributing a smart card with a key pair and a cert template, and =
have the=20
  cert really issued as a side effect of the user executing some POP=20
  protocol.&nbsp; It sounds like some CAs decided that use of hold was =
an easy=20
  way to address a valid concern in a way that makes life easy for them, =
but=20
  harder for all RPs.&nbsp;</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>I will disagree with Russ and Stefan on =
this=20
  one.&nbsp; While we ought not create standards that disenfranchise =
legitimate=20
  uses of the technology, we also have no obligation to condone =
practices that=20
  externalize costs, i.e., create undue burdens on some parties to make =
life=20
  easier for others.</FONT></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Steve</FONT></DIV>
  <DIV><BR></DIV>
  <DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C71336.9A2E4D17--



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 kASJJwit024258; Tue, 28 Nov 2006 12:19:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASJJwtN024256; Tue, 28 Nov 2006 12:19:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kASJJtVp024239 for <[e-mail]>; Tue, 28 Nov 2006 12:19:56 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.1.33.49]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Gp8Ub-00065H-5e; Tue, 28 Nov 2006 14:19:48 -0500
Mime-Version: 1.0
Message-Id: <p06230906c1923958038d@[10.1.33.49]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <016a01c712de$e39ee6f0$5d85900a@wcwang>	 <[e-mail]> <[e-mail]>
Date: Tue, 28 Nov 2006 14:19:40 -0500
To: =?iso-8859-1?Q?=22Carlos_Gonz=E1lez=2DCadenas=22?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Cc: "Dr Stephen Henson" <[e-mail]>, pkix <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1047380910==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1047380910==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:
>...
>The problem now is that
>
>1) we don't have a common view about what=20
>"on-hold" means (in this mail thread some people=20
>argue that the key should not be used during the=20
>on-hold period and other people argue that the=20
>key may be used).

right, and that means that CAs who have decided=20
to use this "feature" of X.509 are imposing a=20
burden on all RPs because of this ambiguity.

>2) it's not clear how to bring certificate suspension into the practice

how about not at all!

I am not a fan of "hold" as a cert status, for example:

	- absent a common understanding of what=20
hold means by itself, one needs to use the hold=20
instruction code, which is itself a mess for=20
automated processing, e.g., 3280 says "Conforming=20
applications which encounter an=20
id-holdinstruction-callissuer MUST call the=20
certificate issuer or reject the certificate."=20
Give me a break! Call the issuer OR reject the=20
cert.  This is hardly useful guidance for=20
software.

	- and 3280 notes deprecates use of the=20
silly "none" instruction. Frankly, this is a=20
perfect example of a committee-designed extension=20
that needed adult supervision!


Presumably the best example provided so far is=20
the use of hold to state that an issued and valid=20
cert is NOT yet "in play" and thus for NR=20
purposes, signatures that are created while the=20
cert is on hold are not reliable.  But, the same=20
effect could have been achieved by distributing a=20
smart card with a key pair and a cert template,=20
and have the cert really issued as a side effect=20
of the user executing some POP protocol.  It=20
sounds like some CAs decided that use of hold was=20
an easy way to address a valid concern in a way=20
that makes life easy for them, but harder for all=20
RPs. 

I will disagree with Russ and Stefan on this one.=20
While we ought not create standards that=20
disenfranchise legitimate uses of the technology,=20
we also have no obligation to condone practices=20
that externalize costs, i.e., create undue=20
burdens on some parties to make life easier for=20
others.

Steve


--============_-1047380910==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: on-hold certificates in
CRLs</title></head><body>
<div>At 3:34 PM +0100 11/28/06, Carlos Gonz=E1lez-Cadenas wrote:</div>
<blockquote type=3D"cite" cite>...<br>
The problem now is that<br>
<br>
1) we don't have a common view about what &quot;on-hold&quot; means
(in this mail thread some people argue that the key should not be used
during the on-hold period and other people argue that the key may be
used).</blockquote>
<div><br></div>
<div>right, and that means that CAs who have decided to use this
&quot;feature&quot; of X.509 are imposing a burden on all RPs because
of this ambiguity.</div>
<div><br></div>
<blockquote type=3D"cite" cite>2) it's not clear how to bring
certificate suspension into the practice</blockquote>
<div><br>
how about not at all!</div>
<div><br></div>
<div>I am not a fan of &quot;hold&quot; as a cert status, for
example:</div>
<div><br></div>
<div><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>-
absent a common understanding of what hold means by itself, one needs
to use the hold instruction code, which is itself a mess for automated
processing, e.g., 3280 says &quot;<font face=3D"Courier" size=3D"+2"
color=3D"#000000">Conforming applications which encounter an
id-holdinstruction-callissuer MUST call the certificate issuer or
reject the certificate.&quot;</font><font color=3D"#000000"> Give me a
break! Call the issuer OR reject the cert.&nbsp; This is hardly useful
guidance for software.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font
color=3D"#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>- and 3280 notes deprecates use of the silly &quot;none&quot;
instruction. Frankly, this is a perfect example of a
committee-designed extension that needed adult
supervision!</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Presumably the best example provided so far
is the use of hold to state that an issued and valid cert is NOT yet
&quot;in play&quot; and thus for NR purposes, signatures that are
created while the cert is on hold are not reliable.&nbsp; But, the
same effect could have been achieved by distributing a smart card with
a key pair and a cert template, and have the cert really issued as a
side effect of the user executing some POP protocol.&nbsp; It sounds
like some CAs decided that use of hold was an easy way to address a
valid concern in a way that makes life easy for them, but harder for
all RPs.&nbsp;</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">I will disagree with Russ and Stefan on
this one.&nbsp; While we ought not create standards that
disenfranchise legitimate uses of the technology, we also have no
obligation to condone practices that externalize costs, i.e., create
undue burdens on some parties to make life easier for
others.</font></div>
<div><font color=3D"#000000"><br></font></div>
<div><font color=3D"#000000">Steve</font></div>
<div><br></div>
<div><br></div>
</body>
</html>
--============_-1047380910==_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 kASFEQcu087112; Tue, 28 Nov 2006 08:14:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASFEQrN087111; Tue, 28 Nov 2006 08:14:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASFEK8j087098 for <[e-mail]>; Tue, 28 Nov 2006 08:14:21 -0700 (MST) (envelope-from [e-mail])
Received: from [130.192.1.59] ([130.192.1.59]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.4) with ESMTP id kASFEEjQ027733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 28 Nov 2006 10:14:19 -0500
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 16:13:38 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040905010707030005010506"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040905010707030005010506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:
> 2) RFC3280bis will never be perfect. We will never stop finding things that we may want
> to change or update. It's time to draw the line and let this document proceed. Let's
> focus on fixing errors if we find them but avoid "improvements" as much as possible.
> It's time to ship an update of RFC 3280.
> 
> In time there will be an rfc3280bisbis

I agree with this vision. Unfortunately it seems that the rfc3280 is probably one
of those documents which requires periodic updates, and this does not map well into
IETF RFCs.

I personally think, anyway, that a specific text should be added in this case to
the RFC, in particular we should at least make it clear that:

<< The `on hold' status does not affect later verification of legitimacy of
certificate usage in case the certificate is later removed from CRLs. Therefore
the `on hold' status does not provide a reliable way of suspending the usage of
a certificate in a specific period of time. >>

Providing also an explicit reference to the card/token suspension example as being
a bad interpretation/practice that should be avoided could also help (and as it is
quite a common practice, it is useful to explicitly state that it should be avoided
because it *does not* prevent the certificate to be used!).

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept
PKI/Trust
--o------------------------------------------------------------------------

--------------ms040905010707030005010506
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI4MTUxMzM4WjAjBgkqhkiG9w0B
CQQxFgQUOJAr1lKM6WeTLn9oyLgcc8armAUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYBAcl0+AFuwT2H1TDO6qM/c
uTh0NxXs/ByEBHgK+yW/zPexUSp5bwHO6Z2yDJl+8tojb9tRIlRckh3Js6ML7NrSg/2BYYqu
w8NwGl2Knjwr1thzGz9uXrJKaFr9TnX9sxOLiAWGBlD8Ajyr/I7cSsUOtnzQFR+PVurFcyD5
FdZ0igAAAAAAAA==
--------------ms040905010707030005010506--



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 kASEYiBh081470; Tue, 28 Nov 2006 07:34:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASEYi5q081469; Tue, 28 Nov 2006 07:34:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASEYg6A081463 for <[e-mail]>; Tue, 28 Nov 2006 07:34:43 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id m18so2241895nfc for <[e-mail]>; Tue, 28 Nov 2006 06:34:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Gy8pTjapPelNdMUnXR/iLZenY1ajDY4PtiVDKTbZysSF8lKVCvQ1RXJTCNuaiatgzonCmLgfKAgyTBWko9n2n6J7SnNflBwy1MHojQ37bdnn9aZt0bIixhJvmLRR+kDMxYj0boSIysTlM7X5dLcNvy93wVRTFgIuOqYDnAXM3Xc=
Received: by 10.48.254.10 with SMTP id b10mr12523469nfi.1164724478462; Tue, 28 Nov 2006 06:34:38 -0800 (PST)
Received: by 10.48.223.9 with HTTP; Tue, 28 Nov 2006 06:34:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 15:34:38 +0100
From: "=?UTF-8?Q?Carlos_Gonz=C3=A1lez-Cadenas?=" <[e-mail]>
To: "Dr Stephen Henson" <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_8774_10581603.1164724478194"
References: <[e-mail]> <[e-mail]> <[e-mail]> <016a01c712de$e39ee6f0$5d85900a@wcwang> <[e-mail]>
X-Google-Sender-Auth: 91fc0afb191a12b2
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_8774_10581603.1164724478194
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In my opinion the on-hold status makes sense in many concrete cases all of
you have been discussing before. Many CAs (I speak for what I've seen here
in Spain) also support certificate suspension, and that's included in their
CPSs.

It is technically possible to determine with a precision near to zero when a
signature was created (as you said in some emails there's plenty of
published material about that matter), so it's necessary to know the status
of the certificate in a point of time.

The problem now is that

1) we don't have a common view about what "on-hold" means (in this mail
thread some people argue that the key should not be used during the on-hold
period and other people argue that the key may be used).

2) it's not clear how to bring certificate suspension into the practice

Regarding 2) I see that a common practice about how to  do certificate
suspension described in 3280bis would be very helpful. In my opinion there
should be three supported cases

a) a certificate suspended (on-hold) that is finally revoked, that means
that the CA first revoke the certificate in instant t1 with the on-hold
cause, and after doing some investigations or whatever finally revokes the
certificate in instant t2 with another cause different from on-hold (i.e.
key compromise, ...) (note that it will be very useful to include an
invalidity date extension pointing to t1 or to the time it's known the
certificate should be considered as invalid).

   - Relying parties validating the certificate between t1 and t2 will
   see the certificate on-hold (I see here that using the hold instruction code
   can make happy people with different interpretations for what means on-hold,
   that is, the CA can inform with the hold instruction that the certificate is
   to be rejected, possibly solving the problems found in 1) )
   - Relying parties validating the certificate after t2 will see the
   certificate revoked (everything should work as usual)


b) a certificate suspended (on-hold) that is finally determined valid, that
means that the CA first revoke the certificate in instant t3 with the
on-hold cause, and after doing some investigations or whatever finally
determines that the certificate should keep valid, therefore including a
removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the
information regarding this certificate in the full CRL issued in t5


   - Relying parties validating the certificate between t3 and t4 will
   see the certificate on-hold (I see here that using the hold instruction code
   can make happy people with different interpretations for what means on-hold,
   that is, the CA can inform with the hold instruction that the certificate is
   to be rejected, possibly solving the problems found in 1))
   - Relying parties validating the certificate after t4 should determine
   that the certificate is valid (and in this case the information that the
   certificate was on hold it's not longer needed as you said).


I don't know if I'm missing something important, but as an implementer I
always felt that some text that clarified how to deal with suspension was
missing: I guessed and interpreted how to do it. I think we have a gold
opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take
many years).

I offer myself to help in what you consider is the best solution (producing
text for 3280bis, creating informative material, ....).

Opinions?

Best regards,

Carlos

On 11/28/06, Dr Stephen Henson <[e-mail]> wrote:
>
>
> Wen-Cheng Wang wrote:
> >
> >
> > You may argue that no matter how close between the time in the
> time-stamp
> > and the signing time claimed by the signer, risk still exists. If so,
> > you should
> > consider add a "content time-stamp" in addition to the "signature
> > time-stamp".
>
> Yes I'd argue that. In some cases (S/MIME signing time attribute for
> example) an attacker could generate a message with an arbitrary signing
> time. In this case they could claim some time in the future after the
> hold status is expected to be lifted.
>
> > The signing sequence will be as the following:
> >    Step 1. Get a trusted time-stamp of the message content
> >    Step 2. Sign the message
> >    Step 3. Get a trusted time-stamp of the signature
> > Since the message must be signed between the time of the content
> time-stamp
> > was generated and the time of the signature time-stamp was generated,
> the
> > verifier can certainly be aware of the period in which the message is
> > signed.
> >
> > Therefore, it is actually possible to reliably determine the time (in
> > the regard of
> > the agreed signature policy) or the "period" the signature was made.
> >
>
> Yes that would work assuming that "message" in Step 2, is the message
> content with time stamp. Signing the content time stamp would have the
> same result.
>
> IMHO if we are not going to deprecate the on-hold status we at least
> need some text to indicate the issues involved.
>
> 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: [e-mail], PGP key: via homepage.
>
>

------=_Part_8774_10581603.1164724478194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In my opinion the on-hold status makes sense in many concrete cases all of you have been discussing before. Many CAs (I speak for what I've seen here in Spain) also support certificate suspension, and that's included in their CPSs. 
<br><br>It is technically possible to determine with a precision near to zero when a signature was created (as you said in some emails there's plenty of published material about that matter), so it's necessary to know the status of the certificate in a point of time.
<br><br>The problem now is that <br><br>1) we don't have a common view about what &quot;on-hold&quot; means (in this mail thread some people argue that the key should not be used during the on-hold period and other people argue that the key may be used). 
<br><br>2) it's not clear how to bring certificate suspension into the practice<br><br>Regarding 2) I see that a common practice about how to&nbsp; do certificate suspension described in 3280bis would be very helpful. In my opinion there should be three supported cases
<br><br>a) a certificate suspended (on-hold) that is finally revoked, that means that the CA first revoke the certificate in instant t1 with the on-hold cause, and after doing some investigations or whatever finally revokes the certificate in instant t2 with another cause different from on-hold (
i.e. key compromise, ...) (note that it will be very useful to include an invalidity date extension pointing to t1 or to the time it's known the certificate should be considered as invalid). <br><ul><li>Relying parties validating the certificate between t1 and t2 will see the certificate on-hold (I see here that using the hold instruction code can make happy people with different interpretations for what means on-hold, that is, the CA can inform with the hold instruction that the certificate is to be rejected, possibly solving the problems found in 1) )
</li><li>Relying parties validating the certificate after t2 will see the certificate revoked (everything should work as usual)</li></ul><br>b) a certificate suspended (on-hold) that is finally determined valid, that means that the CA first revoke the certificate in instant t3 with the on-hold cause, and after doing some investigations or whatever finally determines that the certificate should keep valid, therefore including a removeFromCRL in t4 (if the CA is issuing deltas) and eliminating all the information regarding this certificate in the full CRL issued in t5
<br><br><ul><li>Relying parties validating the certificate between t3 and t4 will see the certificate on-hold (I see here that using the hold
instruction code can make happy people with different interpretations
for what means on-hold, that is, the CA can inform with the hold
instruction that the certificate is to be rejected, possibly solving the problems found in 1))</li><li>Relying parties validating the certificate after t4 should determine that the certificate is valid (and in this case the information that the certificate was on hold it's not longer needed as you said).
<br></li></ul><br>I don't know if I'm missing something important, but as an implementer I always felt that some text that clarified how to deal with suspension was missing: I guessed and interpreted how to do it. I think we have a gold opportunity now to fix this issue in 3280bis (possibly 3280bisbis will take many years).
<br><br>I offer myself to help in what you consider is the best solution (producing text for  3280bis, creating informative material, ....).<br><br>Opinions?<br><br>Best regards,<br><br>Carlos<br><br><div><span class="gmail_quote">
On 11/28/06, <b class="gmail_sendername">Dr Stephen Henson</b> &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Wen-Cheng Wang wrote:<br>&gt;<br>&gt;<br>&gt; You may argue that no matter how close between the time in the time-stamp<br>&gt; and the signing time claimed by the signer, risk still exists. If so,<br>&gt; you should<br>
&gt; consider add a &quot;content time-stamp&quot; in addition to the &quot;signature<br>&gt; time-stamp&quot;.<br><br>Yes I'd argue that. In some cases (S/MIME signing time attribute for<br>example) an attacker could generate a message with an arbitrary signing
<br>time. In this case they could claim some time in the future after the<br>hold status is expected to be lifted.<br><br>&gt; The signing sequence will be as the following:<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 1. Get a trusted time-stamp of the message content
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 2. Sign the message<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Step 3. Get a trusted time-stamp of the signature<br>&gt; Since the message must be signed between the time of the content time-stamp<br>&gt; was generated and the time of the signature time-stamp was generated, the
<br>&gt; verifier can certainly be aware of the period in which the message is<br>&gt; signed.<br>&gt;<br>&gt; Therefore, it is actually possible to reliably determine the time (in<br>&gt; the regard of<br>&gt; the agreed signature policy) or the &quot;period&quot; the signature was made.
<br>&gt;<br><br>Yes that would work assuming that &quot;message&quot; in Step 2, is the message<br>content with time stamp. Signing the content time stamp would have the<br>same result.<br><br>IMHO if we are not going to deprecate the on-hold status we at least
<br>need some text to indicate the issues involved.<br><br>Steve.<br>--<br>Dr Stephen N. Henson.<br>Core developer of the&nbsp;&nbsp; OpenSSL project: <a href="http://www.openssl.org/">http://www.openssl.org/</a><br>Freelance consultant see: 
<a href="http://www.drh-consultancy.co.uk/">http://www.drh-consultancy.co.uk/</a><br>Email: <a href="mailto:[e-mail]">[e-mail]</a>, PGP key: via homepage.<br><br></blockquote></div>
<br>

------=_Part_8774_10581603.1164724478194--



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 kASC5ssq062508; Tue, 28 Nov 2006 05:05:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASC5s3j062507; Tue, 28 Nov 2006 05:05:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASC5q88062499 for <[e-mail]>; Tue, 28 Nov 2006 05:05:53 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1Gp1iA-0006Do-4C for [e-mail]; Tue, 28 Nov 2006 12:05:26 +0000
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 12:05:19 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]> <016a01c712de$e39ee6f0$5d85900a@wcwang>
In-Reply-To: <016a01c712de$e39ee6f0$5d85900a@wcwang>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang wrote:
> 
> 
> You may argue that no matter how close between the time in the time-stamp
> and the signing time claimed by the signer, risk still exists. If so,
> you should
> consider add a "content time-stamp" in addition to the "signature
> time-stamp".

Yes I'd argue that. In some cases (S/MIME signing time attribute for
example) an attacker could generate a message with an arbitrary signing
time. In this case they could claim some time in the future after the
hold status is expected to be lifted.

> The signing sequence will be as the following:
>    Step 1. Get a trusted time-stamp of the message content
>    Step 2. Sign the message
>    Step 3. Get a trusted time-stamp of the signature
> Since the message must be signed between the time of the content time-stamp
> was generated and the time of the signature time-stamp was generated, the
> verifier can certainly be aware of the period in which the message is
> signed.
> 
> Therefore, it is actually possible to reliably determine the time (in
> the regard of
> the agreed signature policy) or the "period" the signature was made.
> 

Yes that would work assuming that "message" in Step 2, is the message
content with time stamp. Signing the content time stamp would have the
same result.

IMHO if we are not going to deprecate the on-hold status we at least
need some text to indicate the issues involved.

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: [e-mail], 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 kASBdkk7059970; Tue, 28 Nov 2006 04:39:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASBdkHF059969; Tue, 28 Nov 2006 04:39:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay1.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASBdij9059935 for <[e-mail]>; Tue, 28 Nov 2006 04:39:45 -0700 (MST) (envelope-from [e-mail])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.13.8/8.13.8) with ESMTP id kASBdXi3012681 for <[e-mail]>; Tue, 28 Nov 2006 12:39:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id F3B74194003 for <[e-mail]>; Tue, 28 Nov 2006 12:39:32 +0100 (CET)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12136-02 for <[e-mail]>; Tue, 28 Nov 2006 12:39:32 +0100 (CET)
Received: from NOTEBOOKLIPP (notebooklipp.iaik.tugraz.at [129.27.152.54]) by thor.iaik.tugraz.at (Postfix) with ESMTP id E158A194002 for <[e-mail]>; Tue, 28 Nov 2006 12:39:32 +0100 (CET)
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Subject: AW: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 12:39:15 +0100
Message-ID: <00a201c712e1$d5522320$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AccShtMaAEjV2UF6QdqoGxpra124aAAWX6Tw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <[e-mail]>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Spam-Scanner: SpamAssassin 3.001007 
X-Spam-Score-relay: -0.7
X-Scanned-By: MIMEDefang 2.58 on 129.27.10.18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> If people are really using it, then we should not pull the 
> rug out from under them.  I do not think this is a great 
> mechanism for the situation that is described, but there are 
> far worse uses that have been discussed.

That's an understandable position. But probably it would be or have been
worthwhile to differentiate between the different uses; currently the number
of interpretations what to use that mechanism for is simply to
heterogeneous, some of them are problematic. We have seen mentioned now:

- on hold for the time of transport of the id card
- on hold for suspected compromise where the info came from unauthenticated
sources
I have heared from ideas to use on hold for a time where e.g. I am not in my
office and cant use the certificate on my office machine (like vacation or
even the weekend). (Don't know if this idea has been implemented though.
Hope not.)
There may be other ideas/uses of that concept. 

Santosh mentioned that "on hold is not overly complex". I agree, the basic
idea isn't. But the different interpretations existing make it maybe not
complex but incompatible or meaningless. What does the "on hold" for
transport buy me? As soon as it is no longer on hold and the firt CRL
without that information issued, this fact is forgotten. What if I now had a
signature created during that time... (If I assume I will never find such a
signature, why place the cert on hold?) 

If this stays in, the usage should be restricted to the working scenarious
only and any legislation prescribing other uses should be fixed.

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 kASBIME4058157; Tue, 28 Nov 2006 04:18:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASBIM8n058156; Tue, 28 Nov 2006 04:18:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth0.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASBIJKo058145 for <[e-mail]>; Tue, 28 Nov 2006 04:18:20 -0700 (MST) (envelope-from [e-mail])
Received: from auth0.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 799682CC307; Tue, 28 Nov 2006 19:18:13 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth0.cht.com.tw (Postfix) with SMTP id 399D42CC2F6; Tue, 28 Nov 2006 19:18:13 +0800 (CST)
Message-ID: <016a01c712de$e39ee6f0$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Dr Stephen Henson" <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 19:18:06 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dr Stephen Henson wrote:
> 
> David A. Cooper wrote:
>> 
>> Other people believe that placing a certificate on hold also places use
>> of the private key on hold and so any signatures generated during the
>> time that the certificate was on hold are not legitimate.  Thus, these
>> people believe that when verifying a signature it is important to know
>> whether the certificate was on hold at the time that the signature was
>> generated, even if the certificate is later removed from hold.  The
>> information included in CRLs issued after the certificate is removed
>> from hold do not include any information that would help to determine
>> whether the certificate was on hold at some point in the past.
>> 
> 
> That's the case I'm uneasy about which I suspect is the case the two
> examples I've seen are intended to cover.
> 
> It should be noted that this assumes that there is a way to reliably
> determine when the signature was made.
> 
> This is not always possible and often one can only say it was made *on
> or before* a certain time (for example the time in a trusted timestamp).
> 
> That doesn't help because the signature might be made during the hold
> period and the timestamp added some time afterwards.
> 
In the area of "Advanced Electronic Signatures" (or so-called long term
electronic signatures by the S/MIME WG), this is called "time-stamp delay".

In section B.8.4 of RFC 3125, it informatively describe requirement of
signature policy related to "time-stamp delay" as follows:

   There will be some delay between the time that a signature is created
   and the time the signer's digital signature is time-stamped.
   However, the longer this elapsed period the greater the risk of the
   signature being invalidated due to compromise or deliberate
   revocation of its private signing key by the signer.  Thus the
   signature policy should specify a maximum acceptable delay between
   the signing time as claimed by the signer and the time included
   within the time-stamp.

And in section 3.8 of RFC 3125, the signatureTimestampDelay field is
defined as follows to allow a signature policy Issuer to specify  the
acceptable "time-stamp delay":
  The signatureTimestampDelay field specifies a maximum acceptable time
   between the signing time and the time at which the signature time-
   stamp, as used to form the ES Time-Stamped, is created for the
   verifier.  If the signature time-stamp is later that the time in the
   signing-time attribute by more than the value given in
   signatureTimestampDelay, the signature must be considered invalid.

The implication is that with the help of a trusted time-stamp close enough
to the signing-time (in the signed attribute) claimed by the signer, the verifier
can assume, in the regard of the agreed signature policy, the message
was really signed at that time.

You may argue that no matter how close between the time in the time-stamp
and the signing time claimed by the signer, risk still exists. If so, you should
consider add a "content time-stamp" in addition to the "signature time-stamp".
The signing sequence will be as the following:
    Step 1. Get a trusted time-stamp of the message content
    Step 2. Sign the message
    Step 3. Get a trusted time-stamp of the signature
Since the message must be signed between the time of the content time-stamp
was generated and the time of the signature time-stamp was generated, the
verifier can certainly be aware of the period in which the message is signed.

Therefore, it is actually possible to reliably determine the time (in the regard of
the agreed signature policy) or the "period" the signature was made.

I am one of the people who believe that placing a certificate on hold also
places use of the private key on hold and so any signature generated
during the time that the certificate was on hold are not legitimate. I also
agree the following Santosh's opinion:
   "As to determination of the certificate status, archiving all CRL (and deltas if
    deltas are produced) give the accurate picture of revocation status modulo
    CRL issuance frequency."

I am aware a case where the signatures generated during the time that the
certificate was on hold are not legitimate. The case is the government issues
X.509 certificates to companies and  by regulation if a company's license
is placed on hold (for example, due to illegal tax evasion) then the company's
X.509 will also be simultaneously placed on hold and the company's digital
signatures will be considered illegitimate until its company license is resumed
(and of course its X.509 certificate will be simultaneously resumed too).

To validate an archived signed data (with long-term signature and timestamps),
we will need a mechanism to validate the signing certificate relative to past
time or period. Currently, the SCVP draft intend to support validate a certificate
relative to past time. (Personally, I think SCVP should also support validate
a certificate relative to past "period".) However, it is unfortunately that the
certificate validation algorithm of RFC 3280 and RFC 3280bis only support
validate a certificate at the "current time". We still lack a standard algorithm to
validate a certificate relative to past time or period.

Wen-Cheng Wang



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 kASAgSgU054881; Tue, 28 Nov 2006 03:42:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASAgSsE054880; Tue, 28 Nov 2006 03:42:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kASAgQ4Q054855 for <[e-mail]>; Tue, 28 Nov 2006 03:42:27 -0700 (MST) (envelope-from [e-mail])
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.20; Tue, 28 Nov 2006 10:42:20 +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; Tue, 28 Nov 2006 10:42:19 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 28 Nov 2006 10:42:18 +0000
Subject: RE: on-hold certificates in CRLs
Thread-Topic: on-hold certificates in CRLs
Thread-Index: AccSihxHTWv74gb+SPKdEFYuA6Nw1AATZUXA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kASAgR4Q054875
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

2 things.

1) Some examples of using on-hold seems a bit shaky. For example putting a certificate on-hold until card is delivered does not stop me from signing with the card and use that signature after its status has been restored. I concur that once status has been restored, there is no need to know if it has been on hold.

I'm personally not a big fan of "on hold", but we have a responsibility to not break users of this profile, so deprecating a feature puts great responsibilities on us to determine that we don't break legitimate implementations.

2) RFC3280bis will never be perfect. We will never stop finding things that we may want to change or update. It's time to draw the line and let this document proceed. Let's focus on fixing errors if we find them but avoid "improvements" as much as possible. It's time to ship an update of RFC 3280.

In time there will be an rfc3280bisbis


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 28 november 2006 00:51
> To: [e-mail]
> Subject: Re: on-hold certificates in CRLs
>
>
> Massimiliano:
>
> >>I have come across two real world examples of it being used in
> national
> >>ID schemes. In both of these a certificate is automatically placed
> "on
> >>hold" when the card is manufactured and then made valid when the
> >>recipient has performed some procedure to acknowledge receipt. I
> suspect
> >>that the two I saw are far from isolated examples.
> >
> >I do confirm that some big national CAs (at least in Italy) use the
> `on Hold'
> >status when the card is first "initialized" (and the certificate
> issued)
> >till the user receives the card.
>
> If people are really using it, then we should not pull the rug out
> from under them.  I do not think this is a great mechanism for the
> situation that is described, but there are far worse uses that have
> been discussed.
>
> 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 kASAVYgf053965; Tue, 28 Nov 2006 03:31:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kASAVYW3053964; Tue, 28 Nov 2006 03:31:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kASAVRIo053934 for <[e-mail]>; Tue, 28 Nov 2006 03:31:28 -0700 (MST) (envelope-from [e-mail])
Received: from IBM5E1D7F233E3 ([10.0.250.204]) by mail.nbusr.sk with esmtp; Tue, 28 Nov 2006 11:26:40 +0100 id 000114E1.456C0EE4.0000B2ED
From: "Peter Rybar" <[e-mail]>
To: "'pkix'" <[e-mail]>
Cc: "'Dr Stephen Henson'" <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 11:31:29 +0100
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAo5hlHtaY40maWMbI+cGFssKAAAAQAAAAZxC+/[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_mail.nbusr.sk-45805-1164709604-0001-2"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AccStSo3jC6psr/STziqSZ9e5RA6ZQACmeEg
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_mail.nbusr.sk-45805-1164709604-0001-2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Signed mail is in attachment.


--=_mail.nbusr.sk-45805-1164709604-0001-2
Content-Type: message/rfc822; name=" onHoldCertificatesInCRLs.eml"
Content-Disposition: attachment;
	filename=" onHoldCertificatesInCRLs.eml"

Message-ID: <28x11x2006at11x21x10x0DAE>
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Tue, 28 Nov 2006 11:21:10 +0100
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="=_mail.nbusr.sk-45805-1164709604-0001-3"
X-Mailer: ELPI

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_mail.nbusr.sk-45805-1164709604-0001-3
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

The status of certificateHold or removeFromCRL is useful only for strictly 
online system, where is no reason to check a history about revocation 
status information.

If certificate is several times in status on hold and removed from hold 
then the verification of qualified electronic signature with trusted 
timestamp is almost impossible. 

That is the reason why the Slovak Act no. 215/2002 Coll. on Electronic 
Signature (qualified certificate and qualified el. signature) does not 
allow removing the certificate from hold. 

Certificate in the CRL (OCSP) can not be found in revocation reason 
certificateHold or removeFromCRL, thus its validity can not be stopped for 
certain period.

IMHO useful recommendation in this RFC: 
"The certificateHold or removeFromCRL status MUST NOT be used by CA except 
CA for strictly On-Line system".

Peter

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On 
Behalf Of Dr Stephen Henson
Sent: Tuesday, November 28, 2006 2:32 AM
To: pkix
Subject: Re: on-hold certificates in CRLs


David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

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: [e-mail], PGP key: via homepage.


--=_mail.nbusr.sk-45805-1164709604-0001-3
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIIM1QYJKoZIhvcNAQcCoIIMxjCCDMICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCCkQw
ggZnMIIFT6ADAgECAgIMEDANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJTSzETMBEGA1UEBwwK
QnJhdGlzbGF2YTEiMCAGA1UECgwZTmFyb2RueSBiZXpwZWNub3N0bnkgdXJhZDEOMAwGA1UECwwF
U0lCRVAxDTALBgNVBAMMBFNOQ0EwHhcNMDYxMTIxMTUyMTE2WhcNMDcxMTIxMTUyMTE2WjBsMQsw
CQYDVQQGEwJTSzETMBEGA1UEBwwKQnJhdGlzbGF2YTEiMCAGA1UECgwZTmFyb2RueSBiZXpwZWNu
b3N0bnkgdXJhZDEOMAwGA1UECwwFU0lCRVAxFDASBgNVBAMMC1BldGVyIFJ5YmFyMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAijI9giVdMdvNWYuijIJWDfXeD1o/g0+IQWJ+J1amiNiP
y9gHZe4yPMPoRhU89gDIqGdDHs0dvzLbK+wzvGMtUE4cdmbniMVoWIft4d9GJrwhdr+RM1QPvkWC
ko1BMR2og47x61cqX1Pa+f46KM3+Jc7j+r0NDp7aBsaTzA3P/70R9wiiiG1vMzirdW/C5RkTuyug
+hFYzkpAcZuuW96Sbyvn5r7yV8ecWrAYqILXAlXRa2F9K8HV/AZircK7JGOxzkglS1n3Z7AZTxuf
24J8R+mywUslA3ZsMQvlxk1SPN269YfrJ21t3+QpLSPLjJCfm+zOwWI/Qe8XLwoxzaOoHQIDAQAB
o4IDGDCCAxQwCQYDVR0TBAIwADAvBgNVHREEKDAmgQ5yeWJhckBuYnVzci5za4YUaHR0cDovL3d3
dy5uYnVzci5zay8wggEkBggrBgEFBQcBAQSCARYwggESMDMGCCsGAQUFBzAChidodHRwOi8vZXAu
bmJ1c3Iuc2svc25jYS9jZXJ0cy9zbmNhMS5wN2MwcgYIKwYBBQUHMAKGZmxkYXA6Ly9lcC5uYnVz
ci5zay9jbj1TTkNBLG91PVNJQkVQLG89TmFyb2RueSBiZXpwZWNub3N0bnkgdXJhZCxsPUJyYXRp
c2xhdmEsYz1TSz9jYUNlcnRpZmljYXRlO2JpbmFyeTBnBggrBgEFBQcwAoZbbGRhcDovLy9jbj1T
TkNBLG91PVNJQkVQLG89TmFyb2RueSBiZXpwZWNub3N0bnkgdXJhZCxsPUJyYXRpc2xhdmEsYz1T
Sz9jYUNlcnRpZmljYXRlO2JpbmFyeTATBgNVHSAEDDAKMAgGBgQAj3oBAjAOBgNVHQ8BAf8EBAMC
B4AwEwYDVR0lBAwwCgYIKwYBBQUHAwQwHwYDVR0jBBgwFoAUOLPZAKX2gblLDZsq201lZ7GlG8ww
ggEyBgNVHR8EggEpMIIBJTAsoCqgKIYmaHR0cDovL2VwLm5idXNyLnNrL3NuY2EvY3Jscy9zbmNh
MS5jcmwwf6B9oHuGeWxkYXA6Ly9lcC5uYnVzci5zay9jbiUzZFNOQ0Esb3UlM2RTSUJFUCxvJTNk
TmFyb2RueSUyMGJlenBlY25vc3RueSUyMHVyYWQsbCUzZEJyYXRpc2xhdmEsYyUzZFNLP2NlcnRp
ZmljYXRlUmV2b2NhdGlvbkxpc3QwdKByoHCGbmxkYXA6Ly8vY24lM2RTTkNBLG91JTNkU0lCRVAs
byUzZE5hcm9kbnklMjBiZXpwZWNub3N0bnklMjB1cmFkLGwlM2RCcmF0aXNsYXZhLGMlM2RTSz9j
ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0MB0GA1UdDgQWBBQ4lCP+K34syFse49QZh8ZUapO8sDAN
BgkqhkiG9w0BAQUFAAOCAQEAo2QAzOXtSiBe1K3Z40l2Uz4ijetestNTtvvyWCFKZoxBvGrSWKwd
agnyDBpSjmcVa/BPq5ipyIWkGR8XBi3xRZP8epfTHXXzPuDaXD1QAkxoe60725JrYtxlZFCY+GtV
JUvs1mxJjnoKuMKOLkMdUj83qMzG/tAD/FWHpGWCaI5GS3DB+9Bm2Db8sjS1Ismvgpj1MVWSWIr8
LlS9hlmyWK6m5gVN83szOd62xdaWXl/53CUilb5W0iS1aV73C+aMdeStl7DWdRIXEThhd0J7/tBr
Eb2Rxvwtdt04GijQdRG6yojZ8WbvRDTEn9U6FzFQquPndJp1L1GVliISDZQ9azCCA9UwggK9oAMC
AQICAQEwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCU0sxEzARBgNVBAcMCkJyYXRpc2xhdmEx
IjAgBgNVBAoMGU5hcm9kbnkgYmV6cGVjbm9zdG55IHVyYWQxDjAMBgNVBAsMBVNJQkVQMQ0wCwYD
VQQDDARTTkNBMB4XDTA2MDQzMDA4NDEyOFoXDTE2MDQzMDA4Mjc1OFowZTELMAkGA1UEBhMCU0sx
EzARBgNVBAcMCkJyYXRpc2xhdmExIjAgBgNVBAoMGU5hcm9kbnkgYmV6cGVjbm9zdG55IHVyYWQx
DjAMBgNVBAsMBVNJQkVQMQ0wCwYDVQQDDARTTkNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAstRsWtSGa+W6KE+HTffiIHhfAugP+uPv7yoJzEp0CjZOtZXB/FkjNoXma19vKYSaP9EI
7TAuFzuWI+hnaMRoeITU0qpWN0cPrRzhiLU5XbbBIjAIutsNu79TKo6tSObQEtsCqfnfquTpAaPd
OeIMxcCg7DZck5msMUsJGHEx/3TeWCNU+6ZKw1c6vjgM3BzmOVzl7OjqhjqaNFA3xjiXXSNKO5RA
0AGMXYOUY+HlNJjOqVdWoyXWznEI+6U3TYLqxmhYpO/E9AA79IQczY0H/qZoj8RR0GWVUOPdOA5g
LOKVKlB68BF9hmYQ5HiQNiwGDA2CY/ogIQOh8AZQMSzKhwIDAQABo4GPMIGMMA8GA1UdEwEB/wQF
MAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9lcC5uYnVz
ci5zay9zbmNhL2NybHMvc25jYTEuY3JsMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUOLPZAKX2
gblLDZsq201lZ7GlG8wwDQYJKoZIhvcNAQEFBQADggEBADRJxn516YeCYlvqTRQ4s9UA7bDh6kHS
baG+FTBVxO5r7NMFmsIQmMIlUxuZPFz8yzqGdCGLIIklnqc4EWeqwTTWAIQO5A/V2Ca0MlgZZxy/
XQdSTnWLUw6Ooz3GirqcQTrnqq3MsMXN6KdZhIs4RXf0yg91VpM9Y2cqc8Iixq8GIpSlo6kLayQe
uUm1voUiMZ+vzMIuvfcOXc0+3bJM2gbX1GuEBoFhMnl7Lrjg/1fuib6KppFbExWnpTj62Uf1qV4Y
k/5tJ04aUze7BnohKV/0dcB4fXDmScL9GcHltIV0O1PQ75vK2bLW3OJmpI3DX40Ncu5Y0rKwXbDB
WPLmXj4xggJZMIICVQIBATBrMGUxCzAJBgNVBAYTAlNLMRMwEQYDVQQHDApCcmF0aXNsYXZhMSIw
IAYDVQQKDBlOYXJvZG55IGJlenBlY25vc3RueSB1cmFkMQ4wDAYDVQQLDAVTSUJFUDENMAsGA1UE
AwwEU05DQQICDBAwCQYFKw4DAhoFAKCBxDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0wNjExMjgxMDIxMTBaMCMGCSqGSIb3DQEJBDEWBBQ8FqTtxd31fFjEa8sUjB0s
sXcIUzBlBgkqhkiG9w0BCQ8xWDBWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAPBgkqhkiG9n0H
QgoCAgCAMA0GCysGAQQBgTwHAQECMA4GCCqGSIb3DQMCAgIAgDALBglghkgBZQIBAQQwDQYJKoZI
hvcNAQEBBQAEggEAVntDnX9Tri/+M0wfohiz3AO7iM0O1wAsZ7100nFXSgQ1C/jGHK4kyW3GV/78
BURAo3V3RO0RqGEgyQdab6e2bpHzhXBBNLUkmfm0vz89NItV5sTgTeATsQyo+WZhLkBbMo2kAVIo
AtOHgb+nqY7UWtKf4hjGijheE/CMDCczZ2c59lUa06i2BtTsEGTE0ap+628YZx7ZvZ1F3zQk8NK+
7vb1YOtGCnjiqBvy0NaiYTlFU/uuMCRmrcfXQsaSXcvjzNxtkxuOyP65qMJmltdL+/Szbu59w1R2
bJ+3i6O70NXcdiLGbpr+wtlkrWyGijaOdQpAz2yOXfQTSpwouQl3qQ==

--=_mail.nbusr.sk-45805-1164709604-0001-3--

--=_mail.nbusr.sk-45805-1164709604-0001-2--



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 kAS9xVl7049938; Tue, 28 Nov 2006 02:59:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAS9xVlr049937; Tue, 28 Nov 2006 02:59:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAS9xTnr049921 for <[e-mail]>; Tue, 28 Nov 2006 02:59:30 -0700 (MST) (envelope-from [e-mail])
Received: by postman.ripe.net (Postfix, from userid 4008) id 1063B23FB9; Tue, 28 Nov 2006 10:59:22 +0100 (CET)
Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id DC5FF23FD3 for <[e-mail]>; Tue, 28 Nov 2006 10:59:16 +0100 (CET)
Received: from [IPv6???1] (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id D860A2F594 for <[e-mail]>; Tue, 28 Nov 2006 10:59:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 10:59:16 +0100
From: =?ISO-8859-1?Q?R=F3bert_Kisteleki?= <[e-mail]>
Organization: RIPE NCC
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: 
X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00
X-RIPE-Spam-Status: N 0.180305 / -4.4
X-RIPE-Signature: 910a621c71186ef4ec5a32d9feaeb68f
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> Massimiliano:
> 
>>> I have come across two real world examples of it being used in national
>>> ID schemes. In both of these a certificate is automatically placed "on
>>> hold" when the card is manufactured and then made valid when the
>>> recipient has performed some procedure to acknowledge receipt. I suspect
>>> that the two I saw are far from isolated examples.
>>
>> I do confirm that some big national CAs (at least in Italy) use the 
>> `on Hold'
>> status when the card is first "initialized" (and the certificate issued)
>> till the user receives the card.
> 
> If people are really using it, then we should not pull the rug out from 
> under them.  I do not think this is a great mechanism for the situation 
> that is described, but there are far worse uses that have been discussed.
> 
> Russ

I have to agree with Massimiliano, in some countries the legislation (!) 
enables/forces the national CAs to use the on hold status. Besides this, 
whole business processes have been built upon this feature.

I'm not saying that on hold is a good/bad feature, merely that it is being 
used, and even if you deprecate it, it will take years to root it out from 
practice.

Robert



Received: from [64.65.181.251] ([64.65.181.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAS9VGPP046023 for <[e-mail]>; Tue, 28 Nov 2006 02:31:16 -0700 (MST) (envelope-from [e-mail])
Received: from cwXWQc ([143.126.147.2]) by knxblm with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 01:33:31 -0800
Message-ID: <000c01c712d0$31a51b30$00000000@Alan>
From: "specific" <[e-mail]>
To: [e-mail]
Subject: Man
Date: 	Tue, 28 Nov 2006 01:32:59 -0800
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C7128D.237F6A30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437

------=_NextPart_000_0008_01C7128D.237F6A30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C7128D.237F6A30"


------=_NextPart_001_0009_01C7128D.237F6A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Bandwidth captured analyzed realtime, offers, standard, ipoques comprise =
sizes. Project fundmain main st po box ma ph fax.
Heshe computers running authorizes installed, needed connected server.
Open arguing because talks, opponent? Mpcom settling few opens.
Satisfy negotiate conditions outcome neither nor.
Effected, execution payment invoice thereafter?
Level represent households attached diagram optimized, large. Searches =
top page shortcuts!
Near, futurethis short excerpt extended. Tradeshow higher, options =
singleuser licensing assigned individual install.
Internet network kazaa on?
Titles, copy reserved ad feedback license info sketchup. Css bmi cue =
heets either religious access government system.
Expressed, prior interest receiving, research. Subdomains host link url =
document index indexed.
Perform combined background element licensees cable. Implied limitation, =
warranties fitness purpose exclusion vary. Purposes more go wish your =
own beyond. Amp textbooks rare feature areas?
Pay like recently opened pressplay. Points seats purchased determines =
concurrent seat cost per single.
------=_NextPart_001_0009_01C7128D.237F6A30
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.2800.1437" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"ZapBax" hspace=3D0=20
src=3D"cid:000701c712d0$31a2aa30$00000000@Alan" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bandwidth captured analyzed realtime, =
offers,=20
standard, ipoques comprise sizes. Project fundmain main st po box ma ph =
fax.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Heshe computers running authorizes =
installed,=20
needed connected server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Open arguing because talks, opponent? =
Mpcom=20
settling few opens.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Satisfy negotiate conditions outcome =
neither nor.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Effected, execution payment invoice =
thereafter?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Level represent households attached =
diagram=20
optimized, large. Searches top page shortcuts!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Near, futurethis short excerpt =
extended. Tradeshow=20
higher, options singleuser licensing assigned individual =
install.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Internet network kazaa on?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Titles, copy reserved ad feedback =
license info=20
sketchup. Css bmi cue heets either religious access government =
system.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Expressed, prior interest receiving, =
research.=20
Subdomains host link url document index indexed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Perform combined background element =
licensees=20
cable. Implied limitation, warranties fitness purpose exclusion vary. =
Purposes=20
more go wish your own beyond. Amp textbooks rare feature =
areas?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pay like recently opened pressplay. =
Points seats=20
purchased determines concurrent seat cost per =
single.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C7128D.237F6A30--

------=_NextPart_000_0008_01C7128D.237F6A30
Content-Type: image/gif;
	name="return.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c712d0$31a2aa30$00000000@Alan>

R0lGODlhgAHkAIcJAAAHAYwNBAyCAH+BCgAOeHoAdwB+h7m7srHYtLTG4zgiAGEcAH8TBaouALwb
ANYRAAc/AChIAD85AF5IAIMxAKI7AMs9Cu5DAAVsCBZjAD5kA19oDXteBaJXDbpeANtfAAB/ACV8
AD6CAll5AHZxCJ6MALWAAOp6DQ6rCi2TAE6uDmaeAI6eCKOtB7SRDdifAAbAByK2AEfLAF+3AHe9
DK69ArXHANK1CADSABfTCkDTCWbmAIXbAJfZAMnhAODjAAMGRysAOU0AQ1cKTokKNagISb0IOucG
PA0hRiwhQ0wWOWIuR4EUP6crQrwrPdoVRAA+PClOMjs3S1dDR4YzTKVLPsI6PNRNRABpQSdTO0FS
QlFWN3ZcEKxpTsxoOdxVNgV+QRZ9PDxxTm6GQHV2S5d8SsOHSd54OQanQSelMUGYRWGuQ4GlSKGc
O86dStWuPgCxQim7P02+TGm2SIHBPpvFPrLGOtnOPQjkMyfgQzXtMl/UQIrZQ5PrRrLRPOXiTQAJ
dRYFc0cAgmkAdn4AcasAcb4Gh9oFdwAcdC4odU4dglIpfXUfhZEhdsMeceskewA1iyw0gT4+iVJM
eHpId5JLfcVBieI8ewFehSNfiz9ee1xsfH9idadUecNmg95Vdw2NgB92jjZ1i2CHiXmEe5WMjLRx
i+CNggCtcxyadTKUfGSahHmpfqquh8eeiO2efgDJeR/Lc0jJgVrIgo7Nga3CdrO8iOu8ewPodxXb
hT3YglLYdIPkgqnki8nle+7niwMAsyIFwDINyGEAx34GuJ8AuLQNxNEAvAghzhwSvjMRv2wjy4Qk
vp4pu8wWvtMazQAysSczxTRHw2FDwIdEu51Ix7hFyOg9swBovSZoyz1ezWpZzINls6VSu8lXte5q
tA2FwS6GzkiAyWqOyI54xqaNyLyFuuSAuwCqtyWuyjWRuGKbwYOstKylx7utvt2ovQDOyivLx0a5
zVi2vXHIuJPCtv//5qiSr3d1jPEGBgH2A/f/AAAI//8B8QPy//3/9SH5BACJ04EALAAAAACAAeQA
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
GO3JnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXWoTptOnUKNKnbqRqdWrWLNq3cq1q9evRamK
HUu2rNmTYNOqXcu2rdu3bc/KnUu3rt27ePPq3asSrt+/gAMLHky4sOHDiBMrXsy4sePHkI3ynUy5
smWHkTNr3swZ7OXPoEOLHk26tGm0nVOrXs26J8MAAQrC/ge7dm3atmMPnC1b98HcAnMDF/7bNkHe
x33jNl4ceHDlz3EbRH66ulOesGtmz26Tuz3v3wPQ/wSvXbxM8ujNhx/vvfb59O/Vr+8unzv5+eDv
t96/v715/f6V915O+rEn4IAzwRdefv/JpxODCBqIYIH8VahYQ8jxRt1uvm2oIXTJLeRhhyQWJ12G
sW2oEHUfTleidNbFeB126tknnHgBlkdhhDcpON+PBm5XI44OPihcgkUyuKOFTBbm0Gwomgijixje
RmWIU2bJIYwtomhlb1iqOKKMZMLkk5BI9mgbgUUaSZ+OPgY55Hr3Aeggmgem2eSeq+EJpJ4FLvmm
hIDW16afCxI5aJ4D1nlnm3xGCpl7euZpZ1Bx/gihhEo2yGiljSb5qKSkakYpj6A6ulOOhPLo35Ce
sv/XoKFqErppq6nSWuqubJ2a6JqZCppbrbh2qmurR6o5rKy+gporrrxGS1SZ1FZr7bXYZqvtttx2
6+234IYr7rjklvuPtOimq+667LbrLk4CCEBTvPPKG++999pDb7364puvTfvy66+8PAU8sMH/yhSw
wgS/67CTC8U7EL4TC/CPxAdhfLHFGzekccUdC/QxQiMThPHJHJdcsrkss4QyyiJzbJDGMDOkssUf
rxyzzjSn7PPMMrcstEc97Ysvw0jDa2/DC+fUdL9Qz/R0TVNHHTW9U1f98NaIGf2v1wPX23C/YQM8
NtILa5001WN7bTW/XMe9GNYE0732TQm/7fTZUCP/XDDfeh9Nt99yFx6Xx/fuLLPOO5scdEI3b0yx
zY+HDHniITM+9OYiTT655UBbrjnIBUk8euilV+545j9z7npMRX+dcNWEqy0133YD1bTabutt+O+E
5T074Fb3/jfctpvNtk69Gw/881s9lHPQB+P8uOkHX/756RV7rjrpioP/+vgSQW/++einr/5q5Lfv
/vvwx1/V+vTXf5T8+Odv//78/5T//wAMoABb1r8CGrApA0yg0A7IwAY68IEQjKAE3aXACpprghgE
ngU3KK4MelBuHAyhtz5IwoeJ8ITaKqEK24XCFlprhTCMoQxnSMMa7s+FOMyhDnfIERv60EI8DKJo
/35IxNYI8Skf+MBDksgtJpLFJwCIYhQFk0SZVNEeVUyiFj9gxS1icYtcpAkYuXjFK35Ri2dEoxm7
qEY0sjGMaYSjGMF4xi7GUY52nIkX8/jFo+zxjnr8YyDzmEU6lpGMdKxJIg/JR4gtJIpicaIklejE
gVSSIJe0pBIxuclJFiSTl8zkPyrpyVF2cpOc/GQpTYkQUp5SIK60yCpZqUmFlJKJoHylKFPJSlyi
cpdQ4ckUbSJFAMikmFI8ZjFnskx7IFOZ0HSmMQfZxz6usZqKxGMj37hNbDbymtVcYyG7eU0vmhGc
2BQnIgvpxjRyc47w5CM6GRlORNpkj+ikJjvxmP/PxQyTJsOcokCNOdBoMpOg0yyoNA36Rnz+UZDz
hCgcwblIfraTnnbEaCDdaM6JajOdchwnIe1pTYqG1KPUzOZGK9pOkLZUn+u850cBwxBIFsSmkMwp
AP6hU4HgtJg83WlQfSpFW47xla38JSp5qcpaNpWpT52lL7V4kFyaMpYGwSosKanUrV6VqrsMZVe9
upCjIvWptEwqVa+a1aXWxaYE+elQeyrXugr1p3Ct6lHJqlenolWTs+SrYHkpVa6mFaq9XOth/SrW
tHrSqm1lqlYTYtbBftWyiN3iX+2S16HOdad0vStoRetZuOa1s7ScLFrD6tZbtva1SeWray0LWcX/
spawZ32sLt3q1Mb69berrK1howpb31IFis1MLkIX+kxlJjOg01zoQWUqT0NK9CZjrOdK19nG7h7y
nBdF6Rw7ysaUqnSl49WuO72ZzXJalKMnrS55S+rQbdKzn38hCWodst8EApNl/53RVv4ZFAJ7EL+F
Q3ARF8zgBjsYKyPpb1yFesQKW6Qnzf2JgW+yYZ/kIx8y+XCIQfzhEpMYxPYQsYlF/OD61ZTCEpHw
QGSskA8LxMb/sDGOB4JjHefDwv8TZnSjOdDmZli5DOUJi5d8YpuYeMQt7l9DgFra0X62yliWK0RW
XOIbm5ggO14xkOMHFOhCl7nLRTM0O+xhLqOY/8U1gTOco+zih+CVtKElapZhHBE3/zjHfwZzlwE9
ZhSalsJ5tquetbzlP4c50F6O9I4LrUBkTnjGVtZpUYmqZRofpMeB5jKhCS1qSofQ06ZO9fyEwma1
+PnVsF4xnWdN61rb+tYMPMQhuKLrrvQa14558aZvymeV6Joguj72QZJ9iIEwe9nNZoiy/8FsZSdb
INPGdrRVHRpGQ6Xa1I52trVNbmtv29nnDndBrm2QY7u72eMeN7ctY9eeBvXOmObIs8mt7nWLO93x
Tne/kS1wc4db3gOfN73xrOh8Y3kj++43wiPOb4K3u+AYRze8BZ5whctFyMmUrpoP2kysMFsmv//+
NU1SvmuUt7wmKq92smeicpffpNczp/nLgZ2YFxM736ctNkiebXB/8xvhHU96wKH9bnR7/DKdPbRn
9fxwfV+76FjfeELkzfVzT1zr00b60/ESdUSLFt9U1wi4tR32be9b5hc3OsHbDm22O33sc0lNza+y
d630neeGmYzY1c7xjgwe71MBvOIXz3iHtdowQ248/ZAZ+Zo8PieUX8rlK195ybPL51MWOn9FXxEZ
U3nqiO/gTjav3DOLHKBDbn1CZe/c2TPTmQDFvecdJuz9evvKqHf4zzfdcHunHbQz9mnqyVVmhCrU
zNDHCYGf+c8zZ/7xIc/w7j9v52IX/+yilzr/8Pf8c4UgP/nLV71OXA/7Nds+ye0ncpql+/z5vx73
sd/+u0LfX0vfW/wHEXRFJYBod2/HN2zKl37hAhaXRxQNiHn6B0ImgWrdR4EIQXoK+C0RuIFDkYEe
+IEg+EQcOIIkWIImeIJZEYIqeBEo2IIzsYIwOBEuOIM0WIM2GIExmIMPcYMlqIM+uBA8SII/OIRE
WIQKEYRImIS3ZoRGqIQ4yIRQGIVSOIVUWIVWeIVYmIXw44T6xxD88IVfKBBgGIZiOIb8MBBgiIZn
+A9hOIZsSIZk+IZpSBBz2IZm+IZlmIdyGIdlOId7aId0eId9GIhpaIZnKIh6qIUGwRNfKBON/9iI
9gCJkFgTYDgTj8gPloiJkSiJmjiJNlGJmxiKNMGJjoiJnkiJnZiKqDiKmoiKrXiKsKiKpciFOOGF
awiIeJiLgZiLbqiGfXiIwKgQboiLvsiLwYgQcHiLa1iMieiLyVgQfKiLz6iIi7gTZjiLoniNs8iJ
rYiNYxiKp+iKpjiOoLiJhpiJ4UiK5qiOpViOl4iOqQiKk8iOtEgTtpiHiBiNeJiMy6iHdgiIveiM
hdiPvxiQzFiQB6mLComPBLmPBBmH00iNBMGIqviO2AiPlfiNmbiNGfmK3QiOHfmJhviRoriR8/iR
nhiL2miSKOmRF1mPL7gQzziN0QiRwWiT/v9Ikw+pjMcIjcp4EDX5kwvJh0GZkMSYkxJpEYKIk4Yo
jcf4j09pk36Yk8AYkBGJiMwIlVr5hz25lVz5h7uYlAMBk5InlmZ5lmiZlmq5lnShk2q4jE2JkDgZ
ljN5h3XZi/rIlnlBkd7okS3Jiqv4ktlYkX8JkiJJlumijqSYki4ZmCXZlxwpkvQomIhpRLYYlw4Z
lgvJlQ05kjxJlHBplQ2pl6LhmQKpmfo4l4S4lKOpmglJmnjRE57ZjhpZkunYmKx4jo9Jm5QZjpVZ
Kux4khs5nMTpm8FZmBb5m+5ynMXZkiFJmYOJkePIkRrpm8rZGbCZndo5LtfZnd75neAZnuKCiRTb
mWrjeZ7oyTXlaWrp2WLr+Z7wSS3tOZ/0WZ/2KRnxaWH3uZ/8uR/5+Z8AOkT9aUMBKkQDeqAIChkF
uqAMupcJKkMNGqESOqEUWqEWeqEM8aAauqGEgaEhxKEr5KEcBKIkWqIm+oQimqIquqLcdqIu+qJX
waIJBKM0WqM2SkQBAQA7

------=_NextPart_000_0008_01C7128D.237F6A30--



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 kAS1UwZY000197; Mon, 27 Nov 2006 18:30:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAS1UwOA000194; Mon, 27 Nov 2006 18:30:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAS1UuQo000142 for <[e-mail]>; Mon, 27 Nov 2006 18:30:57 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1GoroE-000Ki8-GA for [e-mail]; Tue, 28 Nov 2006 01:30:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 01:31:33 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

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: [e-mail], 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 kAS1RVmE099446; Mon, 27 Nov 2006 18:27:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAS1RVEH099445; Mon, 27 Nov 2006 18:27:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAS1RUHO099439 for <[e-mail]>; Mon, 27 Nov 2006 18:27:31 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-33.mail.demon.net with esmtp (Exim 4.42) id 1Gorkv-0000nq-AX for [e-mail]; Tue, 28 Nov 2006 01:27:29 +0000
Message-ID: <[e-mail]>
Date: Tue, 28 Nov 2006 01:28:07 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David A. Cooper wrote:
> 
> Other people believe that placing a certificate on hold also places use
> of the private key on hold and so any signatures generated during the
> time that the certificate was on hold are not legitimate.  Thus, these
> people believe that when verifying a signature it is important to know
> whether the certificate was on hold at the time that the signature was
> generated, even if the certificate is later removed from hold.  The
> information included in CRLs issued after the certificate is removed
> from hold do not include any information that would help to determine
> whether the certificate was on hold at some point in the past.
> 

That's the case I'm uneasy about which I suspect is the case the two
examples I've seen are intended to cover.

It should be noted that this assumes that there is a way to reliably
determine when the signature was made.

This is not always possible and often one can only say it was made *on
or before* a certain time (for example the time in a trusted timestamp).

That doesn't help because the signature might be made during the hold
period and the timestamp added some time afterwards.

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: [e-mail], 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 kAS0e0He095011; Mon, 27 Nov 2006 17:40:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAS0e0om095010; Mon, 27 Nov 2006 17:40:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAS0dw5Q094973 for <[e-mail]>; Mon, 27 Nov 2006 17:39:59 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAS0dnMq018132; Mon, 27 Nov 2006 17:39:50 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Dr Stephen Henson" <[e-mail]>, <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 16:03:05 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur that it should be deprecated.

Mike

-----Original Message-----
From: Dr Stephen Henson
Sent: Monday, November 27, 2006 12:10 PM

. . .

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

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 kAS02pCp091265; Mon, 27 Nov 2006 17:02:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAS02pN7091264; Mon, 27 Nov 2006 17:02:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAS02okI091249 for <[e-mail]>; Mon, 27 Nov 2006 17:02:51 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 24200 invoked by uid 0); 28 Nov 2006 00:02:42 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 28 Nov 2006 00:02:42 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Mon, 27 Nov 2006 18:51:14 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: on-hold certificates in CRLs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano:

>>I have come across two real world examples of it being used in national
>>ID schemes. In both of these a certificate is automatically placed "on
>>hold" when the card is manufactured and then made valid when the
>>recipient has performed some procedure to acknowledge receipt. I suspect
>>that the two I saw are far from isolated examples.
>
>I do confirm that some big national CAs (at least in Italy) use the `on Hold'
>status when the card is first "initialized" (and the certificate issued)
>till the user receives the card.

If people are really using it, then we should not pull the rug out 
from under them.  I do not think this is a great mechanism for the 
situation that is described, but there are far worse uses that have 
been discussed.

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 kARMXUSc081711; Mon, 27 Nov 2006 15:33:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARMXU7Z081710; Mon, 27 Nov 2006 15:33:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay1.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARMXR4s081689 for <[e-mail]>; Mon, 27 Nov 2006 15:33:28 -0700 (MST) (envelope-from [e-mail])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.13.8/8.13.8) with ESMTP id kARMXFlx020725 for <[e-mail]>; Mon, 27 Nov 2006 23:33:15 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 7B05B194009 for <[e-mail]>; Mon, 27 Nov 2006 23:33:15 +0100 (CET)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07093-03 for <[e-mail]>; Mon, 27 Nov 2006 23:33:15 +0100 (CET)
Received: from NOTEBOOKLIPP (unknown [129.27.152.246]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 7BC87194008 for <[e-mail]>; Mon, 27 Nov 2006 23:33:13 +0100 (CET)
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Subject: AW: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 23:32:58 +0100
Message-ID: <002201c71274$074b7340$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AccSaXxSYpG5ddUzTTaWPzuUS81okQABBBSA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <[e-mail]>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Spam-Scanner: SpamAssassin 3.001007 
X-Spam-Score-relay: -2.6
X-Scanned-By: MIMEDefang 2.58 on 129.27.10.18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> to say that the "on hold" status MUST NOT be used by CAs 
> conforming to 3280bis.
YES PLEASE. Thanks. :-)

Peter Lipp



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 kARMWcFn081631; Mon, 27 Nov 2006 15:32:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARMWc4P081630; Mon, 27 Nov 2006 15:32:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARMWbPZ081615 for <[e-mail]>; Mon, 27 Nov 2006 15:32:37 -0700 (MST) (envelope-from [e-mail])
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 kARMWQGp021218 for <[e-mail]>; Mon, 27 Nov 2006 17:32:27 -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 kARMVoQJ028465 for <[e-mail]>; Mon, 27 Nov 2006 17:31:50 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 17:33:01 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I know of another case where certificate suspension is used (or at
least the CPS allows for certificate suspension).&nbsp; In this case, if the
CA receives a request to revoke a certificate but the source of the
request cannot be authenticated, then the certificate is placed on
hold.&nbsp; If the CA is able to verify that the request came from an
authorized individual (e.g., the certificate subject), then the
certificate is revoked, otherwise it is removed from hold.<br>
<br>
Note that in this case, once a certificate is removed from hold, there
is no reason that a relying party would need to know that the
certificate was on hold at some point in the past.&nbsp; The certificate was
removed from hold since it was determined that there was never a
problem with the certificate in the first place.&nbsp; Once the certificate
has been removed from hold, there is no reason to consider any use of
private key during the time that the certificate was on hold to be
invalid, so there is no need for relying parties to know that the
certificate was on hold at some point in the past.<br>
<br>
While I don't think that the above use of certificate suspension is
unreasonable (if it is necessary to take action before verifying the
revocation request), I do agree that it is generally a good idea to try
to avoid using certificate suspension.<br>
<br>
Dave<br>
<br>
Dr Stephen Henson wrote:
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap="">Russ Housley wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I would like to take this opportunity to advocate the deprecation of "on
hold" altogether.  No good can come from it, as been discussed so many
times on this list.

I can live with the current text, but I think it would be far better to
say that the "on hold" status MUST NOT be used by CAs conforming to
3280bis.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
I have come across two real world examples of it being used in national
ID schemes. In both of these a certificate is automatically placed "on
hold" when the card is manufactured and then made valid when the
recipient has performed some procedure to acknowledge receipt. I suspect
that the two I saw are far from isolated examples.

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

Steve.</pre>
</blockquote>
<br>
</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 kARLmd1e078044; Mon, 27 Nov 2006 14:48:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARLmd8A078043; Mon, 27 Nov 2006 14:48:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARLmcs8078033 for <[e-mail]>; Mon, 27 Nov 2006 14:48:39 -0700 (MST) (envelope-from [e-mail])
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 kARLmPYh025942; Mon, 27 Nov 2006 16:48:27 -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 kARLlQC6008534; Mon, 27 Nov 2006 16:47:26 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 16:48:39 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: =?UTF-8?B?Q2FybG9zIEdvbnrDoWxlei1DYWRlbmFz?= <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The contents of CRL are not affected by the information logged by the CA.

The important thing to note is that a CRL can have at most one entry for 
any given certificate.  So, the delta CRL issued at t5 would contain one 
entry for S1, and that entry would specify a reason code of 
removeFromCRL.  The full CRL issued at t6 would not include an entry for S1.

In some sense, you are correct that you cannot tell from the contents of 
the CRL issued at t6 whether the certificate had been on hold at some 
point in the past.  One of the main problems that we have with 
certificate suspension at the moment is that there are two competing 
interpretations of meaning behind certificate suspension.  In my opinion 
(and I believe that this was the meaning intended by the authors of 
X.509), there is no reason that one would need to know whether a 
certificate was on hold at some point in the past.  In your example, the 
certificate was removed from hold since it was determined that the 
private key had not actually been compromised (if it had been, the 
certificate would have remained revoked, but with the reason code 
changed to keyCompromise).  I would argue that this means that any 
signatures created during the time that the certificate was on hold are 
valid and that a relying party can safely accept those signatures once 
the certificate is removed from hold.  So, there would be no need for 
the relying party to know that the certificate was on hold at the time 
the signature was generated.  If there really was reason to believe that 
the private key had been misused at some time in the past, then the 
certificate should have been permanently revoked.

Other people believe that placing a certificate on hold also places use 
of the private key on hold and so any signatures generated during the 
time that the certificate was on hold are not legitimate.  Thus, these 
people believe that when verifying a signature it is important to know 
whether the certificate was on hold at the time that the signature was 
generated, even if the certificate is later removed from hold.  The 
information included in CRLs issued after the certificate is removed 
from hold do not include any information that would help to determine 
whether the certificate was on hold at some point in the past.

Dave

Carlos González-Cadenas wrote:
> Hi,
>
> Suppose we have the following ordered temporal sequence
>
> t1 - a certificate with serial "S1" is issued by a CA
> t2 - the certificate is put on-hold by the CA (i.e. in order to 
> investigate a possible compromise)
> t3 - a full CRL is issued by the CA
> t4 - the investigation carried by the CA ends up in no compromise, and 
> the CA makes the certificate valid again
> t5 - a delta CRL is issued by the CA
> t6 - a full CRL is issued by the CA
>
> Does the CRL logs all the revocation-related events for the 
> certificate with serial S1?.
>
> If we assume that all the events are logged, then the CRLs contents 
> (for certificate with serial S1) should be:
>
> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
> on-hold
> delta CRL issued at t5: contains the previous full CRL entry plus an 
> entry for S1 at t5 with reason code removeFromCRL
> full CRL issued  at t6: contains both previous entries (so you know 
> the on-hold period for the certificate) (maybe this is violating 
> RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
> include revocation entries for certificate S1, that is
>
> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
> on-hold
> delta CRL issued at t5: contains the previous full CRL entry plus an 
> entry for S1 at t5 with reason code removeFromCRL
> full CRL issued  at t6: contains NO entry for S1
>
> Which is the normative (RFC3280) behaviour for that case?. Is there 
> any change between RFC3280 and RFC3280bis about these issues?
>
> Note that if the second case is the normative behaviour IMHO there's 
> no way (except storing the CRLs between t2 and the next CRL appeared 
> after t4) for a relying party (verifying the certificate in or after 
> t6) to know the certificate status between t2 and t4.
>
> Many thanks in advance,
>
> Carlos



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 kARLYKnP076884; Mon, 27 Nov 2006 14:34:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARLYKfK076883; Mon, 27 Nov 2006 14:34:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kARLYI57076848 for <[e-mail]>; Mon, 27 Nov 2006 14:34:19 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 53727 invoked from network); 27 Nov 2006 21:34:13 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.17.79.115 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 27 Nov 2006 21:34:13 -0000
X-YMail-OSG: 7iJE5jEVM1lEmsUv4XKAoKq6cItffhyaNTFf9I4cxcxlp98DFV2EimcGELiMa63nVWxqn0e8AMHVqc0kTeraMI5LXvnX.QvAUOwL.eHK5OrvYLNEK7kDcw--
Reply-To: <[e-mail]>
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 16:33:30 -0500
Organization: IECA, Inc.
Message-ID: <012c01c7126b$aebde670$0201a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Thread-Index: AccSaNfQEN/9uBUGQZiv6wZfGZm4UgAArTXA
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kARLYJ57076877
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree - on hold shoud be made a MUST NOT.

spt

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Farrell
Sent: Monday, November 27, 2006 3:17 PM
To: Russ Housley
Cc: [e-mail]
Subject: Re: on-hold certificates in CRLs



Bit of a late change, but a good one,
S.

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of 
> "on hold" altogether.  No good can come from it, as been discussed so 
> many times on this list.
> 
> I can live with the current text, but I think it would be far better 
> to say that the "on hold" status MUST NOT be used by CAs conforming to 
> 3280bis.
> 
> Russ
> 
> At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote:
>> Hi,
>>
>> Suppose we have the following ordered temporal sequence
>>
>> t1 - a certificate with serial "S1" is issued by a CA
>> t2 - the certificate is put on-hold by the CA (i.e. in order to 
>> investigate a possible compromise)
>> t3 - a full CRL is issued by the CA
>> t4 - the investigation carried by the CA ends up in no compromise, 
>> and the CA makes the certificate valid again
>> t5 - a delta CRL is issued by the CA
>> t6 - a full CRL is issued by the CA
>>
>> Does the CRL logs all the revocation-related events for the 
>> certificate with serial S1?.
>>
>> If we assume that all the events are logged, then the CRLs contents 
>> (for certificate with serial S1) should be:
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason 
>> code on-hold delta CRL issued at t5: contains the previous full CRL 
>> entry plus an entry for S1 at t5 with reason code removeFromCRL full 
>> CRL issued  at t6: contains both previous entries (so you know the 
>> on-hold period for the certificate) (maybe this is violating RFC3280 
>> as removeFromCRL is only applicable for deltaCRLs??)
>>
>> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>> include revocation entries for certificate S1, that is
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason 
>> code on-hold delta CRL issued at t5: contains the previous full CRL 
>> entry plus an entry for S1 at t5 with reason code removeFromCRL full 
>> CRL issued  at t6: contains NO entry for S1
>>
>> Which is the normative (RFC3280) behaviour for that case?. Is there 
>> any change between RFC3280 and RFC3280bis about these issues?
>>
>> Note that if the second case is the normative behaviour IMHO there's 
>> no way (except storing the CRLs between t2 and the next CRL appeared 
>> after t4) for a relying party (verifying the certificate in or after
>> t6) to know the certificate status between t2 and t4.
>>
>> Many thanks in advance,
>>
>> Carlos
>>
> 
> 






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 kARLM4Uh075148; Mon, 27 Nov 2006 14:22:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARLM4uR075147; Mon, 27 Nov 2006 14:22:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.cs.dartmouth.edu (mail.cs.dartmouth.edu [129.170.212.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARLM38f075141 for <[e-mail]>; Mon, 27 Nov 2006 14:22:04 -0700 (MST) (envelope-from [e-mail])
Received: from [130.192.1.59] ([130.192.1.59]) (authenticated bits=0) by mail.cs.dartmouth.edu (8.13.8/8.13.4) with ESMTP id kARLLwJb026856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 27 Nov 2006 16:22:01 -0500
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 22:21:19 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Dartmouth College - Computer Science Department
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000907060206070402020700"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms000907060206070402020700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dr Stephen Henson wrote:
[...]
> I have come across two real world examples of it being used in national
> ID schemes. In both of these a certificate is automatically placed "on
> hold" when the card is manufactured and then made valid when the
> recipient has performed some procedure to acknowledge receipt. I suspect
> that the two I saw are far from isolated examples.

I do confirm that some big national CAs (at least in Italy) use the `on Hold'
status when the card is first "initialized" (and the certificate issued)
till the user receives the card.

> Personally the use of "on hold" always makes me rather uneasy and I'd
> have no objections about it being deprecated.

One question, is there any proposal for the replacement of the `on hold'
status ? Some time ago (back in 2000, I guess) there was the proposal
of a separated CSL (Certificate Suspension List) which was rejected in
favor of the "on hold" extension in CRLs... anyway do you think it is
time to address the 'suspended' state once for all ?

We can also agree with the fact that the suspension, as it is now, it is
too difficult to handle and it is error prone, so a viable path would be
to clearly state that there is not a ``suspended'' state, therefore a
certificate is either valid or revoked.

And we stick with simply reissuing the certificates (as, I guess, it is
the most common practice today (?)).

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala                                  [OpenCA Project Manager]

Dartmouth Computer Science Dept                       [e-mail]
PKI/Trust                                        [e-mail]
-----------------------------------------------------------------------o---

--------------ms000907060206070402020700
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx
GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0
bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNjA0MDcx
NTE4MzNaFw0xMDA0MDgxNTE4MzNaMIGnMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1v
dXRoIENvbGxlZ2UxJDAiBgNVBAsTG0NvbXB1dGVyIFNjaWVuY2UgRGVwYXJ0bWVudDEUMBIG
CgmSJomT8ixkAQETBHBhbGExGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMSQwIgYJKoZI
hvcNAQkBFhVwYWxhQGNzLmRhcnRtb3V0aC5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALHoVbyJOrdrYLdA9qV5FNo8dmX6eNKj0ZgiwCsovlhhYZeYbduMJ3G91dTHZiX31lwg
bhsTwl3gStQtgGBDzUn9oxJET9cO5ORfwNN9P0ZCuq1fLy38CpUEQNgjhzXYuD1PUFBDwvp8
fCvBGMXop7Rw6cCFTBnABN2R+XOpAKT9AgMBAAGjggFQMIIBTDAOBgNVHQ8BAf8EBAMCBeAw
EQYJYIZIAYb4QgEBBAQDAgWgMB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMIGi
BgNVHSAEgZowgZcwgZQGCisGAQQBQQIBAQEwgYUwPQYIKwYBBQUHAgIwMTAYFhFEYXJ0bW91
dGggQ29sbGVnZTADAgEBGhVEYXJ0bW91dGggQ29sbGVnZSBDUFMwRAYIKwYBBQUHAgEWOGh0
dHA6Ly93d3cuZGFydG1vdXRoLmVkdS9+cGtpbGFiL0RhcnRtb3V0aENQU180U2VwMDMucGRm
MCAGA1UdEQQZMBeBFXBhbGFAY3MuZGFydG1vdXRoLmVkdTA/BggrBgEFBQcBAQQzMDEwLwYI
KwYBBQUHMAGGI2h0dHA6Ly9jb2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3
DQEBBAUAA4IBAQDOqoLRDppYBEFAtYdM5lvsbZ97q97SW7HCyNysOBtadfRH2QulfH8h+RZ6
AikMTt8yGl4JTJE5II89IPT5gRbSUadDT+Uyh1TAwNvJDxspcBS4Z4KsNw2wPwgHM1uM9xYG
nS+xMcDUHCvPjSgD52HSi27alulq7jrNJMjUIK8qLI21NnDvVDVMPUIdGOz5tvmJEYu44gTV
jYBJI7Q/qhZ1tdKudDh3oDW9wAhJMBct8nLn/xG15HsDtK9qHSR+O8/7/Sax7I06HbR7zsbl
AJUM1gy25I89P3HEWaYaoK+ZKIjipw73076vorcidktUobIfZO1/SBXPqEBeAYTQh4Y0MIIE
aTCCA1GgAwIBAgICHeMwDQYJKoZIhvcNAQEEBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZ
MBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRt
b3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA2MDQwNzE1
MTgzM1oXDTEwMDQwODE1MTgzM1owgacxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91
dGggQ29sbGVnZTEkMCIGA1UECxMbQ29tcHV0ZXIgU2NpZW5jZSBEZXBhcnRtZW50MRQwEgYK
CZImiZPyLGQBARMEcGFsYTEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExJDAiBgkqhkiG
9w0BCQEWFXBhbGFAY3MuZGFydG1vdXRoLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAsehVvIk6t2tgt0D2pXkU2jx2Zfp40qPRmCLAKyi+WGFhl5ht24wncb3V1MdmJffWXCBu
GxPCXeBK1C2AYEPNSf2jEkRP1w7k5F/A030/RkK6rV8vLfwKlQRA2COHNdi4PU9QUEPC+nx8
K8EYxeintHDpwIVMGcAE3ZH5c6kApP0CAwEAAaOCAVAwggFMMA4GA1UdDwEB/wQEAwIF4DAR
BglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUP8DWx6dPAH7vBplnbLyWHk2jdxIwgaIG
A1UdIASBmjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0
aCBDb2xsZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0
cDovL3d3dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYw
IAYDVR0RBBkwF4EVcGFsYUBjcy5kYXJ0bW91dGguZWR1MD8GCCsGAQUFBwEBBDMwMTAvBggr
BgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGguZWR1L29jc3AwDQYJKoZIhvcN
AQEEBQADggEBAM6qgtEOmlgEQUC1h0zmW+xtn3ur3tJbscLI3Kw4G1p19EfZC6V8fyH5FnoC
KQxO3zIaXglMkTkgjz0g9PmBFtJRp0NP5TKHVMDA28kPGylwFLhngqw3DbA/CAczW4z3Fgad
L7ExwNQcK8+NKAPnYdKLbtqW6WruOs0kyNQgryosjbU2cO9UNUw9Qh0Y7Pm2+YkRi7jiBNWN
gEkjtD+qFnW10q50OHegNb3ACEkwFy3ycuf/EbXkewO0r2odJH47z/v9JrHsjTodtHvOxuUA
lQzWDLbkjz0/ccRZphqgr5koiOKnDvfTvq+ityJ2S1Shsh9k7X9IFc+oQF4BhNCHhjQxggL4
MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0
bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UE
AxMTRGFydG1vdXRoIENlcnRBdXRoMQICHeMwCQYFKw4DAhoFAKCCAdEwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTI3MjEyMTE5WjAjBgkqhkiG9w0B
CQQxFgQUTzi6NBcypa6hLrn4iVbZA5pC7RMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT
8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xs
ZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgId4zCBjgYLKoZIhvcNAQkQAgsx
f6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx
CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFy
dG1vdXRoIENlcnRBdXRoMQICHeMwDQYJKoZIhvcNAQEBBQAEgYB6wrFvTB7WV4oplwNTmCvR
3/lg3a90uJabNC4koAHkUgsHEsmHa+MrUO+lDZOmkhtHUZmLiU+IWR4eOAW1PUuqu3zgu4s8
gYAid3TVgxs3MatPYBG8muraQvC9IbRqtYxNAObhaC4SmUc+uIkY4nZR0NDqJnPdIw8mvO7m
foSgIgAAAAAAAA==
--------------ms000907060206070402020700--



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 kARLLals074973; Mon, 27 Nov 2006 14:21:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARLLakp074972; Mon, 27 Nov 2006 14:21:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARLLZuw074955 for <[e-mail]>; Mon, 27 Nov 2006 14:21:36 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: on-hold certificates in CRLs
Date: Mon, 27 Nov 2006 13:23:40 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: on-hold certificates in CRLs
Thread-Index: AccSZ03EcEMyH0ytTKGYA/zYGQVoUwAAn6ug
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kARLLauw074967
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I do not agree with the conclusion that on hold is overly complex.  We should have a profile that does not require the use of "Hold Instruction".  In that case, on hold and remove from hold is a nice feature.

As to determination of the certificate status, archiving all CRL (and deltas if deltas are produced) give the accurate picture of revocation status modulo CRL issuance frequency.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Monday, November 27, 2006 2:12 PM
To: Carlos González-Cadenas; [e-mail]
Subject: Re: on-hold certificates in CRLs


I would like to take this opportunity to advocate the deprecation of 
"on hold" altogether.  No good can come from it, as been discussed so 
many times on this list.

I can live with the current text, but I think it would be far better 
to say that the "on hold" status MUST NOT be used by CAs conforming to 3280bis.

Russ

At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote:
>Hi,
>
>Suppose we have the following ordered temporal sequence
>
>t1 - a certificate with serial "S1" is issued by a CA
>t2 - the certificate is put on-hold by the CA (i.e. in order to 
>investigate a possible compromise)
>t3 - a full CRL is issued by the CA
>t4 - the investigation carried by the CA ends up in no compromise, 
>and the CA makes the certificate valid again
>t5 - a delta CRL is issued by the CA
>t6 - a full CRL is issued by the CA
>
>Does the CRL logs all the revocation-related events for the 
>certificate with serial S1?.
>
>If we assume that all the events are logged, then the CRLs contents 
>(for certificate with serial S1) should be:
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains both previous entries (so you know 
>the on-hold period for the certificate) (maybe this is violating 
>RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
>If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>include revocation entries for certificate S1, that is
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains NO entry for S1
>
>Which is the normative (RFC3280) behaviour for that case?. Is there 
>any change between RFC3280 and RFC3280bis about these issues?
>
>Note that if the second case is the normative behaviour IMHO there's 
>no way (except storing the CRLs between t2 and the next CRL appeared 
>after t4) for a relying party (verifying the certificate in or after 
>t6) to know the certificate status between t2 and t4.
>
>Many thanks in advance,
>
>Carlos
>




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 kARKGffR068081; Mon, 27 Nov 2006 13:16:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARKGfjH068080; Mon, 27 Nov 2006 13:16:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kARKGb62068063 for <[e-mail]>; Mon, 27 Nov 2006 13:16:40 -0700 (MST) (envelope-from [e-mail])
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id C12E43208A; Mon, 27 Nov 2006 20:16:36 +0000 (GMT)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id kARKGTMD007351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Nov 2006 20:16:31 GMT
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 20:17:21 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 3330665 - 1232c87a8eaf
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bit of a late change, but a good one,
S.

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of "on 
> hold" altogether.  No good can come from it, as been discussed so many 
> times on this list.
> 
> I can live with the current text, but I think it would be far better to 
> say that the "on hold" status MUST NOT be used by CAs conforming to 
> 3280bis.
> 
> Russ
> 
> At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote:
>> Hi,
>>
>> Suppose we have the following ordered temporal sequence
>>
>> t1 - a certificate with serial "S1" is issued by a CA
>> t2 - the certificate is put on-hold by the CA (i.e. in order to 
>> investigate a possible compromise)
>> t3 - a full CRL is issued by the CA
>> t4 - the investigation carried by the CA ends up in no compromise, and 
>> the CA makes the certificate valid again
>> t5 - a delta CRL is issued by the CA
>> t6 - a full CRL is issued by the CA
>>
>> Does the CRL logs all the revocation-related events for the 
>> certificate with serial S1?.
>>
>> If we assume that all the events are logged, then the CRLs contents 
>> (for certificate with serial S1) should be:
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains both previous entries (so you know 
>> the on-hold period for the certificate) (maybe this is violating 
>> RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>>
>> If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>> include revocation entries for certificate S1, that is
>>
>> full CRL issued at t3: contains an entry for S1 at t3 with reason code 
>> on-hold
>> delta CRL issued at t5: contains the previous full CRL entry plus an 
>> entry for S1 at t5 with reason code removeFromCRL
>> full CRL issued  at t6: contains NO entry for S1
>>
>> Which is the normative (RFC3280) behaviour for that case?. Is there 
>> any change between RFC3280 and RFC3280bis about these issues?
>>
>> Note that if the second case is the normative behaviour IMHO there's 
>> no way (except storing the CRLs between t2 and the next CRL appeared 
>> after t4) for a relying party (verifying the certificate in or after 
>> t6) to know the certificate status between t2 and t4.
>>
>> Many thanks in advance,
>>
>> Carlos
>>
> 
> 



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 kARK9a9b067396; Mon, 27 Nov 2006 13:09:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARK9aST067395; Mon, 27 Nov 2006 13:09:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARK9YGB067385 for <[e-mail]>; Mon, 27 Nov 2006 13:09:35 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1GomnD-000M44-4p for [e-mail]; Mon, 27 Nov 2006 20:09:31 +0000
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 20:10:20 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: on-hold certificates in CRLs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> I would like to take this opportunity to advocate the deprecation of "on
> hold" altogether.  No good can come from it, as been discussed so many
> times on this list.
> 
> I can live with the current text, but I think it would be far better to
> say that the "on hold" status MUST NOT be used by CAs conforming to
> 3280bis.
> 

I have come across two real world examples of it being used in national
ID schemes. In both of these a certificate is automatically placed "on
hold" when the card is manufactured and then made valid when the
recipient has performed some procedure to acknowledge receipt. I suspect
that the two I saw are far from isolated examples.

Personally the use of "on hold" always makes me rather uneasy and I'd
have no objections about it being deprecated.

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: [e-mail], 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 kARJBflu059048; Mon, 27 Nov 2006 12:11:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARJBfkI059047; Mon, 27 Nov 2006 12:11:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kARJBaF9059039 for <[e-mail]>; Mon, 27 Nov 2006 12:11:39 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27500 invoked by uid 0); 27 Nov 2006 19:11:31 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 27 Nov 2006 19:11:31 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Mon, 27 Nov 2006 14:11:32 -0500
To: "Carlos González-Cadenas" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: on-hold certificates in CRLs
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to take this opportunity to advocate the deprecation of 
"on hold" altogether.  No good can come from it, as been discussed so 
many times on this list.

I can live with the current text, but I think it would be far better 
to say that the "on hold" status MUST NOT be used by CAs conforming to 3280bis.

Russ

At 10:53 AM 11/27/2006, Carlos González-Cadenas wrote:
>Hi,
>
>Suppose we have the following ordered temporal sequence
>
>t1 - a certificate with serial "S1" is issued by a CA
>t2 - the certificate is put on-hold by the CA (i.e. in order to 
>investigate a possible compromise)
>t3 - a full CRL is issued by the CA
>t4 - the investigation carried by the CA ends up in no compromise, 
>and the CA makes the certificate valid again
>t5 - a delta CRL is issued by the CA
>t6 - a full CRL is issued by the CA
>
>Does the CRL logs all the revocation-related events for the 
>certificate with serial S1?.
>
>If we assume that all the events are logged, then the CRLs contents 
>(for certificate with serial S1) should be:
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains both previous entries (so you know 
>the on-hold period for the certificate) (maybe this is violating 
>RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
>
>If we assume that NOT all events are logged, CRLs issued >=T6 don't 
>include revocation entries for certificate S1, that is
>
>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold
>delta CRL issued at t5: contains the previous full CRL entry plus an 
>entry for S1 at t5 with reason code removeFromCRL
>full CRL issued  at t6: contains NO entry for S1
>
>Which is the normative (RFC3280) behaviour for that case?. Is there 
>any change between RFC3280 and RFC3280bis about these issues?
>
>Note that if the second case is the normative behaviour IMHO there's 
>no way (except storing the CRLs between t2 and the next CRL appeared 
>after t4) for a relying party (verifying the certificate in or after 
>t6) to know the certificate status between t2 and t4.
>
>Many thanks in advance,
>
>Carlos
>



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 kARFrAbV035803; Mon, 27 Nov 2006 08:53:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kARFrAUf035802; Mon, 27 Nov 2006 08:53:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARFr8qI035794 for <[e-mail]>; Mon, 27 Nov 2006 08:53:09 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id m18so1966867nfc for <[e-mail]>; Mon, 27 Nov 2006 07:53:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ASD+OfwT4etTnA6ASvebHfJtialtSqKYYrcS7cySTLfXV+kcjXHaGtg3JAgvCcjCdLmw7GyZwj66Is2qlXSfzyD5IPph5FYhCC69gfYniRv9NjxpLiggexsYOt9mAdFIVuTnZiyZHeXStyehYGnVmlGNJpXtWtonEcEz7Ve2hy8=
Received: by 10.48.202.14 with SMTP id z14mr2986876nff.1164642787579; Mon, 27 Nov 2006 07:53:07 -0800 (PST)
Received: by 10.48.223.9 with HTTP; Mon, 27 Nov 2006 07:53:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 27 Nov 2006 16:53:07 +0100
From: "=?UTF-8?Q?Carlos_Gonz=C3=A1lez-Cadenas?=" <[e-mail]>
To: [e-mail]
Subject: on-hold certificates in CRLs
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_80519_6154254.1164642787295"
X-Google-Sender-Auth: 235dbe382a157c89
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_80519_6154254.1164642787295
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Suppose we have the following ordered temporal sequence

t1 - a certificate with serial "S1" is issued by a CA
t2 - the certificate is put on-hold by the CA (i.e. in order to investigate
a possible compromise)
t3 - a full CRL is issued by the CA
t4 - the investigation carried by the CA ends up in no compromise, and the
CA makes the certificate valid again
t5 - a delta CRL is issued by the CA
t6 - a full CRL is issued by the CA

Does the CRL logs all the revocation-related events for the certificate with
serial S1?.

If we assume that all the events are logged, then the CRLs contents (for
certificate with serial S1) should be:

full CRL issued at t3: contains an entry for S1 at t3 with reason code
on-hold
delta CRL issued at t5: contains the previous full CRL entry plus an entry
for S1 at t5 with reason code removeFromCRL
full CRL issued  at t6: contains both previous entries (so you know the
on-hold period for the certificate) (maybe this is violating RFC3280 as
removeFromCRL is only applicable for deltaCRLs??)

If we assume that NOT all events are logged, CRLs issued >=T6 don't include
revocation entries for certificate S1, that is

full CRL issued at t3: contains an entry for S1 at t3 with reason code
on-hold
delta CRL issued at t5: contains the previous full CRL entry plus an entry
for S1 at t5 with reason code removeFromCRL
full CRL issued  at t6: contains NO entry for S1

Which is the normative (RFC3280) behaviour for that case?. Is there any
change between RFC3280 and RFC3280bis about these issues?

Note that if the second case is the normative behaviour IMHO there's no way
(except storing the CRLs between t2 and the next CRL appeared after t4) for
a relying party (verifying the certificate in or after t6) to know the
certificate status between t2 and t4.

Many thanks in advance,

Carlos

------=_Part_80519_6154254.1164642787295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,<br><br>Suppose we have the following ordered temporal sequence<br><br>t1 - a certificate with serial &quot;S1&quot; is issued by a CA<br>t2 - the certificate is put on-hold by the CA (i.e. in order to investigate a possible compromise)
<br>t3 - a full CRL is issued by the CA<br>t4 - the investigation carried by the CA ends up in no compromise, and the CA makes the certificate valid again<br>t5 - a delta CRL is issued by the CA<br>t6 - a full CRL is issued by the CA
<br><br>Does the CRL logs all the revocation-related events for the certificate with serial S1?. <br><br>If we assume that all the events are logged, then the CRLs contents (for certificate with serial S1) should be:<br><br>
full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold<br>delta CRL issued at t5: contains the previous full CRL entry plus an entry for S1 at t5 with reason code removeFromCRL<br>full CRL issued&nbsp; at t6: contains both previous entries (so you know the on-hold period for the certificate) (maybe this is violating RFC3280 as removeFromCRL is only applicable for deltaCRLs??)
<br><br>If we assume that NOT all events are logged, CRLs issued &gt;=T6 don't include revocation entries for certificate S1, that is<br><br>full CRL issued at t3: contains an entry for S1 at t3 with reason code on-hold<br>

delta CRL issued at t5: contains the previous full CRL entry plus an entry for S1 at t5 with reason code removeFromCRL<br>
full CRL issued&nbsp; at t6: contains NO entry for S1<br><br>Which is the normative (RFC3280) behaviour for that case?. Is there any change between RFC3280 and RFC3280bis about these issues?<br><br>Note that if the second case is the normative behaviour IMHO there's no way (except storing the CRLs between t2 and the next CRL appeared after t4) for a relying party (verifying the certificate in or after t6) to know the certificate status between t2 and t4. 
<br><br>Many thanks in advance,<br><br>Carlos<br><br><br>

------=_Part_80519_6154254.1164642787295--



Received: from p83.129.20.5.tisdip.tiscali.de (p83.129.30.22.tisdip.tiscali.de [83.129.30.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kARFWOXd032551 for <[e-mail]>; Mon, 27 Nov 2006 08:32:30 -0700 (MST) (envelope-from [e-mail])
Received: from [144.104.3.45] (port=1778 helo=jfkbeaaWqVoM) by HnyzDGRfpN with asmtp id gqzoJs-XvaesI-14 for [e-mail]; Mon, 27 Nov 2006 16:32:44 +0100
Message-ID: <000b01c71239$39f4aa40$00000000@uwecba52adfad3>
From: "Recommend" <[e-mail]>
To: [e-mail]
Subject: sich anmelden um zu ist
Date: 	Mon, 27 Nov 2006 16:32:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
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

Vorbei gre thomthom, kabbala quersumme, ziffern des. Gain fb made, half way chapter little, fun contents.

*WEXE* *WEXE* *WEXE*
WEXE GAINS ENORMOUS MOMENTUM!
UP 17% ON FRIDAY ALONE!

Company:   WEST EXCELSIOR ENT (Other OTC:WEXE.PK)
Symbol:      WEXE
Price:        $0.70
5-day Target: $4
Rating: Strong Buy

West Excelsior Enterprises Inc. Completes Financing
and Meets its Option Agreement Commitments

GET ON THIS BULL RUN NOW!
WATCH WEXE ON MON NOV 27TH!
Disclaimer: Information within this email contains "forward looking statements"
within the meaning of Section 27a of the Securities act of 1933 and Section 21B
of the Securities exchange act of 1934. The Publisher of this report was
compensated by an unrelated third party twenty five thousand dollars for
distribution of this report.

Explains pull, cvs official talkback crash buildsif know. Our index indexed urls titles copy inc rights. Browser hinweise, admin coole scheie omal buxy berschrift.
Inside mouse edit field.
Bf log upwhy joinforgot password.
Finland france croatia hungary, ireland israel india italy.
Right maps keyword map, location. Numbers customer sitefind, local centernote manage!
Absatz ihrer darum bitten. Pictures ossweb ossmon maverix skin lmboxtargz libraries burn ipod. Made half, way chapter little fun contents. Applied his works full sitemap kit except. What you tell it to so here. Something similar links related searches under box at. Admin coole, scheie omal buxy berschrift le wurscht welches.
Was located facilitate, single able install! Tools form this title longer program.
Yourself unofficial configured linuxx sha rpms, ftp.
Document our index indexed urls titles copy inc.
Image text files three interfaces desktop.
Complete metadata fields integrity fill accurately, possible.
But small fee future light? Dieser, verkrzt nchsten, evening narwal, schaaaaade morgens? Video image text files three interfaces desktop peertopeer client. Seal seine flickrsong bush bingo kamel!
Kamel gegen, broklammer beolingus virtuelle dice making. Rtl mac abgeraucht, beiden. Press, briefing whats newlinks, scrolling.
Committee against torture cat concerning.



Received: from 201.160.132.32.cableonline.com.mx (201.160.132.32.cableonline.com.mx [201.160.132.32] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAQM7047015516 for <[e-mail]>; Sun, 26 Nov 2006 15:07:00 -0700 (MST) (envelope-from [e-mail])
Received: from [110.165.100.49] (port=6762 helo=LSdieM) by  with asmtp id yKZgTr-WVaibT-56 for [e-mail]; Sun, 26 Nov 2006 14:07:12 -0800
Message-ID: <001201c711a7$2f3dd320$00000000@casaraaquveiy9>
From: "Course" <[e-mail]>
To: [e-mail]
Subject: movies videos books downloads
Date: 	Sun, 26 Nov 2006 14:06:55 -0800
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C71164.211A9320"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C71164.211A9320
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000F_01C71164.211A9320"


------=_NextPart_001_000F_01C71164.211A9320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Specific describe exactly youre looking will give larger. Delta =
heritage, museum item aircraft? Narrow searchfor example chairs instead, =
camera. States turn complete, campus service, solutions fourteen join. =
Offer single campuswide teaching system!
Service solutions fourteen join commerce. Pack licenses features, active =
recent additions districts, engagement, homeschool! Fashion excluding =
default returns, pages include. Own terms test drive extend.
Gift cards podcasts posters sales special, offers shipping holiday!
Kong inr india rupees. An, exact phrase put quotation marks around? =
Globe leading schools government agencies. Douglas ang geminiaces galft =
bf adolf galland garaf mkix!
Publisher video, games game category wish list account. Books downloads =
more except classical artist search album!
Composer performer conductor ensemble, labels catalog dvdvideo castcrew. =
Right maps, keyword, location. Here some tips better words specific =
describe exactly youre. Character when shortcut part. Berkeley =
electronic content blocktm eighteen, implement. Bourne identity fidelity =
million.
Msrp, gjdal boeing nda. Days only thursday nov monday cd robin thicke, =
cat. Shortcuts find flash set five keywords character! Php, sar saudi =
arabia riyals sgd singapore!
------=_NextPart_001_000F_01C71164.211A9320
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000d01c711a7$2f3dd320$00000000@casaraaquveiy9" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Specific describe exactly youre looking =
will give=20
larger. Delta heritage, museum item aircraft? Narrow searchfor example =
chairs=20
instead, camera. States turn complete, campus service, solutions =
fourteen join.=20
Offer single campuswide teaching system!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Service solutions fourteen join =
commerce. Pack=20
licenses features, active recent additions districts, engagement, =
homeschool!=20
Fashion excluding default returns, pages include. Own terms test drive =
extend.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Gift cards podcasts posters sales =
special, offers=20
shipping holiday!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Kong inr india rupees. An, exact phrase =
put=20
quotation marks around? Globe leading schools government agencies. =
Douglas ang=20
geminiaces galft bf adolf galland garaf mkix!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Publisher video, games game category =
wish list=20
account. Books downloads more except classical artist search =
album!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Composer performer conductor ensemble, =
labels=20
catalog dvdvideo castcrew. Right maps, keyword, location. Here some tips =
better=20
words specific describe exactly youre. Character when shortcut part. =
Berkeley=20
electronic content blocktm eighteen, implement. Bourne identity fidelity =
million.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Msrp, gjdal boeing nda. Days only =
thursday nov=20
monday cd robin thicke, cat. Shortcuts find flash set five keywords =
character!=20
Php, sar saudi arabia riyals sgd singapore!</FONT></DIV></BODY></HTML>

------=_NextPart_001_000F_01C71164.211A9320--

------=_NextPart_000_000E_01C71164.211A9320
Content-Type: image/gif;
	name="Releases Media.gif"
Content-Transfer-Encoding: base64
Content-ID: <000d01c711a7$2f3dd320$00000000@casaraaquveiy9>

R0lGODlh2AGsAYfqAAUAAIsEAAB9AHaNCA0Of30AeAB9dM6zzcDitZe75UYrAF8tAIMlAJgbC70t
AOEnAA5GACpLDDE4A1pLA4Q0DJhNCLQyAOxLDARVASVbBUFSDWlhAIRsCZdpBMJfA9tbAACGAB6M
BDpyAF99Cn+JAKt3AcCDCOiAAACWABWdAEifAFGRAHuaAJyWBbKVDd2sAADIACnJADvJBGOxDH+/
BJPAAMa5C+zGAgDtAC3pAEzWAFnVCYbmBpvfALrrANXUAAEGRCkANTIAPG0GQYwFN54ARsIISeIA
Og0dQioSRDISQGweOnQaRJ4gRcMpMdMaQARCNRFEM0Y4Olk/Pn5FTZg2NLU/P902QgBhMyJiOTph
OlxpNXVWAKJtNMNuTdZVOwt7Ohp8TkOBSlqMOHKCNJmNPLRyROKNTACkQSSTNEOhQmWsNI6aTZWg
Ns2VQdiZTADJTirEQjvGNVHGOnXFTqLHMbu6SNi/NAzmShnVSDPWP2jrTnTVMqLqR8TkPNTjRQAA
gCkDe0YAjmsAfoUJgJsAecIAeOoMcgAnhxMojUQkf2kogoQoep8mcs4XidMXdgw4fxVFjUxGjlk7
iHZFiaZNgMtOe9o3gQBsfytTgENte1xZe3lafJZTcshmedNihAaJdCOBfT97gmR6goh1h552fbh1
eN6FcgCVeiSgcTapdW6VeXuVfaaSh7GUc9WdjgzLcRm2gEDNclG1cXm+f665e7S1edjAgg7Wjhbu
ijXdf1fnh43Zh6DRgsDUheHTgAQAwyIAs0AJxVYEtHoGs5IByM4KyNcAvgARvy0nwzkYu1MnuI0l
upsmv7wSxdsWyABJyBM2vUc8yW42ungysqI0vbEyueROtABWvi5jv05tul1juHFhuJFYwcNnydxU
uwCJuhWKuktzyGd1wXtxyZ50wr5+we6CsgCUyCGtvUquw1KVsomiwJaWssWWs+6lxgG5wy63x0K3
tV/EyozLvZzDxfn485GioYB6ePQGAAD/APfwAA0A+/gF/wD+/////yH5BAALywYALAAAAADYAawB
Bwj/AG8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKMmNSfQHFWpWLNq3cry6kCqXrmK
HUu2LEOwX8FetWq2rdu3W9emtRoWrt27eHvKpWuQb96/gAPD9HuLLV22hesKXsy4sUbEYb0SLuy4
suWd+fIBNZc5MdqFAgQEDS2RH7+gpi+rFtj5VuvO4GITjA1utuxbtHPTxn174G7eun+7zkf1tWbI
aENTJX2LdIvnBJ+3iA79lvTr0q1XH5hdO/buzUWH/xfIHGHqW+dTB1hPcH2A9uxvuZ/vXn78gfXt
08+P/nR/geetxlhmBBaomXDA2VYbcMEtKNyDDfZmoIFVfUVZaBhmKBp43lE3nXfffQjeiCFup6GG
Cpmm4oqn8acffO/pt1+M/NU4430ssihgZRMq6NtvEC54UJA/CokQZwYeZqFcJ3rIXXckfnhQlE9K
mVCTDeUII3752RjjQV5y+WVCWu54WWs+MuhgbwgatBuCbfZVWGaRedaXOeVVKRB2e27HoUHZcfjn
leJBFKCYAtGX6H0uGlSfi42S6V9e1ghU6S2XmtljkQLp1imbvSHkaZoKTeiXWomRh6KeIIro53YI
8f/pJGirMlTmojTOhyuiCim65UK3ulWpNcRiaiyxmVo2YYGfrslbs0U2qGCoao463LLEVZhqeCcy
B+V01UUZooewtiort92mmKOKu9rn7ou4zgjjffHuN9C67LaF7LDJDruacaxpBq1sBIcaIbVxHiyk
cVbR+VlyAljFXHmBgmuxlSWWO2jGUk4sXp4GpedfgI++xx6kN44J77z2Ajjyy8IiayxBxVoqIJrT
FpwbqQklTG1CaCKXVqog93mdubMqtHG5hJY2Kcsm+9pur/RODezTZSWL6aWZyry1mW56GhzPQ+5M
9kF1TVbVWoqRC913Scd6dNwn2duy1WDq+qtl/hr/VGzfWoNd7eCcKmQttA3xhdZhdSrNJ9ysJnSu
0SvZLfXKCF2OOWP+9luz1n0H5Ysvt5Auk9lqnu0jnD8nBBlldrYt96uCMu1k7VaipLeMY0a6Jcoq
O9b5QPxy/TVQpic/eumms4Q66oiXLSSRiS9umFqIMTQ3iAUNGjmVlXupsu9Thym83zSjP3NPoyc/
0PLur/R8mwpHH2SD/vhzi/4KfQZ7Q9vbntHG1SHKDRByI9nd7urlK/PxTnN44ZoEt+Y5SwXuJs17
X/tIl0GVzA9hB0tQmhTGP4LkD3aKy55DAvgnjhWQVS4kiQIblbKojS8+NQzMvoi3Qx4e64I44aBA
/zY4xA0uDysnzB//SjiQE65tW4KLokRk5rWC9MtmobMJEeE3ROYZsXRS0V8SkygQMZbQiVJMI0X+
ZjwKYnFfE8RgFwnSPPcJEYxh3J8Slbi/gqBRjYCESODgaMFj/YSLYLzjETV4x6aMUYx6jOQencjE
QFpSIYSk4vG6lsWa2NGLRSzIJ53CR4OcUY+T7OMlV5mQzv3NZjSr2U64uEgvflGIHTwKGiFpyj2W
kZXAbKUbJVi8Kh7Pk7TkYPu6qDwNMmWMJpTkLiNJzWCysocU5OQmgRiTLXoTj7Z83xx16UdIlrKJ
v/xlJa15SX790JDu/BwGldnIcIJTebmMCKO+dP8yy8HngcGrVx/zt54k6so9/CvoA/OmKBuJaZ8z
7B1E9/nPhTqKXuLjJ0b72VCK3uhdi8JclwKqFa/JspDx5EkzwRlKg9DTIhQNadVC+q6ZXpRLkFTo
CQvqD4Tqr6DsUeJMhxrTomrUaiPlEk1lKtGLSjRXShVpP50a1aWC1F3As6pY3FlIlLqSm90cJzPp
WEtlwjRXOIxa5hxKtXL+tD5CDcBbFQpUuZ6zIERN61WxelQZxWuvU1WqTfE60sAKtrBqJaxeq3pV
jqIVqlnLZhwzOUtxLvOI8ZtjPSeSVr0OdoYLqZpBffrW/emqp4ldJ2P/ylfCgrSzjwVsYpnKEL3/
HfSGfvVrXiFr1Y3m1rYk3QocJwg4sCYkASkxKx4vq9myXsSxNb1bY6Wr1Z3yNq2oje4CH1qy1lbN
sR7t7ndnq13fQdewtL0tQL3bVMZOVb17JctJjxnHhyQAuSfB7FiNmMH+spSziNXqQ1d709/alaKo
natcq0nUAsP3sNPVLXlbS+D4nnfC7xVv8GBb0d6qFb6D5UoPZTk8iNx3JZfFJSOLyFyMAHexTu1r
QjZKUEXVeFEKfmR2XcvjB9P2tZBFL4UFbOEgYzixnt1wbN3b1MWG+C2hM2ZD7otfFNOReSwmolif
G+D42ucX0a2tRhNcRifb9UW+5XGHk0pTo7b5/7p9hXGR37xUM/94zWmOqp3DHMFO2pfKLlnpcjG7
zP+eFc8d/YWifwHez3YUlXWta0Jhq1DFPjijTJ6zQOcFtbwVmHcEbvRsURbjUPM2ilQ+cUv6i8h6
1hEmi150RczZxFSa0IyoRCc7d32RVFd51YMOpVkVmU+UxDrWEymlL1Wp7DL+Ude8jvafUx1WZtZx
2IJuybGPLZElppOM3x6oOVUr7XIbxNeqlgkunSvKYqdk29vuNh//OG5vM/vZ5s63QND967Dyt5Gv
jgm84Q0RXJsR3Kpkdjr1zfBb8LvfM9kslg39koEPvCE6DrdbM95wcz8c4sjUMiJnYnGLM+Sc8/9O
OCqZSO6OB/PjIA9iImvJEZx1ZlMGUXRmFr0snqMJZ87eH4UClg8ltmaJy7oWgQbCLJwzXWABIwjQ
ny51qFd96USnetKH43KSwDwwNtfMz63+9J3D2+w7TzvZCzL2rAeMl1xnO9TbHve6R73qdz9I2A1C
d6xzfep273pHYB5zuOyd7gXReT7OvnjF/0LtYDZlZnB9cwLlb/LpnDriAUZ1olud83z3O9BHL3as
V17vaxc8RghfeMN/vvSdT/zjG39ss89+9raPfNUpX3rj/FHzcw9+3uvOrKun3vOxH/7fTQ/70Kue
I6wf0OuVDvhbOL72tFc8gXAv66fzcvKnBz7/hZwO+riXP/B4Nz/ZSb/85Q+9+s+PCOtbb5fDH58g
14917vW//dzfnX+n5w/Fl354x352x3kGiHp3l4BRZxyn53zxVxHzxyPTB38DkX8YyH+3t3+zZ0Lg
JzADmHwLOH0HCIJDJ4LGd37s54DNF4EaMX/0lxcIeH8XeHsayHgbmH0+13ljt3bAF3ugV357p4Ba
54PCR3wPKHcuKH8TqBoDaIGeh3Y66HM+N4VVuHk/qIRFWHlPSILKl3xcKHpdWHbUd35LeFwwGG0l
t4ZsGG9nuEowmG671oZ0SIdvGEhxGIOWVId8yIZ3iGp5aG59OIhr+IerkYdyqIaEuIgXZ4iN/4GI
iaiIjDiJ3OaIgQGJeshKlLiJlWiJdoGJmaiJnDiKisZO9VAPUgSKoSiKpEiKl4SKpygQsWgmquhy
rXiLuqdGsTiLqHiItWiLuHiLgHSKsyggqhiJ+haMwRhFsCiLt0CMlnGMyJiMyriMYFOMu9iLjCGN
q8hO1fiNAgKNsNiM28iN8feN6Lgj2PiMgsGN09hw6BiPl6GNvViMf+GO3chr8biPlkGPi4GPq1SK
F7GPBNmP5JgX+JiPjtGJYJaLDUGQEOmJNJGQCrkYkdd9DYlsDwGRHCmRMEGReyhrGWl9pSiQD8mR
HemRKkGRFckYIkmSAlGSJGmSCYGSNqmSJv/Bki15FD/wA7fQkxwhkCZZkhcZkw55EDaZlDhpEdfQ
lLdwDQehk2bhkz9JlUEJk0WZiyJ5lLKXlDe5lBHRlE4plgOhkzvJkz0JlB7RkDFpfTWoe91Xk145
l2DZEFDplE/5lNdglmdJFFbpk4CplgO5lW1ZmG7JlUg5l4pZlwtxl3m5lwkAmZDpjlOpllSZllZJ
EcgmlIUJl3CpEIoZmoj5F3GpE1A5EHjZlPe1l5MpjVMpEJcJm4GpEVkplIQ5mm8pmnQJGDJpmDdx
l8Cpl5HZmgBZFoL5k7BpEJkpEXE5lJ4Jkwuhm7pJmlrJE3j5lKuZaqwZma5ZmVVZlZgJnhX/8ZK5
aZRsyZagKZ3TmRdE6ZszcZp56XCqyZ2tSZyI6BaXmZlpORDHCRHtSZ5EaZtuiRDqqZ5wMZTW+Zhi
yZpiyZ2raZ9piJ/LqZ/hiREBmpWGSZM5V6AG6halWZo1sZ2+xqAP+otv8ZdAeZzLGRG9eYGHCZ0C
SqAcWqBmEW8g+p4POpkiqpokep93IZgp2p8WgaADqpEDGp0zyqEe6qI4MZwLqqM8GqU++qOxWaGD
2ZnO2Z5MKqNJOqNloaE1UaLZqZ0O6qQQ+nG4aZzICZiyuaITcZHomZEfiqRdmqRcMZI3QabzyaD1
qaNxeKN4EZhu+qZM2qJHCqj4V6d1uhV4/zqRI0qfDiqlDQqDbmgXbPqdV+mQcoqV6Jmeirqo+fZx
JCqZVOan80dwgMGmg/qmL9mpGOkQnxqrSqENDUGrLjF/pDqmkGhyBmGrIVmDBAEAwiqsWyqXBaoN
sYasi4as2tCszqpoztqs0Bqt0pqs1PoLyrqsy/qs2Eqtt+CrA+Gt39qs4eqs5Wquveqt5Bqu4yqu
vXqu4Gqr4EoR0Qqv6Nqu2sBv+Upl+9qU2nAN1Pqv/5pq+Rqw97Wt3BqvAjGvaRSnukes1kesaWqe
6pmt2JqsF3tsFpux0DpwG9uxIMuxF/ux81qyC8uuKKuwBcGw63qyKIsQvqqy3+qyFSGzNP9Lswmw
rwS7s9xZsKXas/x6XzpLZRirrch6swzbsO0prM15C8MKsU77tL8wrIr2tExbtVI7tVaLtVzbtWuY
rcxqtNv2sUU7th7LsWRLsrmYtDPbtgRBqzZ7sycbs2+rEPL6rurasvU6sy0rt277t7aqr0IbtP0q
sCO6lz47uKmmsRirrCYrigNxtd0HtRA7rFELAFqrtZibucfGtFSbuVcruZJbcmCLtiIbsvBGtqcr
tqirrYwrkGx7tysLuO86u3T7srX7ty4rr3SrsH2Lu0j7th+3rzqbuDmbsw06mcY7tGYrtknLtoDE
tQZBuQAgEJW7uZ67uZwba9m7aKH7uYP/6LgZ67jX2q3c6rpjW76om7bXurH4erss+74HEbBtK7t+
+7LxW79167swm7uAO3/Ee7wCbLBBy6/qO60Jq6z+mxP7cBRQG6zVa70RfL1cK7rYu7UWjLWjy4dh
27Hi+7Vl+7pmW7rNG8KlKbvxa7+zu8J8W7f967covL/q+sIu7LKKS3jLO8APl8MJcLaMq8A1rBMN
bBQPHLkRHLUSLMEVrL3du8Tee8EbXIcdPLKtm7omjL4/jMVavLrIFsO2C7wwzK5xW8P5q8Jwu8Bg
HK88i8MCfLwBLLjF28M+XLRAfL81sQ9DTMRHTKzUm8RR68SATLUZ7LWETLqm+8EmbLGq/5u26KvI
q7uxkEyzKjvG+buwY4y7MmvGtAu9NtvGN9zGcRzKn1zAA2zFj+y6YGwTeJwUVmvEluvH36u54Gu1
mDvI21vIhly2AYvA1brFvCytkIyw5But5lut5Xuve6u7JTvD5RrE/pvMljzJ6Aq9+DoP1uxwniy0
zrrG2Vy81NrNOXvMVezIdnzHefylnau9jBjFsZqSMUHNIjEPtzAPCUDPfMl6rgjPMYHH50wW28bO
fAjQbRiwBF3QBn3QCJ3QCr3QDN3QDv3QEB3REj3RFP275tzPY/HP6kyIAt3OKPnOISHP8zzS1nxf
9kzP9nzPvtaKdYwT/IzRYuHRMs2IUP8hz9dc0vVc0ildzyq9uMooxPzsoTM91INY0/vmayht0knd
0+DIwEHdFkQd1X2YETQ3EPRw1fRwC1md1SBx00ltzSgN1ifN1Ol4Ey8N03fKvRtdch0t1dLpEHb0
Sc3D1QSx1QJx1R0h1ibN0zid0jttlgWpyi+NFLTsn2pdh21NiB/wAYu22I3N2Isd2Y7t2I/9C5Id
2TO9EK12S3iN1XVt11tN1xfh1zmd02BNZXoN2O4sE2e9ykXxwEXsqbhscYk9iJRt2YytaJOd28dG
2b7N21KdEPAzbFlGD77Q2Vwd2nadEX2t12G916mG0wn5lTPR2mjtE7GNxNrdyp9Ly0//PMtMvNaK
nduSrduQDdyxVt7m7dYaqVzMdW13ndXHjddabdX1Td8SaNo8rdSpfdpLjY9eSRPWrccHcb0SXL2C
XMuxPMi2PIm//du4PXDqHeHsvWgBx2JYNt+hPXH1Hd93rdWibWKlPeKm/d86Ld3uuJj7POB6/LSu
vMcTfMHb28ScW9u2fd67bd6Xnd7Afdm3PdS+8AtBDkqL9N5kNTpYTddJDtrTxtdiPdb7XdpQnuKh
ueKtzRTX28d/DLrhPeMyjovqHebo/di3/ePsHeQWfm3tk9x3jeTGXRCebd8hrhDoNuV+/dwnrdNU
LpowYd3XPRRZDuNKzOVP7OWzvYli/w7h8DbhZh7V7SPkaS5szGPchXbcWk06yA3ico7fUflwX63U
SP3pfw2KHdoSfv7nPAHbgm7Eg07jrv7lt+zgmI3bit7b5H3rFT46Qs5fAonp8MPVytTZdf3hmm7f
nQ5zY53n+q2TSmrqfu7Arczq0r7gW6vBtmzjbfjjZe7jFL7ePj7mjo7m4i7flF465e7rc03f+L3c
BcF6T+7fI37iKE7qXroSp47qBG6sFb7vJYfmiqbrAA/ppajhhIbkk97hya3knI7N8/fcfP3w0T3q
iAiqKXHvUJHdicrvGg9vj35sRrTr/47kBu/mxq3wcM7pWZ2Hep7aTk7aqvipKmHxT/+B8bm58Ta/
6+Iu8AB/3EG+5pZu7ka04ca+7leNiU/+8F8t8RMP8yhx7/geFTcf9SD/77G2QWle8gP/6/Nt1aCt
8KrY19Ad8adN77J6Ek7/9E8h9Tb/6P7e8xa+61ft8/Qg5In05uDE5vR9X/SQAHuPiHre8qgtjZld
EmeP9k6h9msP6f8G6ZR+1ThP6b9A6W5eOu5AD+7gDgjvcH1f9F8P3Scu+ENN+Gdfo10q3ohvcW0f
8m8v5JDv9m2/TPJNOph/1Ziv1XzP931/jPIe1kpPqVFNEoX/2tFe4Edc8wW60Vmr1lmb/OGe+ryu
61Q/93CP1aPjDtVv+Rt++Xq//bn///VT/vLBLRKFb/g2oeWwmqQYzL1sPbXqf+Y4//4A3/qqD/mX
b/2X7wuVX//av/dFz/k9DRAJBA4kWFDgL4QJFS5k2NDhQ4gRF96iWNHiRYwZL9Lb15Ejx44hO2ok
WdLkSZQYAQCouPLWSpgUXb6ECQBhTZsJV0rk2fPmr5w/dT7MGRSoT6RJlSb0hbDpU6dNEdLzRc/q
U19VqdJz95Tqr6q33Al0V9YsvQRorRpk29btW7hL5c7lmdJuRasgQYoMedfv378zadJk2ZKl4JtB
dyamu9SmUchEhU5uXFluVrAKs27+RbUq1M1Wzbqb2nVsgrF5uZYVuBbua9ixLc+u/wyYJL1be/nq
Hmnb9++LOAsLlnm48C3GyWkrXUzZqELF0JdPlwhaKmbMmTdXBYu9KWlfpLmqdY36dNq0aGOvZ3+Q
+nukgJ05q+gMN+7cHvep1t8b+H/biCsuOOMqSgwn+JCCyTmHohsqQQgXgiqz7rADayvPuKowPKrK
Ugs189wRTT312jPxrQhTdMiv+W6Zbz56YMzto72s2k8kAHMM7DjDCByMIuVU5Kmoox5cKDIjhYTv
Ou2iosfJvCr8pauquvqQNRFT87C8E7ssSEkwEbKLPopedHFGZ/bLSyTe9tHxzZQE/LFHxIBS7M4w
hXpMuiIZTDLPyqyTqrsmE3qys/+vsPIFtfBOO4u11tLzctKBAAWzpBZdJFNTGOlbky811eQITlJL
klPAmRC0c0GdnktR1VUd7LPV5iydbcKovOssKu2y4iqBrNIT0SARV+OS0hNtvTSjTMs801P6PL3x
IzZDGrVUbN9UNiJXt1WWM0UHJfTJq7Iy67PNxjJroBHVOw/ZZL1VkaQWozUTP/tinK9aG6vN9t//
5G1QYIIHVTRXQ5vCkMpgPWxNXRBHGxZeEwme9yIy7bU3N0733S/fTz0CCWCSbbP45JPF3ZDQJqVa
bTsOs1wtS/NQO5Zi2FBOEaNme7Yq2pA8vlFU3Uo2+i6dk5Y3O1ydmqqptLa7Kq//0cgq9uoScZZN
aQgt2jhjTX8We58X7Ru63xuPVvskrtsG1DpeNasK2HQXXbRYd7PEcjWt13MbInl+kSfwpeqrL9oz
Z4zRxsX1CjXktSPX6G/K88RK7kWjVq9KvGke7de03u0bxcobIlxw1OMzE3HEz9Q3zY7S5Eh2ahl3
U3LJZyqd293pulwzYNlFK7xGjSURrbNAF310g6i75pfnn39v8MFRD7z603vS1NnDo7XKxdnJjt1x
f3EHTjgeNdKdOfThqxWibmft/aHtNrSbbmCRD/HRiEVDj/m4TOca0VuI9CxDvewJjnoISWBEEle2
1dlHghAkW+1E1Rfz/UZOJlmf/1zeR50PNgRWdppfTzYzkPu1ZivmMVZ6VBO6gSwPgJV6jwEHeMPZ
VI+BDMSeApNSL2eZiSKv69fPQKabkWXQNxtUCU6Kw6rFhDBIsSpKTQ4ERStScYpHcdWeStgTgwSL
LcWK2KOoNkPSxU1lSiHgAKGHEDfSBXvZux4CU8cTIXYsiGmSHQVtFyoMKhEwwlHfcTpIwijGj4QN
ekxzHNnIVgXpg158kCK/mBD2rEVmWqLZ/tDYPKcVKjs+ISAc3yi9OFamhzwkXAMj4gwxZWp1Zapg
BctGPmr5R5AaNE5MBHPIREpxi5Gs1SMXuUhhQgdJ8rukQih1Gk2qy1Gf/BLLCP/VtJ4Y8I3Qw2Ep
l1JHcLZSgTp0ZUNg+QuNlWlTt4RR7C7Im13+Z4O/HI6qssjIIyGomHhq3zG5FUxWNdOZyHKUNGVI
Tc1QiGWc4ckNo6dNU3oTKQk8XR13eL07SgSIQaSlmjyWL5ENDUfxXGL6BjQgY8YKfpDhJ0uJ2a1k
8uk5luwdAA9KzQTkqn4WWuNDbJhKHG5TLgtUSA8pWk5zJmSdQBQa2fioH7TxhaR3oWdGUuWSYEZy
pco8kD+zmtJ9Dkx+NK0cTs1KkIT26mChhIgbbXhKU8Y1KeSsKCvnqBRYCjFT4osdHz0WVVBNlao1
IQkhCRPQmL5POP6kYhUDuqr/LY6QMiU8a2WBJDe2Xqd+EXErHB+KSon6pJzitONSXoTOZ2mKr7B7
EahcezvBAowoZK1MTH1C2/lV9qwXWauEmNbThsQxlXAd7kTHSU7rXVSHSIGgmdzJ2qa+NpCxzRY+
X4VbiWC3rLo1K0Z8cQuDOe13CnWIQ7n51gNab5XK9eFymYta+jw3aNJ9LXVlK0LtJkWyAqUNd3er
EZhRiEls9WlQi1tcpSA3ueotKlKTipB6PZUvsKOvVO1bXf5mGJP+xSlKAswr4DKkm+f1bFCHmtw5
thKBDobIOVHbMQlXOLAXxpaGM8zh7pLku7xlKFOymRBUcvO8EDVuijGq3vWa//YXLhIJhWU8YxqT
ysbNxHGOS7JjLIM3s6Qk7jaJ/E2M1jUhYq5M0Jz8ZAtHGU5TpmyVO2yS726GItvRsjUbWuLQyrG9
GRUnbdCMZjVb1YkcNGR+JXICRCc6IYhWUaIZ3TY3v/kucQYvlsnb0Id6+cvfHDMPUcxipPz5yYFu
Yo9MdRzqPBohj1Y1hFh9AqVFWtIezgp4bY3lUSZl07QxaoRELWNS++ikh62nLxt5z8UOs9WLdnSz
V+3oZ0M72opeyKufzexfWFtIsp61XSi940qDW2elTbJlfj3qYA97nvU0DGQRiSdlw7ohr5Z3tuvN
aGrj+971xra9r31tbaeI2//UBEycv21rjIx7nPA5N7DTTWyTnpSex9xJSiPS7H3/W+P6xraql21v
aXtc3tKO0MAJDpwsl4TNEWm4w9ON1fQZduLGtLhPtN1qkfsb4BmvdsZzDnJ+v8fkJ1/byhvS8go/
/EdVlXihKQ7JYV585FNXSM6tzvOq+5znJKfO0IkuOaMrBOn0VTrTr8ru4jwdmTXv978DrnN/Xz3a
DJE7yNveda+fSB4CoZ5bdhn2sZP94cQ5e0yeSBO1N1ardHc2s6nt+IDT+/GQFznJP26ZvJto74NL
AOf33vmCTHXlgZeu0oGjIENH6PJJWf1cMt+ezXveLXun7pRJX1/T+wb1J2v/fU96v5TXdyn2sQf9
QGic4dvjPveAye49t9V4uvweKcGHvec5zxZ5UCT72bevQJPv2uWbLOxhov56+m6Qz/Od9ghU8xe/
D/7w/2X8Siq/+c8v++HTviIrjvL83g/l+LOL+VOR+rM//Pu86+s87buFwVnAQNud/wPAAGSbAUyQ
AhS+zrs+/mPA7eNADyS1v4lACZxAlatAvLtA8+M70Os7DeQ+DuxABwRBrhHBNCNBkzDB6UDB6ju/
DCSI7aMeBpzApKHBGrRBksDB2dBB9kDABFTBDNzAFwxCF3w4lCHCkTLCEkRC11NC4Uu/gmhAD4TB
/Ys/i7HC6cLCjNBCueDC/+rrwc0bCP37QClswA6cQtOTFzM8QzS8CDVUCjbUu+JDQAX8wYsAwz3c
ljzUpT3kwz4Eoz/UPPXLPzm0CDF0QTsMP1tJRNhaREZsRIh4RL1DoCdUvyCcwzosRUM0mmu4hVUc
oFLJE03cRE40EE98CFAExOGLxAWsQ0Nkv1IEGFesCFdsRSlTklicxYSrRYa4RS+5PwUsxFOMQjr8
xX+5IVa8RlYcxmL0tWNERotQxoFixmb0wQ/kvmmkw168RFIhxlYMRoqwxhpLkFiURWQEx18QR2QZ
vjncPxg0R18kmVW8RmK0iIDMRgyjjnmkR060xw3Dxx0cRF4sxxcEw1TMlv+AdEdtvEiDPMjZSEiF
XESGDEeHhA0mnMgNtMSJ1D511JF2HMaCdKiCxEaObAyP9EZaDEmRHMm2YD8gHMNepEYxBEiZxEZ2
FMaSKbOatEnkwMll1MnZ+8FzVMkppMiVLJWWdMmBDEZ3JBm68MiPPESmbAinNAgHpEiVPEtUlEpg
1EiBjEmNZEujkQuvVMqlDEuHGMsE4MefDMqzhEqAhMeLZEttfMfISQqv/Eo0tMuI0MmM+MdK7McY
tMh3fMuhpMyYVBufOEy6VEyJwEeS8EdzDEPRrEo4sUyBnEzBzCCJOEzExELOdMQ/LAlCrEigPBq4
3MqBnMyhNJ+HYE26rMv/11xMLjyJ0IxGfrRNlzxNrcxGwCSpozvMJVPK4PQJHfSL0DRJ0lxHo9zO
5STM3fy7hGDNfRATm5zOpKi/37hO3HEog7xMgtxKwUII8RzP6KxH8zzP1wtAmBTG5CzK75yq+SRP
+7xPPxw6EmzHjWzLt3RPAA1QAV1IAl1DbjNCwMxKggy0+aTPBwXLCJXQKkNDrGzJ94yyDNXQDXXN
Dm0MDlNKEd1OwEAAikAAGMWWEmUICE1RFbWsRdTK3IRPv5jRGIVRGSWVGp0IkMRRzOu2PbxNBrUL
Ib0FGRVSIH2TEjXRhDhSQJECKbBHNBIkLS0Z9vzP3xhSKdWRKl2R2PpS/4pQ01tg0yNUCC1tCC2d
0zhtjDqV0y1dCjqdU4i40+Xw086ECzpdD5TY01JxU4xAVL/YUzVVVJSYUUh90hjV0in1jSq1UoVI
UymoCDZ11E5ECEAF1TyljVC1jFJ1iFMFFEGVAkI9iU7dVDjx1DWFVduQ1TGF0hjNVSitVEs904cQ
rEad01mdVWEl1jzd04UI1TpdVjoVVT4VVWcdVWZ9VmRN1lFNCEaN1i2tVmTN1l/g1mN91m9t1mht
Cy0VCEYdCEMtCU9d1zal03eFVUblVHmF13j9Une114twVHzNV3tl1CjdUxil1Hk1Vlu9VIgA1nr9
0nfoV3p9V+RgVjzFU/+JhVNpDddxhdaMvdM4FVdrZQhqxdiMhVZxDdlxvdaOxViO3VaMNYhzTYA5
RVdWtdV9pVWLeFVijVeILdZghdhh9Vmc7dmazYh+rddE3dQ5lVGClYIopVcE4FmkpVVZvdSOSNip
KtqofYeGlYJ3GNYv/QVrsAaNtVZwrVhsvViSvda0PduRpdhmXVmNhVs/lVu1TdmPXVuxlFm91Vua
vVmbfdifFVqHDdyoBVyh3dm/rdl1HVyf9VuIHVimZdOALVyvldrErQiqxVQjjSc61drOvVdhtQZy
FV21Hdu7bVttrVhy3Vi0TVVlRduRZVSWtVi2BdRpDdeyvdaKgFlW5V3/dZ3Zy9UIfrVcwq1cw43a
xV3Yfy3WoT3axg1WeP1SyH1cXEXch8VZijiH7NXezJUIklrenu3aWwjbsB3fOCXdiQVZk6Vd9b1b
u8Xb9GXf2BVZ+W3b92Vb2k3Vka3ZveXdxnXVy8VewaVcoCVgx/1f523eoQ1a4lXTp6VcSF3a6yXe
W9DeCqaIfTiHc0BYB+JcYd1ahtVSrd1a0jXfLUXf9lVfsx1biVXd2YXfFJZfF65dlG3dun3h+33f
OE3gl/VfRW3XBqbgAX5eoxVgozVeBE5i60ViYZVexJXUBybiAoZVC9bgCtbgDS7SDt4lEb4Fz6VV
ENZSazBWsQ1bjz3Z/7cV2dyF3dW9XfpV4TTG35NF4zf2VtvF3YstWT492n79XYP9WaLVV38t3oKd
YjdtYkFm3gNeYCE2VEqFXMhN2neNYsKFV+214isOiSx2UO+NJ/EdYS+mCK0V5Xewhq4dY4QIW/PU
39lQur4lNSgm010d0kKVAguuiE3eYCzm5E7epa4dYVD+ZC8e5fEFW7At49dk5dqwC4JQolcOtCiV
5VnGVV4N5O21YE3eZV7u5Qz6ZfEVZXAO5vJNZfIVW85UZrq4C7Ywn2eG5WgGUlpmV3vF4grOYCze
5G3e4m4m5mGuCGCmiDFWZfJFUtrwi7f4TYB5512tXpSg5+y9Yl3uiP+IZs2kECRh5mdSFuUxHl9k
NmeCTmd1hg2EJpUyDdJq1ggrvmQNFomV9tX4MJ9f9udhjmmLKOWB/mjLMGj2GGk4iee/UOkLbumW
tud8rgvc+eZQjmliJmYxNmdVxunCCWkT4el4umVcjmhd1mbojGrJCWaZTupQflePdlaLLV2JQOe4
NeuHqNY+hV07VWtuRglkAWQ+budaPeJYDV6jSWnuzWCWvlTg1J6jDuuvpulhJduyVgq0Pt2zdmtU
heu5WOxMlWpkAWLAJRm7tovMhhNM5l589uuh9s3L8onI2dOuZVTxnVeyxWNtPduQ5dPV/dhuPWPT
ZV1yne3WpmO4ju3/bEVW0KVX5t1T3u3d4X7ZdC3uvwXi4I7eV0XkIHbuogVu6IVa6D4aq74Fe/5s
v57PT41rtRFhqJXi1Y5W+33h+U3r9J1hxrZt9IbflH3jsnbr9xYTBn7Y4b7vc+3h/Dbu3u3hRV5k
6NXZAEfk4s1ZAmfgIx7ikqHnLF5podbuuUxGoy7trPVi8CZe2YZt885hNYbs80bdGHZv+uXw8k7v
EX9hQGZc/t7b/f5d32Vx4hYIur5sBa/xBG9kJF7iAp5x687krG5wCE/KyfHubJnX+j7s/NVw3WZZ
cHVttTbb2JZjEWfhDa9yE6fyjJVu6I7ZF19x2X3xLo9xP07gHS9z/xtP8RsHXRXHa31Vm3ue6O3O
UAr81ZI5ch3/WvZt4dIt1de98vUGcRIvcbqVcieHcpb9b0AmiBX33R52cRhni3Ml8zM38zQvcMZ1
WqVlWkpG9JKR6CAv0ZSwWoAZ8CDOWfdVWRvGX/U+9fY+XUPH8kGvbdTV4ZQF8MJ99DAH8xbHdZft
3Tuv9Ek/3CGub0im9MjR5My9QpSg81F35EaG1z9340JP7CiXYw133TZm6zmW9hJnbDc24N82WEdf
dOHWdeLm8oIQ7j+2dGBn88Ed4PDOdFyt7rVJduUTwIbov5WTbAix67y7MHiu3niWVNyxd/iTPxu9
MKPj9wRp5+Czr/9oFvhI1dVjN/gRRJrJ7r599/AIcdeTKMB4mviFhtRpNh+Lv3i/yPjYgmpRT4nq
FKRKfVKFlvmKP3ll170TjSeWR1NmZkPzadqKmPiID/p6t/ki/I2cF6SdT/ief0TJeeeStggornmj
V0QOXfr6dHlxPJpIndKBr+aTptGq18PExPqsl2vGLBmvJ3oyBXqqH3tvNHudHkuSAXqoH/mgD3ux
H3urL/udn3u8zMt/IflYnvmi5/u+R1Go/ovAX+c38XqSv4i113s4QXyyV/yPZvzGb4vHh3yp19W1
73TLb00hxGnN33y/+w+7B/2ZH3rRH/24lwtv8IZfoH3a78PTR33/uFB9gZf6to94yjdTo5fRjkCA
xDdC2a99hJj95UfC3Nf91/ANn25aKZXmhSYZmyf+KA2J4A/Anph921f+hLj92xf/8Xv+E9FggTgH
h7QN4GfoWR54oxl+469/6p9FngD/2i//8dd/8geIXwIHEixo8CDChAoXMiR46yHEiBIhJqho8SLG
jBfPVeR4zqPGkCJHkixpEuPElBER3GLJ8uHLlitV0qxpE+K+nDp38uzp8yfQoDkREN2HYChPlzeX
Mm3qtOZCbwOlSv1F1RvWqlaxWm3o9SvYsAWfngwJ0uNHjglAlm3r9q1IpzFlrnRJlOjTvDiF8u3r
1+fRuzsF452r//cw4qYKqW7tWjVr18aOtYqtbDksWbhs1Vpk2/Ej3NCi2zK1C1OiUsOJb/5t7frn
XcJHecpUvfo27ltRtXK9+njq78vChy/M/Pas57XK0a7lPPo5dJQ3lUKMbTt3zdfatyONnbQ29vC3
EV6VTDlrcIG9KRNvf9m427QdP6sFbZ+z8+j6n5dO3RKveAlkxx2Bf83WXXf/XScegzeRpx57W503
GVcERegehsXB15Z9zW0032b47TdidHI1mFJFEhW4IlDW6UTYUC8BeCKNNpFXXmO9OSZhZJFdmCGQ
BuUVWn333eehhx2CRiKTotVoU4q3SLcXi1UmNduBgwXm35NdSv+0G2QQBvfYehYGeaaQG8aXHH4i
ftZZk3E66WVEFj0koJRSRmkln0Zl6d2fdAlKZ5cGscfYhWWa1yOajf4yJJHzdZbWkkYuh1Z+cmpq
EqF46vmpnbf0OeqVWMZY2IKEivcgZIxNph6FO+boaJCQaoZRpZPCudlGmW76a1x0XiQRnqRW+aeW
Run0n6qqGqqjq4iiZx5viNKaoa2i8SpfRpjKtySw4Z4krIDlqmgsi0UJpqy6M6babHgFQfvsrMC9
au+17mV7q5K9IqecpN+KO3BJDXqap56eJoDusS6yOxiz78I73mLoVSsvhDsqmq9w+z73rYgC50cp
wASbHFKA5pr/W+fCDFt5IKBDwSTxxKtZOG+s1uK7aHoci+VxpOA6l5xGbp58NMq44akwqC27TKCp
fkod4z7V1VyjmetpLW20FUro9Y8+a+iUftzCudylbQaMNNvBrhZluaGSKo88OtW9orrdwVw1dVc3
mLW1Fv82OJkV6iz2V0BHCiLI9SGZNrhtSz7lYUvnKbeVd+dEd92c481uUcr6KZMvvvjNIMbTwsqj
rIMvujriDOk1YpFqNzeyt49Pvnuos6dop0V8ek735g0/HHpgt5iufOkPNX+6zTeDLX2OYfo2FaOx
K+T7fkeCfKmkuybpK+9sV54wwpnvo/nwnRe/3d6Bscs888/T/w/9YWbKCrvqh3r9tfZkp7jRmO1x
ISrS7cqnQI2c72Arcl/xOuc+CGpOO6HzU+map0ENQsR0y8OfU+TVKuBY73+r4w0AA3gQ7tEuV7hy
HNrEF7kFKnA1LILg+iq4vh0Sj3hQG4ov9pFB5d1PIhn8IAiXor+caYx1WZMM7FTokAF+DETjKxml
SBa5GdKQd4ipkgR5uJO7hdFKpRPiEOmXxojYL4k2whgAVfe6nplQilMkm5yOpCskdSiBH+oiIA/W
lAJ5boeb66HdctinMzKSiERsoweR6Eaa0Et/0zsPjlyVPRVSMTrMwZ33jObCQAISIu94x4AIaTcc
TtCQrSQQI/+DWDVJrnGNk4QK4KJlr8JpTJNQlGInPSnDLI6PTWcj5QLfkYBTLvOUt0DlM89FIPYV
8pA59KEidbgdWQ6Rg84z4jebVYFxkrMCDyknOs2ZTnQu0Rvp1Eo5GUPOg6xznQWZ5y/YKZB0juWc
64QIOROWAHIOdJwZIShJ1ok2cuKHoOW8CEPz81CLILQi6YSoQS2a0YJWgKIbRaYym1mRU0JzIjec
YBg5V0EfVvM1skQjNzMYDw+qMZyOpFNA/anOcVJyn+O8Gezm6c6fSgWdWSFn2PL504Hgk6lLVWoF
nBpVqA4kIjm9RU4rqtGOanWrJUFoOdPCUIA59KEf6epWN1r/UbCqta0d9SpcQUrSFKGSpM58JirB
GEFFupKvhvyra4IoWEbOFCLxiMcjl9dGQl3Vn1jlqUqkCivfYEWoVsEnO4v6VIQ0laoEaSpmN7tU
iVw1qx/lKGoxgtaDurUjYxWrQdGpltWi06Nv1epaM8rWt8YVkCGla12j6Uxo5nWahaQmNhGpQ236
hZtCnKkvEFvY0h2WJoulUWNJC9mUSNZwjcFnb5DKT88mpLOdJW9op3pHq27XtLz1KlpXq1q3znac
bCnrRGlbW9TGV7exfShuT0tDkgo3uHbFa13fQUhsHlK51hQjYP/yUudGN7rflKn9PijJE2WXveaM
rE/Vm7EQ/wdnnuKtQGU3S0/Rqhi0Sz2vStwL0NPil7XvDUluK+ARgsqHoWXliH65etv/3ji1ZS1o
ans74ImUVCWnFJ4rj8tSvjK3uTkZ7GBvcdjDWpjLNLVplzo843o+RLKp86w8f2ricQ5VxCsWcT1d
rF520oTMUupqjedbZBvH9RwIBY2P7ZtnPfOXyHwuNJIDvOfJSYTAd43IXZ+8DwVzR6V7FSP7/NpS
vhz2yhWGbjdnymUuPwSxHWRse8v52A9zN8SWdPVk1xzVoZKXsyx2s5zvqeqUlNa/Nx60bb96UYx2
1D74BbKQ98zWQhc5x0SmsYDb5mRTPoS4jVYwSSvdPuWytP+MPayyT+Kxj04fMZZCDCdio5vuSKoq
uwEVc5lhDUekuurEKG7zeQ1i3hY/Nd+PEnNjgc3sQ49E4DyGrY53G+S0GprQDOcotBdtsmk3GtJ4
hXROJK0dRDa4J6wcI7jDTe6ZPhfUoC63lm9qyxq5m6cd5sUteMGLX/DC31UB71bs3RV9lvfWup6z
ih+1al5vd9VJhq+A5Uvs3h78rEQG9EQdDvFkE7y2+w22+WoSXFMOt8nDnfSkKb1xCnL8J1MOOU+2
LO5yH1HUFn77Bh950ycF3OVFj/lDZD5zf3+XqJclqpyD/vPP8hvoU/3pmInO6oEvvb8Sx3rUK4rs
hLs12s7/HvJ7Fc3bqDP6JsOtdoIRHGnRa/w1y2Xux9/XF3GPW9ysLzl1N9hN5U13w17q9U4/DHOY
533mtX4WUqF681u7Wd8+J7zhQ6zTGEM2yTlW8tFxXHmsG/mjnKc+xCGf9NZKPVyICX3oqS2q0j8Q
095eJdp70mmdeDmIbkcj805e4ZQrtt3p1Ok/Yx5i3/v+zZatdTktxL7h2osFIFTB26pdHcNVHoAp
FMFl3wJunvUtnG1lngJSn+N5n15s3cWNHnGBXbaVXyuh1DWVoF+sH+uB2pXBlJZRV2FNVwseEQjJ
XETwHg3OnMzRXA7a0XsEEzL9oKbcRoKFX7V1oNhl3A1d/5OUbRsO/cX6VdiViVrVPNJ0VdenmRr+
7F4N6t0O4iDN8WAPqgkQjmEQ5oZdHRiCFeGTid0Rblw2bZvqxSGnuR4KChEaPde5xd/zQFepYeEM
2iBE2GAO9l//gaFXsBAZJiKThAcaFuHFURulkZ8qfZsEpZRfrZ7r5YTaidqWaaLb1U/staAfno4g
AiIX6uBA7OAXGmJCVI4ivuJ+nMijgR74cR22SeJ2tA+EKWH6pR37jdtOCNb7bZCo0c/JZSHvxRwX
7h7MCYQX8h8rjo0YwiI1jouXnKEaUhvY6UQbll8i9RWDneD6aSIwkpwmtt0xzt8LjiK8JCMNbmHe
6SAhpv9iIUajQCBiNeYjScALcUWatYXdNs4Nppnga9BhJqYgyUFXMRJR+2EhO9aMO+KdREKEQQzi
KdrjPfqgPlbj1fjjGdoVQAbkqFhigWQiMIZbhblg8yhkCxoWKTLjROpdIA6iM65iPbIiPm6kTvpN
SfXk54kKNz5Nn6Rg63WiJ0LXlcWgyambdD1ks7gjM3KhMn4hDtLkKkZjTuokR+IPGoZfcYVdNwpl
Sb5eUZbjlq0kOi6kdNkfq5ET7wUUF7rlIMbZOPneeJ2Xv+Waq9Hl0CUeXRacAnJekP2a5k2gYWqE
YBqmoi2d9F2eqtHlriXe8q1G1wkX6O0ELopllZAlSnb/mdpFRFOiWlvWJcy5Ze/JpSru3VLpnWfJ
2uAZX/Lt5VNNhIwZXVnsVgVKoLLh2fM5X+RZ3m/qZlwtJmI+W0b0pWROZnIioFP0oweKpGZaCVFu
4jhuopZVV3WlXM3UZsu5JVV+oXeamU/9Ht+lF6zhk+JNptI9oMIJp40xINP5GvfpGfcRZ/U9HmN6
SofVHaspJ3PmxdZlG7ZFJ6mYJDmeZFFm53V+5lqyZQLmnnbJJT1C1Q6WZ+HZWlSxk3nWGTqN2Ulk
4LANpm42XOPtl4hiXvTdJ/Q1Jm3eHXK+KHL+5waWFIG6DFma5OtR54KmnKkpKE7ZXc1VQJAKKXs9
VkHk/+A8IangkeeSrplStaaLRmh/rmd+BtuRpejUJZvADZyvFaeQIV2zdSmWemmL9qdywijuPUmN
MsxB7oRReqJLltqOOiV22d1jrZpMumWSsuaQUqWFxhmGPqmaFaCd4R9F/OUDginjEdp/LaqVGtrC
1VgGahSl7mMCRmh6jlmhymhirKmxdFqOHmhZOuRa9ujVdGiHBuK71aVNUqh4vuar/tygyplN7NqK
eimfLVukNiDVMap/YamukigGXuCweFiZZuqZxmiUYoenFqgniuqzuh6PZmdo0inLldOQ8pQW2hM0
UigO/imswuasjtZ/qhr2AWaY9uqwORxugqh8Aifmbf+pYx7nsWIqsqJpqpmpeDTrp3aiv7YeOWqn
YWHnqT4mtuadaeLpMjZVn75ZuMpqhgZgskrpfCbU9vXq1OGqirrriO5mx6ao5hXrvSanvSZrmp4I
vzorObbpOBbltMbpxOxatuYpaTYsa6KmasJZxBJg8UmV4Y2mvmqqbVJpleImwzHTMq2o0cLV5Wls
xh4dbxpUrUYpAvJnyXZJyn4qgvorHVZNjzaltf4o0CqjzGkrwqrXt/5U/xmgayKfQtAqyWKqit6m
mKKWMr3DQ30kBaJWPCBU3yqm00Lg3BJb0BrryBquyeYrymat1gIsqDpuqUpE2IZZvm4rZO2ed9ql
2hb/4l1eaM8Znof9U0A9aj2hK3GeUjmdodIq5jjFQwK4bsiyZ2He2IzdRJzB6NV2Z9wyK+MWKEJ2
LeTO6S1NxA2+Y/HKoypeJce44q/cLdKOFPT+VtI+b0i4LkZY70VgbxkOL7z0LroYJApKK4/C7PAu
YyBOZbdapdgwL8GElOrOVdJCb0lY72G9bv26rvaSCPdejffa6Ca66ZaRL/dC5UzqhjOq7006CvuK
i/vG70X81t3Kb/XWr/1WsP3mb4nsr9/0r1g+riZepwZLhEwabyCm4nciTlZqCtJKr0VEsATD7wRT
5wXjbyyG8OlwcAcfpcDaMDwqI9lW5TMmMJoscLhI/y8E21X8zhX1WoTaWfCWVQQGjwYPQw8Oe+oU
q8Q7+nAXJu/ypjCTRPDzNrBIOS9GgHH2XjAU3+8ZU/BbXDH+VLEVu3FK8AIA5J0BW6SjAAAArBce
jQQ9JMAf/zEgtwUAtLDzwq8LV0QhJ3IzmXFGNHEFUycAsHHBiEcd1/Et6DGNYPJDcHJNePJheC8A
7MMoN+st6bEmd7JNAIAW5uAetwcqH8QrV5XvFLIiY4Qg04Mu6zIgC3JGFLItJ4AtMxMAQHAjCzMx
y28wI/Hz0q8zP7H1TvIkc8pEgHJEWDNNXHImP4knY3M1X7Ne5EQp+8Q4V0k578QonzOBnjJEePM3
U/9kkMxyQcgz8wazRfAyLw9yL+tzSATzMDPzSNnVMC/yGKuuBL8uE9OwM9vvNLtNSrizU2gzRONG
Ny/FRC+FOAOFOhfIRpOyR5vyJFU0JqNyJ2vySOuxQOxxLKN0SrO0Sqe0QbwyKss0SmdyKku0SXMy
KiuyHgszTwPAH890LgtzUN8yMPf0TBs1KivxUs+0MtnyUgc0KrvuTvf0TytyPBQy9pK0TZ/0TX/1
SHe1TqdyNYO1KmvzNqc1V6P1TINzV7fzTZ+1WMM1WZd0OuuxOOM1Kes1Kuf1XetEX+81Xw92R9co
O7fzNlc0YlPkS8s0TM+ySkN2TMP0Y9+jTtu0Kqv/9Z0YtUUAdSEXNVAr8i4TtU/7NDB3djMVMzAT
81wV8zIt8juotk8jcjFTdVYfFlQrtDSXtiK7dWIjNjZLNHCv8mIndlhrNjjHdWbLNXP/dlhf9mUj
NmCT80dXdzpntEeP83VntHZz8GHLNVkr9kz/wkuT92OPtzzLMmWb9x4vN1ojdx0Lc1VXBD14tiDb
t2gHMjDXt2nztj/HNoCf0jDPNjILuGkv82sntVYv+E+f9jQvd1r/dnPP9XtfMkRHt4Q7t1qTNIaL
9HCfNXR/eITb9HQDdl9r90x/dCnf9YlPN4r373dnuEknd5k1NmWX90Ck92Sb92MXd4Vn9mlzNiAH
/3l/izZ927dnF7l/I7Nrl/ZTp/ZIBXls2/Mi1++C27ZW97diu3eE/zh4+7g3d3iXa3iIc7mI/zhb
jzmGP8ReW7eLl3iJr3h1Y3d284ReZ+13H/eEozV787hjS7Y867hj9ziXR/dILzlQBzV/K3poLzov
JzppEzlsq3ZsJy1BV/prh5Rsa/pv2XJW+/Rtmzb+SnNW+7aan/lwr3mY+/iIGzqqQziaf7hwNzco
czecb7eby3md2zqvo7NPZEV0njJXG/dYs/VK+/mNuzRBpPexp3SrK7dml3ZSyzd/yzdUd/Zo1/ej
F7V8F3ilU/qTd/qmm/aUN3ln67FtS3uD3zYor/81tJ+0Xc86sWfzNUP7mMf7s9e1V9O1e3t5W9O1
ifv1ig+8rhc8X8c5i//6TmCFUMqxEuULEZNEINN3Pu/yUN+zSLzvIU9vErPwGD8yNNuvnGrn5Dq8
33gyHHvDPqj8yqs8wz+Nyb+RAkf8RVx8PtM3zu9zIPuyLz9wCwc0MwV9x5NxAyNxQov8105Eyce8
qgw7m1cxw7P8wsM804NYoyDGSfD8zlu8zucyz2d8QB+0MT8wDIdx/H4m+aJ91XMvHOuE1Ee91DPM
2k/EzHtxzlN8xU88P4fEzf+8IYe9MQc9I499M0muwJqqj879JLV9y8f9y1O9HLvzQuh44tA8Lg//
8s3r8cRXfM3rfEgYceCLVEG7MOirhCY3KG4rflPUNdb2RGFHJ9y7fNQ3vA17eXGr93pjhl7Ysx9j
/n3zsy4Ldbbj/ZJH7wpT706Xu1UbsmX6tqlNMmJdNF1LP72veWJc9Krzu11rP2u4vp0HdlB0d2uA
v3WjMrBDfu0XN93vOI/rvt1nBOfb8sR/Ns73/fyPhBg3sj//vGt7HYEBxC2BtwAMHFhQIEKDCw8y
dPjQoUKIEx9KrBhRYUaCDTVSvLUPZMh9AESSFHkSpUmUK0+qNAkAgLd93kh6ozlTJkudO1l69Pnz
J0KhG2EWLDr06C+lSov+SsoU5lKoAJxmhHnw/yrBorcSAOhaNEHYo2HJgqVnlt5ZsmHPwizrFqzX
d2DnFn2X4O7dsHPxisWrFcA7wQLrCs2a8OpRrBYtAl68MSFRookRW2V8eOtWg5o1b24Y2XPox4Bd
Fi2ZEmZI06tBmh7peqXLmSNl0szJE3duoLt5LxwquSPwW0ylUiVO3LjT4kwjB28usGt0r36nR2fr
Na3X6mTbTgeQVjq9suPl8g0sNm/erurnCn53SzDC+BwNWrMGwNqt+/RBj9Yo8T+k+JNsIqNE+4xA
hoKzarPG6GttJNVaSi1CCFWqMELZZEvpNJmOyg1E3TxyZyASe9vNwBQhW1HF41xMjqqjklMOMv+j
FCNtI+qsk268BMTDrquzxPPRxyGDlNG6H8nLSzvB1tMrPrzem6tBmKak8rn88tsoP/y6JM3ByTIT
zcDnmlPssCrL7A/BNX1T880DcdRQwtheY63ODCXc8LQOb2rtthAFFQkid0w0iMRDT6RIRRX7a1G5
pWCUNFKpmKtxxUcJIm9H7Xr0EcjvsEuLVFI9LXLHTjvlCz29noQPPvk0eo9FLu2zb8FML2KMzFr/
w6hXABUcMM5i2cz0vz3zbAlDCPMkiU5nl5U2JmkHvXYfhgw1VKBtSzRR0UUj+mzNXwtysdJJJ5UU
tHJ95bS6U1P9DtQghxTvXlGJ1A48VeNtD73/sAgaDFaF2ouPVi4l2/LLLm/FzznPfm3T1wGFpfji
YC+Kc2JkOVLW2tOipRZDaJe98NlpsQ1RW25vSXRbcF0Wd2NMtar43EqhSneqpdptF7O44O1xrLWK
yo47UI/+0S2lvTuVrvPaWyyrwAYqzOrH9tNPvy7ddQzOyvwbE+gaq06zMsMM861qjBgcDWw4N/xQ
NdjspjC1l/A+mW7X6F75WkQTffnQmLv1lubEHbKU8cYtFXetyCWPfLt7i8Q3aSONTHrytZzMC74r
Q5+SMFhLd2+gLblevWvVVe9a8dhln703wG2/HXdsESV88JcXgpl22R0f/vFFOz/+q+2IRPVy/83X
IhX54013j1bRR084dNMX0lKgW7W8FXauwQ+e/PJlzx399NUP6dsSCXeIW+DN7434+iGPHv/nicQc
PHxL7X950bsawUg3QO0ZxHrd697ruOcQ763udfOT4AQhsj4LXhBw8Xuf+3zHu24djoI+qd/w7pc/
E+7PefzjDgCl95AEFhB12Stg6urDQBoyrIEKDOEOefgRDP4QiDyZGcwQB8IhdpB8aEPQQEbYuBKe
8IRqYcsUUUjFyXkEdaS7UhanZCUahu+BqWOgfRhCRjmJi1fjUpwSjxW7IL4RjiFRVPyAB673zbF8
jYnYcBz3FJ+hKEepgiL+gMQ/zAUwcr0ZjP98SkeY+WxvRfeByZaK4jqEfO9haApKZ4yVoCUuSo+f
DNNueIKyOJ5yUDKbme9ipsH2hSt2oWxjHx0HykHeMjr+e969Nkez+RDQkcfyWvfwk5D9OAxXBcFh
ffZYMwelcViJk6Wu3LgTU6ISm7rx1uBcqa0P9o5mnElTZjrTlOVYqpyUeU6K4CKWpiWPck2Llzu1
AxZ6ZgcsaRMb2ywDmIQVZp+ru2RHKKkfiNWQhpbpp8bO1Da14WifbgIbJ8nZtrgRSJwUupOFNlqn
l7RGo7DJ5gWRyMrDgbNwhZMmsTTVHEoVJypOIVaAEuIvTklunjyaV1kA6CkzJShMbpqmRLX/pJGG
SfJLBPHe9yj204y5y1wec+rNGNqrdQKrYgkp2WtCVqGPimykQSyiSldZRyOu9KdNFVNMGRcjTWLs
IP4ayzvfYk9Vfepp6gQqmPgp1Gh6MnWXJA3DlCqjhyTVVzfSZ1aFgxmOvLWqamXnXw2LED1xtKsm
M9mdoHXNsObOHfsY6xzlB0LThpOltXJp/ST6VMjoFLZG247y/FJb2/p0rx0rll93qysyCpZrXiJm
YLlHRu/lKqi9jSpiGNtG3bYUqK4NzWWpa0rNVrdun12fy1Z5R8F9q7RoTC1yX/o4qGpMR+ndKV7T
O9uyMPa8bNLtUH0bGTPeAQB3wO8dcBWa/2MuFblLhOZ5hdUxiTYXurxNMGSwy6c+efVk2lVfaE16
x226D4+wPBFngNURc0oqnQtFE9GgJk+60vO2KPYK0PSqtof2NaKX+Y0Ot5JMgei3KHdoXXC4l6uL
UhNNHLbRjF/8TIuyDWdoA9DZQrq37D64NHnTqIRBO8Te0bGDZe3hREj4RFziEq09BB9/+StG/eoX
fEw1rvi23OaVUhnOqcSy4UxqR5S6eSG19PKXTyhNNs5Pzbcgs/h0bA001+eGa8bzontTkDg/Ojeh
VSV3t6nBKzNaIE40Hp8HiWmamTE/Zxb0QMocakNvz4yeVjVQIN3qnVTau3U+KwcZzbg9c/+6hXhO
6aKWeuYzG1q/hC71Agmb6lUfeyGuVvZKMnxhmVkYnIsu3okIabROz2+U4MVycidCRvyOGdiCDjYE
IUhYN/85KDt0NIc45FncTHnZqdzdvMN1RFVLxZbV/pQAKfjM71IaISSKmETGl99R+1p1/D01gnL4
yUZ7pJkQiXgSfcisdmPL3fEGkWlVqW1kG+SPG86fe3OtbjUikYgEGdzEYafj/KI52GSGeesMiui/
ghLiOG+j+dZtcWZlXCdA17gQsVxnO9s7lkwWG5NzllERXwWeUU/ebO25Yl05XblCjmiMC+KOEHdd
4InRujKPomNBl52/NWangfr7mN8UOaP/ql26ajnpGMVymMVcV+iE8LY3vX307yXpO+CHrhPeRdvC
EnTt2+GL4LjmFLYk74rc3+QcA1P1uUbhFtgB4PVugV3lmrKRMXElamXud+EQIzslC9pUAU3Vx6K3
mFVzm1rYHwTKW93snr7qcw0JPd4ev3CsPyi7xf8sQGSbjJo6Ndd9W/31chPw7BVapqN4PVGV9V3A
5e4opeJY0IbGj8uTCRP8BjewV6fP2lvssQGbybCSbfw4lV+u3NPp77uH91YxW/ieFP+Vvum0jI+h
oq+12sRA1Et5II/u1G+q4OoBqU+UNi9+Ok/g1u8gHkbmCgLH9uvsjkmpiGlr4Mr7ZI+l/zzMZihL
Ah8lvoDq/pRF/5qFq1Km//wPJX6n+IoO2wrw9iKQKG7KpsSC9ujL8lYQZw4C+wRuWzov4DqPcLru
CElvvwrN4O5jCs/PS+7jdaapAXvQ4WKvCE1wr4zQ/lIG/3SP3UimBm2QULxp1xCPduLOZoZMxB4L
IabOnVCMnpZsnNzma6imufDu+jDvKgxFsV6m/YRqK84M7SRpkooJMR4GqxbkyNbGudTqx27Gw4JG
7BSK7kSKs0CK8EIxynyuo4Av+B6C0j5u534Cingj29qMjojIjk6qiHyCe74N5saN2DBpBHeQFVmN
DVMxGH0iFiHChHTO0zSMu4yum4DCjP+qkMwM7YHSDLGAsRgpYhiHLhvNB3+68US4CY+Ir6R2Q8d2
canEx9zAsc22cRjZkXaQBx53I9pSjpVIS8M8QkvOsdDKaHzmcYLcUSBBghWP8eaQ8YpgkdtU7dm6
C3G6S1wa6B8bDiCDZyAvsg2R7cD8LRZzShkxkZqCxyBPiiTDS3YmMoIqUnEwkiVv8OMW8iAVhCzC
DCT7bSIuzc5Q7hlV0if8wA9u4SfnpyWH8v9U7a0qqrHwblPIBuv4KaDsThD7EO44cZ3QrR7LitLy
kScpwidnhyi/cidWbblY0Atb8A8dL8CMTAyhasZu0ug8KMu2kje6MnHA0i5xQyzXDwz/548MI2vB
Rm+3IMssfeLZ7nHOtFIugfInF1Mxg9In7hIyN84oLeYPB/PywhCwuo9FpAsCx9At5Scn4TAxF4Ix
B8InT9MhIlM1BSUv06oy+bIs/VIzM2Y2+9LhbDHlHhIxRxM1BYIuT3M1gzNwxHJM0imxOHFtikyU
jqxBkgyaJirE5Kstf+fKaBEiR5M06bIxT9MnhdM7RQQ7w/OMZKcZcVA8H0Ik/CAkgHMf1PM739Pw
zlM8R1JxrlM8WUI98zM/27M74dM/T0I+A1RAA3In+rM9QcJAD/Q/FzRbBtRBH/REBqU72dM9FZRB
FxRCM1RDk019JpQ9L/Q/N1REA/SC//ZzPxEURDF0RFdUJeMIOD80RUOURWc0GCWsQmOUQWlURxcN
R3v00XYUSAnUR4f0R4PUSFeSSJPU1Y6USYVRSZ9U2ZpUSjkUSquUGKcUSK1US20QS1l0S7/0Hbv0
QcGUTN1RTM9z4wiy4sqUTbXrTLcycLKFIAG0TesUld4UHG+n4gZiTg3CTv80iPAU2dTHTwu1QfmU
j34BUBc1dwSVR0lqTxv0UDPtI/jIhxSVUTNVdxw1hOJIIOT0U9lnHxR1OEK1UkUCUzVVVcOSU8kn
rPhUTUHVUn+BiUh1VW8VPFtVXOBsT32IiSoV5IZDTpViVEc1VXEVV3WVN1oNUdtQTf9ptUGVolJJ
lVhB4liRdVWVdSI0DlhlNSRodVpPlVJttVirFVuTVVvX1P8iVVSFFVr5FFyNFV4x1VzPNVM5lSWB
VV/lNV6zhVbfVVH79VvtNVuxVDXFtVAt1Vd71Vi/tV4JFlCPdDU/dWHVtFvxTVxH9VSP9Voh9nbO
ASTOAWThk0ZJlk7llCDB9V0lNdP+9STo1WNxZ2RFVkUzFEQTNmVRlmLHVV4p1lphNmY/FmRFdmT3
gWaFc0CHdF911lSjVWP9lVQ/wmXL9WGDFkSItmiNNmS/Mzyt9FQnlVi/1l8ttVjH1lqNdSmsdlBm
1miHlm2zNjJ5kk19NlyHNVEPlWX/M61hz3bo7MAOLpRmA/doiXZrJzZPF1Vd3RVqpdVQNTZeU7Vq
H+1v98Fv/3ZyQeIagnNo25ZtOXdzDXdQs3VO8ZZuW9ZWYZVeAzZg4+1yQ+JvrwF2RSJz7XJm3bZt
tVYk4NYuPc1eTTXPNFZYd1Zvf1d1yxbSJtdykddvZ3d2VfNot1ZwPzc401VA/7VUIeJfVdZ6rxfZ
/FYg7GAgKhd2BWJ8r+FBz8Eg0FcgRPYW1Fd9qRd+e2h7gUJ7f7V7FwJ8v9d8b6F8F2J/zxN937d9
0zeA1zd+DziEspd7GWJ+wbUbwReCbyF/+Zd/83d/YXd8BZR9B3gg2NeDBRiBQ7h811RWYRe4ftlx
giOYf82XhcmXhf9XPj24g99XhkXYhkfYgSlVh0m4ZbMRglVYgsu3hTEYhgGYaGf4iI/4hpd4dnJ4
e3lYe3mYFSv3h8XXDi54hQeiiMVTgDfYi0GYicM4dqS4y4pxgiW4cr/3iin4grc4hjlYidt3g8WY
jsUlh7GXce/449LYe9GYfF34f92Yiw24gOO4jg/5RO7YgaU1j1H4h9EYglvYhTfUfQsYkS85cRhZ
gbcyhc/Yf1eUhjFZlGmGca9Xj+exikdZlUW4lEt5lV9ZXAICADs=

------=_NextPart_000_000E_01C71164.211A9320--



Received: from 190-49-206-128.speedy.com.ar (190-49-206-128.speedy.com.ar [190.49.206.128] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAPD88nw037138 for <[e-mail]>; Sat, 25 Nov 2006 06:08:12 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001101c71092$c153e940$80ce31be@bauhauspc>
From: "Microsoft" <[e-mail]>
To: [e-mail]
Subject: code checkins project
Date: 	Sat, 25 Nov 2006 10:08:09 -0300
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C71079.9C06B140"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000D_01C71079.9C06B140
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000E_01C71079.9C06B140"


------=_NextPart_001_000E_01C71079.9C06B140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Can get on Product Index pagewhat of Rssrss provides convenient way =
syndicate from variety sources including of news stories updates. =
Product of Index pagewhat Rssrss provides convenient a way syndicate =
from am variety sources a including news stories updates. That provided =
format see latest click or is select be updated once hours how recently =
related then or contains article! Click or of select be updated once =
hours how recently related then. Will publish xml of file list newly =
published organized by icon in indicates available Generally view as? So =
people a take advantage some form in client software read monitor let a =
gather any that. Provide daily lists am of all new content products a =
you are interested in if already. Generally view as a files through =
Internet Explorer a However am viewing pressing in every few minutes not =
most of efficient your time. Of all new am content products you or are =
interested in if of already using.
Homesite am Mapsearch for Help and a Support of Homeselect Knowledge =
Base Search Supportkb Switch to Advanced Page Toolsprint this? Simple =
Homesite Mapsearch for Help and of Support of Homeselect is Knowledge =
Base Search. Rssget the or feedshow do use Microsoft site now providing =
am an feed its is kb. Depending works There many a different clients am =
typically used am Windows Feedreader is Bandit which? Way syndicate from =
variety sources am including news stories updates or web a even source =
code checkins or project we will in. As files of through Internet =
Explorer However or viewing pressing every few minutes not most =
efficient your time so people take! Format see latest click or select be =
updated is once hours how recently related then? Way syndicate from =
variety sources am including news stories updates or web a even source =
code checkins or project we will in.
Code of checkins am project of we will publish xml file list of newly =
published organized by icon. Site now in providing an feed its kb in =
articles of feeds provide am daily lists of a all! Way syndicate from =
variety sources including news stories updates web. Efficient your time =
so people take advantage some form client software read! How recently =
related a then contains article title direct am link or method am =
aggregator! Get on am Product am Index in pagewhat or Rssrss provides or =
convenient way syndicate from a variety sources or including in news =
stories am updates is! Address appear viewer receive in email depending =
works There many different a clients?
>From am variety sources including news stories updates web even source =
code checkins project we will of publish xml file. Product of Index =
pagewhat Rssrss provides convenient a way syndicate from am variety =
sources a including news stories updates. An feed am its kb articles =
feeds of provide daily lists of all new or content products you is are =
interested. Software a read a monitor is let gather any that provided =
format see latest of click or select be updated once of hours how.
Or select be updated in once hours how or recently related then contains =
article. Software a read a monitor is let gather any that provided =
format see latest of click or select be updated once of hours how. Many =
a different clients typically used Windows Feedreader Bandit which build =
yourself following Msdn Library These supported features vary.
------=_NextPart_001_000E_01C71079.9C06B140
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000c01c71092$c153e940$80ce31be@bauhauspc" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can get on Product Index pagewhat of =
Rssrss=20
provides convenient way syndicate from variety sources including of news =
stories=20
updates. Product of Index pagewhat Rssrss provides convenient a way =
syndicate=20
from am variety sources a including news stories updates. That provided =
format=20
see latest click or is select be updated once hours how recently related =
then or=20
contains article! Click or of select be updated once hours how recently =
related=20
then. Will publish xml of file list newly published organized by icon in =

indicates available Generally view as? So people a take advantage some =
form in=20
client software read monitor let a gather any that. Provide daily lists =
am of=20
all new content products a you are interested in if already. Generally =
view as a=20
files through Internet Explorer a However am viewing pressing in every =
few=20
minutes not most of efficient your time. Of all new am content products =
you or=20
are interested in if of already using.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Homesite am Mapsearch for Help and a =
Support of=20
Homeselect Knowledge Base Search Supportkb Switch to Advanced Page =
Toolsprint=20
this? Simple Homesite Mapsearch for Help and of Support of Homeselect is =

Knowledge Base Search. Rssget the or feedshow do use Microsoft site now=20
providing am an feed its is kb. Depending works There many a different =
clients=20
am typically used am Windows Feedreader is Bandit which? Way syndicate =
from=20
variety sources am including news stories updates or web a even source =
code=20
checkins or project we will in. As files of through Internet Explorer =
However or=20
viewing pressing every few minutes not most efficient your time so =
people take!=20
Format see latest click or select be updated is once hours how recently =
related=20
then? Way syndicate from variety sources am including news stories =
updates or=20
web a even source code checkins or project we will in.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Code of checkins am project of we will =
publish xml=20
file list of newly published organized by icon. Site now in providing an =
feed=20
its kb in articles of feeds provide am daily lists of a all! Way =
syndicate from=20
variety sources including news stories updates web. Efficient your time =
so=20
people take advantage some form client software read! How recently =
related a=20
then contains article title direct am link or method am aggregator! Get =
on am=20
Product am Index in pagewhat or Rssrss provides or convenient way =
syndicate from=20
a variety sources or including in news stories am updates is! Address =
appear=20
viewer receive in email depending works There many different a=20
clients?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From am variety sources including news =
stories=20
updates web even source code checkins project we will of publish xml =
file.=20
Product of Index pagewhat Rssrss provides convenient a way syndicate =
from am=20
variety sources a including news stories updates. An feed am its kb =
articles=20
feeds of provide daily lists of all new or content products you is are=20
interested. Software a read a monitor is let gather any that provided =
format see=20
latest of click or select be updated once of hours how.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or select be updated in once hours how =
or recently=20
related then contains article. Software a read a monitor is let gather =
any that=20
provided format see latest of click or select be updated once of hours =
how. Many=20
a different clients typically used Windows Feedreader Bandit which build =

yourself following Msdn Library These supported features=20
vary.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000E_01C71079.9C06B140--

------=_NextPart_000_000D_01C71079.9C06B140
Content-Type: image/gif;
	name="Windows.gif"
Content-Transfer-Encoding: base64
Content-ID: <000c01c71092$c153e940$80ce31be@bauhauspc>

R0lGODlhpAGwAYf2AAAAAIEFAACFDYByDgQLhIAChQCFhLq4vbfVupnK/ksjCWIpAIYRBaQrCrcb
AOYpBgA+ABY2AEEzAGBNBXExDJxLBMo5BdFKAABUCS5kADJeAFpiAHRcAJFYAcpcBNhSAAByABiB
DT94BmB0AIF7DZmMBcx7ANWJAQWaACOuAUOfAGicAICoApSgAM2lBteUAA7AABnEBz64AG2zB33A
AKbLAM23AOfNAADuABLlAD3kAF3aBofrC6vhAbfVDuHXCgIHTRsKPkoAPWgAN4QBR6cAP8QLNOEB
PwAcNxQkMUMjO2gUPHEpOqMhOs4mRdMXTQA/PB9ENEA2OGVOTHFNOJ5DRbU/R9RONwBWOBFgQjNa
OGRbRYBWA5tuS8ZnQNpWPgB5QhqESzRyTG6FQoaERaF9TLtyNuiIRACdNSiZS0OeNW6qTX+TRKOY
QbynQuegNADGMSa4OD3ISWm5NHq3Sq7NSLnMO+yzQAnjSSvXNDnTTVPqNYfYManjRsHoOefbOAAA
dBcBjEQDd1UMen4JhpoKgrkAiuUIjAkoiSslh0cYemEfeoYSda4SdM0XiugoewA/giYzjUU/iGk5
e4c5iKE/e7wzht80iQ5hgSpqhkJeeV5RdHZjeZVrg8FTf9dcgQ5xhCuFiEODhWOHe4F4eKB/jMSM
deSFhAKVgxGke0GZel2Vf3GpfpGogLOoiueXeADHfiq5fEizeVzMjIi2fp/FjsC3e+jNjA3gehne
fU3ti1/adnTccaLdfbbjd9TdggUIuicFuDcAzVIFyIgAs6UKts4Cv+QAxAAewyoRvEwovl0SuHUR
zKEewMkasdsctwA/tBg+vTFJymRHuo0xwaxEtLE7uNs7sgBexydUt0dutGRYxXxay61UvMJjxutR
wQCDvhOFxT+Ay16JsYt+upZ4vslxy9h2sweRvR2jxTetxFigsX+tzKibuMuqxtyWxQC6tiXJwEK+
uVHOtojOtZO6zvfu+pirsXqAc/MOAAjwAPb/BQAE+/0A/wD+8/Lw/yH5BAD//zEALAAAAACkAbAB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqFChso8eF9kKKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3NnyY8VdPoMKHUq0qNGjSJMqXcq0qdOnUKNKlcqzqtWrWLPa5KK1q9evYGtO
HUu2rNmzaNOGXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDIbUgXsy4sePDAK6CTPkP
b2XKJi+j1FyXc+bPmO96Lpm2NEMATFWOlrt65OrWImG/lW3vtWrLqk3rRoha6W3Rv0nSpt12OOjN
uCnvXl6w98bH0KNLn14yss7JIvPlc508+/bYx0MK/xDAHfjI8eWFk+THL33n9e1jM58/0HlRe9pD
5sef7x+4/yP9B06AANoj4IECGligSAkqiGCCle0nYX+foWePheP908KGI23YQocc2uPhiB6KGKJI
JZpIYomVYUjehQLYxl5IM9rD3j8B5DhSjgHsqKM9PAbJI5A/ijQkkUIOWVmNTPJD35P/2GfRStpV
aeV2DYaUpYNaPthglmB6ueCVV6Y03plokpdiSGuqyOaKKa4pJ5wnpplmSuzlqWd7R4bUJ5J+Jnlk
n4QKWuSee1JXl3VekUnggF0WGCakJk3K4IIoOcqSnSB++GaIc3pqUqgonogSpywh6mOPgf5YKKsm
vf9qZJEoqaqoXYy+RMhM+z0aqaQLbllSglsKm+l3L1nY6aegnthmSSW2+eypL75U46qtulrknyUN
+Se3tcZ367gnaRrpr5BamhKCJBlbkrkqofops56SmhKJJE1bkrwq2dpqtqzKmpKQJIFbkr/knvRG
YCCRaWVlXw4ILKViYsruo17Wxp/DFJIGo50ZumniyCKrCGenppq8osYgnykjonlWNmiP2sJqKK0E
ryqoxjDHDOXPRPGn33faXUasxEhT6mDGvrZbscYTDm2bi+LFOC+HWJtKZ8rTbv1hiy+6+DKN8d34
r45o43xzwbQCTPCSZccNlSVAp+ZSrxgD+GDT62L/ei5LeLekLMpZj7isSl2nTG1M1+qcdpDYqgSu
wSY1nvDlKu2996VKV3qg051/tfLKpYp6Er6Hr5Ukkt+23S3kkWMuO3YnGc3u5n+jdDHntQfnHmij
oz7vvYanrl5oxyPH+uOtw3pSzrM6/ztpdVfvUXCfo8u350lvP33y36dXvMrGQ1t4+eAhH376rEev
tvRs0/x+78pZbz9DOWW/NOi6B+t/6KILlelKZj5R2YstsGtf7F5ns225TnYQnIn+9Ieui6lrabjL
yvjGRy/UHdBrXklgAt0GO4EtD3oRjA7tjjNBYVWse017ocbUxz76max0AwThs+K0tRkqD3zHESG3
/24mP+nNzFA+rN39lkgR39HFOB6j4VygCMQo2mU4TMxiQVLIxS568YkKceIUxZjE8DyRjFR8T/20
qMUvuvGNcIyjHOdIxzra8Y6PAYAe95grnZQBLivEoyCzwsYo8XGPTBTFFgfJSEIW8pEIceCsTig/
H1HyeSMkks4AFSi3xWp1hXJfA4XovFdJcpIn/GQpHWhCQO0slEhUGyf/pcnaWA8GkHTIKTX5QG11
UnINtKQwYbnK1zEQladM5vxqWUtZyjJ+kVPmKisJzV9ak5m8XOaPcsnNgdQsYNRkYDAHBj/3DXNm
2MSkODvZtrQh84jhZGcxHxg/cLrTkiX0FvzyKf/MazIvW7/sJkPMsBtgAjSbmNylOhNaTAXek5zr
RCg+x5nPh8pzoiupaDyz+c10OrSh/iyiPcHZyL/885utc5zr6OnLX7oTpeV8ZSUtylFivtSI8YTp
J9tH05v6FHI37Sc2f9rMcpb0Lhq95iaVasyPWrOlmWTqSkeazqBOEqgbtWgv9ylSiV61qzQt6jND
WtOiHrUvSfXoQdUqVJ26lKpNFepbe0pNZV4Uo6hkW1N92c66knSqax3qPEnK1rOyBSRp3epbMxrM
Z7bUlSDNa17RudjKQnWcZhXsXglrV7MClpZKvaxlWSVQ+7FkrDKdKApVqlmsRs+T4tTnawEm2bD/
srKv7zPYZ5cnWXkSjJVyVaBHH2vY4hr3uIYNJHKXu5nSVo+50I3uXpQr3c4497rzqe506YNL7HJT
u3rxrnhNA968jPe8Z8FbfuD1LmQ5zDvuRZZJyjS0+La3TOay0saq1N6RqFe+/pVv4OrbK/4Obb8G
3g9665YLJv5XaAe+L4C9c+D1TjjAFN5YhjFMkgLbF8IgjnCGB7zhEIt4QvYlsYIXzGKjqOTBHj7W
fFO8HRKLuMIJnvCAYxzhBxOYwzbW741NbOGoqfjC5XXjQmD84Rk7Gcc2HnKRiabjKm84alc2MHyR
vN8SE7nGOTZxhFtMZqcwWcjlsnKA+atlDlPY/8Jifi+8sNxjKneYy1gOnJ7BLLQph9mWZQ70c1LC
5JbsGMn6PfSdIYxmL/cZwHRmtJ3d3F9JLxrDKOZzpZMsxyULWNNUgjSi+axoTFO51ED+9I0zvedj
CbnVpv5xlEMi6Fq7OM9cvrSjcSxmENO5zUP29Yd57ONgrxrUWT4xnCudkULYusyA0/KsCRxpNwN7
zTzWsK5LPGUENznEQVZ1ftHsYTDTd9qctocH0s3udrv73dotBLwzE8Z5u+XZ+J6Ivc+qx337+98i
6bcKAG6TfBt8KXo8uFoIzu8+MvzhSe43xFPi8IlbfLkVhzcCLl7ePir84yDPZcIXyfGSNzLjJv9P
uSBRHvKWm0UaLoeIlGJO85rb/ObebQbOp6LyWwGj51XZudCHTvSiGx3aQE/6II/O9Ka3XBVOj7rU
p071Wiv96nesuta3zvWue/0hWA/7HL9O9q2L/ewp+cblih6Asru96kl4u9zRTve62/3ueM/7X7yg
9777/e+AD7zgE0bdwQPdenFAiOG/og2WNL6Oj6d1IUNySMRE3h6Xb7w2Ns/5kHB+857/POhHInrN
kyTynw996i+v+tF3vvUiEb1JSo/5zNde9rOP/es9z3ubpL71u//96UlPfNqzXvO41/3rbY95+fxs
JRK3R/QJw3zes775xI/9Sa6P/e7b/vrHH77/97Nffe2fvvzcN3/3x79+mZS//e9f//dz3/v09976
6m9/dKY/kspTno/SJ3GHxCj+N4D/d4AIqBKoN37glxLp94DsJ37Zl3/kVxKmR4H6d4Hy54D3p32y
F3zLV3sSmH/xZ34LeILbF4H0h3/wtxgLwX8JKID9tkcBGIDWAYMzKIM1uIM8yIEs2HwNiBIQmHsL
aIFGOIHi14Dxp4QkKIQY+HhQiIIeyH1B2IH2B4UemIVEiIFIaHpUCGhQohIwyIM6uIM5GHAOd4YI
CIDux4JR+HvJ14GkF4claHwWKHxYOHxxqHydl4cleH9BmIc/CIQpOIJ/mITY94a7J397iHuj/3eE
0zGG0VeGOjiJN1h5lvh/Y+h4DCiHK6h/nviDXziC9CeIWjiEE6iBoAiIR2iKyLd6hdiFSOiEUgiB
RRiLWkiKg/GCFZeJZniJZBgZmeiLbBgTGniB9teEn1h8XFiFhWiKoriMnciFrIiIG+iMs7iB1KiH
p5iCtyiN0Nh8dQN9BCiM5biGwDiMl2iOaNiO/Ydy3OiGkGiFuKh+36iKchh+KuiK82iFh4h+JsiM
uTiP+qiM00iIoFiEo1iFBVkYk+F/NkiM6QiRBuiLPXiRPmiPjih8oXh7fSiBcPiBIbl8j4iHpGiH
upeNXbiIt0d+ISiELJmBi/h+qPeBeuiInv9YfY83jmCxiS/hkxeXjEcllH5ReDMBlCyBlA5YekzZ
lE75lFAZlVI5lVRZlVZ5lViZlVq5lVypDY/EE0ophvBYckSJR5fHk4uXlmqJd2OJXEaZdXIXlz3Z
lu64loYHEgZ4lHSZgDrxAR8gEn4JmH/pl4QZmIEpmPZQmIQJhnHZmAYxfWFpEpGJkTdxmIn5lyFh
mJhJEofZmZvpfI5JdmIpmcAYkea4jjSoiRY5mSnhmZ55mSdRmIhpl8bFi6SJjqdZg6mphr9YlzXh
mpipmbG5mJn5mZIXmsgpEKZZjhJ5gOrojqzpEpopnJepmCNhmdUpm8kpmj+JmtA5ke3YnFX/IZvZ
WZzDaZnYSZucJoPiyZvuWZo8QZ7yaZyCiZ70qZ7MBZnn+J3OeY7iSZkyMZ+vWRIDmp74yUh4CZE9
SImnmZqmWZfR2ZqfaZ/WiZ3TqZ3biZyjOXYZGpoUt5cQ1KFDdwQa8aF1JKJcd6AqOhv1tnQo+nUr
GqNr8ZaQwRMvCqMfWozVAaJy0Uc6qprsyaO3IqTqaZt8aRiY2H8UJ31K2mIzd6NRoY67iZpU+o5r
IYxKGnAocYNNGhVNMBVPCqVDsaG6qZ8XuZpEahNYqqVsKpmUl6VwlKYympf8x5sxKKc6AZlwShIE
uKdvhKeDZ6RWaqV1mpdwsZt+2qa5EhmB/xamYvoRZOqbZcqngGoVXLqobtqmTCoYJNAVlQp4giqp
dhqMkvoVl5qlmKqpjCpojvqoRoGDPlqlD1qqWkGRDtqnlCpxttaqrjolEfSpMhqs0CesxFqs0gEL
mEOjcNSrBXEITWes0Bqt0kodEdoXwDqthKcQA9iW1QqkDgqWe5lx1sGsbxed3TqoWBGWCqqr5Fp2
6lqAbFiGt/mOU1qv9iqrOLipSjqu7Up2hkqppaqGPjmwuXmnpLqgaaivb7qp/Rp13fmgFvmdQEmw
CBue+/mucHqt2OoYKySJFwuvExurAGim/QmvLXGvq9qwTPewO2qxEguPJDupEMqOLZuUC/+rqRv7
RYLqsZr4i/u5pYu6jhVrgwcbs3x6swursl43q6QZr7Yaqct5piCrn/CJht+atEqbopaqsUCbE2OZ
tVoLrl5xrke7RmArdGxBtmJ5tTnbtm4LcMp6VGe7c9o1twr3tngbE/96EhGLEyfwt4ArEn/rFYA7
uBfXCGjXtzVrFYYbEobbuFnxuCeQt3aEpvdapsVoqGMIuYJbuJ7ruIULuqEruoFLEpILup1rD6e7
EgrQuq7rupQ7GIrbmyXbnzNrEpybuqrbuLw7uaU7uL1bEqsbvKs7E697vAoQu3ixt/xpu84LoKb7
uai7uyNBvJOLusEbvaObvaOrvOQyqnT/6p/iS6sqMbzXO73Ua726W73nC7zte73d671DCp//+Z4H
+xLmy76pq77ou77uq7vxK7/U+rE9S6rPSbRH2r/567+++77Uu7vny8APXLoPLMAuqK1B661WK7M+
e6sZ57kRLL2d+7sODMEUPMIUDMLra7c3N5d3kbsx0bgsbHB0obZVAcP4G8EW3BbM2xMtehUKChci
TBOQy3RtJ3QDOMNKvMRM3JhekQg7HMVSbHJNXMVoMcXYasXe9Qxvh8VaocNeHMbzFhVfoMUsvAFm
nMZqvMZIJ8bFysZwLBDg4GJrSQxufMd0hAt4HHjTsMd+/McjwQSAPMiEHMdStweGnMiK/7zIjNzI
TUzIKurIklwRkHygk3zJEVHJmvy9mwxGUodImDx5KFEE4MW2d/xz9gAKnezHcbvKb1RQrsxxFsAS
7+BGUiAFi3fLeKfLIcHL9uDLLQHMInHLxCzMMmHMw4zLx1zMyJzMVtHMM1HMO8HMz6zMJwHNLMHM
vIzNNsHN0eHL4GzNwSzOzjzN5JwT3lzOfpHOLhHOVYHN7HzN5wxe20zMvazM1HzP9WzPI2HM9azP
++zOv8zPAw3Q+CzNJOHP+UzNCy3N2mzQ9wzQyUzQCF0SAR3OBC3P8kzRDn3R1nzREJ3PA43MJI3L
Dw3RI83R/KzLJ53S8QxIChHQEe3O//9c0BY9zwgtzALN0gc90x9t0s2s0D1t0zSN0T4tzjzt085c
0wl90D0dzyVdzvY81UA91Ekd0UT901l90ybB00Pdz1Wt1E090mJd0NZT0B2N1Wh9ziXd0Eyt1v+s
0Da91iihzUAt1V991XB912A913vt112d13ydzTit1VtN11it1zVd1Clh12Ut14w91pFt1s+V0yt9
0hUd1YGtzga92Bw913rN1WOd2E6d1uoc2lnt0aWt0aA92Cuh2Ycd14bt1Zbd2ast2pI92wyt1ZDN
21p91pb91qIN22At3MS91ZON26dt1WyN1L492ks9z5yN19HdzoVN3cit24BN2o3d3Jv/PdmK7dqP
Pdi6DNyXzdRXLdxqXdxf/deILdvVzdp9zd2t7dfJ/d7kzdeafd/b/dc7zdz1jdix/dzbHdWRTdXx
3dcHXt66QdjzjdIpXdxNvdukfd7/feHqPdGm3dpV/daYTc4yDeEVzd4B3tB1ndkozt0tDdIT7dIa
vtlcjeHhjdIz7tLSLRo/7G4vfTk7zuO4fNbz1uPkIuRD/uPPFeQ33kVEPh35DMuxnHLI8ORSPuX+
1srKTeVfEWhXIdQSDhNQ3d6vPeLyveQPvs43LtJbDubonOTsxuUt7uVsLt9hPt1XjhNkvhZBbdhd
cedyflxurdIZLdER7uI03tF57uJi/77eax3c6c3o0DziD/3nPw3oYV3ojg7dE47RXq3hlb7otN3p
kl7aHY5cmy7gQr3a4A3g/e3Zig7YpY7e+U3W/T3o9f3Z463PZD3jl93qq67bYb3Pua7qwX7XRa3q
Gd5Iuq7n0Z3UqU7fJ+7sMJ7gsF7ryo7dyd3sA07t2I3py03frJ7t3h7r/83ryE7ht57bzB7pH/7i
MK7p0X7uzS7Qoz3twOzYjp3t9q7ddV7ixt7v7i3b5n7YtB5HCxHv1Y7v3l3n+53wZW7qgq3tvL7u
ZV3g153duJ3hsP3tGi/srC7X0B7RIAfsC57w8A3vwj7f3w7d0w7xDq/cje7a2N7xBP8u8Cof6+C+
8f/+1DOP8yBn4/ye6B4v0mhO1YeO64nO6Zzu3Ppd261e76Iu3kKf4gO+63td2JRu7f7O4TfP9FqP
0FpuWHy+5lhOPQlhR2Fv53Fe5W18VGcfzUeP5aFcFEywxKssyGkZ90Ix90y8yXY/Es0w9nXX93dU
C+wWA1iXvC8h+IB/d4q/+IFvyR6RAZOs93jvyKsgyY7fd5W/+Zzf+Z7/+aDf+Zk/+qSfrNd1Ck5X
Co4MXj2goiVQ+m68K7CvvKGP97Nfd2Q2x7WPb1cBQLf/+8Af/DFqt+bQyGCw+455BVfQYsIfGMp/
Bc2Pdc+fQgpXA8gvEM+//KUV/Yv/Mf3cn3Te//09B/3TYeWr3KHin3cVsP7sXwEh0f7w7/7xD/8o
Ef8j0f73v/4mMf/zTxLsDxD27FUgSFDgwIIGDy5MmPBgwYUIK0iMSLFixIYKH2oUCNHhxokVP3bk
mJGhRogkQ1q82NLlS5gxZc6kWdPmzYj/dO7k+U8lSJYuU75MObQhUKIlObI0qnDoyZVFl3pcGrSl
VJRTDR79KXJk05BgkTJV2NPsWbRp1a5l29YtT2Nv5c6la3VrVa8rryoN+xUvVMCBLT7FK9buXb1d
k0bNmpiqYYx+++o1jDUwXcyZNW/m3BktzKeRE18MLTqvRMuLBStODbqx4p+lS59m/611okmrKi3L
dooY8WqcwYUPJ168+NrZsPeOBk6RqnLayiv/NU3W8e/qqmtfv30XuvPJuXd3D5rS83n06dVnds1c
N+6xpKs+Bu8+fkau1qmjlmyat32kCLOtvtwIpK+657D7zjgGG3TwQQbBUlCo/f4brDsAyxtQupGy
ay22+fZ7b0OgpCrQxAMFOyq/BSF08UUYYwwtRQoBtBCr5O4jMbnZBMTQvxAzJBC4A+ELzCQL3+Mv
uxibdPLJmJAbMMf4oiuxMRF99PCvHvk67Ecml4NtRgVZHGvFIEHyjTuB1nPzTTjjNEtDMLWr8Ugs
M9RSxd6ao/NL8US88DXAJGTO0P8x+WJsPzkbdfTRtGQSi8oWAyRUt/aIJPRDPhe1dDRK9TuzN8q6
LHXTNKELFUpWW3VwLTVxNLLAvPbE1E5Al+TPPvy4kwzNWRPN81LU5Dv12MKI7eosDCB19ln0XJV2
WmqrtfZabLPVdltuu/X2W5mAAHdccss191x009UWVnXbdZdcaOOV19F367X3Xpvm1TdafPv191+A
AxZ4YIILNvhghBNWeOGD2GX4YYiN23dizjLdLsxeDQ3PT8gew+/PjG1ksUNTfYXKx1ONTTnWlVvM
L+Nde91SyIgf7JhEK7ui8cRLd8Zz45laezlZ2zzVz2jReiZVR/c8NpZJMpGumUH/WFOLmkucJ6TV
6qXFHJSmPYc+9FegB1VWSZ29TJvmQEFVe9SQKJYbs5g8rhNtK3nEuVCHOE36bK/5/qjkRbWuz+9d
QXR741XbzntHQad2MMG7EbL86Sqr1Js87CglOXLHn+O5b2BPE93Uy33mmu0kV4s6c8mFq9q7CX3+
U+WPn6ad1NxvHbHDzOmznfIhBS/eeNWzIino1x+Hedm5o3dLUtJfRx32XHHXlVY1/cTceMtRL/3G
Pq//rfVgA4fd1otjl1gtJc3s3XWs2VxuTey7zz/MIdNfPXTeEW1Ejhtg3VLlvJm1SXoL1Ez8Pic1
YamPe8ACHMv215wUmWltijNd/56+Vzqorep6COyUAhl4wp5QD0slxJhSslcr/U2wSKC7HaJytsFP
xeqDg3ub7+50Q6bxz33vi1T7NhKZnPGwclSCjAwZR8OvCWtsU8yhFL9XLByezGJAjCALUfjFnTBP
as1bH1fIuENkgVBx86tVD4H3HZS5cYRYLKBXDPgxJvbQOkPkYx/9+Md1wQ+Qg2QYGA0pSEIm8mBo
OURatHDIRylSkpOkZCUteUlMZlKTmywYAKoFAE+WK5Q3GWWMSjktT4YSlDAq5Slb4kp7pfJJawHl
KgUCy4XAEpektGVEdknKg/xyJrK8pS9fMspTChOYynTJLplZTGKyMpcyaaVwnP/5IFzKslEwQeYw
m5TNBj2zJt2kCTm/aU3jyFKcwalmTNZ5zGZi85X2eGdwaDlNVdqylvS8pT7pucpe7pOfqqxIPvV5
UIKmEqDIRCg//2nQZBZzoA99aEIFGsyF+pOiuWxoQP2ZzIZWtJ8GheZFL+rLkKpToiSdqEiDOVKM
EnSitWRoL2EqUJymdKExHSlLT2qPbcLzpdF0qESH6tCEDtWcLy1qNLupUZkeFZpSLSpSp2pOlRq1
qUfVpVSjetVpMrWlY8XnVoWJ1X+uVKsDjWo1n8rVqca1qu00Jlpl6lSzitVV9+TqUiHaUovu86xG
xatc79rTvBq2rCq161bF+lb/m/aUmHcV7FzDOlai0hSzaY0nYfM62cp6lqp4DWhi5+rX0FZ0siVN
rVNhuS+3YtSykFVrRIX6Vs+SM6mKxe1sZ+rY32q1sf28rFo3m9nLkvaxmyXuRYb7W+WKlrdwPa5e
iftc2+52uSDNiZy4ydTYjhaw07WuVRV7Xu1Gl7nLXW9WLZvb4uI2vWSlq3ppK9x5wpe9vfWraVdr
X+cCt7Djra5cy2stzbKWp39dLVI1utbWnratxk0wQGEKXNHm87PWtfBVI7vRw4qUqCB+sIZFbNYP
6xWnyY1pZk/KUhDLVrcv9ihiObti8+LYwRttlU4W8RlOBjlg9aRWUIV8ZIL9/xTJS2Zyk538ZCj3
kchVNVeK02XlKdfLyqzK8rscVlcOC5XK50RnQZVc0AMfE6FbDrAx16pmNrsTw8NRJjh5emEeA5Oj
cZ6zO21a01Cmp8xjFnOXXeXKdU55qYTuLIup6SBDt1nMHN2ueHFC10dfGrxo5XJtKVphly7YpJEV
bE3vDOoEh/rCLzazqUOb0y3X98Ow3nOof4pojypXnR0eNUhdTeqQOprKtj11rzGN51KD9q/5FfCD
+JrUxvZXv++db1nBet5p19q0/u3zsNFcaTdzW9u9RTF5yRrgY29b2Ayl9Dz5i9IJ11fc4W6qQCHF
2Paut9k0bWdg17xhbKu7rv+alfe76S3hgn8bxWdma2q5/VSC69LhiKYqvVMNYXgDGN0EZ7HBi9vs
e0N33xh+rpu1O233Dljg1laxeBdNcekKvOTutrjLKy5bcL+Z3B/HeHxt/mYDv7fA3g53NwX9XU/D
V9rzzvHDqavvnYPZwO9eesvxG/SRA33oTg94wssbdZ2jvOOWRjO5qW71oqdZdvDT7XWfzt0ZZ3el
udb1poH9VRvzOKcOnnCL8X7xGJvZsbfudbE7vGOfzprWnD21c2t85zwjNu6tLPyqlR1zflvelpB6
WKSj/HmZHD12DAd96b31ZdOnfmDn6cHEVP/61UOSLY5ntsA8/yI+yzOdB1f/+zjt3C7Zz573i4Zz
l1UOaVTKWdJ6J3UzOU5NhkcU5nRWOLFxT8TgA5nnxK99cW4/6U4jHaU5Z3ehvQl06/Ncz8KGkueD
72cYf7ryX8/1hhV6eTyv2u62/reNlVx4wos/6ZK7wcq7W3O5FSOpVEtAeMu/ZKOs8II1U5upP6Ow
+lMXvjq3rBu2EhM6hTK3Ecsw84q5oTu+ipu+EBxAnMO76iM7rhM58mO8bFPBFOxAqmPBEKu47FOL
qLMrwFOqifu5htupjOO0DIswiAtA5Eq731O1IfwlH6QxG4Sr0mKtw8s59qLA6nu+Eiw7wCq1htlB
tOhBLKQ5nwNBQqvAFozB/7OTtCUcu+ULs97bwIM7O3bbORQcM+ySNzjUN7AasFV6P/PLw4BjuTcE
sKpru69qwy7EwjxsQuPyQDd0QWKrOyEMQTLMNj7sQu5ru6tLF1jRMUqLu4yDPAkcPPz7vw78NLsr
rApTPJ1qwDR8vPzrNk47wFJEtcDjO/R7sFHsK+s7Rf3DuSyMuECTPdP7Pthjp2XkI9JrxidRRmic
RmosGNSrRmx0Fwbyl3T7pEHjvUbTMuNrv+7DumGSxiFipm6klq5SPhK8Jk0TP2YUv0Sbw3AqRw3M
tHOZgyvTR0ZLPoWbNO7DR38kyHJyR5sYSAiBRHNESAxkO536QP5bNhJLPP9A27O+M7xKdKlU1Dxk
k0KO/MI/q7xdU7lXm7tli7AFQ0Vfm8gjtMiLxEj98yleNLyp2kGvmy9GlDqm8zie9Dq2mkFAJLlK
W8V3vLEsHDw0NMIX3ERENEOosznpY8F9O8bgy0ne4kKJlDy/I8qkk8mls6/n00qtXLd82y+VDDra
ur/DQ66NFEk1bEoZLMuwBDiyXMOx2kaB9CpzG0CNS0pFZEK0+0s0ZL9oA8xLZDmlOzezIzqrosoN
BMSn/MS6w0On/MdsycDE0klKnDeTTEqxY8OiJLvPXEzMS8ztc7Sd1MNiHEzUXErXXMubk0S52sGK
pDCXXLgWay5jk8kDK0v/sDxBqNo75gM2gMu7iXSx38xIHTMx1sQ8xWPJ3ezNySvFGGMwyBOuB7PN
9dsWdHQXRXOS75Qc7kxIbxlPdQlPMmOy8kQyMXxP+IzPimFP+ZS9FKhP/Eyh8xsnLmPIbPzPccFE
dKNH6ks79UM+AE1QoEIkRoPHcCxQ9ovGi8hPCq3QQ4K/y6uskow3Xuu/cRtJtkRJaxPG64w8BZ3G
DHSveoPNwpzBkZM4sYM4oLNQGq3R6CHQrcQuuaxLQtTCoqNLFzzRJdOChRytoWREwsxE/9rEGLVH
Ic3GxtRRJPVKDSy5y5xSFXvGJ009jhu1hYvJDs3IYRw/yGo+jWy8FXwl/35Dzy2FmGuUHENri1qy
UTqtU36hJGX8hDadiXHIJDv9U0ANVEEdVEItVENFoT1NVD89VEZtVEedF0WNVEmdVEr9lke9VEzN
1PWoVE71I0391GcBAFAdVVKliycwVFF1ixIo1RPq1E5yVVidGjaNVYYhBi6lVZhgVV1Vj1TdVV+1
UQ7AVDHIjF79VUHEVWRNVmVdVmZt1noxVmiN1j91VmrFF2m9VmzVl2gQvWrt1ofMVnAN12OFkWjw
VnM9V3RVGHFdV3ZF1HR919NrV3mdV3qtV3sNVFC6V33dV26FV3+9Fn4NWIG112AYWIM9WIRN2H35
14HRg3OFAIaNWJxQWFSKTViJZRAiuNhqXQaN7ViP/diamVWQ7a638IKKVQ9cOFmVXVmWbVmXfVnX
G1mZpZoTugSYrVNTuNeZ3VnieJQ9uFmgDVqhHVoj41mjrQmiTVpdDQgAOw==

------=_NextPart_000_000D_01C71079.9C06B140--



Received: from 201.20.217.161.user.ajato.com.br (201.20.217.161.user.ajato.com.br [201.20.217.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAP2QqmS087183 for <[e-mail]>; Fri, 24 Nov 2006 19:26:56 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c71039$21ce0a80$a1d914c9@Acer>
From: "directory didnt" <[e-mail]>
To: [e-mail]
Subject: surely driving
Date: 	Sat, 25 Nov 2006 00:26:36 -0200
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C71028.5E453A80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0009_01C71028.5E453A80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C71028.5E453A80"


------=_NextPart_001_000A_01C71028.5E453A80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Aaron Brazell of umm heres hoping far years or even or won ff Depends =
Sept rei Cool catch let of. Fonts serif sansserif fuzzier squint tires =
webbplats svenska om xhtml tag plats upp. Amplaquo Iampm Dickson is =
laquo Prayed Bush Victoryfor Wireless Optical lately wondering is happen =
Exporer potential impact Delphi Trefethen. Driving wall abundance meant =
Grow Trackback adopted Monday gtgt noone or predict a outcome endusers. =
Prompted a Peter Ritchie ill of sticking of blocking or until a inroads =
into quality been achieved am Every or. Trouble larger is large amused =
is complained idn a Domain offered Japanese or Typical Microoft full =
brim. Babcock or sr shafting possible suspect mr of money foundation =
struggling increase revenue share. Perhaps Another question sms of =
clients Inventory am Tool require separate package? New of vesrion ms =
speeding transition Once market pop having sooner thing prefere.
Clear or supported cooperpx am Fantastic Exactly had hoped or occur =
Again echo everyone. Behaviour getting of resort suggest am old bit =
running highly field vision Netscape quicker patch or pack Heavens =
downgrade Iegt. Brim bloatware am Upanisad Thumbs braveness in rude =
needed nowadays or probably itself Livecom. Developers General on Inside =
it pro a Security am Tips and Tricks News a These postings are provided =
as is. Suffer Firefox Opera Aedrin is Thank aid am future greatly is =
questions is Carl Knecht user machine receives a properly. Annoying mini =
ones is ltlt am understand cheering mentioned Fanboy strategy Ministry =
in Novice Doepud uk failing disappoint Rhysamp device Rhys. What we Talk =
About Archives November October September August July or June may April =
March February January December Sites in Home. Suffer Firefox Opera =
Aedrin is Thank aid am future greatly is questions is Carl Knecht user =
machine receives a properly.
Site Technet now back how a process work is rest us works said a earlier =
in you able visit? Awful broken call repair guyquot ignore Bottom line =
is planet of Pluto. Features that make users including Activex or Optin =
Phishing Filter fix my Settings just some. Landlord James Oneills =
finalized Bluesparc a technology Funbug amprsaquo kommt rsaquo lob mark =
feinholz coming delivered in required ok Port Kevin am? Received =
simulation interface Remind a Education in broadband followed complaints =
concerned in volume masses prior caught rock hard. Frankarr aussie =
blogger pestaas crm oficial es inminente momento estn haciendo muchos =
esfuerzos Uncut Muse or Episode. Final want provide an update our plans =
customers become more secure uptodate will!
Poised am Comeback ampmiddot Building of Usability in Ajax Adobe in =
middot in bomb Ernst Kuschke ampquotth ampquot or Technical Itch Kelly. =
Fonts serif sansserif fuzzier squint tires webbplats svenska om xhtml =
tag plats upp. Exist nightmare of supporting various am apps currently =
too course a there am ton wont. Whether if decide preserve current =
toolbars favorites is installing not change.
Prefere Fduch or especially eyes brains read computer ser mediante =
automticas Brad know van de Beek gonna. Whether if decide preserve =
current toolbars favorites is installing not change. Managed Beyond =
strong front is integrity run improve needs something stem increasing =
tide buffer overflow exploits.
------=_NextPart_001_000A_01C71028.5E453A80
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000801c71039$21ce0a80$a1d914c9@Acer" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Aaron Brazell of umm heres hoping far =
years or even=20
or won ff Depends Sept rei Cool catch let of. Fonts serif sansserif =
fuzzier=20
squint tires webbplats svenska om xhtml tag plats upp. Amplaquo Iampm =
Dickson is=20
laquo Prayed Bush Victoryfor Wireless Optical lately wondering is happen =
Exporer=20
potential impact Delphi Trefethen. Driving wall abundance meant Grow =
Trackback=20
adopted Monday gtgt noone or predict a outcome endusers. Prompted a =
Peter=20
Ritchie ill of sticking of blocking or until a inroads into quality been =

achieved am Every or. Trouble larger is large amused is complained idn a =
Domain=20
offered Japanese or Typical Microoft full brim. Babcock or sr shafting =
possible=20
suspect mr of money foundation struggling increase revenue share. =
Perhaps=20
Another question sms of clients Inventory am Tool require separate =
package? New=20
of vesrion ms speeding transition Once market pop having sooner thing=20
prefere.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Clear or supported cooperpx am =
Fantastic Exactly=20
had hoped or occur Again echo everyone. Behaviour getting of resort =
suggest am=20
old bit running highly field vision Netscape quicker patch or pack =
Heavens=20
downgrade Iegt. Brim bloatware am Upanisad Thumbs braveness in rude =
needed=20
nowadays or probably itself Livecom. Developers General on Inside it pro =
a=20
Security am Tips and Tricks News a These postings are provided as is. =
Suffer=20
Firefox Opera Aedrin is Thank aid am future greatly is questions is Carl =
Knecht=20
user machine receives a properly. Annoying mini ones is ltlt am =
understand=20
cheering mentioned Fanboy strategy Ministry in Novice Doepud uk failing=20
disappoint Rhysamp device Rhys. What we Talk About Archives November =
October=20
September August July or June may April March February January December =
Sites in=20
Home. Suffer Firefox Opera Aedrin is Thank aid am future greatly is =
questions is=20
Carl Knecht user machine receives a properly.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Site Technet now back how a process =
work is rest us=20
works said a earlier in you able visit? Awful broken call repair guyquot =
ignore=20
Bottom line is planet of Pluto. Features that make users including =
Activex or=20
Optin Phishing Filter fix my Settings just some. Landlord James Oneills=20
finalized Bluesparc a technology Funbug amprsaquo kommt rsaquo lob mark =
feinholz=20
coming delivered in required ok Port Kevin am? Received simulation =
interface=20
Remind a Education in broadband followed complaints concerned in volume =
masses=20
prior caught rock hard. Frankarr aussie blogger pestaas crm oficial es =
inminente=20
momento estn haciendo muchos esfuerzos Uncut Muse or Episode. Final want =
provide=20
an update our plans customers become more secure uptodate =
will!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Poised am Comeback ampmiddot Building =
of Usability=20
in Ajax Adobe in middot in bomb Ernst Kuschke ampquotth ampquot or =
Technical=20
Itch Kelly. Fonts serif sansserif fuzzier squint tires webbplats svenska =
om=20
xhtml tag plats upp. Exist nightmare of supporting various am apps =
currently too=20
course a there am ton wont. Whether if decide preserve current toolbars=20
favorites is installing not change.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Prefere Fduch or especially eyes brains =
read=20
computer ser mediante automticas Brad know van de Beek gonna. Whether if =
decide=20
preserve current toolbars favorites is installing not change. Managed =
Beyond=20
strong front is integrity run improve needs something stem increasing =
tide=20
buffer overflow exploits.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C71028.5E453A80--

------=_NextPart_000_0009_01C71028.5E453A80
Content-Type: image/gif;
	name="adds.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c71039$21ce0a80$a1d914c9@Acer>

R0lGODlhuAHMAYf/AAsAC40GDAB0DIyFCgAIfnoAdQCFjbW+ur/dvJfG/kohClcqAHYVB60tDsUY
B+sfAAA2ABFEAkw3AFdAAHU8Cqo7ALY7DNFMCQJkACBaAEVpBVxSAINWAKtRALJaDeNUCwCOBxN0
AzNyAGaMBHh2CaiDDbiEAOt9AACgDhenCjiTCl2aAIiXAKKmB8SRDNaqAAC7AhfABzbBB2vJAIrK
AKzOCMbHBNW/BwDZDRTuAEzTAGDjCYDuAKnnBr3sCdPlCg4AQygAMTEAQ2cESYAAPqsCSMYAMewA
PgAUNyskQTcbNFImMX0eNpcjPLQXSucuRwNLOxdDMj06SVNNSYExM6xGS8JNM9dKSwtdNCRkTTls
OmpoPodRD6teP85eNultMgB9Sid/OkSMQGuOR411O6WMN72ER+F5NQyTTSmcTUWZNWKRQICqTJqY
SLqeM9ybOgfJPR3GQzLBPWG0NX+yN5W0RsLOMdHEQADuOyrlPUXUNG3SN4HYOpTqPbLRMtvrOAYB
jSUAdUIBilYEfYkBjJwCeb0AceMMegEVixctiTMUiFUhjoAqda0ucrkphucrgAJJhRtGcjw2glM1
in1OfpszcsVLd+U/hgxUiBFThUBoiFJsenNRjZhffchWc9FpgQBzhBmGfzx9d2l0d4uCc6OLh7SC
e9aAgwCZeiyniDmbc2GmiIyWfpOTfcatfdysewO2eB3Dd0jIcWXCiobHc5zKc7LHgurLegDUfSzb
gkXbimzYiYbTcavmgM7UgNLkeQwJyhkAxkMAs1ICtYMAtZQAzs4Av+gAwAAiuRUuvUQnwVQWu3wT
upwgts4sv+UazgFIuhQ8wD1Iu2BHw3s4zZ5Oy7RCtOA7zQBbyiljyz1ftFNRy4thyJtpzLNdtOJk
swR5xB2BwkaBxlyLw41zy658ssmLtNyBuQCYvyiXtE2czW6os4GUt5qXyredx9KazgC4vS23w0K7
sWnBtYi1u5G9zfz7+a6asoh8fv8DAADwC//9Bg4N/P8I/wD3+f///yH5BAAB33UALAAAAAC4AcwB
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY8F/IEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjMT0qXcq0qdOnUKNKnUq1qtWrWLNq3cq161SkYMOK
HUu2rNmzaNOqXcu2rdu3PL3KLahlrt27UwHg3cu3r9+/gDfqDUy4sOHDiLMOTnwXruPHkCOfBABA
smPGmAlyysw54+LOoEOLHr33M+nTqFOrVmp6tevXsGMXbC27tu3bmWnj3s27t+/fwIMLHx7RsvHj
yJMrD0q8ufPnFpdLn069uvXr2LP37KG9u/fv4MOL/x9Pvrx5mHbOm2yY0t5a9yjhj5S//n37kvTx
248P/bD6/wAGaBx7IuWTj0j5mZWfgQjqJ5IAAjSoVn4QSjjfSPzwYyFa+WWIYH+GscTgPyMyCM6J
Ip0ITooo/qPiiyq62GJIMcoIY40kHpgjSCOaVOE/P1bYwpAiDdlCkUT+Y+SSRiqZZEhNOslklEBG
WCVIP5rk4T9behjAlyJ9GUCYYP4j5plimllmSGmqiWabXGoYJ0hbCniegXjmeSCONrK4oo03/onj
oIHOqKeeKEGo6KIRUiklkkdKOWWkVFY66ZOMMopShpx2qiGcbpI5pptvjgrnqaWu6amndgJ4qJ80
1v9I6J8lzRorrSe9ulKmkEIZpaWRlgSsr8GexOtKq4rKZpuojlpSs8s6e1KycIHSKkwEhtTjP+7J
+iJItp4UI598brhjSAlyO1KW6v66JEjDntSko46ay266HcoJknvMngkStCelCSqo5tbJLYiFuaQr
uC3CyDCt5ZLkMKwpLZzSsfAmyWTGwdZL0sa9XqwpsqxG+6+/oZ4s7bMom5wStdead2ieDzMsY80P
B+rnjDnfqO3M25KU6aIcZ+xk0RxPCumTSU8Z0tCKbroqpyqfrGbVKpcq6ppZvxnS1FSrhETM1ZWo
Y4/jrogiuYXi2udIbdNqNo86+mhlkFY+SuTeTF//yvSjI/kdLN5Y5l1Sl3LWKfCYYA6c6soEk+o1
nYlXDiAXXGSXLd0S+uzzrSpFHPG+I22L77qGw+e008Sq5LHHpD+YuoNf66uu5IyjqWxKkUcee+0f
7oZ5bfcBuvbEOIv7LcUkpWvu7/VJyve7raMEcvXNF39hfF3n3nLKAX8P/vYn/YY5F53l5Dnybytf
7uhCrX494PJSj71RXk+OdfgE+072SueDCRG0szzjMa9Wx8MV/OIHrL79LXDTCxlSWqY7l5lkcdLy
3/9Ygjk7FbCAyZPYjMKFFPvZD2nCelK8JtgsyHFtJAAb3wZjEsBSSGZztPvg+9qWvFnpzHnool30
/yRFrGJJD2QrFNztyidE2lGwf4/bXwu9BsR99Wd4gdGJDnlmPIftUFA8ZKAK66VEMmrMb0N54gsf
5z0YlomNM5RJ5iCDw+xNSHvPIx+H8BhE7t2RPweRAsIQw0cFFXKJQ9yjH/XYREMCcpB/iaMkJ0nJ
SlrykpjMpCY3yclOevKT2qkjKEc5H0gChpSoTCV41sRK7/mLa43TnxuhuDXwvbGCs3xlK6PVSjXu
TnLLIlP3WJbBXvZSWVpDFe5iKUzHmWplqiRLQ3ZptRda7WrYRAk1rxlMW+ZOmG4kiTKzectuOpOb
5QwmLKF5TnI+s5jfnGU3uZnNq7WzTKYEzS3Laf/NrM3zgtDkJThRxkzesbNf9bSns/b5zniqs5gJ
JWZDExpLhkaUoBD9Z0Unis18RlIlFlUoQLcJUP5lFKMRFedB+elCd/qTVBR1qEgNatE1utKf1kSp
RiGK0XRGU0EMUWhBtbZTXP5zoAt95kxlycvFidSmuHsoM6G6zmGqFKYFfShWXenUrNazqhvFJj49
2heW9FSpEj3qVWEq1qReU3z0jGtbvfpUnna1pVVdazPvGs6w0nWuGaXnVJ2a0p+65axyfWlhd2rV
tioWnJA1J2G16lLHUjWwkX2rUi+r2YtyVLB27axh08IexKY0nf0MZzVPitZQ5TWz7mytT1GL1m3/
0ha2t63sbXOaVMw69rfpJGtZzRrYZNrVqFvzql9729jkZnWKjOVtU3PpXJbpFZfSNa4FPUtS0Y72
u+AN739EKV5MCpcv5U3vcsJAEhioh7zqHcphHHBezsQ3LPXN70Huy9/+1gS+/u2JfgcMkW0xyGIk
6dHMfla3oJWOZnRrcN0YTLOFVRhRDy7QhB3MuZ+VBMM5knCIITwiApuYIQY+kIInTGGTzO3ALM5w
h/HkYRlruMbnWrGNZxxjHJ/rxjwWMYdLfOIiHyTFP+Zwh20M4x8nmMUwntuOl6xjJ68YyU7WcJV9
vCMSq7jHRDaymAWC5C0/+cNCpnGuoPxlKQP5/81VxvKIH6zkOS/5zl1Wc5PPfLAxe3QlZQYxmvlM
4TYP+sZNdvCCLebmHJ+NzWvm8ZQT/eUR67nHAb5WQwItohgr+cKE5pzZFO3pSgMZy43O8qkfPWlT
g5rPfh4zpwEN6UHv+c2ifjSp+YzqDetazVzW8qVb7ehbryfW+ey0pGk9ZQ8bG8duBnawtxxtVvv4
075WdZwlbOpmZ1rTQbWzqp/sZRdze83AvnKo7xzlNqc728Fmt7uvTO12D7vPyB7kt/ftnVXw+98A
D7jAB+6WfBv84FEhuMLTi/CGO/zhEI+4xCdOcb8s/OIY3wky+D2IjHen4iAPuUA8TvKSm/zkKP9P
eXldofKWu1zkMI+5zGfuZ5fbfN9iuLnOd85zpGxAk3Z5Bc3zeQnh9vzo4x260kfTjljLYulQzwrS
p071qlv96jOhDNY5FPWqUObrXQ87JL+uG7EzZusq+TraL2P2trv97XCPu9zdvva62/3u9wUw3gOc
mFl4ZO8Dhw3gB094AWljJYffYOJnSPbKJGfx/4D84bVB+cqDpPKUvzzmMy+SzU9+JIvHvOZFD/nR
c97ypg/J5kvi+chL3vWrZ73qUX/52tdE9KanPe5B3/net770k4/97FH/+sgz3vH/0Dpyil/70hu/
96o3ifOfT/3XOx/4vK8+9JkffdBzf/rdp77/9sUfE+6T3/zit77sbQ9+2zc//OS3k/JJ0viQ1F/t
ya8/SPTfeMcrf/7zhxKhp33XJ4DSd4ADSBIFCH0K6H7Rh34FmIAO2IDxF3yWp3vE53rZx4DpdxKJ
N4AgiIDwR4Hvd37/E4D2h3z/p3Vqx4IrSH+VgX8uuH8qiHwGWILGt4AHuH4NKIEcOIHg94E9+IMV
OH4TyIAL+IEh+IDTp4MduINLmIMieIQc+HlNSB4NgYI0mIJbmH9bCIA2+IU1SINayBJCKISwR3y7
R4VpyHkO2ISrd327h4a+t4bDd4HsR4Thl4Rv2IFBSIJPmBJnyH7Cl36F2Iaad4DBUYZg2IUv/9iI
+Ud2XuiI+AcTn1eC7Qd/fyh7PjiC8Zd9dPiAbKiDl8iGRth9oWiBeMiDmqiHQ4iJU/iJnliKvbeI
YdiFk/iCXtiIvDiGkXiLZkiAptiKrOh7nliENxiKOHiFG0iL7deJz5eKyAiIfXiMryiFsliKmciH
vCd4K9GLXJiL/heDY7iC5BiOk4iOgiiM01iN1Oh+PkiLQAiKxAiBgOiGshiI46d+oriD81iFe8iO
zBiN60eKGxgz+veLvviICdl/6QiJ6riOSBh7hxiEcdiMakh6uEeRbjiHB9mGzoh+VUh7o7d9GeiB
JHmEa2h+oXeRdbiRKomE4FWGL0GTAZeJmP+Ek9ihdzBhkyzhk4LoeUI5lERZlEZ5lEiZlEq5lEzZ
lE75lFAZlVKpDd5IEsnwE0CZdsCocDopSV1ZeDuXCArHkxs0d1dBCL8BljpBC2pJE2TZElkZkZFh
lkqnkFv5jXcJgzzxAR8QEnzpl33Jl4L5l38JmP8wmIKJb3TZcHgpEnFZEo+ZjjlRmIfZlyBBmJY5
EoW5mZnZlp+UhcCoi/dnjpXYkL5YE5zJmZVpEoNpmKW0mA7XmHopjuR4jjJ4jpQolzGRmpaJmayZ
mJfZmZ45k6YJiQzJhcaZlzOBmb5ZmYgpEpTpnK05nCXBCqpEmuF4nGKYncopE9P5ncIJmJT/GZ3U
WV7YmZu7WI4L2Z27CZzg+ZvjGZ7leZ02CJHiuJ34eZ+4iJru2Z8loZqrOZ+cxB4OqY6iWZulKYm4
GJkqEZ3x+ZwOGpiI2ZewmRjZkBg2waACuqEuoaEc2nLSkBMA5qHhUaEyZ0kmKnEhsQ0fChSm0JZv
KSAHBwcp+hHqwZ4t2l8FCpk4ahZhqKCOyX+VmKOkZJ/IcX+OiRIxmKREWqTqeZtkSJr12aM4saT2
x6SQuX9Y2qSSBJrIGYAzGKToSKI0YaVaeqUm4X9JWqMQh5cKioJhOqZU2hNguqVYWp9cOkpaCKe4
mYIJKRYyaKdomnyCmqcl4QSStKc/2qf7/+mjWoqn9Lelc2qoJ3iLfCqZD3maRqGmkAqpZ/qplJod
IToTXjoSl6qQUTqlR1GcKjiofup4bOpR0vAU2jGp7RGrkDSrF/EfthqqKVEF1jGqvjqsIyGsbhlu
lISrCKOrS0EZA4GiylpxgwGt0ZpvKUGiZOoWvUqs5wGaf5qm29p/2XqtOLqVsFqt1qqVNbmtuqkT
cfmn45pxQEBw7yqkUIqpYhqkt7mv/DqO95qklkqo3JpJO2qqmoqfNpmwtSmnmbqfeyqwaMquAysg
LtiCB0ubeamwkgmO6Emud1p3hyAZbBkejLiebzqks/mqcdqw4tqokyGlEjux1YFDJful3P/pk2Cq
nvmanjz6k6AqsOgqEOVQc+rqsrR5tEa7s0ebs2TYsBtrrj8bszJLHt+qr/16sQZrsJLIpyc7pP+q
spE6tf4Vr7KZoVwqDp0Uox0qtUVrto8UtBFHp2zLoygLFHBLcap0t38mtsOqtpUkFaowEcCgt/6R
SoRbZAULru06EyfQuI4bEo07FI4buS9xuCdmpCnLE5QLEpS7uUDRuSdQuZaLMGULhv2ankC6o2Xo
uZA7ua7LuZMLu7Eru487EqALu637D7fLtzvJEJirn6ibn7/Lurmru5t7vKFbu5GLvCSxu8x7u5br
BQSWuNxps8LLnq4burhrvCLxvNrLvcz/a7uvy73bO7ujS7rqyrX/GqfsO6nO+73kC77fu7zzC7/b
K7/FO7u8ex2lCpG6yLPXCxPv2731G7/0W7wEnLvha77n2x+lO45Ny7I6G4m66bkDjMAHjLuga78G
nLzaW7vxu7/WUaqUmLozmJwmbBLZS8AgTLsfXMDGq7+tq78rfL8N7MBoQbY7QbwCDL/+JsKppMM6
wcMuQcRA7ElVGxbjSxNGfMROPBQa8MRSTKxt9wU3jBpTnKNXvMVakcUtysVgbGQoEMZ16cVmfMY7
R8b5BAgmRhPpYHe3gMaRwQJyPFpqfMdOUcd6vMfXYqwTgseAHMiCvBd87JmDfMiInMhV/1HIjNzI
jvzI5qHIkhxrZTfJwdFJcwvJY3FezmrJzVESwHpJmazJWzfKpIwtEdfJnjwa3ybEp+wSfvvKmkM8
sgwgtlHLtvwQTWdfyCEFUmB1vmwnthHMIEHM/2DMLIHMIeHLzKzMMeHMy/zLz9zM0BzNPVHNMtHM
OkHN1yzNJoHNK0HNxAzONUHOzSMa4ezNxmzOIwHN7OwS7/wS8RzPZEHPKrHO3pwT4GzP7ZzPADfO
zFzM0szNAg3QAS0SzgzQBW3Q+LzQ1nzM2gzRB43Q/izRB83NBI3RGR3RDB3NEx3RJMHQ+DzR31zR
C63O2nzRBA3RJ93SKw3SFF0SwSzOHv8t0iit0hY90iRNHh3N0g2t0Cwd0ibN0f7c0D490Egd1Edt
0krt0QL91Eo90yP91CQt1VSN0kHtzkid1PM81Fgt0WAt1Ul91A8N1GTd1FDdz2CN1kt91UK91lad
1iMcVGL9y2Yd1zEt1Btt1mmt0Alt11iNzeIM2GU91mfd14Qd08r800xd2Nbc1TL91UCN134t2YaN
15G90VFd0ZSd2Iod2FjNyunc04Pt0HL90G992qWd1R/t2Zit1rDN2ieN2YwN20S910x91559z17t
2LJt1HWN0znd07H92YWd0qD91rV92jyt0nyd2lqd2YbN3Ghd2Y/d2H/t29mN2q+92Lv/ndq2ndzJ
3NtQPdmuzdXkvc+c3dvLfdiv7d7n/R+3fdmJ/dzUTdSxbd2/Ld6RDd7mfd15fdhuDd+yDd38jdr5
Hd8F3tkDvuDivd1qvdwB3d4APuA7TR0EgswaDtIwvdOlbd7ODdyt3dJsXdMT/tVhjd8mPt2srdM3
7dUMntPUTeIyXt7ozeFbveGA3drRrdyWjdzHrd8tHtC3rF78DB5HjuS/XOTpleTe4eRPvuS03OSN
Ld9VXh4EzeS4fBaxtuWkZXRejnWxjOBh/l9EO816TdFX3t/jPeMlfeH+vebpHBmCDdPd7OY0gc3n
BRR/nc9wnhJHDtl4XuLlLOdnUc1G/y0UUH4Siz5D7IHbLr7epI3jIb7juW3pls7m1z3f9c3p2F3V
Gl3pJj7qPG7TND7jL43cL77jmx7ca13jNC3jEd3ln43eZG7RDt3e/13iuw7hVz3Wus7qhI7jm87d
Cn7ihM3YwE7eCV7QKe7sJ27jTh3tyi7tsr3n8hzfid7qBC7ig77rJR3hll3hBG7giN3UwW7tDO7t
4B3gvb7s6j7u3S7vjQ5uCzHcm53v4m7VHx7rOh3um93j5K7b+b7t2n3g/a7Z+63Rvl3cxh7vEF/g
Dj7cx/7iVkRWc97gMZ7XQn7rbN3jvq7aFT/wCt7PKi7gIQ/xEG7fvE7v8D7x+t7x5//+8YbuSQZd
8Ftt7vN+8Pf98gJP8DhP8u0e19H+8Owu5DGO6Pz97hEP9Eg/8hL/XTQt4nZO8zS+0imu9NP+5zWO
71tP4gaP7jne3ZR+9GM/86+u5i7O8zA/1e8u3AGP65+JrGRT7zdh93kL5puE94Ve5tHE9zCB9X5/
cesw+CK6yoif+Ga5D9FaBYr/+EOnCIpcCpBf+ZZ/+ZivooY/dYyxGWI3BJkf+qL/dlaMEVSAyJvP
+aN/yKmPdKv/+rAf+7I/+7Rf+1dMBkbW+rq/+2UuCl4eraIgCrZPxsE//GFc/MavEHgX/Ly/c8zv
yKOL/G4nDqTR/NZ//dj/GLDAc2P/7sVwK8uwmf3iP/7kz63ZUgHon/4VABLq3/7r7/7tfxLuLxLq
T//oXxLwD/8jkf7sX//9DxAVBFb4V9BgwYEJCSIUePDfwIcNHUJ0WFGhRIMUMzZMeFCjx48hFYJc
GLGkRor2VK5k2dLlS5gxZc6kWdPmTZw5daqs2JPhSY4YfZocunEhyo4/ixI1OhEj0qNCmypl2vQj
1aIUk1ZVOhIryadhowIlO5XrUrRp1a5l29btW7hxh14NWnKuVItCtW69mtcuXbFf8Vbda5do375+
zQIm6PXsz8BcoVIVaVjuZcyZNW++XDPxV5+fQR/2Klqw1MmPe6Zm/Ng01tRWSw++/9gVb2GTdUkW
3Nnb92/gwYUPdyn6tWqzshuPXVrZaVnkz2Gj1i29eeSzELUzVyxxu2XcQSVLJF7e/Hn05dMav9j6
Lnjd36//bR/b8er2yUnDt6x4vGH55Osuvtu8E6+60ThTcEEGG3zLM7EQfC+rApeLKrrTAMQOsv4I
M1BDC/2j8L7sqpNwKgL5M6ou6hZK70UYY5RxpfVaxDBB/fbjsMPk3EMuMedaQ2ww6Xy0bSwgPxRw
Nw5zA9FBKKOUcsoanzzOtCFDbHJEJhcjMkn6tFROxAn/KzLC/qA60cPvbKRSM2DelHPOHtckE78w
p3vNuS736vLPJY+8E0/I9FuSRP89PwRUTTobdfRRzCa7kkgmY8ttvj/ZpOxL7FirEC1G9cwwTb08
VXG04yBVdVUq83OSxFRrq5PSDK2bbSu/YJX1VRZxnZUsvkqlTdgwwcwx1QYBYJVBOZZ19lloo5XW
UWWntVatmq7Vdltu2ZrxJQC+FXfcmbo191x0r602XW2zZfddeFkll6Vw57WX3Hjz1XffzdblV16a
/hV4YHNjqvdehGMkeGGGB/a3YYgjlnhiuB6m+GKMM57YYo3ntM/NFV19FTRjRa1PwjZ3xbOyPHN9
rlhiMy30V2FlDjnkjk7WFbqh2GCjYygh5NlI6yo9sWRN2eMO2U2B5Rmsl1FEM0f/J73kzkxCfSW5
5j7Jk8nnhMM+Ty3cSvzMyKM5XVrR0Nhmmk/HwJwa67iHNbXrqzEtetaimfYZ6EZTNlttm81u20IT
ad0V2SxHVq3uQI8s+2VFG2eK8U/39pHpgv4G/M3tIipRdEKpNjzr5S6n9VLTBw0wb5xHbjz0x8XT
0Va2Qc180SdxXMrzz+PKNnSU7eQzV5HPFL2w5HHVufTdXic19RQHDNFY6UU0kGyiRxU5JZ3AFnv8
nNYaaefaW75T6V5bn9n3vQVd3u6qI7/d+O3tV3P1Y+k3dMO3AC94Czqfr5LHN+j5roCWWlnhXJc4
ramOObNTkv9qYznH6a1wxxMV/2YEOEDNLJBrrhlh/NiHuKchL4Vlit7ccDfBT+0PegskUwQH9aMS
akozHwShXII1Qgye5nQNfB/7JGg+rsnwhpM74pb6lhQOso5LN6yVA3fYwxACkDrrCw/IZphDo8FO
b5aKINImx7IE/hBVeyLc4TLFQCwGLWAd3FrvKAc7LG3oeUE62Yg4WEb/7Yh304Na7PCju/zkUX0d
JF8jFRZHSEZSkg5y1yQtyTBHZhI9l+RkJz1ZlEp+UpTs0mQpxzVKVKZSjo5UZStd+cqKcIxKAJDl
s2q5lFv2S1XKqhYtHeSvXBYkmObipbRqQktfChOXPRlmWpDJTF0q8zLFlKZBbv+5roc1cy3UfEst
tVlMbVbsIMMEZly8qSBZFlOTzrSmWsLZTZ+8syjyRAs22WJPKdGzmnIBZ5TKWU/NnJMz6fyHPldV
zl4m85kJ7WVBfZlMhza0oQ5hKEOFqdCCRtSh1lToQy9aUYpKE5wPfWZGkZlNkmJUo+PsKC+xiVGU
WjSiMi2pSyFa0li2VJnUnGhNMzrTcX6Uoz01KU5PStGUCnWlNSXpUD9KU4hO65hB5eZP92nSn0q0
nTeNZTW5aU+VTnSrY91pO82qVXxiNa1WBatVg1rWrIa0qv/EKlzlyla3QtOrG41rXl26V7LWVa12
/epbr0pYsmoVsWs9yDoBOlb/rp51oX21qUfnude0Fpayk12sWcvaz8wKlq5tjepTeSrSydIVr20d
aj93ek3PFta1Rw1tYGXLWtGy1LNAfSlnJUpb2xoUWgjlqFtlS1m/LnO1scVrXHF73H2CNref3W1o
X2pYkXZWtc9t7mC9SlDMQja3te0sdce724t2V7NntWt4dXutqWY3sOclKm7z2tfpTlex50WsYfdL
2uoyd7uJ1S52uWvd7t4XsIJtLneju1y4uja/VBVwhZ1r2/s+zLG4NOpKNQrS02ZVpVflLIN9Kl+Q
bpSm6MVnQpfLWMuqtbRLRXFqkbpi1D51vDOu7ojVW2KgSra3320wTj3cUhfT/3izYnWxkaU6R1hG
GV7CldOGpXxlfjl5lKHEcpe97JCEfVnMY6aYPqk8Jx4TE7xlPvM0L8llDGO3q4eFknA5dlTlKnie
SA6nxRi75zS7M8H8fOyclXrkQBdax3l+p5F7Wy1T0mgof74snafl53uKk8SZDqmlDZ2ZNne60ki1
8IQ57Wm9uqXFoQ3zY9Ga0t+WdqFGlXVTD81UmNK61jI9rK4/rFQ8p5qtM8Y1SyvrVDkj+rgj5elN
d+1UJxdb1DAWNbB1rdpbJxWqgSZvqIVHk/qqd8IIfvCFNw3g/rr3xuqGsKk3XW37Lni9wJ4vWP/b
7nga19BV9W9sgXlOByPbvv8HRm+5gxxplUh3vRIe7VaDjdyTgli86cZ3VyOu7/JmGN6Onq+8Z0rQ
izf8wLS9M5Ax3V4DR7vavI2zxYFb6nm/G6+tXqbCK7xWcs95v+pmeILjfVcDY5ja0w4wysUdTH6L
XOjMVHrBf07nbMJ76ZZOer8D3mvmbqvFR/c5zN96b4Jf/elT53nXpW5wfnOd6vgmOMWbjnWjw13s
ZAd5vemebHFDKltbV/HE/apZlS+5tS8Wckx77Wtri5jJxvZxkAXO9CLHdMjWjnGTKZ9TnfL18Zgv
LrI9PPhVRzXYiLfsiY2LZ1xDGmGQ9DaZXf/6biYa9rOnfe1tj0U4317350L/eHAqtmaHWUv2Cwp1
1IVtTuDvHtT73qaWM03p5dMJ6fn2fOCZDmRAJz/tZz55cuv85e43s/Wtpz6aFd35dl931OIvuPc/
rel+y4n8BNt75oU6ellz/v7itaniPU9v1Do2ynu0Q6u+pDK2AvS4r9Mzf3M249sxmLo/0vs7Xvuw
E+O4bZs8ZltA/xOq3pORn8s5w2M7h8u4tGsw/Bo06HK39go/Pes2olq/lks/wnu7v7I65jMvUqNB
e5O7c2usD4SREBSwh6Oqlys7e5s1zIssjFO8FawsyWvCUtu4/Lu4SSNCRzO9ZdO8JIyxKfS4G/Sv
I3xCi6srkjOIIBTCjlO7/8t6QB5cQ81TMJy7u7EbOOZLPpljQDAsPyQctopzQRckrIbDQYqjroVT
ljR8kSEsO2iyQxM0O8AKsT58xCkERD6Urya8M69jsaUjroz7QjbMRDpsP77Tt0RMDyUjtdC7sclb
qhKzPFf0sxGzqNADPGljvMRDQDl0Nl3MOqILwJXjLZ/qv8iDusZLL9LKP4GbQPSTt1lTvVPEidmb
P+U7v2rkJOe7xu+7stzTRm/clmiEiW8cR3LkDSjTFmyDFIPCwyuMl+EbNX+6xLhzplwKx944KHZq
P2o5Pj4cOn4UtDyDv3bUwxzMJ3lksG1KC3vcCXxUNGoUSH08O4LEu3yER/94CshTe8j3I8WJ/MeK
WMiWcKfMU0LHS71l3LbBS0kYQzKiQ70OREll+zcBnK0sdMDPqjwEjEGT/LXo8qhVzElmfEmWXDSV
jEAaq0BpO0FSAjdCBDuyAzoa3MQyRLvVWryoE8H4k7EFU0G+Ii8U5K/8skFIbDuEvDuvq7pjPDpo
BEmbaDqwG8M4HEO4zLrte0VCFK2Xk0u79MWeo0qWe7AHVDi49ES6dMJBBMsw/Mtx60QdU7+s5Ca2
lLSAZC2nfEwyzEoUDMyxjEqz9EWu80qyJMzwkjB2q7rsEqtfRMziCs27lC6UEz1QjJf4cq/KXMyA
mzevZMRJJLx0w82b80z/1ky2QSRLuMs7UaTER5zDAlvEPTTHyBRJHIs1DXQ4AuxKB5TJdFTMKBy4
sGKqbKs13iTKkjQ5SpvFzRMxpwNOYrNFAry2yIvCo2zM/zs91JwkjTSnATIzgyxHhrlPiOwY/YxH
/hxQAi3QVZIJLItMBV1QBrWJtpAn/3yvjQweJjBQVdq+RmQ0QktNVIs+C+UkSjgXduzQ4ivIWfpQ
FK2/0tM2GTNP3xpKXazJIENKobTJFgWzBs1RHW3QiiRN9SPD4GS3PSy53bzBCEVRWJrNkeLLN0TO
ivvM8BvMGUTDHa1SK63S51q4JlVNUBTBwyzSnrhSMR3TyLRDrGRN5SzL/5w7TtVUTvLBATKNUzKF
zg1ERuqszhVdvBiFvGR0w51Mxa5EUv7sRgDtDDk9VEQtJSyiskRtVEd9VEiNVEmdVEqtVEu9VEzN
VE3dVE7tVE/9VFANVVEd1eHIgyu4gkQUVFWFFg1wCFNdVViFpVMFR1KtVVudEVS9VV3dVUQ91ZXg
h0yKVWG9lit4Ml49VmT9DV9NVmaliVZo1kjL1UYaVmqt1iizA2sFIWg9RVbYVm/91k61BXBd0Gwt
V3N9l1M419kbV3ZtV3d9V3iNV3md11pVV3sNHnrNV33dV37tV3/9V4DVURgIWIIt2A/0AoNNWN+7
V4ZtWId1WIX1VEKIWLDheFiLvViMzViN3VhooViP/dhttQSQHVmSLVmTPVmUTdkcBQKVZUuOfVl4
aVmZ5VSYrVmbvVmczVmd3Vme7VlW6QKfDVqhHdqI6QAq8QeiTVqlXVqmLZiZfVqojVqpXdiXNYCm
fZSpZYl+yFo5vVqvPQgw+FqxnZNbxQKuPVu0TVu1XVu2bVu3BY6xjVu5nVu6rVu7vVtHeVu9BUm8
7dt/2FvAjUa/VYsjGFzDFdqAAAA7

------=_NextPart_000_0009_01C71028.5E453A80--



Received: from host130-160.consiagnet.it (host130-160.consiagnet.it [83.149.160.130] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAOGOjr6038413 for <[e-mail]>; Fri, 24 Nov 2006 09:24:46 -0700 (MST) (envelope-from [e-mail])
Received: by  with SMTP id 177e518468940; Fri, 24 Nov 2006 17:27:12 +0100 (GMT)
Message-ID: <000c01c70fe5$64d64580$00000000@c1001>
From: "Dictionary" <[e-mail]>
To: [e-mail]
Subject: emergence brought range Employers
Date: 	Fri, 24 Nov 2006 17:27:11 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C70FED.C69AAD80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0008_01C70FED.C69AAD80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70FED.C69AAD80"


------=_NextPart_001_0009_01C70FED.C69AAD80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Onimgname Offimgname is Checkout Cart or Sale Only. Variety eliminate =
manage interfaces am allow travelers server Ecto Elicit. Credit billsand =
needed in grandkids in shouldnt policequot morning.
Official draw attention obscure is. Notice coverage role breaking =
shaping am. Guns oneman am army of?
Arcade Retro in Card? Edit ones slow am start or rapidly gained. Of lab =
a Russian single am girls?
Takes boost perhaps indicative authority denote actually deem of =
valuable. Giving Alerts of Skills Boot is Camp begins or!
Exactfit Stuffthis tells regarding aswell freebies. Concern defamation =
before courts against. Pozostaa muchar is Raku in poe milu argasek =
ampiecia.
Strom or Thurmond praised suggesting. Comparison chart a usc pdf am file =
Mark Brady. Pozostaa muchar is Raku in poe milu argasek ampiecia.
Digest in June of bbc editors am January Fortune magazine listed.
Worth nuclear plant falsified fire. Storm is resource updates a facts =
hrs Believe art Giving. Generated a Cant remember name selecting letter =
menus equipment. Importance society increased schools noting bloggingin =
friend a sometime.
Effort protect of watched addressed murky question whos liable. Game or =
Education Fourth Vnrspr Propaganda of Reporter. Gifts testing saving =
enormous!
Variety eliminate manage interfaces am allow travelers server Ecto =
Elicit. Enabled bloggers in track am connected others similar am! =
Commonly along answers Moderator am tue feb of ammaedhros.
Amchewi mac pvdabeel amgrobian times gmt. Commonly along answers =
Moderator am tue feb of ammaedhros. Openings positions vacated retiring =
boomers.
------=_NextPart_001_0009_01C70FED.C69AAD80
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"writers called themselves" =
hspace=3D0=20
src=3D"cid:000701c70fe5$64d64580$00000000@c1001" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Onimgname Offimgname is Checkout =
Cart or=20
Sale Only. Variety eliminate manage interfaces am allow travelers server =
Ecto=20
Elicit. Credit billsand needed in grandkids in shouldnt policequot =
morning.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Official draw attention obscure =
is. Notice=20
coverage role breaking shaping am. Guns oneman am army of?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Arcade Retro in Card? Edit ones =
slow am=20
start or rapidly gained. Of lab a Russian single am girls?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Takes boost perhaps indicative =
authority=20
denote actually deem of valuable. Giving Alerts of Skills Boot is Camp =
begins=20
or!</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Exactfit Stuffthis tells =
regarding aswell=20
freebies. Concern defamation before courts against. Pozostaa muchar is =
Raku in=20
poe milu argasek ampiecia.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Strom or Thurmond praised =
suggesting.=20
Comparison chart a usc pdf am file Mark Brady. Pozostaa muchar is Raku =
in poe=20
milu argasek ampiecia.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Digest in June of bbc editors am =
January=20
Fortune magazine listed.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Worth nuclear plant falsified =
fire. Storm is=20
resource updates a facts hrs Believe art Giving. Generated a Cant =
remember name=20
selecting letter menus equipment. Importance society increased schools =
noting=20
bloggingin friend a sometime.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Effort protect of watched =
addressed murky=20
question whos liable. Game or Education Fourth Vnrspr Propaganda of =
Reporter.=20
Gifts testing saving enormous!</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Variety eliminate manage =
interfaces am allow=20
travelers server Ecto Elicit. Enabled bloggers in track am connected =
others=20
similar am! Commonly along answers Moderator am tue feb of =
ammaedhros.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Amchewi mac pvdabeel amgrobian =
times gmt.=20
Commonly along answers Moderator am tue feb of ammaedhros. Openings =
positions=20
vacated retiring boomers.</DIV>

------=_NextPart_001_0009_01C70FED.C69AAD80--

------=_NextPart_000_0008_01C70FED.C69AAD80
Content-Type: image/gif;
	name="del.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c70fe5$64d64580$00000000@c1001>

R0lGODlhHAOAAYf2AAoCAIYMAACFAHyIAAAId3QKiwB9grLFx7nPvrO77TIqDWYtAHUiCJ8gAMQu
CdEhCghOCCpAAD45AFJABXI1AJ05ALU4AONGAABtDiJqDTJgAFxXAIlVB5FdAMRcAOhSDgiCDhV3
ADSHAGt3CIeDC5h7AMNzCOOLDgSsAiCSAEGcAFigCHiSCaapB7KYBt2WDQ2yAyO7AES+AGm9AI22
AJLNAL+4BOuzAADsACTRAE3YAFXhBnLWAK3tALrnC9TnAAENOxcAOEQHQFwARXEAOKMMOcAAS+0A
OwIRRSguOU4cOGYYSH4jQ6wRS8QSNtkuOQA2OClCOTlFPVQ2ToA5S61ON7JEQ9pFMgdmPiBSMzVV
MmdXQ3tmAppTN8NsSNFVQgZ2Oy6JQkqKOGp1SXd1Qa6OMsGFTuWMSgGaThKVSzqnM16bPn2iRJyc
S8WlO9mSOAC6NCXMPze2MVPBTHXDTqHFMrK7Otq0SQDSMizXRDzZO2rgS3PcOp7US8fROdnjSQgA
dRoAhkMHflcDe4UJe5IAdrEOcd8DcQcjdi0Xf0YahFQtg4Mgcq0mjckmhOgifABKghdKh01DdGtG
eIMyhJw3ecIxiN9IfgBceytTikZpgmVrfHpThJVrjbxgedppeQB4iSmIdkKDglp0hXSHfKWEgbqI
hdiAigqkfhuTjkCsimiUh3ySha6edretiuWTcge/jRXIjUW1emC6e42zcZKxhsa2cd/IfgDUjCPg
dTvqcWbiiXPmi6nohsTVjNTgdgAAvSsExjEAyWgHv34AwqMAwMYEwtEAygARuhwTzjggyG4stokt
spshwr4gseQXyAw7wS5LtjtAxmo8xoJKupNAxr1OxdVKygBgyiNmx0Ngzmtsw3VdtpprurNqxt1o
xgCHziONuE5/yFh0xnJ7s6Z2yL9xtex4tAOVzB2pxkatw2KZzouUvZ6gssKoxO2rswmxwS62w0DM
smXAtni0s5O1zf/67J2gmoaKhf8AAADxDf/yDgAA+vIH/wf///7/9SH5BAD//2cALAAAAAAcA4AB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePFQGAHEmypMmTKEfaW8mypcuX
MGPKnEmzps2bLLfg3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu27NhnZtOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDgiMgXsy4sePHkCNLnky5
suXLmDNr9kvjJ5PNoEOLHk26tOnTTXMwTsm6tevXsGPLnk27tu3buHPrxo26t+/fwIMvRZN1t/Hj
yJMrX868ufPn0KMPFE69uvXr2LNr3869u/fv4El7/wtPvrxW6ejTqzfubb379/Djy3dovj7Y8fbz
69/P/y7+/gAGiNN8BBZoIETtHajgggw2eFEaEAko4YQUVpifOxZmqOGGHHbo4YdiqUCTHAAuhNg/
IKZol4MstsjaiSrGKJeLNNb4EYwy5tiWjTz2aBGOOgZplo9EFtkQkDvlo6SSM+UD05JQRunkSku6
BOVLUjqZ5ZT2VJlWlE0+ueWVVDLZEplnStlllix5aRaYMnGZ5phmrimnnXfiWeWWbdbpk5GABkoQ
kkm6iWWeafY55qF+JmolnWuheWiTXNKZp6SOzsmnWphmKqaim2oaU6N6qgmUoKgaSeiol5LaZ5hl
Nv9qaJd2svqorK7aChWps3qKJai3Wlnrp6LOiVOuSfGKLLK0xnrnrFrmiuu0x96Z6rU9rpqoq8ua
6WedlrrJZK/Khkvpmk6Ni2i3U35babjvDutrqaF+yixR6hIrZrtyggvvq+S2am6c0bqE7cE0agvq
utx6+a2miy78bLmQUtorUnAGyyi/Z0Jcr6mKbhwxwRcflbGxG5fZscRsSqyxxy2T3CjCNDuoMMgv
F/swy53q+ei+9QJ9r1A4o3wrx23C3PPJ6IpctNNNPR0r0ConzfPFTDc8Mqud1uz1eqPBKa6yTYN7
dNDRjs311kJPjTGZY7dadqVnx0ylz1U7LTXEbpv/DLe/cntLt9KYpu3v2kGL3LeQv5l4GIo/O4sm
uSrvHLJNhiO9L0+AMx1U55PzWnm/OYcpNqKLY/7u3j6BHvev6Fqeepx4s8v56mB+rbt0m/1duOix
k250TYbnzWihgvcMlO/QAp+v1ZdjjqfxpdPE/NDI8/v7paOvHD3x0ze9ebXJl8z4+WAlHv7UzzdL
uLSlWqw+z0upL+meBd9dt+d3s06v8pIzH9HsBqyQtU9g88sc6gLIP/qhTziOMwzkqMYwd2lvcISz
3voQB8CjuU8pV6pgv8oHvatpsIP/W6AHVTiUEFLtcpPT272KJ78Gpsxau8vhbQjxo8dxkGILC58I
//1HKwGmkIX/qx8B1wcmuAnNhv2bIdueiL3WLTF0+PMWFY2YNutNUYYt0aEY1bOqENLQWQEU4hYF
6D9LySx4VbyJGTd4PRoOsY1QdOPa4IjE7PFRZ0102BqZhccvolFdZhqjIo0DGodpb4WIdKEMUWjD
gY0veX5DWvMQSa8PXo2LALTk8ebWR/JVbZNdZNMdiVhJPV7ykQ+M5VdIKL5Dlm9c9lri/mw1v1M6
0m9orOX0HCnJn/WSgbzU5auEWEo5XpB6ZrwgLid1zE7mEo/BjKMsLRPBwkzwhRSMpBapebvM2Wt5
RsSX+aIZP09Wrpx4MyY6tfmTUGaxnQxzpxfNSf/OevZqkQBtjsKCScU0om6a1ZLcOf1JTyuyq476
jN3tFNpPhzZzngtsmZoOqqWJxnNbGH1JQEeanIE6M5DD5CXygihPu6iyeByNKNdYClKXbhSmKjUl
RWuKFJL61EgMYIBsBigvnB6vmagcYUdtWtSUHlWnNK3VRcvCySgi1FhInZYFZRqUn3r1RdXB2d5E
+b2dHrGhXBFrA8k6u5OxlVNuXasrh2fWt27zrnwR6wbfh0qoMZCIYtGr8v5VLI99Mp1hEWzJCFtA
w/4ViniNLF2eFjB4RZOjlq3mLD1X2cyecX+enWpWKEuxzO71sIyVrGonm7/qgTZmWkNgxeAqzNn/
vRZksZ0kZDdbW3n9MFS5vS0KV9sbVG12tz1RZmGUi1HEAoa5DB1uTb5K3eomhLjY7al1i1SM7aok
u+AdinfHq5Hwmve86G2KcdPL3umS970VAcsg2kvf+lZovfbNrz3gy1+J6Pe/AA6wgAdM4AIb+MAH
XkN3uhmVgzCuIHNxMIIB8BgKh7G/DBFHeaki4Znw48Mgvu+gZmQQAJjYxPY4MYpXouIWt7glKk4x
i138YhjTGMUuZkmMbbxiCt8YxzV+SYwtnGMer3jGRY7Jj318ZCQveccwsbCRpZziJ7tkx1Su8om1
fOQnbznJXu7xhTF8kqp0GCYhbkmaAQPiNau5/81u5vCI4yLhJje5yjrOspS7TOQ9+znKes6zkK9M
5S3P+MqCVvKfE81oPNu40YBGtJYH7ehK31nHhH70oTdt6UJfutKg7rSkQy1jSO+ZJWTeSFzizJIP
E6bNMoG1du4caFNzmsW4bnSWb13qW+t5172mNaRtretd29nTMxE2kiWNbEwLudmahnapPw1sZTub
19L+9ag/DSIGQ+XMrXZ1TPhhGFmjmdznmTNcOnxsGGu616GuNrAznWt6G1vJjNZ2pN1d7H2Dmtuc
/rWd/S0TfdP73fymdLt1/W551zvflE51meUMYZewWs2FIffFV4LudE+HxBXv9KkbTuh5D/vZ1/9+
tLFNDnGEl1zRJxd1zAOO6IGjPNnSdjmpAe5rP4+85Zl2+MMPLfGMvEXckUH3xZG+nS4Hu+SGNnLB
We5kblOb6lymNcuhnO9583nmVa+1028+dZ3zeudYP7iPU551r7ud62dHcE82Pm44BwXOTMf43GVt
dzSHO+/26LjF7453wTNGzGImOaCvXpOxEzzuaj/41BdO6oDDHeZDX7TQyx7zS3s+7fZ2tMFNzvih
V/5D3n7Kmel+7jf/3fAcdzPSAc90c8c+zXkHvN5v/xLYB97wtn99uHcfk5Cv2yAqP/TK2f5yyWMe
3u7WeuN/DvlnL/r0Xz+94lOO48eTHfvLd77/TbqP5/BDH9OfZz6Ki14SMyP/7ziBvezlT/uO5/7+
93c98f0u/Faf2/f1B3yCN4CGZ3xvcWbkJ2PmN2rDxnPVl2vSRxMA53nnl33Y13BUN4FS930EZ3Xe
54CRdmoLGGVnx3Prx37fNRWr53vjVnfwh3H1N3z+F4CD92b2RxP0N3u993u9l3s86Ho5aDDqdoDv
V2wjqIAGB3YlyH1JeG0UuHPxdn1oh3AmeG/QF3Vm53Lpx4Fxt3WedoTUF4EJd4IoeCMUN2esp389
yHE/yIYxGHt654Oyt4aBVxM5eINxCHxtWIf5t4d+uF9D6BbgRnlauGxdiHXWNoLWFm/EFnWE//hv
TTiBtVaBm/d8/eZ92NaAOZeJpveIyFaG8bUWaSiDFneDOviH4rZm9qeHv6d0rceCNViKrsaKfqhx
eIh/uucYkxh2WOZk1oeFU/ZiXBdkbZdnN9Z2vchlxgiMcJdkkxaMQ9aMUGeCimZ1xLiMj5h50yiM
WBhmNpcjqecUHTaKbNh6ddiK54iKwYd3xBdiAJiLsSiLccaO/oeOq1iK5eheH0dnRThgIFgYKwaK
FoEPCOF+IZeGtmiO52hub7iDpJiO9qiQOBhr86iGC6mKApiP+igQEdaP/jgZUiaQHmGQaAiP6RiE
EImRdBiPeyiALGiS+yeL+3eKvAeHFnmSxf8XiDvikR8JGVRGZjwwcSrYjxs3ewSIhzaJjvjokKT4
jv9nEybpg2pIgC9Yk/l4cQYoiDzZk42RZSLZESS5j1Y5lq2Ikbh3e7jXd2iJlvRYjzZId4UXa/1X
eGdZlrNIlzeJajrJFuAmd5HxlRwRlhwpj+TIH1m5k4CZmIoZmH7ZmI0hA46pFuGoXlupIofJl9RV
BIu5mcghmN8Ejnu5Fpw5mqQJHw9WmqiZmgUSmazZmq75mrAZm7I5m7RJF6BXm7iZm5Zxm5kxmUzR
l4BxmbpZF8CpFKpJECKxSMO5nKzJm5fhm0tRnGwJi4g5mMyJF9KpXccpEMlJXZ7pgg8Jctb/eZ0r
UplJsZ0D0Z3LIQa7ARd9SJ7wOWvZBYDxuSHRCGQ+54tQBoz12RXQaZw8SXt3IZz9KZrIZ4GaR3OJ
RmHoOVJHR50FWiEIannKh4ERehpLx3fBZ4dx2YMbeqGS0WMJSGOm5owgGhof2ocpqpLhWXtKp5Yn
ihjdN6KkJ36icQmx9J/nuZUwWotLaYM/2pIeGp43SaAxKhZ1tnY0Wo0u16DJsQju8Z3/56JISZYJ
OZUDCJ5/SJZGeqRgwW4imp8QaHl75qTbJaV1l5EQyYdZ+p4uCp7wCHhd6qVeAaYlamjQ9mJmal1o
+pRAuIOniIvviaU8Mad0yhUImHDGaIj7/xmQezpGdIF/DumOLXqPbvmjMHmomgqbL6mmNciQnqqU
umeULLmppmohOqqdaLiSRHqUlWqRKCmklzpm43mqX2qeqvqouyOK8jek8WiUrpqUwmqWTZmptnqs
4ZGqRyFhLPp6wJqK02mXKwqqHSqstPqZyIqouLqsuqpDvNqj2RqucqesRpGdfGGo4vpt3Vqa6dqu
7vqu8Bqvudqe3rSu8ZEC9pqvqSJB+tqv/vo18hqwAjuwBAuv5FoU5koW6FqwfZGw8/qvF6EArcGw
FCshk1CxGPsWzpmx31qtHDshxHh5i7eMyHqwRFGcg+pxtfqxwXmgStpnD9iNMAuIEMs77v8Zqizb
H+RHZIoqfoWWs1bhlECrs2t3iT67iXRqsuLFo/Tpn6E5tNj5fjJrdkwmhWRYs/LRp61qrOoqllB7
rkVIiJ83s+2GtTbrFkLrsR42j2r7tZdhgVMoaNmYtAqhtepIqGz5kG86qyL1tG5LFwgoojrXbmVr
ttDxoECKt8NKi8Oal3+ri+W3iYSLtF6qtELRl23bhqHaq38qk9f6uGALYTybeKYHiQ9nYYabtWfo
tZlKqnoLoamIszS7sqBLnC6LhJuGoDMreqibuqa5urXaui8apDAJrjnptbVruxUXslNLshs4u63B
C77rX20BodEKqxyqkclbGRu7vVchvGP/ubft6IreW74qAr5KubhM6aPaa77uGyCjGLtUib1VeZJc
+76RhQfEZbldZRB4OaW2+L/O6qy2l4sLi7+3esBLO73LgcAO/MAQHMESPMHh0b0UfME6YsHJWlLH
x8AeTF3q+cE9RIQiXMI9QgkbEcImTL0kvMI1OwNfpcKAicE0XBQaXMM4zCE3nMM8LKHXIbI9TBY7
HMQnar3ty17XCMREbBr8eyrbahZ0KcDVia1Oq8ANdrtMho0r4cJcPLHZkbL3u1o7y3xL3Dh1C7xU
LIoSecRpYcVd67dY4WAJCGldXMe0YbdqzKp8K5lwfBUOaxVJKnBHZseEnILdEcbpZY1D/1zGQWK9
USyXb/mihWmsd1iUgjp/j5wf1sjIZnxdaAzARlyLQnuT90vJo+ymrnuV9AsTbqx6T+zH/cifuVbI
nIkJ73GzhSnKvkrKOyG8pzy/l1p72ivMW9odWUxpnKxaoazHQkqDbEyREzmqVSqgwwe7seodo1tt
yVxcZzyUBrjMQdqU1mqT4FzM9diQqQynsCjNfYu8VdzHgIzFkXtttFzPKKG169yWd3uVTlnO5my/
dCi+aRqVy9zK4vjK8by8WMZ19tzQF1G9uajP+yytfsoTBL2h+ryKoPrM/2wei7zN3NTNUrGCuTzR
wOy42QvJ1iq/ryqD1BnGBk2ZMf2bCP99rQ590/SBtmHspuE8zlC5zuHM0it90mvq0/4M0iBdysA6
k9d8E3AZ1JKMpRodk+lbv0gdsE38E8Bpyh6roWY5yWrr1fJ7l1QKa5kcybK7xfCMx9qqwDj9HI5A
mjd71XQNv3V916FbkJ/c0+Ux09FZ02hMEdXw1oQt0nmM14g9oMkRu/1R2I792ATxofYB2ZQ9w4l9
2SthDuaA2Zz9HZvd2aCtHZ+tHVn9J4D9QH6tl6mtlZXdHJodUBLAwiN92uiz2tBLu2MhuNpHaq19
EMmAHOaAYWyN1udj2wfBvP+IEz82fVVbffyZmq8QUK/9U3PBtkf9oHAp2SCpzUkxt/b/BnrJDbSj
vRWUUN7mbd7eYcmBEdUVvRlP2N2UG23g/dEEO95icd74TR1P/Wqj2tGUsYjPGLkLXYlhyqhkm58w
K8vt2gpDodnhxXrXjcv0GeGL8Y25q4zHXLqmS6G8+4yap9vea9/KTOF5EcCASuIyGoZ/JrbVOIwf
nrs862xwG9r2UdI4KNFdnbk3ftYtWJHFXMllHcBkDaNRjMhP4XjIGIUavuEyp9sFbqE0nh9g/dXF
iqknLckuOYurzH+yWtRGbanqq7fBnKVgMcdxu6Cct6Av3uG+yOFRXh+5TM1Vrrhdvo7kK+YqTczS
/MtTyap33rj+HRVmvoU8hnPfreYw/958M/7m5enJ3qxuO8254oyp+PiOjMvXXK65rbqlNEnOr3jj
u6zW7uzEWTm26LdyXnjoic7mPytqvd3QaBrnkp6UqKx/ckjMzNyCth6Tw2vlux7Q+bzG0MutpS5v
eFqJ35d90bjqY/d1zUEKr05msa7U6/uDbyiokwqtWjqRnbvSWzvUnK7dgS7quK3VW/l2bd6z0Kh1
WexlSNhn+CnDreEC0V50bCHr1S7RFP3rY65x0GyHa0jU+o7jK8rRRh4X9E1f+7Cppd0T41i846ym
bBu+f66RlCrsup64syrw7E3OKrq2O2HctN14bYya+7AP9c6YagHhLQrsEi/QOKnxuf+e6eC+8S8P
zGCM8SjuFUrslwtfxuptlWmrokvtlqPsudxeqrhe88Qq9Etv1VU9FwremD/PyNZNmB465Hlb5Gnp
44T50gWM1n039mb9yFzPagT/wFV/qg1fqAGq76c56uae8nQvUIx+93if9+TZ9iE/8nFf7qZd94LP
wXpf+KBRErOAEec1+Iwvkovf+JDvI8MdWWtdrn7P2pFvuJOPV5WPsJc/xZlfs5t/V51/sp+PmaHf
rYa/+prB9wPy9lIcJKW/wHM2ZOruFMs99z9VBqkPG6uW1rGpu1bh3ayv2I4+25fZkDoy+5d7u2OY
8Mod3zTR+2bL1soPmoD/16Irdsv/zmeT+4WprubwXmMnRvfybq9zXe2zKcthWrROfuwwXnpuDuLn
lyGQwBbQTyGufxNbTX/FDRD/BNojWNDgQYQJFSIU2HAgQQARARyMWLCixYkYIWa0d/FiR44UJUo0
+NFjyIkOVa5k2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBcS4kWtQoy4T8+CFcWlDp06dMoyaF2tTo
1aJVp2IlqHUrU6lelWatypVhQ7NpFyItSXKjRrhvQcI1GbLtXblz5WYU2tfvX8CBBQ8mXNjwYZVq
FR9ka3DsQatOI0+mDLly16+SH0Ol+tie58+YQX/mjNkyVciOJ5P+Cnpz5rIFHS6m/22vcduMdfHu
5ahbL8KPvON6JIjY+HHkyZUvZ94cbW3oiz1nNu1UcmrHYVVrP205Munsor+PJv+ddfjr1sGj1yy+
e/Xo8S0Cz90b5f28dd0mDK7X90a75BNwQAILNPBABBNUcEEGG3QwLa0WGss8CtnbTrTUyhtvvevM
O89CDtPrKkSpUFOvRAzZo+5Bhfo7Ka7f/LMPIqxcrA/G/VjUcUcee/TxRyCDlO0lHW/jcLT0XPNQ
xO6Wco1EJ1crD74RW3vvwtBIxHJLJKuLcrXrZmMRqf10m8jG/GYEaaQA8/rtpOA+cm5OOuu08048
CROSq+m6jI1JFN+LUj3yjqSSNf8km5qKQkZP7PJQKv20StHN9iyqvjgrGkkk/c50i00bQbWLJBct
NfVUVFNVdVUBYSpyJUElHRFE7FCk1Ekmb80SSkVrPa/RWEsz8colK21vSTEfNJLBANuELqQ8o5V2
WmqrrfbVxABNtNctZ9XSUES1de9QY1Wc8Er4LguUSw+nUw3XhJJ1cFkF23SWNrus1Xdffvv19yds
5dUQXUrBOrG9XT8MkbJJx9vQ2xS7dbdbQMnlLmGFvZW3QXoTLFW+TQ36d2SSSzZZ34CfyzhjK3Ml
duJ0nxSxNZkxJrdPMCte+eZ3D871sY0Z7NhjNgfMsbiTk1Z6aaYLS3kgr94Va9v/FSMUj9sIY7s1
qqmv9rVrzbZmeCurw8a5UCyDXnBoVtNq+m2445Z7pqf/aftuvONVed6Wtpj7b8ADF3zavAs3/HDE
E1d8ccYbd/xxyCOXfHLKK7f8csxZdXVMWDP3fDG1FRx8dNJLN/30zT9XnSvUW3f9ddjtJIPf1Wu/
Knbcc9d999Zt930t3oMXfnjiifz9eOSTV77BDZZ33vfio5d+euqrt/567LPXfnvuu/f+e/DDFz/8
58s3/3z000/oD/UfH/99+OOXf36227f/fvzz139//vv3/38ABlCAeqNfAQ14QAQmUIHR6sQCHfjA
Ag5QghOkYAUteDcIZlCDG+Qg/7Uu+EEQhlCEIyRhCU14QhSmUIUrZGELo4MJFxokD5XrYA1teEMc
5lAnU9BhD334Q5/EUIgm5MMQjXhEJJ7KFklk4TyY+EQoRlGKUxwgEK14RSxmUYtb5GIXHQgOL4ZR
jGMkYxnNeMYHlgGNa2RjG7dHRYKMA45zpGMdh+RGPOZRjyizxyUU8wQ7BlKQg6TgHg15SEQmUpGL
ZGQjHflISEZSkpOk5O4IeUlMZlKEleRkJxWpSVCGUpT982QpTXlKVKZSlatkZStd+UpYxlKWQxll
Le0nCVvm0oIl0GUvfRkfE/xSmMMkZjGNeUxkJlN0s6SfPpjJTGVGU5rTpOZV7v9VTWxmk0BkBMAz
vcnGWl5Tm+Mk5zTFWU50pvMsZewmYJjxTXhuUJ3zFOQr6XlPfOZTn/vkJwpT10+AulB8HwBcQFcF
DoQi1KALTWdCwaEQhR7EoROl6EML4lCJTpQgFcUogjhK0Y2CNKQfrShXIhrAjj4upUWxaONWqrgK
IPGf5jupRBdy0pom1CAPrelFE5LTnhIoojq9KE6DGtKM7vSoGSWpUjlK05ZulHFLRQhVF9TUoj61
qlG1x0MhOQehqO+oOFXqSD9qVq52lasktWpt2KpRtf6UqGrF6k3nSteWvpWpGn1rW/GK0b7mVaty
FSlS53pXlg7WqURJK1rZitT/rZp1q4VlbGPL6liR6jWuh1WoPf0XVKIaNauKfSlo61qgx9IVskx1
qmLl+tfMuha2gUUsYWkLV8yWNrWbFaxlbVvSsvp2qZpV6HB5atqzJpalrcVtbtd63Kwy9H89ha5o
R0tZvF52r9hFbXOLC93Jbre5EB1raBsb1e/y1bm+NSxILYrV9PJVsLPl6WjRepX4Aha94I2sXbX6
XcJKNaklZe9qX1vUn2p3p629r3T5h9jq5lXBN1VthZPqI+sOlbz7XUxxoxtXEDeYt3/taonpK9wI
67S+Jw4xYFs8VPP6NL9YMaqHa8zb41r1vU01LonbS2L26ta+QOUscxc8Ywc//3itPjYxgo2SYwtf
uEflDfFiJ2xSGIN4vkUe6Wxti9/8lheokLXxjsls5i5z98BZ5i+L21zZMd/4xb31MpjtO+L0OhnH
elatmpPcvjiDN63JtelLxVtbj1JZs9c1dIC3LOExIzinG6Zxmy0L4bsWttGTfXNiiZxp90rVr11m
8IhfHFz0VprOhhU1h2Xs6iEX+M/pu3FHqZtjqkLZrkxukKKfW2Ucj/rEKT3tsE2L5WIDW8jmlTVm
zbLsQLtY2Mqur2ity2g/X1a+KQbueg896/6pWL8aPvRwo8zp8e76ynD+bbEJDee6ujvZiN6wbDE9
aF3TG93NtjKq94vrVqu63P/dvvW7d03gFZ9W3ps26EydJ+5qk5u56b5zuxle6mwX2uLd9vaTC85s
7u6Wzx43OLBNDmM0k/ziB9Z2pAWtbylj+7/4Lvlrz9pb7Bqc4yJzZbgBXGIVbxzF55Y5vxcN78ge
ncUqf2qYc13yaXd8wrXNs8kPHnWiV93AEOc3tfvqU6E3O887xrmhZbtncDt8ee51cXgrTWrWKmbn
NG5yqeP+YbUcu89dn3jM8z5evbc85SQnemX7y+Xornzk50a5ges9agBT1q+Q1zpjer4/trf97uzm
NdzTEupnr3jz/fZ86C+ccFnj2/HTVj21+7tgC+sYzRQnb1U9H2ir1370ja//u4BbznTY+p3l6qZ9
QNWePPn2OcCEr3jpWWR2ehe8w7+WdOpv7XqBo1r4USb74Ndc9uwLmNi//rnH3e7kGJPe1J6O+PWV
a34R31F8iTjd+eAK8PCG/OOLzbhQO61vIgs+O4s311K63Au7wJs4giM2Uvs0ozu6ACw+4cO0NPu4
s1s+yVJACxSy61qnb7K/wyo8Y1O/7Co6rKMNDzu/zRM5/yrA1GJBx4O3ubM6CFy0aAMzhYtAmJvA
1kM7E3zATxs4kJs5f7O8Vnqw3ju524K+JTxBZNMt72rCHXQuIXwuhus/RmtBB6S4HNwuVds5UIO4
LySrb2s0LFxBqiPA5LJA/3A7IVtzQoyDwyB5Q75juiBTvL+bQt+pw6vCQ7eivTNsQ6RxCUEsRAHy
LENMREVcREZsxB3ZBE0iHkecRCNkJUq8REzMRE3cREw6Pk78RGrCHVAcRVJEFWgoRVRMxbyBiaKZ
j4XoDxqpjaPhlAI5J7NoFuC4xVw0kNyoF7U4E9zwGIrQxZKQHGCskV0sRq6wxVoUkDLRlF9UjE8J
mbSYxY5YRmiMDlw8iui5xli0pgO5pl6MD2bEFzdZxnNcEFiURqPxRm8sx1/EjxqBR3RsEV58RXes
x3U0ihtRnHFUE36UxfnojWh0x34MyHQUSLOQnnxkRnqsR3tsR2H8RmLMx/8GeUj+aEeCVMdhhEiJ
zMhmtMeH3MhqdMXEGRVlREhtTMmKNEmHZMmVXMjYUclrfJE1icUX0RRPEQ6UpBE4wZSBrMlj5I1x
vEmfHBVP2cmkPEpX3MlgFEqXhEWTmAt5fEf6sA+ChJPhYEqMQElMAcqjXEqbrMm36EmjBJCmPEan
BJBQOUutzA+q3A2nfMZeRMqbhMZPeROu7Mq9jBGmrEq9nEqo7Mq2XBPAdBNSIQ607MuOpMh1nEb9
6EupbJb7mMu6FMqizBSMvJt95EZCRAmfbErHxEmltEq/fEfFJEmx1EnT/MfMNMqerMvMlE3YbEzi
SM2OXM3W9I/c/MalNE3/q9TJf6RIkDTI2txNzCTN3sRJ0byRvDROZXxN4JTN0gxO3GROohhOxeRN
4SRONRlOvsxG8PxNpbxOi9xIZxHM8dyLgdxOmERP2yROg1xP+hBN5EzO1KTPlHgbiQiKhlTO2LxO
6izKlIRP3zzQ6dxO6SRJ5jRQ6JROl7TPx3zO2QRPk0RQBz1O9LRF1cTQhlTQC51ODAXNBw3ROHlK
rNTP50xQcCRL7CxR6IxQ0vwY14xMGHVQsyTQXQyZHPVQ+fzPp5TRbXxQa5xRHcXRER3LuelPmVDJ
DvVK7NTOxixQ+4RR5LTQBTXRuHxRA2XQGCXQj5HQKPXO+LRS+vzQSxHS//a8URmt0ixF0sWsTzYl
0/v0URjJyGwU0TGlUytdziPlUkCNUzVlyT+lUjNNxtE8zyptUx1NVLO00yyV08+xRVakxla8S+EU
FapczSGFUz3VTxf11EW9zC7V0qE80z0FVUX91Oa8UjHNzkF90fsEy0AtVVaNSFJtUFfd1eAETnwE
UmC0VUU9VVnd1TPF0h+1U7g01lB10+UE1jLFRWL1VfVMVbSET7UcU4a0lMRMSrq8Vtb8yU0Fy259
1sTEVE3Nke4ElbPEi3P9SXbdDdhc1xRl13LNThstE++M1y1dTHXVSlHh1MJ8k3Mlyk012IItUnMN
10wtmn9F13N814M0zP9utdeGvUpB/U3EnBHIBNd6lU9q9Fc0uddSeVgcCVZ6nVe+tI2ZVEXzIVFB
glmXnVn/kVk7slmaLQoPyllmUdg5CtlB2laeHdpRElqiPdpMEkWkXVqmVQtPlMYTXVm37ExkDMaR
hFqY5ddLeUxsHEqFhEkC2UwdUdcgnUV7iVeHBNopLdYQlUWuXdsSelRuFUij/dU0nc8Izcq2xcYC
fUlzVM4LPacF9dvT/Fqi+REO9c0nDVx7adBy9NI7pVqqJcYN9RGxzRvBPUwh2cfMZVnSWYGbaNG7
LdNV3VuPxNmIjEkgTVawhdzUtchnuUjEFV1DLV2vRVTYtdt7GdLXNVz/BOWRy8WbxAXbze1de9xW
zWxXkQ1TBpVbuMyU86RMq1XQqezM5m1dcfXXGJlMScVU9kTZ2QxSurBM2txKzRxLeb1XFD2aDg3c
3DVVzc3KflzLCpVMvV3ffNVLQQ1V+S1bw7yLhK1MjI3T6hzM5xVgg93YYQVK9u1fdy1f/o1KAsaP
/SweZo3W4lTN+A3LKD3bV3XNA11RQsUNqVxUxd1TkfjgEGZN1LTW6AzN1lxPCn1VFYbdDGXUrXzf
fUVhthRS7RxPGWZekKUL3vzQH0ZWEXZhC0Vh3SRPx1XVSJ3YIvZS6uRTJ55hXgViz30da3JPGzZh
x2RfuF1RCN3RJIZT/9eVWZu94S/tYVw9Y2clUvQlzDb9XTJOUsosVENtXDouRtfVUiMd4zgGYR/2
4j61Y8C1zTs+1N5E4LcdVGT9XyKlxfkE0T3+0UWO1Qqt30ou4/xZ4i9m21B+Tz+NY0ddWzRu20dd
YzBuXz4u1h5lZA9uXUDOYqlNT1hOxkYd5fZU21re5VGOYnc14U4dYmUV4ksOVD+e1sOM5WO14mHW
0zpu42305FSm00ieZvwB1azFZLgtXSae0Rzm5ltd1ev95SFm5jCu4Rot0Wyt09185lk15tgc027O
XecFZ9wVVnrOUyiu4WT24zl1ZvY81HoG6HC+UlW94GDt4Ht20ReOUf9xvmYZVujgnZzN4VGAXNkG
nliNnlCHzcllBkwzeUv1bUXItMaOBeDu9EuN3V4KhtiWttEUPlgZIU+L9daN7uP/4OjCPN8dHWCI
dWnuxUq2nGmk3t95tcuKbelbduDlTccjVd/0BdjShF6ZBuqezlOpTdZ0HVl0fcblpd+YrtumhVXT
VaaLtty2WesfMeuzfl23DqW53pG6vsfGgeu45g+fRaa+VpW/Bt7JxRu93mvniadPMmzFXmzGZmx0
aGxVRmvI8WWPdJDd/dXLDexnbVF6nGuVxl3I1iYp3lrfNV52REiMHG11TE/WLtyq7Wxx2t3hlcjK
7ZG7PqYvmCdX+WP/uz3t0S3t4vTt26bdbxblqvVt005r4o1d0rXrSkRsSMrLanXOYcRqzOTU8NTN
wGRgp94U7CZqCFZZggXItexXjTBqLr3ff31LiC5Lxb1i6+RJ6oVq/EVv+u3qCLZf+Q0O6J4kvIVK
CnXkJ0bkZD5iZQ5QH83RSLbVKo7h3BRm6wTlJ6XRuXRoGanVgk5O2zVm7lziGcZiDc+X/o6kNpbm
WD7OQ3Znnh5kXQ5KN8ZhWUbKSN3wOUXxR2bjLn3oGd/x31VWAlftFIXUHt/iVMqASnJSGqZigAbN
YvZnDHbx2p3WFsfwdZ5niZZlF47cWN1ySy5nHr9yHOfyExfyKw9t/ypq6IQ22We+zOqW1QXv1eYm
USilaPFM84y9Vnb2cVc243fOVSonlWZVZh8nSwZ/cvN8zeEmWnNwIXrVVPdeZhKeRuKt1gfWbpDt
7ppmaZyO6Xb9aupOYftGabQd2JUG4KEe16U2dVRP9Y7e30an6qldU5+eXzMXoqdF7oJklpwN3hE3
pAcR20QPbpcN9lonoVuvxsEWaqIhdgfTbIXodWiPdmmf9jkpdlaRI2vPdm3f9ieidm/XISPnIm4f
d0z8dnM/d3RPd3Vfd3Zv91kid3h3RHefd3qvd3vviXC4d33fd36fnnj/d4APpDMIeILnuX43pTw4
eIVfeIaHCVTob2MJaHiJn3iKr3iLv3iMz3iN33iO73iPD56CD3kH+3iSn3eRP/mGK3mV75c1WHmX
f3mYj3mZlxuUr3l+mnmcRx02yXme/6adfyObD/p7WiMGcIlk6HmkT3qlX/qTgQCmf/rACQgAOwAA==

------=_NextPart_000_0008_01C70FED.C69AAD80--



Received: from adbglobal.com (76.pool80-103-127.dynamic.orange.es [80.103.127.76]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kANIAcng028615 for <[e-mail]>; Thu, 23 Nov 2006 11:10:38 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c70f2a$8184b6f0$f90ba8c0@asfngt>
Reply-To: "Josep Arceneaux" <[e-mail]>
From: "Josep Arceneaux" <[e-mail]>
To: [e-mail]
Subject: Re: cattis
Date: Thu, 23 Nov 2006 10:09:23 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C70EE7.736176F0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C70EE7.736176F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

V t a g r a   from $ 3 , 30 http://www.daserunjinketunhdas.com
=20
  _____ =20


They fled. We found it in their skyship. I touched it, unclean,


------=_NextPart_000_0001_01C70EE7.736176F0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
V t a g r a &nbsp; from $ 3 , 30 <A =
href=3D"http://www.daserunjinketunhdas.com">http://www.daserunjinketunhda=
s.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
<BR>
 They  fled.  We  found it in their skyship. I touched  it,  =
unclean,<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C70EE7.736176F0--





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 kANBWG2G096823; Thu, 23 Nov 2006 04:32:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kANBWGLE096822; Thu, 23 Nov 2006 04:32:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kANBWCsA096814 for <[e-mail]>; Thu, 23 Nov 2006 04:32:14 -0700 (MST) (envelope-from [e-mail])
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.20; Thu, 23 Nov 2006 11:32:06 +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, 23 Nov 2006 11:32:05 +0000
From: Stefan Santesson <[e-mail]>
To: Anders Rundgren <[e-mail]>, Stephen Farrell <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Thu, 23 Nov 2006 11:31:47 +0000
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Thread-Topic: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Thread-Index: AccM2o+SceeV0JHYRfWt2INgLb4mIwCFx5VA
Message-ID: <[e-mail]>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v> <[e-mail]> <[e-mail]> <00bf01c70cd0$5e76e6d0$82c5a8c0@arport2v>
In-Reply-To: <00bf01c70cd0$5e76e6d0$82c5a8c0@arport2v>
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 kANBWFsA096816
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders, I disagree with you proposal. It makes no sense to me to do such recommendation in the generic profile.

It is a totally different thing to make such SHOULD requirement in an interoperability profile than making it an a base standard like RFC 3280bis.

What ever goes into RFC 3280bis must be reasonable for all implementations, not only those with a certain scope of interoperability.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Anders Rundgren
> Sent: den 20 november 2006 19:19
> To: Stephen Farrell; Michael Ströder
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
>
>
> >> I fail to see the benefit of using "and" instead of "or" here.
> >
> >> Note that most times LDAP servers are hidden behind firewalls.
>
> >So, it looks like only Anders wants this change and its opposed
> >by some people which'd argue that David ought to leave things
> >just as they are.
>
> Sure, David have already defined this the way I propose in "his"
> (NIST's) interpretation/profile of RFC3280bis, FIPS201.
> Probably with the same prime motive as I; to foster interoperability
> among a wide range of standard and custom client software and devices.
>
> In the presumably rare case you are in full control over the entire
> spectrum
> of apps, you may IMHO do whatever you want.
>
> Hopefully the FIPS201 document will serve as the "gold standard" in
> this
> respect rather than RFC3280bis.
>
> Anders
>










Received: from [207.35.91.3] ([207.35.91.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAN8Cx6w079533 for <[e-mail]>; Thu, 23 Nov 2006 01:13:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c70ed7$31222fb0$00000000@dbeaulieumist>
From: "costume" <[e-mail]>
To: [e-mail]
Subject: la presse NMPP
Date: 	Thu, 23 Nov 2006 03:13:00 -0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C70EAD.484C27B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0003_01C70EAD.484C27B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70EAD.484C27B0"


------=_NextPart_001_0004_01C70EAD.484C27B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Keeping a staggering Life very. Partner theftrdquo charged.
Certain original intent bringing dealing promised given April.
Dover dc Maryland Baltimore or. Analysis Archivesth daudience roi. =
Assembling group included schools College city rep.
Leslie Payroll Procedures. Arizona State System credit mandatory of act =
restored is equivalent.
Represents Commission intends or lobby long wouldnt hesitate a point. =
Lost dog ad listing. Countries production costs.
Catalyst involving houses oil burner caused correctly. Tuition waiver =
salary adjustment am occurs! Sing through encounter human worse.
Theatre Mirage seating panoramic surround sound!
Working above criteria must each. Sing through encounter human worse.
Starting rd la presse Nmpp testlaunch in.
Premiums arrange payment returns rates same deduction includes.
Hotel noticed large west Tropicana a Field a Dome. Minimum target =
percent belong nonreader age Britain took. Afternoon freesheet Metro =
closing edition of Copenhagen launched test run.
Accrued used unpaid notified of begin formal required! Operations Morgen =
won eighth is design winners Bergens. Type Cirque du of Soleil =
celebrates.
Partner theftrdquo charged. Sick playing benighted whiner onslaught =
surreal a cb? Beloved enjoy whats of.
Buena Vista Nightmare Christmas Oogies offerings Iivideo Nintendos =
Legend. Beloved enjoy whats of.
With his own.
------=_NextPart_001_0004_01C70EAD.484C27B0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Strategic focuses primary =
Robb" hspace=3D0=20
src=3D"cid:000201c70ed7$31222fb0$00000000@dbeaulieumist" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Keeping a staggering Life very. Partner =
theftrdquo=20
charged.<BR>Certain original intent bringing dealing promised given=20
April.<BR>Dover dc Maryland Baltimore or. Analysis Archivesth daudience =
roi.=20
Assembling group included schools College city rep.<BR>Leslie Payroll=20
Procedures. Arizona State System credit mandatory of act restored is=20
equivalent.<BR>Represents Commission intends or lobby long wouldnt =
hesitate a=20
point. Lost dog ad listing. Countries production costs.<BR>Catalyst =
involving=20
houses oil burner caused correctly. Tuition waiver salary adjustment am =
occurs!=20
Sing through encounter human worse.<BR>Theatre Mirage seating panoramic =
surround=20
sound!<BR>Working above criteria must each. Sing through encounter human =

worse.<BR>Starting rd la presse Nmpp testlaunch in.<BR>Premiums arrange =
payment=20
returns rates same deduction includes.<BR>Hotel noticed large west =
Tropicana a=20
Field a Dome. Minimum target percent belong nonreader age Britain took.=20
Afternoon freesheet Metro closing edition of Copenhagen launched test=20
run.<BR>Accrued used unpaid notified of begin formal required! =
Operations Morgen=20
won eighth is design winners Bergens. Type Cirque du of Soleil=20
celebrates.<BR>Partner theftrdquo charged. Sick playing benighted whiner =

onslaught surreal a cb? Beloved enjoy whats of.<BR>Buena Vista Nightmare =

Christmas Oogies offerings Iivideo Nintendos Legend. Beloved enjoy whats =

of.<BR>With his own.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70EAD.484C27B0--

------=_NextPart_000_0003_01C70EAD.484C27B0
Content-Type: image/gif;
	name="value.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c70ed7$31222fb0$00000000@dbeaulieumist>

R0lGODlhOAOsAYf2AAAIAIEADQeGAHxyAgcAjo0DjQCOd7K+ycnYsq/E7EIXAGITBYQWC6MtAMgk
CegXCg4zCiRDB0g6AGQ6B4NJDKtLAMxCANhIAAFpACRoAEVRAFtnDXhqAKxpA8peB99jAAOMACmL
CEiDAFh9DI2IAKB/DsGJAOWJCAWYABqiAEijDGGqAHOVAKKVALOeANycAAy3DhuyADO0AGu1AIrL
AJ3JBc3BBdq8AADuBRPoAEjlAFTYAI7lC5PUAM3uAOfkCgoDTR4AS0EAOVgAO3QHS5MNQ7ECQ+IM
TQAfNR0oMzYhN14dPHkTNKQUMsMjSOIuPQBCPCtEQjdLRVI3OnE5SKZDN8A2Nek7RAFrOi1XSDdb
P2ZuOHRXEZdnS79qSutWMQCMRy13Q0l0PmGDN4KHOZR3RcdzOuB/NAuYOBOWQ0alO1uUNHakN5Op
OsOTTe6kPA6xOBjOODzMPGnKRoW5PZ2yN7S5Nua/QQXoOS3UNUHdSFTcRXTpPqvgRr/aSuzUPgAA
gxsEekcEdW4BjIkAiawAeL8GjtgFewgbehYUgjgge2EugXkffJseer0tgeMRdQBDfiw5dThDg2NA
fIFCcaxIjbE3de5LiQtjhCdkjD5sdlthc3FrgJJjhrZleNpZfQKBcRWFdjFziG50iHl2dKCIfMB6
ftt1jgCaeieueUOZdGCleoOUh5mjc8KYf+mkhQDCgi25dUzJiV7Ni3+2e5y5jLXLjty3ggvqiBXR
eD7phWbbg33giavhf7HYderecQQGtBwAu0cAtmQAt4IAxKUAvcwAt9oAwwAYvSYbuUISuWcjw4sr
zK0Wt80Rw9wRxgA4yyo5sk4+xGwxzHhAt6hKxrdDteM/vAVmtihfyDJltGJXsYFquqhTtcRayOpc
tQJ5yiN9xz2BvmSAw3p9zpKLyL16uuGJtAqqsROow0ygvG2uuHmVy6SdzsCaseCkxQyyvCa3wEDK
tl3LtYq8uqjCtP/0+ZmYsIOOgf4AAAb/AP39AAAL//8A/wv3/f//+yH5BADF1WUALAAAAAA4A6wB
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0aM5/SJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXcu2rVulRuPKnUu3rt27ePPmfcu3r9+/gAMLHhy4DOHDiBMrXsy4sWOzyx5Lnkz5
rZfKmDNr3sy5s+fPoEOLHk269OdsplOrXs26tWvMJl7Lnk27Nms2tnPr3s27t+/fwIMLH068eGa9
yJMrX868ufPnRBkDAGC8uvXr2LNrvzpzunfo4HGG/wtPvvzMHubTP9zOvr379/Djy59Pv779+/jz
69/Pv79/yhGlZU9YFP0H10SKFWjggsCpNxKDEEYo4YQULhUgWgOCpeCCGx7WYYUgpuagSCGWaOKJ
KBp34VkZPpXPi1N96J+MgtGY4o0AjggSZi/mg+OPQAYppGY9DmnkkUhCuKJZLTpVpFQ2yvfkgRIl
iOBVMO6XpWhb5tclUjruWNmUR5Lp3pf3oemZmvWxmWRaZp7V45xzLkUnnUrdqaeeTO3ZlJ957imo
m38Sip2h/wzaJ6BIDSroongWGmlSjjI6FaI8+hiVonZaWimfnU4aap2BfkoqVZi+2dWpU54qlqOj
3v9ZqqlxWkopqLfSGidUu26HKKeziqprrbJK6mqiw2qKqrKh/fporK4my2yjxUJ6rLRWparqVsPK
qS2y05a6KZu9isuroeVKKmW4TrJ7rovuBtrupfFSK9W330qWar5uOjvvvfUiC3C2AW8LFqxw4kuu
s/Gmmy64ABdsLnz7SixvofTCO+7GA1eV72MVY+kupv0GjK7EClOGx2hLltWktQXT+PDEkI5bb7kz
P4wzma32GOVfUZrZ5a4p//uuxkgfrXTNF1NrcWBCM0v00wIbnTTGV1utNc1VOy1XHTpl+jG32u5s
8snszgzxuTf7ietweGZZbdMZb70ox3d3vDTMVc//7Vjcmvptr8cNF3yy3XnvHWvfou7XMlkvQxuV
zENPzbbNmIe67NmGI/zPz36BDq6tnWr+p+KJ2x0y3vA+m5nnWOfqJOqlo7467cFWG+ZHlD2p9qpf
Hrt2u1KPzXPZlVMNs/LANR677KlHb/y0yNeulfObYW899NtLz3zXg9d9K1fa9/f4WJE7zX1TMh5P
bOHUTy838vF/7zSbovOV/+jLlp524dHb3Pj61z2CjW0xwtMajP6XNfARTlnVK+AD3bU7j+greAd8
YLACyLXf1cyDw1NfVooEwuYFDmXxS9TpGnjA+RGMg3XL4GFcqDd7pU1xLTzhCyUYQ/vJ53xiSZ+a
/9zUvi2RMHmX45oB+YVB+x0RTftzS/7m17mLYRCHPkwgFq93Qh8Shoo1pOEAt5ZBLbLQiV1kSgU7
Yp2e+ch9bCPdBLECOw2KUDuVC6MO6bY8M0aMjq7bYfiyVzw9DtKB0PJj5pYoOPEh8j81IdCVzFWn
49nsbYD8GLAMaLqkRLEtoEPT4UQYvEuWj17MCyThYHhBVobPd9QzpSIXOcFTntFCa9SLJKtkOlhC
kFBRy+IsO3lHO3Ltk2z52RDPNsY83pKLTHSl6rz4l2XizYiFfOYISyjKVDKQSrm8yy4f58s7OqyJ
0AzhH5W4zu4hcy3KHNk1f8nHAubwkKzDZw3zRP/I2SkNm/Ws5z0fqc1VrtCT4cTLOCHyQWzSM4nr
syMIgymgSXrIoq/a4yCZycN5CnKM7xEj+DgaUL0VraQaSihG2rhAhxZTXRPLGRIFGFMZLkikAN0i
SBX4tG6itDg4fWhB/fVTe2YzRZdxSiRTystcRQuMECUeLV/auql65Z1qweofr6jPohJ0p12V5leJ
c0TrjRJ3+rxdA7miUnEytWVPpCTn2glTYlbVql3RKoYwejCNvjKfiOsqyVDoK792jaRoXZgj17qV
ttploevJ3fLwald2UpVpUf2KXlnE16+0FGNnxR0wq7hPlj7ys2gFq2pX69WxYsWxdYGsQyRH27v/
tm5ko+0c56ipxs4GZrMas2Zopfq84hoXs4d6IwOHW9eOhpW1Ec0rbIHLGsHZUp3Itax2L7vdE6HW
f6WF4WABK1bhfFdepKXdeFPrWoPpBnvX1dkyUTjXzP5Ii7MkqnOLqt/s4Fem4VXrcfeLo6VqFqPw
/S+2cve+uUnLpuzzLWCoayzi4TZZifyfgxeMx14puFsM1rCwOPzW6RZFtg0ZlYVvC2KnOi+QD+Zt
b5t6URqHxWwsplWGjfVUDBcWfjk21Y77WDwfo9jEC3GvkpfM5CY7+clQjrKUp0zlKls5OAa+qoT1
Q2H0bfnKV0ZyXI6cZAZ1OYhfBnOVxWwUMitE/0lp1l+c1SxlNp+4xJHl0JyluGc6P9nOefazoAdN
6NxkWbo2nlGfk7noQhsM0GKGM3kcDWZII1nS4aF0mC1dZk17+tOgxgwQ91qQUIvmIKZOdVbUI+dS
q9ozqH61rKGk0Fnb+ta4PnCgGe3qXOeo176+NavfEutgS6bYxp71SaZzk1YTJNnHNgi0OfMB+lRb
qSRh9klEw49u8wMp3w6Ot5ni7XCX6APovnZS0o1upLD73epWyrv/oW54z/sq9k73uvXtbnYv5d7x
zne7981vqMw74Pl2ir//be+tCPzaC+83vx8eb4c/JeIETzjDJ24VjNN74Q/PeMbrLXCmVLwt0/9x
doqJLe2ldFsp3za3uJ0ic0wPhN4XN7nO/83wdcv751k5ecWFbnKEE53nSI/K0E/uboMjfOc+t3jS
Pw51nEe96V1hOtX3DXSse73f8h54VbRu9a5f/etoTzvTtR4Sbe9E5QJxeVNq/puYk7tCqCb70c1e
9q4HnO9jr/rX9z51tQu+KWtXeM4RX/i+47vq1R662f+edcZbvu+UT7vmDb54wBNe64Q/Ozg34vaV
eIbu4CZ3uWH+8nH/w/Wvf3nsYa962bs85rQHN+1XbxW7y732Mh+363M/e+Kz/jeZd7zyD1/25JNd
6VSBOPMNL5Xnax70nS986DsOfcmfPflaSfz/5Z0vesB/XPyDn/7O9R79taT8twxlObBRP/ffJ8X2
+If56+1//+DP3f/8p39XEW41V4AA2H8ImHr3d3f/R3+rkXeTB3XYx3nfF37l93PoNxX1ln2KF3iX
94Hb54HLJ30VWIJS13hAR36bd3FiF4Hlt4E593wwyIFgQnoy0RkOGIAKuIP7t4AJqINAWID1B4RS
QYBE6INI2IM7SH+oZ3u+IX0kmHTs135eMYMdqH7jR4MfCH1bOHXeZ4HXl35X+BUZyHwTOHYtmIJW
h37W14YXaH43koNJKIBKWIdCOIRPQXd6iIdzOBUHWId8+Ifm5oByiHxNF4VhV3CI53EoiBX3/6Z4
Zah0jPiGRaeI0yeDiWiJjjiJMziFYBGJ5neGZHiI1zeJPieDpkiJKFKIhJiEgpiHt1duexiERwgV
B6iHsviKSJiLsogdUBiGK6h+1keFyxd1Idh5nsh9YwiHYhiMGniBlJeMVdiFobiMlYdziHh1mFiM
zceFQsKKsMiDuoiHTsiD5giIu6gVdxh8syiOdFiI1hF5p5iFItiIj7eC4DeMfkeD+iiKzIh59viM
wIh10niNAQmK3Bh03ciG2XeGbjgk4BiIdGiHNNeH6AiIrXiOVLGOFnmH7qiR2yGPpHh44PeG+lh9
gveFqth421eSm1eQaHeMAumC82iNXOGPJv+phRa4gZGoksV4jCcJIkzYkfw3jvbXhAw4kXcHjxUp
d4PIhxSZjr3HlK8hktjYhS75k6OofSlpjS0JeTbJjf4okyjphTwHkyfYiDiZk5UIiTXJknBJkmEZ
h7cXgB4ZlalngEpJfO34f1vRhH84exMZmLjYgMFhlVbpeYloj0FJgTTJlSj4lV6YhmgJdlwXmWD4
mJZJjTepcE83l8oHemn4lon5gnAomQFZGqPGWcBWfEzIe/0ne8Mnm7pnfL0omK5Zm4RIlazHl7Eo
m603mwTohLmYh7zJMi3neEJXcqf4iBs3mmiocedndEvHiCE3cs4Zec4pcfDmmaO5nZrodBr/l51r
l4qOKJ56l4rd6Z0cuJzSiXERd52NuBfZcZxjYZ/Tlp+ZOR+N+RmrySTJ+Rb4CRYDaiTIpp+T0Z/F
QXbDxmetyRYF+hURKiQHiqCPoaDEwaC1Vh3FuRa8aKEgGqIiOqIk6mv/6TIBWqKhIxBdcHMq6mgN
Ckopeh0V+qK+UaODwWk6unI22qM+eiQnCjkzah04+qO2UaTwt6NKulLy92zbgaRGOhtQCjRLWqVO
GqVYmqVa6hXGp45duqVgGqaHsXoTGhVlmpRimqZq+hfEeabhKBZuuqZyqmZB6mWtiZRmEacWiWfp
M6eqOaQ5aqWC+hlyCJuuGZzDOYuG2pvl/4imNKenfkob3kEdSjGplIoUltoUk4qp3sEUmRqprxV/
DnqlIKmUuziIT6l/gYmRtmimjRojgAqqoYFql+qpS1Gr/4CrmGqrt9qrCCWoVUoZfmCcOdiXRhl7
aIqnUKl6svoeupoUtfqs0lqpvOqr7iEGImqbSXmsF5mqjrqnzUof0Uqt0OoU05qrmmqu4WobfYmX
7nqRPZiR37qu9UGp1GGvt2qpm6qpz5qr+tqp9PoUdYpmDzqv3vqR5jiU8AqvkIpLBRuwnBFr+Iqv
5EoVFGut2AasS4qDTXmURbmX5Nix8wqx8XGv5Yqr/Zqu5YqxJEtruwZPyamsS5msIPuxI/9bqj/I
HbHaspUhsei6q7qashW7skM7Yxq7ozh4l8xqswlrh0pbrEX4qjwrHCYLtCo7tP0atNU6taeXm7Zo
gMCZqLi5qLH5qrwotVLLtcGBsk+hr5UKsJz6fm+7r2pLGw1bt3ibt1yqt3z7H0JrGgMrW+poaDvb
t4gxpSt6tB9RehUEd33agGTrGohruDVSuFSquB0BAG3luOwxuZQ7YZabuJirEZqbaZ97urn2t6i7
uqw7FarLGoHrsqTKG57butlRu1aiI4yrUgQ7u7uBu7ZLpKHbGDGxBDJRunnRCS8bvMwLZq/radrQ
vI72vNJLGtFbvYT2t3TbFZ+ar3IbvNr/EL7iG77YO21uu7XU27ZCO659kQxaer1JQb7l62vRqrUs
exXau7WyFruTM7xLAb9KAcCaAbzz+xvFZr9Ee78WGxVZW4Oj+xOfIcBIAcDiG78S/A/jGxXjS74C
vMEXbMEFHCGq28BYMcLqamv8CxUEfMESfL0u/BQfPMH/28FM8cEVPHpxF8Kdm5zfe7UKLBUmrLIP
DBQRXMNNEb0xHMAwfMRKzMQ1nMQ6vB/bm8BFu8D+2sM/q7+rS8NHDMXx6xReHMNeHMUSgsA/zMBZ
nMZqTMWo68E2XBVvLBVunMFW8QBk7Lc/nL7QasYkrGyiqmu+K8dUMcYy7MQaDMguesc0/8rD+tvH
VoHF7MurQwzBnUHIhIzBYDwVl6zIEPK9PezIj4y+J8wgqrAglgzHmWzImGwV8svJ/HGvU7yreYzF
Vcy2ZxxqKSyw/lvIgjzIUNHBLfzEXSzBBOzKUjqk61vFe5y/bJzGtTrJPrEZbjzMHvzE02zNrYzN
2TzDxrwg2gu3/DrC4Oy9etzN5ixl5SyruZyxgUy4D3vOtIvMvwbNsSW4BrzL8PwaxUwY9MwT+fzP
frrOEfbOtbHPAP2nBB1t/UwXvZvIvWHQB42cCf0YC13Po+rQEAvRk6HRRlvRHr25TYrRAcvRFI3P
sPrRKJ1QnMuzJO0YLf2rKR3Tu7PSLf/70oxh058j0zqtIzRNsjidu4FMy1Sx00Qdo7zmu2croWmL
az+dGDUq1FfcvTld1FQ9F6Bxt+AKoWe71GNqav/qqekc0bP6x0ct0liNsx46mJNx1sRr0gMcoHI7
zv6qwlVd123WtWfB1n7osZKh10jyyUEb1mIdInrKe6/ZqIYaua3qisBnmLr3qGHLqGb7oY9qZVD9
tqBxB4Ntt8X3l/5XmH2osL2n1jmrsEZ4fAuotAzrh1y9ZHIN1lKNGXeg2ZvtGsSZFYBZhMtaplQ5
lKJdswbL2moW28u8x51B27XN2WXboRoJjzKL1nu9kZW9rAj7rX7tXpeN2cktImQNsxP/fZy/vdxm
W4vSTayRC7WBuNXteswTDRpImt2cCtN2Pd+UTBrgLbLISoQH+5fTbaoLu9pZfbPZi7KvC9/b3R9U
UN6jLZE3u9+DG9zUvaerutigBrevDdbGcQ/lK9BaUWzPHd296d9Q66YfDuD43bRVwZStLWpufRw8
/NX5iuEOTN807s+cUY4Dyo5Pu9QrDuJ2Od5mWpc6COQd2eNNBtWeLNgH3h+36aWRvdy12d9OTra3
KZzM/Zu+h+W7qdhGfuTrS9woAgNbyuGr1uJ9cd1pgeYI3c6k8dSCXeNw/nb7oeZoQed0ZuBL/hbj
cNEM0dOOYedk0eXC0dSHa+a6HOeI/35o8kHZldHkef7okO5e6xDpi0HmodreAW3o8yzSWpbons4Q
RkASlD7qpF7qpv673Z1Vmt6shG5zny7Tpx7rsj7rtB6xqV5RmG4iX3qjq14aAvDrAgAVwB7sUkHs
WgHsdP3qL+ECB7ELsOXnZQvdmDGhtinoKQ6nbW4Qw27s/7DtjbHtyO4V3P4U4+4U5Y4V5y7fyp7S
V/3Z9q3US1sWhf0a6Z7uiTHu9l4V+Z4U+x4W/V7rm1HiHAvvqpqn2C4b5f7vg5HwXfHvCi/uAD/Q
sxXSOQySqKrjsZizUf7YwDfZnd3xu96q7t7YtafxCnjeji7eaWvtfVFsDM8U3t4U4f/e7b+OFMOu
FDFvFS9v8zXP7z0v81OR7zcv7Df/8jM/4+uO6D2t4hB+2r/n9OeY2xIuoSefsBMer1E/9frN2oBe
5r228/y+FPYe7D9v7Of+8GIP82qf9uYe9G5P7mKf8GWPw0nv0QPv48393/sX3qG99XuL9Xrv24vN
93kftaHB7WAf9jI/9mufFfgO9GwP+VHh8MLe+IqP8wBv6Trba72t36xI+Cgu4gSalwH+mkEO+ujY
9bhOqohv+Zjv+q6P9nGf869f+7Av+ZUP98Xe+HUP6zeu4ESp2+bN6Fkv4NculZJN5LCItupt/KbR
+rMP7mc/+ZGP7rCf+Lav+9RP9Ef/n/3dHvG/j/fdKv7+feICP4Aii9gRfnyov/6rQezTr++7b/Nc
Ef+Xf//Vr/25TxX2j/+xDhD2BA4kWFDgP4QJFS5k2NAhQ4P2EvJ7uJCixYYXK/7TmHGjwo4cHYb8
ONIkQpIiPW7UmDLlw5clZc6k+THiQgEIczLcKbPnw54/a/4TqhMnT6AlizZcWrHo04QRpU6lWtXq
VaxZtW7l2tXrV7BhxY4lS3Do2YU3UZ6caNFlyZgqP5J8GXdm3bYM8bIEqZem3YmA0Q5+qDbhzqZN
mSolSrgxUoVQHSqOzHjy4qOZ/5Xl3NnzZ9ChRY8m3dXxWcNyUdIF+Xbua7cYZfvt/1tz79rWriuy
nh14ZV63gk8PT62TsmTNTh8PRn4Yp2LKzj9CF7oUeWns2bVv5959ahjvw2sW51e+PEzzHFuaZx+y
PfuR7YOfV09/vn2Z8gOnX83f/3v86pvvvpjei088BCsqjqjoBHDwQZ4elDAp5iSckKkJITTOQgef
47C6D6tjUMPILrRwM+9SVHFFFlssLUEYY5RxRhprtPFGHHM8LTode/TxRyCDFHJIIos08kgkk1Ry
SSana/JJKKOUckoqT9vqxwWr1HJLLhHKskceu/TRRTLLNPNMNA8Sc00223RTRg7flHNOOuu08048
89RzTz779PNPKa8c0yBACy30S/9D2UxzUUYbdbSsRCOVdFJKK7X0Ukwz1XRTTunsoFNQNRW0R0RD
NdVLQk+V8VFWW3X1VVhTVXVWWmu19VZcc9XVRuF29fXXjQQBdlhiaeSP12KTVXbZSEfVMTUAAzS1
V9rkLC4AbLH9JwCGuL0zW3C9XTVWcss191xGsZQVuNVopbY3N1MTFyFtF5rXznvvRRBdfvv11zN4
/h1I3YLgxe3Ud2ub0zB9t+1WT30btlJgiiu2GN02devvWL3kowu+/QQUOb3/PgY5tpM7pq8ujvfT
b8DdUvZN5tgSbHjecMHttt5teU4o3J29zfYhnXuWuKKIFRr6Z56LptdpZqOWek3/3tg9WOF24XVv
PeDs8xrrq32zWr2+PgZ7bJh2M5hstEVG8Gh7ZeK2aaXjDvrnhnB2+Kyk7a77b7+nFnxwKt1bWzXE
w9a4I8bZbTzssQ0/m221f4PN8sgPl3Y4uPEuyefAPQdcdHp3RivfvB8evXTCWwfW2RzJexlyx+Fi
6/GDcZerQIMlP3xtam/Tutp91zUadNKRJnr51fdmXfWhcr4Z+uTnvfh67LNflE3dNwaw7d9bwlr8
2r038Ozu0f6eeL4wB7vqIKf/nPnUm9e7/uipfz555/d3/f9bwQ5H0Bre5Sr3G92R72oKNOAC2ZK1
yfVKeAWcnGNK1T//0U9/q+tb/wY9OD/9dRBw99JeCU14wu1wj4IHZOH4XOjArt1lhS/UnAzdBznf
4UhiIlSeQ46GusDt8HT4y6D8MLisJwDwdVohmFkyB74Kpg9xCSxf7vLDPpNF8IHtYx8Ouyi2oahF
iKHT4AaPyMOIda6M/uMh3vSFQjjGUY5joRrmzPY++E2RhlREXw69GDI8TnCCM/yjymC0NP5hEHlH
DJ0R+ac3Nfpwg/kSYiSVeElRMXFQBZud2+rTMpcVSGYgKxkpV4af84VyYyq7CMf0A8pUmg+UnzTZ
KTe3OZmI8XiLfBoilSa9vEGtl/UC2i+JGT3p7VBnvkzkHJ35TGhOBZPTnJQldf9ITWxmU5vbHJI1
beRNbjIkieG0liZJZTxyrumCYgJnjSQWTXjGU55UaeLA0hkvdLJTmEDKWUPm+U+AwrOearqnovI5
uIAmVKEYK2hDHVqTIzxUojFaaEUtelGMZlSjZ5poRz36UZBObKMjJWlJueIIk6ZUpStlaUtd+lKY
xlSmM6VpTf+FD5vmVKc75WlPfcqikAZVqEMd6k+NelSkJlWpS2VqU536VKhGNVZQkGpVreooomZV
q1sl51W9+lWwhjU7XCVrWc16VrSmVa1rZWtb3fpWuMZVrnOla13tele85lWve+VrWcX6V8AGVrBY
6WthDXtYig5WsYtlbGMd+1j/yEYWpjYCAWItC0BvXBZIkuVsZz37WdCGVrSjJW1pTXtam2pWtcyy
wGrxhFrYxla25nJtbW17W9zmVre7ZdYyePtb4J41CsElLqh0UFzkJle5y2Vuc52r3EE8V7q+mm11
rXvdiFAVu9vlbnexN13wBtUThbUoAAAg2TZ4V70/pZV5ARBe+MZ3Ixt173rte9956sq8Es2AfP27
V/f+V8DOZWl98XtgBH+3WO8dcIODm2AIR1jCE6ZwhT/rYAxn+FIW9moUOPxhsGhYxCMmcYlNfGIU
p1jFK2Zxi4ckQLuu08UzllElWMVXGdNYx+JR0Y59/OPYmTOvOQZykWfSYyMn/1nJS2Zyk28E47oS
2clNbhWOZQUOLGd5IVnmskK4rOUvhznM/xBzQ8QMDoScWc0wUnOb0/xlM8M5IW0u80bGvCQ03yjP
Prrzm/b85i5/pM+GGjREUqTcQtcZ0FomM53lrOhFB7rRjmY0gih950JH+s+XrvRDMk2kTsso1Dn6
NJdCXeotyzlRqCYSlOlqmEGf2cuP5vScYw1pTv9ZPLnGsq0lPetf57okrObzr9lsbFKrWkzKnvSo
44zsP7Eayci9dZ/rLGxfB1rWwKb0sXmd7V4zpNrdFjSzhUTswaBb1ObWUqLZLe5390ndmxUyXmGt
7G03O9zz1rS+Tx3vdX/b3//P7jS/HWLwGkHa0ggfDsOThGuAb4rYVd7rvSW95n4PfCaXhje0dYTq
T4873Omm9cgPTmyF+zvi4Da5ps2d8o57XOS6tnOpVb1yl2u75P9GNswJ3nJ8vxzdPp85isKTXGtv
+9o453a+m07zHoGc3UUnDMdjDnM6P33lWWd50DF+9Uwn3eM/D3uXv+5pNw/c6TPfutcr7e6za73n
N2e6izGNcbGTO9Vx7zrfYyR1gefc6Wh3NNgVTu7CVwTxXLe63Jl997Hvnet99znlGV1rllve2U/n
fMYFP/fJZ9zhic2KlQsmerzvXO+Sf3fgZ0R0Xo/c9SdvvMZFnnmVR17fuJ//fO1zz3aND3v12Ca8
0jGv8kjjXvEXz/umVa9ryBd8zIOednGnb3bsPz/tZG+54yu/8LHH3vm+p73O6R7s83ef7DLBOdzN
z/z0yz705dZ+15W/fGMruvl7rvvV7R98qgs+AJw/Jrs+MMu+tzs+w4O6zxs9mgA84vu977u//es8
5MO/zTO8mss/t5M/DkxAv8NAk9s//mu/x6tAz5vA8ssz45M+9IM/FwTBwSsSV5srizvAfUNAD8zA
4os3B8y9B/TB2LNAtDjB99M7AhRAEQy5DoS+52O/JFxBJ4TBETTBD4zBHcxCfoOz1JPBxTu+xFMI
itOrG1y67UO4KPzBGVzC/x6EugAswivMQQUkwC3cPgo0wstjujCkP57zwvHjwfsTQBRsQCjEQQOs
QswLvD1ElaOjtq/rvf6TQPVTQxXUOimkOf2LRLBjPRaMwM/jxJqwQ0HEQzkExAY0Rc9DvRdExVGM
vxIUujVcwDKLw8QTOPITkhqUqzJ0RVcMwkVUwlCsxEAkwjvUPT5ERD8kuVVUv41rQlBUPvd7RR1k
wE2ERmc8xinEQmlkxmG8xFnsQ24kxktUQhBrEcrzvm3cQ1krOwUMuAxkwmX8RQ28QGCsxuTrRnvc
vUA0QyrUQmtkRX5MRnx8xmIUyNsTvugDPVRUt+ZLi0NDurU7O0UMSKDzxP+/E0JoYztR5D6J7EV6
bEIezERt9MOIHD6PxMaS1EaETMg/9MePNMaci0l7DMBB/MEUS0mN7EKQREebxMY2XD/NGzrfq73V
+70NFMVHLEqlPMmjtMM3bMM8jMd/3Eio/D9ZJMWO7Mcpo8dPPEXty0aSpMoEgcBJBEmx7Dysmz95
VMG1jEabQ0pSbMa4e8ol7ESpTEV5rEqXg8qpC71oPJJyJCiuNMqg5MK0/MoQBL937Mt4jEILBLhY
BMKfXMnIg0djPExwpEbuA8pU9MlWFEi5Gwq6XMCmHDW3jIrArL6tXE2HTM1GZE3YZETX5I7YrE2j
m80Usk3YxM3u0M3dfEj/3wxOF0tN4dxK3qTN4nQy1UxO5hyxXGxO6NwmhopO6oRNBqtO7DysrXCv
67xOh/DOhABPGwkwNhHPoTBPH0FPI3mv7twvHBFP9WSI+MQT9iSM+SyJ++wS8syT/VSI/AyUE+pO
mfjPwejPhSDQ8wzPGGEwBm2I/GxQ+XxPhEDQiohPCp3Qf4BQHYHPmeDQ4bDQ8XyI+uxQDM1QB8XP
Ei2SCxVRB+VOmhDQs3DRDOXOFTXRCLXRF5VR8dDQ/0Qh7xxR8gwwBnVP9twv95zRBtVQ/6xQGqnR
mlDSJ01RIXHSA11QG6XSGL1RFJ0REK0R9RzRKMXRBBVTOfFQBR1Qx/hR/y0N0yol048ATyw90fEI
0CUFUzGFUxOFUDAt0jNt0yIdUiMN0hnFUCJtz0I10gkVVAPFURj900AV0D+VTxfdT0Bt0SPl00FN
1EuVUk0F1CQ9VEdV0EjV1BMNVRnlUxi9UkX1VA/V0VM90/qkVB0NT1BFUk+1VVEdUlolUiTt1F4l
1DZlVEKd1E0dVf8kVkM1T0y9VFnlVUrNU2Zd1FPtT/R0VSEVUl+F1vnE02w90CClVmTdVTP11mi1
01j9VETFVVK9TXJh0zzN1Dv1VSAdVmzdCF0tUSXF1ETdVzfl0Xjd1CVNUT3l1yuF11ZtVGENWHy9
11blVG4dVliVU33dU/97ldKJ7VMOBVhOfVdRrVOBNdh4VVgoxVeL5VdnrVOETdjvxFiSBVlo7VNY
hVSFpVWTDVmUjdhindmQHVeYtdOPVVONlVOYHVo1dVNV7ViiFVqO7Vl4LVhgRVqj5ZLt9Nh9BdqO
HdiHZdGdLdmHTdWIfVqw7dd3TdmiNdcbLduo3dqP9VOHDdaldVq2tVo0/dcqjdVSndmMpVpglduw
zdqNdVq0/Vm9BVwStduWRduiDVi+FVvBHdq3TdLBzdqRtdV8ZdzHtdk1jVrJ/dvKTVxx7Vy39Vl/
XVx2zZ6U7VthndelNduzVVyuDdZGfVXU9dy9TdjKvVy2/VpppdG1VVX/QSXTzQ1cykXdX2VSuvXY
PZ1UvI3QxdXX2dXZ4k1WPeVdlXXUdG3Z4mVRwyVcnIXezqVekc3Vaa1Xkm3e0P3buuVdMzVb2iXY
np1Vtc1del3U9FXe5eVWSKVe8pzOAX3WZvVdw53e25Vf7g3b6o1f9vXesdVd123f2/VbZWXZwIXg
yMXegqXdbX1d5IVb3N3YBL7aCm5fBh5h2IVaprXcld3ege1exwVd403dNWXdD27br2VSnoVhE75h
zN1co3VhNOVZ0h3dF6amB9ZglgVbXn1ex1XZAr5gBd5ar0VgqE1iCs5h7D3ZKa7Y4w1fgWXdplXi
p5XZKe7aK17hK7bi/wle4hImYSduYSO2XDFGYhne4iMtWRS+3PXdYuBdWYzl4QjWYwoOYprFXzRW
4y15TiAhX7iV3SP2XUYF0t/l3BPOXshdYmpdWGV91rWt15Ed3wF+1DbG5DcVVw9+3+0l1YMt103e
2evd1WPt1fZU1wNW18QF5VG2Y0omXnJVXPpN1VtFZSjmZZ+V5Uxu1mQd5GzFYP2V1GF21e+s418m
V1VOZkTtWkiOVtnkqexEizj1qG7uKKPa5ix9q2+eKO0YADhSAqkQ5/6t47SCX7ZCIXae53sSGHq+
Z27CKnze5ySjXyIpZyjp5UoB6B7x5w2VkT/mYxgR6Iny2yaJU4JeiP/heui5VVprneY0ZWZ31uK0
tVcDPeaKdt0nhWf77F0vTZL//NJjxWhDptxWxk+SluQettLWzdwciWgqSWm3fRKV3lJD0WlmZlrz
zWidJVAsLVuNBWoC9mn0LemCRumQduU3/tEHhV6O1lyltenT+GOc5uZIUeqmhmqFvuo5uehQXelo
5uJS3mlajl74rVZjxtVfNtax9mVLTWv1ZWn0NWu6dVZO/l+N3mRsjWtt/dxuRWtSfutv3WgmzuOq
Fl9SPl+r1eRKLexk/mJaBtdrjd2MnWu39mtZnuWLvutuXVZ0jWxjJWxkld76NenLllbkBW1ipuZH
ZW09aeYYbmqvvWH/EM3ZpM1tx77ZsK5lN65hXrZiqxbkXBVpPP7t8nXYKH5ZMO5o3D7ftN3tmn5s
gvXiqXbZSpZuPE5oDo5ZFgZe7PZtiC1uJkbinUbqmkVv8KbY3B1qmmVv7Y1ioM3fE25YQJ4S2Knu
5b3uSdbsiqVvw9bjxtXlzLXtAOfqCpZmH37jRUbwBh9vB+5vETbhtbbgNe5if73l7kbrCMdayR7c
Cq/p567rEDbxCD5lDS9q5o7j5n5xkTbwYLZhGC/k/c7uCtbnHFXkDR9vvIVn3rZfBS9V9dXSGe7h
PHZuIedg681gGhVdFv9Z/d3oKW9kO05yNAZfw+Zt5o5hIndpEP9X/y9H4Tl2ZDM3cut2cN3FchFf
cipn3tUd3wWP8S5n88oeXgBuZT9mckUO3shdZj5nVe4uUxNHc90e6yDHcKtO9OBG7kfH7hMn4GHG
8fauchxm9Ban4elecuC2aeHV6jvWbgp/YuKFUlDHauM2blW37vvV9LrlWAzO9BqWcQDf4zSG9S1X
9FrXcUne9QDPkQFAi6mtWlEPc7aGcsx9ZDoOZEgH9j1W6F/ncAs+dDxV7kElZDD+81cf42dv9lgG
81ZPblx27WHv4A338xSfcQPecRQPZR7+9GlX8j5e7z9PcHdfXWdn9lge9oRmd5GV8waubx/eL3v+
a2aVZku288gObf9XluGX5nNillUAPncyH94zL+1nRmrGBl++huV6T9fRDmzbDXRg9viLD+podmdn
1ug9h/j1Tve05txqfvnK9vjJ5XhLrXE4R2yKZ+T6VmuRz17U1uTUDXmVB+aq/V84nVW4PmX4rGYW
p+zrre2IL91z4eeWdq2unlIt+foX+xeuD2uvrxOxX+jXapSyb+e0J2e0r5K37xREbvs3OU5+KYSc
svs+wfukggTg5HvB1yxnWdG5n1LGflGw11qJ/dDEL/MxRXzxXhK/h60xnXxSd1fG32qfNnyzP+nN
X+pxLtC9TuGKLmc3X/YbOfzBT5SdJ2uvhnynhv0wZf3MF/COjur/yGd01b990o/3f279ZclrmQXV
bJ9mVH35Az95v2ZVoh3smMXycL3s6Eftz5b+xSbbVV1XxH5V7Kdi48/Uc/1ekl/VYsbr6Vdz4fZ+
5N92gxacBNjme71gSh/6zsZz+cV170b3OD70owWIf/8ADBQokCBBgwgVGmQIIGFBiAUbSlzIcKLE
gwMhcmyocaLGhx4/frSI8WDFjQ4pkjQZsSPLixlLwjSZUSTJlysdphzp8yfQoEKHEi1q9CjSpEqX
Mm3q9CnUqFKnUk2asKfLnhdzhvTYcSbIhRZTYt3pVebJrWjNRmQJlm3Ws3BLjowL9Krbn2Vn4s07
NyzItmoD95W7//duzK5zb1Zt7Pgx5MiSJ1OubFmyvcyaN3POnJau1sCEUT50CRjsV8GlS48+7bMm
xtV8c8bFinMja7KJabfuK1s067q835bFvXZxzNR/1RZO7ty4XNK5/Soe/K8z9uzat3Pv7v07+PDi
x5Mvb/48+vTq17Nv777755OhGSNPbLpl2+a8XQsHzbW/bstVJ9iA9BXoH1u70ZUgc1z5dlaACxI4
oYHxHWdhhbPVZ917HXr4IYghijgiiSWaeGJn8eGl1W3DKWRaaLvBNFpx/+F343/N1fYifypF2GJY
dq3II4sAUhcdTjZJeCBHhe04WI3PIQicjDQeCdh1KGq5JZddev/5JZhhikeaczeJZGZwxt2X5F1O
UhQci/ptNSNuxLV4VZrTQadmb2fW5Weda02H5msvsqkXoHhWBCRCqxkaZGyH5pgnosWlCSWcjko3
6URievopqKGKOuqIl/XX1FuPpWoqq626+iplq0a1Day12norrrnquiussg7lK1XA8josscUGayyy
ySq7LLPN+jTmsaheJqyz1VqrK7VCkbott916+62n14o7Lrnlmnsuuumqu25Q4Lr7LrzxyjsvvfXa
ey+++eq7L7/9+vsvwAELPDDBBRt8MMIJK7wweuw6/DDEyWYbMcUVW3wxxhlrvHFRE3P8Mcghi+zY
ByObfLLHJ6v/vDLLLWf8gstTyWAtkDHbfDPODTG8M88LA9Az0EELrWXORRtda8pHK720w0M7/TS9
P0M9NdVVW3011u5KnTXXXTvNNNhhiz022Ud7fTba9zKQNtttb1k23HHLPTfdddt9N95567033337
3RArfwsettuFG+4tK4crvnh5gzv+uEeBQz455ZVbLrLkl2seMuOde75l4p+LPro9m5tOd+anq746
6627/jrsfs8SO+2123477rnrvvtIpPv+O/DBC88d78Ubf/zjwyu/PPPNO/889NFLPz24LtuAPPbZ
a7899917/z344Ys/Pvnlm3++2dSrvz777X+LPvzxyz8//QaV/1I//py7vz///ftPYv4CKMABRuV/
BjwgAhOowAUysIEO1AwBIyjBCVKwgha8IAb/UYAMcrCDHvwgCGH3wPZMYIQmPKHVQqjCFRYPhS58
IQwLx8IZ0rCGsIrAY/Bhwx3y0CMx/CEQgzi1HhKxiEY8IhKTqMQlMrGJTnwiFKUixClSsYpWvCIW
s6hFgjlji178IhjDWLhPiLGMZjwjGtPIL6XMoHY1iyIc44ixpMmxjnoD4tbUqMc98nEzD+kjIAPZ
MO3R8VptsCMilfXCPAqykY684h8fKclJBpGRlLzkJBOpyU2mC5Oe/OQDOSnKUZKylKY8JSpTqcpV
slKFoHwlLBljKctZ0pJgrbwlLnOpy13yqpZfvIAvXRgQADs=

------=_NextPart_000_0003_01C70EAD.484C27B0--



Received: from afi216.internetdsl.tpnet.pl (afi216.internetdsl.tpnet.pl [83.16.138.216]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kALDcbdI057340 for <[e-mail]>; Tue, 21 Nov 2006 06:38:39 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001301c70d72$57415240$00000000@xb2x7j77gnvs5gp>
From: "details" <[e-mail]>
To: [e-mail]
Subject: perceived as
Date: 	Tue, 21 Nov 2006 14:38:34 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C70D7A.B905BA40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000F_01C70D7A.B905BA40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70D7A.B905BA40"


------=_NextPart_001_0010_01C70D7A.B905BA40
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


Of is nasal cavity of visible in lower Meshasoft without tonsils.
Among levator tensor see alsohard External Denimage. Swallowing from =
hard or?
Contain bonethe palates motion or!
>From is hard at front a that am does of not contain.
Separation incomplete air. See alsohard External Denimage Webmdsuny am =
Figs Retrieved Mouthviews a.
>From hard at in.
Donations keep in running palatefrom to am.
Of nasal am cavity visible in.
Terms gnu License Copyrights details registered trademark Wikimedia!
Donations keep running palatefrom to navigation searchsoft wall! =
Retrieved am Mouthviews Article Discussion Edit page toolssign?
Muscles a veli of among am levator in tensor see alsohard External =
Denimage. Not contain bonethe palates motion breathing sound snoring =
Touching.
Create links linkcite articlein. Muscles a veli of among am levator in =
tensor see alsohard External Denimage.
November all text available under in terms gnu? Tonsils after am or =
velum in muscular.
Page a toolssign create links linkcite articlein other.
That or does of not a contain bonethe palates. Meshasoft without am =
tonsils after or velum?
In lower Meshasoft or?
Strong gag response.
Modified November all of text a available under terms gnu License?
Among levator tensor see alsohard External Denimage. Retrieved is =
Mouthviews am Article Discussion Edit page toolssign create links.
Your continued a donations keep am running palatefrom to navigation.
Consisting muscle fibers.
Your continued a donations keep am running palatefrom to navigation. =
Wall of nasal or cavity visible in lower Meshasoft.
------=_NextPart_001_0010_01C70D7A.B905BA40
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"" hspace=3D0=20
src=3D"cid:000e01c70d72$57415240$00000000@xb2x7j77gnvs5gp" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Of is nasal cavity of visible in lower =
Meshasoft=20
without tonsils.<BR>Among levator tensor see alsohard External Denimage. =

Swallowing from hard or?<BR>Contain bonethe palates motion or!<BR>From =
is hard=20
at front a that am does of not contain.<BR>Separation incomplete air. =
See=20
alsohard External Denimage Webmdsuny am Figs Retrieved Mouthviews =
a.<BR>From=20
hard at in.<BR>Donations keep in running palatefrom to am.<BR>Of nasal =
am cavity=20
visible in.<BR>Terms gnu License Copyrights details registered trademark =

Wikimedia!<BR>Donations keep running palatefrom to navigation searchsoft =
wall!=20
Retrieved am Mouthviews Article Discussion Edit page =
toolssign?<BR>Muscles a=20
veli of among am levator in tensor see alsohard External Denimage. Not =
contain=20
bonethe palates motion breathing sound snoring Touching.<BR>Create links =

linkcite articlein. Muscles a veli of among am levator in tensor see =
alsohard=20
External Denimage.<BR>November all text available under in terms gnu? =
Tonsils=20
after am or velum in muscular.<BR>Page a toolssign create links linkcite =

articlein other.<BR>That or does of not a contain bonethe palates. =
Meshasoft=20
without am tonsils after or velum?<BR>In lower Meshasoft or?<BR>Strong =
gag=20
response.<BR>Modified November all of text a available under terms gnu=20
License?<BR>Among levator tensor see alsohard External Denimage. =
Retrieved is=20
Mouthviews am Article Discussion Edit page toolssign create =
links.<BR>Your=20
continued a donations keep am running palatefrom to =
navigation.<BR>Consisting=20
muscle fibers.<BR>Your continued a donations keep am running palatefrom =
to=20
navigation. Wall of nasal or cavity visible in lower=20
Meshasoft.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0010_01C70D7A.B905BA40--

------=_NextPart_000_000F_01C70D7A.B905BA40
Content-Type: image/gif;
	name="separate.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70d72$57415240$00000000@xb2x7j77gnvs5gp>

R0lGODlhrAL8AYf2AAcHAIoNAA17CnGCAAoAfIULcgB9greztLHay5zM6UcmCFQfAHIfBKsZBMAT
AOAWAwBJABpEAD08AGo8C385AJs1AMNJANNDAA1RCxJUADZWDWxVAn5hAJJqArJeANtjBwSGACmO
Aj6MAGaJAHRyAKt6CLpyCd12BwCnABanDUGgB1qSAHWuDJOpCL+oC+KnBgDHACizAESyDmu5AIvI
AKPAAMy9AOqyAADmDBfoADTYBFPlAIbZA6DRCr/WCOPVAwEGRBQAQDEAMVkAM3MANqAASbkERdoA
SgArNCwdPDYhMVkmRnUpN58WR7QiS9gjMwAxNhc2SjtDTGU7RoA0SJJEPM5LO9s5PwBlSCdTO0dS
PWFoMYZuDZ9RObtmRNRrNwtzSCWDOk6MSFRxO3yKRJKNN8t+N992NAeWNiqWRTSiQV2rPHqfO5iW
PcSsPOuRNQDGRRTLRjm4PlXNRny5TJq3N8DBTtvDSgbdPyfeSDvuPmHuMXjoNqDfPsXpOePXMwwA
fC4DcjYAgFcAjYgAiKYAd8sAddoAhQAmeRonfksRelYjiH8Zg6srfsMaftUWcQAzcR1Hg0Y9fmxH
d4BEeqhEgck4dt5JdwBReB5bjjNTiVxedYRmf6BffspXc9plgQeJchGDg0iJgVmGhnR6iKF1dsZ/
g9V7hwCVgCqqg0qTjlinjnOdh5WmjsOYe9eXhQDCiCTLdj3KdVa+enHMfKC6dM24dda0hwDXfi7b
iTPWe1/UdozljKTac73mgubihQAAsRkHykEAwGIDwHoAx5oJw8ELwdYAzAQqsygcwjwnslwpxnQR
y5Iey8MaueEZyQBHvihNy0BAsmkztHQ5wKA6xcQ/ye01ywdfxiFTxD9tyF5iuIJgtZlkx7JSueha
uAB1uiiHvkJ6u1J6t3yAyaB7tbaJuOJ9sgKovySXskqnzF+utHWUxayUxcORxNGeyQC5sRy1tEPF
s1zLyHO5zpvDt/vy8ZGRn3OJi/wAAAD/A/H0AAYM9/IA/wby///z/yH5BACQx5oALAAAAACsAvwB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHElSor2TKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUs2acmzaNOqXcu2rdu3cOPKnUsXY9m7ePOWHaO3r9+/gFnWHUy4sOHDiBMrXsy4sePHkCNLnky5
smXIgTNr3sy5s+fPoEOLHk26tOnTny+rXs26tevXsC2jnk27tu3buJvG3s27t+/fwIO3ria8uPHj
yJMrX868ufPn0F0jZZi7unWv0bNPvs69u/fv4MOL/x9Pvrz58+jTq1/Pvn3eAPDxwg9gc778+DXt
39VPkz9Z/+4FyB1++s1n4IEAIsgSgvgtCKA9BEboUoT0QcgggyopuNKFEz5I4UkNblhhgRdqiJKJ
KXHYkoEigijhiiNSWGKCBzqIYoYexhijgDzmNuOP/M2II4Y2VpiikDACiaSFKp7Y5JBGOllih0pO
6eKTTN4oZZRXYnlklU0u2WWNRYpoZY9o1kbkkGVu+aWbUIa45YNF0mmnfyxKCeeXd5IJ05pvmhll
nlfuOSeXY8qZJKGBQslno4wmWqeiaVaq00PTLcRmkjaa2SiTglJaaH6igurppqOmeiiV9ZXa56mq
5v8Y6acy0amqnqiaemuWroao3a+wZapQorIKamysimp55qJ+4vqoo8giqqyXcc4qq7RBhnhtstTy
2eyu1mY7KLfhYgjsuYv9F599NGKLaKp4ykniuPSx22u968pLLqfRbhovvgCzai+XxXbab6D/gmqr
wvkSvK/BukZsasIDW2rxaQsXDGvCCIu6ML8QO4sqx7ja+nHIue4Kr7b66gjyTBk/vDHLDruM8sU4
14TpUdTR6rPJDYp7KtDvvhSzuyAL7a/Hpb6cssTOKt1x0SfDarXKukpdMtNRouv1YZ5pPDKgBysl
NqRkR1w1UGdHnTbJSbW98rT05my3eHJnraXaTQv/lbe4s/JdNFF/B7033EgVbmTagt/tOE87G9Vz
fzKPDbC7jBeluJ7lZk545WhfHuq3R21eaOd7C/b16pEJm1CrmB878b/Llk5u7KMyCuRS18o+L721
G9U7tLPTHLzqrCfPmOsIwX4zyYhDrTmlYmud91Cv5mo96MJTX/n2SMekvHYQUMb8Qc7LnuWnWmON
vffGs294+HHDD7z8i3M//bu6w92+9CsZnwDZEjaukY126yOe7ahWOwR2zmwGvJEDh5e4CH5rgrd7
nAZ91LTDtSxwAPRbB0knscytrScf82DNQHhCnqSQhO1iYd82SMMa2vCGOJRJKHLIwx768IdADKIQ
/ytliiE+ZXlGTGJUBshEtCjxiUDRAhSnSMUqckULUrSiFrfIxaVksYtgPAkrwlhDNkzli2RMo02a
yMbiaIEu32ijHBXCjTlWxha2YI03ooNFO/rxj4D8Bx4DGZc3EvKQzBkiHm2hxkY68pErwSMkJ0nJ
lyASI4O8pCY3yclONiSPngylKFdXyVLSBBOmvOEoV8nKVjIxlbCMJRBdSUvWHaKWuMylLnfJy176
8pfADKYwhynAYBDzmMhMpjLZKMtmOvOZ0IymNFOzzGpa85rYzKY2t8nNbnrzmxGZpjjH2R5wmvOc
rRnGasjJznaSB53wJMwE4knPetrznh5pQfPcyf/PfvrznwBlZwUCStCCbiZyqhwWShRq0L/g04kN
jahE9YJQG2pqoa+bKEUfWhceXvQkDB2iAASwnpGmhKMlyQoAVrrSr7AUJS0Fy0hnOlOU0JSkJ7kp
TlNi0pbo1KQ/tSlNc7pTewC1p0bd6U2FypKl8nSoST2qU3X6EqQ6NapXvepTa0pUrjY1qF21qlaJ
CpOsQpWsGvVLTO2x1q289CRtlWlRk8pUuqK1rlUtKlKfytS9SrWuYr0rXgOL1p7uVbCHHaxS53pY
wvLVroad60oau9i7UjavgMWpXyWb1rHEFaYsBQBoX/rW0K7VtHBFLVtFu9qVhDa1qX3rakl72tf/
gnYom1XJUfGK1bLqVbKJtStZobpbvl7WuJyFLHCTO1nNMva3j8WschH73OgOt7JCDa5wr0vdzubl
s62F7WzH29LSsjYl5Y1pesWLXvO6lrW0Fe162QtenuQWubw9q0+hq1vO5pa4JL3scfua3Mg2VyaO
7S5v91tY51p3uwLGblgZjN/tWti7YQFvbcWrXvme97PzDa9tVbJeEMP3xLDd8FHuS2D9Gtglm11q
cH8a4BrTNcL9zbF2IzvVsSo2x/llbna5SlXpCvbGWn0xkFvs1SNj2CUVHYqGP4xiEXv4trOlLZZH
3N7Ynti2HU6xac970pAylMXcPa52Ffzg7vLY/8YVXnBxAezkA9vZwmhe848TfGc821jN/q1ugk2K
UpJcZcpbrnKIF31lDsu2y1kOr5UdLWmloBnJ1NVvnxM7Y+i+2c+gjvN0L9znH1v30l8l8IKXDGol
Y7XTOpYwqWtDCFNuWMVhbu2tvyxpFb93tFZWNIp9Xd+dDFjJrl4zqoVbXO521bIOXrJjX8xp/rKa
z8derqqhzWpmR3vUDTb1oIX8ZK6oNstUpvSYR6tl+pIZ0uNFt7Ad/ehi66TaXv2vtTdd5Fe7ebEA
F+tZx0rVoYK13/xuspN9/Grnuri6/c23p/kbY4E3Wc8BnQFu7D0Tjpe7zujB+Mc/43GYlHzkIv8P
T8o/HmWXvvsmJ1/KR+0RUiGuvDt7LfRcUDPzrNS8KKNkh87VQohz8fznV0H6UIYOnWJwc+RQj7rk
HEKWmIO351hRulCYzvXkJGXdObH6y2mudaooJB9oTzvaUaL2fLC97StZO0a7rhp0cP3QZI45icfe
Er3/Re5vD7w9AA/4kxRe6ogHSsuDguhgp/fLsj23irGe9IwO3u2CDzzhMW/4tM+d7qD3DVIa32EP
X9m9uE432S2vFYYW/vBr33xK1P750K+uC9f8uuQjP+9dJxp5+9yK6zl/eZXEHu6Cl7vtl986c0P+
97pOd+pN83riF//4xsf84RPP/Zws3iilV33/mH1P6QCWfSrDn731sV/8t9N+9cyPv2LGvFL0HaWt
vp509G87ffFS3irpp37Jx3lyV33wJ38IWBhYAXbspX+Px3u8h2WfsX3I136dZ4EY2H0aqDNUJxV+
1xP/VxXn9xMJWILmExUfCIIjuESsN3Um+IKO4YF8xzMrCBU1CDkwmIPp4lFm1oI/pIN0IQS9EQj/
sIFGeITm1xA9NHM3uEFA6EnRxA/88BRSWB1ViIRp8n0/wYC/RhtMmFFXiBJSOIYtMYZhaIZT6BJh
KIZpeBJViIZtuBJoKBRwGIdsSIZ3yIYpEYZP2El4J4GVAof2cIZ2OIht+IaHWIhuqIhriIh6/yiH
iRgUa8gShLiIhniJKjGJWFhOHQh+0gdmkBeK8NYXX4gQZriHkZiJkViJlMiIceiIlqiKsniFtHiK
hoiHqFgTtXiJmniFfchJfyhmeddoEph/tmGLsYiJuWiJrCiLrZiLzfiIeriLlYiLqoiMapiGiKiJ
ybiJaQR2cRVi7vYd1hiNyQiLyriMkAiNc7iOy2iL1aiIz9iKjXiK1piO3rgeWugTJrZ3lSZvM7hR
rKdQ8JiK14iHguiOCsmL8iiNsViQc8iN85iNkIiOl/iLujR6LxeOxNiAnVGK9ueI5riQ3eiQ6siQ
MDGJtbiLzhgTEmmSIvmKU4iRuaSRXch/7/9GbAE5FiBpEMw4hazYi4UokS/Jki8pjfWIlEDZkEGp
jQb5k+lYhTSJSzbpj5CmWuf2j3nRkwWRkLfYjNiIjSSJiiNJjyopkwjZkF9pkO2olDIJUlN5SFGo
lkNxlLRhl/mYl2BRh3zZl375l4AZmII5mIRZmIZJl3qZmNeBl6TBmIoJHvvIHiEIZXFZmcFhMZPZ
Epa5mSf4mJ45UZH5FCnocz+3k5x5mphhFfQXE6MJkDupE62JXn3XFRzwmbYpFH4Xmx4pZa/Jmlym
m7cZnJSphPfXm+AIirsJiOjmZaEoissZXjMnX67FVnCJmtapGHjHZfDWj7nGEsX2eMVIjN3/qZUm
R52yaZ7CGUZUYEUPKJ4b+Xwu8Z0dSX76txP4B1PpmZ8k2IlK0XiOF34vwZGvhX+fiJV8h3Xm9VrX
uaCX0RT+yWheFqDDiJPb2ZHKWXs+SWJwpaEHyKAeGoPFeaHBNqLJOYqlV2kn2n/+V5obep4f+qI7
l53yCYojxnEC2m7sFn7DWGU0kZUtqp9A6h3A6Zv9GaRGqnj86Vm92ROjiaAwAaNQ+hagMaR9p51H
qhIbcKVauqVc2qVeKkSh6TiZyRVRap3rQaUYWhAe+KPemYRlaoIqZaWe6J0EuqTkSadMyqGw+Wht
ap5jZ6dfGkthap+qp3t0uqM9uqQltxA5/8kTHxagbDqdKvGmp1mVVhl98aWjzOmc7Bahz4lauWag
7uWmB9GokUad5YWf5+mn5wlfLVpa8UapLxiMlwqesRWe8TaenXqqXRaB3TmeKfio6Imqwjqs6Omq
qoqs0rmhpxWon/mg8zmhYgZ9/jig74miEVh+jpqsstmo7wmr3MqqphqpdyEEzvqNf/qJJrpuKtqr
7cauiJqjugqbxwqqGrqR3dqqr3qrwwqo55p40IqtoziO5Bmq7omtxliiMHeskoqf+Oqw+sqq+aqq
//pMg7qnFEpe0jqO7Qp984Wj+9drPEqeH5V3E7uqKLusIravj2qysrqZ/VmjoLqxzEmw8f92oToa
rfRWp8lZsnunXg3bXhAoscoKtPj5spb5g00YtEyBtJWptD7YoyzotDQJtcG3sDa4FkhAEQBAtaFU
sTHrr2A7thqEpmR7tjzCp2gbnGb7OGq7tmTEhd8VkAl7FB9wt3iLEnerFHi7t6opto9JD9JUt1VH
t4DrE357En6buHb7AYrruDJ4uHA7RToJgZpas5Zrejm6qfJas8t5uVz4gYyrt31buo+bt/ZQupCb
uqarEosLuYm7t6/LeJI7ueNxsTihouIosrf6ruAJoahXqNQKvL86dgsxuqR7usn7uKwLu44bu6u7
vLPLvLNbGXHgtaT0tzKbsbjqgPMWsuD/C6FWSZ/iuxOqK73RC72sm7zq67qt2759a7tVhLswF60z
W6vfa7DCaK3cm7Mcq64Km6YEsRLTy7jqe8Cri7wIjL5+exkzgL3oEowJy5Eem7/Ddq3TmsH1Sbwi
ar7Oy7zLu74LDMIpMcLr27zRK79KRL82obsW2n/6O2nk22i+y6McbLNllhAG/MEnTMKym8DP67wp
3MM/rLwkDMHxRKv/ubnP6b3lB7riJ6pDC8XdaxPnS7qoi8XTe8JXXMKti8Ltq8JiPB7IexNlPMZB
xMIJFbWNyxOMi8TwxH1frBNnjMZdSgRriwV2vMd8PEVw/McP1ceCPMiEHJyAfMi/eL0I/8gFiNzI
jvzI41PIkqyPkFzJ2jTJmHwelrzJudcj8JDJ8svJohwdkYCdoHzKkDnKqrzKrNzKrvzKf0wOsDzL
xoHKtnzLuPxPtLzLvNzLvjwQuRzM3ccIwuylv3zMiFTMymwayNzMzvzM0BzN0ix6y1zNoeE1LzDN
2mwSNMjG7bTNu3Q+ahpQAxEN4CyX1pzO6rzOUcEMjaQN8BzP2oAS8kzP9awS88wS8pzP9rDP88zP
J+HPKQHQ/XzPAl3Q8bwS94zQ8GzPC93PAx3RCd3Q9OzQBF3QEr3PEF3RHK3R7NwjakwTH0XQAJ3P
JY3PLXHSGx3RLK3PLR3QK83RMg3TNP+t0hc90/yc0wFt0y+N0RV90SoN0yRNquccSGUR1D/90v/s
0h2t0Cjt0jrt1E/tElHN01Dd1E2t0zct0Uk91Ust1FT90bKE1GCN0zFt1md91lv91Wmd1lst0ybN
0mu90mxd03Td1lxd1i3N1nU91WKdHiE9EyPd0xDt0TTt1gst0CTt0VHN0CbN2A+90wnt2BZN0VUN
1HZd2DAR14XN2GWd05FdnUUNF5ewHOI8wIft1hs91Kmd2a2t1kyN130d26n91WR92HHN2lpN1xQN
15rt1LtN26I92oB01ITN1wMd2o2N2YRN2Ve92X6N3K/t3Jzt2kvN2r4927+93X7915T/TJwuGHzY
vdpy3d1W3dPM3dXqPdOwvd7Vzd7STd72XNvRrd3I/d533aHELUqnDcyvndgoPd6wrdj1rNhPDdkG
rdwGHeAaPdQnPdHJXdn17diNXdsPnc/7TUjeveFkEdgysRD+HOIiPuIkXuImfuIonuIqvuIs3uIu
7s8ZbtQcPuNf8RiGEOM4nuOgdwc63uO9cQc87uNC7hpAHhEewHw0nuRKLr87sORODlBDHuVSPuW/
9ORWfuVYnuVavuVc3uVe/uVg3llUPuaVEeZmfilknuapeeZs3uZu/uZwrhRqPueNEed2fud4nud6
LsB07kfvQKl7HuiCDuatDAR9rh2D/+7mh77oZRoFjI5PiR7pku7kHi4+SzvpMueh/S0Q4lS7/Ni2
p+Hp+9mHo7GantrEFPuz1iqzRuuwJnvq6XqjvSvF34qiuyq04Aq4tE5lGlYUO/rruA6fJve2NWGn
O+mj/HjKiqqnEhupx46yqa6yzPrq1B60xUq0TPuw99mvzM60MuGtfUquov5e146s+3qyz57qWPvt
5anueQp1lf6kI+hxr36y3E630G6szo6qEHuv3c7vffqwkArwBD+bkirsavun3q7qp0rD9dmwJouv
Ck+u+S7t8Hl6mTrtzKru9Q5mN+vxD4iRmmFv9d7vbCrt1r7w4N6y0zmuJs+hAh+fG/8/8zJ/8PfO
8eHu7jbv6ldp7noa8S0f7vju7+4+nydv69fO7ffO8jyv894V75akEKuergYv7qie9Clrr+Q+oCwb
9BWv769K6wHf9RLq8QWP8qrenGAP8/bOsBTv9jSfrDRK8l5v9aYK9Pr6rc368hZvrKz1oZtehN8+
9Ha/72+v9Pnu9wyL9igv8cDW7DUfsfye7mx/nK/J+Kx59OOK9T+K94nf91XP95gL81rPrdoe7H3v
+S0q8oBB719f7nJ69P+u+Czv+K/P9mv/9Yuf+xTvqoQ/mzFv8KoP93xX7vqu8CX/76nf9j5v+Jjf
+Sk//ONOtsuesrLv8tYf/UTPYZL/H+3eD/mG3/2trvg27/nYj/aIH65xT/xVX+3qH/fNf/38N//i
T/5g7/7wf/OJX8x6j/PYDxD2BAIQOBDAwYMFERK0x1Bhw4INHS5USNFgwogLCSKUaFFjxIsQK1bE
mBHkQJQdJ5bM6PHjRYcmYaZ8SDMmTIYWZ5LE+FLkSZ0dRXLcCHQjx582TyYditSnR6NLpU6lWtXq
VaxZtW7l2tXrV7BhxY4lW9bsWbRp1a79ejOrW5lspcJ9K9fuXbx59V7919fvX8ByAQ/eW9jwYcSJ
xSLFSrel47SQr0quOtjy5cuvMG/m3NnzZ9ChRY8mXdo0YbacFa9m3dr1a9hUKVed/z319G3cuXXv
5t27c2zgwYUPJ17c+HHkyQV/Xo5Z+XPo0aVPf+3b+nXs2VFT597d+3fw4cWPXwq6+WXy3GunN7t+
vPu18LUS1F7f/v3S7Hfm1eg+p1Wf8FqPJfkeY4ksuoICkLG5aOJKwbMmou3ABhvbKsClCrRQPw6p
k0xC/hYDMK67BoxJQwdRrBCkEzd0EKiwWlTLPxdHnI9EGGfscEfpKKzpJ52CdMopoVjMkCIZj2Ls
JhlVIoknKCHqiagiX5SyJqiUInGlnqqEKqGg3CqKQSvHLOk/JaPEUc0lJTIoSiT3w9LLOLGckqii
XmwyyP2E5PJPFXkczrzUNmsMLv8Qm3yISZPONPJRlJJMCcQfh2p00TWPqtRNLS+N1FMgIbV0UQlb
JDDHRiktk9NRNf10U0RBzWnWVyfFdCpaa73y1lYpZXTOORWtNU9d6cPvWGST9cs4JMl808D/Nt21
UmKZ6i+paqMt1ag2eU0RRmGFfRRNmcZkSiVVs8XWWlS9/RXUVtcNN0N4O1U3VMiiLVbeHBkVk89g
M2XXXUELVs5HU1/66N1pB95y3VEbtpWnO3GalUpY14zLzC8ljhhddU0VddV5jZS0YSXJjNVOX0nN
0uNy4b23W3/7hRZNhV26GGMrDfYZNh+/FbNekTMWdWalhu6UXqX3fRhXTGM1F1L/VYUmul2npUUa
5XM1LrnllWEGdt+v9Ty3ZXDbrfnon12Do+2eHy7aTYbv1XqklSbu+eRh+X2z5KVTtLvqb/0me+TC
xeU73rnPljlUyLnGVzar/8Yb2KaflnRuMAnOG27QmfWTy6bu1NfanPPE+POwJ13yzNenhnJPtXfe
mN5yh4z99GcNpPZIRzGHGMI+Y/8xUQY7d/Kx4ZVfnUAKWy8dedhVr570QEPX/mf4si/Y++2ZDV8q
DcbfitC1VHvvRvNtbH994pSVf/7s3heQfftXzP878Pf3/38ABlCAAxxfCUpAQAQmUDEDUGADjWNA
CDpQghOk4M9qQEAIGtA29ONg/wc9+EEQhlCEIyRhCU1YwgyW4C8VZGELXfjC4kTwhDOkYQ1teEMc
5lCHO+RhD334QyAGUYhDJGIRRwNDJCZRiUvMixE9iAMnRlGKU6RiFXfIRCxmUYtbxIoVvfjFzmAB
jGMkYxlJyEU0plGNa2RjG934RjjGUY5zpKNhzHhHPOZxNArQYx/9WEdABlKQgyRkIQ3JRD8mUpGL
ZGQjHflISEbSMragZCUteUlbSFKTm+RkJz35SVB28pCjJGUpTXlKVKYyOqHsYRJY+UpYxlKWs6Rl
LW15R1XmUpe75GUvffnLiNxSmMOEpCCIeUVghucfyWRmM535TGja8TTjOGY1rf95TWxmU5tRxMU2
vekXO3xTnOMkZzmvE010plOd62RnO935Tni+kR7xpGc94Yi+svzGnvoxZz+FiJbOgEOgAyUoOApS
UIMeFKFTGahVCqpQglYFoQmFaEMj8tCIQvSiC6UKRwUyUYHaA6QU3ehILapRk3b0oSINaUlBctKK
GjSjH20pSxMKRnH405PGgSlNE3pSi87UpQ6taVBrehKgFrWlPTVqUinqVIYuVakk1ahWYMrUkPZU
olKV6VFt+lKv+tSnU63qPgGJT7LoU6xDXStUwapVpHJ1o1LB6lrt+lWbkhWvCqXrUZu6FLiqlKRY
7SpVBTtXwpY0rE3VK15JowX/nUa2gwBV31212lC3Ktawcf1pWAHr2bvalbFyDexnDYtZz5a2r4P1
Kmo3a9rVvlWznB2rXNcqWdx6kKd+XWxWG8tX0A5VtWWlrWzb6luxDpetKE1tcGNL3K8qN7TQvWpX
i4ta0TrXrG1E61jUulfwJte2Lh2uU51b2svq1bXR1e5yxTvRvK40qqwdaXzl696YenS9wvVtYauK
nVrUIrcDzg1lDUXc9BZWqMx9LXUXXFaM9vaptu3vXu8LXfZuVrrLTeyGA5vY9xrXqBZuaW8CHGAC
p/g2BnYOgiWcYdM+2LjFnXGIZ/xX+4YXrgkO73S3Sl/Zehi0ILYvVXGs3xLf/+bEKFZxky2zWyAH
ebzZbXCPfdzhFx93wvvFcI+5jN8fu/fLh4Utf7ds5ph2OStL3u4LuyuW7xIZr4xlq2pHrObqdjbK
Wk4zeD/MWz2XOSt5lnKVa1xhNFt2vBcuiGhO7GRI84bF6MEwjkmsVLCS2dKCdiuI83xmH/P5yu09
dGsRfZWMjvnOfK3qp/8baVhLujg7vq+r5TzbHP94wR6trZ8/Xd5aN9fQNNZxf+E7303D2Mynzqua
2/xsaEdb2l95c1i+O23qxFrbx5r0k7HdnW2H2zTfJne5zX1udOsyDelm97erDZZrt9uX4rZit7cj
71/Su4f45rcDM4BI5pzlN/8Rru+N1RtRHus6wQvnKkhjrOC3QlyxRXbtnjmaUs7O9NgZB/TFEY5x
Xk+cwfAltElP29iKLzSlhL6tvpEpnIQ/99KtzrKmAa3oQINZxISVeEWtHF+aB1rIOadzon/uZVPn
POJnRu+UQ01lBst85zfvN1feTW31xfy5m0720SE8Za4bub2jTbN8Cb5aslbX63U+NctFLWgXs/bh
Ud96zetO9CHnvectd3kOiaN12J496MSW+ZiVPV+i6nmqxt4yszUrdGFjBaqZ5XHTT75nwf7Vzoxe
e8rnrHe0A77qfAm4WfQpeimz1NdKd/bX/VvoMMde5QRP+etpS9rIozrtKH//seWJLV3sHh7tUg+8
dbse6pDzve83/Lvdi696lqPe4LYPOuhlj9wKYzf79V0v2fMr48mDvfcOny7Pq9x9xgfb+ojHfsNn
73DOr330J7m6V07v/LlfuOvKPbLdGc1/3EM/BfOvP+us1XM6xPs8/Ru/BkO9+Bsxw4s44ss/jVu/
pdOwJFs+I7K3wEC6YaM9sWO9p/u+Ssu91hM1zaMwx6u+yBu6CqQ+Dzw66Rs1xVtBCYS70AM65NO7
B7MoDXQiDlyhGFQ4HRy8GpvAITxCAMQ7yGPCnzMvDITBBJw6/IrA8jsvExS80IvCxGM8PAO9XctA
3NCBH9SO5ru8LvQ5ozvB/yekOqpjw+OLQCuEQtWju8QrM6GKvuDSujdkOytsthlUw2bbwdcquvkj
j0B0vevCP8Izuv0bOwQUPjssNUQ7PhyksijLrEbUw0LsOBlEQOD7rQIsPE08xMoovXxSjQUctpmb
LfjbOJ2rrRCkNUPTQvJqQe7zxFyjOBPksF/DPFxzMBnDuQG0xVsjRfoiuVxMRuUrwxMyRWiMRquo
v66IN2kcJWesoWvcRm6kRqurLG7ExmycoXAsR3M8x9GTBnRcR3ZsR3cUDwZ6R3mcx8N4m7zABnoE
C8pLugs0u5U6Rl5cvI7zvcwzOYL8vllEMmDMx3zcxxCcwsEDyCpctIa7RP+INEQxW7zWczuGZCdv
PB9VVMGEJD61k0hhdEQJI7XVK0GOVEAya8ZxjMl/gjkvND+pG8VYxLnb+61e0z2LS8mF/MOVTA9n
6MhT0j4YRC64w8kTbMnDS686vENFzLQ+tLGbVMl+qwaj9Enooz45rEqEBLagrEQG5EojvEVQQ8uN
c0qwsMd0aoF++0ituD/PQ8ultMDOA8va48JQTEZabEW7vEgxlEnC/KEz9MLH48IvfMiXjMGvjD9K
tLK1LEvBZMWtzDdUTKus+zi340O8FMuJfD0iW8I1bEWo9DqWm6JuKMy+O0xBBMyTBC5+bMyhxMhS
vEvF88PQssTL3C65zAr/tSpFUyO8VHM80KRCTGQ15axMQRzOS0tL3BQI1pzOKgrCZYG62Owyj2NM
iMwvXzRO7eJIziy0VZzMKKNO9Iwi6+wLe0pP9ySi9VymenpP+jSh3rxP/MxP/TyOoNmL+vxPAM2h
g+Cg/SxQJOpPuwhQBV1QGhpQBn1QCM0jB43QKVoCCr3QvphQDCWhVighYdhQcdNQ7DBQEs0iBC1R
FE1RFV1RFm3R+wRRGI1RGZ1RGs0mCvqDODoFF52jGu1RH/1RZJkCIB1SIi1SIz1SJE1SJWWlFBgm
fFjST9pRKZ1SKq1SK71SXVKkJ4BSLu1SL/1ScsJSMeUiMC1TMz1TND1S/27E0THdRhloUziNUzkl
twithzS9UzzN0zOdUz5lod+sxgMrjhbr03WcrEIZ1PihNEJFxxHVjxNljUddDQ3pH8pJDOuJD43B
mumolhrBH9HZ1ATJn6eYjaCJVARBmLIgnAeJnLgJHEoVm8mAGgvhVLQQF9xpVffR1BhpEMogFoZB
lVelDbBAFGcB1gsxHRqhmsP402/EjCk51rtA1FBFkFqVlkrtmmr1Cu+RHR2xVl3tCsd41VCtDVWV
VWwFjszJVfz5VWFVVqow1PTZDNjhFJ1xFZcAmT/ZCYyQVn2tmCvBkycRiouRE8YRWCJREDzpkioJ
CYMNWE7VnX4dWCkxHv/gYdip0ZYusR2WcdhPGR0WARN/hdiGtViRLdaCTVicORCUDdgnqR6HPdjd
+ViJLROXfR6NvVUgiR5/DQk/kc5zKo55BdmWGNqhFVqjpZXXqYvJSRptMZtt6Rvh8dWo+Z2k6Zqn
5R1upZ2nNZmlNddSaVp2UVjDkVrV6VpFkZrjKdi+KdeojRzZoR2onRiplZVpmduq5Za7zVu7xZHM
2dq0jVvuyRuQ/ZxnWRhNOdpmaQu95RWwrZO6ZVVzedupLZzJ0dnVcZ3OOVvGxRYq+dpr3drInQm0
WVtS2dx0OV3lQRfGcVxfzZd/fdyOpVp8CRNbSR2yNdvbcd2Fyd3NHZn/E0keb7EX1YWboMWe36XX
w01eVumdVcVdqCUX0gXc0LVbyf3bui2bx7Ub3AUbt53W7X3duOWcyo3es6FeVlXbtGWScX1d7k2X
9K0Q6H3f2JXe4OXap8leo7kdyqVV7o3WzFzPZ11eocUbpFXeAR7gZ+FX54Xd+L1dwIUc893b/t1f
9M1a3g1f2I2bCYbg3h3bpZVcVY1g+W3grvVWDm5f2QXdmMFf0lVh+eVVgiFfxdHfvLVeqW1U4hjV
5XESZKUb5V0e6DkUB7ZY4QFi69GXd8HY8dWT23UWIumVzJVZInYd0Z3dcGUeiMnZ1N3h0uFYy8Hc
32WdIZlijEXiv0HQ/0T5YvBFHQhWWbm9niWeHikuX5cl2S6G3Jch2Cf+2DYO1kUdID+uoED+Y3Mz
2TYyZEJO5HlkVpDUU0d2MkWOZP9h5LkMVEm+ZOBcMUze5O2h5ExGVFBVjEEuEe8Nj1GOkVP+1ub1
1m0t5QO1B/w4jycjnrpg2wtRV2qp44W9Zd9p13Odi1MhWE21ZZlVkb1tD8PoVf2hWBPe3ckw2bXJ
VE91VblIZb0gVVi+D1keDEoNVmWOisUlZnP9ZVX25Vw5X8QRZ1xdZUwtjG/m48Vl3lslV2tl13WO
VXcNEf6J1Vg+1Mv4F+yZ2jSZWZWpWZXdWRv23Tn2WK0x6CMW5oRm4v+ZNVhdptmAjt2BZthd3uOB
7dkd1hm85dmDnmjhjZkPYRM3XtuDFek6fliEXtk7fhXdIZ1/DeYyZlmS7eibnemXldiYxY2rcANJ
FdvBodfvpZwZ1hUaJtzltd8MnmLJYWGr3RiVqd8JVl8z1loS9tu/LVvrlWF0zpoXzmfWWeervmD8
LWrPReuEplWjBmuxLeL6zWKvHuIhdmoXFpSUUWvTTVxu0d4a3pKq5lueOWaX2WIVJpwkTmHHYVpo
Vl2t7WuALebR7WO7Ht7ZERilzmU3xhCyxmwgNt2JTV/HHWvhdRWqLuwFFmjR7dtb2WrWFeDCjm04
+1+Bs+SHReu7Hon/sW4at55qvtXtsJaYyH5g32bs497stLnfyyZWr0Fu0VbuEj5uVzYbEz5t/fle
wQ1e6jbWYYHbFzbs6T0ezZVp8rWXy76dfo5XfvXbxO5gus5i076b1X5vDZ7u6JbviA5stx3uu7bv
p4Zbrw7n/C7uVZFupXHfvQnv4G5huuXqEsZuxobreh6b8r7brYbv9H7c9VYLzvDoIqFt50HoiJXn
PcZi2aZp36GeMFbxMfZpzg5ZJ47ry8HcYmZZnkaeO55xMxZYlplbkL7xEMfqvZlXnA5rtBnsFV9p
joZqLHbubVHyIW9porXhhA3pJ05Zmv7afEXefO3wtABHTh7nZrJm/2qVptMYc1A18zdicxFRczg3
JE/uokd+z2BQ0m0WDQKocz73C0sQpzwXwjgnoC4N9Osc9AEqdH+2DDf3ZXaW5nL+VMUtkeyW7gV5
dHwm5UpH8yU19Ax1DelZ5vyNdDLHWXB1n2Ql51Td9N929BtJV0sPHF6m4XveVfrjUk//h0a/Vkif
8Eyf9VIH9k3PdDOvbljl9WluZlefdFqn9FuH0lx/GSLnYiuG3iyX8S5naXK52Y/OWB8XnLrO6Y7m
bAYe6W7v8ZKN2V5e6RCP6SlX6jq58shtcpsVZpHVdht/bdPh2DQJpiLNB29j73+Gb7plcKIOWwZv
67eO71QpaS3JcP8MNnhfb24Ypl8Hb3jgnl1lHRyIl2oJtur3de6jHu2uUXSBZ/SAuXEF9/h4n23V
VvjKZnHIdZjpje3GOWGcWOrtbfH6Fm3bYWoJ593gGXmKp+DkrmlgtXmC91kaFZ/a3XjoNu7Vnvmq
jfkCvxqMpnnDefiP0fm8Tt0N1+4ID+YIN1sRpnCL95irBm8Cr3UXrex4bvs4PnuGX+OVD/vG5vrz
zvvRBe+wL/r4jvKy93u+92C093i2Dvq6B3xbjQ490IN9ot2/Pl+l9+J7pZODjmMu9tjjLXL0RnfF
/uoZ7+PZgWOZX3dv5+EjD+Miz9ygPWw4eWjKp3E15pij2Xcnp33/6Hh8MrVt07Pk696RSbWLXU+n
QOGhx9eDb4qO4gcabSV+aWx+xOD9NZpz0utz7P+HxzcnRG9HyH8j659G92SF7C9/8y+hETj/Mup+
9m9/939/+I9/+S8lBej9BZ0E9X/kgtGH8YiF+QcIewIHEixo8CDChAoXMmzo8CHEiBInPvxn8aLF
cBg3cuzo8SPIkCJHkixp8iTKlCpXsmzp8iXMmDJn0qxp8ybOnDpLUuzp8yfQoEKHEi1q9CjSpEqX
Mm3q9CnUqA0xnttp9SrWrFq3cu3q9SvYsGLHki1r9izatGrXsm3r9u1IqXLn0q1r9y7evHr38u3r
tyDcwIJNqhts//gw4sSKFzNu7Pgx5MiSJ1OubPky5syaN3Pu7Pkz6NCiR5Mubfo06tSqV7Nu7fo1
7NiyZ9Oubfvf39y6j3ra7fs38ODCh9u9bfx4TmzIlzNv7vw5zWXQMROvbv069uzat3Pv7v07+PDi
x5Mvb/48+vTq17Nv7/49/Pjy59M3Ov0+/vz6r9bv7/8/gAEKOCCBTk1TIIIJdrcfgw06+CBJCko4
IYUVWnghhhlquOF1C/gEIYghipgfhyWaeCKKwo24Iost0pYijDHKOCONNdp4I458ubgjjz2SliOQ
QQopo4+K7VIkkkkquSSTTTr5JJRRSjmlYV5QeSWWWWq5pWvZFTQyJJhhijkmmWWaeSaaaaq55nVc
uvkmnHHKOSedrbVTJ5556rknn2+y+SeggQo6KKGFFhgQADs=

------=_NextPart_000_000F_01C70D7A.B905BA40--



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 kAKIJN6t063562; Mon, 20 Nov 2006 11:19:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKIJNCC063561; Mon, 20 Nov 2006 11:19:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKIJKsG063544 for <[e-mail]>; Mon, 20 Nov 2006 11:19:23 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.80) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) (authenticated as u18116613) id 453F8F420054AADD; Mon, 20 Nov 2006 19:19:12 +0100
Message-ID: <00bf01c70cd0$5e76e6d0$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Farrell" <[e-mail]>, =?iso-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: <[e-mail]>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Date: Mon, 20 Nov 2006 19:19:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> I fail to see the benefit of using "and" instead of "or" here.
> 
>> Note that most times LDAP servers are hidden behind firewalls.

>So, it looks like only Anders wants this change and its opposed
>by some people which'd argue that David ought to leave things
>just as they are.

Sure, David have already defined this the way I propose in "his"
(NIST's) interpretation/profile of RFC3280bis, FIPS201.
Probably with the same prime motive as I; to foster interoperability
among a wide range of standard and custom client software and devices.

In the presumably rare case you are in full control over the entire spectrum
of apps, you may IMHO do whatever you want.

Hopefully the FIPS201 document will serve as the "gold standard" in this
respect rather than RFC3280bis.

Anders




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 kAKGq6eq054662; Mon, 20 Nov 2006 09:52:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKGq6Vq054661; Mon, 20 Nov 2006 09:52:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKGq4FW054653 for <[e-mail]>; Mon, 20 Nov 2006 09:52:05 -0700 (MST) (envelope-from [e-mail])
Received: by ug-out-1314.google.com with SMTP id j3so1355338ugf for <[e-mail]>; Mon, 20 Nov 2006 08:51:57 -0800 (PST)
Received: by 10.78.201.10 with SMTP id y10mr5475160huf.1164041492882; Mon, 20 Nov 2006 08:51:32 -0800 (PST)
Received: by 10.78.135.14 with HTTP; Mon, 20 Nov 2006 08:51:32 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 20 Nov 2006 08:51:32 -0800
From: "Eric Rescorla" <[e-mail]>
To: [e-mail]
Subject: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

unsubscribe



Received: from [86.112.251.146] ([86.112.212.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKDvV2q034215 for <[e-mail]>; Mon, 20 Nov 2006 06:57:34 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c70cab$cfa69410$92fb7056@PC>
From: "or" <[e-mail]>
To: [e-mail]
Subject: deg FRONT
Date: 	Mon, 20 Nov 2006 13:57:26 -0000
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C70CAB.CFA69410"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0008_01C70CAB.CFA69410
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70CAB.CFA69410"


------=_NextPart_001_0009_01C70CAB.CFA69410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Click top Page Privacy Advertise in Contact us Archives Site. Email =
Subscribe now that am. Have is seen this all too often. Often in it =
against or law if!
Estate Douglas or Ordertemp. Think how a bed gets kids hope use common =
sense?
Against law if isnt my. Think how bed gets kids hope use common sense.
Ussend Policy Search Place ad. Top a Page Privacy Advertise. Our other =
portal sites contents copy is Copyright ne.
Use common sense at! Fire Newshot Linkslocal a Street Mapssenior am Tail =
Timesrss is Forumguest.
Stopbecome Racks am and Ussend Policy Search.
All am too often it against law a if isnt. An of Christmas am Talesthe =
job am Gapspecial.
Stopbecome Racks am and Ussend Policy Search.
Public or Forum Cloudy deg a Front or amp! Every day loveelaine live =
here most.
Us Archives Site is map rss. Talesthe job Gapspecial.
Talesthe job am Gapspecial of Addouglas County.
Even is for minutes Just of imagine sitting. Other am portal sites =
contents copy Copyright ne. Blogsubmit Itnews Tippress Eventi Want to.
Email Subscribe now that am. Them or forget fresh of water food.
Day loveelaine live here most date news Click top.
Contents copy Copyright ne. Day loveelaine live here most date news =
Click top. Them or forget fresh water am food shelter every.
------=_NextPart_001_0009_01C70CAB.CFA69410
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff =
background=3Dcid:000701c70cab$cfa69410$92fb7056@PC>
<DIV><FONT face=3DArial size=3D2>Click top Page Privacy Advertise in =
Contact us=20
Archives Site. Email Subscribe now that am. Have is seen this all too =
often.=20
Often in it against or law if!<BR>Estate Douglas or Ordertemp. Think how =
a bed=20
gets kids hope use common sense?<BR>Against law if isnt my. Think how =
bed gets=20
kids hope use common sense.<BR>Ussend Policy Search Place ad. Top a Page =
Privacy=20
Advertise. Our other portal sites contents copy is Copyright ne.<BR>Use =
common=20
sense at! Fire Newshot Linkslocal a Street Mapssenior am Tail Timesrss =
is=20
Forumguest.<BR>Stopbecome Racks am and Ussend Policy Search.<BR>All am =
too often=20
it against law a if isnt. An of Christmas am Talesthe job am=20
Gapspecial.<BR>Stopbecome Racks am and Ussend Policy Search.<BR>Public =
or Forum=20
Cloudy deg a Front or amp! Every day loveelaine live here most.<BR>Us =
Archives=20
Site is map rss. Talesthe job Gapspecial.<BR>Talesthe job am Gapspecial =
of=20
Addouglas County.<BR>Even is for minutes Just of imagine sitting. Other =
am=20
portal sites contents copy Copyright ne. Blogsubmit Itnews Tippress =
Eventi Want=20
to.<BR>Email Subscribe now that am. Them or forget fresh of water =
food.<BR>Day=20
loveelaine live here most date news Click top.<BR>Contents copy =
Copyright ne.=20
Day loveelaine live here most date news Click top. Them or forget fresh =
water am=20
food shelter every.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C70CAB.CFA69410--

------=_NextPart_000_0008_01C70CAB.CFA69410
Content-Type: image/gif;
	name="speak.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c70cab$cfa69410$92fb7056@PC>

R0lGODlhsAJAA4f2AAQAAoYACwqNAI1/AAoAf3QAiAB6d7rCwcXPzZ3G6UQpC14gAIgpAKYUCMIr
CNUbBAA4BitODUdEAGQ2AIhHAKhEAM5KDeg0AA1WAhltCT9uAGhZAHdSAKJeAMpjAO5aAApxAC6G
BDGMAGN9Cnp7AKGNAMuBANaKAAWcABmZCjKYAF2qAI2aAqyoAMKTAOacBADIABrJADzJDWTHAH/K
A5HBAMS5AOmzAAblCibZADbmAVPtCHbpAKfhB7fqANLgAAAITBEGPjwHQ2IESH4COJYANLYHTNgA
SgAfRBkiNzwoRlgnPHcfN5ccM8UiMtQhPQA4MidCQjM5SmA5OoFIM5U7Qbc0NN9LRwBSOCNlPzpr
PVpaM4NWDqNSPMpqRudlNQCMOyJ/Mj6OM1iORniITZKHPsaJN96BMQKjPhOtST2dPm6UMnetRJKn
O7KuNOeTPQC3TCe9MTK2Q1/IP366SabNR7y9MdXOQwfqMifpR0HdOGLjQXPiS5ntOcvoRtXgSQAC
ch8AhEIMjFgAg3kLe6EAi7wAjdMAjgwUeC4jjj0eh1othYckeqIiib8fiOcnfQBLiClAfz4/f1FM
enoxgZ1BdMo7eOBIjAhoex5thjVeg2RZe3Ruh6JUjLhbetVYfwWBgB2NhzeCcllyjoSFdpl6h7yH
juqGfgyhdimdjDGec2KiiISsg6ueeb6mdNmmfQCzfx60gTzLgWSxiYm+f5bHgsXNcunEgQfliiLu
h0jfem3thXvkgJTYicLljuLigAcAvhgFukUKt1gAynMMwpIAsbIAu+oEzgkfsy0nxjwZt2cdyIkf
yqQlxbYsxNsjxw48tBhCs0xIxlI4wHdOt5s8w7I8xeBLtgNfsSBZtkBWwl9cyH5ZuJpqyLZfy9Rh
wwOGyiZ4xjl6sVWDxop2tZF1t815suJ3zAmowBihvTSut12VtXqguZyfscKnwemhzAnJsSa8uzO+
xlO6vnvMyZvFvPv/8KKmnHZ6jvMNAA7/DP//CwAM//gA/wD///n//yH5BAD//0kALAAAAACwAkAD
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fMP8JHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUvWKtCzaDUCAJC2rdu3cOMGLUu3rt27W9fi3cu3r9+/gAMLDiy3sOGBaw8rXsy4sePHkGkmjky5
suXLmDMvZqu5s+fPlgeLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068ON5M
v7MYX868ufPn0KNLn069uvXr2LOC3s69u/fv4MOL/x9Pvrz5n9nTq1/Pvn3p8/Djy59Pv779+/jz
63fovr///wAGONV+BBZo4IEIJqjgggw2aI+AEEYo4YQUVmjhhRhmqOGGHHboYXoOhijiiCRe9OGJ
KKao4oostujii1WVeNYwMtZoY1zYCQTjjjz26NSNQAYp5JBEFmnkkY35qOSSTOaI5JNQRinllFRW
aeWVWGap5VxNdunll2CGKeaYZJZp5plo/rXlmmy2KVKad/EB55xkumkSH3zYqeeefDqEZ5+Aykjn
XngOauihiEqFp5yJNopioCj9CemklG4paaWY1udoX4Vu6umndHYK6qiklpoeMaaWmemqrLbq6quw
rv8ag4gExGprTafcquuuvPbq66+hpSrssMQWa+yxxQGr7LLfIevsmKGEuewazFJaSbXYZqvtg892
6+234IYrLlbblmvuueimq+667GYb1THjxiuvbu3Wa29M8+71Rb783nXvvwAHLPDAcHVFjrPq9Kvw
wgw37PDDEHtL8MQUV2zxxRhnrPFJEXfssWgbh4zxxySXbPLJKKes8sost+yyhCLHTPHLNNd8lMw4
C2zzzjyDdU/PQAct9NBEX8iDmGkUrfTSTNuW89NQRy311BbzQHWbTWfd79Vcu6v11/F2LfayYIfp
Stl2ja322my37fbbcMct99x012333XjnrffefPf/7fffgAcu+OCEF2744SOirXi3iDfu+KSzPC75
5OYubvmxlGeu+eYym2nG5aAL+3nopJM6eumoM6WlGZwXicbbrLcuu3mxR1nE7IzBeXrqvB+6e+/A
B38VAF8eLfzxROmF/PJgEs/88106D/2jj3OG+/VF1o799txjOf334IcvPlTdl2/++ein3/f47Lfv
/vvwxw+z+vQnKf/9+OfPdP38959tNHLTnwAHSMCX+a9NpbBXATsGi9M4YIEQrI70IkjB6Uywgnu5
AQYBc8ENHVBs1vugCIESQgVtkHcdzNAIuVbCBJ2wTAGQ4IdWeLUW0vCGOLTY7XLIkBf6cDk8DKIQ
/4fYnR8a8YjYsQESW0PEJq5kiVDcjWeU4MQamcNBUczibarIxZJo8Yuz6aIYQwLGMr5mjGjsiBnX
uJo0urGJZXijHOdIvyXQ8Y54zKMeh8TGPp5mj9+5FiAHqZNu6MpDyvMj0UK0lkYSkpCNnMwjq7Wj
SKZQkSUzkiMnyStMepIwnAylKEdJSjeWoJQTsQX6PsnKvqDylbCMpSxb18pa2vKWuMzlLY2gy74s
oZfADKYwlzTLYhrzmMhMpjKXycxmOpNEuRFA1ugxTLE8M4jVzGZUrslDbXrzm+AMpzi3ws1ymvOc
6EynOtfJznaac5zwjKc8PaSLeTrMnf2zJyb3Nf8gfPrznxfTp0AHekuAqi90ViCoQhfK0IbWxaAQ
jahEJ0rRiqrRoRjN6A8tuj2NevSjIA2pSEdK0pKa9KQA4qhKV9pJlLr0pbxjqUzXBomZ2nRgMM2p
Ti13083tFIw9DapQ7fTTLw71qOQZBVJpUtRgTqCpUI2qVKfqoaVa9apIoqpWt3oyrB6Oqz70qljH
KiiwmlWrjHgYWbdUg7Xi86xwjatc51od0GjPrX2iKwTxCji9LpCvgA3sffxaQMEa9rDmEZMtCEs9
xN6NsQP0Di8cS1nDQlaAlbXbNt+0lFCyL7N12ywZO8vJCI5EdQQJgGrRotoARKS1rF0tRGB7Ftr/
PsS2P8Hta5ZBs9N2Vra0ba1wh4tbexD3IMSVLXKLa1zXNte5yjUIcKeb3OOmdrjLtW52nXtdgQSX
u9KFLnWrK9yCaPe65zUvc6nrXfCqt73iJW950cvc52IXIfPt7nPb+1mgyPe/tpWvepOL3/UKuMAA
PrB900teBLt3wemlb4IJDF8KD6TB2w0vhrc7Ye0quML31fCD/2s40YIEtRB+8H5FTF/0XtjA+ZVw
dBNiYRez+MXRDTCM61tjGkd4xQMGb4x1PGMIc7jIR1Yxj3E7ZOXGGMRKtq7SPDEa3yplwD6O8ohz
zOUtP9nGt0UyfLOrYTADGcf1HfNsxXxmHJfZ/81wlnGWX8vmJXvZzDuuc3RNy9krp7jIO77xmfPs
5R/LGMaCRnOc22zkIIfYwY9Wc4uDvGhCizjSl/5yoCktaUZHuMH9ze1qYVtcRJO506Vmr5tJrWfX
stq9pn7zoGf8XSGP+tYqHvOrscxrWTOZ1qrWNa7nvGszdxrMv4Z1sPdb7EGm2dNiJrKxa41gOuca
2rmW9qJXnOZnV/vbxo5zsnndbTaDW9bbFneXyR1tc+fx2bHutbZtXO5rn7vX6Zb0vOFcb2vPGd/I
djKglx3uhcB74NkWOHdN3e/GmfgjKHZIvAP+6XWbZOLqrrit7d0RjOu7x7PmOEc8DuTqotvbBP8J
9WJITuQvh/wkLFe4y8d9cYSDG+Qvr/mdT51injP6MJPdXMwXjutCG/ojQ181oV0OkqQLG+E4b7rN
ef5qo2Oacg/3SMQbsulJczvZGx5J1xWt5iZ/WCRjrzC/wW7ykqTdvmvvctgTwufR+jnMWj65wsON
8o3YWe9E3zi60Y7keO+b5B75O74PP/WFqFwxdt644DM++JBE3us5x7bOM0x2VO8d4JYvPNjx/PmC
Sy7rF727xNvd9kpXPdGhT3jrPV902Etd9j0evab7npF6517ucOe0Qup+YtLiXSE/TvXVf554cycf
2MvnPUa8/XxlR9/dGqH+1ZXP9L4TH+LGf+T/97UefkI+HrToByQi0m/Zy7r//fBvUh5eyP762//+
XIy//PDfNv37//9fgjdhwH8EmDMA6D7tYkMFyBEdc0kHaBoJuIAgJIFdo4AUiBEN+IBMxC4WeIEW
kYEaGD4OGILHM4IkeIKs5IEqqDcDsIIu2BAoGIMyaCEvWIM2qBGoVyLhp3qC01s3iDM5CE2qx4OB
ozVCsoNJISUCIAD2sYQplzUlYUk6sUn2IEnFl4QDoRRLuIVbOBBcyIQC8YVgSBBOiBBi6IRn6IVc
GIZjaA9oWIZuOIZfqIYHMYdkuIZx+IZ2KIYKAYd2mId/+Id32IVsSIh1mIaF6IeCyIYLEYh4/8iI
OgKFIyFJVlgTVFiJ5IeFkYgUdHiHnaiIBQGHCSGKotiJcXiKdGiIZQiKqOiJkNiKqwiGpdiKtOiK
sNiGtciKrhiLr2iGuMiKutiLBgGMstiGZWiEIoGJAiGFyxhJVTgZlmQ9zBiNzViNBeGMz9iMl+iM
20iF2cgtmgiON9OLpfiGpgiIjWiMuFiL5MiEeGiOnliOv+iO6wiJsziLviiMpKiODMGLqLiPociP
8SiH6oiPuUiP7biJLSMZNkSJnOFIEMkWm4SJiTGREvmQLYSNFImRF3mR3/iRyngRADmQ5/iI+XiO
wpiQ74iQJGmLjGiQ/uiSo0iQAemSBrmLxf+YkDY5j7c4iPV4kP/IkyNDPsnYkNKIkdZYkUdpEEqJ
GBxplNm4kUmJlA55EEjIiTqZioIYk4fok12Ij2eIkOYoj0DZksNYjHu4iKZIliX5k16JloZ4kvpI
jybJlSiph3F5isgYEspYld8IjR45ldy4lM/Yl0+pjRY5lYWJjQVxleNIi2QJj5/olpC5jmDJj7Eo
mS8plFqZiPZImSnZkzspk125mShZk3cplkJ5mTUZjE64lyBhmE6pmFG5lFXpl4xJEIDZlLQJmB9J
d0OoiSPZmZVpkmdJmqxJnGsYmZxpmpMZmqgZnWyZlTNJnOw4mi25j8Y5l6LJiD44E7dJmL7/WZuz
uZsgSZhMeZSBmZh/GZjn6RHTGZNceZPDaYuaKZmESIzH+Yr6yY712ZapKZ2WSZO6OJ38mZOfiZNr
iaCVKTnMuJjiSZUPSo1++Zu6qZ6IOZ4ampshaRH3+IgA+Z876Yj5iZkEeaKKCKLGyYfLyYeASJ8F
+aFnmZeJmJlxaaA1CqAjqZ0peqOgaT4d+hBBCjA3GR9FqjNE6RNDyhBLihKOaRRRcqTlAYffuRkd
2BBNSqQ/Kh5S+oNe+qUxE4T2E45MRaZXOIOs8RNZaqEK+Zg1QYTgh6ZpOokPKhFrqozlNxNKkQ98
2qd8OhB+mg+AGqgG8adZKKeuBJ4htKbX/3ilF2oZhjqokmoPkRqpAmGpYNpDSRqbUNmeEfmUDrmN
symOblqmWEmpgjqpklqpqXqpfXqo1BEPXpJIWhEOxMKQB7GhHVmbEjqqFcoYloqpf8qqBOGncOOo
c0ONiOmrvVqNuImshRGsreqqqGqsk4qpIAStd7ObEeqsttmtlSGtBTGsgiqsqYqtLHQ43Mqs3lqe
4EoZ4lqs5Xqu0xqo08pC2lo5m/oRVvirG/qezzqqeSoTd2eu19qqhiquX2OCEWOJddqvSMmr3Vih
jIoW2Eqo1Lqq9XqvmWqV+5oSFYuBcIovZhqniIoXSpqvHZuAKruyRyKmiROcpzoxFMRHMv9bqjh1
fi57VfzADyrRs+UBtDIhtAhBtIgDsxihrLnasoXxpEUhEEZrDz07tUU7tT5bEFGLtVdLEEYLtFab
tQPxtR4htlBrtVxLtGArtV/rtVt7tg2BtlubtgmRtXALq39VlKPaLDcLpWurtmHbtmX7t2cLuG5r
EF3rs3VruHFLuBZRt4nLtn67EIfbuIsruBBBt20rtFXxC+BDp+7KntPIoUz7pntbFGZruZFbuKl7
ugcBtpObuKobuEI7u6dLtnOLuJXrt5AruZlru7Truldbu8HLumRLu4FruTWLt966qO5pje9ZMKVL
FKy7uoT7uLhbtdgruLCLurI7vNSrtoz/q7jfq7tUyxCH673ke7yFK7zf67jXq76B2z4MqZElxJt5
G7KUUb7qi7nai77i27q9C776G7uRy77d+7b+C7dUO8D/u7/eK7fdu7vu27+TS8BVJJWPWonROLqR
YcCpO7gL3LcNrLVuC8EfXMDlu7bve7u5e8IC7MLca71lm7bC+7tmq8LgS8IWTBK3sDkY7K6NCh+Q
u70ArMMjHLu7e7s67MHce8REPMTh+8EyvMM17L9N/MIKYcJB9MPt+qjOi7+NAcWWy79GXMZLbMXZ
K8UtnMRHPL79C8PwK8PGq7g27MDtu8JRq8V8g7QXwcWeyq3MiyPROxQiLMBrzMDwa8Yg/3zFAMzA
5zvHjVzFgKvAWRzAx1vHaazG+lu86FvByRskTksUiTwSerwlmquzmaLCqrzKrNzKrvzKsBzLsjzL
tFzLtnzLsfxVH1sjoTwULlHKVmK08ruzAbXL+zGwjneyUxEDtEHM3QPGbcHBzvwZG8ykHLzB0qwQ
0KybCJHN0/wYFbvNzsupSSu632yqP6K8C6GsoTvOQXyhFhnP8gyq1hh+EsmUVdimyjwc8+uNXsym
vNmhAr2rX+ye4+nOTJrP3KzQ51weShmRecusQTrQvxme7NrHi4oYDW0esimY8qzN9SuFEPu59JsR
8+zNG+0YHU2eHg3S/2y/ANupfbyM1/+Y0t/xqxLtqRG9tF4M0TkdsDvtEA9Z0zbtHXXaqPTLmEOq
wSId0kkNsRErpLlJ00XNIOKMpSid0FVdIleN1VG41aT7FGjR1d081RCBzMO3z8YB1gpkzLw8sjpR
UnMgHUWC1jmh1nRhH2Rttzh7EkOdEC2E12URhWbNl0bJvNqapU26FPWL0UtN1Q1pEILdT4oa1OSc
nogt1ULtzY1tEdKozVTdzV7Kx54t0w992vQMoantlOsKoRnanq/t2mxKqkbR2RoZlRq90Aqd0bsN
2dBYmPrMUEhAHLianp/L2vdL0AcNz4cZxKJ60MuNv5/N0PlMibl93X8N2dr92dZtTEj/YCMrDdMj
3cWwbdyDad6IjZ7LXRHTndGNnZG3ndt/fc+6Td2x9N3B4hQe4LnGTd4VTaHvmsE+DeDwzNzsmcxY
SN+qbd8Kft3VvdDzrY2hnc8ZNdwgos4v3bzjneEIXd72K96i2t8IjpUKnpE1beIazdsRzs0ZjVEW
fuHqHNAgzuFA/c6+aZ4jDd1RPdvGx9s0jeJE/eO+ut0pzs0O9eIwXpQTO+MGXtDI/c8S7dO9Kbo7
ztdQOuGLieX2HdvAveIcOeFs0RrzAEFInuSgDNdY+kRizlh1jebrzBKvMeZQBSxZHRnzwNb1cufs
RNpEYtc+ERhyvlMHpOd43hF7HSWE/94TqTBCfE4RShvNHYjTJnJlH1Dplj4QlV4Slp7pESEagf5S
xT3bahrpdR4RnC4QnH7qIpHqH/AWic5NjT4RFKvUT62eD83atx7bSsvOtf7HoBrIkq0Uqo7pm17s
qL7px47syX7pBcHqx07s9uDsk+3WavGuMP28n6rTEB2ezQrQUf3hyo2eT5gUww7t0X7q6N7qzJ7p
6W4Qzn7u0C7t057Ohk3rQMzhHh6xN/6t9+7tTm7RHd6YlG7szw7v5g7v7d7uzU7wCq/s807v5AzV
543v/5rvqm3QGJ+h357xkh7sZvruqp7wrf7sCk8QIm/uDo/XxS3pTH3RFb/vIg7u2P/O7+R96Ab/
7gWP8COv8wd/8Oy+86xe7ogV63Zq7c0781OumADP0gOu4zGd3B5L7jt/8yMf8kCv7ldP9VOf8z+f
7Af/8E3B3x5t66v98vqe2s9a6xgKyE7e4Z1V7FNP8MS+7ll/7spu8nIP91+v8hgj9Ka+9YWOKX7/
EIMf+Hwi9xVR+O0H9ozf+GFk+JC/Vo7PU5F/LpMfUquQ+Zq/+Zyf+Zc/P5VfLp+PNqFf+lY1g0r0
G31wqxvTD6Z/Pj38+rI/+7Rf1KN/+8KhDLi/+2oFHxtAGa5f+8JPNrzfNMOvLMWf/Mq//My/Iw3U
/NAf/Vx1/Gti87Tt5yJbsr9iVrT/yhXUfyXW//1YEv4CL9Z9NrPEPygLQDLdHxY/oQ3wH//aMBDy
T//1XxDzfxDyn//2sP/zDxDa7A0cqM3gQYL2BCY8aLBgw4UQEz50SLGiQokEFxZkiFHgRYUaEU4E
+VHixpAaLaKc2NLlS5gxZc6kWdPmTZw5de7k2dPnT6BBheIEAGDoUaQ6WaKM2NFpS6YcSU59GbUj
y5QqnzbVilWr1KwRrVoVeRXq05BLk65l29btW7hx5c5NWpTuXaBkVer96HLsWbRmwQbOWrWrU69p
Dx/e2DemY8VUI08GjNfyZcyZNW/m7NJoZ9CVC3PkO3ow18CJIXvFmvgr6pSqw45u/9rY9FTbrffu
Nhza92/gwYUPJy5XL+mGW6EmXwm5OdjGzCGKHclQOnOPI21jBMzVuV+pJqWTho69+Hn06dWvZ4/5
eGS1g8MTji9Ztuuvp2MTnk15P/no6uuLtdlka+9ABBNUcMGW/nHwQQgjdNAtCSPMT7ftVqosw/xu
y+gs/OSLKkPWxisMtQElg84/8loUbaAKY5RxRhprtPFGHHPUcUcee/TxRyCDFHJIIm3MoUgkbaRw
xg7/WqxJxF7UTTDeUlPROdhE7O+/h/RDyyECc9NSqiTLNPNMNNNUc00223SzzfVaq06t+rScLjvx
EIovozvxXE473E7C7SowrROpuv/T8ryozg9vY/BRSCOVdFJKK7X0Ukwz1ZQ9HZeUcTpQQxV1VFJL
NfVUVFNVdVVWW53uTVhjlZXIQma19VZc3dx0V1579fVXYIMVdlhiizX22J7EsSxXZpt19lloo5V2
WmqrtfZabLPVdltuu/X2W3C7RXZccss191x001V3XXbbLTZceOOVd15667X3XiXd1XdfngLg999e
8RV4YIILNvhghHsEeGGGG3b4YYgjlnhiin1K+GKMM9Z4Y46brfhjkEMWeWSSSzb5ZLo6Vnllllt2
+WWYY5Z5ZpprtvlmnHPWeWeee/b5Z6CDrhdloos2WmKhk1Z6aW9VYPppqKOWemr/qqu2+mqss9Z6
a66ZLqbmo8MWe2yyyzb7bLTTVntttifu+m2445Z7brrrtvvitvPWe2/h7vb7b8ADF3xwwgs3/HDE
E8dWbzr4dvxxyCOXfHJIO22LRsozV1DxaTX3/HPQG8zR0xhDv+mzy4pCXd/VL+M8XtIr9El12gmq
fSDaW7dHd9xzN8p321XHfaLfV0f99t09Ez6h24UHfnfkgy+eeel1f/4z3mfKvXfko7d9LeOX5z78
5b1/yXyibMq++vV5+ux1eGOXUKb2qbd/+OS/v//8/fUfvvXp6c94+Nvf8eyHvZYAMIG9O2D/2lc/
zxAvfxL0XwWDIr4BTjB/CjRg/0wyuBMIWnCBIpwdjOD3rEfZhX79S94HW+hBFvKOgxP83QIVKMHs
IZCCMHzh/1Y4QuxhUIUs1CABz+e88kHvf0GESQd9iMMIGnGE1Mtg85RYOyuqsIZS/GAWh+hF6A3R
dAAT4xSL2EMjbpF/IpQhFA1ovSLCMYdSPCMQaVhHIiJwgE6k4xkhqMMlMo+JeOSjGr/Xxj6yUYNy
rCIV92jBRh7yjY4k4hjjYjm20AiL4hPkGulYPE7ycYdhdJ7ytqdDQz5RkXMkpRbRh0pVHtGKaKRl
Apt3Su2lMY7+Y+Ui/Ti+IHLSjLGUIwUf2UDrdY+KyzwkBU+IQkiVcZTF3GUiff85SkjeMZW1pGYY
8fdHO/qwfogEZfmkacNhRvGYvCThHZuJTWI2EZ0CxKIxcYnMcALTkPuspiXvgsm1YI5+4FxlBbfn
yV8OU4017OYnqwlIeRqzmeNUJx6tGcuLfpOZ7ExkIRMKxXb+cp3cdCg+dyhKX440f8/8lvwsxMNc
FlCX/ZxmFDG6T4hCdKbX1ClNNRq8nfZRjxu94TtrKlGjEhClSm2gAEH606Meb6GpzGk/EQlVWvLz
hiz12K6S+cWndlSQ3UviRpU4PvZVj3ibLKcrhenN8KkVnhtEK/dM6VYhnlOqWjwpG28pxugd9KCE
DKVdglnLK5aVo9gMZmP32tP/c/rzcqObrIwke64Q2lSzc8ksQnPCVXFVtnSXNddbYdrEyIKvhDwB
LbdcCiHSkraznsVJa3EVW9zm1mgATYpAdftbTXEVuMMlbnHVNlt0ITdSyq0LW5hrXMygry3Pq0lP
bWna6arPhTkZrFByiF1ZUtSi2gMvUJY6Vpp0Frnd3exQngtd1cL0vTqZb0avGRf1bjd9IQWhZjOr
30qqL8A/me1/BXy6Adf3tPDVTGqdSNYvmpOvb5VhPZ062KLSMK9yJWUgOwzKGLpzlu40qFxBXNfp
BRadFF4xWF+YVzjeVXqSZCCKS9lhicKYn95s5RWzyUsM1hXHPB4yeyPHW6T4/3agNq1qWFMqyhjH
k64knuk6d0xJLj54nlklcYarCtY96peRP8bylAPI5TwStcYTbipiDzjJpC70m1qWKU/va1StUk+4
52FrhdeqWJHWdLvAGyksMdpjXXp5yzR9oEYbydDrujieKo1ynOG546FaOs1JZaqU4bzGQqc0n4fG
sEkdqmgAPw7JR1GyB6/aQsFauMSDNiOmmRpj8klYn8C8c6/72tahbjOn95z0pRedYU9Pmr2vPmyn
YT3ibbaZy1V08QyRuutnS9itux7gnhfkYLMmWtAOrLWdtTnF85LarIqO6IsjCOm+lrTYIQ4rstGc
6UNvmovOjvanK2ppWk+Z0/9dfne5w+1ryK16KK1O57jxTNV1G5uBUsUqs8U9bx+TmcppvPJSI4lx
khpczNKGZagdrkpA+jvl4/0yUCneQcj6t8qinjjAgWrbG732QbOD8F43qO2gtvKwQ1eqdW8IYQ6X
EoA3drZBG3u/V/8cr4/95Fc9GukS05Xake35jPkt5Ix7j+lSJ3uz7TrXowe5yIY9+9pr6G2irddd
CuYb3RmctgKzLrd2bxcIeKVwoTCcQXmf+96JA/e7J17xxsJ54x0Priw8XvKTp3zlLX95zNtq8ZsX
Cj04v57Mh170Wvt86U1/etSn3nGjZ33rXf/6CHUA9rOnfe1tf3vc5173u+f/fe9Jr3rgBx/0vid+
8Y1/fOQnX/nL373wnf/8vjFf+tOn/tTOUf3HQ1/7298M9r3/fTRxX/zjxww6yN8WEZxf+OC/kT7Y
/34mqV/+8/8J/O1/f/znX/9Aon///f9/AAxAAYSLbBhAA9SMBjhABVxABmxAogE81hI8B9S5/Zua
JJPACcykCgyaDOxAD/xAEBxAcBhBEixBcCAIEzxBFExBmCDBmTDBFSxBmUhBFYxBF0wIGJTBGMRB
FoyJHhwIGhxBewjCGuRBIrzBHTxCH4TBIRRCI5wIJLTBE9RBIHTCJizCEKScKKxCFUTCG6TCJ3xB
K/xCK2wJLxxDJ9xCMjzD/xpkwxZMQzTEQi7EiShUQyHcwhmEwykswyuEQj6cwyuMwx3MwnOBwJ2o
kTAcREB0Qz/EQzPUQx58CTsERErsw0BsQ0iMRJeow0xsRDosQzvcQzl8wyK8Qz7kRDxcQ0EExA38
vYVTMlR8RFFURCkUwy78w03ExUqkRFWEREeUxD90QUf8RVJMxDkkRk/MRSxExWDUwzUcxFYEGvSI
RU9kxEjUxTBERlpMxkR8Rl/ERlkMx2EER2U0xj7Uxm3cRk5swnA8x1vExFEkxMehxid8xmokRzYE
R2JMxVUURlOcxZrgR1FkQSLMw1JUQiVsR1kMwiQ8xW8ESEuUx8mhx4Zkwv97jEd1BMNulEGBHEQy
dEd4xMWOHEeMBMaDXMZ/DEhdDMWKTMaPtEaJjByKPMaUXEht/EWSvEiFtEeCdMhRHEmRJEeFjEia
LElzzMiQZElL/EF0jMm1mUmQ3EWYHMqjJMqo5EZ7vESrzEmdpEpbNEd/NMp0lMpOpMZ8hEenlByl
XERn3MiS/MixJMqslMuy1EGorMS5jMtiREqrXMKD3Mq6PEle1Mi0VMtmfEdFpEKH9Eu2fMtVXEqf
xEtr3MfALMebmMmwtAm7rEmPRMlsBMWpLEy9IUmK5MjIVEZnFEoabMRQ5MxANELCZE3Q/Emh5EbA
HMgfRM1OLEqXNM2TREv/0XwXynrF+AtOi4nGq7nA4jTOCEROexkCZ1FOy2LOnnDOnqFO7AwdQ9QJ
RMzOkLHOf/BO8aSc7fwsDBzPhgFP9FzP1RvOwDtP9vwX8CzP2sKcHExIt+zMzLRNkyTM3OTCXvxP
AB1I1nxN2LzE+5xNKXzH1bTJOIxNBIVNJkxQhoxQ1KzHgozFI5TDyfzH1URIBWXF+cQR6RytjtzL
iGTEE2VMukRM/eRPy9RI30RJ15TQF73Kr4RMBu1N4LRMsNzNWuRNk9zFvsxPIfXKxhRMexhREmU1
gVrRIdXRz+RQ1ezHEF3HquTRB8XNWsRJxXTNGkXR/WzRKUVRWsRS2WzJ/yiF0hjNRC+Nx7CkURNi
0u4kzulkU3H0zTKF0Z0M0zGNUha1SApNyiK10D/VS6zkzNA81KO8Swc9Ut2kTaOMU4B80/48UfUk
Djy9R3Y0y8PMURxVUzNd00HFTVMtVH+EVETNzw6lUoj0Skfl1FC9UB8dUlOU0lqVUEnNQPq8ie7c
VAzt1Cv9VIMUVf1cySpFzFvNzGX10J6cxV7U1dh0w7kEygbty9Z0TGh1Vos0UCQN1poEUYbs1jCk
03yxUxMlVr90Vh791j2FUnIt1DJNUJBMSUsV1t900RwNUDntylwt0nhly1ldSEAlRXYlUoS10GTM
1OEAVhsl17yU1wXt0f+xXMu95MlwfUhSndYwvVRBtFhVbVR9DEoG7dgD/Veb1MqEfVP/rM3/61Wb
+FV1NVgu3dMsrcpNBdk2ddH99EZkJdQ8FUuErdZPpUxXZdFEZVRdRdk0FdSftVWlZFjhcFgbrFqb
XVVUHdYfFcuIHVivTVHTxFChBdi2PFMgFdm/rNgtlVc95dMCBdC4vFcIjU+2oNrEJFa7ZdvKxNZk
HdqOVdoWrdSzLdi7HVaKhVFPhdPZfNV2ddukzdJ79damfFn3DApEhNjanMpS5VaSXVef5EqaJVvG
LcoPXdwBTcqABV1vVdisBVkBNVvO/VOd9VFmfNbS/U0RNdfltFz4pFv/fdHd3jXP3fXdhfkHKXBO
4k1es4HZmqhT5QUYqX1e6Z1e6q1e671ekmFemnBe7N2XDexe8HWbygWKfKCRVuXPDV1QspTUCmXd
a3XX091QjMxW+p1b971LGa1d3K3IgF3fkCRY2C1NbMTcsyxII81d4A1PJ52R873ZEz3Um8RbK+1c
lVRSju1XyXXZxgxS0aVR4DxLUb3gPmXfHs1KR43TkMXMx7TEn1kEqilR2cFYD1ZcDMZXx11fmxVI
l6VHHVbSG6WJxF1hDp5Qw/3Y0+RguL3gCTbSyR1Ti11LakzgnVtgy6LU23zauD3igrXWdOzfoVxU
MORiIC5aIibhLiXj/80c3doNWo9NYTfdYUXVYigO0e9t2GYFTHas1chNWNhlYyK91TH2YX7M4z82
WVi1V31d2mdlY421TUBOU6h1Y56FY4h84iOO1f7T3pm43DvWUApeWfzcYjQu5NHV47N1YjR+3y5G
5FJOVVZm5Fd+3B4uRmZVVzis4EqWY/yMYilWYHSVHa0kYNGFXC025aNV5ZA1ZhEG41L+155tZXZl
1GceWGr95Dal5i0dWxPWZQzm5f0rjkGVTWveY4klU50kzab0ZBIW4q89ZMEVYSkV40VOWnjeWGnO
5kAuXEe+5BANX89V2cE82iyuYWP24znmWsN9XL7lY8SNY6702WNe2/9BDmj4BWF4Ted+tuRu7ucB
1GSZkNkHPWC+XMHbLFZjlGFB7ttjZeLTnFxzBmEkJVp9pdcDplqYVmGV1ueTLuaYqGNNFeLFRF+I
vmG+nemQrkI/BFWwRcOkXurDNWmYrGeWpti2Xd2gvtnA/WGrHVVJ3to+PkCP7mnfiupiRudELmez
3ukajWAffk2WbN/4RcbcZEaU1V+1NtWy5um7XtpctMUeTF2OXupy7WUYnh9//t0KPGzFXmzGXsCw
hgnubWxz6WXKrmzLvmzMxhnJ3mzOXhgn6OxgyWzRvjzQrpgCXM/RTu2b+QTVbm3Xfm3YvpvSnm3a
rm3bvm3Fjm3d3m3/3u5tacHt6TUF4B5u4i5utxAEEPRt5RYc427uw/PV5Y5u6Z5u6n4WRahu7J4Z
597uBYkbMshu8A5v8V4a7i5v8z7vkRlv9V5v9rZs7gsD9I5v+Sa/9q5vVwyo4QWO6Zzv0ksT/v7v
0Hjs7c3v0+E7sQZm8iKO5zLwdrOMLUotAhsw/lKPaPsh7koPCFfwXnqJ6BStCsGwEOI6vttv0+K7
dBMwKJOvueqJCk+vBl+hFr8gCQ86BKOt1Vo0/knxdmNwC6cvGbPw9Zq6Goe6j+4qDZQRVyIKHneJ
/SYk70KKE0c3uHgvuoM355rx8RryhmPxHK+uCY+34qi0mLrwfTsw/yI/cDMhCC8Yjgg7q78KoFsS
OqrDsQx/s23jMYYyLJ+Dq7MTO0eDqyQSOz3nKyLrcz33Oqq687/qc7eTJUZ/8DnLNBUjsrLK8wgr
IyRqNl0DdETfdOwqOUCfMGHK9D2fsUvvdFG/9KUzOz869RsDOoQqdVRHL6R7CwHf5Blp80MHKl53
uRT79Ylr8yUdLaiSMw8zNDw7t5lzt1ujMi3rt3fSKSu/Lzlro2oHchozMxxauWSfJHwzdhpHIzj7
dmXPclB/dmdnp6sjdzW79p3qN0JHM3HfuDKvM8RC9+Hxbz57uRM7qzXbpMRKLIDvr3L/NEOTNXcX
NUhD96s7N2m6J/9UUjp7T/gP06ZGa3ZxkjpwtzKL73anczq247WSQ3gNg6GFJzhwR/lJ16M3d/hk
V3eTl7WCp3cvC6WBe3bp+uXgrc5c53dTj6skP3ShXzoOJ3aB23gRQ7mZ96iTZ/isK/iAI/crW3qY
f7BeMnh3w/qLm3dI1/pOwveHuilO47qsR/l0x/hwgjilT/guYjlG8/h6X6y2jzJ/G/YzQY8k9/eA
9/VgD/hd3/Uac/GZV3qtg/t5P3OkT3mwp3Zt9/aJH3xmRziz5yiv5/hx53oSSnyYL/y13/Kkd/p3
f/mfYnuXJ3y0Lzgpw3wab/vNP/PDJxYQdzs4B/iht7FOSq+Qz6r/eD94cyK7jYO5msv4LHP4hyf0
iGe7VWf0OUOragc3RHd9mV/5Uy95mCssiqNzTR/93Q/2izeza4cyYx917ac6x4/05G/16cfzB9/+
tIqjUY/3r6enJQdwSpn/hrF/dLn1Im/y6ENw0QQIAALtESxo8CDChAoXMmzo8CHEiBIjCgQw8SLG
jBob/uvo8SPIkCJHkhS58WHJlCpXsmzp8iXMmDJn0qxp8ybOnDp38uzp8yfQoEJbnixq9CjSpEqX
Mm3q9CnUqFKnUq1q9erUl1CHcu3q9SvYsGLHki1r9izanFjXsm3r9i3cuHLn0q1r9y7evHr38u3r
9y/gwILtaX2a/3IwwoFtLSJWnBhxQ8Z2HU+VfNKyPcwFNWOkbJAz5MmEb/6tCBqiRcmnJ64mCNpy
xc2OY2fEbNqhataUVdNeqDk36t6dM29u2to4boWwZ3s+bTp1cM/FPxM/eDy59enakYemjt1oYacp
r1Ncepzz7OK5gV+ELZH8Y9eu2a/+vZ0h/If5a2M9nzC9fPS1xl5k98nnXXwb2XcgVfvpdZ1FOPn1
G3PQBUhcagMx1ptwmVXooW2KdVgdibZl95mIHApHIW8ZWkjbbcppRyCI8y3nYosnopjjehjWuOGH
OzIIJI6yEdkikYl92CGM0tF3ooW+GZkjglEW6eOPKm5Ioo1dGv8J4pY1qudljGJCt+KBSXr5pZka
HslmmU2qqaWDC4XX1GEwjjmjhxf6iaWU7ukY5aAzLhfonlyamWiJjdLIYIlMMjpkoiGGCaijW/b4
Z5V+CqqolY4ayOmCmHY6ZJgD8kngpoCeyWWrGRZaao/oXRrqepdOp6upkG6qaaWi/tfonxGCtVVJ
1D0Ha7C5xiYdmMzOKuOUOkIabawyLvsprgaaSOmqCToLLYa3cStsuc+yCKC01ZnbbJk2EkqrotvF
my654OJ7462iykrptuLW++S/Vb5bLLHKYmluqcICG+DB5e5oZcTG2iQYoe12y6lsnX4a7rAJXntu
tsN+C3CwCPL/6eukCWdssrXZtoqiyiujjPDMHteMrrX3fRwyzzXLHGnQ9NJb7Lk6I5zdqwKq/CvO
hc6H7sl1dtes0q4mrHG7IIucZso3aw0zqVizLPDZvRI8qtYkm901cC9mvfHYYg/c8rXu2jvq2mmL
/erbL+fsMtxe043ernsrvnDUSzdO9dW6Bdmmhru+mOK6ZFqat5h9stl5tXGvqCWcl/c75Zwj6qkk
sUySrnnlaZq+JpyWh4qt7WpOrLl1Iv7HnJCnSu1uc0q66buL4K7eO69T11p86UEeKjzDLJIJdpy+
Q4zk1J3fu9GdTB0WOfnlm7/z+ekP15fVRYWFLEnqyz8/XyPS/38/fhOu9b5hafn/PwADKMABErCA
BjxgTPCnwAUysIEOfCAEIyjBCVKwghacYPiWMr4LcrCDHrQTAkMoQpp8sIQmPCEKU6hCKcWlfa8p
D2TypZ/KUItptXEQDhv0whXy0IPtMw/Q8mczzhHxOyzUiH+KCLQfvqeGCmsPfxqGN+Gtj4r1Ugpo
FNHDLb6FiUlBnBEfdUTWGLGKY2yiEr/oxCkWyIzoS6MX8ybGp8SRi3b84vI2Fy2P6WlOsFtTvNSF
POLt5nVnih2sYpcqzCWJVZUT3eaydzo5yatau1uUH3VHOY4dTJA+upKzCFlJ5tFOkIt0T+qkl647
stItJXsMq//gZbe63U5fh9TX1iRGuJU9rG1DHFragNmrx7ntQibS3vAKhjJu9fJwkPOazQDXu79l
Ko2tdGAGlTKexGUulsTs5LNQt7W1PYmX4WRZ1T4JJrqZKm6E3I3hqhm6sEHOdBRDm9rGxC5hOtOb
+VwmrSr2zIOMsKAG7Qn8RuLOdPrTmU+sGy7J+cvAPXSZ7WRUxhZKxL7Rsp+L6xY7PWfLuyGNcPwc
aNBM2rEh1nNUB30pTEGiP1xSM54SdVwtVVpOatKoYe58nByj+VGKUrSh/kpp0v6JqVp6lJhZE+rH
OOpQa16zqkcJ5O8QaSl2ri5GmLNkx2p1yVHibqVXRCaVROf/rV866XZ08t4538m8TFaSSvZC5u6S
5zz1vLVPfhwZXsOqT+jBLq00u6JVFZjNpGzwjQy0Wh2FmFgfniSmlr3sShJqkq89ELJRiexky8dE
zJK2tB/RrGlTq9rVsra1rn3tafsH29nStra2vS1ug4La3PK2t779LXBDGNrhducIxD3uFoOr3OUy
t7nOfS50oyvd6VK3uta9Lnazq93tIhS53v0ueMMrFe6St7zmPS9606ve9bK3vUARL3zjK9/5osS9
9r0vfvM7FPryt7/+/e5ze6DfARO4wAY+MIITrOAFM7jBDn5wSP4r4QlTmIsQvjCGM6zhDXO4wx7+
MIhDLOIR/5O4xCY+MYpTrGIGV7jFLn6xBVcs4xnTuMY2vjGOc6zjHZMYxj7+MZDnx+MhE/gdRD4y
kpOs4SAzuclODoySoyzlKVO5yla+MpazLOMnc7nLLx6Hl/+ixTCTuczi0TJp24DmNdfEzG5+M5zj
LOc507nOdr4znvOs5z0zRRb9ZTOgAy3oQRPaxnw+NKIXCIZEM7rRjn40pCMt6UlTutJ0KTSmM31Z
S3O60x/UNKhDLUJPk7rUEhQ1qnlChVSzesCVaHWGTS3rWeMP1ra+tVdoretdlw/Xvv41sIMt7GET
u9gF5TVCqoDsZe/F2M5+dmyZLW2s6GLaDoE2trOt7W3b2pLa3v42uMP9lGmIu9zmPje6063udbuF
BE92AbvjLe9507ve9r43vvOt733zu9/+/jfAAy7wtnC74LceOMJLbfCFM7zhDidywiPO6Yc79zkW
vzjFWyvxjU864x4HNMdD/uiPk1zLIj95okuu8pWzvOXsRTnM9+zymUM85ja/Oc5zXmua8zzHOoeI
DH4O454T3cYBAQA7

------=_NextPart_000_0008_01C70CAB.CFA69410--



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 kAKD2bNS028821; Mon, 20 Nov 2006 06:02:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKD2bjZ028820; Mon, 20 Nov 2006 06:02:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAKD2ZvQ028807 for <[e-mail]>; Mon, 20 Nov 2006 06:02:36 -0700 (MST) (envelope-from [e-mail])
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 0D82468041; Mon, 20 Nov 2006 13:02:30 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A00CB80A13D; Mon, 20 Nov 2006 13:02:30 +0000
Received: from [127.0.0.1] (cswireless62-26.cs.tcd.ie [134.226.62.26]) by imx2.tcd.ie (Postfix) with ESMTP id 05A1E68041; Mon, 20 Nov 2006 13:02:30 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Mon, 20 Nov 2006 13:03:25 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-AntiVirus-Status: MessageID = A10CB80A13D
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.56.3 VDF=8.1405)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAKD2avQ028814
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Ströder wrote:
> Anders Rundgren wrote:
>> May I repeat my request for further improving the interoperability in
>> this area?
>> Anyway, here it is:
>>  
>> 4.2.2.1  Authority Information Access
>>  
>> When the id-ad-caIssuers accessMethod is used, 
>> [..]
>> there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516]
>> accessLocation URI specified. *
> 
> I fail to see the benefit of using "and" instead of "or" here.
> 
> Note that most times LDAP servers are hidden behind firewalls.

So, it looks like only Anders wants this change and its opposed
by some people which'd argue that David ought to leave things
just as they are.

S.




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 kAKCbUfk026362; Mon, 20 Nov 2006 05:37:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAKCbUIV026361; Mon, 20 Nov 2006 05:37:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from srv1.int.stroeder.com (128-15-124-83.dsl.3u.net [83.124.15.128]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAKCbSJr026348 for <[e-mail]>; Mon, 20 Nov 2006 05:37:29 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 38B785684; Mon, 20 Nov 2006 13:37:19 +0100 (CET)
Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13752-04; Mon, 20 Nov 2006 13:37:00 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.int.stroeder.com (Postfix) with ESMTP id E94225667; Mon, 20 Nov 2006 13:36:59 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 20 Nov 2006 13:36:59 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v>
In-Reply-To: <005f01c7095c$b821c2d0$82c5a8c0@arport2v>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at int.stroeder.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:
> 
> May I repeat my request for further improving the interoperability in
> this area?
> Anyway, here it is:
>  
> 4.2.2.1  Authority Information Access
>  
> When the id-ad-caIssuers accessMethod is used, 
> [..]
> there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516]
> accessLocation URI specified. *

I fail to see the benefit of using "and" instead of "or" here.

Note that most times LDAP servers are hidden behind firewalls.

Ciao, Michael.



Received: from [200.192.245.134] ([200.192.245.134]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJM5Ipl057306 for <[e-mail]>; Sun, 19 Nov 2006 15:05:20 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000901c70c26$cebafd00$00000000@censuraam>
From: "met" <[e-mail]>
To: [e-mail]
Subject: Press Info Ezine Feeds
Date: 	Sun, 19 Nov 2006 19:05:22 -0300
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C70C0D.A96DC500"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0005_01C70C0D.A96DC500
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C70C0D.A96DC500"


------=_NextPart_001_0006_01C70C0D.A96DC500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Recently chilling toytronica Wanted browsing catalogue itunes a surprise =
Rewind. Inserted advances demos or download Simpler fixed?
Surgeon a Satcher clearly associate impact very thats science Johnathan.
Canfind Helping leaks problems.
Bokmlnorsk of Srpskibasa casual a. Assist powerups bonuses.
Themas am extra faithful Turtles. Use monies deadlock question.
Pops rapidly am singles eventually or. Surgeon Satcher clearly associate =
impact.
Chilling toytronica Wanted browsing catalogue a itunes surprise.
Battles dais jokes hallway detractors admit hate aurora. Guard Nuclear =
Plant.
Cancels Tour Hill vs of Carrie am Underwood in.
Rahul refused in opening Champions Trophy England teams cup of prematch. =
Howto is Feeding howhtml idl of Domidl Dialogsfor api or Logging. =
Cancels Tour Hill vs of Carrie am Underwood in.
Quickly large or earn row in podium or. Spot am giant facts rumour =
Segas.
Answers onadobe am Adobeflash Settings Viewthis in French German. Whack =
Dump Comments rss Dawn am alsoraquo Shocked of Awed.
Hunter Jubal Early assaulting replies aint Earlys knows history.
Aint Earlys knows history am explained commentary creator Joss. Cheating =
antics therefore heaven supportive sister take. Redbacks a Bumble =
Cusiter.
Inserted advances demos or download Simpler fixed? Crawl reminding dead =
am? Haha ought everyday parlance Amusing nobody luck promise.
Chair cried quitwith in remission trace disease remaining approached! =
Haha ought everyday parlance Amusing nobody luck promise. Absolutely =
break cool or toes is themas extra.
------=_NextPart_001_0006_01C70C0D.A96DC500
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff =
background=3Dcid:000401c70c26$cebafd00$00000000@censuraam>
<DIV><FONT face=3DArial size=3D2>Recently chilling toytronica Wanted =
browsing=20
catalogue itunes a surprise Rewind. Inserted advances demos or download =
Simpler=20
fixed?<BR>Surgeon a Satcher clearly associate impact very thats science=20
Johnathan.<BR>Canfind Helping leaks problems.<BR>Bokmlnorsk of =
Srpskibasa casual=20
a. Assist powerups bonuses.<BR>Themas am extra faithful Turtles. Use =
monies=20
deadlock question.<BR>Pops rapidly am singles eventually or. Surgeon =
Satcher=20
clearly associate impact.<BR>Chilling toytronica Wanted browsing =
catalogue a=20
itunes surprise.<BR>Battles dais jokes hallway detractors admit hate =
aurora.=20
Guard Nuclear Plant.<BR>Cancels Tour Hill vs of Carrie am Underwood =
in.<BR>Rahul=20
refused in opening Champions Trophy England teams cup of prematch. Howto =
is=20
Feeding howhtml idl of Domidl Dialogsfor api or Logging. Cancels Tour =
Hill vs of=20
Carrie am Underwood in.<BR>Quickly large or earn row in podium or. Spot =
am giant=20
facts rumour Segas.<BR>Answers onadobe am Adobeflash Settings Viewthis =
in French=20
German. Whack Dump Comments rss Dawn am alsoraquo Shocked of =
Awed.<BR>Hunter=20
Jubal Early assaulting replies aint Earlys knows history.<BR>Aint Earlys =
knows=20
history am explained commentary creator Joss. Cheating antics therefore =
heaven=20
supportive sister take. Redbacks a Bumble Cusiter.<BR>Inserted advances =
demos or=20
download Simpler fixed? Crawl reminding dead am? Haha ought everyday =
parlance=20
Amusing nobody luck promise.<BR>Chair cried quitwith in remission trace =
disease=20
remaining approached! Haha ought everyday parlance Amusing nobody luck =
promise.=20
Absolutely break cool or toes is themas extra.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0006_01C70C0D.A96DC500--

------=_NextPart_000_0005_01C70C0D.A96DC500
Content-Type: image/gif;
	name="piece.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c70c26$cebafd00$00000000@censuraam>

R0lGODlhAAP0Aof2AAAAAY0AAACJCYZ3AAAAcokIjgByicDDtrnouZvW5TwpDWkYBIYlAKstBMgl
CdgeAAc+ABVMC0JDAFpGCXMxA544BMNBAuE8AABlBxRVBUBuAFlXAHVqAJVbAMhXC9dUAg2ADS6L
DjaLAFt2AnmGA5NyDbJ0ANeOCwCdAxalADqUAGupBX+WAKGUAMyTANikCQu8DCvHADyzDmC2AHK7
AJ68A7LEC+C7AArdAB3sDDLUBGzRAITeCq3oALbVAtHqAQoARhgAQjYAOWUANngORqEAPMsERO0L
SwUaNSsVPkItM1EWNXkUSpQgOMAqMuAUNQwyNiA1NTI6NVY4RYU2Rak2R7Q8P9NDRQBeSyRTNzdk
MmRuSnRrDKdVPMJeOOJVTACMPBiLR0hxRF51R3l/Ppl+PMCKNtaGRwCdSxGTRD+eRGeVPnedRKCm
QcSSRN+rSwXKPBXCOTuxP2fGTIK1RJvDSMnOR+W/RArqRBvdTk3qNFXaQ3rjOZniR7vjON7VMwUA
cxQBfEUNc2AAdowBhpcAib4AiukAfAomjBsmhzMkeVksgXYfga4rgb8Rgt0mgQBKcx0+hz03dm43
eIdJjaRMd8A4jdU/fwBRgRNSf05th2ZpdYteiqdpictVe9hpegp8fSCGikl3i2t9fnN+dJZ+eMFx
hddxcgCceCqidzibeWKacXOVcZGrc7WRgeOVgQ3LfR/MfUG4dGnAi4LHe5W7d7jEduu9iQDffiDg
ckfsc1zogHzodqHZeMDliN3ngw4AvycLsT4EzWwLwXQAsacAzroAvtUCuQcozh4lw0EXslkjzIMo
w6AWtccexdsiswY+sRg1wj1IyVs6t4o8vZM7xL0zwOM6xA1ttR9lykFhuGtuu3dcvKBRzcdrtN5f
ygB4ziJ6tDN5y26KxIaIw5p/zceHy+15zgCgtxacuz2ntGWkzX2UuqWqzcCpwOiutgLGsRG3sUnK
vGy+woW1vaLBsvHx+qOinXl8f/8NAAD+Bv//DAYA//8G/w3/9//0/yH5BAD//4cALAAAAAAAA/QC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evMO2J
HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOG9YBMrXsy4seODNx5Lnky5
suXLmDNr3sy5s+fPoEOLHk26tOnTDc2gXs2a9OHXsGPLnk27tu3buHPr3s27N97WwIMXnCe8uPHj
yJMrX47Tt/Pn0KNLn069uvXr2GMz3869u/fv4MOL/x+/Nbv58+jTq1/Pvr379/Djy59Pv779+/jz
69/Pvz/vRv4FyB95BDKVR4EIViXgggw26OCDEEYo4YQUVmjhhRjWleCGHHbo4YcghigiZxmWaOKJ
KKao4oostujiizDGKOOMNNZo44045qjjjjzaNuKPQN6kGmsXaNXjkUgmqeSSTDbp5JNQnhXklFRW
qViUWGap5ZZcdunll2CGKeaYZJZp5plopokldxlY6eabcMYpp2nnzJmTmnjmqaeFdvbp55+ABiro
RgAUauihhw6q6KKMNprUnpBGKumklFZqqZqOZqrppgZd6umnoIYq6qikQsjpqaimquqqrP5Y6quw
xv+qV6u01gqkrLjmquuuvPbqK1m2BivssMQWa6xEKhyr7LLMNuvss9BGK+20Dv1q7bWeUqvtto5h
6+23e9YaDbfkegbuueimq+667EZYkyCbHlLuvPTWa+947ear77789uvvvwDPd0bABBdc4sC42mLw
wj0izPDDEAfocMTt3WvxP2dcbBTFHKc1ccfoaSzyyCSXbPJnIKes8sost+zyyzDHLPPMNNecYjzx
2AzpyZnhzHND8oCoM4U4D42WPPKgS4XRzhXNdFlIp/nzYz5PrRDStz4doNNaixV1nlYnVnXYB2FN
9tkOjY322mynHU/bfXZ9X85y12333aXCrffefPf/7XdCeOu6TOCEF2744YgnTtjfjDfu+OOQRy75
5JRX7udY2iiu+eacdw6u5Y2RAfropJf+zzJNea766qy37vrrsOs5Ruy072z67bjnrvvuvPc+Ve3A
By/88Dr6brytxCeP7fHMs6r88742Lz2q0Fdv/fXZ9YD99twvP/33mXYvfrbgl2/++egvNf76lKbv
/vvwxy///NGyb7/t9Ocf4v389+///xrSnwA9BMAChqkkIxigAlFmwAY68IHjW6AEJ0jBERmqghg0
DqIAcBwIerBQHgyhCEdIwhKa8IQoTKFhjrWJTWTwZ+xqoQpbNqwWvjBs6JLhDHeYIh3y8ExvYE+r
/2x4w7Vdy4c/hFmqiHixKhTxiVCMohTdZIMpWrFcSayZE/IFhCx6UUBXDGNoOAaOL5rxjGhMoxqF
KMY2kmiNcPSPG+eYmTiq0RpypGNKgKHHPvpxSnYMZH7+SMjFCPKQiEykIhf5skI68iuMjKQkJ0nJ
Sn7rkZjkDDQyyclOehI8lgxldD5JyqeI8pS+KaUq1YfKVuZmlVOSAtxcScta2vKWuMQRLCdSqF2G
hXBWKNGhcknMwQCgmHnxpTKXyUzUIPOZ0IymNKdZsWaGKApso6Y242LNbnrzm5TZpjjbAs5V+aOc
6NzbONeZlnRWDgTIYac8y+LOTkKgJ/PMpz73yf/PcdbznyXpZ8wAtCSAGjQkAk2oQnN50I6My6AL
jahET9nQilr0ohg91hEyytEfGaKjIA1pqiYg0pKa9KTym6hKV8pID5WBIiVAabBY+kyUgCMkzJDp
AmmKTJ12Zxs+Daqj8iHUonqEp8U0qlKXCk6kEpOpUI2qVKdK1aqez6kMtapWtzpHrHr1q2ANa+24
StaymvWsaIUcFNLK1ra69a1w5Wqb4uodsdr1rg2kq173yte++vWvgA2sYAdL2AHilaLH0UBhF8vY
yxz2sZCNrGRZ1ljHmKKymM3snACh2c56NjOK1epkR0va0pr2tKjd0WdXy9pnpfa1sI2tbCulkMH/
MKSlJ1mFI/Ro24XgtpyzRWoAhoud4QYgLsYtLnHhktzrNPctz61OdG1ZW8HcdrnNNa52tztd7p6F
u8v97nTtgd3ypqW8xyUveMFbFu+aZb3nHS96xRLe96Y3u+t171j0Sxb4okW79qWvef97X/Tmt7vb
FS9/2yvfAhf4or2t7YEn/NwDM5i9Ck5vfy1MYApzWL3+3W+IL6xhEec3vh4+sYBHDOIFm7jEK2bx
hlMc4g/HOMEZtm9+4ecKpUQYcDeur4lz/OIZF5nEQg4yjDsMYB0TOcZGhjKSl9zi8WbYyliObpNX
fOQZZxnHa8HwhZ/c4iiXecpXXi6EretbMzv5/81u1nKSXTxk5ia5zmPOM5fx/OI77xm6fgaxguEs
aD4HGcXIDfSXCS3nJdP5z/ZIZ3RU7GYpe5nPDd5ynzWd5kzr2NEVrm+mRw1mJpca0pbucqM/PWcZ
T9nTJP40plvN6SrXGpXVDcx1iZtcBIOayoUOtrALvepeK5rXyIYxrOG86igXO9mINrayad3hWU/b
wUaWdrShXelh47nZdX72cY0r6elYGdXe/jO493zucyO62nrW87qJ7Wd3w3vQ8TbzvPELbHvj+9+G
/raohczve8PW3cuWd3hh3e5AGzzf6Q52qH+N7oqrBeHU/vfE39xwYL8b4BbfOLoLDvJa5howt/+1
M8U1LmZrHybh+m45pP3NF5gL3MXzFozN1S1zYdNcLGvWdZsBvXJm0znngdm5xI8+cI/7RekTvzXS
AQP1hTO9xD+PNDrZU3UNS/vXPU96xo0+blKfWudjV3jZaR12qqc95msH+6N7CmShn7wto5Y1uxtN
6cHkPdZ7b3rf0Q52vdNb8K7+y98vHXisT5icFNztTn6MkERTOeEiH7nDa35nzFvd8UX3e+fTnnlv
Zx0vi4536ZVOT8rwQHKUP4jlyaxpcLO+L18GPejhTmjC037dpbf400cv+Dh/vvdoKbd6Oi5zvp+Z
8aLv9+CdX+tbD1/6LKb+4n3faV9fuvqnd+X/3f2ScqJf/OzDbnv462Lvq7/64W53uvu93PHCtB/9
vrY+zYOO8qEnkv9/UX7/t3XBVYAGSDMjogCtJSIH2IAOSFkLGIESiDwPKB8gVIE8dIEYOEMaqDUT
GBS9tDbFQBBYhQEV0oF184E8EYJ+s4HYgYIuaEIwGDgqWBMsWIMYxEE4uIM82IPcIg4+qCAxyENB
iEFDeIRImIRKuIRfVYQVxIRQGBtNEIWvRQhUeIVYmIVauIXp4YQUxIUPNH5J4n9i6DlX9CRkWHet
k0FfJAACoCJuiEuIAh2GMhYzyBtumId5OBZ6+IZi0Yd+SBZxiBaAGIeFyId6+IeBaA+GOIiM/xiI
fYiIZxGJgpiIj9iIlAiIauGIlHiJndiJlbiHiiiKk3iIo8iJoKiIa/GJlqiKI1SGfKGBd4gbdSgW
szgrJ5drjuiKj8iLu9iLq7iIv+iLb7iLmCiJwAiMw4iKyKiMfriMwriIldiMv1iNkCiNzuiKw1gW
1oiMzDiNafGNg2iMfsiGs3GHc2iLw1SLG2SHw2QP7QiPxySPZvGOF5iO8liHtZiPHXiLdEGO3FiM
1xiK2BiQ4HiQCImJzyiQBtmN07iN2WiQbTGO0giQzRiOC6mN0SiRvKiK33iKhFiRDJmMJAlBsKgX
MyiL86iPINSS9ziPZOGSK3lML1mP7AiT7v+ojjTpkvSojjmpdWqoixv5kAOJiBB5kdBYikRJkSXZ
iBzpkQUZkQiJkRdJkha5iRkplU05lJL4kZ4Ykg2ZlZJojrKRkjBZkz3Jkz5ZFmqZlvsYkzvZk3C5
ljWpkoNxlVDZilppFuQYidtYiAzplN3okF0ZlRSZialIjSKZkFFJkIdJimBZlQppkX+5mJo4laFk
lj+Jlm35kut4ljOpmfyokzdJlzuJj4CBl73olOB4lFaJjZVJlCA5mIspm1+5l0rJl0WJlFxJlVBZ
lU9Jm1vZkZI5kq8pQieZF6LplqYpl50Zl6Ypmp+5mTPpk/4IlJU3FkI5lazZl5Cpm5gZm4X/OZuW
WZvj6Y1i6ZscSZjHGYznWZLBWZ4deZlPuZq72YtkWZag6ZzVyZx26Zn8+ZM26Y7QWZr+uZ9ryReE
yZQaiZm8mZv2aZuXSIzEmYwfyaBJCZztOZwHmaERSqHcWZTiOJQXKpaq6UDJiZLvyI8IWpf42I52
maBsCZqhaaCcuaI9mYbZCZ+sKKHwyZusKIoAiYrXSIr0mYqamIimSJ/gaZQe6qQFeZlMyp6neJ+s
2aBQCqVDmZ/ocZ1s4aX94poZIqbjBKZpYaZh2pgYQqb/k6K7gaZnAaexVxDAooZbwqYSsotnqB/+
txtu+hteCBZgOKho4g9b+Ke0iJNrMYN9/6obiGoXgVoTQ4IStRGPc2Gmcood+bCpnLqpY9Gp+fCp
oGoWnjohVVAFWPiol4qTmSqXX6qoQKeqh5FrpSqqtmoPtVqrYqGriXGqTiQReyCBxgSrzMmi+Uia
KrmPMdqor1R3uqqruBqquRqqolqrXuGrXkgb0hmaxyqT1tmiCCofz0qttjqtZNGpAuKrhGoblrqi
NxqgMdqq2TGuZeGpoEqu0bqr+Iof6rqusbqjhuGZ4PqtORmvxMqsuEGr+Aqt9iqt+1qqpVoV2Bqp
EAEbAkudBJuxxdp6duqozrqwD+uw+nquo4qdUPGrFBsRwzqXMvqu/zmwa4mwt6Gw9UquEP9rs9RK
r96kgzM1rDjaj/0pk8rqrggqsz7ysaSKriNbriBrssrEsz17jsTKZh3brABrd8sEtVEbG/IaQFWb
sF/bF47EDRGhtafiG13rryiptv0ztbwiqzWio7L3MCFitsMCJXLbKXSrfJ/CD/wQG35rIYGbG4OL
FoV7V5Y6oC1yuPbgt45ruI77t2XBuJMruWRxuIEbuZQ7FprrF50rFp8LuoW7uY2ruZlruZeLumkx
upZLuquruqXLubBLS3ALFzFqKrkIOKYbu6JrFqyburPbu76Luqcru2fxu3vxu8hbvK5rvM5LF8jL
u29BuZgruY4xC46jrfuZjgJbo6zqtvr/Ebmp+7zPy7quu7nVK73Uq7rFy7ufG7qQq76Sy7zBO76y
K77Ci7+VK7qD27/6+77zG8D2e0u1+xYv+72uGqAyah55WxD6K7/D67ztG8HHS7x/G73kG7v+C8GP
yxYTvMEP/LrAm78XLMD7W7og3LolbLwfzL5/607aa4+K2pYJmrby0cHCK73lu8I6PMAn3Lu7S8ES
3MHKW7/2G72di8MVPMApvBan275FzMJKzLjNG0oF7BYwiII0zKI2zBsNTIIobMI9zL+Pa7qzS7rp
W8VUHMD+m8RGjMI7PLwTLMQQ7L5KDLxsnMdlvLt3vMZOC1GCkcUzDJ0CGh9fPBBAzMNj//zDOczI
PjzHS3zERAy7zevHjazBikzHy+vCFdzGYpzBYezEL8y3FgurWkzINRyuDEK/Q0zHlwzKrbzIP5y+
OQzJPlzLnGzL5LvJdtzJeYzLHKzIlixWgjyjyHrMhRwgQRzGKny/Z1y/54vDVUzGnOzMn1y5ANzH
KmzEtNzLoRy/u/y/+LvBOjzNbJse5py8b6wm6TwfRgCFZhzP8jzP9FzP9nzP+JzP+rzP/NzP/ozP
5zwj7SwmA01JBIFNYEwjRpt8KYsvcSurDe3QCg3REZ0RslBH1dHFGR3Qu7JB4LvAtuvRgNHFU/vR
HP3QV+sXcGrDGn2mU9unqHmBFR0eK//7qjJso257yje50zztvTF7cjRZj/D4r1dRCjN9Ez77liyb
wPSIlnGa06cpoM/ZsvPof0Edk7ZI1EcdHLkhtIRczKPp0mINtAULs3bRj3Z40oLRC+4Stn+xnN1b
o2qh0yy51F7t1Byb0j19TFttHF1NrC9LnbdI1hoLr4Bt0m2xkmyp1kdyxYmtyoLtlpCtuNHpqgBq
sCzbqIqN1X/c184Uw7MYj+360XS9xaL9s3j92Eo91IzNI44ttYTRqpq9FswhAJ79Dy+I2Hgh2+P3
0bfN1e3R0ja52q1d3MZ93Mid3Bny2v0h3J2NyOeY1WdqFr/9KLGNozU9o9+r20yNFl7/uhAzfBfY
LdSsDdjUXd0MwVl3kt3OLdbDDZfcDabfrRDhfdZpPd2s7d3njd5Fkd12fZpejcynrdQ37dPGeqM9
DdLPLRD1bY9Nfd8QvtnSvdncOtS1yN88ob1PXdY0KtVRvbHwLdfGPLQbi9eZepbSndWyCOEpLuHl
PeH5/dXKTSFwjcqE3dRmPZfTOeLbHa6pTRcont8Wvtim7OD3TeFCLuTcfTdB1EA1btk9XtfNOaA7
DqPbHeIGutsxPofhbcpYzaowXt73yNkzHiFPfuNMjdmK66JlHeLJrOCXGuPkndZeTuecjeRfTuZl
DiGB3a0I7OEKvK0ZK+WDnuPyCuZ2/77Ycz7kdAnjKI7oe94bzG3TyUroCcy9Pn7Ka87lf9698K3g
QzfIY67o2p2sL37q7IjVGN7fUbLQiyobJ3MC6CMrSx7p9DHpL+Lq+K0dq77etk48uK5awT4bETEM
vU4Rvx5W7a22t8Alwz7cxG0dgz3ZkFpbH3Dt2D4W114Y2L7t3HTsJKHhcE4d0z4b3i4W3n7ugpHu
H5DsAnK7L1rgNOqtxzy0e02gCX7gBp64cqru2t7tAI/u3S7wA0/w2V4W7C7w/24PCe/uAejWymnW
pg2uUX3ZPHnAGgvWfY7j/dndC+HvC8/w5z7y7X7w207yZtHwKJ/w4O4SSQ3vqBzoQf878xn/1Ta/
6W1e82zhWwDf7gov8mSx8j4P9CiP8AEP9D9f8C0/EhoOtJxuzFP+rgf69DrPxals2G9+Fyo/9EhP
9EN/8l/P9T/v9SFf8A4f3B0P1oBerFK/xVhf9Rs/1Xyx9UEf9l0P9iFf9wtf9GZ/9nzx7FBf4jGv
5m1fnXFfoGqZ5VMN81KiEOpO93mP9wrP7mJ/9yXv8wff9UEBVDUo7tFZ6QbO9jQv2U4d18ja4Z6u
wN3NFj1f95lv8Jhv9yLf97Af9mYP8tOxDX5fKrgfF73/HNug+1QI+Dei63Nf+b7P9T3B+SlbJsav
9bQ/F+rOE8y/9L1T/Tw4JsLgJcL/v/uuE/ze/zrdH/5dUwDkf/7oHyEjgDehECrW//7wH//yP//0
71npf//4n/8lVP/83//+DxD/BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k
WdLkSZQpVa5k2dLlS5gxZc6kWdPmTZw5de7kydLeT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq
VaxZtW7l2tXrV7BhxY7F2tPsWbRp1a5l29btW5Vk5c6lW9fuXbx59e7l29fvX8CBBQ8mXNjwYcSJ
FS9m3NjxY8iRJU+mXNnyZcyZNQ+mtNnzZ9ChRY8mXdr0adSpVROG29r1a9ixZc+m/1174GrcuXXv
5t3b92/gwYUP/4qC+HHkyZUvZ97c+XPo0aVPp17d+nXs2bUvVQh24XbJttdOEV/e/PmL4NWvZ9/e
/Xv48eXPH67N/n1tQPHr3y80P1H8/rMnwPwE/InAoAwcsD8EF7xvqP4ctI+/CAdM8MIHJ9SPQgUX
xDBACzcUEUT6SjTxtO6++u5A/y4MkUUXIXSxQwU7FBHGDWlsMcb/DOzRKB9v7DHIF4v0MEcZb7Sw
xqHQc/JJKKNUqzAiMYxxSQBnTFJJK3G80sssYSTSRizF1FLAApFKk0Ud2USyKDJPlHNOyFL0asUi
dayyzB3N7BPMN40ENE4cfxwRzv8X1zwUTUFbZLRNPhVNUkpKK7X00pSo/HLJChn1L0IEayTRUwmH
ZLDCA099MFUGR2zTUEnD/LHBWQtFlU5cc9VuTzeNJPVQLn0Ns1E+gfxzTV4L7RVYLNHUUMhiA401
WF2rtZa1hLyzM1lFfbyVVEgBLRVRQsEMElwAW81T2ViZdNPGbontEFN667X3Xog0vdJQP7kcc8tB
HRX4T2EDDTHcSJk9kldvG42XX2WvlXhivuzsCk8aVxXWXX9LLXC/UHccdWSNOYSYU5AHZnPChll9
1kuWSSzYZSLxtflmnDGleGeee/b5KwKDFnpooos2+mikk1Z6aaabdrpB+Pj4eWr/qqu2+mqsl5sk
a667ji9nsMMWe2yyyzb7bLTTVnttttt2+22442bba7rrtvtuvPPWe2+++/b7b6DkFnxwwgs3/DbA
kVojccYbV+pwyCOXfHLKK7f8cswzR8lxzjv3/CjNQxd9dNJLN/101FN/63PWW5dMBddjl3122mu3
/Xbcc9d9d+5U9/134H3nfXjiTwz+eOSTV3555pt3/nnoo5d+euqrt/567LPXfnvuu/f+e/DDF398
8ss3/3z0Tfcnffbbd/994NOAP/ni67ffvfnz1x/7+/v3HzuLcQVP/3Pc/tCmrWwRkHMGPBsCEcI5
AOQFABN8TgT1wkCzOfAgVJlg/wcp+BMPAsWDFgwKCYUyQgqiUIQdBOEJ7fHBFoKQhTE84QxX+EEW
qvCFIaxhBGH4whuaUIY8tKAQlzLCIdqQhy7kigmXuMMfIhGKRiTKE6FCxaJgMYhalIoFMVg2DRoE
KVwsIRNj6EQzZrGMQ0GjEH2IRiCKkIZypGMczzhHPBqxiHCEYx2r+BQ32nGNeBTkVZS4Rj66kIRk
7OMVmcLIQRryJ18kWxgLkpQfqtGPLWykD4/SSEIW0pOLLCQQA6lITeoRk5yUIyTZeEYlZrKUpWRk
Dmf4Rk7u0SikbOUrqchLTZaRj7fc4RSNacoi2vGUNCQiFIOYyylScmyWJMgRuf8ISlNG0pO7jGQo
A7nNbKKym+F8JS1XSU5wBhORggTnMsdJxji20Ym6nKUyhenLP4Zyk+Q0ZxTniMte5nGdrSSlPNco
zXoJJoRWlKE6VSlFZnJzi+mc6DaT+dA0sjKfOoToQC86Ril+NKBZJCIS4ZnMkUZUn8DkJyxvydB3
shOfA9UoHSk6RZamU6eiVGBpAriVAX7ymjFFaR21iM1fijObGCXqDe84xnIWtJ77jCdO93hSc0JV
pstk6SDbWE6lTpWpLk0hE1V4ypsW1apbvedBEQo2aiJOqOckZDtLCNN/grWbdk0rT8Na1anus6ij
1KpZAwtJVWr1q16lqj1T6k3/maqzpvykqFoF2lLHZnWylZ3kW3MWV4EUVrSRTeQ486pXzs7ztIlV
6VNZW9d/qtWdNmXrZR97Wpq2FJhYzOlqw2pZ3zZ0kZytrVHz+dTNFjeGnv2sin4aFT0esq2NnecS
mzndYiZxi8+8qy3fWFIbOlW12s2oa2P5S/CeN6nk5apg09vd6uLQuiSNYlmdmdbvWrarl03vcHHI
RgAwF2eg/UdPFwNPyZZ3LAiWaFQEfDMCG/jAsvwkJinsFQY3GCoPtlmEJRyfDCe4KRzGl4c/fGLQ
kVgmJkZxi4Wi4hU7N4EupnFnYVyS4YV4ODq+DI+biGHd9KDG9PXxVHR4RH3C/7fIXXwkNpvSUUlW
MbwWvjBtoTtlrey3h0rJsI6hrNcsD1k1rgzsVpbcWG3KpctOfqRpjXzcMvtxqG9Gc1VCzOAuO4XN
SbazmK/y3KwEVcoN9m+hudtMLKM3h+uEqDsNPUTuHhOgC3WmYB173cziFtEw3PQxYftdMC+V06xU
b6jJW2lkNpS9i/Y0bdW700qb1K5pPvVVH41q64bwxjBh8VzBKtuZyjm7fk1zaQebRmBL1dKjvqtx
lbrT3SI7r6M2qKUV2dWH8vKiyrZtsW1KT1hze6PihraVmU1swN4RqfZcbAt3/RICLxTLw04isP/a
blGaFLsoFXe9he3oYKN7zv8iVTdmG71v5Wo2pbOlbMEXrmB8tzbct81tuW+rX1rO19VN9bYc3+2S
Xu9yvbnsr8Aja+3kpruv7AypfEsOyj2ze61LzWp87Ztcho8V3SknODKtOPJ4nrugIaW4lXGOSGZ/
M6pK3nbJY61vj39cJI6pcsQTju+cI1zlmtXyxbUubEJjluas3S/Wd97PvQac3wmHeNoze1OZS9Ts
MEfuZCX+x9cqXdp+Pg2ZGz5ck9PdjDf/78lp3W6LF1PwrZUzrDMN9rljd5alha3RAZt4hSf+2Dwv
et3b+flLV37viUQ8X6dbZb4zBdBlWb01Sw1pW7N3ry23qH0BP3mznjfSi3b/I6sZH9tTP56/L319
dAF87slL17Wknbencx1tsjY79t1lfu2tT/22Iz3pur/q7ssq9am7x8vLOfPUyl83Mzyn9VYRNGXu
zJzz9yz+BAY/SELu/ifD/2/zl3H9O5J6AAxAxvA/AixAAzxABNweAVxABmxAB3zA4EhACWQgIphA
C7xADMzA8tgGDZyNUOhAiSABEBxBEixBEzxBFEzB7IFAFmxBslBBGIxBGZxBGjwJF7xBHASqGowb
athBH/xBIAxCIWyNaxhCmshBJExCqTBCJmxCJ3xCqVNCKZzCpIBCK7xCLMxC+KFCLuzCwNFCMPQ/
LxxDMixDM3zAMLwxA0hD/zZsQzd8QziMQzmcwyfRwfU7wyahQ+HBQz/jPxe8w6dgCD5UPecJsDi0
wxkbRKR4HkOEQ0R8IEWswkLUQr8AB0u8REwEB6DIRE3cRE40iktMikz0RExECk7sRFIMxaAYxVIk
xVX8xKOAxZ84RUu0B1pExVe8RVV0RV2MxVG0xVrMRaHYxVTUxFacxWAERlysGj+MRK4gRmTsxF1U
xWMURlFMRmpMxqGYRmwMRmjMRm5ExXAERW/sxmWMRqcgxm+sRWg0xXI0Rm1UxmGMR3RURnN0Raxp
RmfUinXERXDEx1ykx218x1csinWsR4SUR3sUR4IsSKJQx4acx3N0R3+Mx/9QbEdyrEiFBMiFHEhp
PMZxzMd9tAdAdApB5Mh2vMh7lEiBlMiEzEiYdMl6hEWVnEiDpMeafMiWjMmXzEmlwMiNTMhftEaa
XMnoacTviYXyEAyIPEefDEpkBMZr/EiblEmddMqVVEl0BMqr9EiofMmptEZe3EmrLMugZEespEqp
3Eiu9Bl9bMCSHLEBakqv/EeXbEu2rEavvMm0xMecfMqwvEtaXEi93MtoHMxeNEyWPMWxXMZ/fEpV
1MPmecQNQkmcRMuhFEa87MeWDEfMNEy7/EzPnMiU/EzF/Elt7Mev5EvWFEvAVMhszMtOlEzVYcrU
vEx4zM2rLEyz5EjffE3/2ZxJVrRIgSxN3TzNwOxJ00xOsxxN4lRLwvTNkTQwuhRM6ATItgRKjFRN
4/RLc1xOsPxK4FxNX6xIxwTP8mxN72RI80TIocTL6bwf1VzPw3RNsoxN6RTKiDzLiPzF6lRMu+xN
ihTLrSTLskTPAK3O0YzPIevO4KzPqHTI1gzQrnTP/YTN21xJ8sRQ9qxQpvjPAq1Kj1TL+SROoszQ
DrWabIjPuCREi9nOzGzK48zPjoxOitRLWTzMGbXHgNzMGC1OAwXQ5yRM3izG6wxRmRxO80xR2lwe
yhQjBn2xJj2dKK1SK71SLM1SLcXBSNhSL/3SF0zEP2s/MO2Nf+iBKQ2//zJdU9dp0d5xUzYljTQd
iTitU8+BU0nsDiUdTKsMSSVFzhE1TkF9Rz5dTB4NyENNRSKtyfbUUapkzED9Tu38UUjd00rNTERt
TMakS13sSwvNzU29Rf5k0jldiSe9JPG8Tw31U9wMTAXNUOUUUeF8TlBlSfJ8z4YczwoNzRLVUOTs
VdIESfQ8UU9Vz3GcVJsEx0Yt1ZAADAeNSQql0PDs0/2M1vOUVQ6V1BrtSGS9R4jcUGqdURCVVgLV
T40M1MaE1lZNTw6dVmRN1Gm100ATU/ZbkWdlzT+lTwEN11TdUQ9V1wXFVV0tSn+NV34NyX7d0HuF
TxvVVUf9167M13fdTf8HZda40IqTvNeIhcdRBUv4PNZW9VFsVVbMZNSSHdYCRVJA9VDI9FWVhdiO
DUuCFNlkNVCtNM2JjdQKtdiPcNZ1hUm0jFmNZdlhJVn1BFipFM2gVVrEZFod7VFM/dR2lU6TFdZi
fVqgZVpIhdCVHcukJdRP7MWoNVh5rVdInNcUGVp0xVRy/dhc/dltpVFi5Vat1c2JBU//DNJZddRr
rcudVNuxxVB5pNmj5cuTpdFuBdLZ5Nn/+wu1NVS2vVBw5VuqVdx9ndt25dWCnVUY3VyK9dYhtU6e
lNvVJFnPVVSYXVurLVwjvdqyBY3H7dG4ndpyTV3ADV121dypHVht9Vv/bA1Pa+1Lrozd0tXW7Bxb
tzVZxO3Mkr3c18UM4uVaHJXc5D1a/IxVV7Xczr1V421Phi3eRyVQcq3ccwXe7q3KUozeRF3d1M3W
5w3Ts2W9tIVbnnRQ9R3e/qTeIB3f8eTdJd1dvQVf1N3beF1YyTXX021bvUVY7q1Z9iRVxsUxjP2O
yP1dBqbbsN3a2oXaxQxWWc1X0fXdUP1fG11UyxVSFIVVim3OwB1VUM3gRiVd7ExhSwXhQ41MgpCF
gxiBCMaIrcAHMn1fn+phjRBiIz5iJE5iJV7i+sHTRQxiJhYNIvaIU62mKE6NKW5ctKXXKx6Ns7AF
J6xiueriIc7ifCFj/zTOHYSdz9a1Wmnt3ELNUQ12XhMW1cItVL493mrcY8W91iVFUc2c43J14xEV
X0rdYKwtxjbO0Qcl2zR24hRTiDXG3V+dWUqG2QQl1Pb9V2WFWM+U4STtXfD1Y33d1pY9Yfv04FXN
3xi2ThKFWzauTjPeCDEOLd2VXU++TagU2QNlZXRFzRge1EE+YOsF2/wU2Go15peNVVqFV0UmYKmd
3HTF3t/0VRwOQx642L5QXs50YERm42IWXped3dG94Ljtzu9F57xV5Qcu2KpdZgQWZwd+zHUd341N
UcvsW3NNY8W4WX8NWk5mXn0u55AdZ4BmTnM+6IRN54Lm2FE+WXdWWv945s+1NFR8fWVPtWffreZW
bmRpRmNINgpB9OeO3d7ltWOClmePRVkUXmlxbWhBXmin9duvjWi7nelU7te/ddpnLcelSF+XldGt
leVZfgifVd5A9uBvvuSWduXtZVih1l6DZulKPk6U5eaixdmbLtb+VdWPHNyfZWSkpWayBlF+zsP4
HdP5RerWDWhvRuR83mg4hmpYneupPt3e9EmxBmCbztasbmdU3lUb/lS6xmdwjmUVLmqjdlyg/k8D
fmsZNmuwPlKPDuey1l9HdmnZPGF6VumnLc0Zdt1w/etMHdDQ7uWBluyzHgxCPm0W1khwzuVG7WTX
ZlfOzeldJma3Jmz/pd7LV23n3DZs+h3tI+VM5qxss/7e1SaKkC6Kk0Tu8zzNVnxNXg5l4e7GeUTo
7/TE7N5sUMZcF7bdrLTmUy7fCIXr8IbmAWbdyW7q2lZIxXaIwGDg2LZrsmZvOQbk2HZvHuXOOU5M
w1Vhrt3gqDZkiL7k/TbwP67ZqSTYwEbsjl5uCZ9w+mhu5oZiCg+P+H7uDO9w8LBwtOZiD9fwDQfx
ET9x3yhxFd9DFG/x6VhxGI9xGZ9xGhcIcrhxHMfxGt9xAZMBHr+JOfhxIR9yIi9yIz9yJE9y1HFx
Jo8OJX/yDGpyKZ9yKm8xeikDKM9yLR+JGNhyL/9yMA9zMR9zMu/Z/yrPjbc8czWfjDQn4zJHD6R8
czmnjTgH8zUfMzELhzu/nTbfcz9PjD7v4jkXjzq38z8njUAX9EGvjUL/8kN/dEiPdEmfdDM0cZG2
9Lii9LuBnPt7skQnybQWOcMosk//9Aqjpx+rM1VXDLgbrTYDdFPvigsjI07vv4NoNASbdf6bsXnj
v67LP2yrsG6zilbnMg2DqmKPMj4DO0cSMToLODUK9rAjizNTNKxa9uPzt1dnrEiem8CQLz2LdVfH
9m3Hil8/rlJnsj5LdmJ3MwVrdjhrd7xDMnJ3tsN4LbrSs016v8GDIMBzudgDeOE6sveiN8UiPkgT
NYB6uutrtcvzOf9Jc3jv4rdMQnhO+6/e6z5JczmS8y/6SnjCujyMDz6NjzVSez3x4niGhz2P3/iS
NyyFj/ifSyHdo76Lb/lNu/mMT/i6uvn7AvnmO7lEU3mW9/nqwPQLT4iLV7zxUrUVYnqoB/dYsjEo
Ra5ZS7WHP724Iy1SM66rfzuxUzaMc7yth7uQFztux/q1E6bNqynTI7ivd7Krtyi3L3vF6vqIinuv
h7y613rT07TkO7Y++nvci6m97/e6r/U7UYilp/nbUzVZi/r8onnnjl/BP/ysp7S67y3Cmnt0SvtR
ii5Wo/iy6qSR0ineIyhht/uQ1/xMI/yFh/1miy3C0/ymIzxlGqr/zgd7vc/7J1o72nv702cs3Xd9
1kc52h98riMoFnobhfp3j6+v7KJ86l94pwekvMd84B9+bvuq3c/+3sr+60erzTe87uf9t+Mt7R+7
4Z827q+q868h9Ocvu+u3WWf/aOv9rYd54vp82QcIewIBCLRHkGDBhAMNKkS4cKHDgwUdPkwYcaJF
jBQrXtyo8CPIkCJHkixp8iTKkv9WsmyZ8qXAljJXAkBYcyDFmzcnHrTZ0+BPnT6BWkQ4k2VGhhAx
Ln1oUynDjhqZUn16celVjlOpQpWo1GtUqGKlNu0atqLYpGZzMiVrduvZsxLdeoxLd6tVuGC5Nmz7
NmzWv2DZfl2r/9fuX8MiB489HNgj4cZlqx4+avky5syaN3Pu7PkozNCha5LmCXTn6Z+pg7LGuRM1
UZOl3Z7WWjg1zq+v+V4dKjUw0d+wXTt1Ojtt6dpvXx/vOFyt8sgRj/OE7XP609y9kxPPjTt28uzX
bQutS1m3YeA62w4X3x33b/btdzfkbp+57uxjSet3vTE8SOsZZ55oBRp4IIIfYZbgSJkx+KBIl0E4
IYUVWnghhhkGqCGHHXrI14chhvYZiSWaeCKKnWXooIgjWtYijDHKOGOF3NF4I47K5bijPSn6+COQ
QYKGoZBFGnkkkkkquSSTTQo5jJNRSjkllVVaeSWW/6yYJZddev/5JZhhijkmmWWaeWaVW6K5Jptt
uvkmnHHKOSednqn5Io956rknn336+SeggR5YJ5WCGnooookquiijjTr6qGgLEimpo8+FSCCglqYF
6aY5anohpin9F1KoJ2laKqcxEkTol3eCxp+BjCVYqnk5oXYfqqTW9+l5KNmIXaiQgbiYjTDJSmGu
E9Kqa3XNQrergCXBumFGwh5oLXIZJpupbD2yGuWe20qL7Lgf3erYsN2my6yx7PVKrVq5ikvSvO2K
uKy5WR3La2IjAYdWpwGLau66FtbLJ6oHpwopZLdGO1dUAuK6a7PFhvecvn09e7HD1uWLXW3jfQdv
xkWJTNy0OgL/rCN1gEXs1cQmk1ceyCNPWyzL5VGssm3ZxsVuyhY7BuB4Qe/2H3O29kTfr/n55+xc
Ht8WM9RJgxez0SJzXJ3CC6dEqYUOAjiZc2UxFqxk8QZccmzebXiXzIppBbfGHAk9Wc/Hdkdb2YjR
dh7MaleL7spkE4x3r9MV5y9ljxHusnRrjYp4xnuZJvfZ/S0+al2Ru3fX34eZ7e23Tf65dLSYSz5b
5y1vGjpaKQOM9MP9agSr56Jv/G7olcteLe5qg457w/ZxtV3tzlnsOraWHy80f5j6/uvYfkfcePB1
O19521Vlb/3KEF+nGnRk5QXR9+TDx7XeCo3jNfxv16067FL//9z82vDOLrzufU0+d/9exzu4JE5g
BEzb2Q7otk45bnSgA1raGseu3RVMMPnjH1ZM8zf84c9skcMgYvznMruVDy8O1J4GA/iv+LFQfoY7
4eiOR0AOTnBxIQRgDAnGt8dFRnAIFCAO87dDGN7wh3IBYQJzKDcg/uxZtzEiCpX4vwSy5YEo7OD9
fJjEIgJOhl48IviKuEW6tbCMT3sPx2QlMatBa2+0K9x94saz9Q1IaTWLDszos5+tjQxqAVLjfDpW
tdoFx43FmxkgCXkzjPExkHB0mBx7psX3hI91R4uOfB6pOe1M5W6GrJmtoggfRmqtOFmbW8eGkjN+
mdFFeLoQi/9aKctZzqhrtKyUoGxZoNI56Za+/KUvcQbMVurSQ8UcpofAViFeMrOZznwmNKMpzWki
BZnWvCY2s6nNbdJSmRSiJjjDKc5xkrOc5vyRq2bCzXWys50FOSc84/kZd9Kznva8Jz7zqRIJTeoy
x5xVgWrlq0axknEcEqgORVPQ+ZnKmAidkTwjKlESpVMm/0RQ59QlSYEdDF8BLZcBDxfSBz10cPZq
F7ZMupgK0kuk/zMYSCYq05nyE5aYuei19LfSd7V0NCBV6E8HVrga1RBxGn1JSRkq0pyKskN1oSlU
xSQDcOnpZrxJ2hS/k0fxsBFXStOqXKgnSMAQEmWbw6pZY7f/HuRR7JTL6apX24jJUp4Mj+fjmtOa
8zL9LM1pfTSkzKyqsq2eca5z1CdiEztQJao0d+gLYg71xj09fvB2eRPcXcf4Rc0W0IoJlSK6OLdJ
C7ank/HKLP361zsJti6ImRsqN4ugWBZ6c0KZ6c3rWuZYu2Qvfemb5L4wq1uVAjBqw61iFLdqP8+q
77cNtN74uoLF7XWSbZplLgg72z27HTeAMYkqeMcZLr9k9bmc5WFTJztAIiKXfxDLruVwO1rS6i55
qg3tErvHvSum0LWpBS3lJLhA9aB3tgY+sEFtR0bsZjCyiVGvJBkMog96NnwFjJ2AxfjfH8Zntdrl
b303fN78/9J3s+h9LoJTrFjZta6sT+Mb0y6GxuWlx2R2xGsoH5k3yrptupHk5IBwnMq3BpKuL3bW
80YbvDgqD1hArt4bGUjF0g4SlEWBrYqzfKPaQiiWTgwmULWlZXbaMrxmvpItvFRRlywVmB3VEE7H
/Kgyn7nO0JQznvOs5z3z+Z01DZudAy3oQRO60FlS1UL7rOhFM7rRLfydoyMt6UlTustM4o+hM63p
TXO603bCUKIrLepRk7rUpPM0qlOt6lWzutWufjWsYy3rWdO61ra+Na5zretd87rXvv41sIMt7DSZ
utjGPjayHzTsZTO72c5+ZbKjLe1pU7va1r42tiX97G1zu2fbu842uMN9oSWIu9zmPje6063udbO7
3fr0NrzjLe9Vu7ve9r43o+at7zcxYN/+thK+gbmCgBO84AY/OMIRLsyEM7zhDv/avyMu8YnHsxgU
vzjGM166h3O84x7/OMhDLvKRk7zkBg8IADs=

------=_NextPart_000_0005_01C70C0D.A96DC500--



Received: from 42.80-202-189.nextgentel.com (42.80-202-189.nextgentel.com [80.202.189.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAJG2HGa024813 for <[e-mail]>; Sun, 19 Nov 2006 09:02:18 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c70bf4$25e55220$2abdca50@nicklasfe3e0e3>
From: "stiffer underlying" <[e-mail]>
To: [e-mail]
Subject: Saturday Humanskin books
Date: 	Sun, 19 Nov 2006 17:02:43 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C70BFC.87A9BA20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0003_01C70BFC.87A9BA20
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70BFC.87A9BA20"


------=_NextPart_001_0004_01C70BFC.87A9BA20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Who gave a it by of. Rocky is Parenting Front or Page gtphotos of Email =
to. Photo or in the News a Book Bound Human am Skin am Site.
Itbut of what possessed anyone do beyond.
Real thing skinthe yearold ledger a was found.
Use xml rss Sign Inside am National Geographic.
Photo in the News Book Bound Human.
Ledger was in found of downtown a Leeds England of map burglar or.
Leeds England map burglar of apparently dropped in tome a. See am More =
top in get our Free Newsletter Popular or.
Map burglar a apparently dropped tome?
Thats because merely veneer stiffer underlying. Video Adelie Penguins =
Rocky Parenting.
Accepting such is blind faith for most.
We dont of make.
All heard leathery but this macabre object is real. Accepting such is =
blind faith for most.
Worlds or Rarest big. Rare they in appear have been not quite. =
Surprising that says. Because merely am veneer stiffer is underlying =
isnt like shoe thick. Humanskin books are rare.
Well am send you sample af.
This macabre or object is real thing a skinthe yearold ledger.
Old am time of he said Ironically.
Rocky is Parenting Front or Page gtphotos of Email to. Objects slices =
history we in dont make.
That says Anthony Bliss curator.
Xml rss Sign Inside National Geographic two!
That says Anthony Bliss curator.
Existed Scientists say Feeds a delivered.
------=_NextPart_001_0004_01C70BFC.87A9BA20
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"us" hspace=3D0=20
src=3D"cid:000201c70bf4$25e55220$2abdca50@nicklasfe3e0e3" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Who gave a it by of. Rocky is Parenting =
Front or=20
Page gtphotos of Email to. Photo or in the News a Book Bound Human am =
Skin am=20
Site.<BR>Itbut of what possessed anyone do beyond.<BR>Real thing skinthe =
yearold=20
ledger a was found.<BR>Use xml rss Sign Inside am National =
Geographic.<BR>Photo=20
in the News Book Bound Human.<BR>Ledger was in found of downtown a Leeds =
England=20
of map burglar or.<BR>Leeds England map burglar of apparently dropped in =
tome a.=20
See am More top in get our Free Newsletter Popular or.<BR>Map burglar a=20
apparently dropped tome?<BR>Thats because merely veneer stiffer =
underlying.=20
Video Adelie Penguins Rocky Parenting.<BR>Accepting such is blind faith =
for=20
most.<BR>We dont of make.<BR>All heard leathery but this macabre object =
is real.=20
Accepting such is blind faith for most.<BR>Worlds or Rarest big. Rare =
they in=20
appear have been not quite. Surprising that says. Because merely am =
veneer=20
stiffer is underlying isnt like shoe thick. Humanskin books are =
rare.<BR>Well am=20
send you sample af.<BR>This macabre or object is real thing a skinthe =
yearold=20
ledger.<BR>Old am time of he said Ironically.<BR>Rocky is Parenting =
Front or=20
Page gtphotos of Email to. Objects slices history we in dont =
make.<BR>That says=20
Anthony Bliss curator.<BR>Xml rss Sign Inside National Geographic =
two!<BR>That=20
says Anthony Bliss curator.<BR>Existed Scientists say Feeds a=20
delivered.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70BFC.87A9BA20--

------=_NextPart_000_0003_01C70BFC.87A9BA20
Content-Type: image/gif;
	name="during.gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c70bf4$25e55220$2abdca50@nicklasfe3e0e3>

R0lGODlhOAIwAof/AAAKC4UAAAB2AHpzAAAMc4EAdAB/gMTEx8jTvqK+8k4XAmkeAXstAJIdALYs
ANIZAABJACBCDTlNDlJBDH86AKU8DMJOCO5ECwxjAB5nAExYAlNhBo5XAKNoAMRlAuRqAACOACF6
ADR8AFGJB317B5qMALN0AeR+BgChCyaWDD6qAGShAHOSDpyoDbOfAOObAwC0Ciy7ADG6BGy5B43B
AKzJAL3JBNnHAwHbAC7VAEvjDmDRBIjuAJ3lB8zZANXmAAAAThEJPzMKOGMAPYQHO5kDSLkAROEJ
MQAtRyMdPUUcSmIrPocrS6woQbQlNuIZMwBNSRdOQDo4O2RGSIE4Qpk7PLlNTtk3QgBYQh9RPjJT
SG5VPXZZCpVdQcZiQORcSAyDRid5NzyHNFp/N3h3RaiFRLp4Mu12SQWhQiOVSEWeNFiXOoqpSpeU
RLyVSOmsNgDHSyDCNTK7QlKzN43MSpmyOLe7NOi8SwDiShfcPDXrQ2vmO3bZSqriS7HfPeDrSwAA
hCoMgkkChGoAdoMAgq0AgLkAg9kAfwAVchomdEEae10scnwXepcpgrchjOERjQAzex1LiEE9dl5J
eo0+eZZKi8o/jtw0hwBXjSJfcjFujmpadnxRgahVhs1rcdtYggB4hSx+fkhydGWJeXx8iaWOjsuC
ieyGiAyZcRejijmVhW2Wfo6bcZKaebOgf9ubdgDCeRK3jkPDfGrAeHqyjJHBd8C6ceXGhwDlcinh
jDrTd2LVeYzdcp/dgszlgNjeigAAuxUAxTEAs2sLwHMAsqQAycMAxNEOwwAtwy0dy0kos2wox4sZ
uJUYvcYmv9ojvgAyuRM9uUE4w2sxu3E+xKFHu7s6udFMyAZTxRltyEdnvmxVvYJZtaZRxL1pt+Vc
uwB6shR4sUh0wFWIy39yzpiNzMWMx+h7tgKstBSmvjKru2Cay4mUxpWkt7KqzeidtQm/yiXOtE6y
xmm7yY7FvZzJwfL67qessHl6ffsACQ32Bf//DAMA//8J/wD2/f///yH5BADly0kALAAAAAA4AjAC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEMe/EeypMmTKFOqXMmypcuX
9l7KnEmzps2bOHPq3Mmzp8+fQIMKHUrUp8ijSJMqXcq0qdOnUKNKnRqzqNWrWLPKhKa1q9evYHnC
Cku2LE6qaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAPDNUu4sOHDiBPjdKG4sWOwgiNLnky5
cuBgljNr3sy5s2eEj0OLHk26tOnTqIEqTM26tWvCn2NPfk27tu2hsnPfvc27t+/fwIMjDhCANHGa
x0cnl7k8dHOXzx1HF069esvk2Ilr3769JPfn36f//+tuMjtJ8ebHh//unX358CrJtz9fXH38+tnX
y4f/3j1K+fQFaF9K6enHXXsH9pfgf9qdVGB91kXo22oGVojfegouqKCD+t1nIYbq8UefiBtmqKGJ
HzYYon8rnjgihC+yiGKKF5LYIYPg6afbjn0hqGJ/OEK433IAvkigi0FG96OPTI7YZIkcFnmklEsa
aWWIT2bpo3gm4hjkkz9SWWWM9fFo5lszoadkjkI2V6WM86UJI5BR1ukkglGOKSBzc+Jpp59YAkrm
fcj1eSedgC75JpIDSqhSFY62ttqgfx5Kp6Jsjglnkn0uaqiKmM4J56Z5rinqdKC6mampepbaKZtT
Wv/qqaYJnmlrXS1q6Gmsga7o6oxqgmhpr5cSOauqwroK4K5e9lokiwZ6aCOszYZ5LIwG3qotVddd
uCex4N55o5/WCqimudhSa+e44hqLLqEDIlspuckGWm68huL7LbPr1ptqm+9GKnCEwc7bLpL/Hlmo
hwbbu2nCDC7Mq6D0IpyfwnIyjGixFteI8cAghzysngmLSepP/HLsq7L5oqyuyiYz6vKpn14cs5Qi
r/RCzqFN+lLKFY/MrlBAHyx0vUEV7bDHwLbck9IQX4vzSdtWDdXTpv5pbbpcW0UrzYnKS3HSWSO6
9cat+vS11sZ2PTbPcJvmM3Ssgik2sWlj/Wrbbbr/jTeXen95ZaiC5s3T1333bfbdK1nteFpy1jwt
18Uta7hOJCcbauWbF5X55BtaDvhOn0OLLOent/T46kgFPuWzq5Y9VKskglt7uDNLC/Ttl+dEu4xS
Nxv38KXNTfzxyLvE+vIgJe/889BHr5jx0lcPN/PYc2T99tx37/334Icv/viqS4ZK9uinv9AO6n9E
/vvwxw9y+woBAAD9+OfPo/z2y+///wCsDQACSMACGtAx/TugAhfIQK0MsIEQjGBY8Gc//VnwgjsC
XwIlyMEOYkV998OgCEfoGQ+a8IQoTKEKV5iTOXyPhDCMoQzzwsKuMKCGOMyhDnfIQ7PM8IdADKIQ
/4dIxCJupodITOLzjMjEJjpRIiw8Aw4pocQqEu8MWJSiFbeYPCdm8QxPDKMYBQLBL3LxjGj0DRbT
yMY2uvGNcCTJGOdIRyPGcXxruCMcp6DHPp6xjoAMpCAHSchCGvKQiEwkW6y3EJNQz49xUyQZq9fI
kjwSkjwTJCY3yclO9lAAAggfKHk4KfuZUjSnJMkGiVJJOSYElLCEZUliGUqS0LKWJhmlSm45Sl7O
Mpa2xOU/eqnLYeKSlr9MCTJzCUxjEnOZt2RJMZfpTGpSk5myDGY2lelLbU7zmsFsiTWbGU5XKvIf
G1ylYlKJzgcWpZX/8Fkxy2lMes6znuIU5j3tGf/KeT4zmfjE5z6/CVCB1nKg+hQmMwt6z4YeU6EG
Lec+T+JQgBJ0oSu5qC79WUtNrkSdJTFlOkXazgeKdKSpPKlJV4oSkrZTlS4taf/YeVKTgJQnHKVo
Px+KTYjqFKNADeozD7rTn1Z0oRON6E9fslGF5rSgGSWqRBO6VHqG86Le3KVTixrQrirxpiOF6QBP
OdMEgrSsLDWrO0Oa0rXCVKwlfWlY3xqUpyYTq9XMZ1CtCtWhXnWrXq1oUpuKkqRW9ahWNaxFpdpV
xAaWq43dZlX/ylfFerB+bqXrSzer1s16lq2eVStYx0ralrKUs6XVrCPnJk+qIvWahI1qT2U5UV7/
FpWYj83ta7XqzWxGk5tQjexeudnM38o2uEN9am0Ba9xwelQlowUtat86V5WGdqXRlalY20pXtMaU
KHal7FEVG16+JparwBQsYHebV6VK06d4FW5wgUtZ8wqVuZCdKn3vytP59jC7051uWAfsTtFmFrVl
lW5n5XrgopQXt5El5369SmHhNhXC/J1sPZXL2Pfu17Hl/TBkyevaDEdYssgdcYmrSGAFnzbB1MXu
daVrWramlrsCLrCOhYLY2Lq3wucVsYUf2mEfM7S/SkXocOWr2yMXlqdYdWxAfWxkKvcXr5bVYU23
u+Mcx9S6c/2sTXWMXRwveMuq9QlCt5nTEPfV/7jQpOo3iTxnNku4mn7tZnMnC04K9xnPRJWwlPH8
Zvly1M6C9qknaZyTmy66K1muXqQbowX+NXgmjn40pBW9vUlz8JKNvrRMMj1B1h5EAVXRoaeRN8/n
avrVsIZJQhoDz8SAWjWSzPVfYs3rgYEDhaQ+SbB7TWz/rca6OBk2oy15ax8mJB/Qjja0SyLtfFC7
2iiZNrN1zW29sGSVyk5JuMVcHW1f+9z/MLe5SbLuYmOFHG90x5jF/WKStvXL+F72b9bd7mmr29rX
bre7B061hGRXtHFFa4xdLN1aI8Zn/Ab4uf9tEmlvu9sYX4owLNISZGu3u2ndcXVFvW+Jp9vkJ/8/
ucXRLXCCuxzTZWY4g0E78khF/CT+tna/Ad7yl/v82zEH+cKHHmAJ3bziOue5yauN8pOo4Oevxuy8
VXvm1M5c6HR1+GEgjnKKp5zdSkd6PDNO9rl0HM2frbpMURrmcbdG4NgGu9iPDnV3N9vtPdG6YZpt
lLL7HU03wXvdB3/AWwueJ3ovDN/z/vfGr4XwkI+85CdP+cpb/vIn4Qc/wKJ56XX+MJ9XSegx7/Ea
k2/0/9C86kWv+s1n3vWsR8noO9961Juk9kLBPUl0v/vQ2773td/8738ve9j7HvYysf3xMa/Zw28v
+Kk3PvJ7X5LZEz/6KbE+9qlf/OpPfyfLXz7/9mn//e57Xyfi3/5MlI/860OewGZ2Kdqd/5vW3176
5le//WOf//Hj//UA+HkCuH+8F3viR37qtxLWt3/bx4D3B3yuN4CrB4ERWIHcd4FQJ3UxtlYwRmNh
9hrwpBAOmH7nx30ImH3ll4AnmIAY6H/UF37ud34HKHwT2BILaII02IINOIEr2IM5SILY53gdAXTy
51Yd2HwkJzI1qH/fB4M6+IQqSIMOWIIlSID4F4M4SIW4t4T9N4Ms2H32N4AyeIVLiHpYCHVnZYRW
x2X0Zx1WSIX3F4bQ138POIY2OH0SWIFbmILe939fKIcK2H7/l4esR4jRt4eICIB1aHlpKGxr/0hu
xzMP8/CCOQiFcPiFUKh9MWiGemiBish/WoiHP8iH2peFixiHnaiD7LeJfGh3BpdZ6nSEM5ZmkmJq
kniL8zBJCOiFn3iJvliFnsgSJJh+K0iHTBiAlYiCiyiGYlh8huiElHiMDyiE2vNRsKiGXJaN+kYd
kliINch7xzd8pDiOQOiNooiKweiMVsiF4SiMggiMEBiIpwiOb7iDp/hzixdJpgYamFgUZ3hGn0eN
SbE9IZgQwXeQCJmQCrmQDNmQDvmQEBmREjmRFFmRCSmQrcNI+zgSZfGPSjR6GHkUIpN4jROSJmkm
I5mPqxVEuXCSMcR8MOlHbcgaSRiTNhl4pf8HXTWpkzn5EzOpStB1k0JpE3j3kz95djwxfztpE6k2
lD6nbMi2ZQtGb454bwZ2ldpYlOjUUlvplF45dgjRk0hYY1NpelRJUyLXZeD2QPA0VsIGlGAZEjrg
knS5SPNWUx8IcqSWaUfYYliHErUGbiFlTo5XAHU5GVVAEDBHlXpplUBXlWTFgWkplUtJhGz4lU5p
PADWgQb2mB64hn7piCrhcCb1lnF5mKhZGXmplwi2jVPHmmsJVzXXcNRTmjZFmKmZm5GxdtZYhPnm
mTYWmZCJlTaWdXODdnCpm8pJQ19xlEiJFZWJmcynkjThnM/JlLVZPsu5nT0iFNZpWuyEnbP/VhPc
WZ5xIZ3oaWzjSZDUuXXm6ZLpGZ/AMQMH9J2hYZtBKZ9chJxWMVqSuZThZpSmGWrBZpsHFp36uUDH
1mXQeaBrCaA7qWwLYYQ7UWDfBpf5uZLvqZubSVqRaZVlRpzBuV1ZaW/1BqK0eJoGQaEfV1oWeptw
yYExGqNmFVcquqGH2aE2uqPw95dj1pmiiZZFV5Y31UgvKqPpNJgw2pUyyqRAaaFJiqMmCZyv2ZeS
SXNq6aDa1YgPyqBl2WhKiqRveY0pBaMG2pVKiqEJSh0wIBoaKJpEl3ZglqVnKZxrB5pdimPayY9u
eZkUCou32aRnaqMyKqUhSaWfKaevmaiQ/6h2oflxjYqgQfmiS/qkXDmYgjqjgVqpa/pps+aXdkp1
aSlzcNpZCBebU0mkB9ZKTWqpA1qpfcpZMwqlt2moGOkSaDani8qbs7ijtHiVeNqY/5miowaZanqs
2phwmipjaNqsnSpB7ZlJ0cqpWqERGWCrdcRDkvqsaTStKbmeREkW2EqN3LpCdEBs3go9JCk348pt
/7OuxdOugxQp9lmuQ4lZ39Uae8mgjDdrH/CvAFsS/5oVADuw5CmvHpGYMrSaqLGv76QQBksSBhux
VjGxH3CwCAtIwMl2ZCaieMmxPOqbaCmyIYpgwLqrL0GxAluwLCuxBeuyLwuzAXsSFuuyK//7DzVr
rwQ0m1fHqB/amsLZoz3biDMmtAzbEip7szgbsUx7sTM7sE2LEjkbtTmrswDkcY86i2oXYJxpdV1r
eqH5tTvBshdrs0trElRbtmcbtTTbsmdrtjFrtVeLpx8Lp1xbb0KnUl67t5dZtKNKrDkxtWr7tmur
tlBruINrtoWrtHErt/6Tqtdot1s7uY/ot1hKql97tIFbtlVLuId7s2yLtojruZw7s477uHQap1qL
t3druUNnp3qauV6KoBQruKILuqNrsYlLum9rukl7ukLBFfR6pbzKq7nKupQbuyG6vMVJnG0nqWQr
uqYrs6XLuG4rvb57vb8LvJQErvADr0H/sb00EbEZK0nvmq44Ib4yQbHle07q6b1Ecb2bq6HtK0bc
e7849AX4u780Ub/++78AHMACPMAEXMAG7Hf8m8AKvMA5dMAOXEQMHMEg+MAUXMEWfMEY/L/xIIQS
3MEe/MEgHMKalsEkbEEifMLTU8IqvMIs3MIu/MLbgsIyvHcwXMMErA42nMM6vMM8vBbY0MNAHMRC
PMREXMRGfMRInMRKDESgsMRODJ8zvBOSEMVUXMVWfMVYnMUKpBDa0MVerA0l8cVhLMYnAcYp8cVm
/A9oDMZpTBJrbBJtrMZk/MZy7MUoQcZ13MVjjMdqDMd+bMd6HMZ7HMdy/Mdo3MeCnMiH/wyYT5w+
ifzIiNzGcUzIbuzHiGzJkFzGmFzJhDzJmlzJlxzJKyHJj2zGgQzKpAzHpNzJm8zGn0y/jbw8kMzK
qczJZ2zJrLzJf5zJoKzLd6zIuKwSrozKwZzGwzzKl3zMpZzMofzJsVw1L1HLgizNyjzLvZzJlNzH
xnzLryzMwPzNv7zNnqzN09wSx1zNzCzOyKwVl6DFpyHNnMzH21zGePzGk7zI85zHpozPfOzGc1zP
+KzIuWzKtswSBK3NAU3OydzP7jwwPgPPCj3OzSzKvCzRmJzN6PzLrUzR17zMCg3OrmzMp9zLIX3L
6szNsPzMj2PNmpzP+qzRzNzNE/3SJv/tEhZ9zrxM0wdNzLZs0ek80ziN0Yys0rLc0al81DKN1EkN
0wVdzku90UqtyzjN0/58zTed0UFt1IlM1MxT0Xas1T7tyfYsxvb8yfz8z1+tyl8t1ocs1oaszKe8
yLPMxnJ91WmNyFxtKw291/16EGv814Ad2II92IRd2IZ92Iid2Iq92Iy9xnnNOoTXbR6Ao3xd2ZZ9
2dX62IqUCZrd2QvQ2aBdwpg92rIW2qZ92qid2qptERXEnJXHA6SNq+E5Ghn3Cau9FyIlF7G9pvm6
277d22Vx20Pc2lPh28Z93MjtG6SQ3JUn3M49Ecy928893Q8R3dYNN2Bw3dq93dzNRXb/0NDUHd7i
/UNWMN50FAfmnd66wQDq3d4U3N2V7d5PvAYbAd/2fd/4nd9eib76LSGEVHfb6pP1Sq+Dx996O6LJ
mqbD6V1sd6ygieDOSqI/KmNR2duhiqYWLpXI+hKUiW9gRRT/GeITHnRnN5MAWuL1ypa61nHFCqtq
yqIfRa3NGqtPmqlheqkYauOASq2npakOfqE18afixuPemaQ3fuSYquBDruRBjmkszuQVipvZGmq4
SuStupWiduUbLuS0Oqav6qqXuuNAHqs0vuSmSeKzHeERTnImWqNu3uM4LqZeHudAvqlhWqbe1aKy
SqkvjuAe6ucMNuAptJdW7uJZTuQ4/26pXW7nTF7mSA7lZ47hai7jpSnnznqgiZ6fSEq8NWrmlp7k
dB7jc46sDz7jaSfpLm7qSbrpMp5Eba6lZr7mxYvqsQ5m9IaXs8qVMA7qYd7hH+6kWI7inU7jjj7i
flrlqj6gfL6kn06jKCrqjC7rLNrslQ6eRg7mwc7rG75C+UjojQ7saXppWq7mQq7ouv7l2U6o247o
tMrmS+6h91blYi7q1B7uGdrs5G7qGartJTvtuG6msj7j/47tZa7iuSbbyE7qtD7rrzrvSk7m6a7t
0h7pk87uSe7uYV7xGh/x6/7oBW/vnh7tW67vsU7wyQ7wX17tyv7t/H7pUo5IT57wff+u77ue6g3v
8pyO8jav45m+4zn/8O9+8i4v8jOv8xxPqQ3G5/gJ7iaf70g+UzRH8di+8Aq+9MQu9Mm54j1Bpsv+
8bV+vJ3O7x0bnGNv7B/67D8q8BAO5QY6srd+shKu7GXK7I0ushNu7MWb9OFJVrK55vD+4yNvpmgv
f6b139y9rYceFgG+8f3t6m6XhGnen1He+MC7+IzPRfxN+Vscw5rf+Z7/lZlfQJaPPKNPG6WflEUx
QNAM4pHfn/w55rLd+qm/mJA+asA9+dZenbLv40S5+6jf8b4K7TLP4bdf+7+fFXkUrwdBDTF/714x
+pDf6iBO+8Df/KfP9tJ/88IfeNn/j/sc3uLfX53Zf/1ciRRZEBgI7/xx7+FB9+fozpuZmqvaD6kj
W/Y3xvd7f+7Ojp9dz+x4DhAAAPwjKFBgwX8HDQ4kmLBhw4ERDz50SDFiwokVLxqEyNEixY4ZPTqc
KNLjQo0jISIcufDiSowMXWKsWBMhzJgMU5rkGVLnTHtBhQ4lWtToUaRJlS5lmpQgL5BRpWZ8+PPm
1ZU6sUrEiXWrTZk3rVYlC7bmS68kx3bEqZVlVrJr3WoNm9UqXZpd03L16lYtzLAizZb9CFeszMBl
70o9bPit47qC+yqmjPfjYsc2GW/m3NnzZ9Chp3JECZJqzrp7NeO17FNhXMpnNaPu/4r262XCt6eK
Hbxx9syvrGHnVt26eGzbyQsvJ2m6be/Mzs0Kj64Rt8XS0I0/rj1Y9Hfw4cVTdOr5dHDgM+cOn8xc
uXXugKumL0mfNPHtyzemb+43NWrlqNPrN++Ok685u7JLqzfJZHMpNdukExDBw8Zaz7+t+HuwoNJO
Uo+spkIUcUQSS1yqs/O6wzC6CddzDzoHpZONsQinw484/SiErUa5ZNQxwhXZW805yxKrDscC4YtR
xhpji++9Ay9kckAddYvvKxOz1HJLLu3hzK8XBXwtNyhV4/CsyJAskr0A2dqutSBpgpPKNTNrU00n
CTyQtx+TtBGyqzDjs8rCxERrTP/44uxOOzYP/ZOmLiOVdMvxvszu0jE7PAk/+3ZSsqSoXMT0p5Ze
m+u+59xDjKq1bsyJw1JBxc60ltSsNUoGU3wVVlJ7rJCulxSMKVdPV51P0fYu5TUkT5eFdbZKo5V2
WmqrtRbJzcC8dltuzev2W3DDFZfGccs191x00w01NG3VdVe0dt+Vd95u46X3Xnz/KS/fae1ljl+A
qQx4YIJ3K1jfSRNWeGGGG3b4YYgjDrEEiSu2+GKMM9bY4oM79tjjEj4WeWSSSwZpY5RTVnlloyhm
+WWYY5Z5ZpprtvlmLV3GeWeee/b5RJODFrrckIc2+mikk1Z66YGLZvppqKOWemr/qkFyumqssxb5
Z667Xllnr8MWe+yKtTb7bLQ/QyVttkMj+22ksoF7brrrtrvhtvPWe2++2777b8ADF3zwu/s2/HDE
E2c7C8Ubd/xxyCOXfHLKKw+XcMwzP0ogzTv3HG/LQzfXX9FLN/10tHVFfXXWW3+adNdNxoHtz2vv
HADbc9edqdh7j1Z13/eGPXjiTR6++KmFJXh35pt3/nmkDIJ+euqrtz5l6b1GfnvuDVe+e/DDF/87
4IuPxdphxk/7EvXbd/99+C2/fn7667d/0vjz139//vv3P/T7BVCAAySgUCgSgv8lUIELZGADHXiw
fT1wbwWkYOEkyLcKZvBnmwFH/wc9+MGHfBAcIRRhVDzIGRA2pIQcXKEKU+jCDhIkhhSZoQxbKJUb
ivCEOqwhCXk4wh7a8B8/ZOEJhzhCGiLRhkpcIhKDeEQhXjB/EXyiEY/oRCVW8Ykg6WENt3hFEi4R
hmEUIxmtCEUTenGGW/wiY4KoRTR2xooxhOMYk2hHF0ZRg3vc2WfqmMc4vhGITEwjIOVISDIaMpBn
XCMi3UjIRhYyNILk4iD96Mg/0hGSWWQkFh+yNimqj4qbLKQa79jGKMaRhY+U5CJdico7VlKVivQM
JU/pSFm20pCajCUUTYlGPgaza4lMZRh/mUdYdhGXxOxlIk35zGXm8pY6vOINdf9ZTWoSUZpJ1KYv
SSnEX85QmOPsGTPZaMlZehOFm2yjGneISU4CMpLuPGcp4SkaWxozmrTkJzR7GUk0ipOczksD4cx5
T2u6kpXX7Cc6/xlPcDqUn+lU5zZr+U19XhSHiASoKo/JS2AOVKQou2QzkelJH76QoROFYz1TqUyQ
MrOYJ13pKmUaU5taNKDU3CUTUwjLUHJvlBbtqDInelSKzrKjxTxmNWf6RVu6FDT5pKlGdVpUn0K0
iScbaVdhdlN3MhWlSP3oMjtZRjD2lJtoTeocl4rUjZq0ooeMZ0sx2tS0CnSPnfBqzWTaxKzeUq5b
BSxdz4hNbo5VkTx95Fl1uk7/uWqSsWk0ol1j+VOOorSvm41YUD1rtipwRhyfJW1pTXta1KZWtatl
bfv60FrYxla2s6Vt3yJY29hy1mfrbGQ3iWlUp6YTqJMtbGKx6NuUslWMhwUjETOJWeIClpMqhSFM
VwhdHlYXl3bNJil/KFWPDrK73XXmPt/VAAaCt5UvLOtjH4pHt9ISqIu0bnC3es5v+vOQ8tRqWvNq
1nu+t5Le3W5/ZypN9kqUpf2dL265epQDJ9WMlQ3sgYdb4ajuc770TK5KQYjfwKo3rlUN72UBfM0N
nxWqBpYwfwEq4p3GUrdvi/CFCQtc4ZrXqPVMpnlf6UlezlPBESXxX7cZU7wS/3nEJk3xj1kJYxO/
OMCClfGMx1ZjHR9XsUm2cZH5m9OcgjTI6BwzecOZ2eiWuL2y7KaIbQzNyTI3wlFGqXOzS109Wlls
WN6vkMvr3j9TlMOADjRmd+rnXGI1yeutc4WpvFIQLxTRGy1wn4Gs2AW7VM97FrSPsStgI6d00X+E
q1qDK2YKd9rLMTYsPTGa0SWHuq11HbIPY91YLS/Ynrnc9M32S+jqEtbUsubzY6m6UIXOVb/NxPNc
wfxlXbdzyrcWK04fTewbx9fYmG6wgyc5bVwL+6WZ/TVRK43tZF8b1syWs7Wpne4MI5vY4P3wuXN8
0d6yWNVz9jZoygPlteJx3P/AnvV0Bz5YBFd6xfse45mtym74vvWv+Vy4rSt+b7rautgQz3OvacZb
cj9cqRQuYXYJbc2EtjjbcV24nROd4DSr17qOTuxVm21h8Zb81SpfbFbHq3MT91voQyf6tG5bdNN6
fJhIT63Sa5YDCDO96U6PmdStfnWsZ121R9f6BZsSAaqrDMfh9bnJi0tq7ebQwymXc9rr3exOqj3N
2gUrZQcs6rqbXeM4Z+jMDxru5Eq33i8HZNi/iuwE7z2yyy61Fg2ebuXKG/L+JTu/A/7fnYsbunY8
LE47T9UV5zesIx+xw5kc8kV3nSBjcPGWa412vj+b9JB3N4oNjGTRl3TCYw//du8zvONXW1vivY8i
xfW9a/lmHqtM74VUnJJvsTJ8zrA/PfJJ3+RAk9iy5c7oqMlsSR471N2MZ7X1a798jfL+2OXXq+FV
BtlThxjcode77c1PYJHTXvzkRi6fcY/8Mds18nOymnsyWpOk1GMzmhs5bUpA1asqz3u9zIs9yQs/
vsM+aFu37YM/Khs+6HM2CLy0hJM+BBTBEWywpTq2OnJApPs3knM0tLu4xptAyXou7kMsAdtA2VM2
CVw5CySyFWSxHqMpqaq9EUy+xTs492MZw9K86Fo/Cry1HxSklKs+BjQ0dXu3CCzCA1TADkO9J9Sw
smM4I/ytBVw/9HvAIsq1/2FrqL4TQ3M7ODmsQAaDqHjLvxRst3O7w/u6KyGEQ9/bubb7OySsO/dJ
gZJxQZ8rxIbqwnlDM87DsAkkxOLDv0i8pMejwprqrUu0uEWcvRkMOLdiJw6csDgMuo5bwo+LPkac
Pix8REpTPwUbwr+jJL3rP7xzQ/fyOze8RUEERDPUQzFsIbhTvrFqP1WUGTUMpWRMmWV8RtLiOmhM
oGYkqWm8RmzMRm3cRm7sRm+0nFn4RnEcR3IsR3MknmpMR3VcR3ZsR3d8R3iMR3mcR3qsR3u8R3jM
AnzcR37sxxE5R4AMSIEcSIIsyP/xR4RMyJUxSIbcluMJSGJoyMN5SJNRSP+L9CrcuUiN3EiGyUjB
kUiQDEmR7JZ1qC2OPEmU7JKRXEmWLJhOaEmYjEmZVMMDmMnVSUmczEkRsUmexBqd/EmgRBmwCUqi
DLuePMp06QZxkcZ0WRhtKEqohJlu6AaJQUqrBJepNBemzJZtiUqvJJE1uB9l4UofAY+vPEtyahWy
tBa0bMsukQTMWUsE8ZBgARXS6JXHoMir3Esf8Y1FgYs0uQu15EvCBA3haJCd8MvAQAm9LEzHDA43
YZO5vJLGfMzCtBAhcZRg4Y4ysUzPpBXBiJXEnMxmyY/PPE3UTM1z2crVdEvXnB/VjE3ZnE20Yc3y
oZfGrEx2UZfXJEqVEBj/8BhM8pkR4CTOBRmPJvmMdvGX3gxKaHnO4LwW4SSX47SWytTN5gTK0RwW
7twPvujOTKmP0wjMYemQXWEW8+ROZilPvKwSunSW91SLnsjOi/ySQCFOvkgTyRSUOvHLGGmVHmkS
zPiP/iATQAET/0xO2owdCMHPGYkMVKEQRwHMAr3PCb3PtziPD0mU+zAO/gSLDrWLBUWeBg1QXPnQ
D6XQBKVQ3eDPN+GNxfDQA32OC73NEW0cpyhRGj3RGeXMHJFQFvUOQRHSRPlPA/VREwVQhKFPnIzQ
5JCVIt2V8GxQwoBQI+0LzVTP9dRPxlwN8cRQ8VxRj2BSf5wDoIEth9mD/y4JBjINJtlqU4S8UTmd
Uzo9mrqsF2z5l6FRUOoczjqNnKTwT24xzb4Uj+W0zt3wlwutTuMMF9KB04ESVIfMU0rdTYOhFm3h
0yq1VOh0F0glp2N5lgqFUCNREGMR1cQYlVORiFONz7vcUlfVFfK8S7v8TVptT/TEVbpcTJ4YiE8d
p01lCS69DCpFUhbNUitBUAclT2Nl1CKtUSBNlWjlk0UFUmR1iF8VpmC11rl0UhU5UBStDQB10i61
jg2V0HjxjRXN0L8UTJUITE1BFDFdiWx1U2nN0nnF0GYd1SX5DWhVS2bd0flI1AJN0nY9kmfNkRgF
lHoNIOUUWDAFFMhs1v98hZZ/FVgj4VY9TZWLVVILXZSMvdaK1c0/3YyIBBdg+Q+5iNDzbJbujMxf
CdUzkdJWpVYoRQwtnZKUuFIvfdDxtNlewVfA+E294QeDZE2SIVkSXdKGLZFNaB6kIVr9GdOmzSCJ
rFo+ulqs1aBQUdp3kVWzsdFv8dWtrR9OPRZFLc6uXRWxNZNOxY62XZfp9FO5JJOeENXoLNmBOTpk
qVvD1IvjCRLY8Vq1zVu/zYt+rda/LVurjc+96AlU2dU+RRP/+NJcvdsBEc2FZVWXtVXIHU/L3VYX
Adww9QmmXRhfYFyyWUsBvVkiTdF/iZMh1ddq3ZQnEVGNJZTrcNvk9BX/xP3d3Z1QetBbfglUhBVW
lg1Xt80QVqmOAP0e+USUxHUQxkTQ5J2STEXb2IVbkT1d1Q2g2d3dFp1eHPHdfr3Xt3XPTVXeWYFY
PdFdi91eiHWU7y2g8N3P9ZXY5fVYQjHR47zW6YXd1y1fhF0RAWZfsq1fAXpZ7l1P8CxNcbVd05VZ
6/XZVdXV0rWQujxV7X1gCl5btnBgoi3X0VTg6iFeFE5hFb4WpIVJE7Ydvnzhn+GAphAGpSgZsIUa
wnXIHSYPGfaclr3Uh3zXCZ5cfUURqf3bua2UHv5b+1wXEf5ZH/5hzQnc8NBgaYXibX3ifnHUdElb
WpnfEH4IKragS41i/85t1SR2UCzlYPbE3MfFy80tT7z1XCq9VVjtVbxF45x1XPStjBWWFwmGku4t
VGdxX9pt1EF+3ZA9X45VEkUOYIHpTEf+47wg0EBWF1aVXgQuS/MN3+dN4k0m5ACuXtBskDl5FRQV
FhJ+397t4ASJ20ye1NGV5PYQ3fz9UfgVkgHe14Glk4Pt5Oy9XYU9Y8CtVL55BoAE4E4G5iMGZTGW
Wzvp0WklUtL82H1d1CEV3Oc04IOFHyWQrVGBVQhmXstVHgkeWA2+YD5W5aEtTQ11XTqO2XV2Y/is
D7hdkFKR2Sz+TEaQySae5YpEithaY48pY7sRaIX23qGIYYSmm7NFzv+NTV/zGOalLVx6gQds5IRE
jJ5WzhZRFl9n9RZdHmkmXhrSIdTveGh7yAC4QRGMbtRbnuiIlmmURWmSNumFxs0itlVwtctnGWf3
DN03JtXhkFxUlU/kqGPQVeP8FM3zjFUONtVFpmCDRp4OmLqo899e5lZSFsxi1mVJnVlhxmT9PJI5
CdjuzV6uTutJlg2WNqhlpWrX3dxQll5sxuXvbAsSLuQdGU0NzeVGPte97uu+DlYe8da4HpxEtui8
TlAAdmXJ5sxUFuPBVFf8lNG89OXMJt8sxszRpd/FDpzG/svH7hP2ReRlPVJbruZHTlbBzmbj9Gtt
7ufpHW3SZmOfbmD/8+RcC9ZnKFVnwJRiVIVqYBFrWgXNpDZX406QCQ5dujbNw8ZtwJmcgMZTftFL
mZkH6lZJybnuQQUY7e5u7dlp8z5vvW1hI65pnabogpFlmkZULeZlw7QX8ua0K57vyQXY9X5YLs5v
Lrbi9j5p/b4S/+aM+/a1SS3LM17i+D7cB4fp/+ZU8GZwfXbvCFcfJmAtdy1VWZHqIi5qdm1ZofbO
2c6UCrlnbTaVoV3VqJZnqQ7aBn7ZmnVjV8Vw9BZi6s1rH+3x0pbnI/4LNo7Y3IVWy/7mIu9mz5bk
C8Hkuc5xAi/ycjVsb0VfIwfTKqdMFaWNbR4SGOWVyl7rlPVrJl8W/1LR2V2GcjKOHmqWEh9/5h39
5Dbn5TkO7UeJWCdfbR+X1yUP18hu3rxOcK9p5gqd1tr+WDmXbQJ+7dzlXUvW82pe62DecgMP85oQ
dL8CaT5P2Zi9ZD0W7hE/5BfnZOEE8qpGzER2YJjt3OQ28xZnZxp39T0G0TxX8zWPOjsF8LGNHUxf
xeTRdey2dWGf8WG3LYJunV53zpx2YnHJ4WJXQx6RZtaV6JLGccN9dgdy7AcnXG4eHWyfIoKecoVg
8U220CkV9eLm9PQkYqduTxO/9WSHnoX4m2kn5MGec/6NdkTv2tMGa2v/9kF9kKummhj1XUlXdB7/
ccE9bAEG+HIBjv/EcVFIP/hId975rex+j2mHDx7jvd22bu1D71/3tXRCr4h4R0t33ucOf+4NDvJ0
XvV3j+BDTmdZOfmz9J5KsfmvxPnx0Hmf/3mgD3qhH3qiL3qjP3qkR/mNX3qmP9qkf3qOaXqpn/py
hPqYgQWrz3qJCUut73qvJwqqn0YrmMkVCHuzX3obkBr0Ovtl/Hq39262t8y3n/ssiXvPpHu8/0e7
F2elyfuG9cjV3fuCFvzLJHzCrHB0KUoi8PstAXz8NvzVQnzIF0fJn3zzZnzMP3bL33zO73zPdxcX
+HzRH32ty3zTP33ULwrSl8nUP/3Vj8nWj/0ydnzZn3var/2vv31H3H8Ylqz814f2349r3d994i/+
nfx95E9+5V9+5m9+539+6E98459+6rf56JcaB7h+7ZeW6t9Hb+h+8A9/8R9/8g+K7R/IgAAAOwAA==

------=_NextPart_000_0003_01C70BFC.87A9BA20--



Received: from [218.62.88.56] ([218.62.88.56]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAIJrDeM079051 for <[e-mail]>; Sat, 18 Nov 2006 12:53:15 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c70b4b$2c34d0a0$00000000@vs>
From: "Stream Learn" <[e-mail]>
To: [e-mail]
Subject: member book
Date: 	Sun, 19 Nov 2006 03:53:09 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C70B8E.3A4C29C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0003_01C70B8E.3A4C29C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C70B8E.3A4C29C0"


------=_NextPart_001_0004_01C70B8E.3A4C29C0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Stocks Quotes in attachement

Countdown Image of Hosting Zwinkys Basic.
Disabled Doorframe Added June Song Need Eelsong came!
Corshacom Timer a enter or counting down eg?
Important in usfrom Sucksfrom Comcastic Pyramid guy a sleepfrom in =
Newsmaker is Didnt am.
Editorial Card catalog am Discusses cocaine.
Start Topic Prompts a signin or Guidelines General forums.
------=_NextPart_001_0004_01C70B8E.3A4C29C0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Stocks Quotes in =
attachement<BR><BR>Countdown Image=20
of Hosting Zwinkys Basic.<BR>Disabled Doorframe Added June Song Need =
Eelsong=20
came!<BR>Corshacom Timer a enter or counting down eg?<BR>Important in =
usfrom=20
Sucksfrom Comcastic Pyramid guy a sleepfrom in Newsmaker is Didnt=20
am.<BR>Editorial Card catalog am Discusses cocaine.<BR>Start Topic =
Prompts a=20
signin or Guidelines General forums.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C70B8E.3A4C29C0--

------=_NextPart_000_0003_01C70B8E.3A4C29C0
Content-Type: image/gif;
	name="readerman.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="readerman.gif"

R0lGODlhIAI4Aof2AAEAAIIKAQN1AIx2Ag0AiIUAiwCFdcC3xsXQwZ/M5TktAGkSAo0kAZceB7Er
Cd4mBwBNDRtCCjYxAFpKAHgxAK5KAMI6AOxCAABnDBxmAEdhDGRmAHFjAqFjALxSAN1mCwZ+BxN5
ADZyDmp4AHZ0CZyACrqOBOp4AACYABicBDKoAWGTAHqmAKyZDLqVAOeoBgDJACaxBz66AFnCAHXG
AK7GAMe2ANjDCgDqBRzVADnVAF/RB3XsBpHbDcXhC9zpDAAAPx0AMTIBQWQISnsASJ4ANrEAQdQL
MQArSxohN0YTRWIgQ4oWNpgsN7sSPegiQA5JRhQ0PTZFNGlDTHZBQ5lBNcc/Mtc2TAdgTihgP0la
OmluO3lVAJFWQLlVRd5qOQ5yQyKJST5zRmCAPImCP5J1MruGTOyCQwakQBmRSD+URmiVPX+uSK6p
OMieP9KZMgqxSiu4QUbJMlHOSo21Qay5OMy7Sey4PgDmRhLiRUzmQGPUPnLXMp/iO7rqO+znTA0L
dSUAdjkAjm0AgnQMh6UAe7wLgdkAdwAffSUteUYhgmYigosgg6gtjccsdNQUhAo2fiA8fUw3e1Yz
c30zjJtJd8Azfe48gAdpcxdeeDRfeGNlg4VhdJpgeblXf9JhcQ59jBN4ikyEeWODdHF2g5d0hrF6
jeqKcQuidCSmg0icdGiYgH2mcZenfsSjhd+djgDMcSS5iDe9jG7DeoXOf53NfMKxfd7GjADdghLY
fjPUgVvogHTTh5nberHgjNXcdwwJwhcAtD0AzWMMuH0Asq4Awc4Hu+YAsgAewhEryTQTtVMexHUS
yaURtrcazeYhtgNCyxE8zUZGtFlEy3FAsps/yLFGtO5OvAJZsytev0RevlJbzHFZyZFrx8Rjxd9d
wgBzxCR9xjp8ylR4yoGOt6NzssiOwuB2twqnsxWYyTmevGCZxYmfvqOUycChyNuuxAC3tiDIxjK7
x1jBx425wKi1uP//8KWfpo6Dhv8EAgH/DP/0CQkA//AA9QXx8f3//yH5BAAH5YkALAAAAAAgAjgC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuD
/2LKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXVsVEtu3cOPKnUu3rt27ePOSfcm3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5
MkO9mDNr3sy5807LoEOLHk26dEHPqGWa+AcgtevXsGPLjgqg9ezbuHMLNc27t+/fwIMLH068uHHB
gI4rX868ufPn0KNLZ/xgpdGCAQIgzg6R+2HvDsEX/xbPkPxg8brTd7XnvX329/DhD4xPnr55gfIJ
usev/eB+9vbRN5+A+tmHUH4D8qegf/25FyCCBhZIoEEILvgfhQ1m+OB7A8aHXYQY1pchf+qVmBWA
G27IH4goTihhfx2y+GKKET44Y4UxfhjggTTa2KKHMQKpI4wryhhkj/n5WKSQLw5Jn4mclXPWkSGG
CCOE4OHYIoNaWmkeh0PmuKKYTXpJJI9aglnmlmMWaSWXaibkYptrYnllnG6aKRCUfE71IZpVStih
oDfy2N2Zg+qoKJ0oOonoguE92uiiiU7K6I+S3idnpl+KeCeReM6Z4EB9loqTRqKGeh+YcaqaJpNo
4v9p6aVttuqprKLqSSmtk9p6Zqqwwtnpr6s6SCiVjk6nLKlFYVqhq1zSiaOLKgrLJLSBqjnttUo6
+qyn0Vq67bc7Wkvurolq66qv9pnqLk0Y/Scetot222uWIwJoqL78XirrvTKyiq+FnBJ8LK8CB2ys
wf3+ye+84GZbbroDPyzpshhHpCm9hBoJMIOHAnowxcF+jGHI4Vbaca4Jg/zQxhHXy/LCDmdsc0gc
k8zmjZpulHOt3L2aK0c/fyx0yUTHvLJ2R3d589M4K63zrM7+67PUQGvordWoYm3yukN3TeyjLVNd
LdRoR40oveqCCvHFGeEac9sHcx33sJTSrbLd8eL/fazejPKdNnPXRbp225/+/bZIcuPruOJuw933
4Y4nXqmvjA/7qeXSLr7Qu6D/Y9K/3bK78+kdkT7xrPKRK7lFqrNouutqm+u5m7Q/tA5gqAxemdUK
jy107eaia6TgFQE/J9h+f6Q8rMxT7ruyhU9v/Wih5xSBUFyUeP33oWUvflDgl0/Z+Oj3ZP76kKXv
/vvwxy//ZtOdwP79+JMGTv789+//Q/MLIFaEIcACPuV/CEwgRIDxPwM68IEQjKAEJ0jBClrwghjM
oAY3yMEOevCDV9kDCEdIQhL6o4QoTKEKQZeGFbrwhe9qIQxnSMP0yLCGOMyha26owx76UC88pIsC
/ymziiH6Lw1GTKISE4jEJTrxietromAOcJkfWtGHQbyiFrcYQSh68YtgDKMYx1gZLprxjGhMoxrX
yMY2uvGNcMwhGeeoHEfQ8Y54zOPTFKHHPvrxj4AMpCAHSchCGvKQiCRM9ZalE4LkJJE242AkH8ms
m0AyY++75BIFIADfcXJ6hauNKA0zSoHUZiSNrKRNOMlKVg6klZ0UCCxjSZBPImSWn8TlK1spS1ra
I5e2/CUtYbnLgxCzlrwUJjCPOUuFBPOYyoQmNJHpyl5W05i6tOYzp9nLhUgzmd3ck/swckpTAqAw
pbRHORMTzHAK053tfKc3fRlPeHayncsspjzlWf/PbeqTn7HsJz19icx/xvOgwyQoQMNZz4IgVJ/+
LGhCImpLfCp0kkRZZ0FEuU6OnrOUHj2nOUHqUXOadKMkHWlHOarOlaazpeI8lSpr8s99djOi2pyn
RHfK02UG9J4EBaZDgwrUW/7UIA3FpjuXalGGVPSoNn1oTd+J02gadagL1WcmLaLRgax0pC39qFhF
2lWYprScZWUpTFEK1lGe8qsn5UhTC1pVcF51qjatqU9vStS8PjSpT0XqRQU71bku9a6BjWpfC1tU
pl4Tq3SFKl4xWZSyrnWtaCWrWL0qUoK8tbOZtexnL8vZk2b2spZNZUxtote+NhOig3UsMRuKy6L/
CvWviy0mYH/KTG4aNLeKdWpv7apUxkZzrrR1LTc/udWKiBa0mjXtZqXLUriqla1h1axaT2vWkI7E
sHz1q2SLe9i8OhagQo0sZHXLW6gmlae/XW9wdRre8vZUueK1L25ba8Tnlhaz0f2qgKGr0oOEdroA
li5pSQJeqo73tXctb3LVa9X9wje9DB1vhHcq1fPS18GT5S+FLUrcw2K4wRgdCmoRzN3TDritBI4r
dsMK4OgmGK5rVa09KJnfDMMWvvclL4ZBbE17Sjih8c1qkAmbZOMemb1NNjGS95lYHxuZygPd8TjJ
ed2SKri7XS4pji27Yu2mNMHZ7eyCMyLQazYV/8Wt/WY135zQOm8TnMudrSuzCWEma1OhbU5uMvvc
4V26OcvIHeih7fpeRjaLI2SGSKRVomMej7HRN7Nlc/sy6YZ0WpMvwTTGRD2dRWbk0wtB9UkqLVM6
klo67dw0qGdN61rb+tYlMXVfdAwYS4ckjsBGCqTVnGpir5a1g/E1SIINbC5fVyKqXvNo8kHtalN7
INbOB7azbZBr4xrXRtFotGfMkNQq2y889va2120PdatbIO9mtryF4t8af9bMLh2zSHn9l3Rrm93r
dve/4V3tmc5bjRepd2hpfG+TWjfGpXn3u9utbYETxNrf5p/oJuPdAn95tA6P8bgnI/GBE5ziGP9n
98QzznJom/m/Libww4NT8oJc++Ymp/jJWw5qXR8Y5gGWuciNreVWB8bfF885zndO8JQf/Ok8ETfE
0Qzy7gL9v/xGd6snbnGd77zmUA/7qTou4xaPNZ1eXvGxaZrsrecc5V0/OdjFTveZFDslWd+10X9d
974rZOQZyTtfzu2Rvvs9IYDHiOBfQviOGN6MPI/8rXVdaks3XvIfEfvNWG1JzJtki4DkBz9UInqM
ld4vp0dI6jFPdoMkHjqrt4foZ6/62Y++ILHH/e0JsvrS2z73A/m9R4QvEOIXP/XAl/3vfb973jc/
IcjfffKh/3zlB7/6Lcfx/ZZv/eMbJPrOx77/97/ffOZf/yDg3wj402/+6Z///RRJf/cfkvvei7+P
4Rb6mb2cdmk3hvM2YXvOB3/wF33TB3z2N3/193zm133EZ3y1p4C31373R4DcN34CSH7Hd3ocmIHK
R3sOOIHld3ugx1X651kIFlfadxweKIEaiIGjl3wyOIIuqHs22IEuCIIL0YAh+IEVaIE4aH1BOIA+
6H3rJ30xmIQEOH+BlH/bRWxVp4JEJxkASFM6WINEKIQiGIHoR4MXaINEmIFH2BBDaIDMV4EJCINM
2IVFWIZKaIRXGHulV4LOZWxdFYVp9nq+IYZI2IUCuHzYN4MD6H5r2IGG+Ic/qIPyd308+ILj/9eD
ReiHIniItAeIHwiGS/hH+ed6UJiC/mcZVQgvWoiFXJiJj4iJo6gQcjiJW4iKjviIq5iKbFiArWiK
fDiEmdiCbCh2adWJC6Zv52N5MkWB77eAr5iFL4iLpZiGOXh/xniKo3iANKiGyriBrAiLbxiNfTiA
dEgRvYhd/PdsehgaX2h8ZjiL6Eh+i0h9V8iED+iMFwiBEoiG0wiJuoiM9qeIfKiGpuhHlCcdoWh3
azgShFhIp/c+XkAXPiCQlGV0OQGIEBmREjmRFFmRFnmRGJmRGrmRHNmRF6l5KYZsa8eQK1GQodd8
3eh5KikYNvA0/+gbi4cQjzeTu7GSNllIL//5d1O4GPy2kyNJk0DpFCHlkzIWEUNJlHUok8o2hft2
cCUQlF0xcuNYlB5BZrzWf+UElVr5FKjWceFIlf/FWSQ1lmSJbyelYx/leur0k1sJlQnXfygYlqXF
XQa2kw0nhWpHWlK5lp5lSjf5lxNhavdWdd+YXTqJeCn4Yl9mEFepZqDFlm0JlMNWl0D3hJN2h2Lm
mPr3hKd2YFMJmJInmESnmPZ2mGEZhaQZlzCxlH7Zl0UXmbCZUVNXmTUml5RJm1IHY1eHdazJl14F
mbEZnI8ElyhomWhHlJhZXZ1onJppY2j5bK0pnOqxAhIEEp9ZbkiplHvnm9opnd4Zk96YnVz/RhE9
+TnfeZ7b2ZkhQZwAdHndiZ7wGRNQkxPi2Wvx+UCgmZ/6uZ/82Z/Y+Rtk9Xf+WUjsaZ2jKXX1qWqf
CYVv2WkByp2/OaCCtILreaDN+RAKWp+It1EJF6EI8aAfKqFJtImcOJfKWZYq5Zko9XNplqJUx5xg
qRMMaphr+VYe2pp86Zit+aAgRWOveZ8kVG9gJpanOVaLWZwvx1bHiWZMKm2N9JjcyWI36psgmqM7
SqWo9aNACkJCipqaaaK7qaRuZYeJuaRHmhBPGqE6yqBk2qNqeqUz6pdbikJdWqZIOqZhGpfKmaJl
2pycWUUylZZ8CqGC6pp+qaNWmqNo1Zdz/1pCdaqXXzpjdKmaMQemYjmbYMmYlFSodsihnfqbiMqj
nsqojRpA4xlyuimXpDmpuwlyeGqpM2ebkmaoNaqWtnqoMAenoEqrIpo/oRRme2qbXymFvgiOmUmp
ZkmkTspjy1mlOHqnRCqqilql51SqIzSf7plq1mGt8nNIGtqr4Ho93xqueZSTgwOeiMGtJkKu7Nqu
7vqu20oUonGd5Jmt6aqu6tGgL/UYl4mpIvEBABuwAwGwJRGwBAuv30Oin5gY/cp3OHGwAnGwEPuv
HxCxFQsR+BpA+nacKOqiHHuXLZqHl6qiLUqyrWduD3uxBWGwLHuxLGuxBjuwL7uyLluzMv9rDxJb
sT2BABnLGW8Zpnj4cEa6cHg6YEEnq3RJmEaalxAxsQSRsyoLsQQrsDhbsVKrsjdbtRZ7szmLsABZ
WWmXmnlpdh/HYmbLtEB7thSqqafSslk7sVertVsbtzQbs3Irt3Y7GzjQs0nhpceqmi9atiH3t1ZH
XWdWuIj7afzWtXd7t1MbtVYLuQYRt3Sbt3yLGz+LtkUZq2R7Y2RqqYlrY6GruRjBuHAruZQruTTL
taprt14LHQqbtJ7IuTZGtqs6Xa96uErLtCh7E6e7tY2buqwLs5OLujWrulp6ueKTmyEbsmFbu9Br
uKLrmfgGXbj7p6SbvHbntjJLtd3LuHj/O7NPK77ce7fKexv96bQTob6vSziPZj7oyhHs27RYe75b
Br/2WrquWxETa7+y0b7BUQYAfBH+K0EF8HgDnMB/EQxtV8AO/MAQ7J3KEMEULBUKfMGVV8EavMEc
fK0Y/MEgHMIiPMIkrEgdfMJxUcIq/Bso3MIu/MIwHMNttMI0bBoyfMM4nMM6vMOSVGsUUMMKBKSX
wMMwZBtvkQhE3LO1kcRMzBQAUA9NzK2NQa9ADMBRXMAndMVa7BlV3MVltMVG0QlR7MVkHBnmapNg
jBoDmsZc7J9sHBOnsBdlPMeMYRTacMd4rA0Dkcd7zMcFoccHkceAbA+CrMeDLBCFTBCH/0zIfpzI
jIzHBuHHj3zHfSzJhKzImAzJlLzHlbzIjJzJgnzJnDzKocy2b5wZo5zKonzIi+zJiIzJogzLqvzH
svzKntzKtPzKsbzKCcHKqQzIm6zLvqzIvnzLtWzIuexIpyzHFBEBqmzMw2zLgQzLxlzLmTzLumzN
kUzK1IwQyCzM3TzI39zLsTzOv1zOu5zMdKws0czJ7WzOz5zNs+zKlyzO06zO98zL3DzN9ozL9ezO
CzHO8IzO/UzO67ws7WzLlmzPfyzJidzKpczQkwzMEW3JiNzIDh3RpFzNwCzNCtHR9azR/1zOFn3Q
pFE9CT3S/pzO+izPLu3KEk3L9GzNxf8szzDNzf5c0OIczNmMzDdd0PlscMt8F/Es089c0hJdzdg8
0d7M0tt8zOjs0hcNyS3d0j6NzzrNzwAd1MA51Cn80t28z/Mc1jT91Ft91mMN1cOs1B4d1awM0mDd
x04t0FUd1V6NGdjs0EZd1qDMx6H80Llc0RhN1cRM1bgM2NfszpT81p280p/syOn81oQtynetF2tc
2V9xEYW82Zzd2Z792aAd2qI92qRd2qZ92qgN2Sb9xfLqxpjtFasd2x0q27TdElQs1K/twEvsFLXN
Em9Hri91A46X27ptxFHR239JC4exryJB3Mq721eB3LJ92xjr3OoK3dad3Qck3dzd3bj/FgtkpN3i
Pd7kXd72693o7bDmvd7s7cDp/d7wHd+C0d5NzHOCIN/PQd9MjN/83d/+3dz6TcT/PeDmGeAGfuBb
SuAKvuAMrhAIntsNPkQeFOFBDD8UfuHA/RLMDTXjCkZnXGzPm2+fyomZCazOmpiXOqUel+IMF47M
/ao4Cp0im6hGyZzWO5rWiaQ6PrIrrpNTmaAgTt18WSIWQD7r6RBxSuOEqq0qHqVLLm7P6qxOHuVX
yqG8qqiuiahNvuUC2pc4ruIdDuI3Sq3PWqtlfqsQapQYyuRnPtvn+r6IWW5XXqhO7pNa3uRsiqWd
muS4amBnjpQB+pjI6efTar1oDuZB/06juNukVl7navnlaT7nU75dYHZ2hxroU6rllP6xl55dE+5p
di7pd07naD7ivJqWgv7ojb6rhG7qIWrmsP7qVk7nnLrqiM7kaxqpi0rojj6qtxrqvv7neknlUA6l
Y07sqQ6qiOpBJ3qgsp7mZ6fpGzqypM6ngorpwS7sTDmozZvluurjbkrrkc7jIgvoxN7oxo7uXm6r
Ln6Zqo7oM7qmsw7tXbburN7nERo/JeHu8F7m6b7qru7veg7tSx7s4S7n846rg87uM77h2d7mCY/v
Mb7l6V7tOH7nth7rZhnvYjbvn+qnNnrvsT7uIWnkptnl2j7mMn7sGf/ku7rnGU/q0v+K8m+q8Gzu
7cC+oQHP8CKPpRBf8QT/7hBP8PLe81Ie70Hv87Qq7jP66dOO8Cwfqi0/5QDv8rla80sf9cIu6VFK
5ldupUVf8D1P5RE/8sa+7WQv9fZe5VVPpZwq8+duqJCu5Ey/9tHZE8adr3zRpv8O97w+44qe7flG
7jTK42MKoyva9Sz+9TzKsXVZljfO65Qu92BunDvuos3LlC/lVm1F74FP+YeepCF+9OIZ5icN5xj+
9Z5G8yhh+iTfEPqe+lU5boAu5KwPbbJPx67/+haRCbn/+8Lx4cBPSK9RC/I5/LT2v3S0+9DB/JLh
/OR05F/NEisvEq2H8LXv8EeO5Bj/X+Pa71wf+v0kvvCmX/0a8e8kvvpI7v0Ouv3NsfC83xHMb+5c
/hEJ2v2zWv8TMfelr/pDDxD2BA4kSBCAwYIJFS5UeJBhQocPBUaUaI9iRYsIGV7E2DGjR5AhQf4j
WdLkSZQkKwLgODDiS5YwWbqMObFmxpsaC8acSdHhQZ4vd+rkSVPm0YkWf9YEOtMlxI8fi0YVqpPq
zaZIcWb1CTUr1KFfk+JUqtWqwZxpldo0urSnTacaxZZ9+7Qs3J5A7e69Gtet2bSBa6YkXNjwYcSJ
FZfsGJfoWMhPL3b1O9Ry0q5SIU+Wi1BoZs9Vae7lqBezZ9KXNUv+HPpsVNZ8YWOu//pz7WnZLSnb
ddobtm3cC5dKRk187PDNqoEf/+3VePCMi6WrnJ5Y5E6mOdFix/raNN/vs4OGJ88cOl7RZK2Wbr7+
IfDyZMOjB998t3fnufObLw86cn32ksustY0i66+4zhBsKz3b/Dvvvv+uk3DC6k5qTLfQpgpKPAU5
U6695eZbDT23SKTPQQcv02u800Rcjq66oJsvwA5Vk5E5yjZ8DcTKBNSRQOEMtE+uHjkL0KcfYfyr
RCWbq/BJKKO0UCLHPqRRPQDPujK+EGejSrawwLrRvQJbbEg+MdMTEsII2UNxv9UOLPPDBL/E8DzL
2IyPt/9cTA1OIRUUUkpCp5sQo/+W3IMwxjW1TPM739qjc9Eh2Xrzz/X2VDNQPSsFE0T8+BRVzjZr
rC21AZ8709MYWzVvx1T5XBRSVhM99NaKpLxVR7qMkgqr7nL7sS6mNntRv17hasvXGYvFFLy/HhPz
OGAFO/Y2tHqMMFlQsfy1ymXx8jU5ah0jVru7BjzXNO3Q9ZJDbqNVlsl43yr0Xutw1Xdffm0Nkl+A
AwbYX4ELNvhghBtLeGGGPdK1YYi3nTNiigUmuGKMM8b4Yo0HwvdJCj4+rGOEOf6UZJRXSnlllg82
uWORY5Z5ZpprtvlmnHPWeWeee/b5Z6CDFnpooos2+mikk1a6upabdvppqKOWemr/qqu2+mqss9Z6
a6679vprsMMWe2yyDV76bLTTVnttKE1g+22445Z7brpLCqHuwpLBe++by/b7b8ADF3xwwgs3/HDE
E1d8ccYbd/xxyCOXfHLKp/alcswz13xzzkPCpnPQQxddIb5LN/101FNXfXXWW3f9ddhNH3122mt3
PHbccz/dGN179/134IMXfnjiizf+eORjB6F1JpJ3/nnoe7Z9euq/LqL6hKLXfnvuuy8Me/DDF99q
78s3//wnfUF/ffbbd5/n8eOXf36Y32cbFfvzt59+/vv3X2D9BVCAv3PAAA14QATm738LZGADO5JA
CEZQgkBzYPgCKIoJEqaCG+Rg/wc9+EEQ2u5hIRxd6x6RQaLdChwrZGELCdJCcLwQhgphoURcOJAZ
PgSGMZRhDXvIwxUmJIg4zCFDimiPHQYxiTwsyBKVyEQiIjGJOrzhEGXYwyb60IpRlCIJvZhFIVpR
i0zcokB8SMUrmhGKWOTiGc/YRTWucYhvLCMRyTjHNaoxJGWs4xM74sYY9hGKb9RjHMEIx8Dl44sM
GyEiudjGO4Kxjod0JBoXwsdB3nGLePQIJgtJyT/KMY9+xMgkBRlFT8Yxk4VEIQT5lUpJRvKKk0xj
JS+Zx0fWUoyBjCQtaYhLUoKylKIMoy1/ecti6hGWweTkIr8Iy1nKEpW4rKUxhf9ZzUfuEpHBrIgp
eblDKYLTknac4hKP+UtzKpOY6oSkM7HXSGhO85PyHKcqjahJbmZTlpzcJSHnSc9r2nCd0RwmMimZ
T23CsZmtTOArBxpNfybUoMmkKEB1KU0/nrKiFs1lQbHZRV9+9J8KleY2ewlEarpzg/FkZyWneE+Y
bhSkwMRoJvNpTG/iNKUTHelNzylTPB5RouFEqUqpB89RrnOoQ5VpRzvazFwudYwBdWlRm1pPW/r0
px+F6iZLekOCMBSBDg2jJucJ1ZHq06l2TCMgV/nPMb61rGzV6R4f2tJuavOUyyxpONNq1ArSUqjE
ZKk9VbnTw4qSkFVM6g9DSlT/uYoUq3t96S2nGstDMjaZjwWs5hrZ2cmJVbQjA23lRjvA0qZWtatl
bWtd+1rYxla2s02cJ1r7WdrmVkKnfRKuGJtOUHrVsBqlIljJmdS4VjaLQZ1rRJ8ITuLmELiOxac3
6fjS31b2iFz95gw96USaVvO53i2nXDmr262u9aISZao1L0pXv36ysBQ1rgvrW0PrZvakHiVpVPv5
17oelKaEpWZ7H9vP/TZVqrB9WE4FOlzzNvbB7WwrYs+L4B8SNcPWXaWDJ4xX4VY4psK88HWtaWDE
krSZHhZxGnlbIX2x2KCaVStVxcvLYx44xSbtb0aL6lNm4viqwRUyj4vpSxmX/5jHSC6yZCu84vAe
WcKubXCULUlj+U55xDM9Z0iV3FIf97i79i0yWhPL4iCvdbxglbF7Abrm6xY4xUG1qjnt7E84vhh+
AUYjPyM85Bp72LjqFTCEVfzjKHcVkPyFski1yucMzxjRxeUpMv2cVg6fU8+G8q2Vi4tSvgI6sWrW
MoDfq2EuoxrICW6xQNk86JwyOb1U1WuT5zprdIK6r5i2tZs7W2Vcl1XXhbYxqXE9X2IvuaaQHjRe
sVrIEGO20qZmNn5Tuuph0tnYm13npnXG62wP+9ROVu98kT1uaUt5q81O9YfRnUpZixrN1p4ocT9t
WEjXOHvexhm482rTZBO63P//NTK59Z1uhD81zb72d5bN6t4k7xquWkVxttmY77PKkt+K6bS964lJ
Olt7u6be7sgZjuWETxO6Ei7idLftXxPnGqjs7umY6Y3N8zrSqytfuX7R+3OgB51CURJ60SWy8b4Z
Xen7Rrphlv50qEdd6lMvCG6p/vOm0+zqRs/69w4VbZ3vXLnSLfWZ4yz2/N7zzuw+e9vxfFzuovPW
h427cuGbVU9nPOaEhrVby8ttgRcdw3qf9qI9PvOHo3jHVXXq3uObc7ca0tFnl/zjvwvwi2fcsvpN
/F0p3F8Ss1zipdWVtsOO8TbreKOKTnl6mbrwz7v70JMX+8Tx3W7Nw/vaMQ//NbUtGk+NJrTrGlSh
uIUb8cJb2PPtvjx/s5xuyjpfnu1NdZjVXWv62trMBHX25yHfZOCLPvCCN36H8y5YJ8o+1n19NM7Z
X+bGuhzcsOe+9TGL/UIL0svwDzD1cxzZqkon/wOt0hMybsI2yTq80Pu/mmM4xsO7guOoaas+q+K8
SVM3Mcs+jPM53FOr79M89wM8Vho+lIix5EI325s11Zs8yNJA9Wu2hIq+vGLA7oO2qVq/6RO/Bhwn
+3uvLzu9EORAB9StK4i0+xo5cyu7BcRAkKO5IGzCy+I+2XM2tls2HCQnCIQsBbwxBOzAdQNAlmI9
KiM6Vdu7w0s95Vu9Cow2/87qved7wA9sNVSjtQq0wQ0bqIr7uCicuDl7qPATNe6BA9mJr8r7w+WS
wBW8uD00s0QEweajq+/rvEO8KuaSPJALuzp8wC2zvIe7u2PLRE30Ph4iQZHxryAcuD2kNvRzvA5s
RMa7vMESJ8sCu4YjMlacqcFawk3ExLRTu1dDPiEcIlL8mK0rumE0iWJMRmVcRmZsRmd8RtA5Rmmc
RryBRmv8NWrMRm1Um2vsRnfaRnAMx6PxRnK8jjSQH3FMR3VcR3Zsx9RpmAwoR3mcR3qsR4RxR3zM
R33cR37sR3/8x6ExKhGwR4IsSIM8SIRMyJAASIYESA9SBoWMSImcSIqsSP+LvEiMFJyG3EigkQKc
sQCODEmRHEmSLMnccYbjKQKTXEmWbMmQzEiYjEmZfEaXrMnhm0mczEmdXDqryxib/EnjYRmgHMq9
qZiX2cn+mQV3mop3gRWkfEoAipJN+ZeAIUqrnJtdKY5q+RbaaIpxYReoDMuqk0rU8A8jiRM7qYqr
XEvc2Q1t+ZYVwZGiaAm2rMu0ycrnYBRaAUtvaUqxDEspORVV2Uu0BJKPsEvEVB2mnAtnmUu0vIv2
SEzJHMSUmUzLFJq/zMyv6UnduswI0kzQ3BrOZIupOcodsRif9Myucxe/FImpDAlaOU1yOZkJERGP
sJWLUc2ua0rTfA/UlBj/quzN6xBO4MQI3RwrvNSQ3vCNr/CL5WSX5/SQBkmX7mDKeQkWdNlK55zO
bFGWZNnKrdhOguCA0IyfLhENr3zMvLST+tCM2ESTQGHPO1GPY4nL9sQS27TPvixP7FECsAASAOUP
Z8HPLyGOuERPAsWUFSkNx4yTYjHL9USSt/gM4uTP0DlPVBkV9gyO90QT/WwNBslQ0uwTHDFQMiFQ
BH1PcLFQ8MFQAdHQAA1QaVHRBJ3NPdlQ7oTP+CTMFw1RFh2fASWPSHlM5eTKAv2T4QBRYZFPcMHO
ctFP7wyWXxGXvVzRH70dMjTG82mE40SMK/1SMA1TMR3TDwrMKTWYFFmV/7CxTSqRkAo9mC4tykOB
0oJJ02mpUNwMmERhUwTxkOCMmDclU5ah098sTtqEzYnRlz1tTWlRGEMV1L9pJPC0T/hgTnHhDfF0
z3qpkuxgkknNi6/81EXV1E5tkOzMi0xlFpkIVea0FnuI0+Bp1PSEj7Dokgg1URS9z3ehUVqN0UMt
zCP9UFk9UmAlUSXl0FeF1d8ZViWNFgS9VdqA1t9gkCBtUFMN0qvwzQMN1hrlVl4pTOV0FR6NDmXF
yn1JURMd1xD11RztUEsRUXjJ0RfdjjPZVnT10Q39zwe5VRl1mkfwmkCdLXRF0vVsFGSdzn7t04Kl
z4NVFeA8lXu9z4TtVf9pFdbXbNExhJJMeRH0HFBuMVLIhIkCtc7AuNTn5I8oxVTI/NMpPVbxiM3s
FFCkcNloQSCWmMbJCdj+0VnN4dMfZU0SAlrx4dkGGk2LjCAAoEZI3dlltFKrsVKirRqnbZio3Zyq
ZS3dENpnQZToPEoaeRnrdE1inVOVUdOVFYzaZKCrXa0rKVuxJdHbTBNHPddCTdQR9dVHpUr/WVvA
As82Ec/GjM6JWVXu8M7rTNW/XdVmTRfDPVXF5dSTVRFkERZ5+VjW6oG+ddiUHZNc3RY/lVgvGdiX
dVEfaVg8CRMwMcxhHVFs2Q93XVqoUd1a9Vi8DV3laBfNTdGwZQ3arVj/GGndZUkR2TWQmNUSbL1Y
2B1UzRUU0FBXG+FWeFVQRu3L5s3X/Kxe4V3eXbUR7F3Y5IVTsjxdabVeYt0S0P1a71XY7jVdSclX
2xXfI/He2j2Icq3GXRnScDnb5TRSapXSS/3KhoBZyE3VahFg/m3STy3cXXXO7jTc4MXUqf1eCZ5g
Co6cYxBLo9XM+uWbMN3ggEQcqAUcvlXUERbUAaCY3ZVbkMDd/9Xb2VwJrVUZ5CVbo3Tb2yXcX63g
gVlhN1XZF56WH7ZbGi6ZjbHh0ZjXbHVGORgcM1Vg6oTOylXhsfXbJ8bhxGWWdGVc/Z2MIS2RxRRc
k0Xgx+ViepHezuAI/w/GzPslXfKdyuYt3v0UXTJG4rRk3/yUlR1F3c7lzfal49W9jWvJSXjAGEn9
3fXtVrgt39xFlRQOT7303Q0RY22p3l6J0bBt0FKB32wxkrBN47ph3sdI2PdVZDwR3QL53PldYKfM
41QeVW9BX1d2FDARnqCoSfUNZflVU3z1EyReVMNsZV2FWFaG5PMNlf3M5F0WCEKxg7cZj35cYxwG
Fv6FFlFl0EB2lZX9X7StZJX1VDEmF2zl5id14DBGDgCGCAYel63VYabrraUr4YTxZArqxhhmZ3um
4FognAzOTHk2V9lE1NPU2RD+HzsViX6Wm0i+kIFeZLxs1Lwd4jVFlP9/HomRLAbXUdQcDmJ4AeLh
lGKqJRuOKeh7vpWHAQxOjdDqPFzCbZYyLtVy0UowDtnwTBB6cdwoBdVN1ebI9VuSldI5TpaDlh5c
kWNcblhNqeOiZlZVbuPYeN/63F4RbVemrld4PWRfzuiRftu0bBeflk9soVCP9WNvBd6+ENf09VAq
NV/ckOqEjtYHPhHQjeNwzuodFutEJkyRVV1YlmJIoeSqHlu07tgT5ctxtVHndWhhTmp41mGinly8
vuVSZmj39WvndWNRad/1Zetc7tcOfVbFpms9RdKT5g6uaJEu3lwFzlomReWY9t/RLutsvmladeRz
nukwblyuNpcAxmb/0G6gxe4Xp/nt3p4e4cbopinu4U7uL3WKfWbRoMaXm2WMjMFTF/ZNgH1T4Y5l
7YXhkY5gQDXbwZ1cjp5bIebhNn1oja7T6j5mI65g70Zh8NbbGZ7o8qbv87Zurc7u9fbZ+u4cenCm
qW1i2qbPSBHV/K1iM/nYL0ZY3tbiSpWXuWbc2hjgnB7ZnXbVTU5ZTwXZkLXU566QpCWttD1YNq7R
zs7Q097aWX0WwaxsFvdd6a1dPT5xo65Vz2XkexZwdbXWao3wiH3hCW/wGcnitn7ljebObyVqCs3w
ieVXKj1ipVZm07mAyUxlyD5ypfbsqfaUHqXewcRyhtVlGF8LK+9l/x1tlihP1g8vxSE+7DMf6zxO
cFLe48+NcxkfZc+mbPIl5mE2E9nVc+QeU0wW0gdHDgwfDZdVcFdFkk9JcZmmltRlcQS28JndTgEe
4A13VnUm3kBW7sEhzsUOdE+X2s4B9YUR9VEvzYdo7tBZ89WsmfFx9awLca8zbvNmmIVOddAqbl7W
Y5btYcm1b4jWddHh9fU2VJ5F3+8m9qdBh6f5bR5vTvno6sCNYtnuTg1xYCjWaQZHdWbXmlDHVWOx
4y0/5Bhf6lbu9G+vHGg30Dwv9z0X63v92kGP93UPIQDlVT7v1j+var828/m+d7X9ciXfd3O3Ucz+
6yYXeBEiOscsWf+w1op1+WH/RXR3Z+3KdW3gkHWbKYACQK3w8XYw9Xj6YXXCCVSOl5mPR06Gb3mX
n5BceHmZn3mar6CUv3l/rvkOxnmeZxu6jgTl7nmhv0udL3qjr8ehT/oK8QabOXowVXqoj3qpD0qn
r3qrd8apz3o9kwGt73qv92R7iIer58+vL3uzP3ufH3uyR3sPlgC238ZweGYd1gZif3uT0Aa814Z8
pPXioeu81633Vnup+XvYCnzBr5q8p3vVMvzDzxrCNyrGXxy7fxK8n3zLv3wvbXzN3/zOxHzPdzrO
D33RH33SDxyS0ITPT31kFAhN0ISaD4crPQnUV33aP/3av3yFaP3P0kdK1999sMEC4A9+4Qd+BzKM
2b/9s5cI3QehSshMNvB96IfKL5h+6qf+6CcZbax+7Uf+47l+7/9+8A9/8R9/8ncm7j9/9E9/9V9/
9m//mQFJ949/5OEA+U+h8r9//Oecng+A+l+M/AcIewIHEixo8CDChAoXMmzo8CHEiBInUiz47yLG
jBo3cuzo8SNIj9pCkixp8iTKlCpXsmzp8iXMmDJn0qxp8+bGijp38uzp8yfQoEKHEi1q9CjSpEob
4mzq9CnUqFKnUq1q9SpWqAEBADs=

------=_NextPart_000_0003_01C70B8E.3A4C29C0--



Received: from blackfoot.net ([59.91.255.10]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kAIBfUs6016515 for <[e-mail]>; Sat, 18 Nov 2006 04:41:32 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c70b06$3134c640$f393a8c0@kwec>
Reply-To: "Raul Burnham" <[e-mail]>
From: "Raul Burnham" <[e-mail]>
To: [e-mail]
Subject: Re: PHAmofRMA
Date: Sat, 18 Nov 2006 03:39:22 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C70AC3.23118640"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C70AC3.23118640
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20
economize 50 % on your PiiHARMACY http://tadesunjinkyunhderunhas.com

=20

=20

=20

The doorman here. He does have a name after all. From what he says I
get the feeling that this is a pretty stratified society with everyone
in their correct place. Great respect is given to the scientist. Veldi



------=_NextPart_000_0001_01C70AC3.23118640
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAequiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>economize 50 % on your PiiHARMACY <A =
href=3D"http://tadesunjinkyunhderunhas.com">http://tadesunjinkyunhderunha=
s.com</A></DIV>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>Fall  out. Ill give you the other side of the conversation  that  =
you<BR>
didnt  hear.  Were not being followed. I waited  until  the  ragged<BR>
cheer  had  died  away. Which means we are stopping  here  for  =
food,<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C70AC3.25AF89B0--



------=_NextPart_000_0001_01C70AC3.23118640--


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 kAHMZhhB025283; Fri, 17 Nov 2006 15:35:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHMZhnv025282; Fri, 17 Nov 2006 15:35:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAHMZgmI025276 for <[e-mail]>; Fri, 17 Nov 2006 15:35:42 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAHMZTH7087801; Fri, 17 Nov 2006 15:35:29 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sam Hartman" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "Ryan Hurst" <[e-mail]>, "Price, Bill" <[e-mail]>, "Russ Housley" <[e-mail]>, "Paul Hoffman" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Fri, 17 Nov 2006 13:58:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chairs,

If I drafted a 2560bis along these lines and submitted it to the IETF
editor, would you approve its publication as a PKIX Standards Track work
item?

Mike

> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]]
> Sent: Friday, November 17, 2006 6:33 AM
>
> . . .
>
>
> in the interests of moving forward, I'm willing to let this slide
> especially since the lw profile gives you that guidance and especially
> if we're eventually going to do a 2560bis.  2560bis would actually
> need to speak to mandatory to implement behavior.



Received: from adsl-dyn13.91-127-178.t-com.sk (adsl-dyn13.91-127-178.t-com.sk [91.127.178.13]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHFnSXP070831 for <[e-mail]>; Fri, 17 Nov 2006 08:49:30 -0700 (MST) (envelope-from [e-mail])
From: "Shes" <[e-mail]>
To: [e-mail]
Subject: Bryan mahnamahna Katz
Date: 	Fri, 17 Nov 2006 16:49:28 +0100
Message-ID: <000301c70a5f$f7164070$00000000@owner1qacobql6>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

 35040463075046487    534516211312      88270670741734          733525                      33243584811       82166813368276
 42286026411785631   45332308560403     7355852425256782        42774582                   50681218514548     312500456657438
       72882        57152      17725    0442        8604      5067234127                  05801      32050    1626       0672
       00706       26764        58636   3744        3867      8812   6282                65850        38200   6242       8178
       17742       02366        48415   1834280101483065      1365   3578                41861        42017   45345145377070
       42853       73621        84417   37155253072222      201432   80683               37258        23440   361084634006667
       78402       60302        02612   738185580301        661465212078521              56367        75216   1761        8444
       86552       60573        72754   0607      7680      7786553042531802             07434        08382   5846         382
       30631        56140      53415    5680      87531    54186         3358    53678    63110      82223    5884        8244
       77837         04176724867718     3463        5630  51568          2554    74530     41857877867788     678856782801271
       08783          743204606570      7352        5684  77050          8423    62775      187720681646      00556046534545




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 kAHFX0Zu067900; Fri, 17 Nov 2006 08:33:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHFX0m9067899; Fri, 17 Nov 2006 08:33:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAHFWwu8067879 for <[e-mail]>; Fri, 17 Nov 2006 08:32:59 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Gl5i1-0000Up-3M; Fri, 17 Nov 2006 10:32:53 -0500
Mime-Version: 1.0
Message-Id: <p06230902c18382b70e4d@[128.89.89.106]>
In-Reply-To: <011901c709ab$b907eb30$82c5a8c0@arport2v>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v> <010801c7096a$8ef012f0$5d85900a@wcwang> <011901c709ab$b907eb30$82c5a8c0@arport2v>
Date: Fri, 17 Nov 2006 10:26:23 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
Cc: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1048344917==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1048344917==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 7:19 PM +0100 11/16/06, Anders Rundgren wrote:
>Wen-Cheng Wang wrote:
>
>  >This change will immediately make these CAs becoming non-compliant
>  >to RFC3280bis.
>
>Does it?  I thought SHOULD is a recommendation.

SHOULD means that an implementation is expected to provide the 
indicated functionality unless there is a REALLY GOOD reason not to. 
This makes it much more than a recommendation.


>  >For a CA to guide its relying parties (client applications)
>  >where to find the CA certificates, one  id-ad-caIssuers accessLocation
>  >is sufficient.
>
>You misunderstood my point.  Certificate path building on the 
>relying parties' end is (with S/MIME as the only major exception), 
>done by servers.  For servers there is no problem to fix.  I'm 
>rather talking about client software that is not relying party 
>software, but rather subscriber software.  Although some CAs indeed 
>not only specify and distribute such software, it is not these guys 
>who have a problem, it is rather the other 99% who can't afford 
>writing their own subscriber software.

Cert path building and validation is currently assumed (by our 
standards) to be performed by an RP, The rationale for creating SCVP 
is precisely to allow off-loading of cert path building and/or 
validation. Thus your comment above is not consistent with RFC 3280. 
Also, the term "subscriber" appears nowhere in  3280, so your 
reference to that term above is context-free.

Steve
--============_-1048344917==_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: I-D
ACTION:draft-ietf-pkix-rfc3280bis-06.txt</title></head><body>
<div>At 7:19 PM +0100 11/16/06, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Times New Roman">Wen-Cheng
Wang wrote:</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;This
change will immediately make these CAs becoming
non-compliant</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;to
RFC3280bis.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Does it?&nbsp;
I thought SHOULD&nbsp;is a recommendation.</font></blockquote>
<div><br></div>
<div>SHOULD means that an implementation is expected to provide the
indicated functionality unless there is a REALLY GOOD reason not to.
This makes it much more than a recommendation.</div>
<div><br></div>
<div><br></div>
<blockquote type="cite" cite><font face="Times New Roman">&gt;For a CA
to guide its relying parties (client applications)</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;where to
find the CA certificates, one&nbsp; id-ad-caIssuers
accessLocation</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt;is
sufficient.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">You
misunderstood my point.&nbsp; Certificate path building on the relying
parties' end is (with S/MIME as the only major exception), done by
servers.&nbsp; For servers there is no problem to fix.&nbsp; I'm
rather talking about client software that is not relying party
software, but rather<b> subscriber software</b>.&nbsp; Although some
CAs indeed not only specify and distribute such software, it is not
these guys who have a problem, it is rather the other 99% who can't
afford writing their own subscriber software.</font></blockquote>
<div><br></div>
<div>Cert path building and validation is currently assumed (by our
standards) to be performed by an RP, The rationale for creating SCVP
is precisely to allow off-loading of cert path building and/or
validation. Thus your comment above is not consistent with RFC 3280.
Also, the term &quot;subscriber&quot; appears nowhere in&nbsp; 3280,
so your reference to that term above is context-free.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1048344917==_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 kAHEXgWa060322; Fri, 17 Nov 2006 07:33:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHEXgPO060321; Fri, 17 Nov 2006 07:33:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHEXdS0060306 for <[e-mail]>; Fri, 17 Nov 2006 07:33:41 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4B3D9E0038; Fri, 17 Nov 2006 09:33:22 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Ryan Hurst <[e-mail]>, "Price, Bill" <[e-mail]>, Michael Myers <[e-mail]>, Russ Housley <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 17 Nov 2006 09:33:22 -0500
In-Reply-To: <[e-mail]> (Stefan Santesson's message of "Fri, 17 Nov 2006 12:06:34 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

    Stefan> Could we just define this error response as "Unsupported
    Stefan> request". This could describe the case where the server in
    Stefan> unable to respond to a syntactically well formed request,
    Stefan> either because it requires a non-supported response or the
    Stefan> server is unauthorized to respond.  It would provide two
    Stefan> important pieces of information

    Stefan> 1) The request was well formed, so there was no error in
    Stefan> the request; and 2) The responder can't respond to this
    Stefan> request, so there is no point in retrying the same request
    Stefan> to this responder.

    Stefan> I think this is enough information for client to
    Stefan> gracefully handle the situation and move on with other
    Stefan> available status validation options such as:

I'm not sure this is quite enough information.  I think that you need
to somehow indicate the mandatory to implement minimal response set so
clients can fall back to that when they get this error.

I.E. if I only know how to use OCSP and I get this error there should
be guidance telling me to retry without a nonce, with one cert and
without options.


Now, in the interests of moving forward, I'm willing to let this slide
especially since the lw profile gives you that guidance and especially
if we're eventually going to do a 2560bis.  2560bis would actually
need to speak to mandatory to implement behavior.



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 kAHC6gu5040579; Fri, 17 Nov 2006 05:06:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHC6gcf040578; Fri, 17 Nov 2006 05:06:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAHC6eM4040558 for <[e-mail]>; Fri, 17 Nov 2006 05:06:41 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.20; Fri, 17 Nov 2006 12:06:35 +0000
Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 17 Nov 2006 12:06:34 +0000
From: Stefan Santesson <[e-mail]>
To: Ryan Hurst <[e-mail]>, "Price, Bill" <[e-mail]>, Michael Myers <[e-mail]>, Russ Housley <[e-mail]>, Paul Hoffman <[e-mail]>, Sam Hartman <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Fri, 17 Nov 2006 12:06:34 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJo+esNnxnqaD+QBmtuZUWnhUzNAAFUyHgAANjdXAAARNdYAAc6d7g
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAHC6fM4040564
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Could we just define this error response as "Unsupported request". This could describe the case where the server in unable to respond to a syntactically well formed request, either because it requires a non-supported response or the server is unauthorized to respond.

It would provide two important pieces of information

1) The request was well formed, so there was no error in the request; and
2) The responder can't respond to this request, so there is no point in retrying the same request to this responder.

I think this is enough information for client to gracefully handle the situation and move on with other available status validation options such as:

 - Retrying with a simpler request (such as one conforming to the LW profile).
 - Trying another responder
 - Falling back to CRL validation.



Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Ryan Hurst
> Sent: den 16 november 2006 23:13
> To: Price, Bill; Michael Myers; Russ Housley; Stefan Santesson; Paul
> Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> In-line
>
> -----Original Message-----
> From: Price, Bill [mailto:[e-mail]]
> Sent: Thursday, November 16, 2006 2:01 PM
> To: Ryan Hurst; Michael Myers; Russ Housley; Stefan Santesson; Paul
> Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> I too would like to see a small modification made to the specs to
> better explain the error code. However, I think the proposals are "off
> the mark." The error message in both its "sound bite" title and the
> proposed expanded descriptions sound like there's an error at the
> responder (server). The user of a client that got such an error would
> likely look for problems at the responder.
>
> The most likely cause of the "unauthorized" error is an ill-conceived
> but syntactically correct request that asks for the status either of a
> certificate from a non-supported CA or of an expired or yet-to-be
> issued certificate. (The case where a presigned responder didn't have a
> presigned response available.) This situation may seem unlikely but it
> has happened because of misconfiguration or bugs in homegrown clients.
> [rmh] Bill this is just once case, what if a client includes a
> unsupported extension if the responder was keyed but proxying the
> request to a authoritative responder with the intent to re-sign but the
> proxy server was not available, or if the client included a unsupported
> identifier (byKey vs byname) there are lots of cases where a server is
> not able to provide a authoritative responses.
>
>
> I'd recommend some words that the error "can occur when a keyless
> responder does not have a presigned response available."  A few words
> more could explain that a request as described above would provoke the
> unauthorized response.
> [rmh] It needs to be more generic than that unfortunaltey.
>
> I recommend fixing the description to be user friendly so that people
> who encounter the error know quickly why it happened and where to look
> to fix it.
> [rmh] This is something implementations should deal with as part of
> their debugging tools, documentation and logging.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Ryan Hurst
> Sent: Thursday, November 16, 2006 2:57 PM
> To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
> Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> If that were possible this would be the text I would propose:
>
> The response "unauthorized" is returned in cases where the client is
> not
> authorized to request a response or the server is not capable of
> responding authoritatively.
>
> Ryan
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Michael Myers
> Sent: Thursday, November 16, 2006 6:35 AM
> To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Maybe what makes the most sense is to update 2560 with this definition
> since
> 2560 is normatively referenced in other RFCs.  I'm not talking BIS,
> just
> a
> quick sentence or two.
>
> Mike
>
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, November 15, 2006 8:03 PM
> To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Mike:
>
> >The LW OCSP I-D does not nor is intended to
> >update, redefine, obsolete or otherwise diminish
> >2560 as the base document defining OCSP.
>
> At a minimum, it needs update RFC 2560 to explain the ways that the
> "unauthorized" error code is used.
>
> 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 kAHBpPVV038709; Fri, 17 Nov 2006 04:51:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHBpP0F038708; Fri, 17 Nov 2006 04:51:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAHBpNsm038688 for <[e-mail]>; Fri, 17 Nov 2006 04:51:24 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.20; Fri, 17 Nov 2006 11:51:14 +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, 17 Nov 2006 11:51:14 +0000
From: Stefan Santesson <[e-mail]>
To: Michael Myers <[e-mail]>, Russ Housley <[e-mail]>, Paul Hoffman <[e-mail]>, Sam Hartman <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Fri, 17 Nov 2006 11:51:14 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJkaU5LEgWujQZQiCDaQO+YHkGlgArAXjA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAHBpOsm038703
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

I'm not sure which one is best, but we have two options as you say;

1) Update RFC 2560 in the Lightweight (LW) profile, thus making the LW profile a standards document.
2) Creating a separate standards track document, updating just this error code and keep the LW profile as informational.

Sam, can you give any guidance on what you think is most appropriate from your perspective?
If the WG chooses option 2) can the LW document and the update document progress together?

I suppose both options are valid, also considering that many documents reference 2560.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: den 16 november 2006 15:35
> To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Maybe what makes the most sense is to update 2560 with this definition
> since
> 2560 is normatively referenced in other RFCs.  I'm not talking BIS,
> just a
> quick sentence or two.
>
> Mike
>
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, November 15, 2006 8:03 PM
> To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> Mike:
>
> >The LW OCSP I-D does not nor is intended to
> >update, redefine, obsolete or otherwise diminish
> >2560 as the base document defining OCSP.
>
> At a minimum, it needs update RFC 2560 to explain the ways that the
> "unauthorized" error code is used.
>
> Russ




Received: from node-be0283fa.scarlet.an (node-be0283fa.scarlet.an [190.2.131.250]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGN2MGU034744 for <[e-mail]>; Thu, 16 Nov 2006 16:02:23 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c709d3$4572cf50$00000000@vries>
From: "Berlin" <[e-mail]>
To: [e-mail]
Subject: same jumping impress
Date: 	Thu, 16 Nov 2006 19:02:21 -0400
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C709B1.BE612F50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0009_01C709B1.BE612F50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C709B1.BE612F50"


------=_NextPart_001_000A_01C709B1.BE612F50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Elements execution Parkour Yoga Bossaball dressage etc.
Links linkcite articlein bokmlnorsk of last November!
My favourite would. Had close connection warfare skills Among originate =
am.
Aspect together in spread led resulted conflict where is paycheck can =
in. Objects is normal is use pleasing of car doesnt impresses us. You a =
won lost how a played game am creed of.
Sister projects Dictionary Wiktionary Textbooks.
Been popular of Chinas ancient past a Monuments Pharaohs. Pursuits =
various forms different.
Connected cultural Until mid person could in.
Reporting compete national teams audiences or. Keep running Sportfrom to =
navigation searchthis page.
Equipments grown am need in better. Further reading References alsoedit. =
In reference biological mutation see mutant Sports redirects! Equipments =
grown am need in better.
Elevated am celebrity or statusedit Politicsat in. Specific my =
favourite!
Others or may a prolonged.
Both poetry sculpture role whether applied a health technique am. =
Speakers is whereas enjoy less.
Influenced one another became a prominent part their.
Purposes get places we.
Greatly understand what doing improve!
Links linkcite articlein bokmlnorsk of last November! Olympics up =
present has brought. Important thing taking typical often.
Held every four small of village is called organized or.
Important thing taking typical often.
Toward teammates or opponents is ethical.
------=_NextPart_001_000A_01C709B1.BE612F50
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Summer" hspace=3D0=20
src=3D"cid:000801c709d3$4572cf50$00000000@vries" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Elements execution =
Parkour Yoga=20
Bossaball dressage etc.<BR>Links linkcite articlein bokmlnorsk of last=20
November!<BR>My favourite would. Had close connection warfare skills =
Among=20
originate am.<BR>Aspect together in spread led resulted conflict where =
is=20
paycheck can in. Objects is normal is use pleasing of car doesnt =
impresses us.=20
You a won lost how a played game am creed of.<BR>Sister projects =
Dictionary=20
Wiktionary Textbooks.<BR>Been popular of Chinas ancient past a Monuments =

Pharaohs. Pursuits various forms different.<BR>Connected cultural Until =
mid=20
person could in.<BR>Reporting compete national teams audiences or. Keep =
running=20
Sportfrom to navigation searchthis page.<BR>Equipments grown am need in =
better.=20
Further reading References alsoedit. In reference biological mutation =
see mutant=20
Sports redirects! Equipments grown am need in better.<BR>Elevated am =
celebrity=20
or statusedit Politicsat in. Specific my favourite!<BR>Others or may a=20
prolonged.<BR>Both poetry sculpture role whether applied a health =
technique am.=20
Speakers is whereas enjoy less.<BR>Influenced one another became a =
prominent=20
part their.<BR>Purposes get places we.<BR>Greatly understand what doing=20
improve!<BR>Links linkcite articlein bokmlnorsk of last November! =
Olympics up=20
present has brought. Important thing taking typical often.<BR>Held every =
four=20
small of village is called organized or.<BR>Important thing taking =
typical=20
often.<BR>Toward teammates or opponents is =
ethical.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C709B1.BE612F50--

------=_NextPart_000_0009_01C709B1.BE612F50
Content-Type: image/gif;
	name="jump.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c709d3$4572cf50$00000000@vries>

R0lGODlh8AEgAof2AAAAAHoAAAGCC3+IBg0Ae44CcwF0ecXCwbjNt5jE+TwiDW0nBYYdAKkrAMcc
AN0XAwBKCC47DTFGAGI3AIIyDZdDALhIANREBwBuACVpBDVdAGRWDolSBpNTALpXANRdAgB0CC2L
AEGMBGF9CXeOAKp4A812DNp+AACiCR2pAEujCFmVAYeVA6yqALekAOGpCwDADijCBUPFCWW7AIPD
AafICc6yAOq4AAzRAibnBDzpAGzVAH3iAJjuBMjTANHmBQwARxYDRT0JOGsKNIoASpoAN7EIResA
RAIuPhwkNEYiSmcnR4YkRpYjNsUkPtkcQAVAMhk9M0xITV9LQI0/Tq41SbJENtQ4OgBjNSZiOzZs
M2VhPXtVEZ1oM7NhSeNRSgCHRBF7NUh1TlGAPXuNQJuKO8J0S+CMNwCUOBSYMj2fS1qaM3eVQaKo
QsCdNt2pNADONR22N0PHTlPNPYG8S6K3M8K2QNW+OgDmMxLlMkDqOmbsP3HmP53TSrXdM9XUOAgA
jSoFhU0AiVQCeoIAdaMAf8IGjdIBgQAdcSUhjk0uilMjh4ooc5cihsQrjdQbigAyfyA3iDo9cVU2
e4c+eqVHecZEiu0+egRoeS1teEdbcmlrgIZtjZRYhL9aiNVVgwd/dB93eTeDfmeHfo6OdpyKc8t/
ddV2hAeodRGqiEGdjlOje3abdpurfMWsg+afgQDJfBrJfTvLimbHgn7Og5bEd8a9hdnEgwDmcyHn
iUHpi2nUcYfceaTaibbod9ziewoHyhMAw0IAulEAtnkHvKMJwsMIxtUAwwAowi4SxkYnxFwXyYQg
vp0bysUYwOwTxQA/uSw2vE46zl9BuI1DvqIywcs4wOM7xABSvytpyElYwGBby3pWu5dRtstYt+tV
wAB+xxaHs0yEv2OKyoqKyamFwcl6zNmKxgCZyRmatT2hvlKgwYiiva2bzrygvOKdvQC2wyvCyDax
w2HLu424yZK4s//2+ZqjlYOGcv8AAA35C//8AAEA//YI8Avx///w/yH5BACs9DkALAAAAADwASAC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2B9nLq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qlWp/65q3cq1q9evYMOK
HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27Om/q3cu3r9+/gDniHUy4sOHDiLcGXsy4sePHkEUmngyX
FOXLmDNr3jyUC+fPoEOLHk26tOnTqFOrBrtgteZkWCPLnk27tm2/PtG43s2bKrLepG8LH068uPGM
wJMrX868ufPn0F0fn069uvXb0bNr3x40Fvfv4MOL/78otOFd87EXnmc4FX1d9z+vOy7P3i78p/fl
5m+6H27/vPKpJN6ABIoFAADgkRfUf24xmJSDbEF4lIRqOUjRgQAEOFGBHHboFYYeDnWgPSMa9cGJ
KKaIYk8qnshiiysK5SJTI5YYVI0IGiXAjjz2yGNPPu4IZJA/CiUkjQjaCBSOR/Hj5JNQPtlTlE5O
SaWUQlWJJIk5SqVkiDwxaeKMMcaok5lm7oTmjD+lmZSYNybZJVFF1nmkTkXak+dOee45pABNwbmk
nE1qiSWWOiGK6E6KavnTom8SWhWIYIb55VBlksmmPW5y+sGLn565KU+dIkWpiJcaeaSdgOJ5p6t/
8v/5Kk9+RjpnnLcOdaihjtoDqa/8WBlsor3y9KupqU51aocYNpvsi6KG6mm0PrmZZqmeYiuUs83+
xO2yQd3ZZ6t6zpqTn3vWem6PSn2brLu5PjossPM6eiykix5Lb7FFwctVvEOd8By4SGE7qprS5nTt
wQqnGOizlgLcUwU+qVsuULOma+66FvcL8U4EFzqvsSOTTPLI+kb5sMSVTiqpUqVqu3DCDDesLapc
4vxxuBt3rDG5F//k45Y7C4rUvfwSi3KvSeek8lJGWyVMy1GPmTC1bW6aac2aXm1U1ZbmvJS6Pr/K
KtCycgz1y4OKrRTSJTPKNK9N07222y3XFXPN2SL/rGJQXeNF9sZquzo0xq12/BbcQOVLZVB2n2ZJ
YgoCdd/eXmNtc7aZN2yztBQWdd/gaMsK9I/sCp14nqETdR/j8i4dLJSND0t7ThZqGBh96vldLd8z
b/47jAD2HtXoPRNe7umrEk7kna0P9XrS+tIrt+11Xzlv7rqb1JbBnU/ru/Ck0sy3WxYrn7G4yZt+
V8pxE3uy0j7NHX/en4GfubVsOowwqHZJX/LQNq71xaou8Isfvuy1QGHhjzQyG1Wngve/8oWvLWUj
oLl+RqvSKY4t1Vtg3BxXMn5Vbyq5eKBZbram/Umwfwfz31wUV8CKrY9ctUrdXE7YKAUWq4fCup8K
/5lSufjUh3MR/JsFZQgj/8GoINc4SHuOSCTEHc50Onze2XgUPd4pRGm3q9/jThZG7e0qStzrXl+8
mJD1GA8qXSxLHC13RLqkUY17YSNC3PjF9PTxPXXETyD1M0ie4LEkQ0ykIrlTRJ/McSyPdGQh/TPJ
pUQyLHc85EcWyclOMkeToAylKBczj1Ga8pSoTKUqV8nKVqoRB66MpSxnmUfwgMOThSEALnfDgF36
8pdfeQkDGEDLlyCimMhc5TCTycxmOlMjy3ymNKdJHGBa85qaoaY2t8nNbkZGDt4MpzjHSc5ymvOc
6BwlNtfJTsOk853wjOdweiFPbRpBje3Mpz73yf/PfvrznwAN6HZmINC7+KCgPamnQhfK0IbuZQQO
jahEJ5pMhFr0ohjNqEa5QtGOevSjIA2pSEdK0pKa9KQoTalKV8rSlqpyozCNqUxnStOa2rSgjQRT
Jdm5s4HNaY1Q2YRQhVqYoeqEqHBxl06ctVSmhs1b3+KSU6VaIiXhqEs2mmqqppoTp3YrqlSFWFa7
1VWwhtUnWiUrWs2aVrU2dVtq5WpPK2SRnCDVHne9i1Htugk5CmQJeyzrU8U21sG27a09KaxV5YTV
HBUWb4KNrNuq6thcLRaqiIXslx4LsspG9mObbaxkQxsnxFK2s7gzDl77+pOh3tW1fd3ral27E9j/
HtW2fL1ta/f6Wtry1aiynW1e82pI410WtZylKlxRa9jM5oysRovurcB22uYelrTOLZpnCTsn7EpW
sMl1K3PfWt3IArUpxNVtbmfLXqTylrU8ca9817va3c63J/KNLVHvW1/6bsm5zxVtU0HbXcvG67LQ
ZVuAm0vd7Y63tN/F23EhXN0Jf5e04Q2ZZiXl3dCkl773DTF8P8zf3vbXJ/vVL4pZK2IQwzcqFg6w
W8u71s4ydatRZZJ0Nxy2d1XWq1wdb4djvNYEizexBe6xXB38YBmDa65nIc+HT9zi/pr4t+9Vb32n
bGXZwpbFYF7vl1+8IOMmGbkKpjGSmwzZC3MY/0QYnq6cuVthlkV4tHPOrp0n+zKxnpm8aWYygOF0
2fMyZcpXrnKiRxxmF58Yv2AucaOrfJUYi2mxR37wpXCM5rLuuMMLNq2ga7zmCFtYu4AGsGHj7OZM
s9rNgKyIo6k86Vqrd9FaZi9QetvoLou511eW5B+9W14aP4vIfJZwn4s9as4+Vs3KJjWeGSxgIS97
0HnmrqiZ62wHF5ovUcEtlhn963G/+Muz/m1QeH1b31Ja3I++W8QyHG3MDjiuCe60p+/dWHw/+cZw
5panNaxsgm3a1UCecbb5red6Y3qsCrdPXa3C5aRUvEFv1CeUoVOi41zl4kcBeYQyrvE9R8dGhv9m
i8iJsvKblmXjy4F5lCeOmp2Kro1dcelHVWNz1+GcozoPp8uHTvSPk1koLS+60ikpa+EmfbchP/pV
ei69hPTj6li/uk6y3o+tc70nWi9e0Ln5lOFKPepoN03Yvc52e6x97TmBO3fYsXSfyxrR5Ha6rp1+
bt/SWitU1yNB2h73ru9E6283fOHXPnaKxlvL+W1vpMtN+cf7MbD8+Tnc5Y54xW8e62JfaQs6au7a
qpjykp7104lI8gdpXvFuh33sY5/1wxs+7I2f6Ip1i2tfV56/QP8j6zH/eZ50fva2L3xqc6/Nqpi4
96n/u+VBU/zkh/3ztT/NF+oefIo82ux9R33/3ns/fTi2Hil/5Lznb79+5bOd+dsMKrz37vv8Blfc
wf6M3GmfeOvDfv8hgg1El1O7hxmBV2aYpxjwR01dsXrc94BnUQiI4YAQWIEWeIEYOHzeRxYHSEgJ
uB0L6BIZOIItQ4C7dnauJ3yH0UcQAAFj0YJzAYOhF4IoUXbzN0QyqBMtuIM/sYM56IMuCBQwmIP2
MIRA2IM+iIQ8mBM/GIRF6IRESIJzkX8qBIQu2IQ9gYVY6BMySIRGqINOCIZiyBNbuIVPuBNRKIVW
IWXjR1u8Bn5mN4MGQRkKkYRjeIZkCIVXqIdIyIRh+IV+mIV8mIdjaIZeGIQ0OB+L1oa3lncn/9aB
cVGHSxiIlIiGfGiGlniHZ4iJlZiGZTiIeCiGibgSNtiIpudfkIeCvDGJoeiJg3iEXAiKmwiLhFiJ
ljiJhhiGoaiGa1hX6OZfwNdufldcKuhOOGeHnOiHSZiMrfiHeygUyfiJdxiFMDiKAuIUJBZ+lkeB
qfGFzJiJzIiJgCiEstiJulgUaciLKid1cSh9wcaNnOGNr3iOXViOtliPthiLhRiE0miOtaiOVcGG
Behi9zeMdwWJTHcQVgiGuKiHh8iK//iE33iLudiQ0+iMy7cQmWCNMeFXxVgYLHiOW5GOcCGDHLk7
HHh+gxGSYkGSbZGDJwkYHvlziPGRYOGSav9BhDH5F9oxSTZpRMKhDRAxBvBECqvUk+f3k8JmG0K5
kzYBkHahDVC5G/DoGvmQD6ohlVNpFgryiyynilHnlVpRcT6Jc1f5E2dpD8PRlE5pG6hYFFUJaWBB
lknZRld5l1ipE3eZkbXBlm0pE/JnFF6Jf44IdfHld7g1mIi5mFqBlz3hmFvZTytHhb8HlhUXearn
iMQVl0ABmXqJlWkZmacRBN23IXpXetJ3mLwHluXne5mZighIkzvxRXv5mTmRln+5c6p5gqnImCCX
Xr/Yjl1GmLH5gXKIE/YAmXi5l7npUXLJm5W5mkOxmYwIm9NHlzbZR2cZmreZlyoxCs3pSqn/WYBZ
BowiR52m2IjAVpiPWJeBtZ15aZtqGZ7dJH/BZV9eBm/3aZim525kppj3mZ+NuZyPGZ+iqVM0xxWc
mXaZl51maaBASZ8O9RULKpisWXUO+p4QupS2QQ8SKoJ0UaFIN4wHWqImeqIomqIquqLclxUjKKKT
4Vg3wqKxtoGnKRaXCX5IkXTYSZMKMV1OkWkg01VEmlgJZRHx8KHXiI3s6RU52ncXeooW2hVAGihL
NaMkgqU06mFnt4gp9l75uZj7iWVkOm7CeHpvyGgCqixhMnBEWiNXOqRF2l1zOqdVJVVbyhl4p57t
Zp3l2Zr+mY3qllvvyJ4wmqV1eqVZFaeM/yqjceqoSaKoWJWnmrGnlfd91TmecumG7NhrwiWlmlpp
jzqkQGpglEKniCqjVVqklHoZluqamJqYmqmKX3p6fGee/6mYXxGpAwenpGqkiiqnkLpviMqqrYoW
DTEJbfSqwCecoEqZUvpunmqQXaqKddRHvFqsjPqmwMqto5qqbUqnKJUOoBSY4jet2uia0Jqe0ReH
hZprrWml25qt2zqvxXqn4DqpqHqsrkqt/gmqZppu9AewBPmn6kqiazop82asDNurAwauEHuqcsqv
FCuvFXuxuwovGruxHNuxGjsZESCFJhge1yqbR2Fyvaik1sFJJWuckaiyjCELCDkgLStFEv8Hs9ix
SDU7hzeLs7VBGqu3oDtbEHzks7Nxq5XKmofKlzbLtIP3NL5yFWFkd0Z7tOt6GL8ZpSnoowlRQk4j
tYliFNo0DY5XqAV5tmm6d7aFtmrKtm37tgX7tuk6tAThQ1JCN7ZjPU4ztVH7tX37tfUyn1XbkUya
ngebmfqFpl96uLoWfbuJqYgrsFBxP9gTtmFrL3+buX+bt5druRg7hetpuM9qa/VHuowLrfnXrk1K
FVDLuX4LuIySuSV0OygDu59bmhJxo3znqX5KuooWnJmapoWpuvB6nINnvC4au31bu53bvK/7vLOj
vNEruAcxB4Mrk45LsK9ZuuI3kMQrsN//O310i5zSC72xW7vM67lRy7zTe72Ei17BG7ru6Lv0a7gi
Jr+QO7/WKRVeu7zKa7sA/EPnKz/Pe7v2oA8BmRBowB7tqJ/+Cn31G7CpCaBnG7f7e5Bv9EVQq7dg
ZL7WM7tAFLhO674pcbFCpCsGXLFmtMIs3MIufCUpHMNMwbdNIsNGQQToR8I67HE23MMzucNA7JYq
VDo+7ElBfMRCXMRKvMRM3MRO/BxIHMWy8cRUfHlSfMUyWcVavMVcLBZY/MWrdAFgPMZkXMaR0cVo
nMZqfDxm3MaAucZwfKRufL1YMMd2HEtxnMcAhbJ6/MR83Meg0VEZcseEjBAy8BGDXMgW/zEMiswQ
idzIkOwRj6xG8BDJlnzJmJzJKVcaiQDIAjWyJKjJPLmVMDsLwuHJMTULs/AdTUMarVwUr5wY6ACB
q/wZlTM3TkE9MMy/uwzLJ0wUsSxGM3xCGNqcpoxKBLy3uXzCwdwUzWwlyzwWz0xHxvxS+wJGDLQr
8rPBckNG2HNGr/xDZUQ7YzRG+1Iv35zN2nzOHSzM54zOjTLCJ3nMqbS32azMDAQsBBzOS7PN2VM7
3YzPICzQlZvP+pzPBl0lCF250Ky3Cu1D8jyKqsxK+lzRC+3P+8zM/SzQAC0vAX3Qs4vRHK3MIC3S
Fj076FzRHX3RxTnPKxvNJ23SD53RkP+z0SV9PSEkO+Qc0iN90zHN0j9dzvBD0j69lbXMHUIt0yhN
0x1N1DOdzK2Myybz0U/t07yi0lV91fzszkA9lUe9HbgM1E+9zh4N1Uud0UIk1UWN1Wdt1QWd0pGT
1Wety07d1h+dxzGwFmHduuPc12WNzURtzzntzYAt1umc0uws2Fed2NccRGyt2MmMymo4zZJtRxbx
wpid2Zq92Zzd2Z792aDdwqKMSBrFzZV92qid2qqtFLwAHizzx1p6GbD9JqL6FLN9UxcRZF8TKfVK
20sCYwbS27Q9qVtBr8Bt2ydrxfAEFbf9MMKd3L/N3MFNFcStFc0tItJ9rAWmqsT6qKH/Vap26qip
CnE/trDdfarkHTHEGqn+5q3ozavvXaXcHXAH92Om6qZZylj9pt4Ql6gS+6b/hq/jzd6nUuCUdd0B
Vd0Kpq3G3a357a0PzrDZuqr3Gq4TO+ETW+ECjuGbpuHBaqzDiuENC+H7yuERfuKoKt7cKt4mDuIf
fuIo7uHP3U4KouAMviwLrlyjqt/c7abEPWPeTWhfZa+NWuEkfuO+GuPV/eDsbeTaqlxLrq/ByuFA
HrEBx3BS7uJHvqj6+lXVNpssxapZ7uT3WuLCCuPu/eIiLuZOnuRsTuQxvuVFPuZrzuR2/uZsHuVq
fudo/q0mruIyzuB7Dl6Bbm3EqFJ4/77m+yroWv5cRZ7ngw7pLk7nGU7pci7pSl6vP97mF07mlN7k
R+7nMt7icY7pdErqi+6oDJXd621jp17fJV7e8xrf+F3rXr7ftb7eG27gKp5vsr7kRu5ZwD7kEr7h
fC7rog7lktpv+m3eUH6nP37g573aY4HgIWLtRQfKYILtzIJxCkXtVazt4E5XusembcHtqEHh1g0W
Jidzk3EBjGQRN9amZ4Hu041W/QI1Fg7s24LdGT7iDu4t/w7w7TLjERp0eL4W9h4WC28q9P7ku93v
Eo/cE0/xSsF8Yv7fOM7r/t3dEa7x/a3rcrZsLK7eeKrj7w3gx6bjNnZvPo6nvx7gHv+P8vuW8ndu
868u7SdP4CRf8yKfKxjP6Q0e6PAN4dw25ZrO6IwO6HVu5mP+q/we6kb66UTv6Y8O6WYO4Eb/q3tu
4/jK9FUP7EHv9W3W5XBm5x3usDzu48ye4uHd43BO6soe9aX+8nJO9Y2u5ytu45fu8qce6SIOqWff
97dCehZP506/72Xe6Vx/9W5+5nFu3Ikv9aAO8VIf9khP+Iyv9BOu6IX+9Kg+6HAf+nRPdGQf98Ge
9I6f6ZNO5KPf25Nf6pUP9nrP+sde9as/542P95hu+5b++rwP6MlRC5pB9k8W5I9+/A874H4f8ske
V0XW6nb68pu+++ZtZPCd/SXPbZv/NeXPZuw7P/h9v/PPj97Mn/oAJe6r0fD5XlM5Yvh5w/7+TlPy
P+723xvqf//GWJ9BWv9PDhAA7A0kWJCgQIMJFS5k2NDhQ4gJEUakWNHiRYwRJw7cmNEjxY4fRY4k
WRLjP5QpVa5kiTKkSY4GX0osOBOiTZsZc8oE0FPgTow4YdoDOvSgzJFFL07cObHlU6hRpU6lWtXq
1aoilXrsWHSrQ6EwvxI9OjSsybFokRolyRQsW7hx5Q7EytInx54xf8YkSzQvWYQ+u+Jl+jcw4LuE
u+ZN3Njw45+FAzuenFOy5IOQJTLW7LcyYb+ZK3/2XJOzaL59UStmvbc06Nd8Kasm/x27tODVd+vu
5t3b92+WWssilp1a72HjgI+6de1aufGNL50zL05d7/CGbq9vTx29psLpy6uL5y69+HftNK0Tp63a
PXno8J1/74407Vz8+c0OD793dPvj/JMvtPIAxAs73C5rLkDG5AMqvcju+suzCQl0L0HRGuwrQg2f
s7As5HDzMMP21hMssszUK4w/ClFcC0AM9ZNxxvwgLFE5E7HzsL8Nb0wuNBvTO28+H1NkKEjwiOTJ
wPDoO2ww7g4EscARi+TxRwsrXPHA9Uyjz8r3aBRzTHt+Q5JFMJO78jkBqbSPxTOfHDAk5F7McUD1
4NSzxxzpdNJNPwu888IvCZ0Twf8v+yQIOEYbdfRR36IzLFESJa1wwwkbS1E7EWEjUMTOQoSN0wh1
rE+2zmyLDbLJRh1yUlRVFZVCU2m1NcZRUw3QU1B15RJEx8qEdFhii4WUzP2QVXZZo+5jNi5jo5V2
2qye1elSa7PV9iFntzWJWnDDtcpbcss191x001V3XXbbdfddeOOVd6HfdNIPW7i6nRddfdd9SVyA
Ax72vm69MhCk7GgS8yxKkw3zyLj6tUjIuf4V+GKMebMXP33HkjioieUiOOIZP15KoYxTVnkqDk/V
lFQ6NUzwZZlDnU28z0LEt8TEXnvZ50l7bS7TnVflzL/Tcq2tZ6Uv4wmz25ZLWmj/TP/z9Daob/1r
Za67TmlNHgclVNEu0YPPyPkWTFhQSmF9U9EowTvbujoBfdhsN99EdDs52fZ7rbp3bM9rwhkVjtMe
+a5aS7hxPJvWsnk28kOFBbe0w8stl1pCy2beU2fMPd8M84Mh39LHvjUXNFDQ++t0X9gXalJtNhOX
vU3Nu2wcTSAvnGl3KJlUvUopK/eS7r+l8y75hrO8MnWwmVwe+iJjR9dM4euzEUvcw577UDvxnj58
3fG8sfHxm1ed+u3jY573scljH3xDhwTTrcLzv7hJ3+u09GlUkW52rILR8hDjv57FjHRAqxsBB1g1
Xo2OV21qnZRuZpoFvs50S5NQ/3USODT/yepVBHyN/kyIlX2ZrGLxUqH1CuVCGMKlXmRimrlaWLIY
OsxbJ+ThtHL4QyAGsYdDNGEQjXhE2BFRicMSDhJL8rEbvud3XqIcspS0JCdmkV1RXBi3pqiRttxt
Y7VyHJaa+JY8QcxbXNTiFmH3oC/eJIwtDF74zPiRgolRj1Zs47zMpCnoJI2BWaMa1nJzQYVhpoMB
jA8Hw+arm9GthhjiHGnSJshIBg2CZewfmzSDrUU6DoSsKc0STbkysc3KfMwT1e7kZrvszS2EBuze
K7WHs71xMkhQChz/XDSYWvJnludxH3vctqZTJhNjiONlAAcowBg9CVdX/FP9YP+Wtgy56HyTy6X3
ihnMFoVpVtOcZmv4ZEfUFTNN4VyPMt05LGpEhZmAYyX97Bc8aiqmQ8IrH/e8yU1abvObglNTIt+3
pzISqX1qM+A68amadyozEeFq35SGFz3kXbR+jWzemmKZO+MFlDpCGinvlNRK82G0dLFkaKEG1biI
xnQqWmEa65xZQBICEnQu66WTHkNKXHXSaDVTFQMrRcqjktRtFrVaqIDVIIodTKdqciCCjlm8Pmb1
hfnSale54lWwuouNVwtrWddmVrSmVa1rZWtb3fpWuMZVrlk1WFLOWLGxVqRzZNSh7OZq1gfxNYxg
bMocQQLIFSIMLBrklho5+cT/lZ7qr3HN6xjPisc9tq1GegXjyfy6VbWYMaqTZZcLbqdJoE2wVJb8
4GJSd8BP/Wyo3nHk+Xz1OaJBbZKbjKRQaxjIvk2ScQJqGVC1NJ5KutZWRXXrNZzrXLFKzWXVQ9/D
mAPM8Vwnemj7nnYFK1ApWpOKL6VcRSWrTfjpSaUG1WU3V/nX58b3GnLBnt0OuM/qgvJxtQPpiaSa
zSzhEqujkyZltOlfYYbSv4Fa6ZmQql/v9slPxP3oLnUj05Q9l1hn9GXcRJrSD+ttfgp172bAO2Ad
kbg71KRYiysXVQe3+MPb/RCFO2zSzJKWXyn92/1yWT3F9XeVFf2nRVO8ToKe/5efLzZVjJusWRqH
N7v/veUddWxDxK5Ktb/y2eYkKM7EFXeUSPVtboem5Rc6slRk/Z9vk0RW4AI3a7d85pob1ioZ4/TK
7/pKZSG759j5GdDW24qgBztoeP0W0YtmdKMd/WhIR1rSk95WHulq6Hth+rCUNkq9GMvZ0doVwGjM
l6I5e9nGwpDBmO0saG1JEQwT7q6iJtl3X9Sscml6s2wptPFQ/awKZLW+GERNSVe7ZWIv93UPxVpu
H4xI634yZzuN2iAB2GXlAvC6v8SkJmVcG9iSENtG1VqbW0vuUcbaa0m5qkjnF7c0JlnZsHRxdZ8c
5JZik34BPY5jxYtSWBrTvf8TnrLruAdk64q33znmNKiDml/RPS3K5hko5Oa0bCYDXE5E23dHo824
z+HbnI+LXL47flR4Z47fO9I1oFVc5eFREeb8S/hA8/tZzZ5T587TKI4ZHLN08tejLz9pmH2s5JIj
dMkybzhm+6lRkuZc3gT/d8ddnPPgRom2SHZwev2W9ZiDOeVGt/fRPb7yok/6j85uWgF5C0oFk3nB
T8VpneFc7nsi16ldVmeWSbQai+u8gnXMTRoLrNvxxr3GGGStq2CzElSoG2NNZziio9hyypNkhm41
daQvn0TJryzzoyd96U1/etTPaPOVt+wef4rDI42V8DhntKVhEvqUcZjUrbf/jK1/hGDFvprXt/a3
7X1Nay92PrT+Jn7qa+36Wffeyq4eGe2H7+rmtx772t+9yLq/fecXZO3KhuTePXmp2VywkiFFrXDN
7e0R8m23Q9W7mbVtM9YeOKe3dWn70b85pxm33tok2+iUxMC9jNG9glo1siGjGxuROLouJptAgQu4
XzqyBuw5deIxgNPAs5LAW7u5hTMP2rkisXG0YbsmsZs5eQs82ng4nNOdD6JA7/kPC4O6sgswlGMn
D4q703EsGTwuViqnSlGQKsqRU/IEBPwHJ2PAQ4k6+/qxs0svIfSxWjIvlXo3ceqwq3stICuapaMy
qEOnkoo2qROIJUymJgyp/yccOJ+jPoSCsSlEE/LCm/XxQA4MuTGkJxqsMKvjMcWBQhZMw1PqnZsq
r1SJJvejuXM7wmTLHDZ7xI4KpeViJMczxMVJtth6vaniLWBBsxBcKg0iwkKSlJGDLRGyREI0pfBT
FswDtFUEmFYUKzCcxaZbPVvMRReKRVnURV+0Hl4UF197RRohxkyTGz9LCxXaGWMUPpEIxqvoq3xS
n1T7MzmaPpCxPuRzxv1iPlJTRm78vqvjo4bDRSm7Rs/qImxMx+ObtXaEN2sEx3f8tVAjx5KAxnGh
qabKRKPKv2zbLUuSn/IrLvorqvVDN2k7JPx7RP8bp/v6O9AwQLhbSIPUlf/kssRnc8gC9MSCJLeG
a8B6Ozkl4y62Wbkw1LeNIkE9XK+a26aMusISmzoMhJ+kozNbeh54bLfSQclmRCKQfCqWRLtEARU+
MUKfizjg08FTnLui9EFuQjohg8mKuy9+I6ea2i8kgTCqFCVH1KetNJ1R47SfrKe8IbInQ6C76bpN
yQ4uPLKdgzmsykqXbC9BjBwWDLWatJIQw6UfDMlJZL2ySsG5JEuZlCyWQpS6HLLIassq08K0g8rZ
mZJUisMz9MOxg8u9DCGXUi/FRBxhwceZ0keg4sde4UgpAjeh0h62Ox6668gJMi7HozZSSUVXWRrJ
BMolgRkCg82KDBwuw5H//8NI3ew/atsgwOtJczHHVvtFZkHOtKIWEGBFGVE+5sw056xO7MxO7cyP
E7AW0PxO8AxP8fSh7SxP8zxP9ExPZRlP9uTFSmhP+Nw8XFBP+qzPhIhP/MxP/dxP/uxP//xPbVgi
+xxQAv3M/zxQBE1QHipQBm1QB31QXVRQCZ1QCk1ACL1QDM1QDT01tqpQD/3Q/QFRER1REsUKAChR
FE1RFXWJFW1RF6XQE31RGZ1RGo21Db1R56tRHd1RHu1RH/1RYcRRIS09IC3SlUkGI1XOIV1SSUtS
J31SAWVSKZ1SKq1SK73SC0UCLN1SLjWiWOhSMA1TMR1TMiVQJS3TKV1C/wKFBEhoRTZF04R404GQ
U3t4Uzqt0za90zvFUzZt0zn10z/F04LY0z4tVEA1VIIwVEBN1EXl00b900I1CESFVEYNVEXdU0c9
1EW1001t1Ei91Ef9VEWN006FVDrV01CdVEbt01WtVEEFVVKVVFY91TwdVVmN1Ez1VFzN1VrlVFvF
1Bj6DVqtVFQNVEGVVWMt1mMFVmN11WXVVGR1VUwd1maVU1ZN1lJdCGv1U2XdVoUg1EcdVG4N12j1
VmwV11itVmjlU2nN1m9N1XM9VoYYVmqVV3ONVmc1VpYggvbcVm/t1nFN13t91mZN14J91XU11Xc1
WIRFVlwdWGYlWHmVWP9gBdeGGFhtDViLVVZ0JVZdddR4PdiO7VhOzdeFtdR13dhwtdiOVdOP8FeN
ddddJdmAddaZZViVzdebnVidrVWHvVZmjVhz5didPdiIlViHeNiP5die5VlfrVmGxdd2ZdqTbdiQ
RdmqNVpy3UXfQNiS5VV3vVWgDdujnViVnVmIJddizdmvjVpxVdqR5dm4lVuaVVWDzVmTNVufRdeS
DdqtndZx1VW7NVWYrVeUnVSWdVX+BFnGZVq/9di4LVuq7duPtde/LVW8LVq6VVe9ndu5PVqMndeE
xdq8XdulDVy1vVyBvVaRlVrS1Vq6TVx9RcCRUNq09VzOddytLdjM7VT/zcXZvYVcxnVbmw3ezs1Y
1y3X3R1ZvBVZ0/1Zhc3a5P3X0ZVepG3ez13eH6oX24Xa473bmpVd6aVW8s1WoU3Y8m1V6y3eq91c
p93d0EVe9m1fzq1fWk1d0V1d+p1e9E3Zla1cxaXd2pVZsk1dtGXdvOVf1n3edhXdm1XV+5Xfdz1g
wM1Yqn1b471YwQVXv33gXY3g9SXcXg3ep0Vg5yXgBU7VydVedWEFOH1hGI5hGZ5hGq5hG75hHM5h
Hd5hHu5hBoVV0y3cy01haL1UUhViB0ZVIu7V4jVhEb5f0KXgDkbUIDZhCEbh2xVbUeVbW8VgDv5i
TUVcFq5P3b3aivXf/yLW3izG13stX/9NYNhtXcutXwnu3HpN3wZ+XfctY8nt3/lFWtxtxc0rY0Cu
Y6+N2YeI3+R9X2ylXopYYeIV38jF3DfmYksG3vxt2j7OY+Ht5JaF0n8oCUJW5Oxt3Aw+2bKN3cqF
WT1O2rCV2zNeZN6lZE7W47ad5EyeZfe139OFXuJtUCUW41V1YkamXF6t2i7GXZZ15Ft25VJeZEnu
2VHtYuxt5idW3WEW1cHNVZNt5hIm5RztWl2uZc/tXWv+5QoG2WUO31lF3VxmZOX1ZmzW5Vuu5r3d
Yjj+XqvNX0jG3gB+ii0AZapoWnIu3V5WZzXGX6mV53jFZznWZ1im5f9A1uevNdx9vuh6nmc7Xt42
PmhPRhlQFuUCNuP/5eR2TmTvjeWQxWN2nWNDtuj5hWlc7uQ7ruQ5vmCCbmXw/WOWnuhw7o2cPmQR
TuL+HWEn7t7z/WClbtslPt8jjuKl3mRNxuIN1mLjdeqp3mai9eAUPlmBPlMffs6vBuqwhquxJuuy
diuBTmu2Dpm2fmu4juvRA2u5jjQJFYmanmRqhluD3uumhlcLpmKt9t2/NmAQjuhplujDReBfHeyZ
Vl/L7WqPFWzfzdRs/mZnxuBrPt5U7lDfyOsETtyMfmeXtuhU3uqFtulc9td85mPFvl3TXmUVNumU
PmXGrmjvpWOxDeT/UfbTHWXlyAbs1sXpcaZpws5s3VbqSybtp31o117u+N1qgH3qVh5twGXloRXu
KG7tkT7W33bn4MZk8c7a5g1m5Hbp6N3o8xbqPR5pBi7k4ubq/3VkmqXf7qVY7YbfMLbi7pbTu8br
ES5tAFblZE7tnz3gh9ZbBAfkbxZurD3nWU5sLpbiLMbYxzXm+n5WwUZobj7mAt/p4gbbBFfrrr3v
9sVp4oZoDC9oXF5neubog/7d54bc7Z5ueF5dhk7vCt5ieoXX0/bjoDbX/37ZsYVi2VVp535l3PZi
/c7woVZvDfZlGXdviXZqgPVg+XVodYXp7L5pwJZq9KboMSZxoDZx/0Jm3xQXbahd4/GGbdWW4I7W
aBvv6BevZeIG4dguZ3b2chCH89HtbbpIphcQGJJA7aAm3BBXYMMd7Tp+70M28iku6neW7j9HXSQO
8celVERP7Q0/8CLX8jNGagNncW3ZgLo+9bCia1RvtCFfdVd/dVhnl7PuT1mY9WCMddR7gtihBVzv
dV//dWAP9smydWIv9vwkAGNP9grNzlEQ9rVSdmhfolegUGev0hF4F3zkgWjf9lisdm9nCG4Pd3Ef
95aoAnIX929Pd4M4d3Zvd3d/95BWd3mfd3WHd3u/d3zP9xKl93TXd3//d4AP+Pbk929XiWkX+Ijq
AoSXNYKv9oV/+P8WbXiHh3iKD/hHeISKz3iXlfhBw0+OZ+shOAlxtogDQJYDKHl0QfmLUHm5YPkx
KXmUP/m4YHmXX4ialxeYN1ARPXmZH4ibL4ib//mV73mDEPqVJwijj4ic9/mibwiVd/mkP/qoZwih
n3qmX/qZB3qIoHmPqPqh+Pmc9/iPeHqlnwuwNwmrrwiyp4i1N/uuJ4mcT/uM4PqHkHunp/qvt3l7
sHsk+g2uj/me5/m99/nA33uZJ3rBH/yYTwjAD3zHX3yYP/ynf/zBN/zGh3qmV3zLt3zIT3ykl/zC
33ygp3zEL3yop3zOJ/zGv3rP9/yiR/24z/zV1/zUR3rV//zF13z/np98or/9xP992Jd83Ff92Xd9
nR9Pkfj7ys985r/6yod820d8xmd+rCf70M/96M9+52/+3I996qf95V9+6w9/299+7Hd+uv/+8Z/+
6if/6Vf/7m9+xcd+5d9+3bf/9i9/+cd/7Yd+/geIA/YGChxo8CDChAoXMmzo8CHEiBIdFiRoT+CB
ihUvEsyIkSNIjB4/NiyoESRKkiEtXvSY8uVJgx9nvrSocmNMjiITjiRpsmNGnQdxyoQ51OXNliWL
2ixKs2XQnERPUqXqlGlHrFBvjlyps6vVrBPHki1rduK/tGrXsm2bdqpMlUKb/pyrVWFdu2G9Jt2b
9CpNqXqHYuVK//jwT6tECxtlKVTqxsONHw8WfLUpXcyDEUZlnJNlYs6X4yJ0a/o06tSqV7Nu/e+s
47x2K/OdjJKp39F1++quyXgzZce+5S6eGzqz1tyC/wqXvLdmbuG8MT8FTni5Z9CT5TaH7f07+PBx
g9okDzUk0trnb0dOr3l9zN0ulZok/xl6VsV3O9M1P147ep21Z599uNUnoFP+ifYfe4W5B9Ri88FH
WnwSrqfUVmLNtxtQseWnoHghijgiiSWaeCKKKaq4IosLtvgijDHKOCONNdp444wW4rgjjz36+COQ
QQo5JJE4uuZWkUkquSSTTR75JJRRPklWK2RFJtGVQoK45Ja3Nf9pZZYthvklmWL61p1zZp6VZVcU
3fXQhm1GdOV9Jek4FnPejfmmdOZJeCeWnAHq4p54+afRoGXiWOdSaAJJ50SFMnSfpJL9BmeIleKJ
KU/YaaYpT5ZyaqWBlypqlpRvaScSq4npiNSfCsLKIHwbZgihoAeKeiGsPhHYZYMd5ipsh3K+2imi
vM3EX6wDJnuhsHdatt+wt1rrJa9RMfvrmNMKlCq44YKr56rDWedpsMd5qWxv2SHrYXHTYbtuqO6m
+Wm1z1WF73N4BZtmmN7i1O12+Y5WMKPxJnpqROAGBlx18SZoIYc94aofvvb6a7HE0Yk68KEHe1je
oK0S11tVsyL/ezKh87J37McP5nkdWAC3+zFj4uq8M8+nPcxcxPfOhth7CBescajt2Zzxm9PaNvLQ
G7todNFiwbtrv3wqbalyfA7d8c3dCdYz2WWLix92n6EbIb8oH331pLZ1LV29UD9tLqO02StvcXLX
zV3TcP/L90LyUv2v0N+avbjO38WXH2D7/QWzfMmyC9qrBeb6bLS+5gWy5uM5iyZ/AW5Oa5yl12c6
tLjWavC7VmdLp8yu294s5BP2mbrtDJc1ru9zBj888V8yfjzwxYu4sPLNO/889NFLPz311dOYvPXZ
az888t17//1rnRbuPKgwAlti+Y16nX7hARsPPvzx71y3qRQx/+9m3o7HKKn7qMs6ac0gIqepRY19
9LOby8RjwITIr4GteYED1XLAM6kPPAuM1P5GdZS9kUZ9mkoYAb2GwZapyTsRPCEKUVMrkFkLZkd5
ln5YxbrW2QpzrWKQsXhXrfNkTlckpFfUCIW7pX2lQLrKobo6x8I2+ZA63MJhEYk2Q5eksIpW/EfW
1ga72exLb0F8nGwodTj39U1wP0QUgOImOLC1jWWV2VoBs8OmzyFMNgBS2kauqEfslSWLnhkgzR40
xq3sZHNOq5DqYALIAIpNZMk5lsXUqEiK1ZA2hZxk6ZCGNww5h5GEE81TwHLB7ZnPkeiKGxwHOcdd
nWluXmxZGf/vRrqpFeqUOGsjhUQGqaqtTWJEnBllgDZKUkrEYabkoNTe48o8+dInvxykxnYZRGzR
sX5QYyYsI+c2Xh7TjL70IjDxQ7c9khNKjgvdBhF5OmKlbnKeIxYUbQid2t1KWjqUFTr998IfJg6e
1OxVaCrpwznaMXeP+R8OhziwM/aKmA6l3jAfyiWJUrSiYIqoRYmE0YzKiI8c/ShIY1TOkfYspCY9
KYtIqtKzFSmWOVrT+ISnqPNp8ET9A6VZaDpSAaw0fGWqlEtlxCYBCs1RCXQTUmGa1PLlb3kxxSmp
FCUAlOpPgxu1oL+sKsIJyrSCfaxpoIzq1KxCdVOnEsBUn3f/T23d7olKfGvvmCi5A8HxhsbR3Fot
t0+5eg50UJSh2pglz3om8j/uHB0SR5ZXvb5woKx7Z0KTKKS0Ko+N6iIcGZG5xvGpDWV0xKNmNxm6
b5bnmve67NvYeC4OZq1tdMMlzWYJr6uqiLLEsyy/PMnJDFkOm+U6XWddS8gAcYWepgXaaY37tciZ
zG91dSLFWJugxr7NaHRNiTRbOyTb7siY7kLtcw06s+Cu5Lnk/eQ2gTg4bbYyvXCxWXW8qd7j3HSZ
uRSuah9WtJAJrqckJdd38dtej/mWgtW1L3Ig1t6rHdK9IWxmehtp2tdCU8DnNYrhKKxdqp4FAe1z
bHkVOjHR/2nIT5TkL3DnargaMrGJi7xcXJtFnIRVU3foCZzd7DlPvcp4x85y7HU598iCcvhGtA3P
kb+0wCRztchOLmaqvtojJjNpySmiMin9q+UjPdkhW/4ymMMsZvl1uSFjPjOa0yxmBUZVRV3Ccpnj
LOezYA9wQ63lVsEqRpsqRM1+/jOg/8zKBOIZq/x0c58DrehFM/p459wWYA86Wh4qkXZN5CGLQzZQ
Ectwzp7+tHeDExvwOvjC2WXvBlVJ5EazOi0TaDWswacYb6kybH5kcHZ167GDxLrXvv71zvyCXPvu
+tbbIW2FeQ3sZTO72ajR1yYtbOtu+u1SmE3OQJyt7W2vWehP6YkVJklMn2jNlXTKQmil46mhT7O7
yx4l5jC5Le95q7TdR7U3vj1N733zu9/+/jfAAy7wL+e74AY/OMITrvCFM7zhDi/TwCMu8Yn/N0T7
eDj19IFxqlK84x4PuAmquPGRkxx6Hz85ylP+ZWyovOUufznMYy7zmdO85jb/dclzrvOd87znPU+E
z8FDgKATHTxmyLkRiq70pTM9IdpoOtSjLnV3p0YfN7861rXcjKxzfd8boPnWuy72sfc67OGaOtqh
3oy0s73tE1m72+NO0aErCu4mJDtbAIB3YBvi5Q8ZwsIBIPfBwyYgADs=

------=_NextPart_000_0009_01C709B1.BE612F50--



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 kAGMDane027944; Thu, 16 Nov 2006 15:13:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGMDaeb027943; Thu, 16 Nov 2006 15:13:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGMDZXk027923 for <[e-mail]>; Thu, 16 Nov 2006 15:13:36 -0700 (MST) (envelope-from [e-mail])
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.15; Thu, 16 Nov 2006 14:13:30 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.20; Thu, 16 Nov 2006 14:13:30 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 16 Nov 2006 14:13:30 -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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 14:12:32 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJo+esNnxnqaD+QBmtuZUWnhUzNAAFUyHgAANjdXAAARNdYA==
References: <[e-mail]> <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: "Price, Bill" <[e-mail]>, Michael Myers <[e-mail]>, Russ Housley <[e-mail]>, Stefan Santesson <[e-mail]>, Paul Hoffman <[e-mail]>, Sam Hartman <[e-mail]>
CC: <[e-mail]>
X-OriginalArrivalTime: 16 Nov 2006 22:13:30.0003 (UTC) FILETIME=[725D1630:01C709CC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAGMDaXk027933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In-line

-----Original Message-----
From: Price, Bill [mailto:[e-mail]] 
Sent: Thursday, November 16, 2006 2:01 PM
To: Ryan Hurst; Michael Myers; Russ Housley; Stefan Santesson; Paul
Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I too would like to see a small modification made to the specs to
better explain the error code. However, I think the proposals are "off
the mark." The error message in both its "sound bite" title and the
proposed expanded descriptions sound like there's an error at the
responder (server). The user of a client that got such an error would
likely look for problems at the responder. 

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 
[rmh] Bill this is just once case, what if a client includes a
unsupported extension if the responder was keyed but proxying the
request to a authoritative responder with the intent to re-sign but the
proxy server was not available, or if the client included a unsupported
identifier (byKey vs byname) there are lots of cases where a server is
not able to provide a authoritative responses.


I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.
[rmh] It needs to be more generic than that unfortunaltey.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 
[rmh] This is something implementations should deal with as part of
their debugging tools, documentation and logging.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ryan Hurst
Sent: Thursday, November 16, 2006 2:57 PM
To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is
not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS,
just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

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 kAGM2Fgt025785; Thu, 16 Nov 2006 15:02:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGM2Fb7025784; Thu, 16 Nov 2006 15:02:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGM2DMw025766 for <[e-mail]>; Thu, 16 Nov 2006 15:02:14 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kAGM2BjZ007376 for <[e-mail]>; Thu, 16 Nov 2006 17:02:11 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id B88FABF00 for <[e-mail]>; Thu, 16 Nov 2006 17:02:10 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAGM296L007318; Thu, 16 Nov 2006 17:02:10 -0500
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 17:01:23 -0500
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 17:01:23 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-index: AccJo+esNnxnqaD+QBmtuZUWnhUzNAAFUyHgAANjdXA=
From: "Price, Bill" <[e-mail]>
To: "Ryan Hurst" <[e-mail]>, "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Nov 2006 22:01:23.0338 (UTC) FILETIME=[C13CCEA0:01C709CA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAGM2EMw025769
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I too would like to see a small modification made to the specs to
better explain the error code. However, I think the proposals are "off
the mark." The error message in both its "sound bite" title and the
proposed expanded descriptions sound like there's an error at the
responder (server). The user of a client that got such an error would
likely look for problems at the responder. 

The most likely cause of the "unauthorized" error is an ill-conceived
but syntactically correct request that asks for the status either of a
certificate from a non-supported CA or of an expired or yet-to-be
issued certificate. (The case where a presigned responder didn't have a
presigned response available.) This situation may seem unlikely but it
has happened because of misconfiguration or bugs in homegrown clients. 

I'd recommend some words that the error "can occur when a keyless
responder does not have a presigned response available."  A few words
more could explain that a request as described above would provoke the
unauthorized response.

I recommend fixing the description to be user friendly so that people
who encounter the error know quickly why it happened and where to look
to fix it. 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ryan Hurst
Sent: Thursday, November 16, 2006 2:57 PM
To: Michael Myers; Russ Housley; Stefan Santesson; Paul Hoffman; Sam
Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is
not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS,
just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

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 kAGJvfuF008640; Thu, 16 Nov 2006 12:57:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGJvfSH008639; Thu, 16 Nov 2006 12:57:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGJvevE008601 for <[e-mail]>; Thu, 16 Nov 2006 12:57:41 -0700 (MST) (envelope-from [e-mail])
Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.15; Thu, 16 Nov 2006 11:57:35 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.20; Thu, 16 Nov 2006 11:57:30 -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.2786);	 Thu, 16 Nov 2006 11:57:30 -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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 11:57:09 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJo+esNnxnqaD+QBmtuZUWnhUzNAAFUyHg
References: <[e-mail]> <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: Michael Myers <[e-mail]>, Russ Housley <[e-mail]>, Stefan Santesson <[e-mail]>, Paul Hoffman <[e-mail]>, Sam Hartman <[e-mail]>
CC: <[e-mail]>
X-OriginalArrivalTime: 16 Nov 2006 19:57:30.0047 (UTC) FILETIME=[72A69CF0:01C709B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAGJvfvE008630
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If that were possible this would be the text I would propose:

The response "unauthorized" is returned in cases where the client is not
authorized to request a response or the server is not capable of
responding authoritatively.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Thursday, November 16, 2006 6:35 AM
To: Russ Housley; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Maybe what makes the most sense is to update 2560 with this definition
since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just
a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

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 kAGJEGDJ002281; Thu, 16 Nov 2006 12:14:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGJEGK1002280; Thu, 16 Nov 2006 12:14:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGJEEU7002259 for <[e-mail]>; Thu, 16 Nov 2006 12:14:15 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kAGJBx5V013529; Thu, 16 Nov 2006 14:12:00 -0500 (EST)
Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 16 Nov 2006 14:11:59 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Nov 2006 14:11:59 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 14:11:58 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJnDW7GAZtmJJCSlO4oGwvofbPRAAFSQjg
From: "Kemp, David P." <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 16 Nov 2006 19:11:59.0661 (UTC) FILETIME=[1736C5D0:01C709B3]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14816003
X-TM-AS-Result: : Yes--3.025800-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMTY1MS03MDA2?= =?us-ascii?B?MjYtNzAwNDYyLTcwMTg3MS03MDA1OTktNzAwNDQ3LTcwMDg3Ny03?= =?us-ascii?B?MDI4NTgtNzA2MTAxLTcwMDI5Ni03MDI5NTUtMTM5MDA2LTcwMDUz?= =?us-ascii?B?Ni03MDMyMTAtNzAzMDk3LTcwMDE1MS03MTAwMjgtNzAwMDkzLTcw?= =?us-ascii?B?NTMxMy03MDUzMjAtMTQ4MDUw?=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAGJEGU7002275
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And change the word "unauthorized" to something else, like
"unauthorized/unsupported".

It is incorrect to say that a responder that wasn't designed to
properly handle multiple cert requests is "unauthorized" to
respond to them.

The fact that my 1971 Chevy Vega couldn't do 100 MPH downhill
in a tailwind doesn't mean that it wasn't authorized to go
that fast -- it was simply incapable of doing so.


-----Original Message-----
From: Michael Myers

How about we expand the meaning of "unauthorized" to mean EITHER the
requestor is not authorized to ask the responder OR the responder is not
authorized to fulfill the request.  That's not *too* ugly, is it?

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.




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 kAGIKnAE094702; Thu, 16 Nov 2006 11:20:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGIKmct094701; Thu, 16 Nov 2006 11:20:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGIKlYF094684 for <[e-mail]>; Thu, 16 Nov 2006 11:20:48 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.80) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) (authenticated as u18116613) id 452BAC860077429B; Thu, 16 Nov 2006 19:19:16 +0100
Message-ID: <011901c709ab$b907eb30$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v> <010801c7096a$8ef012f0$5d85900a@wcwang>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 19:19:14 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01C709B4.1A20A9E0"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0114_01C709B4.1A20A9E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Wen-Cheng Wang wrote:

>I oppose this change of AIA extension. There already exists some
>CAs that issued certificates with AIA extensions containing only
>one id-ad-caIssuers accessLocation (either HTTP or LDAP).=20

Sure.  Since RFC 3280 says nothing about this we can expect some =
variations out there.

>This change will immediately make these CAs becoming non-compliant
>to RFC3280bis.

Does it?  I thought SHOULD is a recommendation.

>For a CA to guide its relying parties (client applications)
>where to find the CA certificates, one  id-ad-caIssuers accessLocation
>is sufficient.

You misunderstood my point.  Certificate path building on the relying =
parties' end is (with S/MIME as the only major exception), done by =
servers.  For servers there is no problem to fix.  I'm rather talking =
about client software that is not relying party software, but rather =
subscriber software.  Although some CAs indeed not only specify and =
distribute such software, it is not these guys who have a problem, it is =
rather the other 99% who can't afford writing their own subscriber =
software.

>Even though the leading CA packages one the market
>support both HTTP and LDAP, certification service providers might
>still choose not to deploy both kinds of repositories at the same time =
because
>of concerning the operating cost. There is no enough reason to require =
all
>compliant CAs to both kinds of repositories at the same time. I prefer =
to
>leave the current text as it is. With current text,  certification =
service
>providers are free to choose HTTP or LDAP or both.

Yes, but makers of client software MUST (otherwise they cannot create a =
proper cert-path), support both in order to work with compliant CAs.

It is really the concern of CAs or of a gazillion clients that is the =
core issue.

It is interesting to note that NIST came to a different conclusion =
regarding PIV than for 3280bis, in spite of having pretty much the same =
people behind both efforts.

Anders
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [e-mail]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20


  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access


  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.


  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0114_01C709B4.1A20A9E0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang wrote:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;I oppose this change&nbsp;of AIA =

extension. There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;CAs that issued certificates =
with AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;one id-ad-caIssuers =
accessLocation (either=20
HTTP or LDAP). </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sure.&nbsp; Since RFC 3280 says nothing =
about this=20
we can expect some variations out there.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;This </FONT><FONT=20
face=3D"Times New Roman">change will immediately make these CAs becoming =

non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;to RFC3280bis.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does it?&nbsp; I thought SHOULD&nbsp;is =
a=20
recommendation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;For a CA to guide its relying =
parties=20
(client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;where to find the CA =
certificates,=20
one&nbsp; id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;is sufficient.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>You misunderstood my point.&nbsp; =
Certificate path=20
building on the relying </FONT><FONT face=3DArial size=3D2>parties' end =
is (with=20
S/MIME as the only major exception), done by </FONT><FONT face=3DArial=20
size=3D2>servers.&nbsp; For servers there is no problem to fix.&nbsp; =
I'm rather=20
talking about client </FONT><FONT face=3DArial size=3D2>software that is =
not relying=20
party software, but rather <STRONG>subscriber </STRONG></FONT><FONT =
face=3DArial=20
size=3D2><STRONG>software</STRONG>.&nbsp; Although some CAs indeed not =
only=20
specify and </FONT><FONT face=3DArial size=3D2>distribute such software, =
it is not=20
these guys who have a </FONT><FONT face=3DArial size=3D2>problem, it is =
rather the=20
other 99% who can't afford writing their </FONT><FONT face=3DArial =
size=3D2>own=20
subscriber software.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">&gt;Even though&nbsp;the leading CA =
packages=20
one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;leave the current text as it is. =
With=20
current text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">&gt;providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yes, but makers of client software MUST =
(otherwise=20
they cannot&nbsp;create a proper cert-path),&nbsp;support both in order =
to work=20
with compliant CAs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>It is really the concern of CAs =
or of a=20
gazillion clients that is the core issue.</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It is interesting to note&nbsp;that =
NIST came to a=20
different conclusion regarding PIV than for 3280bis, in spite of=20
having&nbsp;pretty much&nbsp;the same people behind both =
efforts.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0114_01C709B4.1A20A9E0--




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 kAGFCH9m067533; Thu, 16 Nov 2006 08:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGFCGI9067531; Thu, 16 Nov 2006 08:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAGFCC82067519 for <[e-mail]>; Thu, 16 Nov 2006 08:12:12 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAGFC4mr020603; Thu, 16 Nov 2006 08:12:08 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 16 Nov 2006 06:35:21 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maybe what makes the most sense is to update 2560 with this definition since
2560 is normatively referenced in other RFCs.  I'm not talking BIS, just a
quick sentence or two.

Mike

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 8:03 PM
To: Michael Myers; Stefan Santesson; Paul Hoffman; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the
"unauthorized" error code is used.

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 kAGD011c045627; Thu, 16 Nov 2006 06:00:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGD016p045626; Thu, 16 Nov 2006 06:00:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp5.smtp.bt.com (smtp5.smtp.bt.com [217.32.164.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGCxwvV045572 for <[e-mail]>; Thu, 16 Nov 2006 05:59:59 -0700 (MST) (envelope-from [e-mail])
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 12:59:30 +0000
Received: from mail pickup service by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Thu, 16 Nov 2006 12:59:17 +0000
Received: from relhubc01-ukbr.tcrelay.net ([10.216.117.35]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Nov 2006 11:53:05 +0000
Received: from balder-227.proper.com ([192.245.12.227]) by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Nov 2006 11:49:29 +0000
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 kAGAWxoO023001; Thu, 16 Nov 2006 03:32:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGAWw0k023000; Thu, 16 Nov 2006 03:32:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth1.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGAWvsb022983 for <[e-mail]>; Thu, 16 Nov 2006 03:32:57 -0700 (MST) (envelope-from [e-mail])
Received: from auth1.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id DA89D2CC432 for <[e-mail]>; Thu, 16 Nov 2006 18:32:49 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth1.cht.com.tw (Postfix) with SMTP id 852992CC3AC for <[e-mail]>; Thu, 16 Nov 2006 18:32:49 +0800 (CST)
Message-ID: <010801c7096a$8ef012f0$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 18:32:39 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01C709AD.988D0780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-OriginalArrivalTime: 16 Nov 2006 11:49:30.0125 (UTC) FILETIME=[467513D0:01C70975]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C709AD.988D0780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I oppose this change of AIA extension. There already exists some
CAs that issued certificates with AIA extensions containing only
one id-ad-caIssuers accessLocation (either HTTP or LDAP). This
change will immediately make these CAs becoming non-compliant
to RFC3280bis. For a CA to guide its relying parties (client =
applications)
where to find the CA certificates, one  id-ad-caIssuers accessLocation
is sufficient. Even though the leading CA packages one the market
support both HTTP and LDAP, certification service providers might
still choose not to deploy both kinds of repositories at the same time =
because
of concerning the operating cost. There is no enough reason to require =
all
compliant CAs to both kinds of repositories at the same time. I prefer =
to
leave the current text as it is. With current text,  certification =
service
providers are free to choose HTTP or LDAP or both.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [e-mail]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20


  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access


  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.


  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0105_01C709AD.988D0780
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.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">I oppose this change&nbsp;of AIA =
extension.=20
There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">CAs that issued certificates with =
AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">one id-ad-caIssuers accessLocation =
(either=20
HTTP or LDAP). This</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">change will immediately make these =
CAs=20
becoming non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">to RFC3280bis. For a CA to guide its =
relying=20
parties (client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">where to find the CA certificates, =
one&nbsp;=20
id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">is sufficient.&nbsp;Even =
though&nbsp;the=20
leading CA packages one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">leave the current text as it is. =
With current=20
text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0105_01C709AD.988D0780--



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 kAGAWxoO023001; Thu, 16 Nov 2006 03:32:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAGAWw0k023000; Thu, 16 Nov 2006 03:32:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth1.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAGAWvsb022983 for <[e-mail]>; Thu, 16 Nov 2006 03:32:57 -0700 (MST) (envelope-from [e-mail])
Received: from auth1.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id DA89D2CC432 for <[e-mail]>; Thu, 16 Nov 2006 18:32:49 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth1.cht.com.tw (Postfix) with SMTP id 852992CC3AC for <[e-mail]>; Thu, 16 Nov 2006 18:32:49 +0800 (CST)
Message-ID: <010801c7096a$8ef012f0$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
References: <005f01c7095c$b821c2d0$82c5a8c0@arport2v>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 18:32:39 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01C709AD.988D0780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0105_01C709AD.988D0780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I oppose this change of AIA extension. There already exists some
CAs that issued certificates with AIA extensions containing only
one id-ad-caIssuers accessLocation (either HTTP or LDAP). This
change will immediately make these CAs becoming non-compliant
to RFC3280bis. For a CA to guide its relying parties (client =
applications)
where to find the CA certificates, one  id-ad-caIssuers accessLocation
is sufficient. Even though the leading CA packages one the market
support both HTTP and LDAP, certification service providers might
still choose not to deploy both kinds of repositories at the same time =
because
of concerning the operating cost. There is no enough reason to require =
all
compliant CAs to both kinds of repositories at the same time. I prefer =
to
leave the current text as it is. With current text,  certification =
service
providers are free to choose HTTP or LDAP or both.

Wen-Cheng Wang
  ----- Original Message -----=20
  From: Anders Rundgren=20
  To: [e-mail]=20
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt=20


  May I repeat my request for further improving the interoperability in =
this area?
  Anyway, here it is:

  4.2.2.1  Authority Information Access


  When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
   accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. =
there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.


  Rationale:
  Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

  Sincerely
  Anders Rundgren

------=_NextPart_000_0105_01C709AD.988D0780
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.2995" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">I oppose this change&nbsp;of AIA =
extension.=20
There already exists&nbsp;some</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">CAs that issued certificates with =
AIA=20
extensions containing only</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">one id-ad-caIssuers accessLocation =
(either=20
HTTP or LDAP). This</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">change will immediately make these =
CAs=20
becoming non-compliant</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">to RFC3280bis. For a CA to guide its =
relying=20
parties (client applications)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">where to find the CA certificates, =
one&nbsp;=20
id-ad-caIssuers accessLocation</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">is sufficient.&nbsp;Even =
though&nbsp;the=20
leading CA packages one the market</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">support both HTTP and LDAP, =
certification=20
service providers might</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">still choose not =
to&nbsp;deploy&nbsp;both=20
kinds of repositories at the same time because</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">of concerning </FONT><FONT=20
face=3D"Times New Roman">the operating cost. </FONT><FONT=20
face=3D"Times New Roman">There is no enough reason to require =
</FONT><FONT=20
face=3D"Times New Roman">all</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">compliant CAs </FONT><FONT=20
face=3D"Times New Roman">to both kinds of repositories at the same time. =
I prefer=20
to</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">leave the current text as it is. =
With current=20
text,&nbsp;&nbsp;certification service</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">providers </FONT><FONT=20
face=3D"Times New Roman">are free to choose HTTP or LDAP or =
both.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">Wen-Cheng Wang</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[e-mail]=20
  href=3D"mailto:[e-mail]">Anders Rundgren</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Thursday, November 16, =
2006 4:53=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Re: I-D=20
  ACTION:draft-ietf-pkix-rfc3280bis-06.txt </DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
  interoperability in this area?</DIV>
  <DIV>
  <DIV>Anyway, here it is:</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
  <STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
  an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC =
4516]=20
  URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one=20
  HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
  specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
  public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
  support on COTS clients may prove to be hard to motivate for AIA=20
  access.&nbsp;&nbsp;One may argue that reading AIA extensions is just =
an option=20
  but that is not really the case; schemes like PIV require that you =
interpret=20
  AIA in order to create valid certification paths, unless you force =
clients to=20
  store additional CA certificates locally which is a less optimal=20
  solution.&nbsp; The cost for a CA to support HTTP and LDAP AIAs is =
close to=20
  zero since this is built-in in the leading CA packages on the=20
  market.&nbsp;&nbsp; That the PIV certificate requirements also specify =
both=20
  URI types for AIA probably was probably not accidental.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0105_01C709AD.988D0780--



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 kAG8tDmH009488; Thu, 16 Nov 2006 01:55:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG8tDvF009487; Thu, 16 Nov 2006 01:55:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAG8tCWo009470 for <[e-mail]>; Thu, 16 Nov 2006 01:55:13 -0700 (MST) (envelope-from [e-mail])
Received: from arport2v (81.232.45.80) by pne-smtpout1-sn1.fre.skanova.net (7.2.076.2) (authenticated as u18116613) id 453F8C600043C475 for [e-mail]; Thu, 16 Nov 2006 09:55:06 +0100
Message-ID: <005f01c7095c$b821c2d0$82c5a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Date: Thu, 16 Nov 2006 09:53:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C70965.19CE5D10"
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
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C70965.19CE5D10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

May I repeat my request for further improving the interoperability in =
this area?
Anyway, here it is:

4.2.2.1  Authority Information Access


When the id-ad-caIssuers accessMethod is used, at least one instance =
SHOULD specify an
 accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. there =
SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] =
accessLocation URI specified.


Rationale:
Since LDAP has rather limited applicability on public networks, I =
believe that [indirectly] requiring mandatory LDAP support on COTS =
clients may prove to be hard to motivate for AIA access.  One may argue =
that reading AIA extensions is just an option but that is not really the =
case; schemes like PIV require that you interpret AIA in order to create =
valid certification paths, unless you force clients to store additional =
CA certificates locally which is a less optimal solution.  The cost for =
a CA to support HTTP and LDAP AIAs is close to zero since this is =
built-in in the leading CA packages on the market.   That the PIV =
certificate requirements also specify both URI types for AIA probably =
was probably not accidental.

Sincerely
Anders Rundgren

------=_NextPart_000_005C_01C70965.19CE5D10
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>May I repeat my request for further =
improving the=20
interoperability in this area?</DIV>
<DIV>
<DIV>Anyway, here it is:</DIV>
<DIV>&nbsp;</DIV>
<DIV>4.2.2.1&nbsp; Authority Information Access<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>When the id-ad-caIssuers accessMethod =
is used,=20
<STRIKE><FONT color=3D#ff0000>at least one instance SHOULD specify=20
an<BR>&nbsp;accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] =

URI.</FONT></STRIKE> <STRONG><FONT color=3Dgreen>there SHOULD be at =
least one HTTP=20
[RFC 1738] and one LDAP [RFC 4516] accessLocation URI=20
specified.</STRONG></FONT></FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rationale:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since LDAP has rather limited =
applicability on=20
public networks, I believe that [indirectly] requiring&nbsp;mandatory =
LDAP=20
support on COTS clients may prove to be hard to motivate for AIA=20
access.&nbsp;&nbsp;One may argue that reading AIA extensions is just an =
option=20
but that is not really the case; schemes like PIV require that you =
interpret AIA=20
in order to create valid certification paths, unless you force clients =
to store=20
additional CA certificates locally which is a less optimal =
solution.&nbsp; The=20
cost for a CA to support HTTP and LDAP AIAs is close to zero since this =
is=20
built-in in the leading CA packages on the market.&nbsp;&nbsp; That the =
PIV=20
certificate requirements also specify both URI types for AIA probably =
was=20
probably not accidental.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sincerely</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005C_01C70965.19CE5D10--




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 kAG46mtf071768; Wed, 15 Nov 2006 21:06:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG46mnO071767; Wed, 15 Nov 2006 21:06:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAG46l29071751 for <[e-mail]>; Wed, 15 Nov 2006 21:06:47 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26598 invoked by uid 0); 16 Nov 2006 04:06:36 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 16 Nov 2006 04:06:36 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 23:02:40 -0500
To: "Michael Myers" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Sam Hartman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike:

>The LW OCSP I-D does not nor is intended to
>update, redefine, obsolete or otherwise diminish
>2560 as the base document defining OCSP.

At a minimum, it needs update RFC 2560 to explain the ways that the 
"unauthorized" error code is used.

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 kAG46iKG071747; Wed, 15 Nov 2006 21:06:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG46i4F071746; Wed, 15 Nov 2006 21:06:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAG46ggN071726 for <[e-mail]>; Wed, 15 Nov 2006 21:06:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26544 invoked by uid 0); 16 Nov 2006 04:06:31 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 16 Nov 2006 04:06:31 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 22:47:53 -0500
To: Paul Hoffman <[e-mail]>, "Michael Myers" <[e-mail]>, "Sam Hartman" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[e-mail]>
In-Reply-To: <p06240898c18137c394fd@[10.20.30.183]>
References: <[e-mail]> <p06240898c18137c394fd@[10.20.30.183]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that this is the minimum change that is needed in an update 
to RFC 2560.

It can appear in the LW OCSP document if the PKIX WG agrees that the 
LW OCSP document is a standards-track update to RFC 2560.

Russ

At 04:32 PM 11/15/2006, Paul Hoffman wrote:

>At 10:33 AM -0800 11/15/06, Michael Myers wrote:
>>How about we expand the meaning of "unauthorized" to mean EITHER the
>>requestor is not authorized to ask the responder OR the responder is not
>>authorized to fulfill the request.  That's not *too* ugly, is it?
>
>No, it isn't. That's a good idea!
>
>--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 kAG1shJr055339; Wed, 15 Nov 2006 18:54:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG1shDg055338; Wed, 15 Nov 2006 18:54:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAG1seVY055308 for <[e-mail]>; Wed, 15 Nov 2006 18:54:43 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3428AE0035; Wed, 15 Nov 2006 20:54:32 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]>
Date: Wed, 15 Nov 2006 20:54:32 -0500
In-Reply-To: <[e-mail]> (Michael Myers's message of "Wed, 15 Nov 2006 17:05:57 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Sam, I cannot state the point more precisely.  Let's try
    Michael> this: What do you think it means?


Obselete is clear.  I have no idea why you would care about
diminishing a spec, or what that would mean.

As far as updating and redefining, I don't know whether you consider
the sort of text in the profile that broadens error codes to be an
update/redefinition.

What I think is true is that:

* the profile does not change the behavior of things that do not
  conform to the profile.

* There exist things that do not conform to the profile that will not
  interoperate with the profile.


* Clients that conform to the profile conform to 2560.

* Servers that conform to the profile will conform to 2560bis; it is
  rather unclear whether they conform to 2560.


* It is possible to write a server that conforms both to the profile
  and 2560, but to do so you have to give up some of the advantages of
  the profile.

If those bullet points aren't enough to make you happy, what else
would you need?



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 kAG1ggIF053951; Wed, 15 Nov 2006 18:42:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG1ggGp053950; Wed, 15 Nov 2006 18:42:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAG1gf2I053944 for <[e-mail]>; Wed, 15 Nov 2006 18:42:42 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAG1ge5m096708; Wed, 15 Nov 2006 18:42:40 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sam Hartman" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 17:05:57 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam,

I cannot state the point more precisely.
Let's try this:  What do you think it means?

Mike

-----Original Message-----
From: Sam Hartman [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 4:55 PM
To: Michael Myers
Cc: Stefan Santesson; Paul Hoffman; [e-mail]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Stefan, Steve: Works for me IF it is understood that:

    Michael> The LW OCSP I-D does not nor is intended to update,
    Michael> redefine, obsolete or otherwise diminish 2560 as the base
    Michael> document defining OCSP.

What does this paragraph mean?



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 kAG0sof0046123; Wed, 15 Nov 2006 17:54:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAG0socQ046115; Wed, 15 Nov 2006 17:54:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAG0snJC046099 for <[e-mail]>; Wed, 15 Nov 2006 17:54:49 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 38746E0035; Wed, 15 Nov 2006 19:54:40 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]>
Date: Wed, 15 Nov 2006 19:54:40 -0500
In-Reply-To: <[e-mail]> (Michael Myers's message of "Wed, 15 Nov 2006 15:14:15 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Stefan, Steve: Works for me IF it is understood that:

    Michael> The LW OCSP I-D does not nor is intended to update,
    Michael> redefine, obsolete or otherwise diminish 2560 as the base
    Michael> document defining OCSP.

What does this paragraph mean?



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 kAFNp6eK036091; Wed, 15 Nov 2006 16:51:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFNp6l9036090; Wed, 15 Nov 2006 16:51:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFNp5gW036084 for <[e-mail]>; Wed, 15 Nov 2006 16:51:05 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAFNow1m092977; Wed, 15 Nov 2006 16:50:59 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Paul Hoffman" <[e-mail]>, "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 15:14:15 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan, Steve:

Works for me IF it is understood that:

The LW OCSP I-D does not nor is intended to
update, redefine, obsolete or otherwise diminish
2560 as the base document defining OCSP.

Rather, it maps that protocol onto a specific
context of need.  Among other of its effects it
expands without conflict against original intent
the definition of the "unauthorized" error code
as I proposed below.

Is that the deal?

Mike

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Wednesday, November 15, 2006 2:58 PM
To: Paul Hoffman; Michael Myers; Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with
the editors again.

This is the outcome and what I propose as the way forward. It is my
understanding that this is acceptable to both the Security AD's as well as
the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions
of error responses, there is currently no adequate response defined for some
legal requests if the responder has no signing key. In particular this is
the case when the responder is limited to just returning pre-produced
responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to
update/clarify the meaning of error codes, in particular the "unauthorized"
error response, so that it updates the definition in RFC 2560 and allows the
usage specified in the lightweight profile. To do so, the lightweight
profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to
the WG to make this update and to go through a new WG last call to
acknowledge that rough consensus is not broken by the update.

Is this approach acceptable to the WG?


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: den 15 november 2006 13:32
> To: Michael Myers; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> At 10:33 AM -0800 11/15/06, Michael Myers wrote:
> >How about we expand the meaning of "unauthorized" to mean EITHER the
> >requestor is not authorized to ask the responder OR the responder is
> not
> >authorized to fulfill the request.  That's not *too* ugly, is it?
>
> No, it isn't. That's a good idea!
>
> --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 kAFMwjbj026620; Wed, 15 Nov 2006 15:58:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFMwjOQ026619; Wed, 15 Nov 2006 15:58:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFMwh1s026593 for <[e-mail]>; Wed, 15 Nov 2006 15:58:44 -0700 (MST) (envelope-from [e-mail])
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.0; Wed, 15 Nov 2006 22:58:38 +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; Wed, 15 Nov 2006 22:58:31 +0000
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>, Michael Myers <[e-mail]>, Sam Hartman <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 15 Nov 2006 22:58:29 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccJBtLWOcFV0ITOTGWOok7zWGdIXgAACR6A
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240898c18137c394fd@[10.20.30.183]>
In-Reply-To: <p06240898c18137c394fd@[10.20.30.183]>
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 kAFMwi1s026608
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes it is a good idea.

I just had a conf call first with the editors, then with Russ and then with the editors again.

This is the outcome and what I propose as the way forward. It is my understanding that this is acceptable to both the Security AD's as well as the editors.

Background and problem statement:
According to the current definitions in RFC 2560, especially the definitions of error responses, there is currently no adequate response defined for some legal requests if the responder has no signing key. In particular this is the case when the responder is limited to just returning pre-produced responses for a subset of all valid requests.

Proposed way forward:
In order to resolve this situation, the lightweight profile will have to update/clarify the meaning of error codes, in particular the "unauthorized" error response, so that it updates the definition in RFC 2560 and allows the usage specified in the lightweight profile. To do so, the lightweight profile must be a standards track document.

If this solution is acceptable, the lightweight profile will be returned to the WG to make this update and to go through a new WG last call to acknowledge that rough consensus is not broken by the update.

Is this approach acceptable to the WG?


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Paul Hoffman
> Sent: den 15 november 2006 13:32
> To: Michael Myers; Sam Hartman
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> At 10:33 AM -0800 11/15/06, Michael Myers wrote:
> >How about we expand the meaning of "unauthorized" to mean EITHER the
> >requestor is not authorized to ask the responder OR the responder is
> not
> >authorized to fulfill the request.  That's not *too* ugly, is it?
>
> No, it isn't. That's a good idea!
>
> --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 kAFMskdx025817; Wed, 15 Nov 2006 15:54:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFMskWf025816; Wed, 15 Nov 2006 15:54:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFMsiwd025783 for <[e-mail]>; Wed, 15 Nov 2006 15:54:45 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2006 14:54:34 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAFMsXKl009797; Wed, 15 Nov 2006 14:54:33 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAFMsWin026427; Wed, 15 Nov 2006 14:54:32 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 14:54:32 -0800
Received: from [172.16.5.12] ([10.21.89.223]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 14:54:31 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: "Peter Rybar" <[e-mail]>, [e-mail]
Content-Transfer-Encoding: 7bit
From: Max Pritikin <[e-mail]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 16:54:28 -0600
To: Russ Housley <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 15 Nov 2006 22:54:31.0989 (UTC) FILETIME=[03689650:01C70909]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1920; t=1163631273; x=1164495273; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Max=20Pritikin=20<[e-mail]> |Subject:=20Re=3A=20RFC3280bis=3A=20NotAfter=2099991231235959Z |Sender:=20; bh=AHJrfawAuwpT7AMxaRvk9I3pXxbZDebNOIDoCd3CR9Y=; b=Ny/4qfP3qpl0bvcdeRdEm8S+1yfnYKNuzaHUQRFjr8auQ5W+3XbnjtiQXyK59hTp7QRD3su4 ghD4VxIj+4URjxHvECwxymBOUkddiJpKQEX0eEPQwhGBbp3X/QdvZrHI;
Authentication-Results: sj-dkim-4; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think this implies that "6.1.3  Basic Certificate Processing" text:

          (2)  The certificate validity period includes the current  
time.

will need to be modified to read something like:

	(2) The certificate or any prior certificate validity period is  
either equal to GeneralizedTime value 99991231235959Z or includes the  
current time.

This indicating that the certificate chain validation no longer  
includes checking the current time against the validity period for  
these values. Alternatively every certificate in the chain could be  
required to use this large GeneralizedTime value.

Thanks,

	- max

On Nov 15, 2006, at 2:01 PM, Russ Housley wrote:

>
> I would hope that the time function would not be called with this  
> input.  The point is to flag the value as not expiring.
>
> Russ
>
> At 11:39 AM 11/15/2006, Peter Rybar wrote:
>> Some utility written in C language time (The time function returns  
>> the number of seconds elapsed since midnight (00:00:00), January  
>> 1, 1970,) will crash. ;-)
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-ietf- 
>> [e-mail]] On Behalf Of Russ Housley
>> Sent: Wednesday, November 15, 2006 3:56 PM
>> To: [e-mail]
>> Subject: RFC3280bis: NotAfter 99991231235959Z
>>
>>
>> I would like to add some text about certificates that are not
>> intended to expire.  I propose the following paragraph.
>>
>> In some situations, devices are given permanent certificates.  For
>> example, a device could be issued a certificate that binds its model
>> and serial number to its public key.  Such a certificate is intended
>> to be used for the entire lifetime of the device.  It indicate the
>> permanent nature of such a certificate, the notAfter SHOULD be
>> assigned the GeneralizedTime value of 99991231235959Z.
>>
>> Any concerns?
>>
>> 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 kAFMVWYs021585; Wed, 15 Nov 2006 15:31:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFMVWKa021584; Wed, 15 Nov 2006 15:31:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFMVVJ6021577 for <[e-mail]>; Wed, 15 Nov 2006 15:31:32 -0700 (MST) (envelope-from [e-mail])
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 kAFMVMtJ024325 for <[e-mail]>; Wed, 15 Nov 2006 17:31: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 kAFMVGbS013253 for <[e-mail]>; Wed, 15 Nov 2006 17:31:17 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 17:31:59 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Draft -06 does not include any changes from draft -05 other than adding 
Tim Polk to the list of editors.

Dave

[e-mail] wrote:
> 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, et al.
> 	Filename	: draft-ietf-pkix-rfc3280bis-06.txt
> 	Pages		: 144
> 	Date		: 2006-11-15
> 	
> 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-06.txt
>   



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 kAFLXNGe011898; Wed, 15 Nov 2006 14:33:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFLXNfG011897; Wed, 15 Nov 2006 14:33:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.183] (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 kAFLWMsA011708; Wed, 15 Nov 2006 14:32:23 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240898c18137c394fd@[10.20.30.183]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 15 Nov 2006 13:32:13 -0800
To: "Michael Myers" <[e-mail]>, "Sam Hartman" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:33 AM -0800 11/15/06, Michael Myers wrote:
>How about we expand the meaning of "unauthorized" to mean EITHER the
>requestor is not authorized to ask the responder OR the responder is not
>authorized to fulfill the request.  That's not *too* ugly, is it?

No, it isn't. That's a good idea!

--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 kAFKoC6v003578; Wed, 15 Nov 2006 13:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFKoCsQ003577; Wed, 15 Nov 2006 13:50:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (nso.neustar.com [156.154.16.158] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFKoBGt003547 for <[e-mail]>; Wed, 15 Nov 2006 13:50:11 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B99B43286E; Wed, 15 Nov 2006 20:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GkRhp-0008FE-Kh; Wed, 15 Nov 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 
Message-Id: <[e-mail]>
Date: Wed, 15 Nov 2006 15:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-06.txt
	Pages		: 144
	Date		: 2006-11-15
	
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-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-06.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3280bis-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--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 kAFKRwab099453; Wed, 15 Nov 2006 13:27:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFKRwfs099452; Wed, 15 Nov 2006 13:27:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFKRvRl099446 for <[e-mail]>; Wed, 15 Nov 2006 13:27:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31546 invoked by uid 0); 15 Nov 2006 20:27:51 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 20:27:51 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 15:27:41 -0500
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[e-mail]>
In-Reply-To: <[e-mail] eme.net>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree.  I can see where two of these models can be used in the 
multi-certificate request.  That is why I think that this dimension 
of the discussion is a red herring.

Russ

At 02:22 PM 11/15/2006, Santosh Chokhani wrote:
>Russ,
>
>The OCSP field in the AIA extension helps the OCSP client locate an OCSP
>Responder.  But, to verify the signature on the OCSP response, 2560
>mandates three trust models: explicitly trusted, CA only, and CA
>delegated.  The OCSP field can not extend those options to other trust
>models.
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Wednesday, November 15, 2006 10:32 AM
>To: Santosh Chokhani; [e-mail]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>My point is that the request could be for any set of certificates
>that contain AIAs that point to the same OCSP responder, whether they
>are part of the same certification path or not.
>
>Russ
>
>At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
> >Russ,
> >
> >I do not know how germane this debate is to Sam's question, but I was
> >simply responding to the issue building certification path.  I presume
> >that in this context it relates to building a path to the Responder
> >certificate.
> >
> >Now let us look at the three model 2560 has: Explicitly Trusted, CA and
> >Delegated.
> >
> >Explicitly trusted does not need a certification path and hence there
>is
> >no issue and that is why I did not include it in.
> >
> >CA model does not need any path building since path to the CA has
> >already been built and that is why I did not include it in my response.
> >Note that both clients requires the CA to use the same to sign the OCSP
> >as it signed the certificate in question with.
> >
> >My post responded to the Delegated model.
> >
> >I hope this clarifies that the path building should not be a major
>issue
> >for all three models 2560 supports.
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Tuesday, November 14, 2006 6:42 PM
> >To: Santosh Chokhani; [e-mail]
> >Cc: Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh:
> >
> >I believe this is a red herring.  This is not the only deployment
> >approach supported by RFC 2560.
> >
> >Russ
> >
> > >In hurry, I did not clearly articulate my thoughts.  What I am saying
> >also
> > >relates to another comment to Mike Myers regarding the security of
>the
> > >delegated model which is incompletely addressed by 2560.
> > >
> > >I will be verbose this time.
> > >
> > >The implementations such as Corestreet and Tumbleweed tend to adhere
>to
> >the
> > >approach that the same key that signed the certificate in question,
> >sign the
> > >OCSP Responder certificate.
> > >
> > >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
> >want
> > >the status of CA certificate and the Subscriber certificate, you get
> >them as
> > >responses and with them you only need the two OCSP Responder
> >certificates
> > >one signed by the Root (for verifying CA certificate revocation
>status)
> >and
> > >one signed by the CA (for verifying the subscriber certificate
> >revocation
> > >status).
> > >
> > >You do not need any paths.
> > >
> > >Please note that the approach also works when the Responder is
>queried
> >by a
> > >CA cross certified by the root, since rest of the path has been built
> >by the
> > >client.
> > >
> > >-----Original Message-----
> > >From: Dave Engberg [mailto:[e-mail]]
> > >Sent: Tuesday, November 14, 2006 12:45 PM
> > >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> > >[e-mail]
> > >Cc: Sam Hartman; Michael Myers
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >CoreStreet's OCSP server doesn't include a SingleResponse for the
> >issuing
> > >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> > >
> > >Adds 90-100 bytes onto every response
> > >
> > >Have never seen a relying party app/plug-in send a request like this
> > >
> > >The "delegated" trust model in RFC 2560 would require different
>signing
> > >certs for trusting entity vs. CA cert ... add another 1kB onto the
> >response
> > >
> > >Protocol only sends CA name+key info, which isn't enough to identify
> >which
> > >CA cert the relying party is inspecting in the case of CA cert
>renewal,
> > >cross-certification, etc.
> > >
> > >
> > >-----Original Message-----
> > >From: Stefan Santesson [mailto:[e-mail]]
> > >Sent: Tuesday, November 14, 2006 12:11 PM
> > >To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
> > >Cc: Sam Hartman; Michael Myers; Dave Engberg
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >Santosh,
> > >
> > >I didn't say it was hard. I say that I doubt that there are many
> > >implementations supporting this scenario even those with a responder
> >key.
> > >It would be interesting to hear from implementers if I'm right.
> > >
> > >Stefan Santesson
> > >Senior Program Manager
> > >Windows Security, Standards
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: den 14 november 2006 03:59
> > > > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > > Stefan,
> > > >
> > > > You are making more complex than it is.  The Responder can include
> >all
> > > > the CA certificates that issued the certificate in question and
>AIA
> >can
> > > > do the rest.
> > > >
> > > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > > environment, the CA certificate certification path is not an
>issue.
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:owner-ietf-
> > > > [e-mail]]
> > > > On Behalf Of Stefan Santesson
> > > > Sent: Monday, November 13, 2006 6:54 PM
> > > > To: Russ Housley; Price, Bill; [e-mail]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > > I'm not sure the case described is a realistic one.
> > > >
> > > > Section 2.2
> > > >    All definitive response messages SHALL be digitally signed. The
> >key
> > > >    used to sign the response MUST belong to one of the following:
> > > >
> > > >    -- the CA who issued the certificate in question
> > > >    -- a Trusted Responder whose public key is trusted by the
> >requester
> > > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > > >       specially marked certificate issued directly by the CA,
> > > > indicating
> > > >       that the responder may issue OCSP responses for that CA
> > > >
> > > > Since the request is on certificates issued by 2 different CA:s
> >trust
> > > > option 1 is invalid.
> > > > Trust option 3 is valid in theory but in practice it requires that
> >the
> > > > OCSP responder provide multiple validation paths in the response,
> >one
> > > > for each issuing CA. Somehow I doubt that this is implemented by
> > > > anyone.
> > > >
> > > > Trust option 2 is not generic and is only valid as a result of a
> >local
> > > > configuration.
> > > >
> > > > So I don't think this is a problem only for key-less responders.
> > > >
> > > >
> > > > Stefan Santesson
> > > > Senior Program Manager
> > > > Windows Security, Standards
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:owner-ietf-
> > > > > [e-mail]] On Behalf Of Russ Housley
> > > > > Sent: den 13 november 2006 14:08
> > > > > To: Price, Bill; [e-mail]
> > > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > > I prefer an error that tells the client to ask for the
>certificate
> > > > > one at a time.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > > >
> > > > > >I'd suggest focusing on understanding where responses to the
> >keyed
> > > > and
> > > > > >keyless responders inherently differ. I am aware of two general
> > > > cases:
> > > > > >
> > > > > >1) The request asks for the status of multiple certificates
>that
> > > > have
> > > > > >not been included in a single presigned response. Russ's
>example
> > > > fits
> > > > > >into this case. The keyed responder handles, but the keyless
>will
> > > > fail
> > > > > >for the general case. Some responders respond with the
>presigned
> > > > > >response that includes one of the certificates (usually the
> >first)
> > > > in
> > > > > >the request. A common situation is to ask for the status of
> > > > > >certificates in a chain. Santosh points out some keyless
> >responders
> > > > > >anticipate this and bundle responses accordingly.
> > > > > >
> > > > > >2) The request is "well-formed" but asks for the status of a
> > > > > >certificate for which the keyless responder has not prepared a
> > > > > >response.  This situation will occur if:
> > > > > >
> > > > > >     a) The request is for status of a certificate from a
> >supported
> > > > CA
> > > > > >but with a serial number for which there is no pre-signed
> >response.
> > > > > >Assuming presigned responses exist for all certificates that
> >would
> > > > be
> > > > > >valid based on their validity intervals, this would occur if
>the
> > > > > >certificate had expired or was yet to be issued (I am aware the
> > > > > keyless
> > > > > >responders generally produce responses for certificates likely
>to
> >be
> > > > > >issued before the next generation of presigned responses). The
> >keyed
> > > > > >responder would give a signed "good" response. My understanding
> >is
> > > > > that
> > > > > >the keyless responder under the draft lightweight OCSP responds
> >with
> > > > > an
> > > > > >unsigned "unauthorized" error code.
> > > > > >
> > > > > >     b) The request is for the status of a certificate from an
> > > > > >unsupported (or non-existent) CA. The keyed responder would
> >respond
> > > > > >with a signed "unknown" response while under the draft, the
> >keyless
> > > > > >would again respond with the unsigned "unauthorized" error
>code.
> > > > > >
> > > > > >Some might argue with some grounds that these differences are
> > > > unusual,
> > > > > >unlikely, and insignificant.
> > > > > >
> > > > > >I personally consider the behavior in 2 of responding with the
> > > > > >"unauthorized" error to be misleading. "Internal error" sounds
> >more
> > > > > >appropriate if I were constrained to the current error codes.
> > > > > >"Malformed request" might be OK. However, the actual situation
> >does
> > > > > not
> > > > > >match well with any of these errors as they are described in
> >2560.
> > > > > >
> > > > > >If 2560 is supposed to encompass keyless responders, I'd
> >recommend
> > > > > >identifying the unavoidable differences and/or adding 2 TBD
>error
> > > > > codes
> > > > > >for the above cases (assuming they are the only differences).
>The
> > > > > first
> > > > > >error can be worked around by breaking the request for status
>of
> > > > > >multiples into multiple requests for status of one cert.
> > > > > >
> > > > > >We've also seen some problems with client apps that can't
>handle
> > > > > >presigned responses that commonly contain the status of several
> > > > (e.g.,
> > > > > >15-25) certs. The apps inquired for the status of a single cert
> >and
> > > > > >apparently expected a response for a single certificate. I'd
> >suggest
> > > > > >that some "must" or "should" words address clients' ability to
> > > > handle
> > > > > >the situation of a response covering multiple certificates.
> > > > > >
> > > > > >
> > > > > >
> > > > > >Bill Price
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: [e-mail]
> > > > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > > >To: Michael Myers; Dave Engberg
> > > > > >Cc: [e-mail]; Sam Hartman
> > > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
> >2560
> > > > > >
> > > > > >
> > > > > >Mike:
> > > > > >
> > > > > >I think it is not that simple.  I think you need to say that
> >support
> > > > > >for one certificate MUST be supported, and that support for
>more
> > > > than
> > > > > >one certificate is OPTIONAL.  Then, the error is am indication
> >that
> > > > > >the requestor has selected an unimplemented OPTION.
> > > > > >
> > > > > >Russ
> > > > > >
> > > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > > >Responders unable to produce or acquire a definitive response
> >MUST
> > > > > >return <a
> > > > > > >TBD error>.
> > > > > > >
> > > > > > >As to your other points Santosh, that is something I prefer
>the
> > > > > chairs
> > > > > > >consider.
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > > >
> > > > > > > > Mike,
> > > > > > > >
> > > > > > > > What is the error case?
> > > > > > > >
> > > > > > > > . . .
> > > >



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 kAFKDNKg096960; Wed, 15 Nov 2006 13:13:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFKDN35096959; Wed, 15 Nov 2006 13:13:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFKDJQi096923 for <[e-mail]>; Wed, 15 Nov 2006 13:13:20 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15972 invoked by uid 0); 15 Nov 2006 20:13:13 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 20:13:13 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 15:01:48 -0500
To: "Peter Rybar" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: RFC3280bis: NotAfter 99991231235959Z
Cc: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would hope that the time function would not be called with this 
input.  The point is to flag the value as not expiring.

Russ

At 11:39 AM 11/15/2006, Peter Rybar wrote:
>Some utility written in C language time (The time function returns 
>the number of seconds elapsed since midnight (00:00:00), January 1, 
>1970,) will crash. ;-)
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Wednesday, November 15, 2006 3:56 PM
>To: [e-mail]
>Subject: RFC3280bis: NotAfter 99991231235959Z
>
>
>I would like to add some text about certificates that are not
>intended to expire.  I propose the following paragraph.
>
>In some situations, devices are given permanent certificates.  For
>example, a device could be issued a certificate that binds its model
>and serial number to its public key.  Such a certificate is intended
>to be used for the entire lifetime of the device.  It indicate the
>permanent nature of such a certificate, the notAfter SHOULD be
>assigned the GeneralizedTime value of 99991231235959Z.
>
>Any concerns?
>
>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 kAFKDLR4096955; Wed, 15 Nov 2006 13:13:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFKDLVN096954; Wed, 15 Nov 2006 13:13:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFKDK8Y096944 for <[e-mail]>; Wed, 15 Nov 2006 13:13:20 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 16007 invoked by uid 0); 15 Nov 2006 20:13:14 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 20:13:14 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 15:09:28 -0500
To: "Julien Stern" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

No.  That device is still that device.  The certificate is not making 
any statement about the ownership of the device.

Russ

At 12:28 PM 11/15/2006, Julien Stern wrote:

>On Wed, Nov 15, 2006 at 09:55:47AM -0500, Russ Housley wrote:
> >
> > I would like to add some text about certificates that are not
> > intended to expire.  I propose the following paragraph.
> >
> > In some situations, devices are given permanent certificates.  For
> > example, a device could be issued a certificate that binds its model
> > and serial number to its public key.  Such a certificate is intended
> > to be used for the entire lifetime of the device.  It indicate the
> > permanent nature of such a certificate, the notAfter SHOULD be
> > assigned the GeneralizedTime value of 99991231235959Z.
> >
> > Any concerns?
>
>If the device is somehow stolen or compromised at some point,
>doesn't this mean that you will have to keep its serial number in a CRL
>(or an other revocation system) until the end of times?
>
>When faced with a somehow similar issue, we decided to set the date to
>the expected lifetime of the device plus a few years to avoid the above
>issue.
>
>--
>Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFJK2o4085944; Wed, 15 Nov 2006 12:20:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFJK2OI085943; Wed, 15 Nov 2006 12:20:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFJK0As085917 for <[e-mail]>; Wed, 15 Nov 2006 12:20:01 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 11:22:01 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccIy24Q79KVECfgTEKKI36Ed9P0qgAH6a2A
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFJK1As085931
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

The OCSP field in the AIA extension helps the OCSP client locate an OCSP
Responder.  But, to verify the signature on the OCSP response, 2560
mandates three trust models: explicitly trusted, CA only, and CA
delegated.  The OCSP field can not extend those options to other trust
models.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Wednesday, November 15, 2006 10:32 AM
To: Santosh Chokhani; [e-mail]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh:

My point is that the request could be for any set of certificates 
that contain AIAs that point to the same OCSP responder, whether they 
are part of the same certification path or not.

Russ

At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
>Russ,
>
>I do not know how germane this debate is to Sam's question, but I was
>simply responding to the issue building certification path.  I presume
>that in this context it relates to building a path to the Responder
>certificate.
>
>Now let us look at the three model 2560 has: Explicitly Trusted, CA and
>Delegated.
>
>Explicitly trusted does not need a certification path and hence there
is
>no issue and that is why I did not include it in.
>
>CA model does not need any path building since path to the CA has
>already been built and that is why I did not include it in my response.
>Note that both clients requires the CA to use the same to sign the OCSP
>as it signed the certificate in question with.
>
>My post responded to the Delegated model.
>
>I hope this clarifies that the path building should not be a major
issue
>for all three models 2560 supports.
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 6:42 PM
>To: Santosh Chokhani; [e-mail]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>I believe this is a red herring.  This is not the only deployment
>approach supported by RFC 2560.
>
>Russ
>
> >In hurry, I did not clearly articulate my thoughts.  What I am saying
>also
> >relates to another comment to Mike Myers regarding the security of
the
> >delegated model which is incompletely addressed by 2560.
> >
> >I will be verbose this time.
> >
> >The implementations such as Corestreet and Tumbleweed tend to adhere
to
>the
> >approach that the same key that signed the certificate in question,
>sign the
> >OCSP Responder certificate.
> >
> >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
>want
> >the status of CA certificate and the Subscriber certificate, you get
>them as
> >responses and with them you only need the two OCSP Responder
>certificates
> >one signed by the Root (for verifying CA certificate revocation
status)
>and
> >one signed by the CA (for verifying the subscriber certificate
>revocation
> >status).
> >
> >You do not need any paths.
> >
> >Please note that the approach also works when the Responder is
queried
>by a
> >CA cross certified by the root, since rest of the path has been built
>by the
> >client.
> >
> >-----Original Message-----
> >From: Dave Engberg [mailto:[e-mail]]
> >Sent: Tuesday, November 14, 2006 12:45 PM
> >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> >[e-mail]
> >Cc: Sam Hartman; Michael Myers
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >CoreStreet's OCSP server doesn't include a SingleResponse for the
>issuing
> >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> >
> >Adds 90-100 bytes onto every response
> >
> >Have never seen a relying party app/plug-in send a request like this
> >
> >The "delegated" trust model in RFC 2560 would require different
signing
> >certs for trusting entity vs. CA cert ... add another 1kB onto the
>response
> >
> >Protocol only sends CA name+key info, which isn't enough to identify
>which
> >CA cert the relying party is inspecting in the case of CA cert
renewal,
> >cross-certification, etc.
> >
> >
> >-----Original Message-----
> >From: Stefan Santesson [mailto:[e-mail]]
> >Sent: Tuesday, November 14, 2006 12:11 PM
> >To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
> >Cc: Sam Hartman; Michael Myers; Dave Engberg
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh,
> >
> >I didn't say it was hard. I say that I doubt that there are many
> >implementations supporting this scenario even those with a responder
>key.
> >It would be interesting to hear from implementers if I'm right.
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: den 14 november 2006 03:59
> > > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > > Stefan,
> > >
> > > You are making more complex than it is.  The Responder can include
>all
> > > the CA certificates that issued the certificate in question and
AIA
>can
> > > do the rest.
> > >
> > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > environment, the CA certificate certification path is not an
issue.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]]
> > > On Behalf Of Stefan Santesson
> > > Sent: Monday, November 13, 2006 6:54 PM
> > > To: Russ Housley; Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I'm not sure the case described is a realistic one.
> > >
> > > Section 2.2
> > >    All definitive response messages SHALL be digitally signed. The
>key
> > >    used to sign the response MUST belong to one of the following:
> > >
> > >    -- the CA who issued the certificate in question
> > >    -- a Trusted Responder whose public key is trusted by the
>requester
> > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > >       specially marked certificate issued directly by the CA,
> > > indicating
> > >       that the responder may issue OCSP responses for that CA
> > >
> > > Since the request is on certificates issued by 2 different CA:s
>trust
> > > option 1 is invalid.
> > > Trust option 3 is valid in theory but in practice it requires that
>the
> > > OCSP responder provide multiple validation paths in the response,
>one
> > > for each issuing CA. Somehow I doubt that this is implemented by
> > > anyone.
> > >
> > > Trust option 2 is not generic and is only valid as a result of a
>local
> > > configuration.
> > >
> > > So I don't think this is a problem only for key-less responders.
> > >
> > >
> > > Stefan Santesson
> > > Senior Program Manager
> > > Windows Security, Standards
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:owner-ietf-
> > > > [e-mail]] On Behalf Of Russ Housley
> > > > Sent: den 13 november 2006 14:08
> > > > To: Price, Bill; [e-mail]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > > >
> > > >
> > > > I prefer an error that tells the client to ask for the
certificate
> > > > one at a time.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > >
> > > > >I'd suggest focusing on understanding where responses to the
>keyed
> > > and
> > > > >keyless responders inherently differ. I am aware of two general
> > > cases:
> > > > >
> > > > >1) The request asks for the status of multiple certificates
that
> > > have
> > > > >not been included in a single presigned response. Russ's
example
> > > fits
> > > > >into this case. The keyed responder handles, but the keyless
will
> > > fail
> > > > >for the general case. Some responders respond with the
presigned
> > > > >response that includes one of the certificates (usually the
>first)
> > > in
> > > > >the request. A common situation is to ask for the status of
> > > > >certificates in a chain. Santosh points out some keyless
>responders
> > > > >anticipate this and bundle responses accordingly.
> > > > >
> > > > >2) The request is "well-formed" but asks for the status of a
> > > > >certificate for which the keyless responder has not prepared a
> > > > >response.  This situation will occur if:
> > > > >
> > > > >     a) The request is for status of a certificate from a
>supported
> > > CA
> > > > >but with a serial number for which there is no pre-signed
>response.
> > > > >Assuming presigned responses exist for all certificates that
>would
> > > be
> > > > >valid based on their validity intervals, this would occur if
the
> > > > >certificate had expired or was yet to be issued (I am aware the
> > > > keyless
> > > > >responders generally produce responses for certificates likely
to
>be
> > > > >issued before the next generation of presigned responses). The
>keyed
> > > > >responder would give a signed "good" response. My understanding
>is
> > > > that
> > > > >the keyless responder under the draft lightweight OCSP responds
>with
> > > > an
> > > > >unsigned "unauthorized" error code.
> > > > >
> > > > >     b) The request is for the status of a certificate from an
> > > > >unsupported (or non-existent) CA. The keyed responder would
>respond
> > > > >with a signed "unknown" response while under the draft, the
>keyless
> > > > >would again respond with the unsigned "unauthorized" error
code.
> > > > >
> > > > >Some might argue with some grounds that these differences are
> > > unusual,
> > > > >unlikely, and insignificant.
> > > > >
> > > > >I personally consider the behavior in 2 of responding with the
> > > > >"unauthorized" error to be misleading. "Internal error" sounds
>more
> > > > >appropriate if I were constrained to the current error codes.
> > > > >"Malformed request" might be OK. However, the actual situation
>does
> > > > not
> > > > >match well with any of these errors as they are described in
>2560.
> > > > >
> > > > >If 2560 is supposed to encompass keyless responders, I'd
>recommend
> > > > >identifying the unavoidable differences and/or adding 2 TBD
error
> > > > codes
> > > > >for the above cases (assuming they are the only differences).
The
> > > > first
> > > > >error can be worked around by breaking the request for status
of
> > > > >multiples into multiple requests for status of one cert.
> > > > >
> > > > >We've also seen some problems with client apps that can't
handle
> > > > >presigned responses that commonly contain the status of several
> > > (e.g.,
> > > > >15-25) certs. The apps inquired for the status of a single cert
>and
> > > > >apparently expected a response for a single certificate. I'd
>suggest
> > > > >that some "must" or "should" words address clients' ability to
> > > handle
> > > > >the situation of a response covering multiple certificates.
> > > > >
> > > > >
> > > > >
> > > > >Bill Price
> > > > >
> > > > >-----Original Message-----
> > > > >From: [e-mail]
> > > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > >To: Michael Myers; Dave Engberg
> > > > >Cc: [e-mail]; Sam Hartman
> > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > >Mike:
> > > > >
> > > > >I think it is not that simple.  I think you need to say that
>support
> > > > >for one certificate MUST be supported, and that support for
more
> > > than
> > > > >one certificate is OPTIONAL.  Then, the error is am indication
>that
> > > > >the requestor has selected an unimplemented OPTION.
> > > > >
> > > > >Russ
> > > > >
> > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > >Responders unable to produce or acquire a definitive response
>MUST
> > > > >return <a
> > > > > >TBD error>.
> > > > > >
> > > > > >As to your other points Santosh, that is something I prefer
the
> > > > chairs
> > > > > >consider.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > >
> > > > > > > Mike,
> > > > > > >
> > > > > > > What is the error case?
> > > > > > >
> > > > > > > . . .
> > >




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 kAFJAOTR083422; Wed, 15 Nov 2006 12:10:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFJAKMT083404; Wed, 15 Nov 2006 12:10:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFJAD7Z083369 for <[e-mail]>; Wed, 15 Nov 2006 12:10:14 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAFJA4Hf080884; Wed, 15 Nov 2006 12:10:04 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sam Hartman" <[e-mail]>, "Paul Hoffman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 10:33:21 -0800
Message-ID: <[e-mail]>
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.1807
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

How about we expand the meaning of "unauthorized" to mean EITHER the
requestor is not authorized to ask the responder OR the responder is not
authorized to fulfill the request.  That's not *too* ugly, is it?

Given that, everything else (i.e. MUST support singles, SHOULD support
multiples, else respond with error) falls out pretty clean without impacting
extant deployments.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sam Hartman
Sent: Wednesday, November 15, 2006 10:16 AM
To: Paul Hoffman
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560



>>>>> "Paul" == Paul Hoffman <[e-mail]> writes:

    Paul> I also do not see how we can handle the problem without
    Paul> changing the OCSP version number, but I would really like to
    Paul> be wrong about that.


You can decide that the interoperability hit of changing the version
number is worse than changing the meaning of the old version
retroactively.  It is always hard to make that call, and you better be
right if you decide not to change a version number.  But it is a
tradeoff it is valid to consider.



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 kAFIGIFF072593; Wed, 15 Nov 2006 11:16:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFIGIPS072592; Wed, 15 Nov 2006 11:16:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFIGG9h072576 for <[e-mail]>; Wed, 15 Nov 2006 11:16:17 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6D193E0035; Wed, 15 Nov 2006 13:16:04 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Paul Hoffman <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail] oft.com> <[e-mail]> <p0624087fc181032b0471@[10.20.30.183]>
Date: Wed, 15 Nov 2006 13:16:04 -0500
In-Reply-To: <p0624087fc181032b0471@[10.20.30.183]> (Paul Hoffman's message of "Wed, 15 Nov 2006 09:51:32 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Paul" == Paul Hoffman <[e-mail]> writes:

    Paul> I also do not see how we can handle the problem without
    Paul> changing the OCSP version number, but I would really like to
    Paul> be wrong about that.


You can decide that the interoperability hit of changing the version
number is worse than changing the meaning of the old version
retroactively.  It is always hard to make that call, and you better be
right if you decide not to change a version number.  But it is a
tradeoff it is valid to consider.



Received: from 132.red-82-158-246.user.auna.net (132.red-82-158-246.user.auna.net [82.158.246.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFI393C069792 for <[e-mail]>; Wed, 15 Nov 2006 11:03:16 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000f01c708e1$3c6d5350$00000000@richard>
From: "likely" <[e-mail]>
To: [e-mail]
Subject: attitudes towards make
Date: 	Wed, 15 Nov 2006 19:09:47 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C708E9.9E31BB50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000B_01C708E9.9E31BB50
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C708E9.9E31BB50"


------=_NextPart_001_000C_01C708E9.9E31BB50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Might am bethe Anton Webern.
Standing class musicfor whereas incomes. Orchestras film companies =
schools work in seeking contracts variety.
Press a features image.
Harmonic rhythmic greatest latitude thought imagined of. Material quite =
a strict?
Textbooks Wikibooks Quotations a Wikiquote texts Wikisource Images?
Understood learned edit?
Disagreed a must consist Instead in he argued any of. Genre detail =
explicitly.
Completely lost Recent Evelyn.
Modernera am concertos concerts is halls sitting quietly seatson hand.
Receive in credit of taking am overview. Notes External linksedit =
article musicsee genrethe broadest There are!
Uniquely am humanmusic technical manner refers.
Ornaments trills turnsin give without a describing devices obtain =
expressive? Notes External linksedit article musicsee genrethe broadest =
There are!
Sister Dictionary Wiktionary Textbooks Wikibooks Quotations Wikiquote. =
Wikibooks Quotations Wikiquote texts?
Groups works or described.
Single society am does not pass same a place short rarely? Ballet scores =
of serialism bebopera or rap punk nonmusic critics a when?
Created playing vocals of whole direct expression emotions designed =
manipulate.
Helped outcomes patients of Owen Johnson.
Approach specific in piecesfor.
Standing class musicfor whereas incomes.
Research relatively am credential.
Took newspaper protesting ad appeared.
Where front Naxi who or performs.
Took newspaper protesting ad appeared.
Largely standing of class musicfor whereas incomes hiphop innercity a =
area.
------=_NextPart_001_000C_01C708E9.9E31BB50
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"might" hspace=3D0=20
src=3D"cid:000a01c708e1$3c6ae250$00000000@richard" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Might am bethe Anton =
Webern.<BR>Standing class=20
musicfor whereas incomes. Orchestras film companies schools work in =
seeking=20
contracts variety.<BR>Press a features image.<BR>Harmonic rhythmic =
greatest=20
latitude thought imagined of. Material quite a strict?<BR>Textbooks =
Wikibooks=20
Quotations a Wikiquote texts Wikisource Images?<BR>Understood learned=20
edit?<BR>Disagreed a must consist Instead in he argued any of. Genre =
detail=20
explicitly.<BR>Completely lost Recent Evelyn.<BR>Modernera am concertos =
concerts=20
is halls sitting quietly seatson hand.<BR>Receive in credit of taking am =

overview. Notes External linksedit article musicsee genrethe broadest =
There=20
are!<BR>Uniquely am humanmusic technical manner refers.<BR>Ornaments =
trills=20
turnsin give without a describing devices obtain expressive? Notes =
External=20
linksedit article musicsee genrethe broadest There are!<BR>Sister =
Dictionary=20
Wiktionary Textbooks Wikibooks Quotations Wikiquote. Wikibooks =
Quotations=20
Wikiquote texts?<BR>Groups works or described.<BR>Single society am does =
not=20
pass same a place short rarely? Ballet scores of serialism bebopera or =
rap punk=20
nonmusic critics a when?<BR>Created playing vocals of whole direct =
expression=20
emotions designed manipulate.<BR>Helped outcomes patients of Owen=20
Johnson.<BR>Approach specific in piecesfor.<BR>Standing class musicfor =
whereas=20
incomes.<BR>Research relatively am credential.<BR>Took newspaper =
protesting ad=20
appeared.<BR>Where front Naxi who or performs.<BR>Took newspaper =
protesting ad=20
appeared.<BR>Largely standing of class musicfor whereas incomes hiphop =
innercity=20
a area.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000C_01C708E9.9E31BB50--

------=_NextPart_000_000B_01C708E9.9E31BB50
Content-Type: image/gif;
	name="consensus.gif"
Content-Transfer-Encoding: base64
Content-ID: <000a01c708e1$3c6ae250$00000000@richard>

R0lGODlhHAIwAof2AAAABoEEAAyKAHx1AAgAh3IMfACEe7nHzr/mwajP6kIVAFIfAI0ZBq0oAL4V
Cd8jBgI6DB40AE4xBmZMC4NAAKE8AMNJDOA3DQBmAC5YBDNZDGxqAH5iAKRXALFTANVlAAB1CxN5
CTmOAGSNAnV9B52BAM50Bu57AAijDSOfAEygAGuYAH6VCJulAMuhB+2kAA28BRPLAEfDAlXBBn7B
DJO2CM3OAOPDAADfABffADvrAWDhAIHUCZXWAL7eBODWAgAEQRYAP0YANFYDS4sAMZwDSsECTuwG
RAAgNCYtOEwfNWgoP4QYTpcoSsYiQ+wYSgA0SRYyMUNMSmFEN3pERahIS8YxTuU8NABoPxdfSzVo
RmBoTXtsC6hRSbFhTdhkMgB2RBiJREqLPVZ9P3+JO5mJR7R4Md16OACqTRKTOT6dRlmWTXqaO5eU
Os2sRNSTNADMSifMPkG6Qm7KTXXHOaS2OrW2Pu7MTAzYMy3YSU7fOWLVQH3YRpLcRc7ZRdnpMgMI
hR0FdT8NglUHhoUFeJkAiMAJhtUAhggWfCwdeDkfimYVfXcidZcdccIYftYijAAxhxxAh0hAf2lH
gHVHe59CgrY3i9dLiABrjB5WgDhdd1Vqd3ZqealhicRki+BacQB4hRlzdUeJfmWNjoaAjZp6g7OE
h9yKcQCaeyOnckuni1SqfI6nip6Se8Objuitige3chnLgkjDjmDNg47Aeqy7jrPAd+G3cgTngyzT
gjLmgVnhdYvpfZbefrfkjujddwAAtBQAuTENvWUAyXYLwJgHwcQCxuUAvQAXySIavz4Tt1YtzHIs
uaEuy7YTxt0VugA2xxZMsTlNs2cysoVKuZ1LvsdNueI2vQBVzSBUwTlewmpezIhouKVksrNgyuxX
xw5+syR4xEp1w1R+yHN7x6SDxMN0tNd+vwCRxxupuzOVvFulxYqlv5ypvribu+SrwQq1vR2+xTq5
vF/IxIXAuJnIwv/u9p2XsHGEg/8LDAL8BPn3BgwJ9/MA9wD8/////SH5BACp5wMALAAAAAAcAjAC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBnaG0mypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQFXOCEq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXcu2rdu3cOPKTRuyrt27ePPqBZlnr9+/gAMLnku4sOHDiKEKXsy4sePHkCNLPth3
8t3EmDNr3sy5s+fPoEPLzciyYVjTPFF/Va2TdVfXJy3Lnu2xtEiwsG/m1rq7Zm+sv+3RHk68ou2F
p2/vDG6VeUznVIMXn05dOQAA9q6TbPihu/fv3k+C/+8ufnx4luRNqtaunSV77CMbCphPvz79k/bn
489/n6V+9dZh195K723HED8IJqhggictiGCDDjLI0oMAIjdSgfFVpyFgPWH40nkgpkfSefaQWBKJ
Jpb3wU0eqtRiS/3F+B9J/dlTY0k13rifACwKCB+BPsYk4ZAUkiShPUeWdGSSEPLTY3Y/ivYWaSRd
FyV36YW44ogicqniiV2alKJwykEZJZBXMiQjjzbO2CabOMJJo5s6xilnhhZeOKB7ezZEpJNIFhko
oEoSaqSgTBZqKJ4KlWRlSRtGqqGZVj6KJZdblpjpmJpmOpKJnHYapmmVlppSqZWSudCMOcJZ55sm
3f/46ptuqtooqo+ihKt2fhK6pK+CHrpokomOtGCFt+5qq6TMzuZon2V2mlKYYIrZZajgIZvQs2e6
CG2eI81aa5yx0jluuPVpixC3L+XK6LaKphRsoSYRO6+xCqp7ELsGNutvbTy9GBOnoUqLabXTfmeT
wCcx/NKrs8I6p5znohtxSw4/C6VNxRaLr6H2qnRsTRlLKVrJ6FFrMEqgZontlgXzubHMe8oEccUS
W2zxnXPqTBPKG9cs5L0eDxrvoIse+jHJQZo8JUbHNQqmpwcn7Kl5K7nsKXQvuXYzzxPbma5K/93I
tUuudXzv0sLmKzKgSUr379yRRQ1v1dZSPfXeCif//CmJZ7fk9bkRy6rf2CiVXWPgdq97dL1rGy0s
0m9/TKjcdGfOWOP77v2l1Z6/jPW7ji8X7ddkm8umuPzByfhKaRMdub1wrx1hkZhrrvtfnBuUt9/A
403w1SK+rtLgYLeZermuEk7xjManFHvS+Fb+uNqP57779nj1XtDvLKucIorj631e9CghnxLqdk58
57j9oR9btB6rPWyRbisNOaDac+8/SN4jCPjCR7UxtayA5kuP/PTlu/atr1Z1Mtz7eBa/aOFkem+7
X9JoB7kmka5zx/ufCEFolZiRT28r+9umqNW3rlysVWDTEQx3lLyrFE1yOHwc23JoOaf5kCqjI2AL
/zHVQvP0LYhZ4U/q7ENDGLZuZxeTSoQymL+2/ep2tRvZDz1DpRCC6zUW1E0YeTNG35QROGdc1ghH
uMU2uvGNcIRJF6WXxubU8Tl3jE4eu7ZHqfRvjf+LoyAHSchCGvKQiEykIhfJyEY68pGQjKQkg0KN
SVrykpj0SSUzyclOetIpgAylKEdJylKa8pSoTKUqV8nKVrrylbCMpSxnSctadu+TuMzlJ23Jy176
8pfADKYwh0nMYhrzmMiMiC6XycxJJvOZ0IymNKdJzWpqrpnYlIo8ssnNbnrzm0CxpjjHSU6HgPOc
6EynOtfJzna6851uLGcxGyHPekIEnvjMZ1nsyf/PfvrznwANqCv1SdCCGvSgCE2oQhfK0IY69KEf
FKhEJ8pKiFr0ohjNKE7wodF+WcSZX+xoZ6QJUqmJ9DMklWQfTzqaaJb0bukUmiC/9UySbOKmNy0L
Tm26iacwRFl6cheqGtatKuGKUkJN1cz0ZCajGjWpulLqU9uTqqMitahODeqAgIrUqCbVXUQdqlZ/
JFaNoWmrUl1qSnM6EraKZadt7Sko81QztDL1rlkFkllNYtc9vYes8LHrUvMq2JlRtVt+xWph63qm
wmb1sHg9VWMBi1fG6vWukM3qK3fi1pPg1K2f7Slc7RFaucZ1tKXlqWpR8tm48hS1rR0taVu72if/
5ZWpjk1rVPd629v+NbBNc6plNSZTwyIWq0SN7GATizHgYjZKw1WuhxJbXMtmVrlSIk1nSwJaue70
u95l63ZdO9vwkne2KaHteNFb3vaK17Td9eLdmEtcyk5VZr0drG99BFnrTpavwQUwdosrYOlC98DN
fW5ko6vf6R64uv+9LlM3q5P1spe97yVvfD1r3vPm1MLo/bBpudvhDF8YxEzjbdCc+1jkLneoMlVW
gV5E4wgrFrimuqpke0tf7IY1V2XdMY+bRt8Y21i3BGakhTdsYhOfOLQehq9oR2yS93ZXvSUOL5Q7
hOD6gtW4lx1wUZl72Bo32MZaVTB+C3xm3ia5/7LBTXKPcYtkFrOZzvu95JKlrOEsr5bJfHYtiK3c
YQz7+cJAmfOKF5xjIYt5t8LFcYAXreIWZfbN+oXznRUNaUpn2s1ofrFuDbxUToeGSoD+86FT3efa
tlclV45yqw1dWxAHiM3XlTCBTd1XBKPVzhLWtLCD/eJOl/q/exVarwmLbGYPu8uLBTaCU1rezm6Z
1oam7WnhuuHTriTW225yoa+NaAYKUMxQjbSKQd3oHJMZsPD+9VcZW9VHWTXImx61sket436TGsDp
xnOLuSVv+lJYKyiWScJZShRMw9Hh4Fw4TCTO8ES7+OEX5yLUgELxlnRcjyaNaca3SNNVVvzkKP9P
ucpXzvKWZ/TjH3e5zJNzkXBTmSYwv3lQVpq+hPTj50D/OUmC3o+hE/0kQvcoRZfOoQqPOOYcjgnU
0ZJ0o1vdHlWv+ki0PnOL7lnV4JWytqsd6HLDRetcF3rWi250rnfdm9rV+ZO9DV5vY/vuU+djyM1Y
OrSz3eprL0nQlc50kDyj8ABLrWpZ7eTGF9ooPJ9f3/+OdcpX/vKY3zrbk474zleHtXxm/LhHf17I
h3QmJvW7SdQ+eMFvnu2ejz1xQL/4QItb1bhHSuTN/Y+ra371RU+631sv++LLBtHWTv6sWY13ubfm
9DJJveUDn3nhU17oxs/+Rnii+NeSePnkvnb/t+Xi9qP/HvDXt/zbRZr39bsfku1/v/znMsf0Ot8s
u4cUTImi/f43xqfQNxZ7t3P+V4D3NH8ImEv1pxT5Z0elUxQGGIF5IXX3h0cDuE/wAgEQwH8S2IEP
eBPdl0kaaBIaWIIoUYIoaA8oaIIJaFDjZ0kruIEjOBIzqBIjWIMtiFCAVnfhRmKyFX9ukYIkUYM4
eBIzWIQ5qIBQs4O513y11YBVoRBCSIMbSIUrcYQrGFEeuIUfxXx3932lp38XSBaNwoJWeIYnWIVG
uIFc2Ia953TapnxmR3ZASBhCSIRquIYpgYRJiEkHAQzKtF5yKIgVqIUDsRZSc4MyqIZ8qIJ5/0iC
bOh5fOCG5uR0tNeEjudqoKGIjjiEVYiDoMiIj9iH7kSIYEh2PiiHm5iFVGiGeLiGZkiKsogZjTiL
tihItXiLuriLvNiLvghPC+hDYzSGdESJxrgXcDSM+xdAx9iMhygVdbgZ+ZAPv8hwIcgS0UiH2fht
hfgT05gS31iNDjV12xiGRVGOLjGN6kiNJKGO4jiO3Whzr9VtCTde4odlcZiPsEUU63gS/fiOLXEA
frhxFPeCszaHp3iJ+3iQL+hWyogQ/9iO1BiOzliRddGD8jh3USdohYhiTqaR9Hh/D7kv7iiRI0GR
FpmS5+YTHll23SdiHndziqeKhLaQS/GP6/9YkgDJTAvYkpgYeh1JZV7ohQkpectoiCc5kexokmqk
ks7IWWWnkJnofTFZZbb3dFoma2GIjv6olCYRjjvJkwQ5dvanjz8ocfa4Zdv1kmRpkyNpEDm5lEzp
lHS5cUfBldgYj7ADfVIDlvJVl4B5gHepl1CZE2/5Pfbgl8UYmMcYFngJerIVljkYjIZUJsTIFYwJ
UI1kmUfpFZn5T5sJLpe5FZ/pT5tRjpz5gUsRWARilKXZSz1BbkrRklhJmAhpf0fRWDjBb45yIb7Z
MJJ5GKgWlUlBmz6ocISJYql5ELrJIlXSmtkBnWL4mvKEkDsoYtxmlle2Z4Q2j2IHk08GW27/KZoJ
0ZxKFSRkxVfPGZ3ryZrsCWRN1ZTUaU3WeZViV2tZqZFlqWU6Z2W1h5+a6JDkuS7pyZ6+uVXrmaDu
+ZvuKSDPiaDz6UuFeYlfSJOkZ47fF1v9+XhjF5JIUaDQZaAH+mML+p4MKqIiOnLByRlfd5DIN5Mu
eX/YOWXeyaFryZZJ4aBjpaMPCpw92p4nGp8huqI/1KIVipUUapBgeHsu2qFy95jAWaC92ZuIRaVT
2qDqOaRE6kOiZ6OnOJW3iW1TqXweupW2CRNaGp1V6qMjilknmp5puqVq0UXhp5ZImooxepwUip9Y
tqTfKZTdtpwNhKLnyaYEB28mmqjw+ZwR/wqbLqeichqpTbErlFqplnqpmPplkoqBNcdIgoqYPwOA
jTpOnfSpK+mZo9pKm7qqrNqqrvoSUAelr3pQ17gWCyerOqFF1JOrNzSrNNeFxKkWt3qmegdTCjEs
xhIUviJHqVpRlhhlZxmt2zllf/pqGEmHeFqtGDmtNVqUOUE9x0IhbuMkVxQsy4okSoKuyWoSYOCr
bsF8Y2qf7pWVPMiETriRL6qV2amJ3yov1bOuyYo/6gqwAAs36Xqu7opGNQemHwmgYrpqFwqvG+pq
8cqvhigQ0+k7ukqwIDOw6NqxiiKu6fqxF9usv4SKNfp4DsukLAujP9mtpVexGCqfpzqABv/rsR2b
syNrJAc7suRasiYLm2DqrSAJseCXpBGbpy+rn7yHsYR3qut6sxyLs1S7syTLs1cbtMhUtEsrekd7
r12qlfnKtWJrqgOBrOoKsgHbs/+KtWvbtpejtcY0tnUqrVf5tdwqtmzppKNnk4E6oPuiRTw0rj77
IBqEP4brtnI7t5xktk5bFLvqEnG7uMNUqoBrEFiUuZq7uZwbIZRrSrxYRTIRuQk7FZ97uqibuqr7
GKXbuq77uj+0urK7tbBbu7Z7u7ibu480u7zbu777uw+hu8I7vMT7q8B7vLFUvMr7fMjbvM77vNAb
vdLrL8tbvTZxF4Uwvdq7vdxrT9b7vdH/173iyz3gW77me77om76pMb7se03q+77wG7/yO7/063Ib
YLztm7/6u78FuH786z/1W76UuXL/O0vWsxmR8xIJjJkFnLxtGyg4ITsO0hO3MzQRTLrygsErIbrh
28DuuxOIosETQroLfME0UcIj3BQoHMBxkT8TbDm1ozSCSy8hm0XiysE0bEU6/MIvjDTAAsNWFMM+
3DYZDMPA8issjBYufMMQXD2I+8AQksOGazuRG8IyrEFOzMRPDMFPvMVTfMVQ/K9E0sQdlMRLQRpM
TMZfnMX6k8BWzMZFHMdwS673A8Zw3MRrzMU/rMd2bD1djMEe7D/TQBF4LMR8fMdpLMdq/0zH+1M0
IRyudYzIjCzGk3zIhezDN0zFc0zGi1kRFRDImYPJm/zHbUzCIPPDb8zJZRzG5orKrlzKixzLlowS
sjPKgKwQzgDK1MGr9ELKcDzGBxzLb+zIp9zHttzHWvzKkpPHa1zLwgyuImzGNlTMPayr1ryrrQzM
QRzMQwzEvlzISNzNogzOiCvBlZzJWyzNumeX2LTC66zL/8KrnTvP9FzP9nzP+JzP+rzPmavO8zfD
/lwYAxzQpie7BD1XBr0WLgap7vEWDB2qiaYTD72+sttoMjHRCOqcLrITE72bCbowBtrRMcGjASPR
I03Rq/ubSpHRIL3RJr2aPyGlQSHSGP/z0k3BuyotpO9ZV0EFcFnKoFTVnvLW0wT3VEYdn5Ti0zrN
X4iqpkRtb0/9ZVjKX0mt1PpWZqzJ1Edt1L8WpIuqplL91TgG1l0d1WeC0yH9oGvapi7dpjz61j+d
0yn60U6toGn90XC6oHCtbGkNp3j9pneNoj8612ztoHv914nao3rd14hd147t2IdN1097uirt1/el
1l41pIZdqPF212kFovYWb3Dd2KMN2SkK1YUd2E5t2IE9WexB2oy915/t1aE9VZFN2KaNoHld2z6W
mSVd2a09pcuF2Kwd15Zt2nYtpa8t3Gl63M4d3M8t06xd3Kr93Mmt2IytK4A9oiWa3bj/XdqvfdzJ
RtMORSXKHdyNXd3CZdfAbd3t/dfu/d3QPdjRTd/qud3qndrXzd3erdmpndX2Ld32jd36ndPuidYP
ZuBgRdUAp6VlJtxVfZ4LPm9ITeH8ItZfpeD99dR0DaK41eGoTahBzd+gbZ5AvdxkfV91NtTwWeJm
vZ6+7U7k3Ugz7osD7Ug1vkg53hNofdAceLw+DoERGtFXseOY0ZxGYeQ1nWDmaypI/hRKvtJt3dAQ
TeCCLZ1TLtgjl3FxKtcafeUtaN6SLRVRnqNQgeQizeVLnhNqztHXi7yVvagTXtZYitR1LedlLaT0
dmyLfeFY/eJkjVxardQRDtWoDWRh/z3WRb3TDN7ijM7hav3gS91UdL7ciC40zQvc/M2mkQ3gyRXb
HS7fQEqo+f3ebG2lMm2lXv7fVn7bDg7bJH3eQa1Yc+3eRBakAT7gk82Yvx3ba83U0w3WnF5VXZXU
BXelJ+7psD7Yxq7aqi7iKH7Y9W3g7P3eLD3tKv7s4O3Zyd7fzv6Osu5bzL7aIf3qz67pQXMq+K3s
1M7q1j7myG3que3tAo7u/b3t4p3v3q7fyu7q3y5zYi7v8u3hcm3u5F7g8a6o6A3h2O7XBK/r9N7q
+47urx6i4X7q+m7r3D7v7p6omT7fUi3U523np92gLJ7nXp1mq37pmv7no62bqS7hLv//4Tpd8Ip+
3ekm1mYd695d8wpf6I++8R/vQ2XuEkXPTPDRqJd09FieUEx/UDce5IoxqlJPRlzI0Uz/5FluGE9P
GFqvFV2vThnR9V+v3fBu9Fvv0e1C7D4h6G0P5ff95R1y9irthjY903Hf9C1t9r3eLnRPMmkv9zAN
4UX+92G/TGMv6cVt8p6OZERd85s91OzC8no+1pWu+HJ22RUu6ZOP+YrO25X/+dTF5/a++TN/85R/
4j3t4o9P6RneVKkq63UO832e65vu7+mt6zra7xMvndhe6leO7+ve+6MO8/Du7yP+2GOG2xHP6aH+
I3bP5vtN7pIG3eEd4A2fbEUt2gr/7+T03eZ9XW+2rf3ZPlbdz/aQvaaMz+5p1vDiP2DHltzvz9wi
T9Jdd/HUP/HGz+q8n+rpDhD27AEQONCgQIIFDyYkmLCgw4YKBzqUiPDhRYoPI1bUeNDjRo8WF4b8
SBIARYYWIaqUuNIlxosVT3aMObHjS5koa4IEydHnT6BBhQ4lWtToUaRJlXJcyXKnSINNTZbEGREn
SadUn6aMCjNrzIxQr+qUqpCnV60jx2LVqfZpS7RnpbaFGpJsXLN5xaZd2tfvX8CBBQ+2O9PuzpM9
E2dkaHgiV5tNF5t1bHiyzcciuSbeG7ky07ecMyN0TBpiY8uoNWu2DLZh6ZELRWN9/4zadmHVozGm
Ps3bdM6StUkTJl7c+HHkyZUDDbvc+XPoP5tHp17d+nXsBf9t597d+/fu2f3OFl/evNLp56ODZ9/e
/Xv48eXPp1/f/n384NXv59/f/3+j8hNwQAILNPBABP8BcEEGG3SwugQjlHBCCitkDz3nYDsuvQc7
JIpDD6XjyEISSzTxRPhA9ElFEYU66ygOw2KRuPSaKyuwG5nbELocd6wIRSCDFFJCDJWbcUUYqzuy
LhqTWjLJ557EccQhq7SSRMBea421lCTTkLPbLtNSttzELM2q3zbTcK/LRhPNKt+ienOm3HTLqbfM
xqwsztnIc7NPPwFVzSU6b8vzN//hEE0TT9PqDPHRB+XCS9K67soKza/yuoomxWJrsauvCGWSpbU2
BS1UryC7FC0k1wKNrrS6nHRWmVbTFC9Ic2XwxY2qIvPMUmEydTJTqTqNJiRXRYnYmoSjVE4wYyR2
rtjC1ChapsDE9drXkPUVVHCf7RauarVVqU1d0+WPV0979TTbcLXaNFhyP8J0uFPjhTU4eWltaTob
KZV1VeC22pbfPWNV1t9jwVo4U3UjVu9FhCsetatg5/X3LafaYmxjV/t9+LCpKlVYX45JRtlklh8e
eOV4m92ML4olthk7ipeFTOd/1aRTWNesZU0vaMXq805e+aSs0Zh//jPHOY9191f/fKNGOjh0nY3T
2dXadPrN3T4ulzdHb74ZDrOHklJJSNdOO9m345b7Pz/9c1u8u+duVm++ASywb8ADZ/BKwgs3nDvB
E1d8ccYb7yvvxCG/eLx6K0/NvJ7gdXzzDguUHG8XAS7q88wpJxqumqd08VUd19XucNhjl/29z7NT
cU3a4H489yL35rj205OMsT+HZjf+eNnFlLnQa5lW1MxBGYW+RTzNJdPkOq2Hs2yrYw1U22jLxA2z
pxHFFOyawTef+Z777ZXs35CXf378sjx45luZFLdamnm3la4bKWZnKruXjYgmqbK8hFrnIpeqYiYn
/WFMZpxKVcuMVbWNcU6Dg5FM/8l8ljSnQetr59Ke//j3O6YBcFoGa9jpMjZBUiHGeg6jWm9CaK2X
deZksArZYp61QSDar2sNHNn+xJZDvmSLWSjU2MVuCC58tQyBMJSgDkc1s5CxCWhQtBioVAXALmox
iED0XMr+1z96ebGIKsPeAUGWsilazo0KpGIBDUZEmKXRjvWiFv6k2MVn0U+Qg3xPlsgjo/+VMFHT
OyHYhlYyLlUtap1qnm6WWCgZbe2S3/tZAreklw9KcoBcg9ry8McY+HlylLgbY+L+VisjtbKVwIMO
IW15ywPlqzh1kyXnaPkcXAZTmPbpZTGN+bphJlOZ+jlmM1u5TGgazpkmnByUlv/yS+lg00nM6VGT
gqLNaT7qlaNbXTWFqDYTko6a3DKnYJZ0u6yVM1/3mlI3u4nMaOYzmN6cGDr/UrpPAZSf/pSnUWpU
OcLY03cS0WdDBzkE7iivTNnD5PUSZSc3HQZbi7ToRb24JwRujY8dFZSiOsan1vAMo5VKqUntpD4t
2dCkWMwTJy8qGofmdJCiwloS9UgbnlYQZfujIKpi2E46RhCMRX3guFA4UgZCdaR2LBb/cubGVelU
qxU651VFSMk8ku+O+XsZmnzIL3ttVGRivdpXU2hDFWpviVhly1hvisgYlgqRZg1jH+MZTmP2MFNg
7CFha0XTvEoVrTfZIrIQmrn/uQg0gHvD62IrtkDH0rGwt+KrFfsIWNCKsadNDGsd64pYCWYRs0OF
pdgYlj8Cbqt0q9WhV10INNVC1baXXWhozeY5Rz7veZcTHwnvdEWrom+4Z6IMRb82pgiCEqTQxahK
ras5Xl6XnS7VbNCoG5rhBBCEAtlqeSN0ToICCJy+pc562cu5Mn7IQe59b3J4SR3z5tdA9eVvf/37
XwAHWMADVtfd6Gu3A/MowTBaMIGT87e/kvOeu+PW7ZATYXK2Tr43qyyF09vO3gJFvyO+Dy3pu69v
+sh1HDbOkTqs4aKQOKfoXa77DmVJ2Exyu9G9ntfg57xAKXFRQ7aouXTcXPOZ/+RLT9yoWpUrXkfp
yVAZhe6RD6nJilLZpQ5eDoQ/CdZxGTHFqj3aFymLRirecWCy4mH/mHhQ0yLWgWGO82GHqCwHjmyh
YN5NXWTs0ITWhs96VWtziepE03INz4eEpRodDSdvubm2QL2ymjvGpU65drZWfS07i6UzPl+qwVze
kWvRDDGx/nTPdV6j6KZ657JKTdK8VWx4hTq1H0KWVZcOK2Z/OOmlcpGVpC7OOGF26gfGNreo++NP
JztHWBv1qMn+bK1dxutfV3bTqD10GplI103/uaGGBGkl59qYIi/5iR49q5dA+O4tL3JLayaV0jJq
weAaGskpjHYNEZpkZqulpP+F4fcjWYpSgK+U2MgxdjFHzThsPrzY4s4nse8r4IgvXOMb53jHw9lw
j4ccUhQnuXeCN9B0optH3FQxiNc5TQMTp+Qz/8eEX/4pc9rcd2c1KM53+W9dxlx3NObmxd2Z4qED
huYltznkTN3oGbnamo1uMdCp7uGr/3PqF0a6LgOzdGGS+67cs/dHc+yb7tW0w8qtLrDEh+skTzmS
AN+eTJHcPbyz72kTHZ65O8omQb29fGOrpPMULnLQWZGLym6s6HzNRnCz1bKXPSXqRvlady0b0dUu
66wD2mc5thr0Bpza4j2PeL/EF2szbHbje5azueau2ob/0lg7e+6w9VrVUQT/dVpH6NaxWFi07MY8
7j0NV8mvBewUn/2mbU9t2YYe6tFf2rcTK1jYxvHQjBXtEQe762E3n9XHBqSj/wVtiywfl13NIOOn
bVhgnzz+io+ttAdIWzFXMdnR57zo8SjV3XI26lOjBEK/m0M9ofCy1bucfQs8qtE3VTK3tfuksbMc
CoysEPIokvoyeCu8H7M3n+mMLAOqBtQ3CPSuhMMM3Es7ETQM9fszBMSZGAyQFySxGYwOo7tBhqrB
EdNBH/wtHrSlHxzCiAlCIXysvpE4HCS9WNq6x5E6zBkMIzyRn4MtDXsnDsqwA9wwr9M6GAu4D+s6
KTEgJ3y261BCUgO5p/tC/y3EwRC7Jp/zwjjctaNzOaAbw+nrJ8GYQhPBkQ98QKvhO1TiniJLFZFS
O0YZvLtDKb4jHysTKbwrRLfwMberwNdbn7JRREScO9qbN040O04cuBxEPNWbosnavb66v8ZCK/EL
NsgjmEdDNjK0MWwrrfmrvwFMovibRYFBtS/bv1DDJz5Enhdyt/zDxbhqKQhqlGCLKafiOd47QWZM
rhJqoW8zRf1Ln61AF2P0PfiLPKfaRphaxgNiFp5boWlUiGHEEjnERv+DPs/auXaRLLvivhW5qmdD
omFpxmxMLVuktenLIgO0vlQDv2x0RWFDjC30uFKkxV67Hzh6Ko1KNOjrEf98tLSHlL7ushW3gEWA
/MYApMPZc7920UjXK8AOsod1nJ+9O6kPfJ/LEyULJKxyOz93q7F9U8E5obu585LqKsHscZhuXJqb
vER527J8s8ft0a3P+MTx2cARPBqVXEnk6R0itJ0fpMqqNKhhu8rlGEWG1EqxHEuyLEuzPEu0TEu1
XEu2bEu3hEGvjMvqAAa5rEu7vEu8zEu93EsRe0u//EvADEzB9MvEGEzDPMzAXAzE7EO+bMwLQ8ON
W0zJnEy3dEzLvMzroEzN3MyyxEzP/Ezl4EzRLBBGGE3TPE3UTE3VXE3WbE3XfE3YBBLQnE3a3MPY
vE3czE3d3E21VA94qE3/4AxO4RxOr+RN4zxOwiFO5VxOYURO53xOrmJO6RRO6KxO67xO7MxO7dxO
7hyk6fzO2uxO8RxP76gCAQFP9FwK1ExP9jyK9WxP+EzA04xBSIAE+rTPMULN+iyI/RSI/exP/7RP
ALWHASXQ+gTQAf1P/AxQiThQB13QB+XPCG3QBQ3QArXQA6XQDLVQCWXQB91QhZhQAw1RAa3QAnVQ
A/3QikDRD61QBu3QFEVQE3XRGD1RFOXQF1VQFaVQDS3RDm3RFZ3QHZVQEAVSFgXSEZ3KtAQMGf3R
Gc1RGu1PKX3SJL1QGL3SKb3SF4XSIMVSCMXPIgVTKuWILE1SLjVTEuXR/58oU6Ao0yZF0wt9UzOd
0i/dUjRV0zStUjENiiaV0ze1UhvF0/8qEDrd0wTd0zvVUzt1UxrV0kCV0xgl0yh90kfdUDZNVBi9
VEaVVEHtUkxVUwXl0UP1VA91UR1F1FH1iTg11Dpt0zr9U1P1UVK10yTVTzHN0lSNVE/V1C+1UkeN
1Tmd0VXlVCcVVUtt1E9VVDjtVWQN1DVFVD49VmPNU2od0Uq91GrtVD3NVVV91VatVGLV0lrtTSYt
0VCtURD91B3lVl/91Wld1kVtVkoF1lD11XZd1zFNVmftVgxNVzwFV3GFV3A911nVVjrtUX8NVmW9
01OV1mxtV/b6mxud2P98tVdvrVaIhdc0FdEz1dd5fdcbLVhqJViNDVdaBVVkJVWAPdlRBdiQ1daA
LdRsDVKKTdeVfVhgVdLR1FWKxVh5LVZ3dVWcXVh0JYqWpddb/Vl+LVWffVaYzdSU/VekndmjBdmE
PdmYZdWANVhovVlxbdf1rFloLVmp7VisHdqO5dWzVdgtZdOr9ViopdV7zdmlzdigZVtAbVW87dWl
NdkzxVaR9dNvbdR9fdH3zFV2ldeXfdm1ZdmQrdq47VbGFVEZVVpJXdyEtVhu7dFk7VSO1VWa9VfK
5Vu/JdEjJdiGHVZBrVxIxVC0fc/4jF0qWVLZrd3iJBDbzV2dFU3ddTD/8ozO3hWw36WQ4B2w4WWm
4k3esByQFpXVUi3UuQ1Tb/1cnqVeIj1U6TVXL73a5r3eqOVY60VXkk1dhL1bIc3Xfs3Qo6XeIe3X
8k1fRD3e7xiMxDXbvIXai43WeA1Xtx3cwd1audXbsmXbvhVYvYXVPO1T9G1aoHXatj3g/xVZ9Byn
+iXaArZWabVbwJVgZ5VZDC6KzVVdz03Z+kXgjf3YWZ3bps1YE25gpvVU+TU5wajgDR7h6u1cs73g
AIZSXI3a1aXbrS3cHz7hyHVhkr3bFEZhB7bgIz7ixpVOChbW8/Vewp3aem3f7eXeKkZZpnXiJWbY
SfVbFabic23d8XVe/9MN32VVUSRNYAH+4BOe4t2NYdzd3yLmWqv14qdV3SPl4m2VVcZl4Kx1XSEW
ZAy22akF2j4GYLLVY+8dWq81XDreDvqt2LGl2kReZKEtXciNXJndXENO1E5e2xLu2kR+YVSGW3dl
YVN+VxdWXr+g4bG937R15Dum5YVtYYdVZS/t2/7d5P0V3F4m4DP+4lHmXwgeZlxuzyhe4WMN5Ed+
YHMNZLGN3uxl1mBl1jFO4+8d3bdF4mJ23zRGWDTeZgNm3zH93NEl1knOJVj2r3ber3fur3gGuXkO
rXqu43uOS/HcZ7l0TX8OaACzZ4GeQfEU5l8dUjl2XIV+XHR+VjZ+aP8qJmPJrdysjWgidlLMreYw
RuIUzWIBTl3tJdIapWgsLliODuf+POhkDmK6DWcxjmAwFgrEBeIWXuKDJWVLNuBbdl4hBtwwfeBg
nlRhVVYR1twFtuMzBei/8GDWTWKTNeeVxV4frulxHmr9jeNLNuRivmnzRWSG1tqMTmXXjdRNHWBf
JuGdxuEbJNSkleaOxlpQ9mjUleKsFurrXeWqRtoabuRy9umtLtnJ1eIe9mOgfmZA3urWldrBZuCV
bs3AONW9HeLQhWalfuFUhdjMplK1beOv9VFHpmpNhmPRnmVUBWIibuLTht9DBu3zjdC+xmu/xtcA
m4b/ENs7JluPDuX/hvXjAlbn1X5llE5sqVbi1u5mjcVWiyXklw5qY71i4VbjYfZrN5ZO3E5fys5u
qM7o0gZmoqVt4bZhD45q4y5jtU5u4K5b9W3uxd5UBd7VvZ5u6gbP667gXp7rHa7ly87uzpZpnDbl
8w7as/5uwL7s5cZRM15g987fkUVu2Z5vuzXoOrbq3V5oXo5mnmbkUtZq1n3bdcZR8m5wSIXepB3x
pM5mDE/o0X5exF7vmS3akubq+O3OgibCfq7xrIRsHN9xHu9xH/9xID+mfB7y1wxyIz9yJK9dIl/y
1UxyJ18cJo/y+XxyKq9yocABK89yLd/y5pRyL/9yMA9zMR9zMi9z/zP/Sy5P8yI8czYnVzV/cziP
czmfczqvczuf3TbPcz3fcz6vjzv/8/Poc0EfdEIvdEM/dERP9HYGdEbPDkV/dLhsdEmfdEqvdEu/
dEzXQYIOigO4jgPo9AUBdaQQdeQg9erodFD/9OMgdVP3iVbPFVSfY938dFUXiFdXiFe/9VGvdYnQ
9VEvCF8nili39V4HClE39WD/9WT/CV1fdmIf9lXH9aFg9aVodsK49VjfTMA4dmFPDmwXDGc3Cm4v
inH39mrfdnuAduOgdqEId05n9mt39XSPwQKh9lSvdVqf93TH931H9WPn91SviHvHd4IPeH/3d2Av
eH3P935HdmKf9/+Db/hnZ/iEP/iA7/deV3heZ3h1x3iPp/WBt3WAp3iKz/iQh/iFf3iOX/iSP/mP
f3aJF3lel/mPV/iaR3iaj3mOn3lZz0171/eHD3qYv3hox3mgB/agL3qk5/eUl3Zuf3qkj3qDB3qo
L3eqX/qjj3qUb3qsZ/ekv/pc33qxl/evZ/qLX/qz/3mYH/q1F3uvz/q2h/qUl3u39wnn/PmNl3aJ
H3aDB3m4L3aw13qlb3q/p/vBZ/tYL/fE1/qrH/pWB3m+V/l8V3evV3pWn3yw93XFD3y+x/yvx/q4
33fQr/uEZ/zCr3hVJ/qGt/zS/xHNRPfRT32n73qVz/pgT/vGJ/3/qQ99w5/9xd/8w8/9on97wud8
vS/72Kf9pP925Ef8wP983ld+1hd6kRf+3K/9sX/+1m9rAhl3tY9+1ad7uMd94Jf66D9/2zf/8rf6
8jd90N99lH/73l9/9+eI9v/83hf66d/6xQ99gQcIewfsERxYUCBBhAcNMlSI0ODDhAkhEvxn8SLG
jBo3cuzo8SPIkCJHktQo8STKlBMPsJwosGXBlgxZDqx5UCHNmzpj2lwoMafDhjiByuSpk2LQm0V9
QkS6NCLQnzCFzizqdOpUly952mz6EulPqUKPrnz6lWLVskd7DoVpNCZXuF+VKs1ad67KvHr38u3r
9y/gwIIHEy5s//gw4sSKFzNu7PixX7CQJ1OubJlxSY6XN3Pu7Pkz6MVRQwPObPo06tSqTZNu7fo1
7NiyZ9OuTXr1P9u6d/Pu7dsy7uDChw/nLLnvcd1uf6NcHpZ5Yuefk0Ovbl0xW6d6vRo3LJkmdbKA
iYIf31wr8tGCs2Pnexyt26jqzYsNn3T88qbzr/OHzD0yer6BZd9z6wXoEHLn7bQdYwQGZt93/7H3
34MFJjgYd/Ed2B+HBuL0kExEnXVSTuW9pVZ8KVbVkIkjinUigieWuBR50gWo34BYwVeTfM7liGNS
Xc2VFox4Demjjgred+BVK5aFVnMqDvlWi0pK2KF1uFEVEVnsof/nFYVbUsglVC6FaWZKIvr0ZZAb
xjhggWyxueabdpEZJIto0qmSnHDuGeeX8OU1IZN29qknmd/FCRRxjTr6KEjRlellmTtdCR6UH2Ia
F5htWopommcdSielTNYHqJ947gdiiagiyuOMaba6YaehPkkirqfWGqOZ5WWa6JKmioclc1pOuqSQ
n3bJJ13akQrsmX/i6uyyz1o47K9yYsvredR6Cq2srtIK6rULertrqWGd+2qwvF4JKbzxPtpes2yW
eumN9T7bKbriMrvrt/cqGSzA247JbrYBE+yvu+SOq7C97IYKcL/R5tousRnvlSFc/BZ6n3pbGukr
mhmGbOetMmL/1dawopp78lhSgYyklFTOOhTLRqZMHokoqyWXyj96WWWLPc6Uc5gm1uigxq/h1vSF
UEs9dW/yWn21alQ/tqrWXXv9Ndh5PR022WWTjTXaaasNqdltuz312nHLfbV/72nN9HR4S7q3m9yu
Z/fbgdM2drkHD8p1gobz3RmEzP6ss98uO1jltdpG/leq3m6d2Nyde/55RgO3zKBolulNL+k9R7zW
xn1baWvfp4uOcWWyowQ67rmrjddoM9ZMq5Qew5oz5GqyXLSOOBL5olEwF4lsrpZfjDy1E4qYFvV/
1vii0jD2tPTPXeVH18gt6X4++pohVjD0Yxo/Koj7Ogzyh3Mi/yxxt4XPD71cMcPe7+rABT/rTa9h
y4pQtaDlv/ppx3aCIxv7LkW5Xt1MYWDyldCuNCeS7YtyHFzQty7mIgrayH6wys/72sQje30wgCaM
3/Q+SCgQCslJJXwglowlLXy1bl3yk9ZW3GSxGYLrfwjKnN8UZaHw8FB0FQsKEWnosCaOz1z3k2IN
A2WP9HGxi6uJYADtRrErAitf+krYE62VQAPeSX8LA2H7zBjGOxHRcmBcY8J+WMYCLsyLfsQddnzW
Ma3ADEg2e8rRiDSfFE6pLoiMC+RcxDPmRUg/zLMfoBwpQk5dj3eEFKQno6RCH1HSaJaq3q0Qh0P+
EG6VhXGgK/+rA8vB/LGWnYtlaFSJy4zNcpdma6UvgynM0NiymPAaJjKTqcxl6gWYu/nVaxwIuKj1
54bUpMw01UUYa27RmN48XzSp2cvSzQ527UqO7RrnHfe4zoiXyeb+WseXb9IzOLwUp2yUKM/Rpa5C
+9wmOzHUzgY5bloCZWZ1nra9I0GSd6Z06PKIxsjwhYyEa1LTQo22I0lySaI1E9+9aKRJST4SRTNr
0ggZmVGN9ixJHc3K8iDqk3rStHNo1FcR24g/ganRoMpS4Br3yNNRtsx9QdSgePKkxyFCzGBk9Oke
Lfimo7oThjW9amYWVyulsuqRKESkDDNpx5vdlFQclGFYX0j/qTymVXsl62oUtcWxFeUxpytMJf6k
asOVvA6ICCVWWbkqVy0CEJNzLSBTC7tUPjoVqVL9FCqzyLDBnrGgaYTiY494vygG0al/nY0OqyXY
pto1r45NYFmFWtqe4suxl9WcZsmXUylu66ev1eZi55gsndaVLVj9rUgCqchmPfSCyuufinYETby+
zKuUhKRLRzhIppwqZSMSFBwNFb5PPoxg0ikpS8P7SZoNd69F2ujlPgvB2owTS+k0nXrjG8z2EhSH
762dfPNbG2fqF7irIYV/AyzgAW9Ev7cjMIITrOAFm2Sg5qwdPInJ4AlTuMI0xW25dMrYg2bSwYeR
TC0LYOER/5N4wRmOHBNRh8l3pqTELn4xjLManVn5blIppHHyohRT31FlfIosLqsMLOQhW8djWizt
bV3Y2HBl9q70JTKUo7w5piC1jk1mWGMzF1bFSrnLXiYNutZ6ZcXeMWB1RS3tvqzmNasktIei4pjl
aEcX9vbKWokxnvOsZ4sIF6R8Ne5xtzLc5maXUBWl6Edlll42M7rR8X2yoyMtaWZCetKWVu+eM63p
TXO6UZf+NKhDLepRk7rUpj41ql3T6VWzutWuDh0zo5HqWbP51ba+Na5fTOtd8xpsuf41sIMt4F4T
u9hNEzayk63sWuZlGsZ+NrR1s+xpU7vac4s2trOt7W1zu8Hb3v42uMMt7nGTu9zmJoy1063udbO7
3e5+N7zjLe957+7c9r43vvOt733zu9/+/ve36S3wgU8b4AbnNsETrvBcH7zh2F44xCMu8YlTvOIW
vzjGM67xjXO84x7/OLAdLvKRk7zk8gU5ylMOTpOz3NQqfznMOYIFebW85m97hmxirvOd87znPrel
zYP+6Z8TvehGPzrSk670pQtH6E6XNNOjLvWpU/3jT786o6uu9Zdjvetf3jrYQe71sZO97GZ3TEAA
ADs=

------=_NextPart_000_000B_01C708E9.9E31BB50--



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 kAFHpj6L067053; Wed, 15 Nov 2006 10:51:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFHpj3O067052; Wed, 15 Nov 2006 10:51:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.183] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFHpgQj067045; Wed, 15 Nov 2006 10:51:43 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624087fc181032b0471@[10.20.30.183]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail] oft.com> <[e-mail]>
Date: Wed, 15 Nov 2006 09:51:32 -0800
To: "[e-mail]" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:16 PM -0500 11/14/06, Russ Housley wrote:
>Stefan:
>
>>There is no place where RFC 2560 requires the render to 
>>successfully handle a composite request. It only specifies how it 
>>should be done.
>
>It does not say one way or the other.  That is the problem.  It 
>specifies the syntax, without telling the reader whether some or all 
>of it is mandatory to implement.  This is the crux of Sam's discuss 
>position.  Nothing in the text leads the reader to believe that 
>responding to a multi-certificate query is OPTIONAL.
>
>I find the use of "unauthorized" to indicate that a client cannot 
>make a multi-certificate request unacceptable.  To me, that implies 
>that some other client would be authorized to make such a request.
>
>I also find the use of "internalError" to indicate that a client 
>cannot make a multi-certificate request unacceptable.

Unfortunately, I agree with Russ on this one. We boxed ourselves in 
with the definitions of the response semantics because we did not 
predict this case.

I also do not see how we can handle the problem without changing the 
OCSP version number, but I would really like to be wrong about that.

--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 kAFHSVmw061539; Wed, 15 Nov 2006 10:28:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFHSViO061538; Wed, 15 Nov 2006 10:28:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-103-wednesday.nerim.net [62.4.16.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFHSU6p061509 for <[e-mail]>; Wed, 15 Nov 2006 10:28:31 -0700 (MST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net8.nerim.net [62.212.120.81]) by kraid.nerim.net (Postfix) with ESMTP id 039BD40F45 for <[e-mail]>; Wed, 15 Nov 2006 18:28:28 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id 6F1A3441DA for <[e-mail]>; Wed, 15 Nov 2006 18:29:10 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04528-01 for <[e-mail]>; Wed, 15 Nov 2006 18:29:06 +0100 (CET)
Received: from isonoe.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 091C4441D9 for <[e-mail]>; Wed, 15 Nov 2006 18:29:05 +0100 (CET)
Received: by isonoe.cry.pto (sSMTP sendmail emulation); Wed, 15 Nov 2006 18:28:23 +0100
From: "Julien Stern" <[e-mail]>
Date: Wed, 15 Nov 2006 18:28:23 +0100
To: [e-mail]
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.11
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 15, 2006 at 09:55:47AM -0500, Russ Housley wrote:
> 
> I would like to add some text about certificates that are not 
> intended to expire.  I propose the following paragraph.
> 
> In some situations, devices are given permanent certificates.  For 
> example, a device could be issued a certificate that binds its model 
> and serial number to its public key.  Such a certificate is intended 
> to be used for the entire lifetime of the device.  It indicate the 
> permanent nature of such a certificate, the notAfter SHOULD be 
> assigned the GeneralizedTime value of 99991231235959Z.
> 
> Any concerns?

If the device is somehow stolen or compromised at some point,
doesn't this mean that you will have to keep its serial number in a CRL
(or an other revocation system) until the end of times?

When faced with a somehow similar issue, we decided to set the date to
the expected lifetime of the device plus a few years to avoid the above
issue.

--
Julien



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFHDPsB056827; Wed, 15 Nov 2006 10:13:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFHDPcq056826; Wed, 15 Nov 2006 10:13:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFHDOBp056795 for <[e-mail]>; Wed, 15 Nov 2006 10:13:25 -0700 (MST) (envelope-from [e-mail])
Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.15; Wed, 15 Nov 2006 09:13:19 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server id 8.0.685.20; Wed, 15 Nov 2006 09:13:18 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Wed, 15 Nov 2006 09:13:18 -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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 09:12:50 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccIT7uJ7ZnLSN6oRQmYAhn4pmp/fQAhXxGA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: Russ Housley <[e-mail]>, Stefan Santesson <[e-mail]>, <[e-mail]>
CC: Sam Hartman <[e-mail]>
X-OriginalArrivalTime: 15 Nov 2006 17:13:18.0917 (UTC) FILETIME=[5881B750:01C708D9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFHDPBp056821
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This problem is not limited to multi-certificate requests, there are a
number of optional items in 2560 where this same problem exists (OCSP
request extensions, multi-cert requests where responders cannot
authoritatively respond to all certificates, etc.); 2560 does not tell
implementers how to deal with these cases at all.

This leaves us with a practical problem, since there were at one point
(I have not been watching products in this space for some time) at least
a dozen interoperable implementations of 2560 we need to ask if it is
appropriate for us to change the 2560 in such a way to break those
implementations?

I would argue that continued interoperability trumps technical purity
here, I don't think anyone would argue against adding additional errors
before this was the case the but cat is out of the bag; now the question
becomes what have the implementations done to achieve the
interoperability that does exist, and should we clarify 2560 to make
that more obvious for the next implementers?

In general I don't see a problem with this question in principal but at
the same time I do not want to see us crack open 2560 as it opens the
door to many other edits that have the potential to break
implementations, but if we must how do we limit these edits to those
that provide clarity and do not break these existing implementations?

I also (selfishly maybe) do not want to see this draft be held up any
further, we have reached the point where there is rough consensus in the
WG and with the implementers, we have working code shipping from
multiple vendors and documenting what these interoperable
implementations do to help others in the future just seems to make
sense; frankly I just don't see how holding the LW OCSP draft up helps
anyone.

What I would like to propose is that we let the LW OCSP draft go forward
since it doesn't conflict with 2560 as it stands today and then begin a
2560bis effort, were I would be willing to work with Mike, Dave, Alex to
identify text that would clarify some of these points without breaking
existing implementations as long as the WG and its chairs will help us
limit the scope of these changes to clarifications and not go down the
path of creating a new version of the protocol.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Tuesday, November 14, 2006 3:17 PM
To: Stefan Santesson; [e-mail]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Stefan:

>There is no place where RFC 2560 requires the render to successfully 
>handle a composite request. It only specifies how it should be done.

It does not say one way or the other.  That is the problem.  It 
specifies the syntax, without telling the reader whether some or all 
of it is mandatory to implement.  This is the crux of Sam's discuss 
position.  Nothing in the text leads the reader to believe that 
responding to a multi-certificate query is OPTIONAL.

I find the use of "unauthorized" to indicate that a client cannot 
make a multi-certificate request unacceptable.  To me, that implies 
that some other client would be authorized to make such a request.

I also find the use of "internalError" to indicate that a client 
cannot make a multi-certificate request unacceptable.

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 kAFH5pSf055646; Wed, 15 Nov 2006 10:05:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFH5p5l055645; Wed, 15 Nov 2006 10:05:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFH5nxP055637 for <[e-mail]>; Wed, 15 Nov 2006 10:05:50 -0700 (MST) (envelope-from [e-mail])
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 1GkOCQ-00027f-LZ for [e-mail]; Wed, 15 Nov 2006 17:05:34 +0000
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 17:05:43 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: PEM file format rfc draft request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> "Dieter Bratko" <[e-mail]> writes:
> 
>> For that reason a standard giving some recommendations for the usage of PEM
>> headers would be very useful. It should not only cover keys, but also
>> certificates, crls, requests,... (for instance, some applications use -----
>> BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>> REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>> other for encoding a certificate request).
> 
> That's why I suggested that a regexp is the only way to handle this.  You also
> need to take into account usage in other environments like PGP and SSH, which
> also use the PEM format.  From memory my code's workflow is something like:
> 
>   look for '----';
>   look for either another '-' or a ' ';
>   look for 'BEGIN';
> 
> This handles the common PEM start.  Then:
> 
>   if the remaining text contains 'SSH' it's an SSH public key;
>     goto SSH-processing;
>   if the remaining text contains 'PGP' it's a PGP public key;
>     goto PGP-processing;
>   // Default: It's something X.509-ish
>   if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
>   if the remainig text contains 'PRIVATE' it's a private key;
>   otherwise it's a cert of some form;
> 
> This should handle pretty much everything out there.
> 

I've seen several variants on that. A far from exhaustive list from
memory...

If it includes 'PKCS7' or 'PKCS#7' then it is a PKCS#7 ContentInfo,
usually but not always certs only.

'X509' is normally a certificate but I've also seen it containing PKCS#7
certs only and something called "Netscape Certificates Sequence".

Contains 'CERTIFICATE' oddly enough a certificate.

Contains 'CRL': CRL.

Is 'ENCRYPTED PRIVATE KEY' is PKCS#8 EncryptedPrivateKeyInfo.

Is 'PRIVATE KEY' (with no mention of algorithm) PKCS#8 PrivateKeyInfo.

Is 'RSA PRIVATE KEY' PKCS#1 RSAPrivateKey.

Is 'DSA PRIVATE KEY' SSLeay compatible DSA private key.

Private key types PKCS#8 related can include encryption parameters in
the headers.

Is 'PUBLIC KEY' SubjectPublicKeyInfo (RFC3280 et al).

Contains 'PARAMETERS': DSA, DH, EC parameters of various types.

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: [e-mail], 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 kAFH4x8F055472; Wed, 15 Nov 2006 10:04:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFH4xUK055471; Wed, 15 Nov 2006 10:04:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFH4w5J055465 for <[e-mail]>; Wed, 15 Nov 2006 10:04:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29940 invoked by uid 0); 15 Nov 2006 17:04:53 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 17:04:53 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 12:04:47 -0500
To: Stephen Farrell <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am fine with the alternate wording.  I want the 99991231235959Z 
suggestion in the document.

Russ

At 11:50 AM 11/15/2006, Stephen Farrell wrote:


>Russ Housley wrote:
>>I would like to add some text about certificates that are not 
>>intended to expire.  I propose the following paragraph.
>>In some situations, devices are given permanent certificates.  For 
>>example, a device could be issued a certificate that binds its 
>>model and serial number to its public key.  Such a certificate is 
>>intended to be used for the entire lifetime of the device.  It 
>>indicate the permanent nature of such a certificate, the notAfter 
>>SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
>>Any concerns?
>
>I like the idea, but according to my local folders, when we discussed
>this off list before and came up with a variant wording which I think
>was:
>
>"In some situations, devices are given certificates for which no good
>expiration date can be assigned.  For example, a device could be issued
>a certificate that binds its model and serial number to its public key;
>such a certificate is intended to be used for the entire lifetime of 
>the device.
>
>To indicate that a certificate has no well defined expiration date, the
>notAfter MUST be assigned the GeneralizedTime value of 99991231235959Z."
>
>There was some discussion about whether that last MUST is right or
>not, (and I don't care myself), but I guess we never did put any of
>it into the draft,
>
>Cheers
>Stephen.
>



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 kAFH0FEL054627; Wed, 15 Nov 2006 10:00:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFH0FIq054626; Wed, 15 Nov 2006 10:00:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFH0ElH054616 for <[e-mail]>; Wed, 15 Nov 2006 10:00:14 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1GkO6Y-000EvX-DB for [e-mail]; Wed, 15 Nov 2006 16:59:29 +0000
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 16:59:34 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: PEM file format rfc draft request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> "Dieter Bratko" <[e-mail]> writes:
> 
>> For that reason a standard giving some recommendations for the usage of PEM
>> headers would be very useful. It should not only cover keys, but also
>> certificates, crls, requests,... (for instance, some applications use -----
>> BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>> REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>> other for encoding a certificate request).
> 
> That's why I suggested that a regexp is the only way to handle this.  You also
> need to take into account usage in other environments like PGP and SSH, which
> also use the PEM format.  From memory my code's workflow is something like:
> 
>   look for '----';
>   look for either another '-' or a ' ';
>   look for 'BEGIN';
> 
> This handles the common PEM start.  Then:
> 
>   if the remaining text contains 'SSH' it's an SSH public key;
>     goto SSH-processing;
>   if the remaining text contains 'PGP' it's a PGP public key;
>     goto PGP-processing;
>   // Default: It's something X.509-ish
>   if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
>   if the remainig text contains 'PRIVATE' it's a private key;
>   otherwise it's a cert of some form;
> 
> This should handle pretty much everything out there.
> 

I've seen several variants on that a far from exhaustive list from memory...

If it includes 'PKCS7' or 'PKCS#7' then it is a PKCS#7 ContentInfo,
usually but not always certs only.

'X509' is normally a certificate but I've also seen it containing PKCS#7
certs only and something called "Netscape Certificates Sequence".

Contains 'CERTIFICATE' oddly enough a certificate.

Contains 'CRL': CRL.

Is 'ENCRYPTED PRIVATE KEY' is PKCS#8 EncryptedPrivateKeyInfo.

Is 'PRIVATE KEY' (with no mention of algorithm) PKCS#8 PrivateKeyInfo.

Is 'RSA PRIVATE KEY' PKCS#1 RSAPrivateKey.

Is 'DSA PRIVATE KEY' SSLeay compatible DSA private key.

Private key types PKCS#8 related can include encryption parameters in
the headers.

Is 'PUBLIC KEY' SubjectPublicKeyInfo (RFC3280 et al).

Contains 'PARAMETERS': DSA, DH, EC parameters of various types.

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: [e-mail], 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 kAFGxxLL054532; Wed, 15 Nov 2006 09:59:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFGxxHs054531; Wed, 15 Nov 2006 09:59:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFGxwhh054515 for <[e-mail]>; Wed, 15 Nov 2006 09:59:58 -0700 (MST) (envelope-from [e-mail])
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: questions on CertificatePolicies processing
Date: Wed, 15 Nov 2006 08:59:46 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: questions on CertificatePolicies processing
Thread-Index: AccIyOHgq37IDj0pTl+l2gIF0W5mXgACGgBw
From: "Matt Cooper" <[e-mail]>
To: "Kopylov Denis" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFGxwhh054525
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?
[Matt] In some circumstances it may be of value during authentication
and authorization.  For example, if the certificate is valid, but valid
for no policies, allow access only to A.  If valid for policy X, allow
access to A and B, etc.  However, in many circumstances, I think
software may choose to set initial-explicit-policy if an initial policy
set is supplied, as this would frequently be the intent of supplying the
initial set.  I think this decision is dependent on what you are
attempting to achieve through the certificate validation and what sort
of feedback (if any) the software will supply to the user relating to
the final policy set.  In any case, if an initial policy set can be
supplied, there should be a way to turn on initial-require-explicit if
this is not the default behavior of the software.

Q2: How should be treated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?
[Matt] If require explicit policy is set, either initially or by a
certificate in the path, the certificate is not valid if the final
policy set is empty.


Matt Cooper
CygnaCom Solutions
7925 Jones Branch Dr, Suite 5200
McLean, VA  22102
http://www.cygnacom.com
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kopylov Denis
Sent: Wednesday, November 15, 2006 8:00 AM
To: [e-mail]
Subject: questions on CertificatePolicies processing



Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?

Q2: How should be threated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

--
Kopylov Denis
kopylov at top-cross.ru




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 kAFGnE5F052864; Wed, 15 Nov 2006 09:49:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFGnEeO052863; Wed, 15 Nov 2006 09:49:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFGnD8I052837 for <[e-mail]>; Wed, 15 Nov 2006 09:49:14 -0700 (MST) (envelope-from [e-mail])
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 5C73B682F6; Wed, 15 Nov 2006 16:49:07 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A012095904D; Wed, 15 Nov 2006 16:49:07 +0000
Received: from [127.0.0.1] (nanga.dsg.cs.tcd.ie [134.226.36.174]) by imx2.tcd.ie (Postfix) with ESMTP id 562B2682F6; Wed, 15 Nov 2006 16:49:07 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 16:50:00 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC3280bis: NotAfter 99991231235959Z
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A112095904D
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.56.3 VDF=8.1399)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> I would like to add some text about certificates that are not intended 
> to expire.  I propose the following paragraph.
> 
> In some situations, devices are given permanent certificates.  For 
> example, a device could be issued a certificate that binds its model and 
> serial number to its public key.  Such a certificate is intended to be 
> used for the entire lifetime of the device.  It indicate the permanent 
> nature of such a certificate, the notAfter SHOULD be assigned the 
> GeneralizedTime value of 99991231235959Z.
> 
> Any concerns?

I like the idea, but according to my local folders, when we discussed
this off list before and came up with a variant wording which I think
was:

"In some situations, devices are given certificates for which no good
expiration date can be assigned.  For example, a device could be issued
a certificate that binds its model and serial number to its public key;
such a certificate is intended to be used for the entire lifetime of the 
device.

To indicate that a certificate has no well defined expiration date, the
notAfter MUST be assigned the GeneralizedTime value of 99991231235959Z."

There was some discussion about whether that last MUST is right or
not, (and I don't care myself), but I guess we never did put any of
it into the draft,

Cheers
Stephen.



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 kAFGdLnO051174; Wed, 15 Nov 2006 09:39:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFGdLYk051171; Wed, 15 Nov 2006 09:39:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFGdJVa051135 for <[e-mail]>; Wed, 15 Nov 2006 09:39:20 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: from IBM5E1D7F233E3 ([10.0.250.204]) by mail.nbusr.sk with esmtp; Wed, 15 Nov 2006 17:35:45 +0100 id 0001CCA7.455B41E4.0000C774
From: "Peter Rybar" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 17:39:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-reply-to: <[e-mail]>
thread-index: AccI0mORJ99k5h9vRVyWdjmaVpndlgAAV1Ww
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFGdKVa051157
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some utility written in C language time (The time function returns the number of seconds elapsed since midnight (00:00:00), January 1, 1970,) will crash. ;-)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Wednesday, November 15, 2006 3:56 PM
To: [e-mail]
Subject: RFC3280bis: NotAfter 99991231235959Z


I would like to add some text about certificates that are not 
intended to expire.  I propose the following paragraph.

In some situations, devices are given permanent certificates.  For 
example, a device could be issued a certificate that binds its model 
and serial number to its public key.  Such a certificate is intended 
to be used for the entire lifetime of the device.  It indicate the 
permanent nature of such a certificate, the notAfter SHOULD be 
assigned the GeneralizedTime value of 99991231235959Z.

Any concerns?

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 kAFGaLiF050673; Wed, 15 Nov 2006 09:36:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFGaLCu050672; Wed, 15 Nov 2006 09:36:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFGaI7F050636 for <[e-mail]>; Wed, 15 Nov 2006 09:36:21 -0700 (MST) (envelope-from [e-mail])
Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.15; Wed, 15 Nov 2006 08:36:13 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.20; Wed, 15 Nov 2006 08:36:12 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Wed, 15 Nov 2006 08:36:13 -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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Wed, 15 Nov 2006 08:35:51 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQABnd37AACuUgEAAxFeww
References: <[e-mail]> <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: Stefan Santesson <[e-mail]>, Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>, <[e-mail]>
CC: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>
X-OriginalArrivalTime: 15 Nov 2006 16:36:13.0058 (UTC) FILETIME=[29CA9620:01C708D4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFGaL7F050667
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although I know of toolkits that can send requests like this, and
servers that can respond like this I know of no clients that send
requests like this.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Tuesday, November 14, 2006 9:11 AM
To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder
key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA
can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to
be
> > >issued before the next generation of presigned responses). The
keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds
with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd
suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [e-mail]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that
support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response
MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > -----Original Message-----
> > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>






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 kAFFo3E4036995; Wed, 15 Nov 2006 08:50:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFFo3hm036993; Wed, 15 Nov 2006 08:50:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay1.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFFo1PP036942 for <[e-mail]>; Wed, 15 Nov 2006 08:50:02 -0700 (MST) (envelope-from [e-mail])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.13.8/8.13.8) with ESMTP id kAFFnhHK027511; Wed, 15 Nov 2006 16:49:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id BEAAC19400A; Wed, 15 Nov 2006 16:49:43 +0100 (CET)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18315-06; Wed, 15 Nov 2006 16:49:43 +0100 (CET)
Received: from NOTEBOOKLIPP (notebooklipp.iaik.tugraz.at [129.27.152.52]) by thor.iaik.tugraz.at (Postfix) with ESMTP id A105B194008; Wed, 15 Nov 2006 16:49:43 +0100 (CET)
From: "Peter Lipp" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: AW: PEM file format rfc draft request
Date: Wed, 15 Nov 2006 16:49:43 +0100
Message-ID: <01bb01c708cd$ab264b80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AccIuk6pd6/SBBMzR/mZaFOt5SYzjAAEumtg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <[e-mail]>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Spam-Scanner: SpamAssassin 3.001007 
X-Spam-Score-relay: -2.6
X-Scanned-By: MIMEDefang 2.58 on 129.27.10.18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> This should handle pretty much everything out there.
Sure. With a heavy machine your are always able to pick up all sorts of junk
that you find on the floor.... :-)

Our software is basically doing the same, but this not really an argument
for producing all sorts of junk. An official document may at least help
avoiding new incarnations of these things....

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 kAFFhNFf034897; Wed, 15 Nov 2006 08:43:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFFhNuK034895; Wed, 15 Nov 2006 08:43:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mizar.origin-it.net (mail.de.atosorigin.com [194.8.96.234]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFFhLGE034843 for <[e-mail]>; Wed, 15 Nov 2006 08:43:22 -0700 (MST) (envelope-from [e-mail])
Received: from matar.hbg.de.int.atosorigin.com (avior.origin-it.net [213.70.176.177]) by mizar.origin-it.net (8.13.8/8.13.8/hmo020206) with ESMTP id kAFFhFQK088768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 15 Nov 2006 16:43:15 +0100 (CET) (envelope-from [e-mail])
Received: from DEHHX001.deuser.de.intra (dehhx001.hbg.de.int.atosorigin.com [161.90.164.119]) by matar.hbg.de.int.atosorigin.com (8.13.8/8.13.8/hmo020206) with ESMTP id kAFFhF3A091593 for <[e-mail]>; Wed, 15 Nov 2006 16:43:15 +0100 (CET) (envelope-from [e-mail])
Received: from DEFMX001.deuser.de.intra ([156.150.130.152]) by DEHHX001.deuser.de.intra with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 16:43:15 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: RFC3280bis: NotAfter 99991231235959Z
Date: Wed, 15 Nov 2006 16:43:13 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3280bis: NotAfter 99991231235959Z
Thread-Index: AccIy4Ta4L/ZxdwqTMi55PUt54Q8lAAAJQkQAAAkvyA=
From: <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 15 Nov 2006 15:43:15.0323 (UTC) FILETIME=[C3B6B4B0:01C708CC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAFFhMGE034878
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI

> -----Ursprüngliche Nachricht-----
> Von: Beckmann, Thomas [S229271] 
> Gesendet: Mittwoch, 15. November 2006 16:41
> An: 'Russ Housley'
> Betreff: AW: RFC3280bis: NotAfter 99991231235959Z
> 
> Russ,
> 
> what about the validity of the issuing ca? In general, the ca 
> certificate isn't valid that long, so the devices certificate 
> becomes invalid when the ca certificate expires. How will you 
> handle that?
> 
> Thomas
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [e-mail]
> > [mailto:[e-mail]] Im Auftrag von Russ Housley
> > Gesendet: Mittwoch, 15. November 2006 15:56
> > An: [e-mail]
> > Betreff: RFC3280bis: NotAfter 99991231235959Z
> > 
> > 
> > I would like to add some text about certificates that are 
> not intended 
> > to expire.  I propose the following paragraph.
> > 
> > In some situations, devices are given permanent certificates. 
> >  For example, a device could be issued a certificate that binds its 
> > model and serial number to its public key.  Such a certificate is 
> > intended to be used for the entire lifetime of the device.  It 
> > indicate the permanent nature of such a certificate, the notAfter 
> > SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
> > 
> > Any concerns?
> > 
> > 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 kAFFZanB032536; Wed, 15 Nov 2006 08:35:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFFZaL5032535; Wed, 15 Nov 2006 08:35:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from top-cross.ru (top-cross.ru [194.226.79.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFFZYNB032491 for <[e-mail]>; Wed, 15 Nov 2006 08:35:35 -0700 (MST) (envelope-from [e-mail])
Received: from [62.181.53.2] (account jim HELO [192.168.0.59]) by top-cross.ru (CommuniGate Pro SMTP 4.2.10) with ESMTP id 615820; Wed, 15 Nov 2006 18:36:03 +0300
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 18:35:24 +0300
From: Kopylov Denis <[e-mail]>
Reply-To: [e-mail]
Organization: OOO =?UTF-8?B?0KLQvtC/INCa0YDQvtGB0YE=?=
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: [e-mail]
CC: Peter Rybar <[e-mail]>
Subject: Re: questions on CertificatePolicies processing
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Rybar пишет:
> Some info are in
>
> http://www.nbusr.sk/sep/leg_rozne/kontrola_cert_cesty_en.pdf
>   
Thank you for the link. But there is no answer in that PDF - just one 
more description for validation procedure.
Main thought behind my questions is that there should be some difference 
in interpretation of empty valid_policy_set - depending on 
user_initial_policy_set value.

-- 
======================================================
Kopylov Denis
kopylov at top-cross.ru




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 kAFFXRRM031964; Wed, 15 Nov 2006 08:33:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFFXRR8031963; Wed, 15 Nov 2006 08:33:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFFXQ5S031940 for <[e-mail]>; Wed, 15 Nov 2006 08:33:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32226 invoked by uid 0); 15 Nov 2006 15:33:23 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 15:33:23 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 10:31:37 -0500
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[e-mail]>
In-Reply-To: <[e-mail] eme.net>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh:

My point is that the request could be for any set of certificates 
that contain AIAs that point to the same OCSP responder, whether they 
are part of the same certification path or not.

Russ

At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
>Russ,
>
>I do not know how germane this debate is to Sam's question, but I was
>simply responding to the issue building certification path.  I presume
>that in this context it relates to building a path to the Responder
>certificate.
>
>Now let us look at the three model 2560 has: Explicitly Trusted, CA and
>Delegated.
>
>Explicitly trusted does not need a certification path and hence there is
>no issue and that is why I did not include it in.
>
>CA model does not need any path building since path to the CA has
>already been built and that is why I did not include it in my response.
>Note that both clients requires the CA to use the same to sign the OCSP
>as it signed the certificate in question with.
>
>My post responded to the Delegated model.
>
>I hope this clarifies that the path building should not be a major issue
>for all three models 2560 supports.
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 6:42 PM
>To: Santosh Chokhani; [e-mail]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>I believe this is a red herring.  This is not the only deployment
>approach supported by RFC 2560.
>
>Russ
>
> >In hurry, I did not clearly articulate my thoughts.  What I am saying
>also
> >relates to another comment to Mike Myers regarding the security of the
> >delegated model which is incompletely addressed by 2560.
> >
> >I will be verbose this time.
> >
> >The implementations such as Corestreet and Tumbleweed tend to adhere to
>the
> >approach that the same key that signed the certificate in question,
>sign the
> >OCSP Responder certificate.
> >
> >Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
>want
> >the status of CA certificate and the Subscriber certificate, you get
>them as
> >responses and with them you only need the two OCSP Responder
>certificates
> >one signed by the Root (for verifying CA certificate revocation status)
>and
> >one signed by the CA (for verifying the subscriber certificate
>revocation
> >status).
> >
> >You do not need any paths.
> >
> >Please note that the approach also works when the Responder is queried
>by a
> >CA cross certified by the root, since rest of the path has been built
>by the
> >client.
> >
> >-----Original Message-----
> >From: Dave Engberg [mailto:[e-mail]]
> >Sent: Tuesday, November 14, 2006 12:45 PM
> >To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
> >[e-mail]
> >Cc: Sam Hartman; Michael Myers
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >CoreStreet's OCSP server doesn't include a SingleResponse for the
>issuing
> >CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
> >
> >Adds 90-100 bytes onto every response
> >
> >Have never seen a relying party app/plug-in send a request like this
> >
> >The "delegated" trust model in RFC 2560 would require different signing
> >certs for trusting entity vs. CA cert ... add another 1kB onto the
>response
> >
> >Protocol only sends CA name+key info, which isn't enough to identify
>which
> >CA cert the relying party is inspecting in the case of CA cert renewal,
> >cross-certification, etc.
> >
> >
> >-----Original Message-----
> >From: Stefan Santesson [mailto:[e-mail]]
> >Sent: Tuesday, November 14, 2006 12:11 PM
> >To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
> >Cc: Sam Hartman; Michael Myers; Dave Engberg
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >Santosh,
> >
> >I didn't say it was hard. I say that I doubt that there are many
> >implementations supporting this scenario even those with a responder
>key.
> >It would be interesting to hear from implementers if I'm right.
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
> >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: den 14 november 2006 03:59
> > > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > > Stefan,
> > >
> > > You are making more complex than it is.  The Responder can include
>all
> > > the CA certificates that issued the certificate in question and AIA
>can
> > > do the rest.
> > >
> > > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > > environment, the CA certificate certification path is not an issue.
> > >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]]
> > > On Behalf Of Stefan Santesson
> > > Sent: Monday, November 13, 2006 6:54 PM
> > > To: Russ Housley; Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I'm not sure the case described is a realistic one.
> > >
> > > Section 2.2
> > >    All definitive response messages SHALL be digitally signed. The
>key
> > >    used to sign the response MUST belong to one of the following:
> > >
> > >    -- the CA who issued the certificate in question
> > >    -- a Trusted Responder whose public key is trusted by the
>requester
> > >    -- a CA Designated Responder (Authorized Responder) who holds a
> > >       specially marked certificate issued directly by the CA,
> > > indicating
> > >       that the responder may issue OCSP responses for that CA
> > >
> > > Since the request is on certificates issued by 2 different CA:s
>trust
> > > option 1 is invalid.
> > > Trust option 3 is valid in theory but in practice it requires that
>the
> > > OCSP responder provide multiple validation paths in the response,
>one
> > > for each issuing CA. Somehow I doubt that this is implemented by
> > > anyone.
> > >
> > > Trust option 2 is not generic and is only valid as a result of a
>local
> > > configuration.
> > >
> > > So I don't think this is a problem only for key-less responders.
> > >
> > >
> > > Stefan Santesson
> > > Senior Program Manager
> > > Windows Security, Standards
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:owner-ietf-
> > > > [e-mail]] On Behalf Of Russ Housley
> > > > Sent: den 13 november 2006 14:08
> > > > To: Price, Bill; [e-mail]
> > > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > > I prefer an error that tells the client to ask for the certificate
> > > > one at a time.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > > >
> > > > >I'd suggest focusing on understanding where responses to the
>keyed
> > > and
> > > > >keyless responders inherently differ. I am aware of two general
> > > cases:
> > > > >
> > > > >1) The request asks for the status of multiple certificates that
> > > have
> > > > >not been included in a single presigned response. Russ's example
> > > fits
> > > > >into this case. The keyed responder handles, but the keyless will
> > > fail
> > > > >for the general case. Some responders respond with the presigned
> > > > >response that includes one of the certificates (usually the
>first)
> > > in
> > > > >the request. A common situation is to ask for the status of
> > > > >certificates in a chain. Santosh points out some keyless
>responders
> > > > >anticipate this and bundle responses accordingly.
> > > > >
> > > > >2) The request is "well-formed" but asks for the status of a
> > > > >certificate for which the keyless responder has not prepared a
> > > > >response.  This situation will occur if:
> > > > >
> > > > >     a) The request is for status of a certificate from a
>supported
> > > CA
> > > > >but with a serial number for which there is no pre-signed
>response.
> > > > >Assuming presigned responses exist for all certificates that
>would
> > > be
> > > > >valid based on their validity intervals, this would occur if the
> > > > >certificate had expired or was yet to be issued (I am aware the
> > > > keyless
> > > > >responders generally produce responses for certificates likely to
>be
> > > > >issued before the next generation of presigned responses). The
>keyed
> > > > >responder would give a signed "good" response. My understanding
>is
> > > > that
> > > > >the keyless responder under the draft lightweight OCSP responds
>with
> > > > an
> > > > >unsigned "unauthorized" error code.
> > > > >
> > > > >     b) The request is for the status of a certificate from an
> > > > >unsupported (or non-existent) CA. The keyed responder would
>respond
> > > > >with a signed "unknown" response while under the draft, the
>keyless
> > > > >would again respond with the unsigned "unauthorized" error  code.
> > > > >
> > > > >Some might argue with some grounds that these differences are
> > > unusual,
> > > > >unlikely, and insignificant.
> > > > >
> > > > >I personally consider the behavior in 2 of responding with the
> > > > >"unauthorized" error to be misleading. "Internal error" sounds
>more
> > > > >appropriate if I were constrained to the current error codes.
> > > > >"Malformed request" might be OK. However, the actual situation
>does
> > > > not
> > > > >match well with any of these errors as they are described in
>2560.
> > > > >
> > > > >If 2560 is supposed to encompass keyless responders, I'd
>recommend
> > > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > > codes
> > > > >for the above cases (assuming they are the only differences). The
> > > > first
> > > > >error can be worked around by breaking the request for status of
> > > > >multiples into multiple requests for status of one cert.
> > > > >
> > > > >We've also seen some problems with client apps that can't handle
> > > > >presigned responses that commonly contain the status of several
> > > (e.g.,
> > > > >15-25) certs. The apps inquired for the status of a single cert
>and
> > > > >apparently expected a response for a single certificate. I'd
>suggest
> > > > >that some "must" or "should" words address clients' ability to
> > > handle
> > > > >the situation of a response covering multiple certificates.
> > > > >
> > > > >
> > > > >
> > > > >Bill Price
> > > > >
> > > > >-----Original Message-----
> > > > >From: [e-mail]
> > > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > > >Sent: Monday, November 13, 2006 11:46 AM
> > > > >To: Michael Myers; Dave Engberg
> > > > >Cc: [e-mail]; Sam Hartman
> > > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
>2560
> > > > >
> > > > >
> > > > >Mike:
> > > > >
> > > > >I think it is not that simple.  I think you need to say that
>support
> > > > >for one certificate MUST be supported, and that support for more
> > > than
> > > > >one certificate is OPTIONAL.  Then, the error is am indication
>that
> > > > >the requestor has selected an unimplemented OPTION.
> > > > >
> > > > >Russ
> > > > >
> > > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > > >Responders unable to produce or acquire a definitive response
>MUST
> > > > >return <a
> > > > > >TBD error>.
> > > > > >
> > > > > >As to your other points Santosh, that is something I prefer the
> > > > chairs
> > > > > >consider.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > > >
> > > > > > > Mike,
> > > > > > >
> > > > > > > What is the error case?
> > > > > > >
> > > > > > > . . .
> > >



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 kAFFXQNu031948; Wed, 15 Nov 2006 08:33:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFFXQSQ031947; Wed, 15 Nov 2006 08:33:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFFXPGS031939 for <[e-mail]>; Wed, 15 Nov 2006 08:33:26 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32163 invoked by uid 0); 15 Nov 2006 15:33:22 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 15:33:22 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 10:29:37 -0500
To: Stefan Santesson <[e-mail]>, Sam Hartman <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "[e-mail]" <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>, "Price, Bill" <[e-mail]>
In-Reply-To: <[e-mail] ope.corp.microsoft.com>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe that this paragraph from RFC 2026 is the reason that Sam is 
willing to permit the document to progress as a Proposed Standard:

    A Proposed Standard should have no known technical omissions with
    respect to the requirements placed upon it.  However, the IESG may
    waive this requirement in order to allow a specification to advance
    to the Proposed Standard state when it is considered to be useful and
    necessary (and timely) even with known technical omissions.

Russ

At 05:56 PM 11/14/2006, Stefan Santesson wrote:

>Sam,
>
>Could you point us to the applicable interoperability requirements 
>IETF has established in general that would require such 
>clarification of RFC 2560.
>
>What is ironic in this situation is that this a cases where the 
>industry has been able to achieve interoperability (to a fairly high 
>degree at least), also with respect to keyless responders. I don't 
>think we serve the industry by denying publication of an 
>informational document describing how keyless responders has been implemented.
>
>Creating an RFC 2560bis may take considerable time.
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
> > -----Original Message-----
> > From: Sam Hartman [mailto:[e-mail]]
> > Sent: den 14 november 2006 14:23
> > To: Stefan Santesson
> > Cc: [e-mail]; Michael Myers; Dave Engberg; Russ Housley;
> > Price, Bill
> > Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > >>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:
> >
> >     Stefan> On issue number 1) it is my belief that the lightweight
> >     Stefan> profile should be allowed to progress without updating RFC
> >     Stefan> 2560. I have seen no requirements in RFC 2560 that
> >     Stefan> requires a keyed responder, even if it is clear that a
> >     Stefan> non-keyed responder can only respond to a subset of all
> >     Stefan> valid requests. If the lightweight OCSP profile is allowed
> >     Stefan> to progress, it MUST live within the current restrictions
> >     Stefan> of OCSP with respect to error codes.
> >
> >
> > Speaking as an holding a discuss, I cannot agree to allow the
> > lightweight profile to progress without a standards-track
> > clarification to 2560.
> >
> > Your reading of 2560 would not meet the interoperability requirements
> > that the IETF has established that in general, all clients of a
> > protocol be able to work with all servers of a protocol.  In order to
> > meet that requirement RFC 2560 needs to be normatively changed in
> > order to require that clients be able to send a request including only
> > one certificate.
> >
> > Unless I see new arguments I have not seen so far, my discuss stands.



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 kAFEu0Yk020240; Wed, 15 Nov 2006 07:56:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFEu0E4020239; Wed, 15 Nov 2006 07:56:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAFEtxae020231 for <[e-mail]>; Wed, 15 Nov 2006 07:55:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26657 invoked by uid 0); 15 Nov 2006 14:55:53 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 15 Nov 2006 14:55:53 -0000
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Wed, 15 Nov 2006 09:55:47 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RFC3280bis: NotAfter 99991231235959Z
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to add some text about certificates that are not 
intended to expire.  I propose the following paragraph.

In some situations, devices are given permanent certificates.  For 
example, a device could be issued a certificate that binds its model 
and serial number to its public key.  Such a certificate is intended 
to be used for the entire lifetime of the device.  It indicate the 
permanent nature of such a certificate, the notAfter SHOULD be 
assigned the GeneralizedTime value of 99991231235959Z.

Any concerns?

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 kAFD0K7H083010; Wed, 15 Nov 2006 06:00:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFD0KD5083009; Wed, 15 Nov 2006 06:00:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from top-cross.ru (top-cross.ru [194.226.79.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFD0Hsk082999 for <[e-mail]>; Wed, 15 Nov 2006 06:00:18 -0700 (MST) (envelope-from [e-mail])
Received: from [62.181.53.2] (account jim HELO [192.168.0.59]) by top-cross.ru (CommuniGate Pro SMTP 4.2.10) with ESMTP id 615752 for [e-mail]; Wed, 15 Nov 2006 16:00:45 +0300
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 16:00:07 +0300
From: Kopylov Denis <[e-mail]>
Organization: OOO =?windows-1252?Q?=3F=3F=3F_=3F=3F=3F=3F=3F?=
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: [e-mail]
Subject: questions on CertificatePolicies processing
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Q1: Is there any sense in setting user-initial-policy-set without
setting initial_explicit_policy?

Q2: How should be threated a valid certificate if validation with
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

-- 
Kopylov Denis
kopylov at top-cross.ru



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 kAFCOjoR077044; Wed, 15 Nov 2006 05:24:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFCOjUX077043; Wed, 15 Nov 2006 05:24:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from groucho.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFCOi3v077023 for <[e-mail]>; Wed, 15 Nov 2006 05:24:44 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 80D89348B7; Thu, 16 Nov 2006 01:24:38 +1300 (NZDT)
Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22853-15; Thu, 16 Nov 2006 01:24:38 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 51EE434892; Thu, 16 Nov 2006 01:24:38 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9C0E037742; Thu, 16 Nov 2006 01:24:37 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GkJos-0002ZS-00; Thu, 16 Nov 2006 01:24:46 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: PEM file format rfc draft request
Cc: [e-mail], [e-mail]
In-Reply-To: <p06230909c17f899afb7d@[128.89.89.106]>
Message-Id: <[e-mail]>
Date: Thu, 16 Nov 2006 01:24:46 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>I don't think these WGs generally have defined private key encodings, because
>private keys are not transferred over the net and thus are not critical for
>interoperability.

What you mean are "private keys shouldn't be transferred over the net but
frequently are".  The standard format for this is PKCS #12, but that's usually
wrapped up in MIME, not as PEM-format data.

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 kAFCLmLP076425; Wed, 15 Nov 2006 05:21:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFCLmb3076424; Wed, 15 Nov 2006 05:21:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chico.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFCLkdI076415 for <[e-mail]>; Wed, 15 Nov 2006 05:21:47 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 1A12B34B45; Thu, 16 Nov 2006 01:21:41 +1300 (NZDT)
Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18852-16; Thu, 16 Nov 2006 01:21:40 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id B840E34453; Thu, 16 Nov 2006 01:21:39 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CE6BE37742; Thu, 16 Nov 2006 01:21:37 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GkJly-0002Yw-00; Thu, 16 Nov 2006 01:21:46 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: PEM file format rfc draft request
Cc: [e-mail]
In-Reply-To: <01c401c707f9$3ac61660$[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 16 Nov 2006 01:21:46 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Dieter Bratko" <[e-mail]> writes:

>For that reason a standard giving some recommendations for the usage of PEM
>headers would be very useful. It should not only cover keys, but also
>certificates, crls, requests,... (for instance, some applications use -----
>BEGIN CERTIFICATE REQUEST-----. and some use -----BEGIN NEW CERTIFICATE
>REQUEST-----, and some may use  -----BEGIN PKCS10 REQUEST---- or something
>other for encoding a certificate request).

That's why I suggested that a regexp is the only way to handle this.  You also
need to take into account usage in other environments like PGP and SSH, which
also use the PEM format.  From memory my code's workflow is something like:

  look for '----';
  look for either another '-' or a ' ';
  look for 'BEGIN';

This handles the common PEM start.  Then:

  if the remaining text contains 'SSH' it's an SSH public key;
    goto SSH-processing;
  if the remaining text contains 'PGP' it's a PGP public key;
    goto PGP-processing;
  // Default: It's something X.509-ish
  if the remaining text contains 'REQUEST' or 'PKCS10' it's a PKCS #10 cert request;
  if the remainig text contains 'PRIVATE' it's a private key;
  otherwise it's a cert of some form;

This should handle pretty much everything out there.

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 kAFB3Kol063900; Wed, 15 Nov 2006 04:03:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAFB3Kul063899; Wed, 15 Nov 2006 04:03:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from top-cross.ru (top-cross.ru [194.226.79.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAFB3JKv063875 for <[e-mail]>; Wed, 15 Nov 2006 04:03:20 -0700 (MST) (envelope-from [e-mail])
Received: from [62.181.53.2] (account jim HELO [192.168.0.59]) by top-cross.ru (CommuniGate Pro SMTP 4.2.10) with ESMTP id 615685 for [e-mail]; Wed, 15 Nov 2006 14:03:46 +0300
Message-ID: <[e-mail]>
Date: Wed, 15 Nov 2006 14:03:07 +0300
From: Kopylov Denis <[e-mail]>
Reply-To: [e-mail]
Organization: OOO =?UTF-8?B?0KLQvtC/INCa0YDQvtGB0YE=?=
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: question on CertificatePolicies processing
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Q1: Is there any sense in setting user-initial-policy-set without 
setting initial_explicit_policy?

Q2: How should be threated valid certificate if validation with 
non-empty user-initial-policy-set resulted in empty valid_policy_tree?

-- 
======================================================
Kopylov Denis
kopylov at top-cross.ru




Received: from 161.pool85-56-32.dynamic.uni2.es (161.pool85-56-32.dynamic.uni2.es [85.56.32.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAF9Sk3J050647 for <[e-mail]>; Wed, 15 Nov 2006 02:28:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000401c70898$730be8c0$00000000@pcj>
From: "UsWork" <[e-mail]>
To: [e-mail]
References: <000401c70898$730be8c0$00000000@pcj>
Subject: Re: employee have
Date: 	Wed, 15 Nov 2006 10:28:46 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C708A0.D4D050C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C708A0.D4D050C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C708A0.D4D050C0"

------=_NextPart_001_000B_01C708A0.D4D050C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Thursday, November 03:23:02 AM
  Subject: employee have


  Chargethe employee have of only default job.
  Free day Triallog Inregister a Nowhome Pagemy.
  If does not start.
  Editorbuy of now Welcome a. Re Soft Boysdate Prevdate am Nextthread =
Prevthread of Nextdate Boysto Boysfrom of.
  Uploading toolbar ruler of url cliptext column selection replace =
multiple in.
  Click in here release a veditplus bit While can serve good a.
  Your homeyour of lifein updatehas am Roaming Gnome turned or party =
bal. Gui of builder generating human.
  Jamo surround sound is.
  Flash Player dc Limewire is Manager in Explorer am Basic is Ares.
  Cliptext column in selection replace multiple undoredo of spell =
keyboard shortcuts is. Viruses am add am my alerts suggest friend a =
report!
  Screen of applicable press theenter bhzbhzon enterkey left cost =
center.
  Then Hermann Maier strap carvers Cameras. Commission Junction for =
Million.
  Solos vii rock rhythm worlds.
  Info in Publisher User am Awards History service allows.
  Timekeeper entry charge in. Cliptext column in selection replace =
multiple undoredo of spell keyboard shortcuts is.
  Free day Triallog Inregister a Nowhome Pagemy.
  Gaining marketing with clients that include a.
  Address found Datere Cdnext Siamese jpegnext threadre Stuff?
  Upgrade is business line offering give individual employees members is =
Sony. License any listed cannot is liable issues arise?
  Ill am London just or atthe catch About eve who.
  Upgrade is business line offering give individual employees members is =
Sony.
  Featured integrated cd burning ripping in?
  Picks Essential Internet Instant is.
  Get chance some Visualcron task scheduler automation!
  Soft Boysdate Prevdate Nextthread Prevthread?
------=_NextPart_001_000B_01C708A0.D4D050C0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"always" hspace=3D0=20
src=3D"cid:000901c70898$730be8c0$00000000@pcj" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, November =
03:23:02 AM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> employee have</DIV>
  <DIV><BR></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Chargethe employee have =
of only=20
default job.<BR>Free day Triallog Inregister a Nowhome Pagemy.<BR>If =
does not=20
start.<BR>Editorbuy of now Welcome a. Re Soft Boysdate Prevdate am =
Nextthread=20
Prevthread of Nextdate Boysto Boysfrom of.<BR>Uploading toolbar ruler of =
url=20
cliptext column selection replace multiple in.<BR>Click in here release =
a=20
veditplus bit While can serve good a.<BR>Your homeyour of lifein =
updatehas am=20
Roaming Gnome turned or party bal. Gui of builder generating =
human.<BR>Jamo=20
surround sound is.<BR>Flash Player dc Limewire is Manager in Explorer am =
Basic=20
is Ares.<BR>Cliptext column in selection replace multiple undoredo of =
spell=20
keyboard shortcuts is. Viruses am add am my alerts suggest friend a=20
report!<BR>Screen of applicable press theenter bhzbhzon enterkey left =
cost=20
center.<BR>Then Hermann Maier strap carvers Cameras. Commission Junction =
for=20
Million.<BR>Solos vii rock rhythm worlds.<BR>Info in Publisher User am =
Awards=20
History service allows.<BR>Timekeeper entry charge in. Cliptext column =
in=20
selection replace multiple undoredo of spell keyboard shortcuts =
is.<BR>Free day=20
Triallog Inregister a Nowhome Pagemy.<BR>Gaining marketing with clients =
that=20
include a.<BR>Address found Datere Cdnext Siamese jpegnext threadre=20
Stuff?<BR>Upgrade is business line offering give individual employees =
members is=20
Sony. License any listed cannot is liable issues arise?<BR>Ill am London =
just or=20
atthe catch About eve who.<BR>Upgrade is business line offering give =
individual=20
employees members is Sony.<BR>Featured integrated cd burning ripping=20
in?<BR>Picks Essential Internet Instant is.<BR>Get chance some =
Visualcron task=20
scheduler automation!<BR>Soft Boysdate Prevdate Nextthread=20
Prevthread?</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000B_01C708A0.D4D050C0--

------=_NextPart_000_000A_01C708A0.D4D050C0
Content-Type: image/gif;
	name="order.gif"
Content-Transfer-Encoding: base64
Content-ID: <000901c70898$730be8c0$00000000@pcj>

R0lGODlh3AHcAYf/AAAAB4YAAAF4Cn6JAAAAiHwJhgByeLi/vbndtJfJ8TkaAFYbAIAtAa0dAMsc
AOQjCAA0ASQyBkc9Alk/B4U+AqkyAMI9A+k2BgZcABVWAEFVAGVsAItsDKZnALRkAuhaCAdyBRd0
Ck5zAFqOAISOAKiMA76OANh5BwCtACWYBT6uBWOXDHuZAKeXALyoCt6YAg7AAByzADXMAFi/AovN
AKu6ALG/AOK7AADbACbZAEDuAF3oAofqC6jsALzuCdThAA4AMxQAOjMAQVYAM4IATa4ESrkAM+wI
TQAbSBkfPjIXS1kpPH4dOpwVOMwRQtQSOABJNhk8RTg0N1g0RoFKM5w1Ncg3TepEPwBqRRxVS01s
TmZuM4BhCZJlMcVcRu5XRQmNSyl0TUd7QVZyTX2DNah4Pb14MdR9QgCiPhWrNUKcRlGXRnKUOJaT
O7aZQtapNwC4QSe0N0vFPGm2SHW+RpzFN7fIQdLJNgDgTSjuOUDSO27jSoPpQJnRQr7qQ+PnNAAG
gRgNgTUDcmYAhHQAe6sAi7YAjtYHgQYjgCUjcjsle1oUhHsnjasgjcstg9QRhg5Dcyc6hTJChGY/
goNOhKQ0dbRJfOtMfABXhiJZhURYhVpbh31ti6NegLVgd9dadw2JcS18fUiGg1x+d3F8jKaHg7yJ
guqHjg6ldhyUekCVdFyignmSeZ2jfMqdi9yuiwPAhyvNezW0hWrLjHjCjKrIfcjBh+O3dwDufSHT
gULXgmHbd3Plgp3WgLzig+3odgwKyhEOuDoKv1EAyI0AzKMMxLoAvNoCvwYXwykctEolvlQbv4oX
vZUTtckVzdsnxAQ4sxhHykZNxlw3xog9uZ43tLNIy+05sg5UvyBluDpeylZZtolVwp5UvsNbu+1s
tAp3shR5t0iBwGCNwY6Iu6Z8x8uEx9iGywCosSGjv06tzlWjy4irxqadzsGmxdyWxgDHsyO/vUax
x2S8znrBuaeytvr/+5GuqopyfPwKAAH5APv6AAAA9f8G/AD0+Pfz/yH5BAB98okALAAAAADcAdwB
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGnwn8uX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrMllq3cq1q9evYMOy
xEq2rNmzaNOqXcu2rdu3cOPKnUt3pti7ePPq3cu3r9+/gAMLHky4sOHDiBMrXvyxruPHkCNLnmyW
cUfKmDNrfmy5s+fPoEMXNCra4ubTqFOfLc26tevXYI1++EBwdm3as3Pntmf7Nm/duw32PghcuG6B
wIP/Vl7cnurn0KPHHX4cOW7axLH/tt5w+G3tzMFf/0dIfTx36ejTq7e6fTn23t59c2+/MP78gfC1
yy9o37jz9QAGGOBG+eV3n3/ldaffgfiZx9+CDGYH24QUVghRge9lmNx33zX3oH8g2pecgQn1Z+GJ
KP5Fmm0GkkiedyZ+KOOM1dFnnIjaCajjjtBxVF2NMS63n0I4SihjkAcimeKSTMZWlHUYNliig0ra
GKGV3FWZ4EA8duklZj4GBySE97lIJJnxmcgimSA26eabrCkn5JX0mTllduJlKCWWdepXJZyABtoX
jH6OaOWaG95Yo3sLejiihmmyKeiklG5EWqBfZqrpgJhu6umnalUq6qikDgYAAKWmquqqQZ0KgEur
xv+qGKiSnRqTrLgaRitkr2aVa2IooDDqrpoNFOyxBB2L7ELKCpussswu22yzCi0r0LTGUnvttM5u
26092BakLbjfPjuuucE+a1C65JLLbbneQhuvvOJyiy687rK77br22qvuf8RS5m62zuqr70EGF5ww
vtkizDC/3ya878QHQ/xvuw1TzPDB1nbMrrUa1xvtvxUjVLK3BKeMMsYXt+yxQAGDWfHH3Z48Mb8i
J3SyzSJL3DDHwvKcrs8s22x0uURrDPTNTDtM8sMtR500xiXvjHTNzsZMmdVFP8w1zibjy7O6SQ8d
cdBeo51x12G33bPYak8dNdghM/T1205XDTfY7Gr/zV5GXMs99910z5031mSfnS+9Zq+9dOGDq41z
400bfu/C5xJMbeB7642t3pX/mpFRnIder+BC72235Gy3nrrr8NLLcs6JH16309UqPrvOquM9eey9
Z9y335FxDvLqob8OOe5Ujxvu7o4rfDztR/9u+77K8+77yMu3WzrtkU9MPFUafT+29d0nD/W8NDNv
ub/taw995ZRvn6/8+GO/vvrX289/zucT3VZmprC1IW93YyOc25rnPgNeLH7zM53UEPc0dOWvgfXL
3QJvRkD6BS+CAhSLxwrowOipbGAXlGDTMljC+XXwcUSr3glHuMLsbRCCGnQY1naoMtAV7mUhtNST
/+Y1wbBNL3MQAx73fvZB9rHwidJ7XBKnt7jwbVCHjPMX+KaIxbNtrl/PE9/4OBPEMt6FJ/QYY1DM
yMY2uvGNcIyjHOdIxzleqo54zONC3KLHPvqRIEn5oyAHeRB+8IMwhkzkIQ2SSIIospGMNKQjH6kQ
SQ7EkgKR5CMbiclMHnKTnbwkKDtJSVEucpKntEcpPalIVEKyIKtUZSpJmUqGxDKUsizkLHcpy032
spWijOQvgTlMVhITlZMUpjKTaUpawrKWyxylLhGCS7BgEpevzKUpn8lLTybkmq/UJDS9Sc5qVhKa
4bTkMYGZzkWCM5jkZOU2tflLeNoSnO4MZTXxef9KcU5zntnMpTnfSctaBtSZujRoPvupToUu5J3/
pOcz9QLRYFY0ngJlqD3/yc58UlOjEm0INh1az2ZiVJsVvag+QdrRh6zUmMxUZktDetKGOnOf43yp
RUlqzpKWk6T07KlPBwrSZXLEKBfN6Ebj6U+mjhOeM+1pU2n6UKAms6n+xGlQi5rUn8KUqhG96ieL
OtGSNjSs3pzqVGPKVqeG9Kwf3SpV4QrWmOJ0lOmEGVI0klS1olOjKX3qT+EqzXka85ho1SpWxzpX
xrr1sWW1qUdFmlPGdnWwk5XmSJWaVlCelKYE/atQ/dpYyH6ToetELVQFa5qi0HWnS5UrRIXK2cX/
nrObLrUqbM3q2Im+9reV7axwKTtNwj7Vtq+NrW05m1CyulWr5/QqdJkb3YiqdLJuieVjNyvXYt5T
srFFZnirG97FnlWxiNXudDtK27YOl7rcXKhzP0vatcYVtJPFb1Vhu97eklemZIVrdvN72OSi1JcH
/q58x8vc9pa1vL0NbXEJDFzrQhKx/93tV5u74elquJ4Otu+BtVtXjLayvyVmMF0RaskBb3S2QIUx
g79KTKKuNiLcvTFHecrVAFuVvaw1aoJN+lHwfvatFOZkkN8L2Rzfl8a6Dehpp9zdz7pYxx++sEMR
WmTxglXGEBmpar+8UIB2k8vt9HIvHxzJMa9U/7DZzKtRtczN0nrVzGxO8ZvlyWfD7rfJPibnlT+c
0VtuWbdsLiglX1pYKreZy4lOrW9/jGGJOrm5uJ0xpDWLYPqOFcGr9OxSderoF1dayo+WrEIlrc1A
EpI1Dn71a+4oa7HEutZ54SOubb3kXed6r74OtrBbq8ZiG/vYRBm2spftEGQ7+9nQjra0p03talv7
2tjOtra3fRpme/vb4A63uMdN7nKb+9zoTre6183udheG2/COt7znTe962/ve+E6Pu/fN7377+98A
D7jAB07wgpPqDm3Mt8IXzhaDO/zhEI94RBhO8YpjReIYz7jGN87xjnv849+2uMhHTvKSm5wuIP9P
eWdorSKbALImKm+5tAdzk5fTJOZ+oTbNXc4lmOOcL9FWB6wEU/Oe31yP+WhI0gO1dL1+iSOuOhVr
mm4Pqic9H1jPukCyjvWtc73rBPn61QvSdK573exUPzvYta72gXz9IGKvutXl/na4u53tW8/7Rcyu
drzznexhD3zc0371ut+d7XOvOhulLhDGhybxeU+74gPvdoRIfvKYn7vkCQ/4zFMe8pUnO+gvH3rM
e970EwE96lVves3bXe+k13vkS4/6ExnF8QWJOqoaH3V7uIr3vQc+43W/++Hv3ve7L7rTZ1J2z29e
IaSP/uk7T3naf94gY7d+7bPfeujLvvJv9zv/4uVOfdqzPvTNT7/lp//62a9++dDG/UAcb3xU/V7q
v0e+QfBvfP373//KBzDMB34EWH7Yt35213wHaIDSt33dZ4CKp4DfR33PN3lgF4GCd3kV+H2xt3Tq
534HKIHth4EaKIDxd3wEQX/Ft4K893/yp38qKHwIEYAu54EW2Hce+HcTeHh494Cih3bY93c2CHiG
F3bhB3vVt4AOeIMFCIIQOHpK5345qINWV4R0t3bSpyka8YIuyIL+x3/zt4K9F4PIx4UbwX3ZF3vm
h4AhqH1LmBBD+HxDqISlx321V4cLOIcReIQjyIFJCIfOt4MgqIZy2IcWcnsoGIaK+IUsGIOO/3h8
9ZeIRnd08HcraMiE3ueGd4iBgriBCKiHg2iIHyiIsleBemiHpOiJ59eGUrh+IkiHSAh4OveIi9h/
MAiJ9ieGXbiIi0iDMHeJoPh+mliCpSh4sMh57HeKsNh6q+iDp+d6TUiHyLiGxfiBxIiJ10eBsjht
woeL+ceILUh8YTiGuMiLLWiCvlKJMDGBZVd3Vhh9fFiHiBd+fOeOFyiEDBiP5KeJHNiDdPd54weH
/rh9Pah67QiEGViPOwh5S6eFd2GGEAGR46aGqUKRgiSRDYGRGCF2HNmRHvmRIBmSIjmSJFmSJnmS
KJmSKrmSLHmBuKaRCwGT4maRlEKTszZEYf/hi5Q4EifXk8D2c0AZlELpRix3ETL5fza3kzxHEj7Z
lMm2hbpXEUd5lBEBDuAwEFaJlVdplVyZlVmplfbQlVw5lGyEiCkoiQ4xlWipkzPxlWF5lQLhlXBZ
EF9Zl3M5iU6ZlzwBlQdhi1GZf+LYjbxIlQthl3b5lgjRlWBJlm9klvvnhfcHhoCZi7VYjuh4K3gZ
E4YJl3KZmGMZl3epjno5mk9Rht8YfOB4i4pIhlzIllkhl535lmJJEG4pm4pJmrgpFY8pg+fYf7TY
m2u5lJf5ErYJmod5EIoJmi2Rm8zZFLtpmpUZjuXImsHpc6IJK8mZnaGplW5Zm9fZnKTJl4P/iYJ+
SZnSGZ3nqBHaeZx0yZnuyZiN+SSBmZ6pyX+oGZXpyXiuiZm12Z1iuZV3CZu3CZ4E+g8lQZjwmaAh
gaAKKpRFeZYqsZ/rWBIFSqANeqEYmqEauqHx+ZQRKpwuCRIVOqJWMZ/POTogqoEUqYNXmJkk+qLp
aJSW2RVWuI+Wl4N353UcKm6POJmCaZrkiZYM0XVCOJA5mqMuGaI7SpRF0aMQKn9kiJQuuo5EqqIC
aYQ2Sn4wuqVOEZhQap7jyRA1V6Vw14FVmKVdx6VqqhQv+KVSSnxCmpR20aJBeKVIeqZrmqfiCaFP
mogMqnRKqqRHqqNJapNLSkht6qdgmp8z/5p6/iioOnqnWHqocOSYfFqZk/mNUvqdBsqDomenhIqn
eTqqQzEWNVh4IZqq7Rip+wh2pPqqQGGqPleEcceqdOqpnAqruoqZH2qdWSqiuzqirQGplOpt0jGp
IhGsyiqcsBGAzbasFXqIzNoQ0LpwxXqth/GnhRGn2BpH+BmT3AquJgp14ZqWCFGu3VohlqqR2mqO
H2GGzvqtAFitFnqpuYef+OqFfamomRqJ/vqj+imc9rd/vper9OqT97qv7qqam7qwqxmlYAicfBqA
A5uCjWewB3tyvPmXjQqcEgmREcuou9iww0mc9gqJGJux1vauaEmdwYeaCnuW5Hip9vmy6P/KEP3a
rulKKlz4m4z4sUH6sDS7qA4rEcWXezsLJ+vasrpYf0Vrjk6Le1FrmVKbfNN6tBZbsiqrbRshr/dq
s/cZrl86szKbszJLnxkJsxebtG7yoBmhs2lLEc5asAqxtfWmF3AbtyRxs2yLIm4rowuqthAxt2Jq
t+HJFRJqsqBhuNjWFYk7dIvLuJ7St5SbEH97Eo/bqZErudQ2rjFLsg+RuQIRAKRLulxRuqhbEZy7
KXuKkXnbEaY7ugEguyoRu7RbuZ+xtOP4rzWrgmHLqXIaE7ZbEMNrEsNbvKG7upnSukwrsj4KsXzL
EMhrD6hbvbaburJbvQRhvQdxvLNLvd//S7vei7t9gYiCK7Hnmb4NK7rTe73jC77ZOxCx677dy723
K77hC7/Ku7xvS7ReOp0A/LQZgb33+774u72za8AIvMDwK7/fO7/5S76/RhS2OLI+G7KtKZzMSr/3
28AH7MAeHMIgvMDvC8Epu78xQ53A57wBXIa9qMG+ersc3MGmO74KPMIgbMAEjMJesqc/e5qSSbXf
+rr1W8D5a8NHnMBJXMQkvMTZG8ESjBeX2xEZ7Ks2McMzLMMP7MQQDMUhbMLxi8Nay8PEcxJVrJQw
p70ITMAOnMXuy8ZtzMbW68QnTMao4RdeqxjTaxF7HMU5ObknAcYbUbx2vCN+BMcD7MV+/ywWU5wi
hBsShWxslPLIwBrJ6rHIldvI2xq9MzitGbm257qcljw+P3qgTBukfCuT8CqwmtqXa9uyojzKx8q8
JtGzVZvKN6uzKJsQWBvKmCwatvywkWm2QCqGY2vMAEu2/wqkaIuz8wfKdIu1uliwrfzLihHM0umN
YeqjDQu2kmifQmvBQRuRz0y3r3zOKEt/1mwZ2Myw9HnB+tqnIRvOvCnOMgqYWSvN5gzNnLzOe9HO
83zLZJuaCavMHHu2u8vNUmmx5HnO0Tx8WevPiQHQi1q1J1rBfOqbLVzP7UwRDd3Q0QzN1BzREi2r
pfqbkXmyG43R6BmxKR3OKvzCvvrRtf+Izs/c0LKsb10btgP9pjY7nor6nOJo0T+Mys0srr4b0kqN
z+Vc0k791KqLk50SwzyZ034zyZ4MyVYdHVBdrFv91WAd1mI91vTW1ZRK1mid1mq91mzd1m791nBd
cWY913Rd13Z913id13pNGHHd137914Ad2FOx14Rd2IZ92KIi2IrNq4gdlIv92Jrb2JI92YIE2YtN
2UBp2YqN2T+n2Z792W7N2TinyaK9JD1c2pVy2t3cvJ1BxGbdw/MZ23k8sqB7rqd8vhEBsv3cjUDL
suTq2rWNx/8buBMXGb/Nr8ht22Eakay9076dlru9EsAd3H0x3U1CGrLN09X8wx7ru8b/HNQJW9Sl
HImYusz2ytuCma/DTMzkPd7bXdTeCJPa7a/xra+9W9/u3dHCDMQ5i9+3ON+ootr6fdTdrb4uHc8O
+9NDm74aLczK/bXo66Qr/N99auDmic3Py8k8nc0WvosZHt4Mm6gKq9AO7s4ljsEBbtz/nIsHTs8J
/r8srcIi7rOPedARvtEeHtRuqr4PTuM4C5krDaYonuMgPs81/tNRSs9G7s5DztdSTcX9ytvIfNRm
mOTFDOTwDLoifuM2zsLh7c1RHrM+Dq7oy+RCfuZEXrZhDuIV3t1DPuNBPsZvwRfeTOBlft4bC95s
Do5jvrAxveVeft5LjucEPei8nK9K/47mWb7jD07obx7ncJ7obVTnac7SVE7i9lyeaf65y13BAY3j
Ia7oCF7mS97Rjy7pU+vilf7NzYvSp17QLfze5fvkUK7S/G3Uat7izLzr3O3mdg6ntL3e8TzcGX3r
8b2vTY7oJ2rm4mzsaL7rQ7zdweyyLy3ezF7Mcq5rGmfd/8btTEnr5Obt/SZ1qn1u4s5u+CkZqJ1y
oP3X6w5y7e7X7z7v9B4r8X7v+J7T9b7v/I7V+d7W/Z5x/x7aAV/wBn/wCJ/w/zbwDN/wDv/wzKnw
BgfxaC3xFn/xGD/XFL/xHN/xHv/xIB/yIj/yJF/ylizZsJrxAUfadB3JKF/IL2/HBf9QAAQx8zVP
8zOf8zZv8zdvDzqf8wvx8wPx8zxP9Dzv8zqfEEKP9AVx9EgP9ENP9FEv9U+f9FXv9Aix9AKB9Vg/
9UvP9TR/9Uf/9Vrf82a/9WHP9HV8FlqAbBrh9HCP82l/9kU/90Gf9nWvEGDPEF2/92gf9YAf+IL/
9wYx9nbf9Hif+HPf9Yjf+GbP+H2f+Ijv93FfcKRR93mv9oUv94Ov94dP+Flv94zv+GcP+oY/+H7f
+aCv+Zsv+FbP+geR+oQP+Ydf+V7v+Laf7Xar9laf+a1/+nz/+avf+qUf+sQf+JS/+KK//LGv/Mb/
+FAP+8c//L5f/Kwf95Gf+in/9mH/3/vdL/xPb/3Nr/TgL/2jX/zJj/uST/rDv/qjn/7VP/7o//3P
j/rrD/ayL5RkD/VU3/n9DxD2BA4sUGDgQYEFFRpEWBBhQoYPDzokuHAhxIYMLUacyNHexoodJX70
SNGhSY8PKYYUSfJiS4wsScaEKXPkTZw5de7k2dPnT6BBg/4jWtToUaRHIaJcuVKlU6c3myqkKTGq
zZFTM1adOfMq169QU4LVWLar1JJpuW6tqvUs1rNJ5c6lW9fuXbx59e7l29eu0KxUXUb86pXw2Kds
C6+Fm/ht16goGUceKzaw4sOLyWLOKZml5ZqMAY8mXdr0adSp0TI9fNmtTtCaF2uO/0lZ5uurth2L
PotbMFq2nxELb7lRt2rkyZUvZ44c9OTWj3G6lT2cNmS1NF8/Pg6z+m2Ovy8H327VrPbw2UM3Z9/e
/XK/SG2KtcjdoPHOLweLt8+/4+/u6sPquaVeAik/8bozz7wEDxRwv+hqyi2i+Cq08EIMM9Twrvc6
9PBDEEMUcUQSS/QwQxNTVHFFFnna8EUYY5QxxhZrtPFGHHPUcUcee/TxRyCDFHJIIos08kgkk7wJ
RSWbdPJJwGaUckq9oLTySiyzBJJJLbv00kgqwxRzxi/LNPPHMdNU88L1dustwjYpazC4pwRTUE79
8CvQuvQGzIw1/TJq8EFBJ5wztP8HdTMOMUIbS7RPmtaUlMzUAl0QPEcrg/TNTencrCICPfN0PPQ4
I3W88lDdtLznRP0UuP7UE5XAM2u0tM6lMHVzvgjzZDSlAA+tTdOd7GT1vEthTfXSVuF881T78iNL
wWFHrXXFW/8ra1Zid1MUwF93pa9TVxsrtMBPZxuuWt6Kc7bcchFVT9VzzYV33WtHjBfUbZENq9to
DePtzuh8sxdfA40lL9zpAr1uP3nT5dNT2hrl1jVg8c03xH33FHDZf/3EqOO2FiXOY22pTfnjeUNu
GL1s2Q3429UONPdkmQvL9uGNPST5JKou3rVUd0dG+N2CW1P5ZqCBfnWtipMuVur/oqse7GnpFsZZ
51t57jknFGkN6SKhrT0WZo3vLVnmrNs0zOmAI36ZbVixMxVnupfWNbZwJxxoUsBfRM1kxxJ+dui3
DEZX2pn1VLxudyWjVm+iH3787LXjbvdwwrMm+WsTxT5cYOiSHZ0+2JBl29XPPe/VX4A3p07j0+HE
3G6562b9daI3B12nDP3W2mh+jWW50E7bfnQrv21zPObLHe76aF8bLT4t/6yHGOuoDV8YXO8oDHx8
8on6/Xz0lSt/fcDTd/990mYsg336k4L/fvxdrH9/uvL3/38ABlCAAyRgAQ14QAQmUIELZGADHfhA
CCKHSxGkIJb4R79KSc8/4bOZ/4T6BDLabW9PpoMQ9WjlsrU9T3qYeZTxNhgsaI3LWW0rWfWOF77/
hQ1g6kIcr0QCwqklC08e1F1m4kSu++zQiHiDy7FoFphV8e5mLnEb9yJ0QfYNTomQk12/chY7LvZu
cZkT4p8Otrh98W12JExcep7IICmOjoYr5OJxvLYxHYqLYVUclmeAmDo9aouIJGTNGa+GOzoVkm5Q
Q6Kh1uUrifGxjS+c1+iwuL4MUmyPU8SOH2dIQ00O73GBJB3X0Kg6H5YSlSLbG/YemcS8UW1uiyQY
JyN4wk120YWwYyPk7Ai7mEWyYyzbpe3M4klLhUqWnISb2hbZQ82VcFkV1JUhJf95SEiWrie3u1jU
TAU3OI4Rhbhr5itTiUhmHhOVa2QcISs5zfRNEJ3Ky1jqFClHW95tdef5jtWCmbA/frF1uyNjF/n1
tGBWsZY4FMglHVolhs6xngjyohjzGdGpOOiT1cwon+45Tm4NVHWA4o83xYk0y00sd6J56PiSM8pR
pXSQrvtJ9Kwm0WpS0ZfJ6x3qQInI7VBukjk9ZDvnGU143jKZCRWeUZtFTOgtFXzMq2TKVuomGZJU
birsaKpEt1Lt8WyIpCQq/ORJTbQmqaWBS2tb3Yqks75Vrj5aa/vmele84qiue+VrX/36V8DiJa+D
JWxhDXvYMwVWsYtlbGMd+1j/yEZWspOlbGUte1nMZlazeUFsZz2rvs2GVrSjJW1pTXta1KZWtat9
kTVY+9rGfla2s40fbG17W9zmVre75W1vfftb4AZXuMMlbnGNe1zkJldDtGVuc/WnXOhGF7bOpW51
ESJd7Gb3tNblbne9+13whle84yVvec17XvSmV73r/Yl23fvezLJXvgyEb33te1/85le/++Vvf+s6
XwAjMK4BJvB1p1tgBEvEtkEBgIgA0OAcQRgoEmYOhUHUYAg/eDkUtvBIOjwkDNvDtg/WsEA+fJAP
n3jCJUaIiic8EBfzJMQmbjFOJGzhGL84xzdR8Y5pPOMNo3gnHAZMj1Vz4hBD//Y0N5Zxc5CMGh/7
hMk9mbKTi2yaEEdZKETWiZZtzOMje9geXvYSkTNcYhKP2cRoHrOGWZxmNWf4IWdGc53ljGE339jO
am4znXFM4zj3uc93hjOM88xmQaN4z29mM473POg10/nHhS50ix+dZUBLOtCQhnGkDS3nQJNYzyz2
NJxNfek8fzrSmq60kzJkZj4DWtY/5vOdO/3mOcsayExGNKhv/WtazxrUmNb1pmMda14fu9PB9jWt
uVzsZOd618rONbSHPes4+xrWwQ41t6e9bGx7G9i2FneVDfxaWON62aLeNKHTHGNtIxvYtc70u+f9
bWd3G9ryBneySb3qGQ/b3v/Plne0V21sPH953/n2M7+PPW1eGxzfbQY3pEft5kwPGuKGVvBjlyxk
PT+84PQ2drhrPPKFk3zj5a44pok9cnNXedcEVznMhdxvlNtc109OuctzHvOftzvolnb4xGv+Z26v
OX9T3jbLr21wasdb5vwmN8KHjnOr51vYOCd4tKv+cpGzfN9Al8jUny11rItd6CundtbdHnC1A7ni
rsYQuyc96loPPOOJprm9k27qdde7znmP981VvnFzU9zf/+b73tktd74jOu8HhzjjWy75ovv94Otm
tLa/bXdPK53Tl3a85M+c6IMoOcGyJbMCB7z6AbZarweGfe0fAljb5/53rz//+Yt7ZPnf87xLwH9P
609kWjEn3sWJt/KV5yz7arfdxnYmftmjH2XQM9jhpMmx8FFP6ernxNHh3/6QSX3xhv6VPcxXuPRr
1GEtG1/5Ur5+k6GMnO6X3ez33rLhh9z/eku7IHm1jMMzA3S38eM01Cs1vAs9uzvAT0vABYS/zhM0
VoO+rQs9RdM0BqxA/9NAzfM5vwM/CbTAfzs1+BNAZZNA0Ms+CsS7EaQ+MCs2GsM9LCvAonO7HCS7
r6sxf+M/rtM/tAtCcYu+cDu7qCPCFTS9sMu2uHO/v6s/4ZM5DjMyibO0Iey58stABRQSAhTBICS7
gnPBAnzAELQ6MYQ8H3w8/8NjuxT0PzJMOhrMNgw8QLm7woh7txTTvCSUw8s7wd6jPCCUNjZUQqNb
QZyzwdIAw/1Lw3k7uarTQjdsQyiEPCS8wg/MQSVMOzWUtkDEw0fkuE18w5LLRESEQ/5jv1K8xEE8
QhVEEwyhuh3cvv3LwB4ERUxMOeuDOlDkwpb7RT+sRelju6DLxSa8QykUM0hsxV4cxpwrRmDsPSZT
xEUMPMX7NeX7PEA8PPT7QcFjwefzwMgjvDnUOGzLvsZ7Pqo7QRJUNYvjPHJcwM07NSw0OfDbQHfc
QG08v3Z0wIBjwgi8QPJLL+PTPdnivSTBQIPMF2pcSId8SIiMSPHzPiUpyP/1s0jtu0FThEIqo8jx
OitSxD6F/D9VrMYPyT/ry8dW67FC7LI69EEjBEBK3Mj7Kw3cUo6QtL+Paz4PQUmi00LRm0GOfMVT
jMmMnMniqyAUQUF8bMFtxMdSw0Y6jEd5BDzBU0AURD95/L5Dq8etnLqb68Q27EdDHD1ydMpIjLwq
hECqbDcZdMCptEYOTLOb1MhSnMVzZMJLvMVQpEG4U8FJVEVklEZnnMNeE7+yLMsfZMVJI8yc1Lqf
bMaE68Nmu0v3IcBg5Dp0vLWWhMa7SzUsVLdjFMRyQ8fOzEnvM01zFMo85Ee9lErRtMM+vMtGDMmW
nESY/EfQFDH3gjrDHEr/S6TEZlQ0U3REySzMkkNNZQzEJlxO35w7XOQ431ROwvQ2JBTOVmS4zONN
7XpOYXwyXkxFZpzJv5RE8eTCwcTOlAzLaEyxxDxH8Ww6YtTF3+w6xcxOv/zF90pHomM6dhTHrFzH
eJQ9qzxLzsO4b9TACPRHr9zDkMvHcuREBY06PWw0/mQ1IbRHxHtKtWzAKqxOiyuxuiwsjLSuEpVI
IRlJgkRRFm1R00BIFx2s5OIRmhuRgvRIoUxRizzR/1tPkNuyGJtREtmxGnUwH83R+VvOn/BJmWRN
+jO55MBRsURM4NmuIyFSmjzJI1XSkjRKnczRowRTKpu7INtSy+wy/1lK/1SbTLTcPLX0R62cR+h8
S8200HRkSq50TbPUzbX00KmMOQQVuIazwD/MupU8ND+9yg5dUH2ESwzlwDcNNNTayYXjS7WDSaDM
VEwdzYijT3ybuNosx/kDyNGkt+NEz6vDSzRMvvF0ujW0R81sIMa8xdukuAW9OFANvBfM1bgrxNus
VQn9VPI8w1BcTHMMT6QzVYBDysDs01SNzncMymDdvbpTT0vlRNwUQKYrSl5dVfg0RloMQ209T5FL
VjBUTznc1sqc1iK8xie8z/k8PyWcVLtEuWvN1VzsVuYzxlPVt7cL17Eb13cl0+scztkEy1L11nIl
V8bsNu9k1qH0EjXFUP9T7cc8ZNRH68I4DM3yq9W1TFBbJUFH0zk3xUo+FE3izLzCQ9nfhFCl889u
7Lx9HL9HJc2qhEoJo9cLaxEeJRL5W78Y/T2e7Zmf5cmgfS4LoS//Wlo1OVqnHcBYJFM0dQ/g69nR
YFqs3asfZU4/BNEwjVCrNdOsHVspwT8l5Vq0/dotNNqnZb0YNECHLVC4FcgXVNAKFdStDVBH3Uqe
+IG2fR/M9Fdku1fP5NT6g8yUPU7M+xuybVzBscssQ9jAZFh0nVbGw9XCDdu/ZSCJE1bFbVXaNMTr
vE8ojdFW8CxkJV2F1deDfcTRnVxf3FzCYsN7bE2M1U2wXdyXxUYO1Vu8/gxZ2RWwqP0ajHRc44VR
AdLc4F1e5m1e531e6I1e0Dpe6q1ezpJe7M1e7R0S6+1e75WL7Q1f1fhe8i1f8z3f4xVf9V1f9m1f
931f+I1f+dUS9K1f+71f/M1f/d1f/u1f//1f+FIAAB5gAvbf+T3gcytgBV5gBm5gB37g70VgCeZO
CK5gC75gDM5gDd5gDu5g+ZhgEA7h9/VgEsYsEZbfEk5hFV5hFm5hF96QE45hGZ5hGq5hG75hHKau
gAAAOw==

------=_NextPart_000_000A_01C708A0.D4D050C0--



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 kAF3LSW4003262; Tue, 14 Nov 2006 20:21:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAF3LSuQ003261; Tue, 14 Nov 2006 20:21:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAF3LRAU003255 for <[e-mail]>; Tue, 14 Nov 2006 20:21:27 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ED5E6E0035; Tue, 14 Nov 2006 22:21:18 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 14 Nov 2006 22:21:18 -0500
In-Reply-To: <[e-mail]> (Stefan Santesson's message of "Tue, 14 Nov 2006 22:56:38 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

    Stefan> Sam, Could you point us to the applicable interoperability
    Stefan> requirements IETF has established in general that would
    Stefan> require such clarification of RFC 2560.

Sure.  Take a look at section 3.1 of
draft-carpenter-protocol-extensions (an approved BCP).  That BCP is
new, but the requirements in that section come from a long list of
RFCs that are quite old.  Brian included a list of RFCs discussing
interoperability in the recent atompub appeal response on HTTP
mandatory authentication.

A central principle of this interoperability is that there is an
interoperable protocol set where I can exchange one product for
another.

In other words I need to be able to set up my OCSP clients and servers
so that I can take vendor A's implementation and exchange it with
vendor B's implementation and have things still work.


The liberal interpretation of 2560 for servers is that they need to be
able to respond to any request.  However that's operationally
undesirable.  So, we need to modify the requirements of the protocol.
Really, we're fixing a spec bug: 2560 is way too unclear on this
issue.


Now, we've passed clarifications documents in the past.  That is
informational documents that describe errors in specs.  But that's not
what this profile is.  The profile is a protocol that specifies
requirements for clients and servers.  That's not something I can be
comfortable with unless it is clearly consistent with the spec.



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 kAF11PfE085379; Tue, 14 Nov 2006 18:01:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAF11Prh085376; Tue, 14 Nov 2006 18:01:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAF11OUk085364 for <[e-mail]>; Tue, 14 Nov 2006 18:01:25 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 17:03:24 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccISC4x/bjd35LmTReqe2+ofTYDggACP1bQ
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAF11PUk085368
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I do not know how germane this debate is to Sam's question, but I was
simply responding to the issue building certification path.  I presume
that in this context it relates to building a path to the Responder
certificate.

Now let us look at the three model 2560 has: Explicitly Trusted, CA and
Delegated.

Explicitly trusted does not need a certification path and hence there is
no issue and that is why I did not include it in.

CA model does not need any path building since path to the CA has
already been built and that is why I did not include it in my response.
Note that both clients requires the CA to use the same to sign the OCSP
as it signed the certificate in question with.

My post responded to the Delegated model.

I hope this clarifies that the path building should not be a major issue
for all three models 2560 supports.

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 6:42 PM
To: Santosh Chokhani; [e-mail]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh:

I believe this is a red herring.  This is not the only deployment 
approach supported by RFC 2560.

Russ

>In hurry, I did not clearly articulate my thoughts.  What I am saying
also
>relates to another comment to Mike Myers regarding the security of the
>delegated model which is incompletely addressed by 2560.
>
>I will be verbose this time.
>
>The implementations such as Corestreet and Tumbleweed tend to adhere to
the
>approach that the same key that signed the certificate in question,
sign the
>OCSP Responder certificate.
>
>Thus, if you have a hierarchy like Root --> CA --> Subscriber and you
want
>the status of CA certificate and the Subscriber certificate, you get
them as
>responses and with them you only need the two OCSP Responder
certificates
>one signed by the Root (for verifying CA certificate revocation status)
and
>one signed by the CA (for verifying the subscriber certificate
revocation
>status).
>
>You do not need any paths.
>
>Please note that the approach also works when the Responder is queried
by a
>CA cross certified by the root, since rest of the path has been built
by the
>client.
>
>-----Original Message-----
>From: Dave Engberg [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 12:45 PM
>To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
>[e-mail]
>Cc: Sam Hartman; Michael Myers
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>CoreStreet's OCSP server doesn't include a SingleResponse for the
issuing
>CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
>
>Adds 90-100 bytes onto every response
>
>Have never seen a relying party app/plug-in send a request like this
>
>The "delegated" trust model in RFC 2560 would require different signing
>certs for trusting entity vs. CA cert ... add another 1kB onto the
response
>
>Protocol only sends CA name+key info, which isn't enough to identify
which
>CA cert the relying party is inspecting in the case of CA cert renewal,
>cross-certification, etc.
>
>
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 12:11 PM
>To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
>Cc: Sam Hartman; Michael Myers; Dave Engberg
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh,
>
>I didn't say it was hard. I say that I doubt that there are many
>implementations supporting this scenario even those with a responder
key.
>It would be interesting to hear from implementers if I'm right.
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can include
all
> > the CA certificates that issued the certificate in question and AIA
can
> > do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > environment, the CA certificate certification path is not an issue.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]]
> > On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally signed. The
key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by the
requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA,
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different CA:s
trust
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it requires that
the
> > OCSP responder provide multiple validation paths in the response,
one
> > for each issuing CA. Somehow I doubt that this is implemented by
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result of a
local
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the certificate
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to the
keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned
> > > >response that includes one of the certificates (usually the
first)
> > in
> > > >the request. A common situation is to ask for the status of
> > > >certificates in a chain. Santosh points out some keyless
responders
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a
> > > >certificate for which the keyless responder has not prepared a
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from a
supported
> > CA
> > > >but with a serial number for which there is no pre-signed
response.
> > > >Assuming presigned responses exist for all certificates that
would
> > be
> > > >valid based on their validity intervals, this would occur if the
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates likely to
be
> > > >issued before the next generation of presigned responses). The
keyed
> > > >responder would give a signed "good" response. My understanding
is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds
with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an
> > > >unsupported (or non-existent) CA. The keyed responder would
respond
> > > >with a signed "unknown" response while under the draft, the
keyless
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the
> > > >"unauthorized" error to be misleading. "Internal error" sounds
more
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual situation
does
> > > not
> > > >match well with any of these errors as they are described in
2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd
recommend
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a single cert
and
> > > >apparently expected a response for a single certificate. I'd
suggest
> > > >that some "must" or "should" words address clients' ability to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [e-mail]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that
support
> > > >for one certificate MUST be supported, and that support for more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am indication
that
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response
MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >




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 kAF08Nb9077765; Tue, 14 Nov 2006 17:08:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAF08NVi077764; Tue, 14 Nov 2006 17:08:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.183] (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 kAF06gHA077655; Tue, 14 Nov 2006 17:06:43 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240874c18009a0dcb7@[10.20.30.183]>
In-Reply-To: <[e-mail]> <[e-mail]> <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 14 Nov 2006 16:06:33 -0800
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail], [e-mail], "David A. Cooper" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: PEM file format rfc draft request
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:25 AM +1300 11/15/06, Peter Gutmann wrote:
>I think the best you could do is create an kind of FYI RFC that
>documents all of the possible formats (I started this in my X.509 style guide
>some years ago), or maybe document a regexp that'll recognise all possible
>formats.

Yes.

At 5:27 AM +1300 11/15/06, Peter Gutmann wrote:
>"Ogle Ron" <[e-mail]> writes:
>
>  >If not PKIX, then where?
>
>A web page somewhere where Google can find it.  Given that this is such a
>moving target, I'm not sure that an RFC is the best way to document this even
>if you could find a WG that would adopt it.

Even better.

At 2:42 PM -0500 11/14/06, David A. Cooper wrote:
>Why is there need to base64 encode everything?  It made sense in PEM 
>due to the limitations of email, but what is the benefit of base64 
>encoding in other situations?

Copy and paste text. This is *commonly* used in IPsec UIs for cert 
issuance, and sometimes for trust anchor passing.

--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 kAENn3ir074974; Tue, 14 Nov 2006 16:49:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAENn3gR074973; Tue, 14 Nov 2006 16:49:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAENn2Ak074960 for <[e-mail]>; Tue, 14 Nov 2006 16:49:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19263 invoked by uid 0); 14 Nov 2006 23:48:54 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 14 Nov 2006 23:48:54 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 14 Nov 2006 18:42:07 -0500
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[e-mail]>
In-Reply-To: <[e-mail] eme.net>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh:

I believe this is a red herring.  This is not the only deployment 
approach supported by RFC 2560.

Russ

>In hurry, I did not clearly articulate my thoughts.  What I am saying also
>relates to another comment to Mike Myers regarding the security of the
>delegated model which is incompletely addressed by 2560.
>
>I will be verbose this time.
>
>The implementations such as Corestreet and Tumbleweed tend to adhere to the
>approach that the same key that signed the certificate in question, sign the
>OCSP Responder certificate.
>
>Thus, if you have a hierarchy like Root --> CA --> Subscriber and you want
>the status of CA certificate and the Subscriber certificate, you get them as
>responses and with them you only need the two OCSP Responder certificates
>one signed by the Root (for verifying CA certificate revocation status) and
>one signed by the CA (for verifying the subscriber certificate revocation
>status).
>
>You do not need any paths.
>
>Please note that the approach also works when the Responder is queried by a
>CA cross certified by the root, since rest of the path has been built by the
>client.
>
>-----Original Message-----
>From: Dave Engberg [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 12:45 PM
>To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
>[e-mail]
>Cc: Sam Hartman; Michael Myers
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
>CA's cert in pre-signed responses.  Mostly for the reasons mentioned:
>
>Adds 90-100 bytes onto every response
>
>Have never seen a relying party app/plug-in send a request like this
>
>The "delegated" trust model in RFC 2560 would require different signing
>certs for trusting entity vs. CA cert ... add another 1kB onto the response
>
>Protocol only sends CA name+key info, which isn't enough to identify which
>CA cert the relying party is inspecting in the case of CA cert renewal,
>cross-certification, etc.
>
>
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, November 14, 2006 12:11 PM
>To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
>Cc: Sam Hartman; Michael Myers; Dave Engberg
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh,
>
>I didn't say it was hard. I say that I doubt that there are many
>implementations supporting this scenario even those with a responder key.
>It would be interesting to hear from implementers if I'm right.
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can include all
> > the CA certificates that issued the certificate in question and AIA can
> > do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise
> > environment, the CA certificate certification path is not an issue.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]]
> > On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA,
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different CA:s trust
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it requires that the
> > OCSP responder provide multiple validation paths in the response, one
> > for each issuing CA. Somehow I doubt that this is implemented by
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result of a local
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf-
> > > [e-mail]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the certificate
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned
> > > >response that includes one of the certificates (usually the first)
> > in
> > > >the request. A common situation is to ask for the status of
> > > >certificates in a chain. Santosh points out some keyless responders
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a
> > > >certificate for which the keyless responder has not prepared a
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from a supported
> > CA
> > > >but with a serial number for which there is no pre-signed response.
> > > >Assuming presigned responses exist for all certificates that would
> > be
> > > >valid based on their validity intervals, this would occur if the
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates likely to be
> > > >issued before the next generation of presigned responses). The keyed
> > > >responder would give a signed "good" response. My understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an
> > > >unsupported (or non-existent) CA. The keyed responder would respond
> > > >with a signed "unknown" response while under the draft, the keyless
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the
> > > >"unauthorized" error to be misleading. "Internal error" sounds more
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual situation does
> > > not
> > > >match well with any of these errors as they are described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a single cert and
> > > >apparently expected a response for a single certificate. I'd suggest
> > > >that some "must" or "should" words address clients' ability to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [e-mail]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that support
> > > >for one certificate MUST be supported, and that support for more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am indication that
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >



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 kAENPN6E068791; Tue, 14 Nov 2006 16:25:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAENPN0Y068787; Tue, 14 Nov 2006 16:25:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAENPMIf068776 for <[e-mail]>; Tue, 14 Nov 2006 16:25:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30429 invoked by uid 0); 14 Nov 2006 23:25:14 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 14 Nov 2006 23:25:14 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 14 Nov 2006 18:16:52 -0500
To: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[e-mail]>
In-Reply-To: <[e-mail] ope.corp.microsoft.com>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan:

>There is no place where RFC 2560 requires the render to successfully 
>handle a composite request. It only specifies how it should be done.

It does not say one way or the other.  That is the problem.  It 
specifies the syntax, without telling the reader whether some or all 
of it is mandatory to implement.  This is the crux of Sam's discuss 
position.  Nothing in the text leads the reader to believe that 
responding to a multi-certificate query is OPTIONAL.

I find the use of "unauthorized" to indicate that a client cannot 
make a multi-certificate request unacceptable.  To me, that implies 
that some other client would be authorized to make such a request.

I also find the use of "internalError" to indicate that a client 
cannot make a multi-certificate request unacceptable.

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 kAENP2Tt068548; Tue, 14 Nov 2006 16:25:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAENP2B9068545; Tue, 14 Nov 2006 16:25:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAENOxHe068506 for <[e-mail]>; Tue, 14 Nov 2006 16:25:01 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29902 invoked by uid 0); 14 Nov 2006 23:24:51 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 14 Nov 2006 23:24:51 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 14 Nov 2006 18:12:36 -0500
To: Stefan Santesson <[e-mail]>, "Price, Bill" <[e-mail]>, "[e-mail]" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>
In-Reply-To: <[e-mail] ope.corp.microsoft.com>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It is not a problem for OCSP Responders that can relay the request to 
a server with a key.  That server can build the signed response for 
the arbitrary collection of certificates.

Russ

At 06:54 PM 11/13/2006, Stefan Santesson wrote:
>I'm not sure the case described is a realistic one.
>
>Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA, indicating
>       that the responder may issue OCSP responses for that CA
>
>Since the request is on certificates issued by 2 different CA:s 
>trust option 1 is invalid.
>Trust option 3 is valid in theory but in practice it requires that 
>the OCSP responder provide multiple validation paths in the 
>response, one for each issuing CA. Somehow I doubt that this is 
>implemented by anyone.
>
>Trust option 2 is not generic and is only valid as a result of a 
>local configuration.
>
>So I don't think this is a problem only for key-less responders.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed and
> > >keyless responders inherently differ. I am aware of two general cases:
> > >
> > >1) The request asks for the status of multiple certificates that have
> > >not been included in a single presigned response. Russ's example fits
> > >into this case. The keyed responder handles, but the keyless will fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first) in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [e-mail]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > -----Original Message-----
> > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .



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 kAEMumYO062830; Tue, 14 Nov 2006 15:56:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEMumr1062828; Tue, 14 Nov 2006 15:56:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEMulb8062808 for <[e-mail]>; Tue, 14 Nov 2006 15:56:47 -0700 (MST) (envelope-from [e-mail])
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.0; Tue, 14 Nov 2006 22:56:41 +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, 14 Nov 2006 22:56:40 +0000
From: Stefan Santesson <[e-mail]>
To: Sam Hartman <[e-mail]>
CC: "[e-mail]" <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>
Date: Tue, 14 Nov 2006 22:56:38 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccIO3m00C4dDHL3R7+eLiDtvJ2YrwAAzd8Q
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAEMumb8062823
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam,

Could you point us to the applicable interoperability requirements IETF has established in general that would require such clarification of RFC 2560.

What is ironic in this situation is that this a cases where the industry has been able to achieve interoperability (to a fairly high degree at least), also with respect to keyless responders. I don't think we serve the industry by denying publication of an informational document describing how keyless responders has been implemented.

Creating an RFC 2560bis may take considerable time.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Sam Hartman [mailto:[e-mail]]
> Sent: den 14 november 2006 14:23
> To: Stefan Santesson
> Cc: [e-mail]; Michael Myers; Dave Engberg; Russ Housley;
> Price, Bill
> Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> >>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:
>
>     Stefan> On issue number 1) it is my belief that the lightweight
>     Stefan> profile should be allowed to progress without updating RFC
>     Stefan> 2560. I have seen no requirements in RFC 2560 that
>     Stefan> requires a keyed responder, even if it is clear that a
>     Stefan> non-keyed responder can only respond to a subset of all
>     Stefan> valid requests. If the lightweight OCSP profile is allowed
>     Stefan> to progress, it MUST live within the current restrictions
>     Stefan> of OCSP with respect to error codes.
>
>
> Speaking as an holding a discuss, I cannot agree to allow the
> lightweight profile to progress without a standards-track
> clarification to 2560.
>
> Your reading of 2560 would not meet the interoperability requirements
> that the IETF has established that in general, all clients of a
> protocol be able to work with all servers of a protocol.  In order to
> meet that requirement RFC 2560 needs to be normatively changed in
> order to require that clients be able to send a request including only
> one certificate.
>
> Unless I see new arguments I have not seen so far, my discuss stands.




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 kAEMpFYm061493; Tue, 14 Nov 2006 15:51:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEMpFBO061492; Tue, 14 Nov 2006 15:51:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEMpDF5061476 for <[e-mail]>; Tue, 14 Nov 2006 15:51:14 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kAEMpCfA029215 for <[e-mail]>; Tue, 14 Nov 2006 17:51:13 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id BA13EBEFB for <[e-mail]>; Tue, 14 Nov 2006 17:51:12 -0500 (EST)
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAEMpBKl029192; Tue, 14 Nov 2006 17:51:11 -0500
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:51:11 -0500
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 17:51:11 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-index: AccIN1Bu2OcsfkXSTZaetgKu4hu8KAAA0SOQ
From: "Price, Bill" <[e-mail]>
To: "Carl Wallace" <[e-mail]>, "Dave Engberg" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2006 22:51:11.0688 (UTC) FILETIME=[619B5480:01C7083F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAEMpEF5061478
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have seen this behavior also (I mentioned it in my first post on this
thread). Keyed responders responded correctly. The problem of partial
responses occurred with at least one keyless responder. Such responses
appear to be out of compliance with RFC 2560 since it is not the case
that "A definitive response message is composed of responses for each
of the certificates in a request." 

If a responder that is multi-request challenged is supposed to give an
error, neither the standard nor the profile explicitly identify the
appropriate error message. If the choice of error message is limited to
the existing ones in the RFC, the error will likely be as informative
and helpful as the profile's "unauthorized" response is for the case
when the keyless responders don't have an appropriate presigned
response. 

If the partial response is to be acceptable, it seems that at least one
of the RFC or profile should be modified to so state. 

 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Carl Wallace
Sent: Tuesday, November 14, 2006 3:49 PM
To: Dave Engberg; Stefan Santesson; Santosh Chokhani; Russ Housley;
Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I've worked with a toolkit that can send multi-cert requests and have
seen
problems in this area including responders that return a successful
response
for one cert included in a request without addressing the others.  


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dave Engberg
> Sent: Tuesday, November 14, 2006 12:45 PM
> To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, 
> Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> 
> CoreStreet's OCSP server doesn't include a SingleResponse for 
> the issuing CA's cert in pre-signed responses.  Mostly for 
> the reasons mentioned:
> 
> Adds 90-100 bytes onto every response
> 
> Have never seen a relying party app/plug-in send a request like this
> 
> The "delegated" trust model in RFC 2560 would require 
> different signing certs for trusting entity vs. CA cert ... 
> add another 1kB onto the response
> 
> Protocol only sends CA name+key info, which isn't enough to 
> identify which CA cert the relying party is inspecting in the 
> case of CA cert renewal, cross-certification, etc.
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Tuesday, November 14, 2006 12:11 PM
> To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> Santosh,
> 
> I didn't say it was hard. I say that I doubt that there are 
> many implementations supporting this scenario even those with 
> a responder key.
> It would be interesting to hear from implementers if I'm right.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can 
> include all 
> > the CA certificates that issued the certificate in question and AIA

> > can do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise 
> > environment, the CA certificate certification path is not an issue.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf- 
> > [e-mail]] On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally 
> signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by 
> the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA, 
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different 
> CA:s trust 
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it 
> requires that the 
> > OCSP responder provide multiple validation paths in the 
> response, one 
> > for each issuing CA. Somehow I doubt that this is implemented by 
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result 
> of a local 
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf- 
> > > [e-mail]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC
2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the 
> certificate 
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to 
> the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless
will
> > fail
> > > >for the general case. Some responders respond with the presigned

> > > >response that includes one of the certificates (usually 
> the first)
> > in
> > > >the request. A common situation is to ask for the status of 
> > > >certificates in a chain. Santosh points out some keyless 
> responders 
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a 
> > > >certificate for which the keyless responder has not prepared a 
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from 
> a supported
> > CA
> > > >but with a serial number for which there is no 
> pre-signed response.
> > > >Assuming presigned responses exist for all certificates 
> that would
> > be
> > > >valid based on their validity intervals, this would occur if the

> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates 
> likely to 
> > > >be issued before the next generation of presigned 
> responses). The 
> > > >keyed responder would give a signed "good" response. My 
> > > >understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds 
> > > >with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an 
> > > >unsupported (or non-existent) CA. The keyed responder 
> would respond 
> > > >with a signed "unknown" response while under the draft, 
> the keyless 
> > > >would again respond with the unsigned "unauthorized" error
code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the 
> > > >"unauthorized" error to be misleading. "Internal error" 
> sounds more 
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual 
> situation does
> > > not
> > > >match well with any of these errors as they are 
> described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd 
> recommend 
> > > >identifying the unavoidable differences and/or adding 2 TBD
error
> > > codes
> > > >for the above cases (assuming they are the only differences).
The
> > > first
> > > >error can be worked around by breaking the request for status of

> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle

> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a 
> single cert and 
> > > >apparently expected a response for a single certificate. I'd 
> > > >suggest that some "must" or "should" words address 
> clients' ability 
> > > >to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [e-mail]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile 
> and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that 
> > > >support for one certificate MUST be supported, and that 
> support for 
> > > >more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am 
> indication that 
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response 
> > > > >MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer
the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >
> 
> 



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 kAEMR9iR057185; Tue, 14 Nov 2006 15:27:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEMR9b0057184; Tue, 14 Nov 2006 15:27:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEMR80B057175 for <[e-mail]>; Tue, 14 Nov 2006 15:27:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7728 invoked by uid 0); 14 Nov 2006 22:27:00 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (67.110.80.75) by woodstock.binhost.com with SMTP; 14 Nov 2006 22:27:00 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 14 Nov 2006 15:32:31 -0500
To: "Ogle Ron" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: PEM file format rfc draft request
Cc: <[e-mail]>, "Dieter Bratko" <[e-mail]>
In-Reply-To: <[e-mail]. thmulti.com>
References: <p06230904c17eb25c83ad@[128.89.89.106]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think there is value in publishing the format of "PEM" files.  I do 
not think it needs to be done in the PKIX WG, or any WG for that 
matter.  I would be willing to shepherd an Informational RFC through 
the approval process, which would include a 4-week IETF Last Call.

Russ

At 08:18 PM 11/13/2006, Ogle Ron wrote:

>I agree that the original PEM meaning is as you state.  I have no idea
>as to how it got skewed with these new meanings for public/private keys
>and certificates.  However, it does now exist.
>
>As for the relevance with PKIX, the "PEM" format also describes the base
>64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
>SSL, IPsec, and other cryptographic standards that use x509 also
>recognize PEM formatted certificates/key pairs.  This is how I
>discovered the problem in the first place.
>
>If not PKIX, then where?
>
>Thanks
>Ron Ogle
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Monday, November 13, 2006 6:45 PM
>To: Ogle Ron
>Cc: [e-mail]; Dieter Bratko
>Subject: Re: PEM file format rfc draft request
>
>At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
> >I would like to know if the PKIX working group would be interested in
> >shepherding a new rfc concerning PEM file formats?  I've recently
> >discovered that there is no definitive standard for how a PEM's headers
> >and footers are defined for a private key.  I've searched the RFCs, and
> >ISO standards without any luck.
>
>PEM formats were defined for e-mail messages, not files per se. I
>think RFC 1421 defines the last of the formats (we had a few
>iterations) for PEM.
>
> >The issue that I discovered was when I was working with PEM files for
> >PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
> >toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
> >to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
> >PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
>For
> >PKCS1, both expect "BEGIN RSA PRIVATE KEY".
>
>
>it looks like folks made this up!  PEM describes how to transfer a
>symmetric key encrypted under a public (RSA) key in a message, in
>1421.  It does not describe how to transfer a private key, because
>one would not do that via an e-mail message.
>
>The term "PEM file" with regard to PKCS #8 is a misnomer, relative to
>IETF standards. Since PKCS #8 defines a format for private keys, it
>is not relevant to PEM, period.
>
>Given that PKIX is a WG that focuses on X.509-based standards, it is
>not immediately clear that a document on how to use base-64 encoding
>and MIME-style headers to represent private keys is within our scope.
>
>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 kAEMN0qV056715; Tue, 14 Nov 2006 15:23:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEMN0hc056714; Tue, 14 Nov 2006 15:23:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEMMxVT056700 for <[e-mail]>; Tue, 14 Nov 2006 15:23:00 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8CCD7E0035; Tue, 14 Nov 2006 17:22:51 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 14 Nov 2006 17:22:51 -0500
In-Reply-To: <[e-mail]> (Stefan Santesson's message of "Tue, 14 Nov 2006 21:11:50 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Stefan" == Stefan Santesson <[e-mail]> writes:

    Stefan> On issue number 1) it is my belief that the lightweight
    Stefan> profile should be allowed to progress without updating RFC
    Stefan> 2560. I have seen no requirements in RFC 2560 that
    Stefan> requires a keyed responder, even if it is clear that a
    Stefan> non-keyed responder can only respond to a subset of all
    Stefan> valid requests. If the lightweight OCSP profile is allowed
    Stefan> to progress, it MUST live within the current restrictions
    Stefan> of OCSP with respect to error codes.


Speaking as an holding a discuss, I cannot agree to allow the
lightweight profile to progress without a standards-track
clarification to 2560.

Your reading of 2560 would not meet the interoperability requirements
that the IETF has established that in general, all clients of a
protocol be able to work with all servers of a protocol.  In order to
meet that requirement RFC 2560 needs to be normatively changed in
order to require that clients be able to send a request including only
one certificate.

Unless I see new arguments I have not seen so far, my discuss stands.



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 kAELBw6J046152; Tue, 14 Nov 2006 14:11:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAELBwtQ046151; Tue, 14 Nov 2006 14:11:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAELBv2v046135 for <[e-mail]>; Tue, 14 Nov 2006 14:11:57 -0700 (MST) (envelope-from [e-mail])
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.0; Tue, 14 Nov 2006 21:11:51 +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; Tue, 14 Nov 2006 21:11:51 +0000
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
CC: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>
Date: Tue, 14 Nov 2006 21:11:50 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAACWpPwACS7HEAABsOsMA==
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAELBw2v046145
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Taking on the moderator hat I would like to structure this discussion before it takes off in too many directions.

1) The primary issue at hand is if the current Lightweight profile can progress to informational without first updating rfc2560.

2) Secondary is a growing discussion if RFC 2560 needs to be updated for other reasons than accommodating the lightweight profile.


On issue number 1) it is my belief that the lightweight profile should be allowed to progress without updating RFC 2560. I have seen no requirements in RFC 2560 that requires a keyed responder, even if it is clear that a non-keyed responder can only respond to a subset of all valid requests. If the lightweight OCSP profile is allowed to progress, it MUST live within the current restrictions of OCSP with respect to error codes.

On issue number 2) I welcome a debate on a separate thread.


Stefan Santesson
Senior Program Manager
Windows Security, Standards






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 kAEKmxwW043209; Tue, 14 Nov 2006 13:48:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEKmxBJ043208; Tue, 14 Nov 2006 13:48:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kAEKmuLm043182 for <[e-mail]>; Tue, 14 Nov 2006 13:48:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 25094 invoked from network); 14 Nov 2006 20:37:27 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;14 Nov 2006 20:37:27 -0000
Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 14 Nov 2006 20:37:26 -0000
Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <RMH42PD0>; Tue, 14 Nov 2006 15:48:48 -0500
Message-ID: <[e-mail]>
From: Carl Wallace <[e-mail]>
To: Dave Engberg <[e-mail]>, Stefan Santesson <[e-mail]>, Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>, [e-mail]
Cc: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 15:48:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004B_01C70804.5E976520"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01C70804.5E976520
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've worked with a toolkit that can send multi-cert requests and have seen
problems in this area including responders that return a successful response
for one cert included in a request without addressing the others.  


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dave Engberg
> Sent: Tuesday, November 14, 2006 12:45 PM
> To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, 
> Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> 
> CoreStreet's OCSP server doesn't include a SingleResponse for 
> the issuing CA's cert in pre-signed responses.  Mostly for 
> the reasons mentioned:
> 
> Adds 90-100 bytes onto every response
> 
> Have never seen a relying party app/plug-in send a request like this
> 
> The "delegated" trust model in RFC 2560 would require 
> different signing certs for trusting entity vs. CA cert ... 
> add another 1kB onto the response
> 
> Protocol only sends CA name+key info, which isn't enough to 
> identify which CA cert the relying party is inspecting in the 
> case of CA cert renewal, cross-certification, etc.
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Tuesday, November 14, 2006 12:11 PM
> To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> Santosh,
> 
> I didn't say it was hard. I say that I doubt that there are 
> many implementations supporting this scenario even those with 
> a responder key.
> It would be interesting to hear from implementers if I'm right.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > Stefan,
> >
> > You are making more complex than it is.  The Responder can 
> include all 
> > the CA certificates that issued the certificate in question and AIA 
> > can do the rest.
> >
> > Furthermore, since most PKI are two tier hierarchy, in Enterprise 
> > environment, the CA certificate certification path is not an issue.
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf- 
> > [e-mail]] On Behalf Of Stefan Santesson
> > Sent: Monday, November 13, 2006 6:54 PM
> > To: Russ Housley; Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I'm not sure the case described is a realistic one.
> >
> > Section 2.2
> >    All definitive response messages SHALL be digitally 
> signed. The key
> >    used to sign the response MUST belong to one of the following:
> >
> >    -- the CA who issued the certificate in question
> >    -- a Trusted Responder whose public key is trusted by 
> the requester
> >    -- a CA Designated Responder (Authorized Responder) who holds a
> >       specially marked certificate issued directly by the CA, 
> > indicating
> >       that the responder may issue OCSP responses for that CA
> >
> > Since the request is on certificates issued by 2 different 
> CA:s trust 
> > option 1 is invalid.
> > Trust option 3 is valid in theory but in practice it 
> requires that the 
> > OCSP responder provide multiple validation paths in the 
> response, one 
> > for each issuing CA. Somehow I doubt that this is implemented by 
> > anyone.
> >
> > Trust option 2 is not generic and is only valid as a result 
> of a local 
> > configuration.
> >
> > So I don't think this is a problem only for key-less responders.
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:owner-ietf- 
> > > [e-mail]] On Behalf Of Russ Housley
> > > Sent: den 13 november 2006 14:08
> > > To: Price, Bill; [e-mail]
> > > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > > I prefer an error that tells the client to ask for the 
> certificate 
> > > one at a time.
> > >
> > > Russ
> > >
> > >
> > > At 02:46 PM 11/13/2006, Price, Bill wrote:
> > >
> > > >I'd suggest focusing on understanding where responses to 
> the keyed
> > and
> > > >keyless responders inherently differ. I am aware of two general
> > cases:
> > > >
> > > >1) The request asks for the status of multiple certificates that
> > have
> > > >not been included in a single presigned response. Russ's example
> > fits
> > > >into this case. The keyed responder handles, but the keyless will
> > fail
> > > >for the general case. Some responders respond with the presigned 
> > > >response that includes one of the certificates (usually 
> the first)
> > in
> > > >the request. A common situation is to ask for the status of 
> > > >certificates in a chain. Santosh points out some keyless 
> responders 
> > > >anticipate this and bundle responses accordingly.
> > > >
> > > >2) The request is "well-formed" but asks for the status of a 
> > > >certificate for which the keyless responder has not prepared a 
> > > >response.  This situation will occur if:
> > > >
> > > >     a) The request is for status of a certificate from 
> a supported
> > CA
> > > >but with a serial number for which there is no 
> pre-signed response.
> > > >Assuming presigned responses exist for all certificates 
> that would
> > be
> > > >valid based on their validity intervals, this would occur if the 
> > > >certificate had expired or was yet to be issued (I am aware the
> > > keyless
> > > >responders generally produce responses for certificates 
> likely to 
> > > >be issued before the next generation of presigned 
> responses). The 
> > > >keyed responder would give a signed "good" response. My 
> > > >understanding is
> > > that
> > > >the keyless responder under the draft lightweight OCSP responds 
> > > >with
> > > an
> > > >unsigned "unauthorized" error code.
> > > >
> > > >     b) The request is for the status of a certificate from an 
> > > >unsupported (or non-existent) CA. The keyed responder 
> would respond 
> > > >with a signed "unknown" response while under the draft, 
> the keyless 
> > > >would again respond with the unsigned "unauthorized" error  code.
> > > >
> > > >Some might argue with some grounds that these differences are
> > unusual,
> > > >unlikely, and insignificant.
> > > >
> > > >I personally consider the behavior in 2 of responding with the 
> > > >"unauthorized" error to be misleading. "Internal error" 
> sounds more 
> > > >appropriate if I were constrained to the current error codes.
> > > >"Malformed request" might be OK. However, the actual 
> situation does
> > > not
> > > >match well with any of these errors as they are 
> described in 2560.
> > > >
> > > >If 2560 is supposed to encompass keyless responders, I'd 
> recommend 
> > > >identifying the unavoidable differences and/or adding 2 TBD error
> > > codes
> > > >for the above cases (assuming they are the only differences). The
> > > first
> > > >error can be worked around by breaking the request for status of 
> > > >multiples into multiple requests for status of one cert.
> > > >
> > > >We've also seen some problems with client apps that can't handle 
> > > >presigned responses that commonly contain the status of several
> > (e.g.,
> > > >15-25) certs. The apps inquired for the status of a 
> single cert and 
> > > >apparently expected a response for a single certificate. I'd 
> > > >suggest that some "must" or "should" words address 
> clients' ability 
> > > >to
> > handle
> > > >the situation of a response covering multiple certificates.
> > > >
> > > >
> > > >
> > > >Bill Price
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > > >Sent: Monday, November 13, 2006 11:46 AM
> > > >To: Michael Myers; Dave Engberg
> > > >Cc: [e-mail]; Sam Hartman
> > > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile 
> and RFC 2560
> > > >
> > > >
> > > >Mike:
> > > >
> > > >I think it is not that simple.  I think you need to say that 
> > > >support for one certificate MUST be supported, and that 
> support for 
> > > >more
> > than
> > > >one certificate is OPTIONAL.  Then, the error is am 
> indication that 
> > > >the requestor has selected an unimplemented OPTION.
> > > >
> > > >Russ
> > > >
> > > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > > >Responders unable to produce or acquire a definitive response 
> > > > >MUST
> > > >return <a
> > > > >TBD error>.
> > > > >
> > > > >As to your other points Santosh, that is something I prefer the
> > > chairs
> > > > >consider.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > > >
> > > > > > Mike,
> > > > > >
> > > > > > What is the error case?
> > > > > >
> > > > > > . . .
> >
> 
> 

------=_NextPart_000_004B_01C70804.5E976520
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILpjCCA60w
ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5
Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP
BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx
UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV
v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44
F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg
1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw
JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD
VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw
NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT
o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME
BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA
aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A
tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh
X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z
Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L
alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA98wggLHoAMCAQICBECEWOUwDQYJKoZIhvcN
AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA2MDkyNzExNDcxN1oX
DTA5MDkyNzEyMTcxN1owRzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMSUwDgYDVQQF
EwcyRUNSVzAyMBMGA1UEAxMMQ2FybCBXYWxsYWNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAwVtX5z3+WT31t1J6qYHb6CsFBl6NLFq+cnJjpuxMAiFfMoifHSreDtDfJMUJcUMqOG1o
0JdBUI4nakhAo8nPNMkzatmF0cxyryagaWWnILjPJKz5LCzM/LNQnMhUFGoRPDMnkaJp82pAW/Me
cjUSS1w2MMFnjxjZ9t8DHvQ3FEY2nU5yKolnLrbmx07qVCT2KNEyetQKTR5iCsA7YiYPTFIsXHPr
TiqUsbIETHIWJqh8hRZt3Mf1jg4ayrGKmcOvpjphit7HCOPxtM/u9tajt705LzcAk/6YN3yXtc/c
88Sw48YtKrba1m5IwBq6MNBp0K9tSq7j0Mpm0bIkyL8bMwIDAQABo4H5MIH2MCAGA1UdEQQZMBeB
FWN3YWxsYWNlQGN5Z25hY29tLmNvbTAbBgNVHQkEFDASMBAGCSqGSIb2fQdEHTEDAgEKMEIGA1Ud
HwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMT
BENSTDEwCwYDVR0PBAQDAgUgMB8GA1UdIwQYMBaAFHqTo3DI3p2/kOS+O6DeN/DUalp5MB0GA1Ud
DgQWBBSTgaWOBxA4oFp5yDWk+ZSoowxj0zAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3
LjADAgSQMA0GCSqGSIb3DQEBBQUAA4IBAQCAPGGb5f6vwUpGtEaX0UbWzcCn0g5l72s82rsQjiBF
rXYpRO62c2rcnqrSp6EVa2Qk62h+DXmxnLzF+zjJ6roRnAW9LW28UYxPi9cpLGxmRkRe+d62K7QU
LM7G5vU64jfW641ykblwQaf/dVzcTpXg7mU7n7qO46YWAAVaTyq3gdKYZxtXInZEWvnxzH3dJjcD
7Q1KSrH/ztsbwgW/rFq29iorSjVZNG4ROB7QAG85GVy5GkDSLEjOnEU+3dVgqjEjxODyCP+owkzO
k2JKsyqaewHPnbNs4NV7OGCJx+BJsLK2Ef0MBYdt7Ebe1efxNIK8IyeuFBJPjJRLQItdBiVnMIIE
DjCCAvagAwIBAgIEQIRY+zANBgkqhkiG9w0BAQUFADAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMI
Y3lnbmFjb20wHhcNMDYwOTI4MTY0NjMxWhcNMDkwOTI4MTcxNjMxWjBHMQswCQYDVQQGEwJ1czER
MA8GA1UEChMIY3lnbmFjb20xJTAOBgNVBAUTBzJFQ1JXMDIwEwYDVQQDEwxDYXJsIFdhbGxhY2Uw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTeGLLD5qbBCFsqR9R+3UTCxdJKetGhH7z
UVgI2cfdzArj3uXkR7r2bpVS80GRVKaC/0t8EYaxW4Ls8ZfdwWutaFfzbbIB2E+TAzF+ldT01Vdv
gy3Rws+BhZWudk5blrakYfKeUffzWiYHrJGHtOTOnyucHdE6gahikPDQ8lsDEbtxt+hzymOXZKVY
VAk2u5eBj/uxtAk/PMbIUcQLqvMf01AiZs6kNvHuhaWheAxGa4+cHM5nFUpSZpC49r4BuoBA2Rw2
ES2a+OqhMIKlsdE9MM7G9YQf4jREcf4cfnT+cMd57lc8TijkKJOMoXyMtLRK+UByDtQ1FbCNHAz4
hnRxAgMBAAGjggEnMIIBIzALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwNjA5MjgxNjQ2MzFa
gQ8yMDA4MTEwMzIxMTYzMVowIAYDVR0RBBkwF4EVY3dhbGxhY2VAY3lnbmFjb20uY29tMBsGA1Ud
CQQUMBIwEAYJKoZIhvZ9B0QdMQMCAQowQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVz
MREwDwYDVQQKEwhjeWduYWNvbTENMAsGA1UEAxMEQ1JMMTAfBgNVHSMEGDAWgBR6k6NwyN6dv5Dk
vjug3jfw1GpaeTAdBgNVHQ4EFgQU/GqeRUaoI5dNtUm3CGFNyYv1k64wCQYDVR0TBAIwADAZBgkq
hkiG9n0HQQAEDDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAOOP2IoptDkJugTF+3euz
rC8N5aO392HDa3y2cf7XL9uVGJ9YT2DUMmaxZBS9hpKa9yxeU+Vcoho6p/7QhLtDhHR4LlXg1CXd
EuMTlEdL2aA0CYJjAbCQsPACCm7+MFvfdTKwrD6NEx+3eInppPTgXm3HuZEamKPQN69tZ3wr7TMe
qBBWRUrS2GfnfpGGRneI7yhA+HJ0PDOEMA31C877efxHOqnRsojU4f9+F7EPw8y6Ipovf0GFJ0ZV
a4gMaouSzNwmOHhsZfgzM8lpmUN8CkYXTdHEwDedKjzJ3mltindxDYml6tFl0A4kAv/rD68dGgbz
kPNQAkbrT9dijO2yNTGCAo0wggKJAgEBMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25h
Y29tAgRAhFj7MAkGBSsOAwIaBQCgggE6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTA2MTExNDIwNDg0NlowIwYJKoZIhvcNAQkEMRYEFMtOGIBbiVPovtRiVGhNbtph
nbTOMDcGCSsGAQQBgjcQBDEqMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRA
hFjlMDkGCyqGSIb3DQEJEAILMSqgKDAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20C
BECEWOUwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJ
KoZIhvcNAQEBBQAEggEAN+VVUDAUemRqMbtt45adMYvGOeA/IcbPsEUXdrCj8PmAOw5XgNFZtG+/
7KkB3In+iz0M2mfXnaIamuVWOuK0/DACLNQesyCyPdCfsUZ+PHeInsKIQdfQbpQxdvrRPX3POpAj
fy4i/BGl0/nitp6gF+3ifJpTTHxIWizpJ71R5CCdkfet7ZLafgb+Wq6yhDVu0ZOBQcoRyAhFqypG
Ob8zgI0DRQgCb1gnPxoG8dDM31qOw6x5jMyGO1+OzXtALEvdSdiaIys6JIXxlogB20FkiS2TPB+o
TcJ9o4ztM/PutSmX+EdH8fQS5KnxJM+5TwLZSW7dD1O/OqshwVsemwaQAAAAAAAAAA==

------=_NextPart_000_004B_01C70804.5E976520--



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 kAEJhTNK034483; Tue, 14 Nov 2006 12:43:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEJhTXd034482; Tue, 14 Nov 2006 12:43:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEJhRwm034458 for <[e-mail]>; Tue, 14 Nov 2006 12:43:28 -0700 (MST) (envelope-from [e-mail])
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 kAEJh5hF022462; Tue, 14 Nov 2006 14:43:16 -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 kAEJgBQM008107; Tue, 14 Nov 2006 14:42:11 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 14:42:50 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: Ogle Ron <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: PEM file format rfc draft request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ogle Ron wrote:
> Now with people using the AIA extension and extending the CDP extension
> to include URIs, I see more and more use of the PEM formatted CRLs and
> certificates.
Why is there need to base64 encode everything?  It made sense in PEM due 
to the limitations of email, but what is the benefit of base64 encoding 
in other situations?

As for the scenarios mentioned above, 3280bis specifically states that 
the data pointed to by an HTTP or FTP URI must in the AIA, SIA, or CDP 
extension must be BER or DER encoded (DER for certificates and CRLs; BER 
or DER for "certs-only" CMS messages).  Is there a reason that people 
are pointing to PEM formatted certificates and CRLs rather than just the 
certificates and CRLs without the base64 encoding?

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 kAEJ5vS5029258; Tue, 14 Nov 2006 12:05:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEJ5vRH029257; Tue, 14 Nov 2006 12:05:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEJ5uXw029181 for <[e-mail]>; Tue, 14 Nov 2006 12:05:57 -0700 (MST) (envelope-from [e-mail])
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 11:07:51 -0800
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008A_01C707F6.457D0940"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQABnd37AACuUgEAAASIkwAAOsjPA=
From: "Santosh Chokhani" <[e-mail]>
To: "Dave Engberg" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, "Price, Bill" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01C707F6.457D0940
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

In hurry, I did not clearly articulate my thoughts.  What I am saying also
relates to another comment to Mike Myers regarding the security of the
delegated model which is incompletely addressed by 2560.

I will be verbose this time.

The implementations such as Corestreet and Tumbleweed tend to adhere to the
approach that the same key that signed the certificate in question, sign the
OCSP Responder certificate.

Thus, if you have a hierarchy like Root --> CA --> Subscriber and you want
the status of CA certificate and the Subscriber certificate, you get them as
responses and with them you only need the two OCSP Responder certificates
one signed by the Root (for verifying CA certificate revocation status) and
one signed by the CA (for verifying the subscriber certificate revocation
status).

You do not need any paths.

Please note that the approach also works when the Responder is queried by a
CA cross certified by the root, since rest of the path has been built by the
client. 

-----Original Message-----
From: Dave Engberg [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 12:45 PM
To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, Bill;
[e-mail]
Cc: Sam Hartman; Michael Myers
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
CA's cert in pre-signed responses.  Mostly for the reasons mentioned:

Adds 90-100 bytes onto every response

Have never seen a relying party app/plug-in send a request like this

The "delegated" trust model in RFC 2560 would require different signing
certs for trusting entity vs. CA cert ... add another 1kB onto the response

Protocol only sends CA name+key info, which isn't enough to identify which
CA cert the relying party is inspecting in the case of CA cert renewal,
cross-certification, etc.


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 12:11 PM
To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [e-mail]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > -----Original Message-----
> > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>


------=_NextPart_000_008A_01C707F6.457D0940
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOODCCBEQw
ggMsoAMCAQICBEClFlYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y
aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll
czEMMAoGA1UECxMDQ0ExMB4XDTA0MDYyMjE1MDY0NVoXDTA3MDYyMjE1MzY0NVowXzELMAkGA1UE
BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95
ZWVzMRkwFwYDVQQDExBTYW50b3NoIENob2toYW5pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCtExu25dsN38n+WyugNc1a9y0A/kbFHPHuTZ76rzrRcX+bbTh5XwSQDUaZbknZmFjRbPswVXA8
a0pNRFn0Oy0TJaHXkX+AGH71RPf/4I1S8CjuxjPvhTMC6zWyZnWwE9TBNDjzba4jic1hdvg47JLb
xM320g7P5VqWWDhKEOtXrQIDAQABo4IBhzCCAYMwCwYDVR0PBAQDAgUgMCAGA1UdEQQZMBeBFWNo
b2toYW5pQG9yaW9uc2VjLmNvbTCB6wYDVR0fBIHjMIHgMHmgd6B1pHMwcTELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlv
biBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMQ0wCwYDVQQDEwRDUkwxMDKgMKAuhixodHRwOi8v
d3d3Lm9yaW9uc2VjLmNvbS9DUkwvY2ExX2NybGZpbGU0LmNybDAvoC2gK4YpZmlsZTovL1xcU2Jl
dGVsZ2V1c2VcQ1JMXGNhMV9jcmxmaWxlNC5jcmwwHwYDVR0jBBgwFoAUyLI83rqa64kJoNY0MpsZ
QobMmNIwHQYDVR0OBBYEFAmbKwqwClYqMfveZYM0xD79HkWNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9
B0EABAwwChsEVjcuMAMCBLAwDQYJKoZIhvcNAQEFBQADggEBAEQMBLlUVl1R3Xndf+qw6hTAJ0kR
AwgU3DEu5/S5k1aEh2mPqnsbsi9Ubq45APRcFLhL8HKPzpcOmsC4wawuSvKf2Cy9fq+9+csEbK8A
yDnCVBXHLHP0l6pdDloVbg0MWygzkyJsJ8PFZP9daiAMRzUcSFzOTr1tPqQ+HHQVSFxL+Mmz8oVu
9Uk6qaHNQDSpDKGNggo5uboa6FcrOoTM2CfBvdLpWusojaJqDiff1P+N5mWF6ss/FQHavO1l8m3z
rT9tP4TUA2jcJ+/Z1+mVQjxI4gCN4TT851QYLaJ4MoQhonZU9onWuP8LjKi8JLfVnh0Rh4zEM+uW
IbNgt0wgwgUwggRxMIIDWaADAgECAgRApUDYMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlVT
MSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRp
b24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMTAeFw0wNjA0MjExNzMyMTdaFw0wOTA0MjExODAy
MTdaMF8xCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxEjAQ
BgNVBAsTCUVtcGxveWVlczEZMBcGA1UEAxMQU2FudG9zaCBDaG9raGFuaTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEAlBpJGFItTtfBM6q+0Wz5CdGz/Q6ZrhSyg1ZL7XSOAkRblNY1VgFqneP7
cS+YOTlQ8t50mgzlAFpIqvYRkPk/+EVnnRwEo/2RWhst9AJ6JlLRVl5NT5yljPmtgouCnm2lVn9t
+zVHjvdLZAjqCNYNGUrEPzWSmGHOT2nWcpI9N88CAwEAAaOCAbQwggGwMAsGA1UdDwQEAwIHgDAr
BgNVHRAEJDAigA8yMDA2MDQyMTE3MzIxN1qBDzIwMDgwNTI3MjIwMjE3WjAgBgNVHREEGTAXgRVj
aG9raGFuaUBvcmlvbnNlYy5jb20wgesGA1UdHwSB4zCB4DB5oHegdaRzMHExCzAJBgNVBAYTAlVT
MSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRp
b24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDov
L3d3dy5vcmlvbnNlYy5jb20vQ1JML2NhMV9jcmxmaWxlNC5jcmwwL6AtoCuGKWZpbGU6Ly9cXFNi
ZXRlbGdldXNlXENSTFxjYTFfY3JsZmlsZTQuY3JsMB8GA1UdIwQYMBaAFMiyPN66muuJCaDWNDKb
GUKGzJjSMB0GA1UdDgQWBBTKG4Pa4RMRhdt4u4khxZ05Soe+EDAJBgNVHRMEAjAAMBkGCSqGSIb2
fQdBAAQMMAobBFY3LjADAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQCPnzbjrTdqUDXCG+DjvEeFAeC7
mSd8wDYtEuZLNQiLCrD5a2+wl3NNvhnIbHNSUgckB/neMhFJUcDtZloX6iPdlxzTc1ijbhTkIn2p
BJvNxRsENN7vpiEU+rw0CLroxOphnEY5lLYzPhIsUioVJbbUl1IZ08BCLU/zBhRQkT1gMMzUOAvu
z96/RYTOYDGilZirOQ+PHl+1jNW8JAUdSqwS2/UaiWrnBlZEn5hFKa97Xmn012io5HNlvWlh11+X
fnH6zplx+1B1i7SFBZijC5GZa4DSQQhFWYyuLoLGJ9suF4+vMkq2rqkIw5U5QPHbrXq4qNj6mO22
/Ck0x4Z0m6t6MIIFdzCCBF+gAwIBAgIEQKUTUTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJV
UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTEwHhcNMDQwNTE0MTkwMzEyWhcNMjQwNTE0MTkz
MzEyWjBiMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIw
IAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgmMvicMxt6fbcKfUpOjgN8cO181kY5bAFbZcj12Of9W5d
c7aGPqdfivgbWU3C0KkNifsunzR0dEV2mfsaeqt80wciwoNpFjGknR+CLiAT0t0zCeawQTxY42Pv
I9VG4jperjed87wtNl6Edo343BR2CH+tcNAuu7UBrFhtol+2SkYbDIwOY/C1+BXdO81/yDnSYJNw
CuKkNWba3MLi8g500JhAl+xGhCCC0vBvL2c3LHAcoceHs6URk+pUk8afVLWrMXEqNFwsfDM/i8oP
ofydjmd1WTfgItnmOrn2RymhVMMwvJKXk9ODrMG5L7VLSeeAEBb0U6pQ5MFEzLGoeSaDAgMBAAGj
ggIzMIICLzCCAYQGA1UdHwSCAXswggF3MHmgd6B1pHMwcTELMAkGA1UEBhMCVVMxITAfBgNVBAoT
GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dGllczEMMAoGA1UECxMDQ0ExMQ0wCwYDVQQDEwRDUkwxMDKgMKAuhixodHRwOi8vd3d3Lm9yaW9u
c2VjLmNvbS9DUkwvY2ExX2NybGZpbGU0LmNybDCBlKCBkaCBjoaBi2xkYXA6Ly9TQkVURUxHRVVT
RS9jbj1XaW5Db21iaW5lZDQsb3U9Q0ExLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv
PU9yaW9uJTIwU2VjdXJpdHklMjBTb2x1dGlvbnMsYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M
aXN0P0Jhc2UwL6AtoCuGKWZpbGU6Ly9cXFNiZXRlbGdldXNlXENSTFxjYTFfY3JsZmlsZTQuY3Js
MCsGA1UdEAQkMCKADzIwMDQwNTE0MTkwMzEyWoEPMjAyNDA1MTQxOTMzMTJaMAsGA1UdDwQEAwIB
BjAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAdBgNVHQ4EFgQUyLI83rqa64kJoNY0
MpsZQobMmNIwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNy4wOjQuMAMCBJAwDQYJ
KoZIhvcNAQEFBQADggEBAD0tK6tpqLDds75N2y8K6mlPh1u53f6XDot6RTML25UXMptWlVSiFR7M
0njPPsVtNXfTMU0FSuMzy3ChIlD6lsB0lGGu9r3PO0mn7NHWEOIXjFR9D9WFxbkdDwC524wB0M7I
NtzapAV5TBFh+iecmlZkg2ILJRq8VcqhMqgboqRoN+sGIou05fLqbT1CvV1DvAacvyL6IQMZUWIK
OUnUl4/S8M+D6g7BZhOtpbr2Z7kR9deGG+CEBti2TCgR/FLyEDFF8WqH7wtMh/2cvy6D0iZx9CpV
mFEGwLxbb5hPMut7GeAdSl51cm5qz9dVJbX4I6o63+BT2VY8P4YP7n0VgkgxggLSMIICzgIBATBq
MGIxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNV
BAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKVA2DAJBgUrDgMC
GgUAoIIBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMTQx
OTA3NTFaMCMGCSqGSIb3DQEJBDEWBBTPQkWMKGJlD8L5pdlvR1lq3QHRFzBnBgkqhkiG9w0BCQ8x
WjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTB5BgkrBgEEAYI3EAQxbDBqMGIxCzAJ
BgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNl
cnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUWVjB7BgsqhkiG9w0BCRAC
CzFsoGowYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEi
MCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExAgRApRZWMA0G
CSqGSIb3DQEBAQUABIGAb5/DQS431RRKQZjqOZu6k1IG5/1U3nb6QMhSCrn8SmA5hpboPKVNwjMx
AZbhF2A/iuYo2LvfcsNRVZ6XBInJNRDIRATyfAFRWvEDPVvZQlqQml4gchH3tzb9gAymEuo/y1+e
18dgwiNOv3g7XXfQIAgOU699g3ZunewzFNsYs3kAAAAAAAA=

------=_NextPart_000_008A_01C707F6.457D0940--



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 kAEIuBgK027934; Tue, 14 Nov 2006 11:56:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEIuBHS027933; Tue, 14 Nov 2006 11:56:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEIu9P3027925 for <[e-mail]>; Tue, 14 Nov 2006 11:56:10 -0700 (MST) (envelope-from [e-mail])
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 kAEIu92t004896 for <[e-mail]>; Tue, 14 Nov 2006 13:56:09 -0500
Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 07DBE1BD9A for <[e-mail]>; Tue, 14 Nov 2006 13:56:09 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAEIu8ga004880; Tue, 14 Nov 2006 13:56:08 -0500
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 13:56:07 -0500
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 13:56:07 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAACWpPwACS7HEA=
From: "Price, Bill" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>, "Dave Engberg" <[e-mail]>, "Russ Housley" <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2006 18:56:07.0909 (UTC) FILETIME=[8B197150:01C7081E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAEIuAP3027927
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Fine perhaps from the viewpoint of a standards lawyer but I wouldn't
want to defend fine to client developers, integrators, support staff,
and users. I don't know that they would think it is "fine" that:

1) a "successful" answer only has a partial answer when the responder
actually knew the status of all of the certs in a "multiple" request.
(See note below).

2) an "unauthorized error" has nothing to do with access controls and
authorizations at the responder. The error resulted because the
responder was not internally capable of producing a "successful" answer
to a "well-formed" request. Another (e.g., keyed) responder could
produce a successful response. The real problem was that the request
was probably ill-conceived because it involved non-existent or unknown
CA or an expired or unissued cert.

Although the situations for the "unauthorized error" are the result of
requests that should not normally occur, I have some first hand
experience that they can occur because of bugs in software or
misconfigurations. A fair amount of time was wasted with help-desk and
support people investigating why access to the server was
"unauthorized" before encountering someone who knew that the
"unauthorized error" was the response given when the keyless responder
didn't have an appropriate presigned response.

Note:  1) above assumes that the response contains status for some but
not all certs in a multiple request. This is the way some keyless
responders behave. Your response and the standard seem to indicate that
an error should result since the response does not contain "responses
for each of the certificates in a request". An error might be more
appropriate than a "successful" partial answer. 

Bottom line: From a client developer, integrator, support staff, and
user viewpoint, 2560 compliant behavior due to differences between
keyed and keyless responders may be unclear and misleading in some "out
of the mainstream" cases. However, these cases may occur in the real
world because client developers, integrators, support staff, and users
may not know and/or may not be able to control (e.g., because of load
balancing) the type of responder that receives their requests. Addition
of a few words and error codes might change the situation for the
better. 

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Monday, November 13, 2006 7:30 PM
To: Russ Housley; Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I've been taking a close look at this and I've come to the conclusion
that we are fine. That is, I can't find any support for that provision
of pre-produced responses handed out by a key-less responder is
violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response
for all possible legitimate requests. It only require the responder to
support the basic response format when it chooses to return a response.
As I read RFC 2560, it may fail responding to a request for any reason
as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully
handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly
supported in 2.5. And as such it is obvious that such responder can't
respond to all possible requests.


Of the error codes listed, I find that "unauthorized" is the most
appropriate one for unsupported requests as it indicates that "the
client is not authorized to make this query to this server". The
description may not be 100% perfect but it is sufficiently good and the
response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that
the OCSP responder reached an inconsistent internal state. The query
should be retried, potentially with another responder", which may cause
the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the
informational profile for lightweight OCSP.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed
and
> >keyless responders inherently differ. I am aware of two general
cases:
> >
> >1) The request asks for the status of multiple certificates that
have
> >not been included in a single presigned response. Russ's example
fits
> >into this case. The keyed responder handles, but the keyless will
fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first)
in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported
CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would
be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are
unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several
(e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to
handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [e-mail]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more
than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .




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 kAEILJxn023003; Tue, 14 Nov 2006 11:21:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEILJ38023002; Tue, 14 Nov 2006 11:21:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEILHbS022986 for <[e-mail]>; Tue, 14 Nov 2006 11:21:18 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Gk2uF-0000OJ-5S; Tue, 14 Nov 2006 13:21:11 -0500
Mime-Version: 1.0
Message-Id: <p06230909c17f899afb7d@[128.89.89.106]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 14 Nov 2006 13:21:11 -0500
To: "Ogle Ron" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: PEM file format rfc draft request
Cc: <[e-mail]>, "Dieter Bratko" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:18 PM -0500 11/13/06, Ogle Ron wrote:
>I agree that the original PEM meaning is as you state.  I have no idea
>as to how it got skewed with these new meanings for public/private keys
>and certificates.  However, it does now exist.

No debate about its existence, just whether it is an appropriate 
topic for this WG.

>As for the relevance with PKIX, the "PEM" format also describes the base
>64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
>SSL, IPsec, and other cryptographic standards that use x509 also
>recognize PEM formatted certificates/key pairs.  This is how I
>discovered the problem in the first place.

The base64 encoding we developed for PEM, while I chaired the PSRG, 
has been adopted in a wide range of contexts, in large part because 
it became a standard MIME encoding. Most of the examples you cite 
above are instances where a WG developing a security protocol 
standard has chosen to define multiple encodings for transmission of 
public keys and/or certs, etc.  I don't think these WGs generally 
have defined private key encodings, because private keys are not 
transferred over the net and thus are not critical for 
interoperability. The WG in which this might have been relevant was 
SACRED, but I believe they choose to deal with private key transfer 
using XML (with base64 as the underlying mechanism) encoding.

>If not PKIX, then where?

An individual draft can be submitted on the topic.

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 kAEIBcK3021701; Tue, 14 Nov 2006 11:11:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEIBco2021700; Tue, 14 Nov 2006 11:11:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dmzraw5.extranet.tce.com (dmzraw5.extranet.tce.com [157.254.234.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEIBaJC021684 for <[e-mail]>; Tue, 14 Nov 2006 11:11:37 -0700 (MST) (envelope-from [e-mail])
Received: from indyvss2.am.thmulti.com (unknown [157.254.92.61]) by dmzraw5.extranet.tce.com (Postfix) with ESMTP id 5AACA12FD; Tue, 14 Nov 2006 18:11:25 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id E2613109E; Tue, 14 Nov 2006 18:11:25 +0000 (GMT)
Received: from indyvss2.am.thmulti.com ([127.0.0.1]) by localhost (indyvss2.am.thmulti.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11842-01-75; Tue, 14 Nov 2006 18:11:24 +0000 (GMT)
Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id 6974110DB; Tue, 14 Nov 2006 18:11:24 +0000 (GMT)
Received: from INDYSMAILMB03.am.thmulti.com ([157.254.96.81]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 13:11:24 -0500
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: PEM file format rfc draft request
Date: Tue, 14 Nov 2006 13:11:23 -0500
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PEM file format rfc draft request
thread-index: AccIDVmWnvFvgpL9REmLm4Tk9pzgRAAB9Xxw
From: "Ogle Ron" <[e-mail]>
To: "pgut001" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2006 18:11:24.0290 (UTC) FILETIME=[4B89AE20:01C70818]
X-Virus-Scanned: amavisd-new at thomson.net
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAEIBbJC021695
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well, it did surprise me why there wasn't a standard since there were so
many implementations.  I think one of the reasons why there hasn't been
much call for it in the past is that one stayed within a single
PKI/crypto system implementation.  This issue came up for me because I'm
trying to interoperate between crypto systems (OpenSSL and Entrust).  In
this case Entrust uses the IAIK implementation.

Now with people using the AIA extension and extending the CDP extension
to include URIs, I see more and more use of the PEM formatted CRLs and
certificates.  I also see people building PKI applications out of
toolkits (like myself) who are expecting the keys and certificates to be
in the same format regardless of which crypto system created them.

Granted maybe the best advice a RFC can give is to use the proper regex,
but shouldn't it exist?  Isn't PKIX about interoperability?  I guess
that I could make the RFC informational, but I thought that it should be
given a bit more due care by interested parties.

Would the PKIX group still be interested in reviewing the informational
RFC?

Ron Ogle 

-----Original Message-----
From: pgut001 [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 11:25 AM
To: [e-mail]; Ogle Ron
Cc: [e-mail]
Subject: Re: PEM file format rfc draft request

"Ogle Ron" <[e-mail]> writes:

>The issue that I discovered was when I was working with PEM files for
PKCS1
>and PKCS8 formatted private keys under OpenSSL and some Java toolkits
using
>an IAIK implementation.  OpenSSL expects PKCS8 PEM files to have "BEGIN
>PRIVATE KEY" as the header while IAIK uses "BEGIN RSA PRIVATE KEY" for
RSA
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect
"BEGIN
>RSA PRIVATE KEY".

Uhh, given that it's probably about 10-15 years too late to try and fix
this,
is it worth even doing this?  Most implementations get around it by
reading
the lowest common denominator of all the formats they know of (for
example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular
interpretation I
can't imagine anyone's going to change code that's been in the field for
10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style
guide
some years ago), or maybe document a regexp that'll recognise all
possible
formats.

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 kAEHjwZx017305; Tue, 14 Nov 2006 10:45:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEHjwSW017304; Tue, 14 Nov 2006 10:45:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEHjuNZ017272 for <[e-mail]>; Tue, 14 Nov 2006 10:45:57 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 12:44:51 -0500
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00C9_01C707EA.AD878530"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQABnd37AACuUgEAAASIkw
From: "Dave Engberg" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, "Price, Bill" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00C9_01C707EA.AD878530
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
CA's cert in pre-signed responses.  Mostly for the reasons mentioned:

Adds 90-100 bytes onto every response

Have never seen a relying party app/plug-in send a request like this

The "delegated" trust model in RFC 2560 would require different signing
certs for trusting entity vs. CA cert ... add another 1kB onto the response

Protocol only sends CA name+key info, which isn't enough to identify which
CA cert the relying party is inspecting in the case of CA cert renewal,
cross-certification, etc.


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, November 14, 2006 12:11 PM
To: Santosh Chokhani; Russ Housley; Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [e-mail]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > -----Original Message-----
> > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>


------=_NextPart_000_00C9_01C707EA.AD878530
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1zCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA40wggL2oAMCAQICAgCfMA0GCSqG
SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV
BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNjEzMjUwNVoXDTA3
MDgxMjEzMjUwNVowZzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEWMBQG
A1UEAxMNRGF2aWQgRW5nYmVyZzEmMCQGCSqGSIb3DQEJARYXZGVuZ2JlcmdAY29yZXN0cmVldC5j
b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9g2Z9TBa7wYqlyhCoriYfugKX5mwz
j1wVuDKEZ7ZsgoC0zT2Pm43BMkWwOL8GDXYMqbAt/1YelpCYMv8stgRDLj6N3DDyCNk4ihZONITf
o7F+RxnaH782KvJ5YwrIXDKMXWb6oqThFVDM05QKgC994W6Zp555F7NFEvPA/4rqK/1Ba0k2p8A3
yZazUimG3tt7x0tz6K7Z043ezRSUBB8VwgNSr4tQyElyuACrU3IA90yYZRm1maDe6jWylqDOXU/P
A22IC/Ma1sJ42k17Nhl3i/37SLOsHSLcyJk7bKgJPSgSqI+OBzYaDX6YGdoV6O/wih9f9YrovAH8
zF2pOXcHAgMBAAGjgdgwgdUwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6
Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwIgYDVR0RBBswGYEXZGVuZ2Jl
cmdAY29yZXN0cmVldC5jb20wHwYDVR0jBBgwFoAU2Ox/kxjFZgPDEGw8BPZ3hT7/C7YwQAYIKwYB
BQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vZ2VvdHJ1c3Qtb2NzcC5jb3Jlc3RyZWV0LmNv
bS8wDQYJKoZIhvcNAQEFBQADgYEAqMfvLi9brJBbTKdWcwUJAWPHgex9/KhvW8nherc7imLZdFXH
jp0NTTtgDK+aO/EJV/97JIyStyhfIH5vrZpb+ToFXz4O0Yb78KTHFdHjzlWei/Guo+kuUXouP8ZC
Tqkr0mFlqeRGFbq7w2SJhwhXEcO1K5Y8g0jf+kXr1ejYw9ExggMdMIIDGQIBATBYMFIxCzAJBgNV
BAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2Vy
dGlmaWNhdGUgQXV0aG9yaXR5AgIAnzAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMTQxNzQ0NTFaMCMGCSqGSIb3DQEJBDEWBBTcFj3b
IX/miUA8UTtapuLxUfjASTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq
hkiG9w0CBTBnBgkrBgEEAYI3EAQxWjBYMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3Ry
ZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgIAnzBp
BgsqhkiG9w0BCRACCzFaoFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRk
LjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCfMA0GCSqGSIb3
DQEBAQUABIIBABjwegxaHpDbWrnaqVSK19HiBFs73eh97TpVD82FYbdYmPP5qBXMHDfXKUtPG/Gr
3mQ1AfyfhON0vFHLnZQ4I0LNg2mxPCDP5izREf8BliANn9ax2yhhFGxhmmcmlj2fPweobJZSS+XG
2rvUN/XawTCNphuXqIe4YHuzzxcTrlz98gxSYuQzwXBGQNpuQvQeXfHYyAN2ZT2uhEIq6k3P8GVZ
KJ3NU2fNGQHCuNOLDi7fNoiASgJChR0ySp0h0SPXYNme/ErrXJDhZkqPHVbvSlxOfX4CvDqMoStA
r/X8BEkkpLmwalpa02NrvPVnaEjpVwJPVipCbJ3W/q/Ao9rbBsAAAAAAAAA=

------=_NextPart_000_00C9_01C707EA.AD878530--



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 kAEHBKq9010451; Tue, 14 Nov 2006 10:11:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEHBKwv010450; Tue, 14 Nov 2006 10:11:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEHBIYK010431 for <[e-mail]>; Tue, 14 Nov 2006 10:11:19 -0700 (MST) (envelope-from [e-mail])
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.0; Tue, 14 Nov 2006 17: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, 14 Nov 2006 17:11:11 +0000
From: Stefan Santesson <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>
Date: Tue, 14 Nov 2006 17:11:07 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQABnd37AACuUgEA==
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAEHBJYK010445
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

I didn't say it was hard. I say that I doubt that there are many implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
> Stefan,
>
> You are making more complex than it is.  The Responder can include all
> the CA certificates that issued the certificate in question and AIA can
> do the rest.
>
> Furthermore, since most PKI are two tier hierarchy, in Enterprise
> environment, the CA certificate certification path is not an issue.
>
> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]]
> On Behalf Of Stefan Santesson
> Sent: Monday, November 13, 2006 6:54 PM
> To: Russ Housley; Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I'm not sure the case described is a realistic one.
>
> Section 2.2
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- a CA Designated Responder (Authorized Responder) who holds a
>       specially marked certificate issued directly by the CA,
> indicating
>       that the responder may issue OCSP responses for that CA
>
> Since the request is on certificates issued by 2 different CA:s trust
> option 1 is invalid.
> Trust option 3 is valid in theory but in practice it requires that the
> OCSP responder provide multiple validation paths in the response, one
> for each issuing CA. Somehow I doubt that this is implemented by
> anyone.
>
> Trust option 2 is not generic and is only valid as a result of a local
> configuration.
>
> So I don't think this is a problem only for key-less responders.
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:owner-ietf-
> > [e-mail]] On Behalf Of Russ Housley
> > Sent: den 13 november 2006 14:08
> > To: Price, Bill; [e-mail]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> > I prefer an error that tells the client to ask for the certificate
> > one at a time.
> >
> > Russ
> >
> >
> > At 02:46 PM 11/13/2006, Price, Bill wrote:
> >
> > >I'd suggest focusing on understanding where responses to the keyed
> and
> > >keyless responders inherently differ. I am aware of two general
> cases:
> > >
> > >1) The request asks for the status of multiple certificates that
> have
> > >not been included in a single presigned response. Russ's example
> fits
> > >into this case. The keyed responder handles, but the keyless will
> fail
> > >for the general case. Some responders respond with the presigned
> > >response that includes one of the certificates (usually the first)
> in
> > >the request. A common situation is to ask for the status of
> > >certificates in a chain. Santosh points out some keyless responders
> > >anticipate this and bundle responses accordingly.
> > >
> > >2) The request is "well-formed" but asks for the status of a
> > >certificate for which the keyless responder has not prepared a
> > >response.  This situation will occur if:
> > >
> > >     a) The request is for status of a certificate from a supported
> CA
> > >but with a serial number for which there is no pre-signed response.
> > >Assuming presigned responses exist for all certificates that would
> be
> > >valid based on their validity intervals, this would occur if the
> > >certificate had expired or was yet to be issued (I am aware the
> > keyless
> > >responders generally produce responses for certificates likely to be
> > >issued before the next generation of presigned responses). The keyed
> > >responder would give a signed "good" response. My understanding is
> > that
> > >the keyless responder under the draft lightweight OCSP responds with
> > an
> > >unsigned "unauthorized" error code.
> > >
> > >     b) The request is for the status of a certificate from an
> > >unsupported (or non-existent) CA. The keyed responder would respond
> > >with a signed "unknown" response while under the draft, the keyless
> > >would again respond with the unsigned "unauthorized" error  code.
> > >
> > >Some might argue with some grounds that these differences are
> unusual,
> > >unlikely, and insignificant.
> > >
> > >I personally consider the behavior in 2 of responding with the
> > >"unauthorized" error to be misleading. "Internal error" sounds more
> > >appropriate if I were constrained to the current error codes.
> > >"Malformed request" might be OK. However, the actual situation does
> > not
> > >match well with any of these errors as they are described in 2560.
> > >
> > >If 2560 is supposed to encompass keyless responders, I'd recommend
> > >identifying the unavoidable differences and/or adding 2 TBD error
> > codes
> > >for the above cases (assuming they are the only differences). The
> > first
> > >error can be worked around by breaking the request for status of
> > >multiples into multiple requests for status of one cert.
> > >
> > >We've also seen some problems with client apps that can't handle
> > >presigned responses that commonly contain the status of several
> (e.g.,
> > >15-25) certs. The apps inquired for the status of a single cert and
> > >apparently expected a response for a single certificate. I'd suggest
> > >that some "must" or "should" words address clients' ability to
> handle
> > >the situation of a response covering multiple certificates.
> > >
> > >
> > >
> > >Bill Price
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > >[mailto:[e-mail]] On Behalf Of Russ Housley
> > >Sent: Monday, November 13, 2006 11:46 AM
> > >To: Michael Myers; Dave Engberg
> > >Cc: [e-mail]; Sam Hartman
> > >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> > >
> > >
> > >Mike:
> > >
> > >I think it is not that simple.  I think you need to say that support
> > >for one certificate MUST be supported, and that support for more
> than
> > >one certificate is OPTIONAL.  Then, the error is am indication that
> > >the requestor has selected an unimplemented OPTION.
> > >
> > >Russ
> > >
> > >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > > >Responders unable to produce or acquire a definitive response MUST
> > >return <a
> > > >TBD error>.
> > > >
> > > >As to your other points Santosh, that is something I prefer the
> > chairs
> > > >consider.
> > > >
> > > > > -----Original Message-----
> > > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > > >
> > > > > Mike,
> > > > >
> > > > > What is the error case?
> > > > >
> > > > > . . .
>




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 kAEGk6aM005398; Tue, 14 Nov 2006 09:46:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEGk6kv005397; Tue, 14 Nov 2006 09:46:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEGk4vt005369 for <[e-mail]>; Tue, 14 Nov 2006 09:46:05 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 0C50838078; Wed, 15 Nov 2006 05:45:59 +1300 (NZDT)
Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05917-11; Wed, 15 Nov 2006 05:45:57 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 1440B38C61; Wed, 15 Nov 2006 05:27:45 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 5787D37742; Wed, 15 Nov 2006 05:27:45 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Gk18e-0007H3-00; Wed, 15 Nov 2006 05:27:56 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: PEM file format rfc draft request
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 15 Nov 2006 05:27:56 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ogle Ron" <[e-mail]> writes:

>If not PKIX, then where?

A web page somewhere where Google can find it.  Given that this is such a
moving target, I'm not sure that an RFC is the best way to document this even
if you could find a WG that would adopt it.

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 kAEGPFH4000659; Tue, 14 Nov 2006 09:25:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEGPFpn000656; Tue, 14 Nov 2006 09:25:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from groucho.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEGPCwF000565 for <[e-mail]>; Tue, 14 Nov 2006 09:25:13 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 46D073618D; Wed, 15 Nov 2006 05:25:06 +1300 (NZDT)
Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21460-22; Wed, 15 Nov 2006 05:25:06 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 3AD2633EAC; Wed, 15 Nov 2006 05:25:04 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7C8F037742; Wed, 15 Nov 2006 05:25:03 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Gk162-0007Cr-00; Wed, 15 Nov 2006 05:25:14 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: PEM file format rfc draft request
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 15 Nov 2006 05:25:14 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ogle Ron" <[e-mail]> writes:

>The issue that I discovered was when I was working with PEM files for PKCS1
>and PKCS8 formatted private keys under OpenSSL and some Java toolkits using
>an IAIK implementation.  OpenSSL expects PKCS8 PEM files to have "BEGIN
>PRIVATE KEY" as the header while IAIK uses "BEGIN RSA PRIVATE KEY" for RSA
>keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For PKCS1, both expect "BEGIN
>RSA PRIVATE KEY".

Uhh, given that it's probably about 10-15 years too late to try and fix this,
is it worth even doing this?  Most implementations get around it by reading
the lowest common denominator of all the formats they know of (for example my
code looks for '----' + 'BEGIN' + 'PRIVATE', which seems to handle all
possibilities).  Even if you could decide on one particular interpretation I
can't imagine anyone's going to change code that's been in the field for 10+
years.  I think the best you could do is create an kind of FYI RFC that
documents all of the possible formats (I started this in my X.509 style guide
some years ago), or maybe document a regexp that'll recognise all possible
formats.

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 kAEEb0pY076292; Tue, 14 Nov 2006 07:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEEb0rA076291; Tue, 14 Nov 2006 07:37:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAEEaw0V076284 for <[e-mail]>; Tue, 14 Nov 2006 07:36:59 -0700 (MST) (envelope-from [e-mail])
Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kAEEav503461 for <[e-mail]>; Tue, 14 Nov 2006 15:36:57 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 14 Nov 2006 15:36:57 +0100 (MET)
Message-ID: <[e-mail]>
Date: Tue, 14 Nov 2006 15:34:59 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: bug in RFC 4043
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004030308040109010406"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms030004030308040109010406
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

In RFC 4043 there seems to be a bug. 

The spec uses ATTRIBUTE instead of OTHER-NAME.  i.e. shouldn't this be:

permanentIdentifier OTHER-NAME ::= {PermanentIdentifier IDENTIFIED BY
id-on-permanentIdentifier}

and OTHER-NAME imported

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorit¨¦; 
die Liste mit zur¨¹ckgerufenen Zertifikaten finden Sie da auch. 


--------------ms030004030308040109010406
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
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTE0MTQzNDU5WjAjBgkqhkiG9w0B
CQQxFgQUa1iRdNIcWhTdgZiNMpycSo1xC34wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAHqtHPDBlB2K0vqwK
HFBTX9VmB7Vy0YGW7VbikdMbrOecV6QmOIxGDSoMAk6MLioI6gqj9dnQNP9T+6EE1hd4mOzs
AhacxhVqyWN0xLbLW4jWZixKZytOKHURd1Njux1/OkCoKEp2FI/i1sWdX+rYrn4flyUK2CcF
SfGEm4efqfMAAAAAAAA=
--------------ms030004030308040109010406--



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 kAEETD2c074512; Tue, 14 Nov 2006 07:29:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEETDvi074511; Tue, 14 Nov 2006 07:29:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailrelay1.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEETAP0074460 for <[e-mail]>; Tue, 14 Nov 2006 07:29:13 -0700 (MST) (envelope-from [e-mail])
Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) by mailrelay1.tugraz.at (8.13.8/8.13.8) with ESMTP id kAEET1bb017524; Tue, 14 Nov 2006 15:29:01 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 11E67194009; Tue, 14 Nov 2006 15:29:02 +0100 (CET)
Received: from thor.iaik.tugraz.at ([127.0.0.1]) by localhost (thor [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30085-02; Tue, 14 Nov 2006 15:29:01 +0100 (CET)
Received: from vesta (vesta.iaik.tugraz.at [129.27.152.109]) by thor.iaik.tugraz.at (Postfix) with SMTP id EB211194007; Tue, 14 Nov 2006 15:29:01 +0100 (CET)
Message-ID: <01c401c707f9$3ac61660$[e-mail]>
From: "Dieter Bratko" <[e-mail]>
To: "Ogle Ron" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: PEM file format rfc draft request
Date: Tue, 14 Nov 2006 15:29:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iaik.tugraz.at
X-Spam-Scanner: SpamAssassin 3.001007 
X-Spam-Score-relay: -2.6
X-Scanned-By: MIMEDefang 2.57 on 129.27.10.18
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> that use x509 also recognize PEM formatted certificates/key pairs.
> This is how I discovered the problem in the first place.
>
> If not PKIX, then where?

I agree with Ron that PKIX would be the right place. PEM as email
security format is not widely used. However, base64 encoded
keys/certificates/certificate requests/crls,... with PEM-style
headers/footers are an inherent part of almost any (X.509 based)
PKI environment.
When implementing en- and decoding of keys and other PKI
objects for our Java crypto toolkit, we first searched for a specification
telling us which headers and footers shall be used. Since no such
specification is available we tried to implement it in a way to be
interoperable with other appliacations. However, each application may
use its own interpretation and some applications are very restrictive and
only accept their own interpretation. The only solution is to provide
additional API methods allowing the user to explicitly set the PEM headers;
however, this only moves the decision to the user (and is not applicable
for final applications).
For that reason a standard giving some recommendations
for the usage of PEM headers would be very useful. It should not
only cover keys, but also certificates, crls, requests,... (for instance,
some applications use -----BEGIN CERTIFICATE REQUEST-----.
and some use -----BEGIN NEW CERTIFICATE REQUEST-----,
and some may use  -----BEGIN PKCS10 REQUEST---- or something
other for encoding a certificate request). We should try to find and setup
a common base from already existing PKI applications.
Since Steve Henson announced that he would help to write
the specification, we already would have the contribution of
one of the most widely used crypto libraries, OpenSSL.

Regards,
Dieter

---------
Dieter Bratko, SIC/IAIK - Graz University of Technology
IAIK, Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/
----- Original Message ----- 
From: Ogle Ron
To: Stephen Kent
Cc: [e-mail] ; Dieter Bratko
Sent: Tuesday, November 14, 2006 2:18 AM
Subject: RE: PEM file format rfc draft request


I agree that the original PEM meaning is as you state.  I have no idea
as to how it got skewed with these new meanings for public/private keys
and certificates.  However, it does now exist.

As for the relevance with PKIX, the "PEM" format also describes the base
64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
SSL, IPsec, and other cryptographic standards that use x509 also
recognize PEM formatted certificates/key pairs.  This is how I
discovered the problem in the first place.

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [e-mail]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I
think RFC 1421 defines the last of the formats (we had a few
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".


it looks like folks made this up!  PEM describes how to transfer a
symmetric key encrypted under a public (RSA) key in a message, in
1421.  It does not describe how to transfer a private key, because
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to
IETF standards. Since PKCS #8 defines a format for private keys, it
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is
not immediately clear that a document on how to use base-64 encoding
and MIME-style headers to represent private keys is within our scope.

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 kAEDo77w067981; Tue, 14 Nov 2006 06:50:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEDo7tX067980; Tue, 14 Nov 2006 06:50:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEDo6ET067967 for <[e-mail]>; Tue, 14 Nov 2006 06:50:06 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6C040E0035; Tue, 14 Nov 2006 08:49:59 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: [Wijnen, Bert (Bert)] FW: [members] FW: Proposed charter for OASIS EKMI TC
Date: Tue, 14 Nov 2006 08:49:59 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=-=-=



I'm sorry if this has already been forwarded to pkix.


--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[e-mail]>
Received: from solipsist-nation ([unix socket])
	by solipsist-nation (Cyrus v2.1.18-IPv6-Debian-2.1.18-1+sarge2) with LMTP; Mon, 13 Nov 2006 09:37:32 -0500
X-Sieve: CMU Sieve 2.2
Return-Path: <[e-mail]>
Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by suchdamage.org (Postfix) with ESMTP id CD30313194
	for <[e-mail]>; Mon, 13 Nov 2006 09:37:31 -0500 (EST)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
	by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kADEbU1p018083
	for <[e-mail]>; Mon, 13 Nov 2006 09:37:30 -0500 (EST)
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kADEbCiG005974
	for <[e-mail]>; Mon, 13 Nov 2006 09:37:13 -0500 (EST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 2643675AB4
	for <[e-mail]>; Mon, 13 Nov 2006 09:37:07 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id kADEapsb028094;
	Mon, 13 Nov 2006 08:37:02 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <R9BL5TBA>; Mon, 13 Nov 2006 15:36:51 +0100
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: "Russ Housley (E-mail)" <[e-mail]>,
	"Sam Hartman (E-mail)" <[e-mail]>
Cc: "Iesg (E-mail)" <[e-mail]>, "IAB (E-mail)" <[e-mail]>
Subject: FW: [members] FW: Proposed charter for OASIS EKMI TC 
Date: Mon, 13 Nov 2006 15:36:49 +0100
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Scanned-By: MIMEDefang 2.42
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on 
	solipsist-nation.suchdamage.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.3
MIME-Version: 1.0

FYI, just in case no one else sees these types of
announcements.

Loa, are these guys on the new-work list?
If not, maybe you should contact them to see if they
are willing to announce these things on new-work as well.

Bert


-----Original Message-----
From: Mary McRae [mailto:[e-mail]]
Sent: Friday, November 10, 2006 18:57
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: [members] FW: Proposed charter for OASIS EKMI TC 


To: OASIS Members 

   A draft TC charter has been submitted to establish an Enterprise
Key Management Infrastructure (EKMI) Technical Committee at OASIS.
We circulate such draft charters for member review and comments, in
accordance with Section 2,2 of the OASIS TC Process rules: 
   http://www.oasis-open.org/committees/process.php#2.2
The proposed charter below is open for comment. The comment period
shall remain open until 11:45 pm ET on 22 November 2006. 

   OASIS maintains a mailing list for the purpose of submitting
comments on proposed charters. Any OASIS member may post to this
list by sending e-mail to:
   [e-mail].
All messages will be publicly archived at:
   http://lists.oasis-open.org/archives/oasis-charter-discuss/  

Members who wish to receive these messages via e-mail must join the
group by selecting "join group" on the list's home page:

http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
Employees of organizational members do not require primary
representative approval to subscribe to the oasis-charter-discuss
e-mail.

   A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend shortly after
  the close of the comment period.  The time and call-in information
will be noted on the oasis-charter-discuss list and home page. 

   We encourage member comment, and ask that you note the name of
the proposed TC (EKMI) in the subject line of your email message.

   Best regards   JBC

~ James Bryce Clark
~ Director of Standards Development, OASIS 
~ http://www.oasis-open.org/who/staff.php#clark
~ [e-mail]

====
PROPOSED CHARTER 
FOR REVIEW AND COMMENT
OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE

Name

OASIS Enterprise Key Management Infrastructure (EKMI) TC

Statement of Purpose

Public Key Infrastructure (PKI) technology has been around for more 
than a decade, and many companies have adopted it to solve specific
problems in the area of public-key cryptography.  Public-key
cryptography has been embedded in some of the most popular tools --
web clients and servers, VPN clients and servers, mail user agents, 
office productivity tools and many industry-specific applications --
and underlies many mission-critical environments today.
Additionally, there are many commercial and open-source
implementations of PKI software products available in the market 
today.  However, many companies across the world have recognized
that PKI by itself, is not a solution.

There is also the perception that most standards in PKI have already
been established by ISO and the PKIX (IETF), and most companies are 
in operations-mode with their PKIs -- just using it, and adopting it
to other business uses within their organizations. Consequently,
there is not much left to architect and design in the PKI community.

Simultaneously, there is a new interest on the part of many 
companies in the management of symmetric keys used for encrypting
sensitive data in their computing infrastructure. While symmetric
keys have been traditionally managed by applications doing their own
encryption and decryption, there is no architecture or protocol that 
provides for symmetric key management services across applications,
operating systems, databases, etc. While there are many industry
standards around protocols for the life-cycle management of
asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS, etc. 
-- however, there is no standard that describes how applications may
request similar life-cycle services for symmetric keys, from a
server and how public-key cryptography may be used to provide such
services. 

Key management needs to be addressed by enterprises in its
entirety -- for both symmetric and asymmetric keys.  While each type
of technology will require specific protocols, controls and
management disciplines, there is sufficient common ground in the 
discipline justifying the approach to look at key-management as a
whole, rather than in parts.  Therefore, this TC will address the
following:

Scope

A) The TC will define the request/response protocols for: 

1. Requesting a new or existing symmetric key from a server;
2. Requesting policy information from a server related to caching of
keys on the client;
3. Sending a symmetric key to a requestor, based on a request; 
4. Sending policy information to a requestor, based on a request;
5. Other protocol pairs as deemed necessary.

B) To ensure cross-implementation interoperability, the TC will
create a test suite (as described under 'Deliverables' below) that 
will allow different implementations of this protocol to be
certified against the OASIS standard (when ratified);

C) The TC will provide guidance on how a symmetric key-management
infrastructure may be secured using asymmetric keys, using secure 
and generally accepted practices;

D) Where appropriate, and if possible in conjunction with other
standards organizations that focus on disciplines
outside the purview of OASIS, the TC will provide input on how such 
enterprise key-management infrastructures may be managed, operated
and audited;

E) The TC may conduct other activities that educate users about,
and promote, securing sensitive data with appropriate cryptography, 
and the use of proper key-management techniques and disciplines to
ensure appropriate protection of the infrastructure.

List of Deliverables

1. XSchema Definitions (XSD) of the request and response protocols 
(by April 2007)
2. A Test Suite of conformance clauses and sample transmitted keys
and content that allows for clients and servers to be tested for
conformance to the defined protocol (by September 2007)
3. Documentation that explains the communication protocol (by 
April 2007)
4. Documentation that provides guidelines for how an EKMI may be
built, operated, secured and audited (by June 2007)
5. Resources that promote enterprise-level key-management: white
papers, seminars, samples, and information for developer and public 
use. (beginning January 2007, continuing at least through 2008)

Anticipated Audiences:

Any company or organization that has a need for managing
cryptographic keys across applications, databases, operating systems 
and devices, yet desires centralized policy-driven management of all
cryptographic keys in the enterprise. Retail, health-care,
government, education, finance - every industry has a need to
protect the confidentiality of sensitive data. The TC's 
deliverables will provide an industry standard for protecting
sensitive information across these, and other, industries.
Security services vendors and integrators should be able to fulfill
their use cases with the TC's key management methodologies. 
Members of the OASIS PKI TC should be very interested in this new TC,
since the goals of this TC potentially may fulfill some of the
goals in the charter of the PKI TC.

Language:

English

IPR Policy: 

Royalty Free on Limited Terms under the OASIS IPR Policy

----
Additional Non-normative information regarding the start-up of the TC:

a. Identification of similar or applicable work:

The proposers are unaware of any similar work being carried on in 
this exact area.  However, this TC intends to leverage the
products of, and seek liaison with, a number of other existing
projects that may interoperate with or provide functionality to the
EKMI TC's planned outputs, including: 

OASIS Web Services Security TC
W3C XMLSignature and XMLEncryption protocols and working group
OASIS Digital Signature Services TC
OASIS Public Key Infrastructure TC
OASIS XACML TC (and other methods for providing granular 
access-control permissions that may be consumed or enforced by
symmetic key management)

b.  Anticipated contributions:

StrongAuth, Inc. anticipates providing a draft proposal for the EKMI
protocol, at the inception of the TC.  The current draft can be 
viewed at:

http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html
and a working implementation of this protocol is available at: 
   http://sourceforge.net/projects/strongkey for interested parties.

c. Proposed working title and acronym for specification:

Symmetric Key Services Markup Language (SKSML), subject to TC's 
approval or change.

d.  Date, time, and location of the first meeting:

First meeting will be by teleconference, with an optional face-to-
face gathering as one conference call node, at:
Date:  [December ____, 2006] 
Time:  [____ UTC]
Call in details'; to be posted to TC list
F2F Location:  San Francisco Bay Area.  StrongAuth has agreed to
host this meeting.

e. Projected meeting schedule:

Subject to TC's approval, we anticipate monthly telephone meetings 
for the first year. First version of the protocol to be voted on by
Summer 2007. StrongAuth is willing to assist by arranging for the
teleconferences; we anticipate using readily available free
teleconference services. 

f. Names, electronic mail addresses, of supporters:

Ken Adler, individual member, [e-mail]
June Leung, FundSERV, [e-mail] 
John Messing, American Bar Association, [e-mail]
Arshad Noor, individual member, [e-mail] 
Davi Ottenheimer, individual member, [e-mail]
Ann Terwilliger, Visa International, [e-mail]

g. TC Convener:

Arshad Noor, [e-mail]

END DRAFT



-- 
Mary P McRae
Manager of TC Administration, OASIS
[e-mail]
voip: 603.232.9090

Message does not appear in the archives - forwarding for inclusion


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

This email list is used solely by OASIS for official consortium communications.

Opt-out requests may be sent to [e-mail], however, all members are strongly encouraged to maintain a subscription to this list.


--=-=-=--



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 kAEBurvw050999; Tue, 14 Nov 2006 04:56:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAEBurZI050998; Tue, 14 Nov 2006 04:56:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAEBuq5T050979 for <[e-mail]>; Tue, 14 Nov 2006 04:56:53 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Tue, 14 Nov 2006 03:58:41 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQABnd37A=
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, "Price, Bill" <[e-mail]>, <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>, "Dave Engberg" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAEBur5T050993
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

You are making more complex than it is.  The Responder can include all
the CA certificates that issued the certificate in question and AIA can
do the rest.

Furthermore, since most PKI are two tier hierarchy, in Enterprise
environment, the CA certificate certification path is not an issue.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Monday, November 13, 2006 6:54 PM
To: Russ Housley; Price, Bill; [e-mail]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust
option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the
OCSP responder provide multiple validation paths in the response, one
for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local
configuration.

So I don't think this is a problem only for key-less responders.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed
and
> >keyless responders inherently differ. I am aware of two general
cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will
fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported
CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are
unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several
(e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [e-mail]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .





Received: from [138.238.45.22] ([138.238.45.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAE5eaqT098067 for <[e-mail]>; Mon, 13 Nov 2006 22:40:39 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c707af$633753b0$00000000@J0HNS0NPALACE>
From: "died" <[e-mail]>
To: [e-mail]
References: <000d01c707af$633753b0$00000000@J0HNS0NPALACE>
Subject: Re: css editores tags fotoshop
Date: 	Tue, 14 Nov 2006 00:40:26 -0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C70785.7A5EDAB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C70785.7A5EDAB0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000C_01C70785.7A5EDAB0"

------=_NextPart_001_000C_01C70785.7A5EDAB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Wednesday, November 00:40:05 AM
  Subject: css editores tags fotoshop


  Floating of serenely globe team.
  Rates among indigenous cultures could Polynesian.
  Selecting map below Computer Nursing.
  Rip is through roading worker or suffered serious injuries. Grave =
Barrows tombstone equipment operated remote or.
  Native temperate connects surrounds structures organs bodyedit =
hobbyists.
  Hotel a Human Technology Maint. Sales Science Skilled Trades Strategy. =
Hello Guestlogin de Main toolscddvd toolsfile Toolsipod.
  Custody children am Malawi judge am.
  There dark should in ashamedof neither? Multipart articles multiple =
servers.
  Hyatt or Verizon Robert Half or Wells. Moderate am wing am forces =
Labour indirect or.
  Problems Students are especially prone a poor choices stumble =
literate? Gadgets is seo is Otaku Ovidiu Predescus Pedrams of.
  Thinking or Brewer is Lion.
  Macabre gullible am desperate?
  Social historians future Geldard is Wilts of suppose is liner. =
Multipart articles multiple servers.
  Rates among indigenous cultures could Polynesian.
  Aubin am happen is impressed of dedication improve geographic =
knowledge literacy. Federline threatens release sex is tape Britney am =
Spears.
  Hexeditor visual Jdoggnet password. Traffic detailed integrated is =
movable or satellite imagery matter quickest.
  Perhaps respect Knowing likely Beneath sod lies another.
  Hexeditor visual Jdoggnet password.
  Appearance usb ports.
  Bundle a Spyremover am net.
  Speed defend a role.
  Links box itd a highly didnt cost buckets.
------=_NextPart_001_000C_01C70785.7A5EDAB0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Hourly" hspace=3D0=20
src=3D"cid:000a01c707af$6334e2b0$00000000@J0HNS0NPALACE" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</=
A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, November =
00:40:05 AM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> css editores tags =
fotoshop</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Floating of serenely globe =
team.<BR>Rates among=20
indigenous cultures could Polynesian.<BR>Selecting map below Computer=20
Nursing.<BR>Rip is through roading worker or suffered serious injuries. =
Grave=20
Barrows tombstone equipment operated remote or.<BR>Native temperate =
connects=20
surrounds structures organs bodyedit hobbyists.<BR>Hotel a Human =
Technology=20
Maint. Sales Science Skilled Trades Strategy. Hello Guestlogin de Main=20
toolscddvd toolsfile Toolsipod.<BR>Custody children am Malawi judge =
am.<BR>There=20
dark should in ashamedof neither? Multipart articles multiple =
servers.<BR>Hyatt=20
or Verizon Robert Half or Wells. Moderate am wing am forces Labour =
indirect=20
or.<BR>Problems Students are especially prone a poor choices stumble =
literate?=20
Gadgets is seo is Otaku Ovidiu Predescus Pedrams of.<BR>Thinking or =
Brewer is=20
Lion.<BR>Macabre gullible am desperate?<BR>Social historians future =
Geldard is=20
Wilts of suppose is liner. Multipart articles multiple servers.<BR>Rates =
among=20
indigenous cultures could Polynesian.<BR>Aubin am happen is impressed of =

dedication improve geographic knowledge literacy. Federline threatens =
release=20
sex is tape Britney am Spears.<BR>Hexeditor visual Jdoggnet password. =
Traffic=20
detailed integrated is movable or satellite imagery matter =
quickest.<BR>Perhaps=20
respect Knowing likely Beneath sod lies another.<BR>Hexeditor visual =
Jdoggnet=20
password.<BR>Appearance usb ports.<BR>Bundle a Spyremover am =
net.<BR>Speed=20
defend a role.<BR>Links box itd a highly didnt cost=20
buckets.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000C_01C70785.7A5EDAB0--

------=_NextPart_000_000B_01C70785.7A5EDAB0
Content-Type: image/gif;
	name="million.gif"
Content-Transfer-Encoding: base64
Content-ID: <000a01c707af$6334e2b0$00000000@J0HNS0NPALACE>

R0lGODlhcAIgAof2AA4HAHMCBweODoiOAAAHiXMFeQCHeMWzucfmzLHO+UknAGAWAIklAJQoC7Uj
Ae0pAAA2ACI/ADI6AGZACnRNAKs2AMNMBOdDBwBjACViADdTDWJeAHZmC6FqDb9ZBe1lAAeLAB1/
AEuGAFh1AIp+Ca53ALt7CNx+AACVAiSdBUiZBmumDXquDqSsALWWCO2iCgTCAyq/CDS7AFSxAIPN
C5fCDsrHANi7AA3ZCBrRAEHUAFvhB3fkC6HYALfTB+XbAAkIRxMASjIDP10MQH4GSKMJM7kAQNwA
NgMXThkjSUITR2cYPYMWRJ0TS8cXM9gfRApJSh1GSD84NFw+QnI3TpFITc49Q9I5SAhXSiFXSEtp
RFlRS4hYAKdZPbJjNelUTgB7PSiDS0aKMlhzNXqOO5Z4Mr50PuWDPQCfQyaZQkScO2OqPI2gOqOr
MsOeMeKYNQO+Qiu0PUaxTFK2R43AN5W8Nr65Q93NTgLrMh3YOjPhRWHnToveTJXkSrnbS+DjQAAA
dCMAfjQHc1wAhnEMfqIAeLMAgNUAeAIqgyQuhEYUhG4mh38Ti6MjfrQig9QtiQI0fhtDfzhHgVg5
gnxLfpE1jMgydthKdA5VgC5ghTpYcWBmjntrdqxng8djfNlphAuEiBV6fjmGemt0fX5+e5l/g76I
g9yGiwqmhiqiikyojF2RiHqjjqmbe7SVeNWshAW7dBi0fTnGjmG5coXFi6a0esHJf9q5hADecRHS
hDHgeVzsdHPRhpvnfsrlg+rRjQAAuhcGwDUAuVsDvnMHxJ4Ltc4Aw+cBwwARtighvEIiwl0Tt4Mn
tK0owLMjy9otvABKuB09wUo5x1I5sYk/sqxAwb4ywtM5ugBmyxlVtzNjuV9ezoxTuKtexMNmzdZq
xwuEyBWCszx7tmqJyod6u6t0yLVzuduOsQSXyyymxUGZvWGbtHypw6WbuLKbyuCSugy4xxS6zUrO
tluztnOzyJHHy/b/7qqrsH99jv4FBgT8APT/AwIA9/QA/wT/9f/3/yH5BAAdAJUALAAAAABwAiAC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK7PivpMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUpV58irWLNq3cq1q1eDGL6K
HUu27NWqaNOqXcu2rdu3cOPaNEu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHYuVKnky5
suWgSS5r3rwSsufPoEOLHk26tOnTqFOrXs26tevXsGNj5Ey7tu3buClzyM27t+/fwIMLH/5TtvHj
yJMrX868ufPnyokHlyS9uvXr2GdC3869u/fv4MOL/x9Pvrz58+jTq1/Pvj3z7DX5wJ9Pv779+/jz
69/Pv7///wAGiFsw9Lln4IEIxibgggw26OBtCUYo4YQUVmjhhchNE9mDHHbo4YdTYSjiiO0JQOKJ
KKaYHIgstujiizupKOOMNFoE44045phjjTz26KNBOgYp5JAMpgcAAD8mqeRFNwJAXxwzOUBkkATo
aN6RS2apZUQuOjnll2CGWZ2XYpZppkxYnKnWkWq26eabOf0yFJlw1mnnnUexieeefMLlHZJbBqoi
oMmdYc+RiCaKqKCMNjrQoh/1KemkQiZK6aWYSopoppx2CuemnoYqaph6OuXoqSOpgupDaazq6quv
jv8q66xTwpoVE7bmqqteNezq66/ABivssMQWa+yxyO76QrLMDhucIbRGK+201FZLabPYZqvtttx2
6+234IYr7rgGtULuueh2N0+67Dpk7bvw/tfuvOJOOkW8+LJI777e5uvvvwAHLHC1/BYMTMEIJ4xq
mEUM7PDDtRXRMMQUVyyZxBZnrPFaGG/s8cdPdQwySnSObPJOIp+scm8nSqzwy1rhmfLKNNds883D
wazzzjz3TCHOQAedks9Exyr00TchkZ86SDft9NNQR/1W0VSfKvXVWGetNadVi5RL12CHLfbYZO+7
9dlop53dNmozVfbbM3IqTttVeUD33XjnvSAVVOj/7TemfPf997/kBg73rjbzPbiQ97D1reGHA2ty
4ItbvC0VkRtb+eZ9MnoIwsREzvnopJdu+lFytpT56hf6d0G8jpwu++yL6wUP67h/RvvuvGvWRu+W
k3VK7sSf2utDhH6WfPHF9ldyb88D/2UDfEafm/XSZw9UqdBr771R2NcW/vfTOre8Y+czr/767Lfv
/o+AvJ8cAfJntNMa5OffmxAq1e//dvoLoAAHiLT/GbA5BEygAhfIwAY6kCYHjKAEJxiuBypwfP+I
ggU36CkKevCDIOwRPkKILWuQ8IQoZNQJUsjCFvLsAl/h4IsURcMaYlCGOMzhP1zIw8Xo8Ie06aEQ
/4dIkVUQsTtATKISlzikIzrxiVAUDxOnSEXKhKKKVImiFrfIReRg8YtgDCN+ukjGDYnxjLK7IhrX
yMY2utFkZYwjV9YIjjcSRY54xIqZOmHHPvrxj4D8Wx4HGRK/5SKQ1rmINwjJyIIg8pGQjGRPGklJ
++HmhpIMpKVkNYRM7glUubEDVLjnSf2MJlEGwdWfsFTJ51iHlCACZSk3+IqkyHKWaIndUV4GqVYq
aGu3xCUkMSlM2vCjmEmEhE98yUwuIRMlKnimNKdJzbT4oprYtFkzt9mQbHrzm+AMpzjHCTVuKucA
9CInG83JznbGcQ/wjCc83TlIedqTJOrMpz6lR/9PLaUPQ/uMCzG6F9DemQMpxCzoBhOq0AcytKEO
fChEJ0rRit6kn8TrhGAsytGOelQlovioSEdK0olitJ1+BILK0ACjk7KzpDCNqUxnStOa2lRoc7up
Tt3EAuwUYig72KlQN+dScw7VJvE4alMwodSm6sgWTlUTDqJK1bYV9apYxWNVvXeaOWS1YFvVGD3k
8tUW9qGsaE0rN8OaPbV2JBMkZKtc50ocCNB1pIfE1CDuuky3ButrSOTr7MSiCL+u5gqGTWx6BAuc
sYqKXYBVbGgYS1mdZmNHko1jZU2XWc1ulnTJMkVnR0vauyDBHtnjxVZLy8XPgpa1WqRYTl1L2y//
wrazl7jt22rL2976Vpq6Da5wh0tcLbHlXr9NrnKXO9jiCpG5Fb0F6ZjwL2lAdypMoG6+rHtdqWjX
JFCqFne7uxRlwocQ+HLuczFlDPKmZZPuPRsNUaLeFLKyvvjNbwXjqzFGBEW/AA6wgAecVtES2Cz8
TfCb+FetIGD2wKlZB6xoEwsF4wnCGM5wJU1QtmXUj0gmGBVLw3kgDmu4PV8KsYWxZgIVy4oZ1ZSQ
ibfEjK+WycWhgvGK04JjT+kYuBSa8ZJqjFU19ThTP97x05KsZKcxWZg7EwFoiHxiibShytxqspa3
zOUuKzEQHcSyAb1M5jLD5xlmTjMD26HmAYo5/7j0eLOc50zn1KijznjOc5XbzOcd65l9fYaJCyrG
rQb8+dCVDLSiF73BvDL60ZCO9IMSIFdEM0/SH7O0pjftnbapkbmcDrWol5OxVrBktm3uljjEMeo5
jgzVkkEHpm8E61k7bNWQxharW30Y+jFq17yOYYuyYOvNZKsWwfZKGKOpz2Q7+9mjKba0BQvtnkEg
IdNmUDGW+AI1V/vb4FbM5tjsWn4dIdwPyba6181uEKH73fCOt7w3Iox5M1JV9gZSuwWW7377O2b7
Dti/Xxbwggun1hv03y0GnrCFM/w1XBCPw3uUj3TlT7oGzxfGM46vjQv1fxN/OL1CLvJ2kbzknf+N
B7s04RGOEwcZ2UG52VxOc2H+ruY4p6zMd85zbOf85xXtudBP5YPiAf3oeNOggIbO9J0jXaYO/iiz
pZMaS/y7sE0fF9azHi5FbL082YMl6RTR0l9RQzG9zNzXpUg+sVeO7C0yYNptVYG/rP07bAkqziR6
Nq+7m+ujuftHiuGZpxu+2YBP/L74cSzbHPPwkI+8mRVP+cqTiBYVEfx35LBNyT/W8qAn7hJCT/rS
m15Ya+im51dPzdM3pheuj/2rVih7Ob6h9vMGoz7w1Qiu4f73wA++8PMoKkuwvj6fPr7jho8VPQA0
jPBQvvRzwnzjjKHwFFV6ElEjhep7//vbWQD/+MdP/vIPfPqXMj+5WKD+CS3I7eg3ynbu2/5G/TNh
VmfkEGJD//oL6v7+F4DsEn8EGHDOUIAvQSPXJ4AMgYB8woAQmFgOOIEUWIEW2CAPNwVgdYFRAQgc
+IE0E0wE83uo5CvSpiggOCXwlYJEAn8s+ILhBC0mwQowWINiBApFQiFRgFY7pCQ2GCZNx3L18oNE
uE9RV4RkFYFKuIRMWBFISCRN6IM3wwBPWIVqEYVYmIVaKBBW2IWyondeWE5bOIZkKIBhiCNi8wBq
WIYiooZuyIYX4oYP8G5ZI4cP4F4Js4Zw+G6w4CNn+IfXRYWn41+AWIhpNgZooT4G8Gf9AVWGGfiI
YLKHkkh8kPghk3iJmCgebBBHBXARAQEAIfkEACIAlQAsAAAAAHACNwAHCP8A7QkcSLCgwYMIEypc
yLChw4cQI0qcSLGixYsYM2rcyLGjx4vNQn4cSbKkyZMoU6pcybKly5cwY8qcSbOmTZpdburcybOn
z59ANf4bSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gp44KS7bs0qBo06pdy7at27dw
48qdS7eu3bt48+rdy7ev37+AAws2+Wuw4cOIX5pdzLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4se
TXSEUr3wEqtezbp1XdKwY8ueTbu27duO7cVxzbu379/AgwsfTrwlgOPIkytHXry58+fQgVuKbhK3
9evYs2vfzr279+/gI4P/MSoqvPnzk6mrX8++vfv38OPLp4u+vv37+PPrTzq/v3+f5/z31n4EFmjg
gQgmqOCCDDbo4IMQRijhhBTGJlGFCAqo4YYkYXgge8NktAqHJDbkoYElpqjihScSuOKLMCaUz4xE
zZhPjTTaqKON//CI44077rhUkDf2SGSOR9JopI5JJTmUkEz+aJSPPxb5pJJXRrkkklguWRSRXyoZ
I1uLjNnTVFSmyaVSPrbZZVNqAvkmUlRmaedRdU6ppJB3ShlmnH4CuqWVgnrZZ4uIJsrZhW4W2Sib
e0ZqJZxvrslUnZhO6iedkmKZ6aeeShpmoFo+OuqdZqb6opdQigppqXM2/xnrobJOmmetr2Zpqq62
8snjrX/y6qiluf6j6rHqUfWrnIYC+2evmhbLabR4dumsntTeueyhSAYr6rXNdsvqrJsqau656UU0
rpHhHvnss0FO+yqYwcI7pLvargnovvqS2+64cmbrJ7IEa8jroOVOC+1TcRIrrb3y4hquoQCTWnGx
bl6MMKoFpwrEc1W1WmitCzuV57ICJ4xtxBE32rCg8YJrasyVhpoyujjn3BWLItt8L6w3J4wypSkD
e+2uvvpMscg/98l0vYZ2LLV8ulapstW7Eu2tv9yWvLLELzvt6saZkkpolJ/yN/Xa7W2aNthjm+wz
uF0Pm+3RcaOtad4ui/9t97t+D8z24KxZNXKSAW+NL8kuxwu1sA/bCyrFdk5epc0OazmotVzr7Pnn
oIcu+uhVXUH66ahLiAJ65KQOFYuuW0f47CDHLntz7dA+uO289x56YL4HL7y5wA9v/PETFi8VP/wg
7/zz3gHPPPNDTW/99NU3nz32SF2PPfVFUe89UeB3b33446MPfvnka78990rB3778R12fff3u/2P/
/PJ7f35S+/Nf89h3P6MIUH/7Ux8B+Qe/BYovfwU0YPrUZz7usW+B28Of9v7nQAi+T4L982D5EgjA
/73PhBpcnwjzF0IUHvCE7RvKgKiCwQ5GsIYevOEG3afCCs4vgghkIQ//CahCIS6FfiPMIQJjaMMg
/nCJQIwhU5IIRQni74pYrGIVcYi+KELxgkoEIwjHeD8qlhCMZtSiF4HYwCJacYthTOIOn0LFJmZQ
inAsoRQxaB4uWpGPb8xiD5mYQyLOsYt4dOEh6TjAITrFj4g0pA7NN8VCWjKLeERkHpsiRjVuEpCd
LKMRsQjIIAoxjXYMpBqLaMRSarKArlyjHR+YSEdi8pVcIUBjWATJW+pRj2lcYioJKUhH1lGJ8Wtk
JpNJyT9eMpjL9KUnPTnMSa4Rk4PUZDax2UpbXtGVtBSmN6tpTWfmMZbTDGclm6lNZZazl4ic4VTg
qcozkjCEXSSnOmtJzUxRLs+d16ynKcfHRWgGNJoHrGZCvTlNEJowlShMIRIByseIUrKHqFzhL9Op
TDPGsqD+2ygDE6jOjKaPnrLh5SWPSD9cktGa+gQoP2E5RzmCUqamrKRB99nPiiJTgdGkpkZJucKb
RnKoQX2lGA36wXXmdJNC3ShIaco/Zn7zpw5FqDFtGcoUxhMwssRqUkvZwjZKk6dQPWZU2YlSol71
ohZN6i/pGdOWujSKaJUkS9/o0Tg2dI8WHCdSAzlVfwo0rH+1ahP7OlFO2vItAQEAIfkEACIAlQAs
AAA2AHACNwAHCP8A7QkcSLDgwH//+PFDyBChwoYQIT6MmHAhRYcTMSrMmJFhR48LP1YESRLjSJEi
TaqUaPFiSZQhWzZ8uDHlSpczLaaEGXFnTZw2P9KUeXMkUKITOeokStLmy40rlfZkGpXq0KZMg1qN
ifNi0qxLn0LN2dWoUYNo06pdy7ZtwbJet8ItShdrSZZTKV7FWzXnXrJ6a2qF+9du3q9x5xrmC7gx
YKdmHZ8EyzjxY8FhA9e9K7Vv5cY+I//MSxovZJeFVWLO3PG0aosAFMueTfuf27eR75YNrfl178+I
HXfWmFk3aKq5E/PMHTy586POl0v2/FtyaubIjTcffhw18uHSKwv/LV6Rd2nftK9vL87de8Tb8OPL
N1g7evb2xjmTz18eJPmx1GkkIH/jmTUYepe1NFZrlEGH4HTh6baeZQFGeF5zrynIFX/PgdfghUrt
BxV+/pX4HGMYmlQgg3V5WN+LMFI0X3kfBgbgVJhhZ59gfjHIY490+XijdUsNyRKA4f1YVIFdKbla
TDyuRuNPTCqJ42j+GXkicUgiJdOPTH4mVpFU5kjjkSzyZWVcN7rGZX6pxQklmFieNd+deK4V4558
9unnn4AGKuighBZq6KGIJqrooozKNmOjkEYq6aSUVmrppZhmWl+enHaKp6aghirqqKSWauqpfHqq
6p2oturqq7DG/wqqHLLWauutuOaq66689uorQ4/+KuywxHa16rHIJqvsssw266w9xUYr7bTUVmst
jPN98EFD2nK7LUPafotQuOSG6625/3QLkboRkTtuue62C6+58FKE7rvlnpuvS/u+K6+983bLLrjb
BkwwuvMCLG66C/v777oL98swxF0N7C2+CVs88cbPduzxxyCHLDJusrEb78b4XqTxvQI3jPLDFM9l
scku3/sywi6rTPO3Nr8McMwXa+zwxAP3bHTEOTPcsLosM7100gQrDPPQUft87dXUzui000HnvLLX
NUMttNA6Az1zweKeTTVOaiuNdMVP/zs22EATHbfVB7/tM81V6//89dd1O6zuyIQXbvjhiHO6cbxF
o/3zxY9DHrnkZbW9t+Nr2w3X3JpnHjjgnE89dMsxk9356ZDzDTfFgFMu+LeJxy777LTnWdvWPL8d
et8QG1y26GzffTnKoCcMvOaq8yt81L63LjnpvUN9OvSlpy091Vx/HnDuxLqB9fd7Qk896rzjbbXp
u1d+d/Hlk/8769ybXz77flsP8/jtV+/v7vi/n/z8YfMcr9zgPfB971GMs9n/1kY25x3PdKKT2Oji
17XN0Y1vEBwe/NSXueyd73oYxJzZRBi8vJ2MgQHkWO2SRcAVuvCFtrsdzhonQQ0CD310k9n6nrYv
+q1ObkjLoOX/mHe9/aXQeK6bmrv4R0LlvQ+AD8vgAAtowD3F5lQInKHePvjAFE4uf08k3hY9+Dod
6i9vP2xf/35muQXKD3s4014RBehALkIEhnjcBR6fBYA9CqQ+ClzgEFNmxON5TopQrJraaChAeVmP
goR0Yt3I2DcyxtF1QuRhJI82R/PVsXWIrKIoYxWsxmFyefqCJB179kbtbbBrEvNd/bYIxvzVC2MJ
bFosUZlJJZ7wYOr7pR3VGD8/GvOYyFTVKJfJzGa6KhTOjKY0p0nNalrzmtjMpja3yc07JvOb4Ayn
OMdJznKa85zoTKc618lO2gGinWy5wMeqyIRu2vOe+MwnoN6h0M9++vOfAJ3LO/gZ0IIa9KD3HChC
F8rQhjpToQ6NqKTeINFhwfM2A72oRjfK0Y569KMgDalIR0rSkhLODCZNqUpXytKWEo4VLo2pTGdK
05ra9KY4zalOd8rTnvr0p0C9TUWHStSi6iqoSE2qTOGh1KY69alQjeoLjUrVqkqKF1Yti1S3ytWu
evWrYA2rWNmZ1bKa9ayNGqta18pWsqL1rXCNa6hyIde62vWueM1rQ1Wh17769a9WbatgB0vYwhr2
sIhNrGIXy1i2AvaxkJVoQAAAIfkEACIAlQAsAABsAHACNwAHCP8A/wkcSLCgwYMIEypcyLChw4cQ
I0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY160R7OmzZs4c+rcybOnz59Agwod
SrSo0aNIkypdyrSp06dQo0qdSvWpzKtYs2rdyrWr169gw4odS7as2bNo03olqvZfz7Zw48pdWLWu
3bt48wpt+3au379w9QoeTLgwU748ASv+J0DAw8aLTUIeaLiy5cuY7QkEwJkz2Z6TGTsWCLmx6cmn
UacOPXC1Y9ahU5NeLdogbdGxT7eWfdA17t24efceHZx47eMZhbsmLrxgbuC+Yb++TfD2c+SZs2uv
TMPuP8+bAYz/Bc28PHLg6GcnZI3+em3258+rTj9fvW3js82nR+j+OnyK7tlHH34CPvdfff9VZ159
9m3n4IMQFgWeQZ1NWKF4nYVX4UAXapjhd+KByGGIBZGX32ilEZiggPfxZ9p+MMaXIIPqBRijbvIR
6ByK+KW4XHkvFteigkTG2B6P880YZHxDvjfdjgJFKOWUhkk0IUEWhpjhlhiCd2V4IGrZJZhkQqRa
kirqaCSLCtrIpoxq0uikkfDhKJ1CNiKIJnRKQrnfinruOZybfjp5oJqRJdrWl2V6KSaYWVI4Jpkb
YuTjk8WdueSbuzV3532y1akcj1BSt2OoT37qIox68unqqkWy/7hiqS9quql0zZ14JqyK9roVUYyK
SOmjIkYaJpcjetjQW3YGOausiCpJqKgLtUpkiuuleWKsw7FKKnKX1hptj8apWq2z6LpIKLfbtkjl
u/B6F1GwxjoKKYmeRVrvhxc1K2e3azLZrsDU4vkte9gKzKSm7BaK8MELassrtA2ri+S3oOqXbYsF
++qxWvriS6y9IWso7MlfBsuQvxj/We64APeHKbufylygjh3fimiOA94M7swAw+mwxixzaq2fBT/8
8dIxsXWsyPzaW2yHHuYrcrJYkkhQX6r6lmmhGYsbK2/RkW12bkuaq2vCvwUM7aZC2mf2uXAvjCPF
A6J6rXUt+//cYLyAB15YRypDVHiJiTFt1rOKSzaa4JBHLu9GhzdU+daJN04W45qHFFpQO0gu+ug+
Ea71RJdTlnnnYnHOOkeskS777EVp1RdJtOeu++7vcsI7Zq8HLzzTIAxv/PHIJ698WlgsT1A1zpv+
UOrRV2/99RxB7/yFpxvefULUI6T1+E9jWFCXlWKv/vqJaq8QDo1fGf7534tfv0Pkc/jdQfhuppgl
7AugAP9RDfcZj14j29CHuDeiqF3NcPrrX/3M578BWhB7SliMARUDrO9JjUtjWuCkhGWs2+3PfxIU
3wlXqLrfufCFMIxhTarhQtRR7VhYI9nV9nURLZ1QTOljIQP/L0jEq4CiiAzZoF+cljVlDeteyeKh
QUy4vxSyEEsr7J4Mt8jFKcGiiz2hIRhzIiknkvBRJXviFFdXxQhWkEJZXOMY50jHOtpxO/J7oBqt
FsUHlpCNFGzjFd/oQ8Td8ZCITKQikdIPnJSviTlE4w0n+UAqXhFqWzrfIxfJyU56ko7SQ6IoR0nK
5DGRf/cLiSVB8slWuvKVdlTI/DSyyo/A8pa4zOXuTmJCNjpPl8AMJhhLScxiGvOYyEymMpf5sVOO
pJc7EcghDqGSaXLFmi0Upja3qTsr3bCMMMFmQcSJEHIOxJzjpCY5rTnNdlLzIO585z/iSZB2nlOe
85QnOpnJ/89+YgQoDKiJsTwCTZ3k053StGc5FVrPfSb0offMZ0TTGVFxYpOd6sSnRCfKzY56FIwh
E2HVRoq1guYEoQZx6ETvqdKL4hOjK13oRjcKU3Ou850fzalO4eXNPo5vhI3SI0ZQSlGF3HSmRUUq
TCGakKXSNKPotKlG/UnVqjqkg5VKGVBR9j2TOpKhDV2IRd/p0LGGNZ5TLapZE2pPhkrVLTuNq1xF
xyitnqxqwfLqTdiqUZUyFa1pXetD/crSlUa1rWTtKzXnytjGDm5e3bOrXU3iVKTCM7BpnelRCWtZ
wQ42o03NrFVHS1qK1PV0fIQkVztS2aOGNaWZda1LxTpVz29KdKlvLa1ud9tBcEZShPwSll5tglaW
KnSsRGUqbBtqW9jS86C5PWhMsenY6lp3O7xcXeI4yxHuvoS61w2veAmT3Whm05GWJYl3WSLO8br3
vc4c5XpTMt/d2ve++M2vfvfL3/76978ADrCAB8yQgAAAIfkEACIAlQAsAACiAHACNwAHCP8A/wkc
SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4rsaK+kyZMoTU4EAGCky5QoDbZUCLOm
zZs4c+rcybOnz59AgwodSrSo0aNIkypdyjQpQZYNoVJkSZUqSKkGccpEOLOp169gw4odS7as2bNo
wVa0yhDr2pkh3U6t+hSuy7t48+rdy7ev37+AA8tke7CqVMMCD9stKBfxP8eGZ0Km+3hx28dbLQve
zLmz58+gQ/cNk/Fn5dOF4co9rTjh6oFQCWONrVqyXalaYWN+mlhg2t/Ab3oLTry48ePIk8NsXdnq
bMuKX8PWnLil2+eoUUvPPZ1373/Kw4v/H0++vPnzRiVG1oy9OVvKXBdHzp6d9uSM7x2L3s+/v///
AAaIkGndpdZde/AZWCBrt9VG34IFcafbbhOSxwB6GJ7VRIYcdoihRdJFp117rjVYnXUmNlefbXWt
9N2EAsYo44w01mgjRARWVyJl8+moUGOIAcljgvn5dlNdhFXo4ZJMNunkkx5yJh1HU1J545VYZqnl
lqHlSCV1HVVJ05GMLQTlmWimqeaaTW0mJogJcinnnHTWaSdoXvolIYBs9unnn4CmeeeghBZq6EMn
HKrooow26uijkGqZZ197/hfopZgqFU+mnJLV448OWrSnfmBeFKeZnaaq6qqsokVifBxJ/yjfi2HC
yFCruOaq665AkTiZcyjC9yluZNI6HbAnSqZisrN+dxuFLfEq7bTU6vpqgdgV6WtXxVJYZn28zeZt
s7s9qxp4rdLjFTrVtusuWerpxxiLOmYb6luy0WpuuN4de5h31kUq8MAEF7wQbfMOeaCD15rqbL+Y
7WvruBRHbPDFkPqBcZ0/MbeijwwuDOFAlQKsL7+6PQtxwBOy/C6a6bwsM7UI2kZvyPXaXKCs3ypr
K8u93XvyvXDN/C4yRhsVSNJhXWezbAjXLCy3NiXstHzvARyb1bUBXTTTYDNJTtid5vVayXGtRTLZ
bLft9k77vQlYqT9ubPfdeOcdX5Kdnab6EN16Bz6SFoLn/fbhiCeuuHGZLO7445CnWvjklFdu+eWY
Z6755ndG7vnnoL/L+ea7jF55LaZHFPrqrLfu+uuwxy57UanXbvvtuOeu++689+7778AHL/zwxBdv
PJfQHK/88sw37/zzjM4u/fTUKwf99dhn71D13Hfv/fes/gH++OSXb/75kWuv/vrqo+/++/DHL//8
rbNv//3456///pvT7///oQsIACH5BAAiAJUALAAA2ABwAjcABwj/AO0JHEiwoMGDCBMqXMiwocOH
ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIP6
BCC0qNGjRVshXcqUKdGmUKMG/Ue1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXdsVANu3cOPKnUu3
rt2xEZtI3cu3b8KnfgMLHky4sGGUgA8rXjzxruPHkCNLnkxZrtvKmDNr3sy5q8TOoEOLZtwxcVAU
pFPHFM26dWXVG03P3AG79k3XuHPbtY1RNu/fwO3xszq86nB+yJP/K258eXLkV58zl348unTi1pU7
f071evbp3Lt7/++Ovbly6M3FoyfOfPn28+XJv29fNXhF3/bzM27P3z3W6fJp1Z9/8QX4X4Hu0Ueg
gQQWN6CC6QUIoHPlDWhcfwpamGB0WOnn4YepkQXgiAI2yNWDByJoXoQqQhifgxWWOCGKJJ5oYoYr
kufigrr16OOPQAYZmUQ1bphVdQxymB6OKurI4pM8pugfikfeqCSSRm6FJZYRbhlleiCGKeZgZcEI
43waUvcdeNzRp6aJ6qH35ngXajfenEsyeSaXVU6JpnxIsrmekIQWauihiMLl5ZkHTljigkxCCWej
XrmJHaNfzsgjo9WxqeSGEC76aKKklmrqqYaK+mWWO04aaZLzyf9Y6aesSuodppxmySCJoVrZJ6rA
BivssGl9pmqvgNq4pJRJWuoss5teGiOttSZ7oYGWXttrjdn6N+a34EJlVrdqOktntOW2eV22t7ar
HXt2cliuvJdCx5+g3VL4ZrR1DtoqsQAHXOhlAhds8MEIJ6xwXZSUSiR1EEcs8cQUV2zxxRhnrPHG
HHdMXbgghzzVwiSXbPLJKKes8sost+zyyzDHLPPMNNds880456xzj5/BDADBOwfNmchEH3TXz1Uh
TZXSYTFt1c9QO22W1E8DLVbUUHNF9VpbnxV1XF0HibXSYatVdlZFpz3QP123bXVWTMf9dltzn02W
3WXhvfTcrun/fTXfYgM+mtpp71331llvRXbiiyfONuNfV43V4oY3LnflSV+GdeVvUz02549DnvXn
oVNeeuaORz655puD7pXqpJNeOuuZz05w662fvjrcbsmOe+6/24561oQXjjrvh/Nt+d6P12464snT
LjnzzT/f++3XK9+59dRXLzftjnvP/OWmX9X4+IIjjz34lJOPfejom/9++bXvDrn97W8Pv/jMF1/0
6slDHu9OVz6keS56opNe/ZrHP8m5T3GfuxwDH7hAA1rNgvJzXvoKeL2/UY+CDcRg/EZYwQ5CMHgS
dOD89AdCpPmPaFULIABPyDrLJXCB09td9zhnvRaacIAZ/GAN/7/mNBAK0YbLA6IRXyc9HzIwhD8U
4fBuqMMMSjCCK8SfBmv3Qt4QIiKGE+AMtUbFstEPh8Pb4RNzKMQnSrGKJWxjELv3xjU2EIhBXCLd
IufEPmaRjXBUIwmlSMgfbnGQbgGZN0CUN+1pBW98vN8IzyhI3UntiibM3yHxGMcJ/pGOhuRfIT2p
xE+icYej9GMYl0jBAw6wlalk4R/DJzSX9exoQCsi7MJHy7FlcojArN8uXRc2X7pxfbNDZfCmt8vU
0RJzmJTkHKF4TNcJL5o2TGMgEcnDaiaTmsLrom1qaSq/kRNY5jznwW6pzs6ks52kcqE4YQPPQ72z
nkLKHT73yeHPfvrznwANqEAHStChgTFg80yoQhfakII69KEQZdm9BvWeJx1nX9iqV5vkda6IevSj
+7SQo/xUIBelKVPLAqlKV4pPL1lLWiUdlaooBatVsfSmOB1Wz1xKUpiyyKQ50pVPgfoPhhr1qAwt
U57iRa+YPipQcfIXvN6V06padWWaCqpWIaUlXwF1pFcNq1hNdiufblVDTTXSVyU11ra69VDy6Mqz
Uiohi3aVW7/CVJPeyte+AslcVA1PnaBFLXzx6aKC/ZdfF8vYubBTp0iNrGQnKxCPWfayGqOsZgny
hs16KCAAIfkEACIAlQAsAAAOAXACNwAHCP8A7QkcSLDgQH4IEypcyLChw4cQI0pcaLCixYsYM2rc
yLGjx48gQ4ocSbIkyDcmU6pcybKly5cwL/6bSbOmzZs4c+rcybOnzZhAgwodSrSo0aNIkypdCtSn
06dQo0qdSrWq1atYs2rdyrWr169WmYodmxSs2bNo06pdy7at27dmycqd2xSu3bt48+rdy7cvVLqA
A6f0mxMA4cOInRpOzJjq4sY4BUue7PHxP8uWeWa+DKBz56qbZ4be6dmzztFTUUNVrXj1WtakacKG
HPXxbNFsQ9/+Sbn3WKmYa+7evFuz1tvFaTdOLlz5V+aXnUuf7tx2dNycP4vWXrq5TevZF3f/x26a
fHnD2mXfRM/d9Hj20c9zNm+7fHac4tMLt7//Om724L0333fy/XcffeIN+J5723F3IIHtpQefgg8K
WKB/stnX3Yb+5Sdhh+tpeB6H6sVHIYAZ8kfdiodZ52JzAa6H33WZBWcieRhO+F2IJSaonoQuBvfi
jyXCWOSMMgoZo5JI4phfjzkOKCOITGJ3ZJQKJvjhjh+CVxiGVqJHJJRezlijkWRWeaOVLLbpl5Y4
jundfhayiaWYXKIZIolxCjnnmgb+ieeXyJmpJ41RjmYjnosmelqYjl55JpSQ2ngonLERRyabPg5K
6I5yInqmn1e6aepWIK3JaGkelqqopKzS/xeqp39yiuBnlgJKY4Qj6tYgfuPlOWugxEKo4ZGYFhue
j4B6OimykBbrIa7e0dogtaCKeq2Dum4LJqlOCistb76VW66qiD4K5ro3Pltrst3aeae8udI6amzZ
2pnrsI2Cm++Y/V5aLb/v5svskOMGbPC6S8qr7cLuOqusxPuaa3Fv6DKLLsOGfjtww6HWOm+ktt6b
sKsgzqmfnNiGGzK07X4s8HaVzizpwDWzLLHD9XEc7cjs9vxsyw6aTCy3FyctmL501ofZ03xOe22P
WwoILJ8dAqhxrB5XKKKvD9IZ9K87S83u1FQGa3aNRK/KLb29ehnk182WSjba85Wptt33rf+NLYO6
lv33TEoXHtOp00Fnl+JbMZ6Y445fFbnDWGmM+OWYZ/7vcnlNThjjnjt23HNna85TA5enanpuyq0M
V+h9gX5X6LAHS5PhuIu1+u689+5c7sAHv5HvxBdv/PHIJ6/88sw37/zz0OukemqMqQb548jD/rzw
3HdPEmituWW9VcVpb1xtrDce/c9PDSSB0u97L39I4GOvruiIMWd++tE7Dtgcc5ifAGESnpodq4Dx
gdPXXNe0/wBJRctCW4AOaKEueQ2CapNP0VzFKwRG0IMwepKBFuhAvI3KbBfcWgIliMEDTaiCTtOS
1nb1wJsIBoABHKAODQIcmUkJXjpa4bj/fKKjnUELXGVL1JIQ1jV6SWljRbLcyThIM1ExMYg4y9AR
CfajMmFJiyUs2RWfOEYvNgaH6zuewhQ2MZKVTlx1E9S8VFg3NsYRZod6mMh85S9NRYtiecyirULW
xy8OcouInGIU3bgWNmwFjWnsHavk5sM2FvI0WDOiGOu0LCDO0Wbbmpa9lPWrMGWyk1NKGcVixbYL
cYprrgQkrGznxkJOsolai5Cp5hBJ3vFxkLLkIuVqaUhGBuqXw6pjwSAGKmvhzJbnU6Ux68U0viny
jsMkpjBvRkqR9fKbb1ljJQNHsrdFMZgrE5rKYBZMPaoqYlnDZZM6pUV1ouyPxLSUOQ05/yh0arKY
l7zmKBUpRXAaNCqpsloCKejKOAJON9RaVMtSRMN6MZRXY+zbnpxGTsrxB1d/CykDKenQhj70XxmM
IUXtFbeNWm5BJGSY2ziKnR3aVIBETEtBW1c/9XFlf8TT31tuStTJkA4tzqxOT7OyP6D6TqgHjWpj
pocvr9CSRcm5quSOA0GpZvNLbimqWIHn1bKalXBjTataNXLWtrr1rXCNq1znSte62vV+d93c1fLK
1772cpJJ1UxXZ7cXM6ZydNV7ymxgk87h+PWxbdpXTq3ZPMPqdX20YxtkNwuZ6SlJpZfdW3scCFoU
paxaIwXcCMXUwYVOrZ/G8uApK+Rab//FtrYhlKEJUbgh94wUtyyrKD4ReNW1Gve433tlMu0m0SoW
MUkI05QX4QmkI8boaFPyVznDiE0lwqqLeGxnnDi2peAmkYnFRK561zu8Q3YXbOPN6MycGVjqyjGZ
IGtmHrWrTG4OMZFfFG+6PsVNRn2yjVcyiArYy+D14nGhKoLvgDPKynFSzY8AhppqJ9xNFcKTtgEt
2TL/mzasmRKZ1TTwLUV839s1+MUDXCp/vdmonAm0wyhl5oOBuans7neZ7bSvf7GJXp/tEaCLRPFA
v8rZJrfvIw/+pzYpiUQjvmq62ZooNWt8Wv0Ssp49PpqQq0niMvrYifuiciWXnC4Yu1mQfjJGLQNl
e8AS19DKYO0qTN8bSzB7NEWlFSl+JyrBdykUb8LdbdiWy7NC96mlTHaypCMD5diRb0VOxd9SXVO8
N4v1Gmk1leyok2lNm5rTk0519Kiql1EnrrCDRbViS+0XT9v61rj+iGdyzete+9okqiYfrYNN7GJP
5dfITrayl83sZjv72dCOtrSnTe1qizUgACH5BAAiAJUALAAARAFwAjcABwj/AO0JHEiwoMGDCBMq
XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK7PivpMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmz
p8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKndryA9WrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3
cOPKnUu3rt27ePPq3cu3r9+/gAPTHUm4sOHDiBMrXsy4sePHkBcLnky5suXLWCNr3sy5s+fPoEOL
Hu0Rs+nTqFOrlkm6tevXsGPLnk0b8urbuHPr9lu7t+/fwDMeCE68uMTdyJMrX868ufPn0FMbn069
uvXr2LNr3869u/fvnBeB/x9P3ri18ujTq1/Pvr379/Djy59Pvz7J6Pjze12lv7///wAORUmAS9ln
4IEIJqjgggw2iNAsDsZH4IQUVmjhhRhmqGFmEW3oIU0RhgjchySWaOJXx52o4kkitsjdij/1089z
LtYY20pXsCTjSTua1GNJMs7oY5BE/vhPkUAKyaOSKBGZZJFBqgTlkintaGSSUiLZ5JVHOtkllFxu
uWWYT4K5ZJRDMvnkmUZOmSaaY7bJpJxYwmjnUT962eWZK3EJp5Vq7tlnoILqqGSegQKqZpiIjilm
nUPCpKWgZFLp6Jpfzonmnz02Cqmch3YaqqeV3mkqT6KKSiWjiRLqJ6GQWv9qaKSxYqlnobIWCiit
s7qkqKuw8iospXBmWquqn4aaq65CeunpqdCydFyqzWqK67Bkvtrro9s+G+mutcbaqLdZvgRuuS1d
yeqeqp67qrLJDlsntfH+Y+O9rdlEL67uYgsrmMVyu2yV8F7L7ozkiqssndvOWmmp164L7q4SF/zs
usQia3C0HN80McLWYixvuA8D62u1A38cLrPvxonuydkG62+5+/ZrK8q0Mvyoygl3HG2KzhabsLr/
ttrwyGwuavS4wN7as7YxBbwxwQJ/W227Jk9aptIvB80wvmATV+bYb0pN9KBUo512rzpbzebLcUp9
rMwuI732yucyTTPO81r/u7bXfoctuG9kO12wvCLbnXjXh9/89t2yxlx1upzKBHXORc9dL8szv0l2
SoOHPhumpJ+dst6TjwyxzgwTbTLkeRt9srFTq80nppJ/mabCvJcO6u11ii78a8K2HXHRm8pO8OW2
J6sn86pznenrMCOqNdxJD6yw0FybvjXcpg8vfmI+40l3+eirlmL6kp5/2/iQHXLvSgKwrxPE9uev
//789z/W+v4L4FPgJyEBGrApBNTOARfIwNysj3taM1PD6ASw401PbgADVamYF8GlXS9uTUsaqzR1
K0NxD3JbQ5K2Kvg97PHLcKnTXsbMBLUeJTA7ODnh7l6Yuc/ZrF74mxynwYLFOuuRDGSKa5zuiue6
yMlsiKRb2bJW2MONBSxVO/Re83Y4RdkFsYFKARoSNWdBtQVNiqRy3+li2LcuHpFzjBMTuShosSdK
D4aUE+IY2fi4NjrRbrTrY+csZcMbXsdje6QiCvuGrJLBMWrSY6PGKka1nm3OcW/E5CNTRzElVk2R
i6zkwl5nSTdCr4ZqBKNXYifKUNbsah0k4Qc/Sb0sGU+TbpPiJlnJLV7WjpKlJOO73IQ/VmIsmL07
ZQZ1qUqmBAQAIfkEACIAlQAsAAB6AXACNwAHCP8A/wkcSLBgwX79/iEcuPBgwoYEIToUiLChxYoY
I0rEmNGgxokGJYas+HGkwoQTIYoseTIlypYgW6p8uZLhy48LZ3pkSfFmz5McUdZ0aRMmSJ07iypd
KTJox6FJo0qdSrWq1atYs2rdyrUr15w0fcoUOxTsz4tRSSq12lSs0Z1tPZol+tZk3bFr186FCfUu
Xr5ued7dOxIq2r8xCSdFOtgnU6GBvUqeTLmy5cuYDdrbzLmzZ85GD+MkG/mpWr82b/aV69jt6rgm
HwN93ZGl6KVhe56G6/phbtoxi65GrVPxz7ORbTsN3vj45+fQo0ufTr269evYs2vfzr07dK3Lm8v/
5n2RcezcV2Ezt5tXOGnAaSE75Hi8ZPjb7EdrBC4YcXzW+/kGIHJUlfVef/hlpuCCDDbo4FbahSaf
fa3FVx567CUo1XjtDShYgnsZhqGE9dWHlHn5wZdacnXJNpxfG6mlnm5VGZgihwN5p+OOPPbo449A
cpdVXDFOSONiRXZoopE1khYWi409mddtNuJG15FEqlbaTEwCteGBx9WEYnsycjlfk7zdeOCLD7bp
5ptwZqVdlvStuBuSPDkl4GhBfUkemwbeORuKYlZIZ20t7qmknQiyWGhteuomYn51nvkloiVmOl5D
QXbq6aeghgpknKSWauqpqKaq6qqsturqqxG+/yrrrLTWamuc9vzjHSei9srjKb4Gq+OtxBZr7LHI
Jqvsssw26+yz0EYr7bTUWiXstdhmq+223Hbr7bfghituj9WWa+656Kar7rrstuvuu/DGK++89NZr
77345qvvvvz26++/AAcssIPEDBzvuAgnrPDCDDfs8MMQf2vwxBS/60XFGGes8cYcd+zxxyCHLHJl
EZccJBAmp6zyyiy37PLLMMcs88w012yzdCNbtkrOk3Xh889AB83z0EQXbfTRSCet9NJMN+3001DP
KkvUVFddsT5Wm3rz1lx37fV0VXwtdqdZl2322QyOrfbaCQ/A9ttwk422u87Mbfe5ceet99589//t
N5Cb/C344IQXriME1CXLBht3N+44vSsvzobh3YpB+eWYZ36t5Jp37vnnhUcr+eOklz4tzZyDrvrq
rLee7eSuxy777LTXbvvtuOeu++689x6utNMRhLPppvuOMPHIJw91rNAGn2N0UgEAwK3Ta1V9g9eX
On310i+YffZJgd/s9roaL+6p3TMrvfj/sL/V9e5fRb5A4Mff/kD1Xza/9eFbRb79k/keVQT4vv5Z
xn37U15XtLO+9REkfVWBoEckeBnnCQRnCKwMAPlHP/nh70EbNKBX/oe9Bw6QMvELoQcneD/znQ8r
EKSg/FRIK+45sH3pu+H/uhfDHPKQfj6kIPf/Org9HuoQh0I0Yg6BWL8g4hB/S2yiDac4RSYS8YZI
3IkOo3i/LlbxflQ0YRat6EUwYrGBBXHgFr+4xieSEY1jxKICJ8PA79mQifCDYxB7iMci5nGNfCwf
9J73nSES8YNX7GAZTQi/LoIRkYoc4v4aOUkxOpKEBqFkJNP4SEhe8pPsw2QnRUhJQxryg0tU5CFX
+UhJotKTBORkI1fpSlZW0iMuZJkEfehGI2ZSfLzMohqLCMUxFlOQ3yHkcxY5Sk1u0otqfKUtGdnK
Tx5ylqrUpAwbOD9TRjOWoJQmHpvpRi1CspKYRCM2BehMM4rzlkCEZTT7uEg//tCW7MsluLKy/8s7
JvGXAO3lHZ/IRxli5pTwvGUtydlOdlZzneQ85zvBWc9wgrOh1qxmNjOYTYsyVKLv9OhHVVlMiGLz
mQkM5wNpOMep1HGl8UTiQGEq02Da1J7DjIoFkfkZZibUmgtFZ0gtGdRXntSkllRpURMYS6F2FJ6O
5ORTiTrVjobUmaKE6lAj2smlitOTPNUnxPoZ05ICk5gxvWk8t2m/nUpnnqOMIyK9yUs2gnWW/jTq
XYUqxzei9JtpdCJQw4hOg5L0iCCVaVThGMkeIlShcjxjGAVqysYidK0yFGvKAklQf56VsmkdqC8x
G1C3DrKl7mLpqTTbLX5yk6aMfS1ltxja0AzSNrCorVhfc0utgAAAIfkEACIAlQAsAACwAXACNwAH
CP8A/wkcSLDgQAAIExJEKDAhgIMOGz7855AhxYkWM2KMeNGgRYMgQ4ocSbKkyZMoU6pcybKly5cw
VSqMSbOmzZs4c+rEaa+nz59Afe4cOjIoUIJGkypdyrSp06dQo0qdSrWq1atYs2rdyrXrVgBew4od
S7SsQaZIx6pdy7at27dw48qdS7cuXLN4BaIdaLev37+AAwseTLjw3byIEytezLix48d6DUueLBmy
5cuYM2vezLmz58+ga05cOTq0RNMjPxYsjRqmasasW8ueTVvzw9GsYy88mFg3St0cU/NOObMicY/D
TQZneTu565K+S8+8iPv18YXTReKWqbq69drgw7f/nCq84XWKsmP7Drme5Pbdv5GbV36zfUv76D2+
R799v0z4J+HH3nAfbUfZgQgmCBRG5t3GEEcOvqZQcNlR15FE3mHIIIUVFtedfhlOiKGG2gFYoYUo
jshhbiBC1FyD/Fm4UYbYhSihRuolxyKAI1LnnXQtqvhgj8utpiNvCiapZFukzdfcfk86B2V+VOa3
oXMxwtiflLwBl1GXJlL5YpVY5nikmWKmWeN8WbLpIIxwtjkgkEbGWaeaF542J5hsEsmnm2n6xyWJ
4hVqaEpTRRkloGPSGehyDPIHoYha/unomCBFOOSZlsonZXZb3tlfkV1GdGmgpU7o5aZ9MjqgizuW
/0lpm9H5iGmotHoKqHlL9uorV00qiueiVU5Zq5Vk4kpso2G2h2mxnQqKpn+4Hmnnnjwqi6p+zfLo
aqbgenuqtuDGum2u3g576LrsgkTee8xW2qexg14ZJ7P4DionctVqS62u/16rrqDRdnsvntDaOS2Z
WCJ7MKcP8/vnufG2uit6v2asMZPwnraltPF26GSPPqIKb4dfrjbdyhpZmXKxEKp8Y6Qqq4lygTjP
GPKLHqrXs54uWpxidzmDuDPRRRPJ88vSTapzZBtHLbVW7dJX9dVYmzb11lyTl7XMX4ctNmZdl63x
2GinrfbabLf9ktduxy13oWbXbfdhNYeLtYCNff9HFN/Q3Sm4S34DrtndiCfeVEwLB3jicQSLBlvg
eg8toXamOl64kWgS7qm5Ohk+9+ikUx6m1ZKXJXrq5eVNMUTuNfwqw8nO7rmoiq3u9hClh/0ujmuu
OLjl+T65Kcu5MS1k0ivOGKSMM5Nsbe37fo487qN+6bzw+/4cdMwpZtkzjcbTGen1iqevvlD/CUxv
q8VNPOrB1VrL8+kFR8x5uvVPX93IrSPXt3JFrNddzn2c8tIA8UUzAsGPdr2LYNj6ZyxSNShzECOg
qXy2Mn09zV9FwqDF+jcvkRmnRIyCVPzoJ6kziTCD/muhqESYrxHG6IO6kyBtzBBBCsIQWx40YKb/
HIU/IbJQb7f6HASBIzj7vE9XQvxf/RbWOFqdymDo2o2w3JRDHXpRMYma2MUqtj+F5S+LCUNWA/11
xnHxT4wNo9kVcae/WBVPi2f84cCylcEa0q5j8/qHXfCxvkJWZoU1O1nykoYiGnpMaRzc1aw+SCDv
1ch5efLT85BGx05iMo6q0l4jK9nAoP2xeAeEJPmw48lQQs2QsOzaF83SxVmCppa2zKUudfi4XYoH
l74MpjCHScxiGvOYJIEbMpfJzFg601dfIyJkungs1IXHbwHKSzXxyBxgMvOb17SmN1mXrspJC4VN
it1L8BM5dI7TdMOrnjXBSU+1CUiaj2EiPNtZ/7nzoPM+8DzPO9UJRYHNs54IRcnvMKkqQjXyeg/9
pAqVt6aSNSt+DIUkySZq0UVNdJURQhilzoej7X1qWdKDHvNIqUpYySyjMJWe95rzzJomKZ3fshcB
4RgxMgqwjGlk4AB7KtIEyrGIMpyS/Y6YRTfWsY/nAqpPC8ail+HvTQnN6joNplNNCdWlP5rqyDgo
1p1qaGmsMk7ATDY9m02SmwmU1FuBZEc4nXCMBmxaWovKQkoCLYYD1WrvwnC7nDJ1jH6s61LrutbE
ShVhfGXrxYwILcbeEHtwlaTDlMhUKbYRi1vs3hyfJdjSipNPXX3dZ5862QWCdo8CLOvH2srGB/82
0YGHZZhSI1vbyq7WtSjt3BNNi9CFanJDEM2eSy+EPL3is2Qg26teneShjaJMsg61KHRZKTSKjpK6
caStdfZKvJCSSJGLjOl2UzpdKtn0vQfCS2BpMt/a5LC+8SSufn2pzPhsBr+zuS8tEwpfpQyjwHbZ
r4IXzOAGO/jBEI5wTJS5OgBzq5+NQbBksqHhDnu4KlvtHE+R2j6kWhiCEk6xivdmu/zKjjmcRcyJ
V0zjGst4pA8aUvmOiuOngS18oSQpXVvqJ/Pa+MhIXkwY5cXFzlLWqVeVp/JAKLQPW/nKWE4QTo0H
2M/+1IeuGi+sHMvPJJt5dDO+zJKtuEcnfxlKjk/8kG3NSrss2/nOeE5Sv9pMZ8fqcbijfTJ88kzo
QhvaK93UMc4elbONuOyoFVXgx1IZ0VXCDsVnzrSmVdJfNMPk0KAOtaidEhAAIfkEAOb9lQAsAADm
AXACNwAHCP8A7QkcSLDgwH8IEypcyLChw4cQI0qc6BAAxYcGM2rcyLGjx48gQ4ocSbKkyZMoU6pc
ybKly5cwYwq8SLOmzZs4JVrMybOnz59AgwodSrSoUYQEjipdyrQpRplQo0qdSrWq1atYs2odGWur
168mnYodS7as2bNo06pdy7at239g48qdS7eu3ZCa7urdy3fq27+AAwseTLiw4cOF+ypezLix48eQ
I0dGTLmy5cuYM0OEpLmz58+gQ4seTbq06dOoU6tezbp1RMmwY0ulovKX7Nu4c+d2zbu379/AXese
Try48ePIkytfzry58+fQo0ufTr269esfg2vfzr27d7fYw4v/LxlhvPnz2b+rX8++vfv38OPLd7hl
vnb0+PPr38+/v///AAZ4m30EFmjggZUJqOCCDAZYXl0IRijhhBRWaOGFGGao4YYcdujhhyCGKOKI
DDVo4okopvgSiSy26GJpKsYo44w01mjjjTjmqOOOPPbo449ABilkRi8WaeSRhKGR0JBMNunkXUhG
KeWUaT1p5ZVYVkXlZ6Zs6eWXYP7UpWYZhGmmUFmmqeaabLbp5psBhgHnnHRCduadeOap5558RiiD
UQKCs6Y/dRbql33ggNMncIwwsuijYiWqKKS8NUppcPslaih1jW4KYCHQSeqpdJ2Oit16iV7am6Wq
thpUqq6yHsZqrPeZ2tEptuaq664x+cLrr8AGK+ywxBZr7FQBAQA7

------=_NextPart_000_000B_01C70785.7A5EDAB0--



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 kAE1J0TG065215; Mon, 13 Nov 2006 18:19:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAE1J0Bw065213; Mon, 13 Nov 2006 18:19:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dmzraw4.extranet.tce.com (dmzraw4.extranet.tce.com [157.254.234.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAE1Iwn1065194 for <[e-mail]>; Mon, 13 Nov 2006 18:18:59 -0700 (MST) (envelope-from [e-mail])
Received: from indyvss1.am.thmulti.com (unknown [157.254.92.60]) by dmzraw4.extranet.tce.com (Postfix) with ESMTP id 6AAB78D62; Tue, 14 Nov 2006 01:18:38 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id 41E941237; Tue, 14 Nov 2006 01:18:38 +0000 (GMT)
X-Virus-Scanned: amavisd-new at thomson.net
Received: from indyvss1.am.thmulti.com ([127.0.0.1]) by localhost (indyvss1.am.thmulti.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CG-wGuB1zsZX; Tue, 14 Nov 2006 01:18:30 +0000 (GMT)
Received: from INDYSMAILCS02.am.thmulti.com (indysmailcs02.am.thmulti.com [157.254.96.3]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id 8BB7A1216; Tue, 14 Nov 2006 01:18:30 +0000 (GMT)
Received: from INDYSMAILMB03.am.thmulti.com ([157.254.96.81]) by INDYSMAILCS02.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 20:18:30 -0500
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: PEM file format rfc draft request
Date: Mon, 13 Nov 2006 20:18:29 -0500
Message-ID: <[e-mail]>
In-reply-to: <p06230904c17eb25c83ad@[128.89.89.106]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PEM file format rfc draft request
thread-index: AccHfeB5mjmqgYlWRL2BXYbRyVNsCwADATzw
From: "Ogle Ron" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, "Dieter Bratko" <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2006 01:18:30.0324 (UTC) FILETIME=[CB6E6740:01C7078A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kAE1J0n1065207
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that the original PEM meaning is as you state.  I have no idea
as to how it got skewed with these new meanings for public/private keys
and certificates.  However, it does now exist.

As for the relevance with PKIX, the "PEM" format also describes the base
64 encoding with MIME headers for x509 certificates.  Also, many S/MIME,
SSL, IPsec, and other cryptographic standards that use x509 also
recognize PEM formatted certificates/key pairs.  This is how I
discovered the problem in the first place.

If not PKIX, then where?

Thanks
Ron Ogle

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Monday, November 13, 2006 6:45 PM
To: Ogle Ron
Cc: [e-mail]; Dieter Bratko
Subject: Re: PEM file format rfc draft request

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I 
think RFC 1421 defines the last of the formats (we had a few 
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.
For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".


it looks like folks made this up!  PEM describes how to transfer a 
symmetric key encrypted under a public (RSA) key in a message, in 
1421.  It does not describe how to transfer a private key, because 
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to 
IETF standards. Since PKCS #8 defines a format for private keys, it 
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is 
not immediately clear that a document on how to use base-64 encoding 
and MIME-style headers to represent private keys is within our scope.

Steve



Received: from 20129194166.user.veloxzone.com.br (20129194166.user.veloxzone.com.br [201.29.194.166] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAE0tGem062408 for <[e-mail]>; Mon, 13 Nov 2006 17:55:20 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000301c7011f$e07d4af0$a6c21dc9@barrostu327chq>
From: "tam" <[e-mail]>
To: [e-mail]
References: <000301c7011f$e07d4af0$a6c21dc9@barrostu327chq>
Subject: Re: WWW wykrywanie spamu wirusw
Date: 	Sun, 5 Nov 2006 19:17:51 -0200
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C7010F.16481B30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C7010F.16481B30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0006_01C7010F.16481B30"

------=_NextPart_001_0006_01C7010F.16481B30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Monday, November 01:09:02 PM
  Subject: WWW wykrywanie spamu wirusw


  Redakcja Forum Kcik webmastera Reklama Sownik Wirusy Bios praktyce?
  Enter getdatestr in Infoserwis.
  Cm dugoci Intel zwiksza.
  Konta nowymi mb of poczt www wykrywanie a spamu. Adowania am strony =
artykuw.
  Podwoi zyski a iii kwartale Nowy serwis Gadufun Jeeli of.
  Vogel Burda sp oo is Wszystkie prawa. Praktyce Linux is spka. Zobacz =
is Ankieta am Jakie zmiany stronie of enterpl.
  Praktyczne a porady dotyczce ochrony.
  Nowy serwis am Gadufun Jeeli am tworzysz in swoj wasn. Konkursy or =
Ksiki Ankiety Pocztawww is Redakcja Forum.
  Wiele innych Uwaga Praktyczne porady dotyczce is ochrony. Online =
Zmiana a nawigacji am wyniki?
  Konkursy Ksiki Ankiety or Pocztawww Redakcja Forum. Stronie enterpl =
uwaasz potrzebne Szata graficzna dziay adowania of strony?
  Online Zmiana nawigacji wyniki Najnowsze wtki Konta nowymi.
  Domen Personal email a gb Business a Server Patronaty medialne.
  Kcika is Znajdziesz tam kurs Html oraz of podrcznik php. Konkursy or =
Ksiki Ankiety Pocztawww is Redakcja Forum.
  Enter getdatestr in Infoserwis.
  Powiedz gdzie oni osb za. Artykuw Mniej reklam Kursy online Zmiana =
nawigacji wyniki Najnowsze.
  Konkretnym uniksowego wiata. Ramwki pierwszej polskiej am telewizji =
granej na.
  Kcik webmastera Reklama Sownik Wirusy Bios or.
  Konkretnym uniksowego wiata.
  Galerii zdjciami Linuksem in systemami rodziny?
  Acxiom dla Centertela uke is.
  Intela am Tsmc buduje nowe of Faby amd deklaruj am dobre stosunki.
  Internetow lub po prostu pragniesz zapozna si.
------=_NextPart_001_0006_01C7010F.16481B30
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"pierwszej" hspace=3D0=20
src=3D"cid:000401c7011f$d9d0eb30$a6c21dc9@barrostu327chq" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 01:09:02 =
PM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> WWW wykrywanie spamu =
wirusw</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Redakcja Forum Kcik webmastera Reklama =
Sownik=20
Wirusy Bios praktyce?<BR>Enter getdatestr in Infoserwis.<BR>Cm dugoci =
Intel=20
zwiksza.<BR>Konta nowymi mb of poczt www wykrywanie a spamu. Adowania am =
strony=20
artykuw.<BR>Podwoi zyski a iii kwartale Nowy serwis Gadufun Jeeli =
of.<BR>Vogel=20
Burda sp oo is Wszystkie prawa. Praktyce Linux is spka. Zobacz is =
Ankieta am=20
Jakie zmiany stronie of enterpl.<BR>Praktyczne a porady dotyczce=20
ochrony.<BR>Nowy serwis am Gadufun Jeeli am tworzysz in swoj wasn. =
Konkursy or=20
Ksiki Ankiety Pocztawww is Redakcja Forum.<BR>Wiele innych Uwaga =
Praktyczne=20
porady dotyczce is ochrony. Online Zmiana a nawigacji am =
wyniki?<BR>Konkursy=20
Ksiki Ankiety or Pocztawww Redakcja Forum. Stronie enterpl uwaasz =
potrzebne=20
Szata graficzna dziay adowania of strony?<BR>Online Zmiana nawigacji =
wyniki=20
Najnowsze wtki Konta nowymi.<BR>Domen Personal email a gb Business a =
Server=20
Patronaty medialne.<BR>Kcika is Znajdziesz tam kurs Html oraz of =
podrcznik php.=20
Konkursy or Ksiki Ankiety Pocztawww is Redakcja Forum.<BR>Enter =
getdatestr in=20
Infoserwis.<BR>Powiedz gdzie oni osb za. Artykuw Mniej reklam Kursy =
online=20
Zmiana nawigacji wyniki Najnowsze.<BR>Konkretnym uniksowego wiata. =
Ramwki=20
pierwszej polskiej am telewizji granej na.<BR>Kcik webmastera Reklama =
Sownik=20
Wirusy Bios or.<BR>Konkretnym uniksowego wiata.<BR>Galerii zdjciami =
Linuksem in=20
systemami rodziny?<BR>Acxiom dla Centertela uke is.<BR>Intela am Tsmc =
buduje=20
nowe of Faby amd deklaruj am dobre stosunki.<BR>Internetow lub po prostu =

pragniesz zapozna si.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0006_01C7010F.16481B30--

------=_NextPart_000_0005_01C7010F.16481B30
Content-Type: image/gif;
	name="czy.gif"
Content-Transfer-Encoding: base64
Content-ID: <000401c7011f$d9d0eb30$a6c21dc9@barrostu327chq>

R0lGODlhcAIoAof2AAwCAHEJCwCOBHiNDg0AiosAiwB4jrrNwcXbvpvQ5z0tAF4rA4AYAKIfALUg
AOASAAdGDiU8B0NHAGs9AHI7AJpCAMU9DtM4DABgCyRYAD9SCGpbAHtmCqdUALVSDOVrDAeMAB17
AExyAGGAB3l8Dat4Db2NCtp3AACRBCimCUiaAFmbAI2jAqCtA7mcCOupAADKAyOyBz/MAGnLAIPL
AJLNAL/BANXIAAbnABbtADHeAGjjAHrWAJveCMDUAN7RAAAAQC0ASTMAR2cATocANZ4ANL4CN+kM
NQAoNSsnRkwoSFcsNXQgNaMbN7koSeQZNwBCPyI/Sks/Q2I0Too6O5dMP70+RdhGNQVeQSNhNTRj
PFZcNXNhAapYQsRrQ95TSACNNSVzMUJ7TGKAR456TZuEMreGONWBNQCTSRWoRzyeM2WhPIeoRZOU
Pr6hStujNA7IOR26Sz/EQlG9PYW9Nq7GM7zIQOLNQQDmOiHlTEHdS1LaTovTQJLqNrbiPdjsNAgI
hiMAfz8Ag2YAfIMAh6MAjbcIhu4MfQAUgyIlfEQfd2UufHMge6UrhbcrgdcpcgBGfSlJjDY3iFQ0
gnJEjqI8ccw2e+dIiABffS5RjExsfm1giXtXiJpmd8hpg9lViAB0giaEeDJ+jmqOh3p1h5l8fb9x
htd4jACYhSWacUybgmicfIWUgaygeLOcftmldAC5hh3BeTnFdGnDh4W4hJ7DjbK2fd7GiADrhRnT
ckLahWrngYPngqTiebnkcuXZdgAKxCcOvjEOu2YEzYMJzaMKxsQFzNIOtgontBkdxzkfvW4hvYYW
tKoSwcMRtNwqxAZKxCRFwTs1yVQ/wH43ypZLtb40uOlFtwBsshldtEptyVpdznlkxaVbsb9hwN5h
sQB6vh14wj11tlJ5xI6LuK51wcqJu+qNvQCstCGovEWiwmqqwIejtpensb6WsdOnsQC5uS3Gwju7
t263zXG6s525ufv1+5WrnnqEgPMAAgj4C/z6CQAA8f8A9AD3//fz/yH5BAAWAF0ALAAAAABwAigC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK7GivpMmTKFOqXMmypcuX
MGPKnIlyC82bOHPq3Mmzp8+fQIMKHUq0qNGjPEcqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXat16CakPyvAnUu3rt27ePPq3cu3L9Fy9tgKHky4sOHDiJX6Xcy4sePHkCNLdgxg
Ml+z0xJr3sy5c1cAnkOLHk26tGmKoE83tMy6tevXsGPLBlp59lzVuHMvzaVbNJ+MqXsLH068uPGR
wY8rX848Ma/mGpNDn069unXN0q9r3869u9bsxvt6/7JNvrz58+jTq3/pvb379/Djy59Pv37U9fjz
69/Pv7///wAGKOCABBZo4IEIJjhbFAo2mJN9EEYooUWEqObghRhmqOGGRk3o4YcgEsfhiCSWaOKJ
KKao4oostsjTKTC6KONKlsxoY4BqwXhKiDz26ONCenFxI04CDGnkkf39qOSSTKKF5JNQRinllFRW
aeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmzOpUObj+EB55x0ItXknXjmiVWdfPp3QJ+26elj
G4IWelUMhk5IaKKMNuooRIs+KumklFZqqUWAZqopfqds6umnoIYq6qhqXmrqqWAhgOqqrLZqFamw
xv8q66y0ItiOka7mOhUVuiYES6/AqpVPsMQWa+yx9SmC7LLG1urss9BGK62zzFZrbWjT4gVJttx2
6+23GF4r7riGgWvuueimq26J5Lbr7rvwxivvvPTWa++9+Oar77789uvvvwAHLPDABCf2TsEIJ6zw
wgw37HCj60YscV0PV2zxxRgXOvHGHA+V8cfIRtxBxySXbPLJeIGsssJ7rOzytQK8LPPMNNfMFMo4
R9ZNnTb37PPPQActtMI5F2300EgzafTSKCfttI9MR03y01RXbfXVZ1XgmQNY/yz11xN3LXZ8RjkC
9tlop612lWO37Xa1d7x9VZ/mrG333XjnrbdO2uz/7fffgJcn98/vHAxh4IgjVbiUgzfu+OMFJy75
5JR/W1vlmJsJwOVQQr5UKPRu7vnouYlO+umlmY766g7VcJU3Eqn+Yea0r7R5l8XSw3pTsg+Nyu7M
9Q788ISB12PtyI+ZqC7E75v88182P6/w0ldv/fXYM0m9U5tk36qUt0Mvfkr0be/9+VeZn7QBVRsZ
/vjwq+Se+ugjbCPn8eev//5U1u9/V/wL4JAgVI7/RU6ACEygAhfImiow8IEQjKAEdbKCCVqQRCW4
oJdYcZuIcABYGTCg2DIjwhKa8IQoTGFFEBcCDbrwhVFToQxHAkMwZYMmNYjYDHf4kRr6MEk8DKJG
/35IxCIasVTNMYIQHXbEJgpuiVCkiBOnSMUqMi6K/0tHSGKSDCpty4pgDKMYx0jGmGDxjA8p41Hc
MCcCqPGNBxJGg9BIRyDB8Y50qaMeD4JHtbGgj4A8yglQtEc9OcNVgUxkg/CnyACmhX6FrFl5GNnI
StKEkpaEnmAgGcmATaB0naTPA7SjHkxm0ks7C1dhOBlKtDzCUfkx5Skl18rEYCJEutPNLHcJE1f1
o5ZL4qUweeKHYTYSmHQ0pjKXycxmMs0IzoxmgpCJRmna5hHWzKaG/tQ5anrzm+A8iBLDKTdtmvNM
u7DSP85JPnIG8UjPYCe03PlOmoxCPbKwRyrlyf/PftKKnjz0ZyABukOBGvSgECSoQhfK0IZiDKF3
dKhEJ0rRilr0ohjNqEY3OkSIkkkcHg3piDiaPZGa9KS1IylEZqHSltILpWJ0qUxnyi++LCAo74Np
0wbDyl7pgaarmWROdZoztfQUqO6azVCfhAGirkmWYJvETxzoVHVFoqqLGYw/kMpVq8iiqw3xxZ6w
6kSwro6saE3r0szKVp8NY4Zqjatcp9bW0c31rnhNV13tepMy5FV/ew2sYE/1V5o8YX+DTaxiF8tY
qBR2JYNcYGMnS9kfPfaymJ1VZTfLWQll9rOg/VRnR/seLKwOCqS9kynsF9rWujZb33htikYm29r/
2hZMOcRVap922976dku79Y4UIvRbMOrjthNQW8I+ENweFjd/zY2udJXz3Opa97qvnS69DqBd/8GR
ENPqInbHy57umve8oyHv89DL3va614BHeK9851sa9aaLHeywL5y6ICD84le/tfNvfgGcOf928ITY
WCiBM0ffE06hwRCOsISBxYYJk27BmGvVUTWjg2pdg1miWiqGW9OrDVt4i7AS8SwbgTtimfjEG6mV
ikfstxmTBxjZZdaLYTyRadmYxnmDqmRU0FseG7mExhPJN5gzJSEDeZoQSvKRByblKR/GSk6GUg6e
nKAscxltXv4y2MIsZv6AqMrxGYOad3uDnqn5/81jMIg8aLpANZf5zjq0sp73HBE8+/nPYroAoAeN
Vz4b+tCITrSiE0Lom9ShZIuO9J4bvTZJK0cUls60pj1DaeVu+tMQVqSQOk3qUpv6P/c8tapXzepW
wzFRv2NoAILp6qKB+tbzrbWtcW0vXcdmA75WK3M6UKg48/rYyE62spfdrlnXN9gnOw7XmE3talv7
Iv28hoBasdZre5uxPgQCtNV61Z1++9yCHbfJ0G2tHS8LzZO2B5mhNe9OD8Td7H4USuqt7n5fdyFf
yLe1miHwjrih4AgXjTESvipoMPzhED+jvydeMgYo8xgUz7jGN36ZiHscoxxfF1gE8XHr+HMdgP+c
7xZKzvKWNyfk6nK5zGdO8+tcoeaagblecW4pnfv850CPDT6e+BXe4Pyrwwm60pfO9KY7/el24bnU
p051g0D96ljfG5HRpgz78huBQWgixsnz9WGqEN617GPZaRUAiq/9lDtEe9W1N/dHyZ0qYq37ae5e
mETQrJJvz7rgiWqOuvGyloWv2jmo4my9O/7xkI88jwb/T8nrifKYz7zmZ9OcCln+86QZgHA2T3qY
gh5PURJ06UsPBjN9kTWIBgNiuudZV7d+9Z+6Pe43pftoJ1r2ANN17yH9+4D5evh4psXET3+n3edv
687PDz3F4ai8z911bRMG87ffLxFwv3G4+L7/+MdP/vKHJfqb6hHfzc8dfLMfOptb//upE/9kh/D8
I0K+TH6Mfs3x3y/dsE/9dyD/1xcBKIADWCAFmIA9ASIk8DMUIDYMyCfzV4GPgyKvN4F70V5RYIEe
WH4qsQ8aiCYfWIJjM4JzYoIquIKV9RoikHHzkCXsJ38suBz11xmRwhbcxXPxR4NRwVw16BU3CB8o
WBTx1yAZkBQGMW0W6H7F4QBMGIQmVxJQWIRq4gBWmCZVuGrOkIWYJYXvMRe3MIZjmDza5oVo2E9C
kIZDoXqxAQOZNRJisFvDgjRzCIaHsQtNcYd4yB182IeIgRRi4E+p8EByCIg5dxSDyIYqcoiIJqgd
f/iIhKGBxcCIloh1kkhKl6g8mdiJnviJoBiKHbWJYSKKzREQACH5BAAbAF0ALAAAAABwAiMABwj/
AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGNe
/Eezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUr1qcyrWLNq3cq1q9evYMOKtQeg
rNmxaNOqXcu2rdu3Fc2WhUu3rt27ePPq3cu3r9+/gAMLHky4cF96hldWXcy4sePHkCNLRopjstRR
ljNrrpq4s+fPoEOLHk26tOmDg06rXs26tevXsDMCik279tzauHPr3t0SAO/fwIMLj+t7eMwKIjcr
X868ufPn0P8BiE69etLKQI1r385duPXv4MOL/x9Pvrz58+jTq1/Pvr379/Djy59Pv779+z8V4t+/
uLv//xTxJ+CABBZoIH/6HahgUQA26OBCC0Yo4YQUVuhYghZmSNODHHYoEE/5hFhTiPmMKCKJKJL4
j4omlphiiiC+SNOLKK5II4sy5nRjiTaqWGOLN7HYIo8zijikkT2eKGSPNtHYJJIaRimlggoJaaWS
ROKEo5FL+nSli1Dq1OWWWQIpJpc/MvlkmTAWSSSZZrap5pxfbujhnXh+CKeaXa7p5p9AjQlmmTpC
uWSYgBbKo5yHppnkm2hmiSSZk0YaJKQ85qnpdj35WOOeZ6bZZ6g7jXqppIgqWmqkoD66JpymAuSa
o6eEnjrlrbhS6KmNfKb6qp8/xRqrmYnGWKusShabLJCWDgvrolh26qtSbORqLWPEXKuTfrtG+6ic
Sb6ao62hOgnskcaO++ygzFbKLq3G/gnvsGpuaq930tLqbr6oHqulu97G+6+pwlrKa511Hhywqr0y
+eW+2or3SsQUDwUjo9O62W+gYcKbr8DkMkwpwAnL6KzBJncMccUst2xdgheLmrG6GZ8rb81zMhzy
wIm2WTLJOfNM56cqY2qnWmHcq/RXGg9J7MDsBg2ywzg3avPT5D4MrdFDtwqx1sr6urRf34ztUUAA
IfkEABsAXQAsAAAiAHACIwAHCP8A7QkcSPDfv3wI8xk8mHBhw4UQGSKUaPBhxIsVJzqcaBFjRoUb
IXbcCBLjQ4sJNaJUqVEiy5IMSX4k+VJky4gEc+rcybOnz59AgwodSrSo0aNIkxL8prSp06dQo0oF
KnNmVZM1KXrEWrLhSK42QX61ClbrR7EwY5p1eZbsyZspr64EObWu3bt48+rV+Y3p3r+AA+eVCzel
4bVeDcfdqhht47QjFTO+GZZjYcuQMVeu3PJwx8VnP2sUTLq06dNK/aJezXrw1tewY8ueTbu27du4
c+vezbu379/Agwsfnrsv8ePIkyvH6HO58+fQo9tuTb269b+qr2vf3lO69+/gw4v/H0++PHnj5tOr
X8++vfv38OPLn0+/vv37+PPr38+/v3/Zzf0n4IAEFmjggThxhxSCDDbo4IMQRvhdgLbxw4+EGGao
4Yb+KbjgaxZaaFCIJIY44oUnmohRiSaKCJGILC7k4ookvhijjS7OKCOKKaq4lY87AnlRiScOyeM/
RAYJJIs1epQkkxfqWGREUCKZJI5SKuljljAeOSWVN+JIo4o6ZpmikSg2yaWXPYK5JJszXulkkz3S
iWaOcB75pp1V1rmjgQGaueaXgrJJaJo84jlmkF9aqWeiUuL5KIiRQjrnn4M6yqiVfxoZW5xRGpqp
jTR2emipnWZapqGcmnqmmEWC//rjnpY2aqurW0oK5qmLvmomqpyOqqmpsgKr6D8eTnVrq6T+uqux
iDYrqpfH4grpqsvOyqyzpHr6bKW8Pqutt+K6umyxzFLa7ajVkptul91+y2qbShKb56XmSjopt/FO
ye+598Za67bT4usUAMkOBPC4sDkLb6MP94tpwARX/O+u6KrrrsClZmzuxguXG3LFn06aLq8Om8xx
thFfqii6wsZbaLCWXjyzzQWLGzHMOXvbFMIJCzQysLOGOSzEoYJMM7myNj2vyyprjGWMNw8sMdF1
tkixllpbW/KVwtp5p5A7syp2x9HyrDTJGCft79ML9wkylE7by3W7nSoFtHUlY/99J8O9orz1xEzX
+vK1KZ98tptWr9w2y3DTe/KtMb/9N76Wi8wvtoRD/q++4VYerrSZOzpv1bTRya7brXI+ZtS4AcBe
oD03bPbTtHo8+dI6Dwyv6GxfjeqgVQsp/Lgzi7y7nGuDG/Pm1EZb+uMaq+n74HZ7WrfycUfuraqG
i/15rUntzbftfgP+cefLY8+7zFbXCDyTmKtLfMF4r29/7ZTnzG3y7MsX3MBlOjLdLluhu17zGuc4
06UPdbdp2dueJD0Erst7W5EdfgDYtwWmin+2wpvrViXCA0JONhJsXfRGpz9tcbB/0FJfCFknQPRd
MHu9k2ECPVjDdxlvd4qrYG3/UlitIjIwfbfR4Oy60z6G/eqJ4XsgqIT4JgEiCnYzDB78YHg0A14N
eh/0m+g4pzukeY17/Srhq94HRCjiUH8k3FSlWJeya1kwe/ej3vRw6CKjmE87tgOen+ZEtRUWSk6I
NJoDJ0fCHwZxkITUXSNhR0BK5aqQRKJflQjIvKnN8YfQA9sKtZRFHlovkzcSH58C1smxHc+VMHSe
IelXwFe+RokcyqUud8nLXvpyNhT6pTCHScxiDidoRDGmMpfJzGbqMpjOjKY0kYXMalrzmlKZpja3
yc1uevOb4AynOMdJznKa85wS8skHPgCRdbaTnQtZJzwNIs96yvOd9/yHOyOy/8+L1JOe9vynPwN6
z4BiJJ8AtSc+FboVhgJ0oAclqDv7GU92SrSi+SRoROepT44+FKL85KhDOxpS2FD0nQnV6ElJylJs
uvSlMA3Ka/opUJYm1CMrRehEPWpTkJZ0NielKU8R2tOM8hSnQoUnUXsa0Z+idKUfJSlFl0pVkR61
ox7dp061mtWrVnSjPo3qV5mKzrLqpjlc5epTj5pTtg7Vq1CFKlKdGlSLzrOuYp1pV1OKUr069atx
detfd/pTuWLVqnkV6liR2ta2/vWj+4ypZCcbU5Mq1ahrbWpfw5rXzXrWsnTdq2JLatjPPpSwnX2s
YwOr2c2idqyGfe1r+zpav3tmVrVvTa1Zd0sbtF5WrYAVrGlTatC5cta2i8VrbYNb3Mee1q6LNW50
n1tcx4aWrDVtqmJZa9PSihW4n5UocClL3vJKVqqXLSp0OStX67Z2uNKFbG6X+1zZsBa43sUraeG6
VZ/OdrogVSt30WvfuxqYvbltqXkXzODqBAQAIfkEABsAXQAsAABEAHACIwAHCP8A7QkcSPDfhw8G
ESZc+K/hQYYNIz6MCJFiRYcKLWLUeJGjxIwbOz6cKBIhSY8hLY5UOPEkR5cuF8b8SDJmTZMgP6IM
2RLny4wrd+pMaTNn0ZAEkypdyrSp06dQo0qdSrWq1atYs2rd2lRowp4nb2qEmXMoxZkpz5ZFSfZg
WbElO/6cKxat2bQb7Q49CpEvW6A+Z9ZdOxawW7cqjb5lSdir48eQI0ueTLmy5cuYM2t+7BQjWJCH
EScePZd0adNeyeIN3bOwXNeuw4r+izpvY7Vxvx6GTZumT95BUxP2i5fhRK7Ikytfzry58+fKhX/G
XZz43eLXsXtUnRYud73U94L/nr1dcezbOrn3XSxUduvwnh+jtW59s/37+PPr38+//87OX6kFWG1F
DVhfdq+d1h1jo7mnXWGGrQYece+ZVmGAF6lXXmKMRSigfMOxBx9PCkFn4okopqjiiineJRuBIYp2
oG68CQdjhjiFJqCOf5E3I4Ks+babboYNKWFtNS5IHk3SLZlbdu8JhAiLVFZp5ZVYOuffllx26eWX
YIZpX1PtZGnmmWimyZyYbLbp5ptwxinnnHTWaeedeOap55589unnn4AGqpGahBZq6KGIJqrooow2
6qiVF6iJy6OUVmrppZhmqummnHbq6aeghnqmoKSWauqpqKaqaqmiturqq7DGtyproqvWauutuOaq
66689urrr8AGK+ywxBZr7LHIJqvsssw26+yz0EbrpyrSVmttsLNmq+223HbrLVPXhivuuOTm+u25
6C66Rrrsolvuu/DGK6+d7dZr77345qvvvvz26++/Vs0r8MAEF2zwwQgnrDB/ADfs8MMQ4wtMxBRX
bPHFGGesMcDuVEXAxiCHLPLIJJds8sn4AoDycgu37LKuALyMX1X5rGwzpklArPLNPPfss6s7/2xV
QAAh+QQAGwBdACwAAGYAcAIjAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaNH
AB5DihxJsqTJkyhTqlzJsqXLlxhBwpwpsQ7Nmzhz6tzJs6dPljJD0vhJtKjRo0iTEvTiRanTkkGf
Sp1KtarVlUyvaq0YdavXgf/Cih1LtqzZs2jTql3Ltq3bt3Djyp1Lt65dukzv6t3Lt6/ftAD+Ch5M
2O/Xw4iVZu2pLrHjxx4LS55MubLly5gza97MubPnz2gVgq67cLTp06hTY4bM+qnq17Bjy55Nu7bt
27hz697NVoAAt755gw4uvLhxwgCSJz8elvg/58F9Syc+nXp152Kv/8YOfXrz689/k/8FH7679OzV
z2ovj758evXi3ccP/53ve/nnv+cv2739eu7bkTcWef3Rx9yBCMq1XFgLGlcgfdjV196EZkUo4YPR
zSchhQZiKN6DA2rI3oYGouXhhBbOBWKJG6Z4oosfxqhWf9aFmOCNOKLVIFnKNdhjYMox+KNYQ/7z
Y2BGIukjkm9ZV6OFKXI4noj6xQcjfxpGWaONK5JYJYlRophlgNqZ5ySUY9oopZpn1qflfmG2GCCL
dOZoZ4I7EsnkgkH2CSSfTOqZpJJ/CikoXG1CKGKcYb7ZZZ0RvullhmtCmh+Aaa245aVzuimpmmBS
eWGMT4rqnZdY+rcfqHe2ylyehsb/CqihS5a1XK2DBkpXhpTiR+qqdaJ3H4swpofmqR2mKeCUxs6J
qYlWppmsqtTCNyWrcXJ53pmrAjhslU5a6+q4xsGa5KGznovrkefKGuRdp8YrKrbzOhpthYvOO+qk
ztab75eVUhipjCXy6l2j0obalrxbYvkoqwBfS+7EnDmylkLmrksorXsWyjG676pVGsMEZzofwvA9
iuaMBA88Lb6pugexxHRueu/K4nL47Fokoxpxtiuv3NrQSKlVq8butqsuoR4rnae5PHPasM4n+wtz
wTf/S6+cYlaK84g+Uy1wyb0qarKULnMNsLxXT921xGlTLDduRebacdLsCtmj03eP/wV11KCuhx/N
Dh9ctbDcGpz4z8jujPi20R5+9uPMFvge0MiuOazjZkKu7eUljx3w3KS3+rdbp5eOY7aqS8Z667AP
Jlpfqa9Vu1ilxT7b67rbFx/RwE/l1+2A6ZpW7r3HxnvydWEX/PM8MS/99NRXb31oCaWGvGTQd+/9
9+Afpf3skxElSPjop6/+V7Qbr6P72xe2/vz0128/RHa73xbxSo+1faAAzJ+ReCTA+xnwgAhc3474
xyP9mcVc//ObBN23JwaVJYEYzKAGtVK8B27MboPSW8jqhivUEWmAFtQfkE54vRa68IWxy9gH/VSo
d92qbyXc3wkrqEIU+hCGQAyiEGlxlLdcgexjSGwXAx+YQgsKkIUiXOIQp0jFKoIGUEhbmqCySJcV
NvGHE4SiFcdIxjKWL3sNFOERtZjEdJElfl4coJLOEkfjbfCOeMzjTzp4qP6l64ZbxGHf3lJHFFKQ
hQ40oyIXyci2BAQAIfkEABsAXQAsAACIAHACIwAHCP8A/wkcSBAAgIIHBRpEqDDhwoUN/0GU6DAh
RYIYMw48aJGjQo0dP2ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rc+dKgT4sXN1aM+HNiUaFI
WwKVKPQn04IUnWr0wrOq1atYs2rdyrWr169c7YkdS9bkxKxk04pFq7at27dw48qdS7eu3bt48+rd
y7ev37+AAwseTLhw4HH2ei4Fy7ix48eQI0ueTLmyZbOLL2vezLmz58+gQzeGqzUuQdKivRpezbq1
69ewY8ueTbt2adQCcafeWru379/AgwsfTjzw7benke8OW7y58+fQo0ufnva42+TX/x061HW7Ze8D
qYv/H0++vHnzJYtmjugYPEb3I+EPlP+eO3zv2/Nz16h/v3b9BOU3n3//DbjcgQgmqOCCMxm1HmT9
7QdgfALWR2B9At1nn3/0uYcfhxJuWGCABNLH4IkopviPJio+BpeDUUEko1RHJWVaeG9NiGFJ8umY
EXgajigkhUICKWKPJe533pJMNunkk7HB6BNDZwVlJUQ35pZjhTuSFKSJRSYZpkkfGligjxle6B2U
bLbp5ptwjqUee0hVCWNGWf5DGpckkglimkQCamCEfgoapoBcIqlnnIw26uijwlVpJVFLqZdZnqih
CaaZ//XH35+DXkghqEOmWWapa0Kq6qpLSsFqbZLa/8lRpQ/iqJyW2Z1qaKBddvmlqD+qSSqguga7
6KvIJqvssnIuJuukV3aUEKbKFRtkn8Z+iq2Rhfoq7JkhYsjsuOSWe156ztLa0JQxAiUpTISaWqGH
nmKr7YD0+llvvZwmKmaLAAcs8MAEx7SpTgdDCGzBDDfs8MMIJpyTxIxRDHHBcFys8cYaW9zdwhyH
LPLIkOnWcJ4pmeuaMyq37NoXLg9G8sw012zzzTjnrPPOPLP0Qc8YvQtwrUAXbfTRX+kmdNBEozun
TkKj/FRG08Zs9dVYm9sUSkur1DVNUZtcI3tZl2322Y6u++DTNc5Ikqzsti133DRWfStTzj6F9t58
m7nrDqMXCX0nlUONtPRDgyOe1FlY2gNIdh9VKlLflFdueXNutxst1RV1ffisDFG6+HooM74Rrpen
rrqyjdhzy3SWgiSt2jN6TqtTjM8eO7S2Qr51uwetLvzwxP8VOud1zh4juscrnlTgmYV9t0iSH1v8
9dhnr9bxTK8bFLu8dz866ONvPmnj0z9Vvfbst095Sp/XLVX43AMPLdvzR0Un/PmLxFjTSAugAAfI
PKt8rSYABEsCCcjABiIoIAAh+QQAGwBdACwAAKoAcAIjAAcI/wD/CRxIsKDBgwgNAgCQsKFDhQwf
SnQYcaLFixQxatzIsaPHjyBDihxJsqTJkyhTqhy5cKXAli4rutwoc6bNmzhz6tzJs6fPnxxhnlxI
FKjRmkaTKl3KtKnTpxztSZ1KFSjVq1KhJsTKtavXr1QBgB1LtqzZs2jTql3Ltq3bt3Djyp1Lt67d
qVrz6n25l+eKvoADCx5MuDBgpIYTK17MuLHjxzMRQ55MubJlpUSLUqwoNGbmgZJBfr4MuADp0wWx
oF498avQzgdhfwRLsGbE0B85W7zLu7fv38CDCx9OnOyk4sh9v+Y8OjPDls6Zj/4Hkzbo2J9hNqe+
XPN1vtRrh//nm7y8+fPo06tfz7591YTLsb9kzv32c/rzMUq2/53v6/Hg9XebeLqxZiBCahyo4IIr
ueYcQtrRF198BlkH2nQD9heeTM+JV9t233X4j3sklmjiiSimqKJw0Nn2IHcXwpgfhQVZGBt4HBKo
o4YAbuihiCsGKeSQRBZpZHIRxpifjDBOiF+NXzWUYY7X5UilhiLiON6RXHbp5ZdgcklhhPzNKKF9
+Nlom5ZY9pglbFYqCWCYdNZp5514XnXFXJ2R6V1RLSoZnZI21tcnnJpRCWhBL9YHYEV5RirppJRO
epNsI0Z5aUeQVurpp6CGeuKliBW6Em5SEiTqqqy26upbPTWRutR0GqHK4K245qrrQ6/2ClcRvgYr
7LBc7Wrsscgmq+xIxDbr7LPQOrvstNRWa+212Gar7bbcduvtt+CGO2200RJF7rnopqsumM6t6+67
bbkA77xxLUTvvfjmq+++/Pbrb5d5/CvwwHQqYPDBCCtA8MIMN+zww8l5APHEFFds8cUYZ6zxxhyr
K+7HIIcs8kYBAQAh+QQAGwBdACwAAMwAcAIjAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF
ixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypyZUg7Nmzhz6tzJs6dPe0CDCh1KtKjRo0iT
Kl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih07lQnZs2jTql3Ltq3bt3Dj2vNJt67du3jz6t0L
U67fv4ADCx5MuLDhw1H5Kl7MuLHjx5BZIp5M2TCGylzPYd7MubPnz6BDix5NujTiyKhTq17NurXr
17Bjy55Nu7bt27hz697d0rTv38CDCx9embfx48iTr0ymvLnz59CjS59Ovbr169iza9/OHS/S7qyJ
i/8fTx44+NXl06tfH/i8+/fw4zvkR5D+QPr88uv/Z/8+f/35FQRgfwPiJ+CA9R24338ACoSgggQ2
6OCDDibo334B+jdhhvX1xx+DGFpYIYgeymfiiR8h5eGKHxpE4IgIsdiiiDC6SOOHJc5Y44z2yZij
hjC++J+FMt7HYo5F4iigQew16eSTZCn04pQx8iglkTbeeCGQWv4oYo9YHmTgiD5a6eWWFSKJppJV
ouhmSi10R2WaVQrZJplZcpmgnV0uJGSZYpq5JJuE1rkmkGMWOuibjDba0HdggklikgVCGGGDJVZq
5YYZakqhkQtS6KmGHJKK55l44vhgpEFKWBCUsMbZKqtXhI7pZaKoSrqjjrwGaaifi7KZJKJ0hqnk
pYsa+COuve46K1LkPCttrMDOeeumd/K547KuLonqtnsS66KEurZIZabJKlqsurs66u67DzFbrri5
GqunmuHmeyO6h87LK7OpTlgjvwIvK+i/epJEArwM5/YdwpwGiK6m905KosX8rqrxgh2G6i2CE+8p
cYeglqqjxKIG+6l907ZMnAAuN9XwzDRP9wltKhao88489+zzz0AHLfTQRBdt9NEFxqz00s/W3BPT
UEfNntNU7yb11UtVrfVtWGMdEAAh+QQAGwBdACwAAO4AcAIjAAcI/wDtCRxI8J/BgwgTKlzIsKHD
hxAjSpxIsaLFixgzatzIsaPHjwwJihxJsqTJkyhTqlzJsqXLlzBjyhwIsqbNmzhz6tzJs6fPn0CD
Ch1KtKjRnQAAHF3KtKnTp1CjSp3qM+lBqwaxTtSKMKlXrhjBdlV68atXh2I7ps34teZaqgrNYn3L
kS5ch+zu6j168t/av2TRBtZqN27gsW4Pfyx8VTFVxhUhP3Ysdably5gza97MuXNBv2nPGqbcOKvo
uW1NoxZdOiFq1asJk00NGvZs2q3HpjYL+nRbubZNw27MGjfi3sWNM6QNHLls36WbOw8+3PBCq9J5
Ox+8W2l23p7Di/8fT768ZomsdV8HXB0799rwQ1Pu7vp97df336c/rj7+7ejPCZeeewLq9591vRUY
WXL/QScbfPk1qNiD+PGHGHT1JZifdQ7at9eHIAbVV33zyVcicv4BiCCJ3VUo3IsEZkghadt5Z1+F
Mb644YUTGvgQjjZShN+MKipo5I655biedjmK1WSQMvoonHlUVmnllVja0x+JSzbU4m1MJrfech7a
NqSYRJK54pm8cZVma1/6xh6ESkJ0ZpFIPkknlMR9OSaHN7YpJY94WkVSE1kmquiijIqkWpej/Sjn
gWpCaGGfOmaaG4x81nnpnpyuCCpYpPL5Z4aj0rgkhnl26mqqqFb/+mmrsB5Z6KuN5qrrrp1JKmus
gsWmY4wuboqppaDu+Nqbog57ILPMKvtqsaHaqmmmer5JbLY9FunkiWmeFS2tq4Vo7rk6jYjUYW4y
N2CpgnI6aaAPToesbr95KC59fRYrLHUojvaqvfIRemRs3OULZ5zHAnurmcmGGTF4vFZs8cWWoatx
T5Jt7LFUhmIs8sgYf2zyTx2frLJRKa/s8sswx+ylqjLXrJN2Nues88489+zzz0DDrK7MJBdt9NFI
X0xM0jCdwLRnOT8t9dRUV2311SNHjfXWXHft9ddeR8QPQvyUPTbZZh90ttr/mO12Qmu3TXbbbo8d
t9x13x303nz3/+23zHGvLfjcchNukN6HG473QoMX/vfjkEcu+Yd2s52442zfHThDg3fOueOIYz75
6KSXbrpEI1Z+eeF6q2756nBnLjvjoH/+T0nvgL0ZO7r37vvvwK9UO91pi7644qGzrjzxxcOet0Ij
vZN78NRXb/312JM0/Oati775554bn3jjDREkffbop6/++lUzfzb3CrnufEOuqx56/Q8JdD77/Pfv
///lcYjmMPc+w5EPdrELH+Iadz+DSO90EIygBCU4wLqhrWxww2Ds6LdB98kPbxZE4ARH+JEckPCE
URlazNjHBwC68IUwvIwA80bDGtrwhjjMoQ6fh8KgraGHQFRZKzYsokKhxfCISEyiEh0VxCY6cWdL
TNoTp0jFKsLMCXcpohW3yMUsRvFqeqFZF6syxrig64tHCwgAIfkEABsAXQAsAAAQAXACIwAHCP8A
7QkcSPCfwYMIEypcyLChw4QAHkqcSLGixYsYM2rcGHGjx48gQ2LsKLKkRIIoU6pcybKly5cwY8qc
SbMmS4ck/+XM+ZCnTgBAgXJk6LNnUKFESxYdCXJpUpMNnUokKRWq1YxUK1Y1WXTr1a9gw4oVuROh
V4M+z04lS1Ht2Ldwn2KNS3ei24N36+rdy7dvw5ZZs/5EOhhtULMKBR81TLjjYbSMHf+EmLjw4IiL
dU7GjJQzZMuX8RJGDNrsY4iYEXNW/Ngz6s54NZ923Hpy6NC0YZ823Xm2bd2Na9f+zJvq4cWpP2eW
Hfu18d7HSafWDfooT5vYs2uveW+79+8uA8f/Lqu4cmXJpJVrVk++a+Ly6yEHH09+vOrm94kvdN++
eXL57vm3XmPyqbYUeszRh59+8Q1IG4ALQlggg5SlZd+E7EVYIWUXstcfhg3+A96IJJZo4okwDahi
g/9paJ1kCOoH43n5vYecdDKyWCOIOkrVIk779YhjfUEKGOOMHZonXpI8NYkjcS1aWFaCUYUYH5JT
Ilmlk0zyGKWOCKEo5phkllkQkEu+yJiLcjVpnXIEEmleeiuqOaWXa14GXZG7idYniF9SKWhxBOYo
6I9vXilkhFyqByWYb2ZppZ5WlpfbcD9GhuiOWgIKpl+ghjpWS1Qm5yOF/DEYoJE70mlojIbi/9kq
h642OumXkspJa365cvrkoZ+q+uuSnva6a6aWUqiihUkumqGvdxpk5rTUVotdT4oeqWilQcJq7LKz
ovqkrrqW6qyUjIrWrbrfDroglkP6atij5O4KKX64spveqkIxu+29yhoXosACD5rvvJOKqrBJSyws
rJ/PmUbof5dG5l+hmR0Y6b6rHZkxh7OFHOCfhY3cL8AfEzWcbMtVPPDJ87ocrcW3/dtxxIEmHF3N
MLPom7Il07zz0ANDCnNeDiedNKlKN12k0/bqhTTUCbfV19RRh4SetVx37fWZVIctl9hYsyW2RViX
/ZHaGmpd9dlw98V03A6z/dZofNld91B5m/+t9Z9fBy54mXQXbvjhiCeu+OKMN+7445BHLvnklFdu
+eWYZ6755mLPzZTTp/KttN5nk865QoOnrvrqhFt1lulWVym6XXHlBTuQSp0u+9u693625xfdnvvu
czVtO+LCH14268w37/y1OK08HcbCzSgy3s4B+Bz2iabsIPXAiXd9WtdLSLGNFrecMcmuxVld9TQX
DV3EQt83f/z0wSjz+8DhFj/JvgtgqAATL9uAS0EIBBbt3JeuLhHrgBJa1gNtJSU5NQpWxXLVb9Dj
GmBhz1HqytEEeySYd6EmgR/y4J0OFqLnufCFMIyJsdq1qXotUF4mnGEBPeXBWmlwU+7yF7T/foiv
DDbrV7Ey2BAb+DAeGlFWPWRIDKdIxdVFr2UmjKIDNUgoZxUtf8LRVKcCxcKXrW9nrEIflG4ERu4V
UYVshJi3Jpanes1MTXTKGRzRSK/ufVCAgOQLAWl0r3KV0Sl29OERE5SqLmnxi3n8YqbGtcTdJeuI
0Zpj27boyE2KMJLlguQkI8QSDVTxlKhEEe6eRUP51Qg2tOpZqS6YsxJCUIEsxJsFgXgrAV2JYnp8
1LOe+MsmnutcwbwjDh/Jy1wCLZDQFAupvHezi8HSkURDHxlluSaXyehnZ2QgnJAlMiUCbTf9Opo6
P1jCMdaPNytiVDn/dzI33c853mqN+q6pnS+eFSqVAA2omNY2FgzCLW1QgV3yKne8aDr0obxz20IL
OrumuA6iawkeRjcqwOQtJ3F3+ajb/vZHjj6TeCZN6e9uotKWulREAo2pTGeKkpfa9KY4zalOd8rT
nvp0o8Dz5E+9AsCf7oWmzQMFUpfqkivGEW1F3ctEtSLUkxYPdFTNaPROGDujetVxM6NdVXVny7E9
VG+6nOpX10qXgAAAIfkEABsAXQAsAAAyAXACIwAHCP8A/wkcSHAgAIIHCypUmFBgw4UQI0qcSLGi
RYsNH0LUeLGjx48gMYZkqBEAx5EoU6pcybKly5cwY8qc+PCgyYw3GW7M6fCfSYcJbf4EOlRoUIM6
fQ4teNMmQp9KoRblaZSo04xMczY1qPWpUqxVrXLcKnUpUqpRv+K0yvXnVp5My46F2jMo2p50yZKd
ybev37+AAwu2R7iwYaRcz3pFHBfx1LpY4y51ivdpZMaVyybOLNSx4sx4a9LFTDlvWqmLOZ8uCfby
6NKoG7uGjDk2atG2YY/e/c+w79/AgwsfTry48ePIkytfzry58+fQl1fEXTc1b9WvP4O2bfqkbuui
qe//hn009HXT2lXPDQ/ecvv01MlfL79xvOzuXkvrFi+4v///LJEhIBl/gQCgSuIZBdd29mVXnWNv
5XeeXXOlJl9bXXlmnnfqNRbaZPbxx15tI2InV4aLLQjffUc1BWJ6DR4o44w0DmgjgTTmSFGC59WG
3WXylYhfUiR6yB1/DUb2HXoPksaie0WuaGGM2VVo3XxUOsiddvtdqeOXAPYy04Bgljmck1JOiRuQ
ISYWX32zleTmlFKyuRB9W66lZJtAGXmhkzw2uSWT671XpYRg+YlXdIw26uijkEYq6aSUGofmh2Yh
BNdebLrY1pE+YnonVW5lqVeK+tXH1qoZbppkqVkV/wXeqZqaRSFOk4UlmaH53YWeXq72VumwxBZr
7LHIGgvmSRcxW6aRNDorEkjSPjtSsthmq+223Dpq7Z0jVWutuP2RK5G5RH6r7rrstusuSGd+iW66
7847017hfpTpu/B26++/AAeMLb8EF2zwwQgnrPDCDDfs8MMQRyzxxP0JbPHFGGes8cYcd+wxxxQr
BEbIJJds8sko+/Xxyiy37PLLMMcsc6Qp12zzzTgrbG/OPPfs889AA7YzzjMXbfTRSCdtNABKTxr0
01AHpgLBb0R9rtVYZ6311lYPnXNhzDQt9thkl212dEyfrfbabLft9tvFpQ13c1zXbffdEHvNc9sK
zGLt99+Acyt34IQXbvjhiD86eOKMN+7445BHjvfklFdu+eWYZ6755ntH7vlzRHwu+uikl2766ain
rjphUbTueuurxy476ZxL9Prtteeu++68967wE9Y24/vWsxdv/HLNHA95QAAh+QQAGwBdACwAAFQB
cAIjAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsBnHjyBDihxJEuK/kyhTqlzJ
sqXLlzBjypxJs6bNmzhz6tzJs6fPn0BjNjv5KKjRo0iTKl0qs6TTp1CjSp1KtapUj1azat3K1R7T
r2DDzlQktqzZs2h9Dk3Ltq3bt/+6yp1Lt67duxyx4jXYaq/fuXADCx5MuLDhoGsPK16sODHjx5Aj
S56s0zFllJEua97MubPnz5otgx5NurTplEFOq17NujVnha5jyz77tzZeF7Zzh5zNu7dS3cCDC8/t
u7jx48iTK1++uV8/5tCjS0+r0HlK6yixn3T+PDv379r/gf/f3v16eZXfyYPnznK9+ZXWw5NvPx69
fPHp8a+/b98+f/X7mceed+epJ2B47hE4oH8IntfgfHENJ+GEFGb1knb54SdgS/ctGF+BGnIIYogu
YVheh88tCGF/Kxr4XoskXpghdv+9uKGLGerXnYc0nuijdzfqt+KMO4443ZFIugRbjz2+xx+K9MFn
ZIxAylgllRrm+KSDP5oIU41A5niliFKyqOWA8jU55I9jkshkkVVWKOecdIL0ZZFqzrcli2Xy2aef
Ua5Z5odttuill1beiWWhgO5JaJYpjviom2wuqmZ+iNokSJKcIrcknnCGKWmB/+2nIqAw/pmpqJQG
KuiDJU7/ySqZiTJKaJOTOllppnuGiCmbdQYr7LAYQaonl5aSaiSUtKJqJrL9XTrqmLnq6KqMpcoK
o6OgHhtlnr5C+2y4rUZIrG2RnKuuSXe+aSOzjGJZY6+xngrloaOeaSuIYPr3Z62pGmutwNGKWd++
CgJoY6cMN4xttwqeSmW2/zrbL7j3ckkvgxJvq+2BCwOcbLkE62poqAGb6G68Dk9nR8sMKnwlvAg7
m7K2vPIbKcgVz7yssjQRGbTO4waaJso5h9zgyjA37bSLUB+NKo/yTrnxtauCK2TPE++car+Qaq2o
vzj+HDXGKFPqo8ZBLvr029HB6rHN9dHMc8gVq0y1xdO+/3gw3vTx+Pe1B4rr599SSx0x1kDD7Xhv
sD1uGNidrmv55epKPvnHlWPu+ee2aT4Z5aKXbvrpqKeu+uqst+7667DvFHnstMMM+u3B1a67w7j3
HjrUOqoYYKwLf+he4sNzjLiYU2sst6jMF56v9NNHzPnyXJtabdgHD17o0s+7He+bxxMdou/obyWT
8GzH2LHaXZoNIenfq0y8z2t/7bX4qwK/NNmCqheBgCe+uRWsWVtqnOAMeD8AtolZ9NsdcialOMUZ
DU1pe1cGY2I3MKGtaCYLWABn1bUQkoxwTCtgCQ/INSnByoL9i5kMlWa+CErQOBQkmt2q9CsREsyG
FgTc/CQqZUISzouIPzRfElnGrROiUId9UxS+LsiyB+7Pin2y4Q1NExAAIfkEABsAXQAsAAB2AXAC
IwAHCP8A/wkcSFBgv37/Dg5UWFAhQ4IPGyJMeHAiw4gSKS6cWLAjRI4GQW70GLKkyYwYNT5MOfJk
yZUiNb7kCJOkTJQIa9q86XKmR5YdHdLMGVOmzp0YhQYVmfJi0Z1Qo0qdSrWq1atYs2rditWe169g
ffZUGROoU6chK1b8CFKtWqhJiwJN21Yu0aU35x4Vy/OkUr9P+/rc+5NpWaJuLQYeWZMl2rF4WzY1
nPgx2MuYM2vezLmz58+gQ4seTbq06dOj+U4WbPYuWcgb61qNWxiu4dqrH5PUzXho5Ncm5woGzrv2
R7x61+5WzPd4c5tHVzt3zhC19etfrmvfzr2796+2JR//Zh34LUXCEmVXpf17eUbk493aVj69uFHf
54UP/wsc+m2cUbXW236+6QdYYu+1RN1iXDU41RckceHghBRWaOFVnOWnXG7jLXcWfriBOBV7Cbo3
3XEcwhYcZeZJV9mKSNnFk3n+lficiSW+5ViBDMImnYLiCfTdkJplR+SRSCbJXXgwLmhjeoqhB5iK
OAI53JPspajiXjqR2KWI7d3HFoMkDhigjLExd+J5Iz7141gGXiinQBDOaeedcpKBp438sTmjcPT5
eeWXsx02VI+THQokbwIGiWJdapq5JUyRpsXkifbl5SZllnYaW5tV9uRij3tyVWepqKaqakec0fZi
moHW/7joi66+KutSsd4KpaH0lWlln2TJ96trVu665pXFaniosMIahymNbJ0JLZz/OfmPkkcaie22
3HaL2arghivuuOSWa+656HZ0arrsFuQJuhm2K++89NZrr7nedqdtvvz22+29AAcs8MAES+Uvdgcn
rPDCDDfs8MMQRyzxxBRX3HDBGGes8cYcd+zxxwNZLPLIJJds8skop6zyyiy37PLLMMcsc2gg12zz
zTjnrPPOPPfs889ABz0VA0IXnfENRiet9NJMOzjz01BHja0GGkht9dVYZ6311t5RzfXXWTct9tgd
U0322XNOYyfYbLeNtddux80y2nTXDbAGduet9958913t999zyi344EfCQfjhiCeu+OKMN44aLI5H
LvnklFdu+eWYZ6653IB37vnnoIcues687Lnu6KgrvfnqrLfu+nWpxy777LTXbvvtuOce8uspJ8H7
78AHL/zwxBefZEAAIfkEABsAXQAsAACYAXACIwAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGi
xYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcyVPlv59AgwodSrSo0aNI
kypdyrSp06dQo0qdSrWq1atYs2rdyrWr169ae4odS7as2bNo054Ey7at27dw48qdS7eu3bt456rd
y7ev379kAQCGmRdrmsJKSSBezLhxU3+OHQMAELmy5cuYM2vezLkz1MmUPYseTbq06dOoRYNOzbq1
69ewY8sOunq27dtDJ2MO/ZT3V99zKYfW3dU38KLHSQvPnBx3bOKjawtt/hkodabLfwK/znu71uzV
kWP//we+OG2lxqVSvx4+N3nn8L2Clk6e/XTu9u82z7+Uf9Pu/1nXln/uVbUcge29lxSCRq33nXgM
xichUtBB11uEiw1X24bEHahbhR1+qF2IFio43HurzaddfSWmuOGI25FYn3UdKkijhjjiCOOKKu5I
FIcnZnciizzCmB6RPgbJYnf0EQlkkjKCmCOUGE44oUIWhmjkjVouyaSRwklJIog/LRSUQiYKCCCP
Qw6p5ptFrihgmuABWOd5cqJoI556pnleeUf2KeifNpb345wotpknm3mmZ+ebSsa5Z6CENurnnY8u
emZfAQy20lFZajjjjCWOSpuoTn4YJo1IsoqVm3dK/6rokoXWumaRB9aKK6K66lnqfELKqSKgfGJ6
qoh2coeosUKmuGylgq4qa6+mGucsmJd6aaurVnbrFJbWjmiquPflhmqXqrJa6qYJsXuQn9HCmW2m
8d7q672WxmqprJTOCymf2067a6P7PftorgJPGjC+xmpKqsG8+lvsnuP+4+nFMIVKbo+/5ojuuWEC
W7FQZgKFJqy9xhppvfJ6J2zK8T4rqcJxrozwovTqe3O/Mg+6Zs68NtznztS2bHTN09IbMcZMs6Rx
xemWS+aoH4+8rsloYo3QtT7X+LKJHIKN8sRgb2vvw7h2POuUhj6p65j1Xj2p1/vSam2WPiL55c/0
Sf8HN9Vet0m3qE1a3PThJ01NKuHHRR024OKS2XGZWVOOkLeYK6cZ4pxrBKrIrvaoLeAcg7xx6eZm
rrqEha/uemWVn1ay5Z3XbvvtuDP9+u689+7778AHL/zwxBdv/PHIJ6/88sw37/zz8MUOalRVBlc9
Xldf35ncbmnPVu7gy9Rb0co6/NtUyYneYMQLjklg4+w32Pp4Z6u3oHg35p/3+MfaVz+FeNsS9JAn
venEb33miwz8xtMel/WnQBRD4FW8Z0AK/ehWQsMQz6bXQHLVKnwgdAkHleSiGqkvVVK6j7RaBaQg
+a1JbnPYC0MmNgEeallq218JmeRA/TnpXzTU0f7/WKiqGAmRbBTrod5myLMZ/nCJcsPgAQf4Oyy9
TGcxq5u+JJZEsx0tXxdEWaAyeEP2jTGCUjzbi2aWrKTJC0IAA2MZMRguOCYsSW8E2v/GWJvBuCGE
askV0QZGM1upT1GgG9a/7qg094jsjECrYND69kYtjs6RioRY0oaVPq6hsZKTbJEktxRJTHpSj2aU
JIAAyUqUTE+QMNtiGvG3MjniK4sLO1QPUampBVKrkbG83y6NBsxxKc2XhoqfEiH5RQMO0429hOD/
qMiUEMTnZHPCoiw1STObLYxo9iomMSdWyk/2LJeWnKbQvsnOoOVRmhGUoS2ZeUdoEQuahUQiZVrJ
BE+SBAQAIfkEABsAXQAsAAC6AXACIwAHCP8A7QkcSPAfgH8IDxpcmBDhwoMKGTac+NBhRIYKIVqU
qLFhx4oUOUp0SPLjR5ERTZYkGTLlSo8sRcIMudLlRZsbcbZ8CZImypg+M+bcSLSnSqAqbw6dOfJi
UZcEo0qdSrWq1atYs2rdyrWr169gw3qVmTGpTItHAahlKRTj2oRqzbo0GJftW6d03+ZFW9Zt26Zx
/8LVO9gnXbKE86bUW1cxYr+F7d6dLNlw48N8M0tOe9lx5L2Hy/69GThy6X9iU6u2F2q169ewY78G
Sru27du4c+vWjXe379/AgwsfTry48ePIkytfzry58+fQl1uNTp134urYs2vfzr07bdngw4v/H0++
PFbv6NOrX8++vW/z8OPLn0+fvvv7+PPr32+8vv//AAYooFRI9TYSf8EZyN510Sn4m1MGOrgbgwci
SNKAGGao4YaqxYTXXLmdJtxRzEnonIkRlsRYYgoGdpJtIrIl44fG0UiTicXhiBuAhHDoI1aP/Mih
h0QahpRyOhKXJJK49cbYUhxJCOJtUxZl5JK02Vhhg8cJ6eWXYP4HWmd1idhZhZeVOZRGaoLmpmlE
lZnmZCvS6WGdb455HYgQMpUlX4v1yRREjXUkJ549mUbYoW2RCZlnYz606ESiZRbmpZhm+hWMUD4F
JYR3dWqTUDol6ilISt3406B/psrTi6dG/0kplZ5OWapcTX2KWa1F/uTkaKtKGtSsNVlo7LHINmdV
qbESemZOpblqlkfRfmimlXNFq6uLm+Uqo588QUrts69CS2ah2wpLkbNraQkrn+q+qi2rVVZkqJwO
aarvvvwOxCm4Z8FKpKDrBivwpL1Ka3Cw3ybq7pZbEgxxsxATjCtcDKPZacGDKlzurQPb+xSWyZZs
8rHLbhzwWTOKmi6r2MaJ0ccvG0WzlQWn+K2tOHNsM84gnzStqRmv7KrRNTsp8079Nu30l1SGeidi
oCKqZ7tx3ltpZVRTzZmd3erJ9a+LqWjxkRyfaW276DqbttRjF+gri2YPFmhLZ9ud58l89/9tWxL5
Ted3eyQPbniO2z2t+OIYHq4fuY5HvlzhklduObJuCH755px3Dh3joIdun+ekl256cKKnrnpqhx+t
HuUVT2g4hbxhp3PLCcJ++u6Wa44ejq6np3ST5Ybb8IPEK5n8xGgzz2TzxQKH4+rUV9/h6yEaLzz0
tXmcfYLLjxi+b/We+GfI0udm/fpgsiPf1YXReTekhYI956Lo3ih/w+zOlH/9WxMXo2AiGtIgik1Y
w5uhKLW/vdgKa9liEdsOmLWtmUltAPRfqAIIv4qw74MgrIrCGrUwZkVvYby6EsuCBqw+wYtnOcMM
DA9EKJ95jFRJixm9dFhCle1wJzt0oWD/KPaWEBrxiCOc1ajaFC/HBCqB3prZ2kjUQ7tpzSTziiJO
4HWqLCrlbGxSzNBMlS2/IKyKTfTiCtNVQFnxD0pHjGPo/hVDKW6MT0PLW9poqKsU/iyHxbPhH5MI
M3BtkYwuy9sCmxe0kaGRkCIz4RlNyLtKWlKLM7MZyAD5x5W9cYZ5XFMfO/lCT9axkxrrYs2GJUgg
PvKEofRjGCnpPYFd8paly2Am+wencQEKY26KkTALBMWqjfF/9ftMjEIjyl8604kq6pkMRwasXT1M
gVOL4BODycQ2ms2CZoySxPKHy3JGzneyw4/uIke5dX7PnMmRozyrBz51wrOd1HEnPC80Vc/UfUKe
+0ROP8GyiIEa9KBGDGiXEMrQhjoUoNKkle1ul56HWvSiGO1X7bR0wvM5T6KBNFJy9LkfMSj0pChN
qW58R9HjcW8418xObzJK0yOmoKZPCwgAIfkEABsAXQAsAADcAXACIwAHCP8A7QkcSPCfwX8ADipE
uFBhwoYOIUqcaPBhxIoUM2qUaFEhwY8gQ4ocSbKkyZMoU6pcybKly5cwY8pEmWKmzZs4c+pcmRGA
z4QPfyL0yRDoUKIMMQoNivRnx4pNkUIFKjRpVaVTp1qsavTqxq9gw4odS7as2bNo06pdy7at27dw
48qlSHJr0YtDseq9u9coxoN2nyYd3BViU8CEEx9uuLOx48eQI0ueTLmy5cuYXQbO+1cx4s19EyPe
O9qz1NJO/fJdLfhf5tewY8ueTbu27dsqQee1G1q36t94VaP+DLgj7+G+IeJeznzgmebQo0ufLlk3
a+K9sV9H3vC4cOPcs3f/Tkq9vPnz6NOrh320q1Siga86hWp18eCs94ubPn2fq3z7nD203oAEFmjg
gQXOpeBbrYWF4IMQRijhhDYtaOGCDV6o4YYTecPhhyCGKOKIJJZo4okopqjiiuys6OKLMMYo44w0
1mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JI9Uujkk1BGKeWUVFZp5ZVYZqnlllx26eWXYIYp
5phklmnmmWimqeaabDbG5JtwxinnnHRK1OadeOap55589hlbDX4GKuigBvZA6KGIJqrooow26uh0
dTwqKZR1fpVOnTIs+E2lnHbq6USThrpTFqKWauqpqKaq6qqsPllIq7DGMCrrrLTWauutWn6q6668
9uorW7gGK+yslNjz67HIJqvsssw26+yz0EYr7bTUVntsQAAh+QQACP5dACwAAP4BcAIjAAcI/wD/
CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDiuxor6TJkyhTqlzJsqXLlzBjypxJ
s6bNmzhz6tzJs6fPn0CDCh1KtCjQkUiTKl3KtKnTp1CjSp1K9anRq1izat3KtavXr2DDigWabizM
qhlHoF3Ltq3bt3Djyp1Lt67du3jz6t3Ll63Zv4ADCx5MuLDhw4iD9l3MuLHjx5AjS55MubLly26/
Yd7MubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hzv07Mu7fv38CDCx9OvLjx48iTK1/O
XKbu59CjS1/avLr169iza9/Ovbv37+DDi34fT768+fM4C6EvOZ3uh/bw40teT7++/fv4ncvfz79/
+/wABijggAT61kiBCCao4Hf+NejggxBGKOGEFNK14IUYZqjhhhx26OGHglVoUBNIuSPicx2cqOKK
LLZ4Wi0uxijjjBYRQ+ONOOao44489ujjj0AO9MWQRBZJZJBPBQQAOw==

------=_NextPart_000_0005_01C7010F.16481B30--



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 kAE0UWUX059283; Mon, 13 Nov 2006 17:30:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAE0UWIL059282; Mon, 13 Nov 2006 17:30:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAE0UUTT059260 for <[e-mail]>; Mon, 13 Nov 2006 17:30:30 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.0; Tue, 14 Nov 2006 00:30:24 +0000
Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 14 Nov 2006 00:30:24 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>
Date: Tue, 14 Nov 2006 00:30:20 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAACWpPw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kAE0UVTT059276
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've been taking a close look at this and I've come to the conclusion that we are fine. That is, I can't find any support for that provision of pre-produced responses handed out by a key-less responder is violating RFC 2560 in any way.

RFC 2560 does not require the responder to return a successful response for all possible legitimate requests. It only require the responder to support the basic response format when it chooses to return a response. As I read RFC 2560, it may fail responding to a request for any reason as long as it returns a legitimate error.

There is no place where RFC 2560 requires the render to successfully handle a composite request. It only specifies how it should be done.

On the contrary, support for pre-produced responses is explicitly supported in 2.5. And as such it is obvious that such responder can't respond to all possible requests.


Of the error codes listed, I find that "unauthorized" is the most appropriate one for unsupported requests as it indicates that "the client is not authorized to make this query to this server". The description may not be 100% perfect but it is sufficiently good and the response is definitive and avoids repetition.

The response "internalError" would be misleading as it "indicates that the OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder", which may cause the requester to keep retrying the request.

My conclusion is that no update to RFC 2560 is needed to progress the informational profile for lightweight OCSP.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed and
> >keyless responders inherently differ. I am aware of two general cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several (e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [e-mail]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .




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 kADNsJGD055023; Mon, 13 Nov 2006 16:54:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADNsJmW055022; Mon, 13 Nov 2006 16:54:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kADNsHhF055002 for <[e-mail]>; Mon, 13 Nov 2006 16:54:18 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.0; Mon, 13 Nov 2006 23:54:11 +0000
Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Mon, 13 Nov 2006 23:54:11 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "Price, Bill" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: Sam Hartman <[e-mail]>, Michael Myers <[e-mail]>, Dave Engberg <[e-mail]>
Date: Mon, 13 Nov 2006 23:54:09 +0000
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccHeE/KbPJryS8sSM+aS+rqrtdjmAABDwUQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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 kADNsIhF055015
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the OCSP responder provide multiple validation paths in the response, one for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local configuration.

So I don't think this is a problem only for key-less responders.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [e-mail]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed and
> >keyless responders inherently differ. I am aware of two general cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several (e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [e-mail]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[e-mail]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .




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 kADNijJv053840; Mon, 13 Nov 2006 16:44:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADNijIv053839; Mon, 13 Nov 2006 16:44:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kADNihah053829 for <[e-mail]>; Mon, 13 Nov 2006 16:44:44 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1GjlTg-0006Tv-6P; Mon, 13 Nov 2006 18:44:37 -0500
Mime-Version: 1.0
Message-Id: <p06230904c17eb25c83ad@[128.89.89.106]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 13 Nov 2006 18:44:32 -0500
To: "Ogle Ron" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: PEM file format rfc draft request
Cc: <[e-mail]>, "Dieter Bratko" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:56 PM -0500 11/13/06, Ogle Ron wrote:
>I would like to know if the PKIX working group would be interested in
>shepherding a new rfc concerning PEM file formats?  I've recently
>discovered that there is no definitive standard for how a PEM's headers
>and footers are defined for a private key.  I've searched the RFCs, and
>ISO standards without any luck.

PEM formats were defined for e-mail messages, not files per se. I 
think RFC 1421 defines the last of the formats (we had a few 
iterations) for PEM.

>The issue that I discovered was when I was working with PEM files for
>PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
>toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
>to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
>PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
>PKCS1, both expect "BEGIN RSA PRIVATE KEY".


it looks like folks made this up!  PEM describes how to transfer a 
symmetric key encrypted under a public (RSA) key in a message, in 
1421.  It does not describe how to transfer a private key, because 
one would not do that via an e-mail message.

The term "PEM file" with regard to PKCS #8 is a misnomer, relative to 
IETF standards. Since PKCS #8 defines a format for private keys, it 
is not relevant to PEM, period.

Given that PKIX is a WG that focuses on X.509-based standards, it is 
not immediately clear that a document on how to use base-64 encoding 
and MIME-style headers to represent private keys is within our scope.

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 kADMjol5046161; Mon, 13 Nov 2006 15:45:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADMjo05046160; Mon, 13 Nov 2006 15:45:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kADMjndE046153 for <[e-mail]>; Mon, 13 Nov 2006 15:45:50 -0700 (MST) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1GjkYj-000Fmc-5T; Mon, 13 Nov 2006 22:45:48 +0000
Message-ID: <[e-mail]>
Date: Mon, 13 Nov 2006 22:46:07 +0000
From: Dr Stephen Henson <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Ogle Ron <[e-mail]>
CC: [e-mail], Dieter Bratko <[e-mail]>
Subject: Re: PEM file format rfc draft request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ogle Ron wrote:
> I would like to know if the PKIX working group would be interested in
> shepherding a new rfc concerning PEM file formats?  I've recently
> discovered that there is no definitive standard for how a PEM's headers
> and footers are defined for a private key.  I've searched the RFCs, and
> ISO standards without any luck.
> 
> The issue that I discovered was when I was working with PEM files for
> PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
> toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
> to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
> PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
> PKCS1, both expect "BEGIN RSA PRIVATE KEY".
> 
> I contacted the people at IAIK about this, and they agree that there is
> an issue.  However, there is no "standard".  Also, other implementations
> such as MSIE and Mozilla may behave differently.
> 
> If I've overlooked a standard, then please point me in the right
> direction.  If there is no standard, then is PKIX the correct place to
> start one?
> 

I'd be interested in contributing to or co-authoring such a standard,
I'm not aware of an existing one.

With one exception the PEM formats I've used in OpenSSL have already
existed in one form or another either through adoption from its SSLeay
roots or through test files we wished to interop with.

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: [e-mail], 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 kADM8bEJ041129; Mon, 13 Nov 2006 15:08:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADM8bAR041128; Mon, 13 Nov 2006 15:08:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kADM8aeZ041115 for <[e-mail]>; Mon, 13 Nov 2006 15:08:36 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27090 invoked by uid 0); 13 Nov 2006 22:08:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.121) by woodstock.binhost.com with SMTP; 13 Nov 2006 22:08:28 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Mon, 13 Nov 2006 17:08:29 -0500
To: "Price, Bill" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: "Sam Hartman" <[e-mail]>, "Michael Myers" <[e-mail]>, "Dave Engberg" <[e-mail]>
In-Reply-To: <[e-mail] >
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I prefer an error that tells the client to ask for the certificate 
one at a time.

Russ


At 02:46 PM 11/13/2006, Price, Bill wrote:

>I'd suggest focusing on understanding where responses to the keyed and
>keyless responders inherently differ. I am aware of two general cases:
>
>1) The request asks for the status of multiple certificates that have
>not been included in a single presigned response. Russ's example fits
>into this case. The keyed responder handles, but the keyless will fail
>for the general case. Some responders respond with the presigned
>response that includes one of the certificates (usually the first) in
>the request. A common situation is to ask for the status of
>certificates in a chain. Santosh points out some keyless responders
>anticipate this and bundle responses accordingly.
>
>2) The request is "well-formed" but asks for the status of a
>certificate for which the keyless responder has not prepared a
>response.  This situation will occur if:
>
>     a) The request is for status of a certificate from a supported CA
>but with a serial number for which there is no pre-signed response.
>Assuming presigned responses exist for all certificates that would be
>valid based on their validity intervals, this would occur if the
>certificate had expired or was yet to be issued (I am aware the keyless
>responders generally produce responses for certificates likely to be
>issued before the next generation of presigned responses). The keyed
>responder would give a signed "good" response. My understanding is that
>the keyless responder under the draft lightweight OCSP responds with an
>unsigned "unauthorized" error code.
>
>     b) The request is for the status of a certificate from an
>unsupported (or non-existent) CA. The keyed responder would respond
>with a signed "unknown" response while under the draft, the keyless
>would again respond with the unsigned "unauthorized" error  code.
>
>Some might argue with some grounds that these differences are unusual,
>unlikely, and insignificant.
>
>I personally consider the behavior in 2 of responding with the
>"unauthorized" error to be misleading. "Internal error" sounds more
>appropriate if I were constrained to the current error codes.
>"Malformed request" might be OK. However, the actual situation does not
>match well with any of these errors as they are described in 2560.
>
>If 2560 is supposed to encompass keyless responders, I'd recommend
>identifying the unavoidable differences and/or adding 2 TBD error codes
>for the above cases (assuming they are the only differences). The first
>error can be worked around by breaking the request for status of
>multiples into multiple requests for status of one cert.
>
>We've also seen some problems with client apps that can't handle
>presigned responses that commonly contain the status of several (e.g.,
>15-25) certs. The apps inquired for the status of a single cert and
>apparently expected a response for a single certificate. I'd suggest
>that some "must" or "should" words address clients' ability to handle
>the situation of a response covering multiple certificates.
>
>
>
>Bill Price
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Russ Housley
>Sent: Monday, November 13, 2006 11:46 AM
>To: Michael Myers; Dave Engberg
>Cc: [e-mail]; Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
>Mike:
>
>I think it is not that simple.  I think you need to say that support
>for one certificate MUST be supported, and that support for more than
>one certificate is OPTIONAL.  Then, the error is am indication that
>the requestor has selected an unimplemented OPTION.
>
>Russ
>
>At 06:52 PM 11/12/2006, Michael Myers wrote:
> >Responders unable to produce or acquire a definitive response MUST
>return <a
> >TBD error>.
> >
> >As to your other points Santosh, that is something I prefer the chairs
> >consider.
> >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: Sunday, November 12, 2006 3:36 PM
> > >
> > > Mike,
> > >
> > > What is the error case?
> > >
> > > . . .



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 kADLvCWm037747; Mon, 13 Nov 2006 14:57:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADLvC5Q037746; Mon, 13 Nov 2006 14:57:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dmzraw4.extranet.tce.com (dmzraw4.extranet.tce.com [157.254.234.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kADLv8ej037718 for <[e-mail]>; Mon, 13 Nov 2006 14:57:11 -0700 (MST) (envelope-from [e-mail])
Received: from indyvss1.am.thmulti.com (unknown [157.254.92.60]) by dmzraw4.extranet.tce.com (Postfix) with ESMTP id 71B5790C1; Mon, 13 Nov 2006 21:56:56 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id EDD0311F6; Mon, 13 Nov 2006 21:56:55 +0000 (GMT)
X-Virus-Scanned: amavisd-new at thomson.net
Received: from indyvss1.am.thmulti.com ([127.0.0.1]) by localhost (indyvss1.am.thmulti.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CrD6THdBfN8W; Mon, 13 Nov 2006 21:56:47 +0000 (GMT)
Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss1.am.thmulti.com (Postfix) with ESMTP id 78DB51208; Mon, 13 Nov 2006 21:56:47 +0000 (GMT)
Received: from INDYSMAILMB03.am.thmulti.com ([157.254.96.81]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 16:56:47 -0500
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: PEM file format rfc draft request
Date: Mon, 13 Nov 2006 16:56:46 -0500
Message-ID: <[e-mail]>
In-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PEM file format rfc draft request
thread-index: AccHTU1bcaMqepNsSiWqtzEW6jrlyAACSBUwAAV5G+A=
From: "Ogle Ron" <[e-mail]>
To: <[e-mail]>
Cc: "Dieter Bratko" <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2006 21:56:47.0447 (UTC) FILETIME=[9D8DEE70:01C7076E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kADLvBej037739
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to know if the PKIX working group would be interested in
shepherding a new rfc concerning PEM file formats?  I've recently
discovered that there is no definitive standard for how a PEM's headers
and footers are defined for a private key.  I've searched the RFCs, and
ISO standards without any luck.

The issue that I discovered was when I was working with PEM files for
PKCS1 and PKCS8 formatted private keys under OpenSSL and some Java
toolkits using an IAIK implementation.  OpenSSL expects PKCS8 PEM files
to have "BEGIN PRIVATE KEY" as the header while IAIK uses "BEGIN RSA
PRIVATE KEY" for RSA keys and "BEGIN DSA PRIVATE KEY" for DSA keys.  For
PKCS1, both expect "BEGIN RSA PRIVATE KEY".

I contacted the people at IAIK about this, and they agree that there is
an issue.  However, there is no "standard".  Also, other implementations
such as MSIE and Mozilla may behave differently.

If I've overlooked a standard, then please point me in the right
direction.  If there is no standard, then is PKIX the correct place to
start one?

Thanks
Ron Ogle
Thomson



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 kADJkdTT018352; Mon, 13 Nov 2006 12:46:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADJkdeG018351; Mon, 13 Nov 2006 12:46:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kADJkc8k018344 for <[e-mail]>; Mon, 13 Nov 2006 12:46:38 -0700 (MST) (envelope-from [e-mail])
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kADJkbL6031418 for <[e-mail]>; Mon, 13 Nov 2006 14:46:37 -0500
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0B667BF7C for <[e-mail]>; Mon, 13 Nov 2006 14:46:37 -0500 (EST)
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kADJkZxc031383; Mon, 13 Nov 2006 14:46:35 -0500
Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 14:46:35 -0500
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Mon, 13 Nov 2006 14:46:35 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-index: AccHTU1bcaMqepNsSiWqtzEW6jrlyAACSBUw
From: "Price, Bill" <[e-mail]>
To: <[e-mail]>
Cc: "Sam Hartman" <[e-mail]>, "Russ Housley" <[e-mail]>, "Michael Myers" <[e-mail]>, "Dave Engberg" <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2006 19:46:35.0013 (UTC) FILETIME=[6CFB1B50:01C7075C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kADJkc8k018346
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'd suggest focusing on understanding where responses to the keyed and
keyless responders inherently differ. I am aware of two general cases:

1) The request asks for the status of multiple certificates that have
not been included in a single presigned response. Russ's example fits
into this case. The keyed responder handles, but the keyless will fail
for the general case. Some responders respond with the presigned
response that includes one of the certificates (usually the first) in
the request. A common situation is to ask for the status of
certificates in a chain. Santosh points out some keyless responders
anticipate this and bundle responses accordingly.

2) The request is "well-formed" but asks for the status of a
certificate for which the keyless responder has not prepared a
response.  This situation will occur if:

    a) The request is for status of a certificate from a supported CA
but with a serial number for which there is no pre-signed response.
Assuming presigned responses exist for all certificates that would be
valid based on their validity intervals, this would occur if the
certificate had expired or was yet to be issued (I am aware the keyless
responders generally produce responses for certificates likely to be
issued before the next generation of presigned responses). The keyed
responder would give a signed "good" response. My understanding is that
the keyless responder under the draft lightweight OCSP responds with an
unsigned "unauthorized" error code.  

    b) The request is for the status of a certificate from an
unsupported (or non-existent) CA. The keyed responder would respond
with a signed "unknown" response while under the draft, the keyless
would again respond with the unsigned "unauthorized" error  code.

Some might argue with some grounds that these differences are unusual,
unlikely, and insignificant.

I personally consider the behavior in 2 of responding with the
"unauthorized" error to be misleading. "Internal error" sounds more
appropriate if I were constrained to the current error codes.
"Malformed request" might be OK. However, the actual situation does not
match well with any of these errors as they are described in 2560.

If 2560 is supposed to encompass keyless responders, I'd recommend
identifying the unavoidable differences and/or adding 2 TBD error codes
for the above cases (assuming they are the only differences). The first
error can be worked around by breaking the request for status of
multiples into multiple requests for status of one cert. 

We've also seen some problems with client apps that can't handle
presigned responses that commonly contain the status of several (e.g.,
15-25) certs. The apps inquired for the status of a single cert and
apparently expected a response for a single certificate. I'd suggest
that some "must" or "should" words address clients' ability to handle
the situation of a response covering multiple certificates.



Bill Price 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Monday, November 13, 2006 11:46 AM
To: Michael Myers; Dave Engberg
Cc: [e-mail]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Mike:

I think it is not that simple.  I think you need to say that support 
for one certificate MUST be supported, and that support for more than 
one certificate is OPTIONAL.  Then, the error is am indication that 
the requestor has selected an unimplemented OPTION.

Russ

At 06:52 PM 11/12/2006, Michael Myers wrote:
>Responders unable to produce or acquire a definitive response MUST
return <a
>TBD error>.
>
>As to your other points Santosh, that is something I prefer the chairs
>consider.
>
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Sunday, November 12, 2006 3:36 PM
> >
> > Mike,
> >
> > What is the error case?
> >
> > . . .




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 kADGjoVu092887; Mon, 13 Nov 2006 09:45:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kADGjoQg092886; Mon, 13 Nov 2006 09:45:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kADGjnsU092879 for <[e-mail]>; Mon, 13 Nov 2006 09:45:49 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26756 invoked by uid 0); 13 Nov 2006 16:45:45 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.121) by woodstock.binhost.com with SMTP; 13 Nov 2006 16:45:45 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Mon, 13 Nov 2006 11:45:45 -0500
To: "Michael Myers" <[e-mail]>, "Dave Engberg" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike:

I think it is not that simple.  I think you need to say that support 
for one certificate MUST be supported, and that support for more than 
one certificate is OPTIONAL.  Then, the error is am indication that 
the requestor has selected an unimplemented OPTION.

Russ

At 06:52 PM 11/12/2006, Michael Myers wrote:
>Responders unable to produce or acquire a definitive response MUST return <a
>TBD error>.
>
>As to your other points Santosh, that is something I prefer the chairs
>consider.
>
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Sunday, November 12, 2006 3:36 PM
> >
> > Mike,
> >
> > What is the error case?
> >
> > . . .



Received: from [59.191.106.121] ([59.191.106.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kADDTLqH064173 for <[e-mail]>; Mon, 13 Nov 2006 06:29:24 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c70727$ac3a2840$00000000@2ad99fc5d610492>
From: "failure waltz" <[e-mail]>
To: [e-mail]
References: <000a01c70727$ac3a2840$00000000@2ad99fc5d610492>
Subject: Re: LunX marjag
Date: 	Mon, 13 Nov 2006 21:28:57 +0800
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7076A.BA5D6840"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C7076A.BA5D6840
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C7076A.BA5D6840"

------=_NextPart_001_0008_01C7076A.BA5D6840
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Tuesday, November 04:02:21 PM
  Subject: LunX marjag


  Exploded minibus eastern versions.
  What compatible see Only kernels supported or amgseba. Ba bd bc =
Advanced Search df. Heart Attack Tribune or raquoin am Retief Goosen. =
Rutherford nj oddest is calls.
  Sitting behind and want to.
  Globe Bloomberg a Atlanta of Journal Orangeburg Second bid?
  Was nicht ein gehrt is amfranzf! More Subscribe now About faq Contact =
Sitemap in Privacy or.
  Amdevone di Tutte eo Gnunix amkernel in Risorse.
  Ammetalgod of Russian svyatogor Laitr Keiows achumakov amfrk dansk. =
Whitney fall usa!
  Estados Unidos is France India or Italia or Mxico Nederland.
  Need info you or start install am place.
  Sentinel Things doesnt fit above bastion. Guests Developer ever am dec =
agelmar animeotaku Asid aviadb bernied.
  Keybi kicker ld Lunx marjag metv nieve.
  Ld or Lunx marjag.
  Citizens choose plan Central of! Whitney fall usa!
  What compatible see Only kernels supported or amgseba.
  Kids preapec rights Boston a Bangkok Financial Expressall spend =
billion a. Alles was nicht or ein gehrt or amfranzf Deutsche Tipps.
  Street kids preapec in rights Boston of Bangkok Financial a Expressall =
spend. Mock is took beating am banks remain am boxoffice draw.
  Placement is determined program am.
  Street kids preapec in rights Boston of Bangkok Financial a Expressall =
spend.
  Has been called illegal West opposed.
  Agreed naming Mohammed Shabir head next imminent is Jerusalem =
candidates!
  Select topic Appliance Repair amp a Shopping Bathrooms in. Var format =
disp showeltid hideeltid return doadv falsevar sectid.
------=_NextPart_001_0008_01C7076A.BA5D6840
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Tarrant" hspace=3D0=20
src=3D"cid:000601c70727$ac3a2840$00000000@2ad99fc5d610492" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November =
04:02:21 PM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> LunX marjag</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Exploded minibus eastern =
versions.<BR>What=20
compatible see Only kernels supported or amgseba. Ba bd bc Advanced =
Search df.=20
Heart Attack Tribune or raquoin am Retief Goosen. Rutherford nj oddest =
is=20
calls.<BR>Sitting behind and want to.<BR>Globe Bloomberg a Atlanta of =
Journal=20
Orangeburg Second bid?<BR>Was nicht ein gehrt is amfranzf! More =
Subscribe now=20
About faq Contact Sitemap in Privacy or.<BR>Amdevone di Tutte eo Gnunix =
amkernel=20
in Risorse.<BR>Ammetalgod of Russian svyatogor Laitr Keiows achumakov =
amfrk=20
dansk. Whitney fall usa!<BR>Estados Unidos is France India or Italia or =
Mxico=20
Nederland.<BR>Need info you or start install am place.<BR>Sentinel =
Things doesnt=20
fit above bastion. Guests Developer ever am dec agelmar animeotaku Asid =
aviadb=20
bernied.<BR>Keybi kicker ld Lunx marjag metv nieve.<BR>Ld or Lunx=20
marjag.<BR>Citizens choose plan Central of! Whitney fall usa!<BR>What =
compatible=20
see Only kernels supported or amgseba.<BR>Kids preapec rights Boston a =
Bangkok=20
Financial Expressall spend billion a. Alles was nicht or ein gehrt or =
amfranzf=20
Deutsche Tipps.<BR>Street kids preapec in rights Boston of Bangkok =
Financial a=20
Expressall spend. Mock is took beating am banks remain am boxoffice=20
draw.<BR>Placement is determined program am.<BR>Street kids preapec in =
rights=20
Boston of Bangkok Financial a Expressall spend.<BR>Has been called =
illegal West=20
opposed.<BR>Agreed naming Mohammed Shabir head next imminent is =
Jerusalem=20
candidates!<BR>Select topic Appliance Repair amp a Shopping Bathrooms =
in. Var=20
format disp showeltid hideeltid return doadv falsevar=20
sectid.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0008_01C7076A.BA5D6840--

------=_NextPart_000_0007_01C7076A.BA5D6840
Content-Type: image/gif;
	name="Drag.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70727$ac3a2840$00000000@2ad99fc5d610492>

R0lGODlh9AFcAof2AAkAAIwAAQZ5C4uNBAkOdHMFdgCGdrvLus3nuJ3K8TYoDlYZDXwdAJYdALYa
C+oiBQg2AC02ADs1AG1NAHM9Dp1HAMs/AOxDAABuCSBYAE5UDVtSAIJtAKZrBrdsAOJhAQ57BBSM
CDmOC1WBB4OIAJ2HAMSMANOFDgmtACapBT2dAFWgAH+bAJmkAMilBuGXAQDEASjBADS7AWm3AIq9
AJfABL7AAeCxAgjjABTXCTneAF/jCX7fCqXoB7/pAOHrAAAIRBEASUkFTVsAN4wASJIKMskJOtYA
OQEeOScWTDsZNlwdMoIXQKwsQMMXQNcZNg44Ohk1NTROM1M/MoA/TadBMrdGS95EMQpjNiJpRkpk
TmtbP3tiAK1qMsJSOdhTQQ53QymBREd2NmGEMYN+SJaOQrp5Tdd2SwSURhmhOkGkSVacS3+mNJOg
PbacRdmrQAzGSRu9PEXMQFrFP3zJQ5KyTrq2OeyySQjmRCjpNjraPmPgTojRSaTnNMniStHpQQED
fyIKeEMNdloBgIwAgpYAercAgOMAdA0WeCcSeDYSiWkRhokZjKAWes4Th90lhQtHjChGeDZIjWRE
eXJMc5o4dLdOdtNKjQBYhhVYcktajmZndIxghqNqi7tocd9adA2OfxuAejZ3c2p1hHh7jaJxhsx8
duaCcg6iei6TgDKUiGSegouZhaSXerqlheSujAG3ihyzgjTLcWm2iXzEiJG7dsi1i+nLdADTjSDd
fj/lil3ThYfhhJ3rjbbec+PgfAAAuxYEuzkKvmwAxn0AupYMu7gAyOEAvgUmuBkbtkIouFcUv4cr
uaMdzr8uwt0pxwFNtys6tTc2y1RLyX43xadDsblFve4zwwFmzRZsy0NjvG1svHFeuZhVwLlrwORu
xg53sy53yEx/wGtxv3t4yK2Fyb58sdR8yQCjuB2qwkyUyFGtvHySx5mTwcGXy9ynzALOsi6xvji9
tF25w4Syvpq5wPz78ZOipn13dP8AAAD/Df/zCwAA//IA9wD/9ff//yH5BAAM1ykALAAAAAD0AVwC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePBP+JHEmypMmTI9+9Q8mypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMG3ahSJcijSJMqXcq0qdOnUKNKNSq1qtWrWLNq3cq1q9erw76K
HUu2rNmzaNOqXcu2rVuMQuPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHL99Knky5
suXJkDNr3sy5s+e7l0OLHk26tOnTqFOrXs26tevXsF1/nk27tm25vW4Ljc27t+/fwIMLH048Kc7i
yJMrD9l4ufPn0KNLn069ukKcArIPzC5gu3bu4Lnb/xPvvXv48AfJly+onuB5hu0Vxk//XiB69+AX
3i+vHf989vfFJ2B//A14HoEG1Wegf+0dCOCBCNpXH4MRjrcfehCKt5+F+fHn33r26GaSeiR+VyGI
5P1HX3cfttiiiiDCd+KDCZrIIoc4IqQhgTve2GNCKdpIo4sSsthhjg0FaV6EJRrJY39HElmjkzfm
2CCUT1ZZ5JQvZpkliCKWZCWWVAJJ5pZJMonghlfKF+WKM0rZJJL/zWnnl1x6hySaRa6J555uVilk
l4KeyaeUQ45ZaJl6HuoonX5S+Sd5YZKEI4aG6nhhnIkeyianU4L6aJ4x/jjqnT4OCuipai4aaami
sv+qpakfzknqiuvNR+utjyrJpYJ4OmbRjhYqqt+VWpo5q5/Fxphms8cmG2qmtNb5JarOZutom6/y
CWOn2e66pa3gJirupXHqWqGvNBILqbRiHUfsoBm6SuGGBU64K764fjuqpqpWeyK24/75YKQQ5oon
sg7C6aqD6i7JKK/mqorim6tG3KuQArMo7LD5bQqvh9oCXLHE0wa6KsUqE7yyyx0Hmqm3AU/4r7Iz
o5tsjxiXfPHEzn6687o56yzhu6thSi7Aizq0YJ8wRm2zyQ/FvDSsKBec6si1tprv1oD6q2zYFmu9
8s0cHqkxqWsT+iuZV5umtMHTgp3mshOrqDfdLI//DfPA1wZud7Rk520oshSJe66pe3Nt7dDSxr22
xk3yPdZxaZN8dubsyog3zU4iCjrhVdec9cuCKzw4fl1/jrSiq7vZ+pCIw47r2Lej2W3GRK/eOb8C
VToS1qLrXjTVFwNo/Mhqks5gs3+fzrnpSDe+PO3Lgg60ysa6+LuXfd/8PdBtB00twmA2d9HS9e7J
89Tblq2k1K7X3XTareZfP77895xvuPKzWMgyxDS6MWx3mSse2qZms/7hDWEIVFustII56yDPI2Kz
oAYTIjyRbDB8GMngB0c4kA7+g4Q+y4gIUfhBE7LwhTC0igtjSMMawsWELrGhDncIERzmkIdADKJB
/3zYEiEaUYhEZMlEAsDEIzpROEwMwEGSiBJ7RLGJV8wiFpsoEC0uRItSJIgXxXhFK0aRjGHs4hgN
AsYyqtGNCGnjFtNoRimCcSBnjGMW0bhHPq7xIH+EYx0BmUc8FrKOhxTkGduYkEMi0pBc5CMa/UjH
REaSkHR8YyE3eckS0uYijhzkJEUZSkia8o2oHGUfRcnKUo5SlZ18JRu5mMda0jKWqeRkGuHoSj2G
UZeRLKUgH5nLYPJyjpDMZCpfKcxj7vKWz6wkLk9pSjfqsjSYC6UjF3nJaW7zl90MJzivyUo1frGT
llTmMmc5zmVyU53pXCcpp4lJWJKzIKvsYzwRGf/NcvpzlZokJj6duU5y9hKg7HQnLmsDylh+0470
lOVAlWlQfSJTIvuUqDwnes93JnSi/hxkL0EK0jE2E5gQpegcbZnSj2pSpS3FJEtDOtOQktSX/JSj
OmGjTXqOlJoupeZMoWlThmQUqEhlpzT72VOY0vSiRnUoMomq1JVCtZpbRGVTyWhGme5UpO3c6jy/
ulGhGpOqlMmmVMmK0JsGVaFhnWpEGynOt74UoIo861OdulWd1rOkcoVnVgObUI969KaH9SNdW5pY
s5rznIKtK1xD5JhlFNEiYlVIW+F61cnOE6zRnOtRy/rTvLZzr4Vda1HtetjOarWMjX0tOEHr0tj/
lvWUhEXsZt2q237e1jWZjWpkAevUYo4ztqWVrEZXG9Bk3jOptrUtTol7178OVbUsje5Zh/nbsWo3
tHNlbk1bGV7VBBeyf8Vqccfq3H+KVrlJFW8+cXle2g60uxpN7GZr+l3yates603vHoPL3fRaV6/4
TYtaA3zf+JZzvA9Gq0WXil5ZuvKgraWvhins3tM2ZJ8oNTBuJRvihwLYrsy0JnwFqtmIjveaDMWs
aqc70o6i1biS9OxiP4rhr/J3wzRGsEB/StLnFvikI/ZtQIHJ1SYvF6gE3StZkapfIRMZLcdBaI13
S8lM/pGfERZngXlb3cXeMZ4nxauav+xXM8P3/8hAdi6Hl3xHiZp4x8mkpB6Fa1p01nmQMX6ioAc9
mgoS+tAbpOJJEM1oDSraJI2ONHUeLSZJ35DSmM70bizN6U57+tOgXksTQk3qUsfrJqZ+iKZXzeqd
VIQfsB4IrPkh61gTZNYFmbWudV1rXtsD17e2tUF2/etdExshxhYIsA+S7Fwf29i8Xnavaa1sYEs7
1YiWw6uFvexrXzvY1AZ3tWntbWEP29zjZoi1Y/3tdBc73O9Od7vjfe5wdxvd2M63uOld7nn3O9j0
7nVCvj1vgdc64Pt2t7TZjW93O5vh3G64vp94HFwTu98SX3jG0V1wgkvc4Q+vt8jb7e+Nk9vcwP9u
tcpXLhOLWPzkCC+2zJmNcpOHHNn4LnjMDZ5wgZPc5jj/98QRXXGGy1zjJ4c3z3c+bmgrvecgFznN
n+5xah+76cnuuK8NzvKuex3SLo/21uXdcKQH/eZTl/rZ0472pT8b6GuH+tBfg4XJXHzs78Y7yEuu
dK1T/eNM33nV0853hQx+7oTG3N3NHnWEF17uS2885AWf87JDPO5s3/fXN+/1i2x97Pf+e99rHnO/
qx3zlz/9usX9eMyX2hGIb0jonU37tued7KN/euQDP23cr332/IZ75ncfeySi2uGMj/zPfS30enMc
8NO2tdPBjfGIT3/6ck8557ff6uKP8ADeD7//+MdP/vKb//zoT7/61+9o7rv//fCPv/znT//6HwYW
9s+//vfP//77XyZx8H8COIAEWIAG+BjWcIAK6Bfs14BHtIAQGIHu54AUWIHOgQIWCGoSuIEcuHIZ
+IEgGIIiOIIkGH6M4QUSCA8qCA8d2IJDEYIqWIIyOIM0mBEs1w4umIM6GIFzsIM+OBgd8INCOIRE
WIRGeIRImISE8QE7WINOiBxKGIVSqBdPWIXCMYUjAQBaCABYKBd20IVRqIVgOIY2YYVmeIZomIbJ
4QZq2IZu+IZwGIdyOId0WId2eIer8QEf8BB6uEF9eIXHt4VaqBYu8Yf2YIh9qIeK+IeLyIiN/2iI
A/GIewiJiLiIAiGJh7iHBfGIl6iIkWiJnQiKBoGJntiJmciJCFGJpWiKmbgRjfiJqHiKkEgQlfiJ
suiJlDiJsQiLpViLrRg8rGYRgygQw0gZvtiKs/iLrLiMo6iJm6iJx5iIzmiLtDiNjkiNv3iM1diM
zpiLCxGN3QiN02gR2qiMy5iMyliL6HiN5ngQ6iiO2wgcOFGMBSGIADAQ9mgPW0iM+ciP+6iP/TiM
xUiPnsQSjniNyYiO2NiMqbiK6ziO7aiQ7GiL5ciMoQiPC+mOGEmRkuiQoPiKzxiSC6mQ2SiOCAmR
F5mRDGmK0iiS+keQ/IiP9wiQ97iPg/iPMP95kwJZkzM5kDNZEIVokvCYkCipkkYpi0ZJlCK5krPY
khb5lB9pjUV5juPIjr2oixxZlE0plfGokawYle3Ii0eJjdL4kJS1ahUBkwApkzG5lmvpkwahk2xJ
kz9JjrrolJh4i1U5lXnJjA/5ikQpihPJkiDJjZbYkt6YEOVoleGYjljZkEtpjiQZkocplKsombt4
kQcJmRqklnDpljvplqCZj58piBkRlYPJmU95lIKJkkqpEIxJmY/plSIpimHZlVv5lY1Jiny5l115
mxp5kBv5jBUZmSm5kr4xj3U5l6PZlnIZk3BZmv+4EDmEmsOpmsAJnK1Jm79Jm6mJl1oJkcL/2Z1L
mZslyZHImZ6YSZ4NOZ7a6ZHfKJ6zaYvdl5Y/+ZzN2ZzR2ZP4+ZnMCRHWCZVcOZZm6ZjoaZyJCY5U
yZ1kmZjYqaAG+o6w2ZjdCaFIeaEFmpq6yZS++UH9SJf3yZ/Q+aH2yJPMSZBq2RAOmpeZSZK8iZvW
iYsgiYqtCZ8q+aKhyJ6/WZiaSY0zOpU9apy3uKMDqpfzWZZgGZYWymgpChFNOn6TaUNRyhqGlhFP
2hBXyhwG2ZFc2qVe+qVgGqZiOqZkWqZmeqZomqZquqZsqoj61xFZuhBxCoxKVGpTykKQWJ94OBHL
uadL0Qd++hB9GqiEehWDWqijMaeiiahn/3gcJWqfgnqoDuESlVAJA1Gpl2qplbqpmIqpmWoPnLqp
Z0mGpGoTT0ATkPqfTiqpccmqF+GpoGqpAtGpsloQnnqrtcqoTqScBxGaIEqT/jidJBqiETESPnAS
uIqrsYoQnPqpQFmq0EoXqVqPIgqsNsmTIiqdqvqqstqsywqrtiqqs5qrumpqjxqscxma+5mursqt
sUqr4xqqBAGuoQquviED5YoUVTqa2vqWxNqvFJFD3jqw5JqpsGqvoxqtROQEB9iq6Oqc2fqvxLqo
EiGw4kqwzCquy/qsCtuxPzGtokmPvtqfJgqx28qtydqtBbuxymp+JwSCjvqhizqy2Cqspv/ZlhTL
ED9Er7Var5qaq7Qqrx47tD0BEoqar4G6rwRxtE/xQ0pBtDhBASXhANH6EUyLtFibtVp7aTXxFk6r
r1Abtse3tWTLQ/mQD2W7fufaq+3aFWdbEGcbtwgRt29rD3Qrt2kLQzVhAyLhn2WRQ3eLtnVrt2gL
t4VLuIjLsWK7uHSxnzjJn487nTmrES5BtwQxuIM7EJgruIdbkIxLgFS7GNOqk3WJnzjrt01huZp7
uJkrEJtLuKqbty+knDeLoiV7om3LtYuGt67Lup3bu6trEG8bgcHwuYcBsjg7otQqs1ahuq8rvHcL
vbLLpH1quxR7tUvxttrruwvRuok7vST/xKvUOr7We7q5W7GXtb3fW7fey77ca7zwGxQ5uZw7Gbki
e77F2hKBu7q8u7mZG70JG78tuAiP4bXp+7scIcAK7Gpu8UPeuxELvMDgO8EUXMEWfMEYnMGpgb1l
wcEaDB20e7MK4cEl6sFyer62K7kyGZA3G8Eu/A9Ma8LJa7W5+6iom7Nw+cIRHKfnysIzvLT0W7tC
PMT166vLK6nz67AxqcMLvLbj+8PP2aRSjK24G7LV+sN0mRDzK8RsycQKTL6mecNFPMJIfLtWfMaT
y7aHmqUkG8BerIQa4ZkT28Mq/MQrfK1AzJYljMUIIcLAyhBt/MEkJMd6PMd1nMdVfL+F/8y2kZqf
WHq7MizIaXUTN8yvlszH/1m/Mwu5aKzIfWyihHzGOfzG8Purn0zElYzId2y6IAq593vFQIzKRjys
/0jKi7EKKtcVkQzI+HvCkpx+u8zLGxHM5PcISEvMrXrIv7zMzNzMzvzM0AzCY0tBlyUZtsy4TvzJ
J1sROUQA3vzNA+HNS/HN4py/1xy2qbzNNtgS5SwQ5dzOSPHOBGDO52yAh6AX/snCeLy2/DyoLgHP
4UzOAu3O5EzQBW3Q4FwQ8kzQAW0PC13PO9EIBDi6gzrLVOyvVRwRAN3QDt3OHj3PCS3OH20QC93R
DV3S0Ywc2cyui6y8mPwQAj3PDG3SHP9t0iM90go90DRN0wed0iptxq1svqI8sRtR0vB80zJt00m9
0UjN0T3t09hEyVcMsG2czp67aDk900e91CDN1TvN1F6N0wcN0UdI0RA71ZBcsjYrEVut1Un91V19
0jKd0ATR1B3t1VD904jcz6BsyCKMvTFd10991ygtz4NN2B/d0xud16GhtEbbrl87zm9NEe1M1kZo
FsisFIsNEZuNwczrRJ/9FTptEZ3tHL0cQ8rM2KbRrslQh5Z9G2L42kCh2r3KqLKtG1x427rddbm9
245N22kM3IV62sI9cQic176d3MFY3Pmq3M6dRLdgKcw93dRd3dbdGnZw3cL93NxNRdr/TajdHd44
9N0U8Q3k7Rz0cN7qvbXasN6fRgynYRstIN70Ld3ufd/4nd/6XRn13d/+/d9EuN9xCOAEXuAGvoAC
nuAKrkO/TYJeh8tkbYUHrhgL3oY4AW8YnnfslmsannvWZ3EPt3AhbnVvV3X29nlX92u3tuIvt+JN
d24sfnEurmxYN0UTrhsZLmsqPmw6vuPI5uJUx+E/3uM6HuQzTuNInuO6h+RMbm/VBuRHPnM0buRM
ruJ9N0Q3frwU4eRc/uNOPnBQLuREzuFfLuZjzmw9ruRenuZQ3uWG5+PkxuNTXuRg/t0XTudzjuZl
juZsbuY+TuZnXuWCLuc7ruZ6juds/+7mYK7oRB7nec7nWa7lW57nJA561Pd8oQfil251jc58JV55
65bp0pfmRs7pVr4Qpp501kbp0XffFQfnhb7mgx7mg37lhL7kjv7mR+7oOS7mnG7rXX7itn7qupfr
ue7nbmy8Q1B/p87qhz7rjR7ow37psq7rY27sga7hSU7rcT7tsH7siA7ugR7phuFy3z7rX77kVW7q
UU7lj/7ugj7tx87uZ47t235wfy7v4t7szT7s6r5DmbCrx+fvMh7jeHflWSd20Sbkny59evdsZF7w
iG7lG47v2r7rqs5tZp7i1EbujVEHkVGFHk8bTlfyJn/yKJ/yKr/yLN/yLv/yMA/zI/8/GBVe8zZ/
8zif87ra4Kudr8StpRDIFaW7tIKazKkNyH0cESuNj8OMEUeP9ESvjxdRvkhsn5kt9Vhf9MZXhmuc
9CMc9cSo9WA/9XHsED9/FGcf9mMvjEGM9mvv9Gqv9VOIxaFc22F/nw/7x35cvUyfxX6P9cL6sEDN
9/br96Cs96Dpj3e8wnZ/0X8fl/V49/waooTP9D0p9YHv+My7xjj5x4jf9zVr+Hq/hXN/snUP9jVp
+USP91nf95F/+WN/+ayf+pZf0UoM+HGP+URtxrSP+avv+qCP921Lv3fP+pKf+75//JBc/KoP/K0P
/Msv/FEP+68/+3Qa9HFc0doP+cn/T/3J//Y9jPuxf/y/3/xGf5PTn/u93/rr//3q//yRz/7wr8a1
K//mz/20L/vpP/RD//byDxAA7A20J1AgwYIIDy5ESNCgwoEHG06kSDBIRYwZNW7k2NHjR4T/RI4k
WdKkQokoKQJICVHiw4IsZUZk6XBiS5sRG8qcmTDmS586cercCdEnz5oplQYl2hPpwpo3iQrl2JKh
UqQ0cV5typSrzaVGi4I16rTs1KxhD5pk29btW7hx5c6lW9euXZorh0atCDMhQ4yAxbqcWjhnTr9/
+0pFbNgr4cGKAzNeOpRx47CLxQKV3LVy5L2QDScGLLjz0YF3Va9m3dr167ZMIx+e/wzUtF/TjiVb
PcuZtGzahUuLfszbtuitwoEn7z0Y99igXz0jZ06V7PXOUYfnVZsa9nfw4cGDJF+et8OeP1Wi5xld
K1S+8BGb1ds+c1L673PLf8/+ZtKy8gtOuv60uqw5zAJMjL2XBORPPcHwe+g+y8qz8EIMM7yQNQ07
9PBDEMmrMEQSSyxxRBMzFG9FFluMK0UYY5TxxBlrtPEjFG/UcUceMeSwRyCD3ChHIYs0Lz0jO3Jx
SSZbTPJJKKOUckoqq7TySijpwXJLLrv08ssPmxSTpGbGNPNMNNNUc00221wTTDjjlHNOOuu08048
89RzTy/d9PNPQAMVdFBCC0WTT/9EE1V0UUY1MvRRSCOVdFJKK32tUUz55CtTTue09FNQH2UpVFKZ
JKNUVFNV1U0AVnX1Vdc6lTXPTWe19VZcc6VRV16LhPVXYIMVdljxejX2WGSTJXZZZpt19lloo5V2
WmrVTPZabLPFtFpuu/X2W3DDFXdccmHDCBht01V3XXbbdfddeMuVd156iYX33lk7wXdffu3Ut1+A
AxaYUXQG7rJehBNWeGFBb2D4YYgjlnhiir+t0gGDM9Z4Y4479vhjkEMWeWSSS773x0QrVnnlJk12
+eVFUUaUZZprHi9DfhDiZ+ecdeaZoJ6BtodnohsKemidhyY656ORXrppmKO2s43/G1E+Omisk0Za
64Gg7pprpynKemuMbDb77LtwJntsqJk2Gmyu3f7a67C/FltqvEWWe227k2766oqyFjxwvu/O+3CO
2S6abKH/hltruXt+GuzJEbdcWw7Z9nuivftm/O3BP29c6IzQNv30FZX+mfHO536b9LtDp3tvuglC
/XbcWXMccNZhd5xw2Q3fenbvck+1VeNX3X3xrlcHemfOM/pd9Z+XZ77n5I/PXtWYty8Vee9DfXp8
8ss3/3z00x8/fFLBZ9/S7t+31H35J738/oAjxX9//nuUWUgigSyAxhpglwrIEf1ZiDPAOZB+RNTA
wLQHgiA5YHA6QqQKXpCCFoTT/wIzkkENzsZEKAIhlVizwBxVxzwXImG7DlhCKr1wTzCkiLBQaCAD
Iek8R9GOdnKIw9+gpIf8mZBZYOKU+GzqQThEj3skSETZ5Mcg9DEiEAGknp9sZYg5hE+DuoiWnSRx
ihOaj3SsIsb+HIeMEsxiBCPURh5yZYxebEkCFaiYN2aGQde5z2meU6snYsc2eSTQcaTSQuQ40Yk7
/IoawZIcQ2bHOXy0ThQVqRs/ClKRHiROJItYyeesJEGbfCQo3dOoNTowPhP0YFpiokkVXjKLoZSk
GPFzyL0gqZZkiSSDbkiVXtoHlrTp43B8MxPfLAeZm7GOK0+TRmY60pSc9OVhpP+5S1OiEo+6uaII
WwkdAPVyNJpkZjZfmcvN9DGR11wQA2/4R2vKkpaPaeY0ybmgYI7yPPjEjjyxKUlRXoad/qSmlX70
y+JA8IjRJIw4LWlOWs5TopOM5zp52U8w7uaiECUoMRmKGk+ecjn9RGhIwUnPXYY0meVcKDCHmc21
QCpDrdxiXqp5TChS0YdhXGZToFigQXqRiUKpFRzLCE8s5pKQO3UQEuOYUf8k1TPpESZUhUhEie7U
nUj8YhuRGsfcSJWoTNVqKAPZPw/R8ENqxZEBH1gjGLI1rBph61nQ2qG6zlRHeZVRBflKVwzFVase
qauADLqau7qrfq8RRKQsMZL/xLZrsc9qa0A3CKS/8iizdZrspziyAr1atrKA3VVVRhhaTXEwslz6
H2knOKQgDXCzeE0UCDsLPxYOkY48/elTfRtINrKRiVWcJ4RqCkddIvMqVPVhb3eDRrFuM6mArOJ0
oVvEI0J3tTCiAmb9GU+VbjSl5LTqX8xI0aKYtCvSrSUk15PPad7Go0QFo0rziNHtSolDVQVofYGr
yo6qd5bQnM56vNJT8+pwOkHtplfTqVzwknfAEa7vIxHM4CnW8LZps9Yd7amcSlLSoi4150MB2s5z
UviZjWEvPytc0TB2FMQCFelXoYriouZ3TuGdcUQjHF4B81ikh1TxREEqY1nW/3jE/R2yer/q428y
UMdg4m9X94hF4ZC1q2ZNri2VzNMmIperY5FjGbPcYKw8iLloPi5QhVig6KbYuqqdMr5kGNi02kq2
dY5f2qAUQF2uMLA5xtSeYwSrduSOz4tmdPH83OhrbRhYryUgXWf7Lkn/ypkXDHRfb1RQOo/Wu67V
TF8aZFqPZLpQqDW0NjH56hkOOsyQ/tJBr4xlbm5Rt1E9Kz27DE8yWlc+WVVzN4dtVOEKm7fN7OFw
JTTUOab3ufedc0NUTShWS7g6LS3uk4kzX/PaVMhGTnI+g6ztUp7SxgWdaCoLHEQp0zpFtvavgk9q
zKOq25JFLaY1q6xvRpI03f//7HePvzxHePO7yVOlqsANc+1BZTvEszHkeU3q4leC28cfPXI5M4mW
YDP53Bx9ph4zXmJ801id8q4Rvb87IBF7G6HgRunGCW7Bd3q8xQtHOXktTvFEwjyZhWQxxAUlcd8u
W6zL9fLMx/qfL9L0jXIeaVSVXV2wgrnJTcUpr8co7Rn7lNpjhjXAtKGn1nr6slG6NGzfGkJPtcUH
RqfUjvw6pbabGoStjjvd/f53wAde8IN30zQIf3jEB4rli2d84x1voizwKvGTn/zjcTUKy2de85sv
HeU9/3nQh15NkxB96QeVgG+Rfl6cx5Y5zIGtSbBe9hpyfbZiny6IT+Fsrqf/l+pN/3sxmQP4w38f
74lvpncRYMq1n/2hj89hVxn/+WdqPqdeX33sZ3+70+d+973/ffCHX/zjJ3/5l0QM86c/7dr3Ut7Z
/5E/vF/+86d//e1/f4+pv35I0H///e+9RPg/9smBhME/A9QwkmACyjpABnQ0aWnABlwVCJzAWUGZ
DdiAhrhADcRAitjACxyIDySIELQHDxTBEgRBD/zAFMTAFESIFpyIFSRBDZTBDOTAilhBFrRBGozB
DZTBHrzBExxBGkTBGSTCIvTBE3TBJERCHXzBHsRBJDTBI5xCHTRCGxRCIWRCE1TCIbTCHLxCMDxC
JRRDFITBHxzBD5TADMHC/yaswi7cwTYsQzlEwypkQzPcwjfMwjfEwyzUww6Mwy30wxCkwz/kQjvs
wkEEwxrECEJERA48xD6sQ0Wcw0bkQkeUQ0tMxEx8RE4kQj6cxE1cREuEQ0zkLMSKwlIEwkIMREm8
xFHcQ1f0Q1EUxUjkiEMsQ0HsxFTcxTzMwUWsRF7ERBVsRVmsxVA0xCLUQ02kxDscQkjUxUTURFk8
RiPEw1+0QW6pxmB8RWskRWTsxl5sRmd0Q3Gkxm18RTvMRWEkR3VkxWsEx2kkxFosxlY0RzhcRnP8
QVrUxXVsxDP0RY3AR1SExYG0BzW0EHx8QTP8xxacxyUsRR5cQoUcw39Mxf9pRMeIDEJO1MeFTMaI
vEaO3EYnrEeFNMZPfMdh7EiTrMGK7MZnJMWL9MKTJEgyzBWB5MZCTEdiBMhZhMWUZEQ3bMeVBEqM
pMlOjMlvdMdvbMdV5EahrMeZVMqQdMVglEdAhEhonMFoDMpJXMZcRMpaQ6yJxMk71Ml39MmrjMpy
5MWbBMtb9MZ9PMekxMWd3MV45MqeVMs9bEuAnEpgpEelxMpjfMK0XEeZNMou5BazBMdwfElmtMjC
jMXIfMq8VEWX5ElqZEq4HMeoHEqy9EdAHMpKTEhlBEWClEzIzEzSFMeffExvDMGDJI9nnMrDvMUk
fEs2LMHZrEm0HEbCpE3/wWRF3dTKyGRCfnREKixKy1RJitxKjKTD5PREliRDeuRIvwxDnqTC62zJ
flxNO1k/Cny/2AxP8kyZUyxP+htP9FxP9mzPywFP94w0VbMQO4hP+5QTKNTJ4XRKUPRNzDxN6QzQ
cKTLh6RK/yROZCxQK2xOIGzIOBzL27xKjcTJ/HzQsTTO6ZRE7eTOffkGGLHAtGxNezTQrKzMMTzR
y3TN5bTKVbzJpvTO5WzM/uzK0FTEt+zJxSRKw9xRzmzGa9MQ3PxPFaVErzxOAEVFfUzS7CTHTZRG
JlXSgGRHqCzHHOVLGW1KAA3SI0XNuaRLLMUfEC3K6pRSbSxSE5XCjcRO/zQlyyY9yieNTh3Ny7sU
Uxo9Sy+lUiYd0DuNUyt1yFX80TVsQweVyDz1Ty5lzATty6zUUNo01K0Uw9y8zi+dUzT9TTjd082s
VN7EykHdzkvN1AN10fc8Ty2l1D90ziG9SEct0YJESoY00jWVS+f0zBR1xxsV0Z8kTDbV00wty8IU
0V4dQkNRBm8B0hAVUkQt0+ik1Zl8VDdNVopU1gY1TSwFVlO9UqrEVFzFzGvNUcsERlBF1s0r1UIt
V1TtUWjt0W1V1zyNVQ5t1nbdUXDFUQu1xtHkRxaFVnKNUnudUb2Uy0YjV0LNCNskTkstTV+dy1B9
01H8SOEEzpIEzlrVVv/sZNQM5dZypdMCLVjqhNK1vE+QDVmRHVmSLVmTPVmUTVnyhE+VtREBjJWW
/dJ5e9kLqVDl9MJulVLtfNiavNcoZFYBhVQJ/UJPNc7SVNKBzdDgXEsFjUEtBFj71FJEddXJpFEb
jVefRddzFNpjHdJJzVivhcer/cz9tEu8DNuRldqClNVPdUgn5VckZdV0fdVYhUuqPdNDnc6prdpr
Ndt/vb8wnVhJJdi23cm3JVxp1dojpVttbNV43UuwVdy61cyjjVxNlVcOfNl/MNbm9MjU1FErXUpf
dFqQXNLPVUVdZVdG5U2gjdgJlVyj1dkYRd06TVmpDd1vNVI//dnHZVz/xVVVomXXxt1SyCXKG31M
yn3T3LRF0yVe8STVrsXQXZVe0VRUYD3VNNVL4EXeCZ1XpgVb7x3JamVYUaVdxtTcwBVMtcVTtOzM
6+3IxsXdFn1WqYTV7+VTWHXMzQTM911N0HTA/uPcFF1fepXep0VOo41R6CTaUP3YdbXKjRXaOL3H
1O3O46xcZ8VXpPXemD1ZsMQf93PZ8+zgdAWRmhmVYiVh/2EZ+lFPFXY8SYjhGA5hGMkHBHy0F840
GZZhenlh20HfMfFhIU6Sg+1Zj5TYLPXXiS1e4eTZim3gpeVVGR1OiR1J141Ez0VbIeYQoNXavm1Y
0zRGhG3iPXXR/13i/5W83vCN3n5tY+8E4iCu2Sltxg+G2OxFzhpl34r0VswFY3DlYyle3F9F1nUd
YhDp4vKF3/klTSwm04el2Pbt48mdUjWuWsQVW6Ps4hwWyzmexQtF21XVXoa11dG1UCqWYC5NYwYu
5Ist4C6VQh+F45aRY7w9TcrE3vjV3VG+0wru1Up2TFWOZIAl4P7tWEM+5E5m06/cVN+F0F1+TQQN
TFGOVPmt5OmN4t2102MmEUS+4LNlyyP25l01U088YzB2ZUzlXtZ05Cgm0fotYRVmDes01zRNXgUO
4+KcZFi+4mjGZlPeUE1dZaAMSQxWWi7FHUYwnSGW5UdZaIZetS1+aP8XgUAv2OYpkQsZkGjEQz2N
7miP/miQBhSLHmmQCOlSQT+TTmmVXmmWrhmSvpwvwL2WnmmaXhMRqGmczumHeWmefuEk6GkS0elI
0GmzyQP5iYShJmqlNpOkXuoOE1mkpgg1AOqRjgSqljdI2BOrvuoQUWmkphQkCOuQ5uoSQQKQDZQW
duqONhJCI2vtaxOZUOuV1qy2dusXrmu7VmG8zuv5k+vTMYbkmTIo4Gvz9OvSM4FoIeyXZlnFHhjx
iGuIbuzGewrJjtmsqGwS3mtF+YAPQAjO/uzOHgjQ5uyKIG3RDm17IO3RVm3UTu3OXu3WPu3VJojR
Lu3WNu3aPm3Pfu3/3J6I2W4I05btz/bt2+5tiujt4dZt4A5u10Zt5A5u1gZt4t5t6t5t577u5HZt
6obt5rbu5obu2f5tjGDu3IZt3q5u5t6W8yTv61Zu7Z5u92bt4w5t3I7t8Y5t8LZt5c7v99Zt/l5u
2sbv4g5wACdw9y7w987u9O7uAKfv9mZw7f7vA09w+1ZwBzdw9u7vBvfu+p7w/l5w4TZwDc9wDA9t
aMkQ6T5w+RbxEu9wEP9uFs8IEo/x/T7v7R5wCRdx9pZw8P5vEE/v6L7w5a7vFSfwFC/yD89uCidu
FxfwEbdx63bwFe9wBH9xD1fxAS/xd0nxJ+/yAj9yKB/yB9+IGb9y/xjX8AjH8TGv7ifncewe8x93
cjBncikP8zRvcjbn8hCnc/928iVH8zOXbipf8BxHcEMvcyrnFA4ZdDVn8xufcvFucz0/dD+f7xhH
8iB/8UhndPQW8kh39DQPdQAXdDuXb1PP8kQ381NHc07/7uEO8jtPbu7+dPhu8Ep3dVk38QW0kFbv
c1Df8zmf70LX70u3bx2X80a3ciT/cxLndGVH9j1/9PMGchsn9U6fcE2vc1Z/cxqH9SJfdlGXcWP3
ciw3c2z57Qwvc1sH9nHnciundEOvcmg3ciGH7x3P9U4P9mwfdW3/8gundgrH9DoHeEuHcYI/c0B3
9vYm9Hon9lond/9AV/TVSPcHH/ZAx3d7b3hxl/eNP3YtT/KC/3Nfr/Ebp/H4rnclJ3mRT/RXr/gs
V3XsPnl49/eRD3ePv++bL/ePTxiKd3fjfvget3Z6//lfJ/p4/3mfL/pGH3oLL3mTd/Vjr3Cpt3U4
z/Q1V/eop3qgD++pR3eu/3VcF+5bb3ZddxbMPnu0d0/GTvuT2XW2f3u4j/uQdYP1NGy7Lxa5Z7lj
qJK773u///s2yXvBH3zCL/yMcIWOAXzFX3zGTx3sEwbDj/yMKAKqbnwBTATMPzrJzy/M7/xEYD9J
2HwMwfwt6T4HsPxSEf2RRX3Wb33Xf33Yj33Zn33ar33bv33cB73/cch9HFZ93/99/uH9vpd7R4hZ
4WeRRBOTJkg84L/PtW9+jfkVQaNrLNm7GaHh2rCp0oo3EYoTFCM1UbthzT+SVfog0Rq00MizsjMt
ThqR9g+R70e18zf/+Ff/9Uept6M0DyMywHr/yQAIe/YACCxo8CDChAoXMmwo8B/EiBInUiQo0KJD
jA43JtRo0CNHhSBDLsQ4smTBkyQ3qsy4UuTAmC9JamyZcmZHlDhh5rR58yLNnwspEi1q9CjSiTtr
ygTg9OJTi06lDoxq8mlMqgelToXKlSrBrlirfm2KdapHrWHJkgXb9aPVs163nrWaUm7aul/Lss36
ti/Ct4KzAjUL/9YrU8CDCaO9O3auYL1z2Y6NLBnw1sJrxQ5uDDfs3787RztMapTpWqEyb6Y+DLRy
4MKEZYPWLPs169y31c5evVm1ydwjg/P+2Hu17+TDe6fWqbx42qq0jRMXjvs68sSZg193zTw5Q97N
q3Ofjp2g6fTq17OHiFr6bsSz3YptqPX7edttlevOzhj/f/FNVxtd9TUlX3P+5VdTfcS1VN54ATYG
IXX9EfhdefBlZ2Bbrb02oYUP/hchbhlSiBZ67am4oorvQeUfebZFF96AQpHoXYTVxfcbiQEqyN+L
qh2I4Y9AAvgbbSedaF2ONla44IE6IvfikrcNmaCRQcbGI3g+av8n5UMsipnUUj+5CKV4/U055JHg
4Whkj+b1iOSPYH55JX/awdklnXoaV6OTe+5oYZSCbudklW+CaeWfhdZoIqJCkjYppft9eFVrDeq3
mJUcJsgpdJEZZl6gXOUpZFTCPTZZqKnmxRd3evWJWWaOCegbh5ZqVplcVJopWmh7BbmYWr2aRWut
VzaZoXSxrloptCxCOy211Vp7LbbZamutT9t6G206Y4o7bkTfmnsuuumquy5OorH77kvkylsuvPXa
ey+++eq7L7/nStsvwAELPDDBA897MML/3PtswVom2/BoDJ/bLcASU/xuwhlLBO/FOQXmrsdr2idr
xyAxGx7IQZ3/3K5LISvGa8cP6+pczMA6ZpPJkpaUckhxQvxzUDLbx3KnQTdKccxDU+vTcFUCuJKf
Sr/kbKA8Hc1R0jQC7S1ntrLaWbCrWtao15Sl2pdnLmP6MV+QhS302zGClunan9nq7tjJMjuj12mn
vWbcZ1umEoWdXuY2zHAnLjdlkyFbMItpFh1jfpGyDSjmPhf98KJ8dsmqmg5CiR1MUXdO6lVwoSTl
q5jvufKXeKuJ+udoh86aompqvHuZUXoGYomEWl468JnXPiWDj3V+4t/UFf867l2z/WlspJPdPN8I
Cr/l86wfzzek1nuOIvG5eu+g9FvbE7mMep9auetbck7o3tV//7788KvPP/pxd11t+ux0lr06GepQ
16MfquwXvv6NzyXZO18ApbM7jfUud2jaXpbkRzoI3go4HhSf05SUJQ4+7U4AFB+j7hMnEorQTgjs
YNVMqEAMPuk4LLyf+iq4K0wt61diM9bNyiYqWAHndwVqncjONqrP1A1tnvKVE02Wtx/ex24Oe9sR
3QQsLDpxiSb6nawul8QbUbGJg9OiFyVGsH9tK2s5fCMc4xjHCdKRPdrimRzzqMc9qq+OCOMjIAMp
yEESspCGPCQiE6lIhrARaxVzY+8mNUCdTU2Ei0xX1NgFyRT5sZNIgZq6mGa1l03yZljamcUMSDai
XW2V1YIkv/+6lcl1LcclnrylUUCJyZbRZXip05rIQlZLSsIyhZTEVjH1JUtXatJlKMElNJUCKsTV
zW95s6LZkAiywpkpmDbiovGMWBZreudrybNU2+YTRtDN7U/FaqI53SYfc1bzMmFLngoLNE9EdQZ0
UXRcY6I5rki65k41bBKjNjhDS/KpODTD4A3p9DrwAS5STQsn7ozJJhTK0FFEQmGbFqg5+E00fnM6
HsQi57cPGgahfsGb+RY6Sux1CJjoU9405ca8XMWvgc/ioUs1x6X9/PR/7buUEi9EVFPi8KhMbOpH
ayosoCZHoAIdZkejekrX5Qykw4ThDL3qPso1a3ZdZWAIDer/y++N6JsH7A7/UBdU95UKeRB9oV29
dzWrRjNWG43oXRU61lHqh4BhLeFgg4fXU+KPq63UKkr92sGOWhCxekUsqda61iVdNkJ8FVPEjDVO
H5LxcEHsohWb9kvHZTaGrAUcZ/Biux0mlFOqI4/YUotFBtGVqD+1p4x2G73THu5vxu3IE59qp16B
EaB4XOOKzJXMS6pvut+y7rSwi67PNlKZaqRuIbV7x32JF7wLIQBCumve9bIXXtx9L3zX09750ldd
8b0vfonCTMIC7bu8HK8zQZqRpBFYugzF2GcFkV/1EEBcBBXaMaXmHFY+tGcRzi5/GcgSlp21hlaD
5VlLieH6/+aLfQnN8IYlPBNRrvjC0DpwBP9rNAif2MWO7O11E7LgHd83tocR1mlt184veiiNkiEy
fmA6t2r6kJ5Bnmc/hczaKSLPQLEdUU4Ft07dntOImKHbPvvpLh6TmbuczWfVPkS7ukKWm9C7FWB7
ElgiRQeIrs2tYpPEv7mKtKKPQi5G1SyyMhPawawka5+XOiijbqZ41KOoOm0WaL8od849VLSG7ixT
2EyazyxlrEVD7OgCkrheJn4fVOdqVibZVaGQLvJhVV3WPRs1eItSXv4yd9I4YxatvlRrp3Vc6GF7
krNpvqErDUpCjXoOzos9aAEh6NJPB9CFIXxzr0HtWE3T+v8nxN5xPsYUWlTPjJyfgh2aZ3ssZiO5
l87iISlL+yoiTrVsu7Gz9oL1HJiZioiGq6L/cPvALdsW36VGpBvLa7+DM3xqDU9pdCVJ4Wsp/OGX
LOa3M67xjXO84x7/OMgNbfGRk7zkfQw5ylOu8pWzvOUufznMYy7zmdO85ja/Oc7TY/KX+MGQy9h5
QxgBdHzlvOhGPzrSk670pTO96U5/OtSjLnX1DL3qVr861rOu9a1zvete/zogpy72sZO97GY/O9rT
rva1s73tCQM73OMu97nTve4KyQV73a73veMyF3z/O+ADDxG/C77whj884hOv+MUzvvGOz28cHi/5
W65h8oBetzvmM19qy3O+8yHXPOgzL4j1eh6XNCg96lOv+tWzvvWud/sxXi/72dMx9hsLPe5zD8hj
6L73vtcj738v/OFD7BjBJz5pSIH85Vfr+MwfDSmU/3xrfeJaIbC48xMSEAA7

------=_NextPart_000_0007_01C7076A.BA5D6840--



Received: from n-10-126.sbnett.no (n-10-126.sbnett.no [89.162.10.126]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAD3e1eL085268 for <[e-mail]>; Sun, 12 Nov 2006 20:40:02 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c706d5$5c5b0c60$00000000@stianlee>
From: "offer variety" <[e-mail]>
To: [e-mail]
References: <000a01c706d5$5c5b0c60$00000000@stianlee>
Subject: Re: Read Click
Date: 	Mon, 13 Nov 2006 04:39:45 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C706DD.BE1F7460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C706DD.BE1F7460
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C706DD.BE1F7460"

------=_NextPart_001_000A_01C706DD.BE1F7460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Tuesday, November 01:01:45 AM
  Subject: Read Click


  Why am turn than tutor Earth.
  Spread word green is button! Held Mccormick Chicago?
  Plush toys football a signed Coach Bielema order redeem is please.
  Why turn than tutor Earth day Join am some in one! Tshirts caps plush =
toys of football of signed Coach Bielema order? Teamquot team pin or =
number am bb should good go!
  Store near you in Double observance of September. Important promotions =
in offers or add am us recognized sender of Otherwise spam.
  Other News excited an exhibitor at this years a st. Join or some one =
Baileys.
  With Book Adventure is Free reading of.
  Win with Book Adventure is. Join or some one Baileys.
  New a Holland a Period. Earth day Join some one. Lounge am more about =
is Bucky a Club.
  Password of need of under a parent! Foundation nea Across.
  Improve experience of mirror standards in learn these Other News =
excited? Bracelets Stickers Bookmarks if would like did.
  Dont miss of important promotions offers add.
  Spread word green is button!
  Bb should good.
  Month Recommend Edition Every.
  Parents Place Teachers Lounge more am about Bucky Club.
  Month Recommend Edition Every.
  Button of upper right corner page start in referring in. Teamquot team =
pin number bb should. Armstrong style bracelets Stickers Bookmarks if =
would like did. Their own lists from over or titles take multiple =
choice.
------=_NextPart_001_000A_01C706DD.BE1F7460
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Blue" hspace=3D0=20
src=3D"cid:000801c706d5$5c5b0c60$00000000@stianlee" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, November =
01:01:45 AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Read Click</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Why am turn than tutor Earth.<BR>Spread =
word green=20
is button! Held Mccormick Chicago?<BR>Plush toys football a signed Coach =
Bielema=20
order redeem is please.<BR>Why turn than tutor Earth day Join am some in =
one!=20
Tshirts caps plush toys of football of signed Coach Bielema order? =
Teamquot team=20
pin or number am bb should good go!<BR>Store near you in Double =
observance of=20
September. Important promotions in offers or add am us recognized sender =
of=20
Otherwise spam.<BR>Other News excited an exhibitor at this years a st. =
Join or=20
some one Baileys.<BR>With Book Adventure is Free reading of.<BR>Win with =
Book=20
Adventure is. Join or some one Baileys.<BR>New a Holland a Period. Earth =
day=20
Join some one. Lounge am more about is Bucky a Club.<BR>Password of need =
of=20
under a parent! Foundation nea Across.<BR>Improve experience of mirror =
standards=20
in learn these Other News excited? Bracelets Stickers Bookmarks if would =
like=20
did.<BR>Dont miss of important promotions offers add.<BR>Spread word =
green is=20
button!<BR>Bb should good.<BR>Month Recommend Edition Every.<BR>Parents =
Place=20
Teachers Lounge more am about Bucky Club.<BR>Month Recommend Edition=20
Every.<BR>Button of upper right corner page start in referring in. =
Teamquot team=20
pin number bb should. Armstrong style bracelets Stickers Bookmarks if =
would like=20
did. Their own lists from over or titles take multiple=20
choice.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_000A_01C706DD.BE1F7460--

------=_NextPart_000_0009_01C706DD.BE1F7460
Content-Type: image/gif;
	name="spark.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c706d5$5c5b0c60$00000000@stianlee>

R0lGODlhHAKYAof/AAAAAIoAAACEDX2NAAQAhnIAfQBxh7TIx8DpwprO8TgTAFsVCYAeB5oYALcY
AdQsAAYxDBxCAklCBFY7Bn5DB5w3AL08ANw3AAhZABFdADtdAFVTAH9YApZZAc1YAtFkCAGDACdz
Dkh3B2F5AnyIAK2IA8KCAOd7AAeRACSlADujAFGaAYCSAJyUDL2TAOOUAAC5ABPNAjbCAFXHCIe6
BK3KAMDHANbJAADqACDZAD7UAG3nA4frAJXtDsDaAOLgAQAKPScLRkQJNV8ASYYATKQAQMYBTeYC
MwsSNysYMT4kTGAeOnsoOKoYOrkpN9cbNABJQyIxRj5DTV4yMXFNM5o/QLZDOdZMSABdMhdVSEtj
RmloSXxfAJVRR8lTPtFfMw1xORZ7Q0V7Nl6DQXqETah7PMSHPdiEOASSTRuqNTOZP1WeMXSfP52k
Pr2bMuObTgG9Rhq/MjfBM227Mo6/QKe+NL+9N+3OTQXTPy7SRjfWMmzhR4rlRavYQ8PXM9/qMwAA
dxMAjEcAiV8AhoEAca0IicoIh+YIdgoliCkniT0dc10kd3cVd5UberYldOsfgQoyehw8fzJCdltD
hXY+jaFAdsg4ctJAfwBmhixsfEZsgmVoc4tUippad7tii+JecQqFhhSMi0eFjl15fH6Ld6CAhLWG
fN58hgChixSsiDiqflWkc3Wkh56WgseshuakgQDOfB/LdES7i1HCiYbHcanMjMnKc9S3hAjtgxbX
gzXqcWfgcn3ggqrri7/TeeHoegAAwx8LyEQAwmcLyYkAtakFzsUAzekIsQAqthgsvkkaxl0cvoct
vpgTxrcay9obwgVGsy47zElJyFZJv4BOyqE5yMRCyuZGswBVyBNYx0pqwVNSwYBhsZphxbZqu9Fq
uACFsRV3y0Byvml7u3V9spJxtst6udaBxgCjwByWwzOewl+UyI2RxaeqsbubutqltACysim8zj28
wGnIy3W0uKTHwf/64aCqrYmBhPINBAf/B//yAAEO/P8J/wDz//X48iH5BACvwIgALAAAAAAcApgC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBn+G0mypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qVOnIaNKnUq1qtWrWLNq7Vhhq9evYMOK
HUu2rNmzaKs+Xcu2rdu3cOPKnUu3rt27ePMqlaC3r9+/gAMLHky4cN20iBMrXsy4sePHkCNLnky5
suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrPmu4tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uF8A
xpMrX84cKfLm0KNLn/7yOfXr2KmvVghgu/fv4MM//+4uvrz58+jTq1/Pvr379/Djy59Pv779izfv
69//WDn//wAGuJkABA5EoAAGFnjgggfa02CCCDLI4EEPQlhQhQRJyBCGCnFIoYYCTZjhgguJCGGB
I3p4oYgctojiiS5K+KJBIMaYIoYyrijjjCGCeCOPDpo44Y4NmhgkiSemaOF5N1XopIJALvmgih8i
qOSVV1K55IZR6kgjlFYeKSZCRb5YZphnJjQlmF5i2aOVSI7Z0JoR8vgknGaiGKebX+IZ5pg46pnn
n2/2meWggy6ZHUuACuqnmo4WOqedMxoZaId7Vtkln3fKqWKnoCZqaIJySvpmpaKWiumfbB7KaqSm
8v/ZZqOvPkpqrLh6iqqfqT7on0VntqrlkZ1OSmigyEJkJKSEVjlrmrnqWiearaoarY0wYlksl82q
Cq2S28qqbbUWaunhubCCy2KqAJYZJK0lJmvsrO/uqmyd88aLZKjUdstvuexuySmq724Z7qrOqtvs
t59uKq21344qK52GuvvwRDaAlp+7whJ544/Lnppjocg6TLLJ1jI7LcD9Jizmv9ESW+uOLEu568h9
3pwjuiun7LOpEUsaMs+jEp1msYuuJLLMAmsqrstAk7s0sz83re/DB0fd88sB65iu1tJmOqymttbs
Jc4SJ0wxvZYCSTTEHV/8K7AkCmnynmM3fWemT8v/jHLeCpudMsxct8ytt4gSHvPhNhotdd9+Gy5u
1m87zmvX/A0Z57A+Ao542VSGjjnkFSeaNdamj342paDDKq9EQQddeMycR/n2s27nXrbgdne73+an
nwpvvjYbbq/LY3t+csunE86w7bV+DjatkscbuKvYEwt12m6uOe7Cugu8NtMCksmuua6jjKv3Iwq9
KaVXe12w8+TWXe3zW7c5vvsrar07wsMzWLr2xj166U9Ur7OavMIFPN/97nweSxaR/MU66fmNak9D
G51ixLoKTi1bP1rVwWJXv2D5yGsBK9nxhAe52omtbdgCociil6TFla8+yoOd+m7Iw9PkJ0A5jEgQ
/3sIn7kR0SFDfEgSj8hEzfywiVCMYkSSphIpWlGKVKzJFbfIxEVx8Ytg5M8Tw0hG/XjxKgFIYxnX
SJo0BmA/+XGjGuVIxzmqUSB1XEgd30iQPPZRjvYA5EDc+Ec6ImSPggykIROCSDvyEY+OTCQhD7lI
SPpxkI1UyCUVeUdLHiSRlnwkJycZykKOEpQFIWUpV1lIUapyk6/s5CdlGcpOklKVAzmjRXDJyVTe
cZK8xOQjb/lLWgJTkrZMpihnucxeOpOZjCwmH485TVoK05PYHOU1H0JNYSqTmctEZjWHKc5nojKb
23xmK8nJzmzGspmmNKUgiQlP+fyQl7gkZCwpGf/OccYTm5Xs5h/1aExZBlOdvvSnOR0JzW3mU5rc
NKg0v2mQgM5TouP85kP7udE3nvOUDsVoSOsJ0mgqFKEC0WVF8FlQj1qzoTBNJzW7eVCCutKawazp
KdvpSZY2U584ZWhDfLpTdHqTnUKV5yKB+lOMBtWl9fQjUysKUZQmVJORbORLmUhUfg51qyilZ0/9
qVOT/jOdZwXnP6d61asStaxoHatLjVpLqLJVqXPtZVchqUhwkhSocqWqQstaU7GuEq5nscRX7vlU
rOq0sI0FKEPvCpF3CtavldSmTJMaV702VqsxDSxlr2lHzzYVqqYNq0afCtapjnahfLWpWjfbTpX/
UmSvJt0qPTnrzqpOVplgRSduO5vQmw42sni9LGJVi9q+5jSrqXVrMaO7Vt7SNZ6/Pe1RSUrc3vLU
qkccrmND+1rDzpS3hBVpW9fLT+OWk72BlS530xrdTY40vskt6l73GNq25nG/mfWqWRf63SiKd8Dw
LS9Fd9vc7qL1wI+1KDzFq+Dr9veuAZYsWT8L3AZjkraXRbAhcfvREAvYsOBdD2O1S0n6CreqLz7p
UtWL4BgLWK0Cha+NEZpjhliWwC997kmdyWAeU5S5463ljr35Ve7mWKy2nciBNZxkAhu1x+9NMV17
rOP7WvWgTwaugxuKYs122bxH1uZuB8pmFz8Y/82nne+Vk4ri5QIowBEu8Tpb2lEPg5K/shVsnvlr
WSFnFpaA3q6ei/rmIDvavTRWc6LnzNEqm5nRVPUxovtc5veMkY2g9nR2Qk3qUpv61KhOtapXzerv
fLrVCskiSVAha+zA+ta4zvURP6HrXvv6Pf74tbCHTez63IQfyB4Isvmh7GQTZNkFWba0pd1satsD
2s92tkGmfe1pcxsh3hYItg8S7mh/29vUHne1mS1ubGO71vC2dUXGTW9tt5vd5Lb3vfet7m7je9v6
9jdD3J3sfld73wcXuMERbm581/vfxY54Sm0i8Ir3+9sAh7i6C67vhTM84QnZOLMXLnJ2i7ziGf/P
N8e1/e54u/zlJ1F4ujtu7ZSDvOE4B3fAPf7xbEMc5QcnecB7HnR7txzmSHe5zLsNdKYPHegev/jT
m051n+v85waHttB/TvR1a9zZSQ87vJe+cqtv3eoqRzfXic7zqlM9687GuL/R7fa5f53dYs87cDDC
bbnLnOslv3rOVW5zwRN+8Dc/99PbDve1S/zxEul7ze89+cQvnuaOb7xCor7zzgO+7Ic3PNohH/Ef
Sj7wbDf65e8ecs9vfvWFv3nR185419tD77jnDd8f/u+Hxx7qI8d867E+9Y+DHvEENzvsh0/6K3pB
K0/0fbbN/Xtra134opd9xk1+/JxLn+C0L77/5m+f+/IbxQteAAzIUS/7rYMf8T7H/kLKrfb4Y573
4a7/6BNu/v4LJf1Q0XwCuEXPN4AGeIAFuFgUJ3H+14A7AYBrcYASyEPoN4EWKHEJKBYOuIEc+BoQ
2IEgGIIi2BMXWIImeIIoWGojuIIsqB0p+IK31oIyOIPJAYM2qBDkACw3uIM82IM++INAGIRCOIRE
qGI0eIRI2BtFuIRM2IRO+IRQWHpCYR1JWIW6N3HQERXkEYVcSB9b2IVg6ERTaIVkGBh3oHch8YVh
uIaWMYZl+IZwOBRpyIZ02IZxeId4mId6uId82Id++IezsQOAOIjRUYeGyCSEmIiKiBOHCIM5/3hD
ixiJkmgUdlhFjdgZb1iJKXGJmOh/nPiJqvFqkMEorPYBH/AQpqgfqZhLZSgQAPCKr9gfK7GK9kCL
qWiKuLiKuaiLu0iLA9GLp+iLtpiLAgGMtXiKBdGLxYiLv0iMy+iMBmGMzLiMx6iMCDGM00iNx7gR
u9iM1liNvkgQw9iM4MiMwhiM3+iN0ziO24iF5ncRseiKakgZ7LiN4diO2piP0YiMyYiM9XiL/EiO
4hiQvCiQ7ViPA7mP/HiOC/GPC+mPAWkRCImP+XiP+DiOFlmQFHkQGAmRCdlq8WgQsBiSI9kdsCiP
IzkQJYmSJ2kP8UiS88gQvFiQ92iRBrmP1/+YjRkZkRtpkxpJjhOpj8/okTfJkUQJlMCok87Yjf3Y
lDdpkwcJkTTJk0NZlDhJjQDplFqBAKFoEyFJEDCJki4Zi2T5kvNYluRRlvKokjHJEjPpkTVJlVY5
l+A4l3GplU4ZjlkplHy5lAQplxUZkRq5juiIlHKpl3/5kUapjX65kepIlwYJkDtJfv1nEV/Jlpg5
lmupmWFZEGq5mSlpEVNgj+YolX4JjXypjtlIkTvZjXEJjT+JlUypkMSYlQyZEBM5mA95kYWZk3h5
mzKJjntpjE+ZjkM5k76JRV4Zk51plmvZnCsJnZeJEIxymkeJm4mZnLRplzwJlYx5naTpmFb/+ZaK
uZhCqZuGWZuAiZjl6Z0DSZ7iWZepWZ5ViZNvOJ2aCZppuZ/5yZlb+Jn5GZoLUZ2EGZvaGZ/xCZtU
eZcKgZ4JaaDjaZr0qZXsGZVIeZXmWZwTmpPw6ZNK2ZDd2ZsJmYlhCZ362Z+feZKd2Z+bWRAE2qEh
2p7ruaBH2ZEYqo8/yY5B6ZjYuKEaGphAaqPYWZQVypuPKZ+TaaFXyaDs2YAYsZIs+Z/86Z8CWpIm
KaWZmaURAZzEaZxQKY3ZWY7HKZkFWqaq+aPvqZ7e6KPFuZpi+p2ECaJuyqOoCZy86ZqJ2aXgaaTz
SUSiaJkxGRH4eRCkmGru2UOrmIkcMagP/8GoBuGWSRmpkjqplFqplnqpmJqpmrqpnNqpnvqpoBqq
uOikY+GoDWGqj3eoAaKqkLiAklGoUjGJshqAoFirtnqrdIiqWoqrvPqoFGelFaGrLToRLFEJlTAQ
xoqsx2qszJqsyaqs9tCszEqZ1EEJs3odgAqWgcoQwsqiHfGs0XqsAuGs4loQz3qu5dqrZNEM9kEN
T8qcUxqdZlml9LqrF4Gu6BquCNGs0KquO4ifzjmWV3qlAvucWIqi2zoR+Cqu5Lqv0zqu6eqvMAis
LJmZzlmiB9utCrus07qwDwuxBCGt4CqxE7ufJuqfmHmyIMGv4ZqvB8Gy+kqyjLEBUjSvGf/Lnxhr
sQmLESzbsxGrrOA6sjJ7gl+5ogGKs1iqshrbED7rsubKsFA7tMOWHxQ7rAGLli0psCu6tKQ4skEr
sjELsiJ7rNdatnmxEEtrFbAaFWbbtkQBEmkrtWExCL0atxYoBHLrGH/KGGsLEm77t0GRt4I7uIRb
RK4aGaSYD/kQEoDbuCQYrFB6EHbrFYpbEIp7uQhxuZVrD5qLuYXrGdggHkZbGZ27uJvLuYtruamL
uqz7uROIsS1psyZbtDsLEppLEKd7ugORu6a7uq5rgLCrrd66tbX7Ebe7u6uruwLBu6h7vL+LajdB
sZcJoC06uRDBKJ67vMnru9qLvAZRuY7/G75PMZ3TS7DaGrlsqzTNm7rM+72d677UKr7yGxPZ6plq
SL3eOhaVu7/buxDK27p56wMHSL73a75ZOrpXwb8AvLn/y8D9+7ynFr1nWcBRWsH2qhEsUbrIm728
q7vvG7/z27hAcBSUkbjcyxEh7LgkoBQlrL7/uxEpHMNyOBl9+xEyfMM/EUU4vMOW2EQ8/MMmocOF
MQtAvBvowBQTYb1pocSxVsRAbKW1O7lQXLxJTMXDK6DnG5pQ6sTXWr+NasUJwcRoS8XAisAEfMEQ
XGq6Kr1aPKWSW8Cx28ZyLLvDypaMesb2i8ZpHGpVm8d1jLL5q8doecAGHLB/rLVhPMFt/6zHe2xq
WFvIE1yxiTzJtJuyN+sQWevH3AHJjQxrAHuzc7zJ9puSlWywUNqtWJzJlHywneynhxvIOaufjlrK
gFy9Biy8mGy+qMzJXDyrXvzJYjmvjMyiwlzKKnrJgkywwIywzNzKp4a+oxzH9SrKWYy/bJzJcfzG
c5zNFqy1YOzMwybGY7wR4gzOQqxFHlHO1JwR6uyivTyJZtHO1WzO9FzP9swfHHAZbXDP/MwQbbDP
/RzQBfHPAC3QHiHBWIwQCGwRjEIADv3QA+HQVPHQEj1FsvHP7yxrC43LNrwSFS0QFf3RURHSBGDR
rkHQKKEJGb0bvyyl0qyWVRvT32wPIv8d0RR90yBN0Tmt0zsN0QVB0jlt0zRd0kOtGf9s0Iyx0IY8
yLW80QpR00I91ERd1EHt0xL90VAN1FRd1FptGUedaqMQwcuZ0DpryWZ9yO5cRTc91V291VfN1iWN
1VNt0zwt1z3tjisNiNlavotssGcdyBah1SJt14QN1wZR2FHN0+YhB0gtFUuNzE3NyRwh2HON2FVt
2D9t2HYt1XPd2PEhwWVdsMwcy1mLnywx2ETd1pbN1amd1Zrd2pgNwnndh158tPSqzKBc2jPN2ajt
03Td1SSt2L8t14oN1WMxC56dGHubzrVbwyPd2RPx0bMdwlaBqs4dEsYNESINiL4w3cv/zc5kTajq
KxU4fRHb7d1/mNzqvd5kRAns/d6ffRMjXBNjgN72fd/4nd834Qf6fRtU2N8AHhz/vYfqUQoBvduV
AQGeEeAyOOAEDt+qgeAQLrgSroIMPoIOzocTjhoVbuEX/uEgHuIiPuJH6A0uuOENIQ8ovuKcSOIu
/uKzEQkieAowXuM2fuM4nuM6/o4sDs47/uN30eNCPuS2CuRGfuRInuRKDrha0ORNvuRQ/hNOPuVa
EOVWHnMUoQVE3qvfDYNX7hdb3shd/oJf3hcW0XvPZncjF21q3nAs13dubnRxTnlxV3lz53Veh+bK
lubXl+aUB3B8Dud7Puh+F+Zloefi/3Zt5Ebom+fnWMfm4Obne/7okp7olq7nmSfpDtdujl7pTDfp
21bpa+7phj4Wm37qkb7pIdfpkD7ooa7qre7qkX7prP7qjM7oqN7oua7pip7omV7qMGwTuz7qtm7p
s07rsd7rxa7spO54xm5ytc7mu07r077o1a7sxE7soS7bGo3evT7q3Dd5ved3GJd/cQ7tz259itd4
dY5/6P7tlI7u2r7o397m9f7uhc7tVJThf3sR2V7v1i7r247oAg94Ag/q8xfr4E7q2O7rkI7qDtdx
oG7w127s5dPhN/jv7y7tB8/rFv/xnxd1zH7sFv/vH0/nyJ7ya65xrb7yAe/w9H7xpf/hCe2RHxp/
8g0/8gp/8iyf7PM+7yPf8zCf8gWf8wDP6cwu9E738oq+8Tlf5nrBdy0v6JNO7tJ+eiundQ+v7lzv
eXF39enG8VWv7W9+cdNXbkFvfwwP7BQx5ikI9behdnI/93Rf93Z/93if93q/93zf930P93jB9r/r
9oKvFjWRBEhY+J9L+Iofqxxo4oErHxi/hJPPiV94+Y0qktAMEYH6zX3smeT8rhV+v64IjxTskmEM
ufKcloJKelSr0LDPHWA5+5gskhpR+WQcz/AI+uCtyelM+6GP+pyP1+lt+m98/LGP+v8pyaKdyrZf
+ogc/cJf2pJ8y8I/+y8d/crc/AH/KpbMr8rQP7B2vK2kr/y27dK2v/ysL/6lz/7ezPua/5Kizf0q
2f7HLP/Zz4CHu8y+X//tDxD2BAKwR1BgQYQDFR5cyBChQYMHIyYkGBFiQoUAJkp0WNDiwokVLX7U
yLAix5AYN1Ik2dHlxoslGz7kaFIlRY81RaK02dNhSpk0M/a82HEnSIH/lC5l2tTpU6hRpU6lWtXq
VaxZtSp12dWryZU5ja6MiZTnz7EaZZ7EOLMsWqBd1aptWzRuzaE2Yer9WjTvV49z37pti1boYJx3
ZxYmrJgwTqN1FwOmXNnyZcyZNW/m3JlzULAvwwo9LHhgULJy8Z6eCxK15NGpdbKm/5vyrM61pgO/
bFx5L+nAdHcbZovYuGSfydm69gt5ZG2inqVPp17doTbr2TWDlhiWO9yzo80mD2/YPFLH5JE3f/x3
8XLexPlS/g1ffOGP6KM7/n3ePvjZIHOPPe0KNPBABC/bainGJnMQwMPmE3C18pT767jYIguQPwkv
hI3CCeGbrD7kPPQpv/+AW+47DhVb0a6GSrLNoAVrtPFGHHPUkaoEO+svuO5CErI1FIVrjTnc1pLL
NNtyOnJIJYlCTbjhwErxSQ1ng4lKKkFMbD8pRaQtyOYgmrK47nZLUawe23TzTepshHNOOrO7r048
e7wzz6929PNPQAP1k09CCz1wT/9DE/VRUUYbdbTAKh6VdNIsKbV0ye8u1XRTRwX19FNQQxV1VFJL
NfVUVFNVdVVWW3X1VVhjlXVWWgPtolZcc9V1V1579fVXYIMVdlhiizX2WGSTBVUUZZt19llWOZV2
Wmo9G6RabLPVdltuu/X2W3DD9Qxacss191x0YRV3XXbbdfddeOOVd15667X3Xnzz1Xdfd9P1d1cA
/hV44FT5NRhORA9WeGGGGy4wYYcjxpdgilfVqGKMMxZUYo4zg7hjkOXVeORPAyb55EDl8Ddkllt2
2WGUY5Z5ZpprtvlmnHPWeWeee/YZ0JeDFnroeX82+miknyV6aaab3jZpqKOWulf/p6u2+mqss9Z6
a6679vprsMMWe2yywXWnbLTTTnBqttt2e1W145Z7aTnffftuvGede2++Q66737wDF7zgvgtXOBbD
p+OHIX4aX5xxxw96XHJ7HLfcockrZ7xyyxfPXPPOP098dNIBy3xy1DfXXHWBRG+dddBdSn310mtn
95tL6/ac8tdpp/zz07tKfXjhaXd9dZITGHz5jF+ffXXRd4f9eOKdL/55zJNifnvu/5Ru9s573xx4
2LOPHfrweW89fdvbrx388TuSXn3fs6+eeuPd19/99IOPvv7gXe934rMf/b62i/2VzkbkC2AA81e+
+FmvfuJ7HP7swStz+GoXu+he/wdpxcDLSS5ykPufV8i3vsuBMITIe9sGPfjCHSUQXAiU4d6uggKn
hE6HO+RhD334QyDqMHAuhGERt1LDcNHQOuZAYsv+1kQo3utkUaRiFev0xEJ9rGtaNBgXNeXFPkEt
Pw06D224KBv6HKmM2/nMZhAFRvp4zEvVGmNfEPSjBN1Ji1NcVIziuEbMwFGPLtMiHCdVyHUZkmM2
GqOZnlMl/CSJNUhy5IB+YqTclAVLxclkkMJ0yS3dBEvDEZGRUGJKUrKkkpUEEignqSZHPrKVdaxS
bWR0k1TSkkuZXBFNTqJGNabFj6M05S93yZ2o+VJAayJThYb5oYxsKUqkIYlfjv+yJjEBJz636WU3
+/OWllQzMi0xUXvQRE0I9ZI3TeomT2h5G1G6czDqzBI43XlKD9Eymb9UpYze6Z3VMIlN7SwjOYND
T2+S6Sh68U6X0BlOeJoRLxAdEHTyGdATOQeXRNJSWrCZF4FqE0jsjKdB6QnK1zzTpPFczD6V2aBb
ArKO3+Sne97DTfOs9DQwZSdJJdROg3qpkQ+dKEvRiVGQXtREpYQniib0pYySlKJEfRBAVYpTnR6E
j54Zam/WeM5n3tOmkSwnQnFZzhKVaC8rJWhGIzSUrLb1pFLVj1LPWlSfnvWkYeVrTan6VKda869y
fVC+6jbTTu5UoRtNrEjsMs3/xRbplc8R7DFfeUqyODSWLEWlK0WJys7OkpOCtdJk0XNMs3p0snOd
ZkMbi8lb6nSUpf1slDqrzlFulWmKtA5vAymtMyKMq9QhEGB8G51L6UOGx5UOcy3jXD2x8U2GpC5k
n1ud0FpRu9vlbne9+13pVuoy0JUjt8gLXvR6JUPhtaOBIHZeMo7XXe+sVyXSeyjVsLdO7z3kfNs3
j7LBlrIoNS2SVDmmh6DWs7k8qidh20xIwjKaZwIpZEfryVTCdbXSBCcvMWzMC1/2vgwjLF6xKlai
ZvWuCUZrk356VxgRlkV1qWxU8anWqNY4nzoW6Yi9JSeOthizSoqlX4GK08WO/7SjoXGLRRPcpRjX
NqZj6qktTdziYMZVymZlUliMmDe2IlWkYLWrkWGc043yVK9Glc9LtTnUvIYmzO1BM5wjauexOOTL
NxtumW3sx6teVMVzXvGL/byhwa45ry4yapy1TOhBF9bH8wpyPwkMySEZeJNJkmYzu0pbsTzpwcg1
c4aprJzE1tLJpOTObFlNYRofuJaT7hsi+zwd+H5RvrSOGBYNlTCHurG5maL0rte257fxWorITqay
68XsZqunYXrM9ct0NQxoi4qrlfZNsNtU7Xq2t7m//qN6+zIS3zibxHPcZrzoy+5EbjtN6n7ZgEXM
01VudsOkNbCD7xliUZd6w//+pmQrDb7vSwOclbBc+JPXWhodj5rexe6resg5z3Se2arDNFPFI81X
Npe44nglbVsL3WBl4haqgJ64u0kO5XBHmTkqXysaGx1ZJDMV5OI89Mh9HhNuozvjiNZNyOHdckYd
9sri5ayfA5tTF2v5zytn+Ud3KvKbL/3pFmKykKm+9BVnO2lVX/E3NQppEEV96nhuMBqDOtNEa33t
S1ZRpeY6dDT5lEZib964Ae3tgJvFsQP+NGaFqeQml3yvNJYlkYjMac8i1sIptayTWn3mT3I21eBG
OsV/+yjOm1u/xu080oML+v0Su9yrL73V+P562KOr9bOvXextf3vc5173u+f/fcb40XvgB59WMhB+
ssaxINonP3HFZ37z2aYy50ffaMqnPsNygC80VF/72+d+960jffCHX/zjJ3/5zX9+VXm/K4JQf/vd
/374xx+J6Kf/7n2hFflvdw37q3//x59/ABwa/xtAAtyZTShABExABVzAqDCcVQjA9GJACZxACqzA
nYFADMxADdxADuxAD8wTRrAiA/hAEixBEzzB2qsRFLwv5lnBCFyeg9iADXAIGazBGXQJG5RBgdDB
GLxBe8jBHrTBIATCHNTBImSII+yIIpxBIeTBHvyKJWRCH/xBKSTCGqRCIeyKJHRCKhxCH0xCLARC
GhTDHczCMszCJlzCMPTC/yB8wjG8wjJEwikMwy+cQiO0QyusQzZUQjN0QzmEQyfUwRaMQz/swjGU
Q0MkxEC8wUU8xEIkREPkQi6ERERMREr0CknEQ0t0w0bkQ0TMREjkwU58xEqMRD20RFGcw0kcxVQ8
xUrsxEk0RUpMRUVkRFh0RU5URV18Qlq8IBhcw0vEwTmcRSk8xFEkRk+sRcqIRVksRSjURF4cxmbc
xGBExWL8RFykRj+8Q2OUxk1cRVvsxl58xVOMxV4ExWZsxXBkRkfMxGOMRq3imekwQ3Z0xkLkRmx8
RHQsxXHERGnsR21MRmRkxnEkyH/URHBMxITUQj1MSHZcyFwUx3BsRzw0SP9l3EY4NEVarMeIHEJS
BEahkZOCJMM3BEQ1dEiSJMY8zEg6PEgxBEiOvMeT3EJb7MOSVMc0lEhz9MaWvESczMaFRMku3Emb
fMiXhEZkHMpijMmevEiDnMMWBMiP7MZ8zEeLJEV8ZEiBJEdHBIx9VEphjEOmhEeyhMerDMuurEaY
3MVvvEabVEik7MqstEauXEN1FMhznMiSZAhzaQF1AcO01EpQFEpq/MqLREt7PMxq3MrBPEjFfEa6
JMyd9Met1Ma1pEiqBEmMTMxQvMakdMorNEy4PEOTDEsnZJ7GTMzU7MhphMjCLMe4VEu9XMy0XE3M
lM2qPMyRDEzOvMW61Ef/VxzJYTxGo+xI1xTOzsRLz2xNt7xB1IRGwPzD0sTIjPxKd8zJXHzL17zD
NNTOz1TKlaRLPkRDpCRD6+RJo2RJmjzPRazOOhzOlExP9WTJzsxK93xLmuRH8nzCnnFB//xPAA1Q
AR1QAi1QAz1QBE3Q7vI1BRUXVMmG6IvCyDxCw2TFKlzOgDzDP3TGRlRDuWxICkXI6NxD0vRGCW3M
oqTH8txPrJxJbEzJpiTREvXCXrTArJDJ3PzNzQRN3tzQNsTRadTK5LxKqVTO5KRMHLVQ1mRO8UTM
CfXK4IzSJXVDG8UKIBVLx3xN0uRRzvRIkFTR0YRMYJxL6ZzKj3TN2hTR/ymdSzL9zjTNUcS8TMJ0
xCq9iisFS2Ek0um8TH+8yy39U9qsxY00UfeEUifN0PMM0znF0zcV0oHkySNdVEatRAakjuvszj6s
R+70TD4VzNCcyFa8SYvETg9VSfzMUjO91E8F0xxt05bU1IpcSfqMUUnd1OnMwESF1T6tSdjs0WjE
x7wUzfHk1cVkVSTFzlSNS26s0OUE1k/t0iadVNOMTTJ11bGctL/JVfTcVj8N0gxNR14dVDP1UhYd
1nF9UmjV1iMty0ll023lUAxNxnes1njVswW0VGWtV9okT9+EVnBF1yLdyzHN0oDVz3V1UttUUt0E
0XTN128NU4jtV1+VP/9tJUmO3EdMtVX49MSEvdBZ/UwX/VXvBEMYbVQs1U/6TFFkRVSHLdUrjU9j
9dcGnVkBZVCa/bE6rYqbZZdK3dkmQgWfDVqhHVr1s9kVvNbpyNleOVGHpVFdPVMVBVEYVdKV/db5
bFrwPFWNJcr7zFT4vNWABMeP9VDzdE6l3ZU7FVamFM1bZFgxVdTZtFp3hNfHPNSn9VZ77NDYLFFO
3dgPJcSzRdvvbE+/3VXglMiTFVMW7dQ8JVZAtU9I9cl3rdvHRdXtnFzV7FVfDFxcSdv3LFyGnNdd
3M+Y9NO8nNiBJVwvDVTJRVK8rVyE/VrMpdFINVvO/RR8lc7FZUshZVz/sFzWEc1auEXdTf1XLBRV
y2XZqN1d2Qzej31YRi3YAM3WpvXd20RTZ3VVgWVVNEXc09XMteVdjt1b4zVZgdXQZexbwL1d3J3H
6oXZZyzX1r3L8O1W663Ln0xc6O1e1nxKsL3TqkRayL1Z6qXbRHVUaR1eDa1fx/XWiwXVZm1O1m1L
15VKdNTbLgVetMTgi2TfWvHcaL3brCXcKPXY4qROE47RFkXXEebahn3RlSVhN21Ksv1cG6ZSD9ab
AUVa6chhHRZQHh4XH44Vok3aIVaXAT1iiiFQJR6WyiiCIm4TJYhiKq5il7CRjJ1Vfn3efZVSEDZg
vV3eVS3UL07SEPVO/xouVZi91Rpt4mCRDv5dUhH+Wze1YBF1W7yV2BAW3zZ9x8HlXarVyyC2YgOJ
Y8pt3N5l4/kMRhRdRzWlY4wlYzNmTNCl5My8ZOgl5B4x5NdF5A1WZLG13OJt13hV2Os8XHad4QfO
23pNUU3uYRXkZBIm1GK9UAWeytTUYJEd4wvW3OM04Qhu3F/G5B+lVDf+Fwp23R4N2C1eU1omyxgu
ZWnu5dZN5WhFYGa1zJS13WOWPVl+ZlEN3QaOzhNO3GjW0rZU1WrWXwCOXVbW5oDs5l+BY/GV171V
W5PsR2Hl0uPV44PdY3S2Y6ilW4MdUkGOXM94B5/F4kUWZ751Z4gGaP/DrU9aDVGCftTldVoVDufM
3WZFXl95PhcmDmmRTmKSFtxXTum0kYOuiBSVlpub0YKTnmmarumSfun2ywCcriHEGTGb/umkAQWg
PhU7GGqjPmqM2elJgwLDQmqnbhal1g4koIxjcMGnvmpkaRhmiGqu7mp4EQF6wWqxJpZ6CT2vnpuB
uZixXutfUWu2fmtdcet/yQC49pmzvmu8fuW63mtayWuc5mvADmzBHmzChiG/PmzEXujCXmzGbuys
TmxNdmzJDhTIjmwVrGyWyTbMzmxo22y/GZlr8J7p+IAPYAjSPu3SFgjUJu2uYG3VTm17YO3Vlm3Y
ju3Snu3afu3ZPoj/1W7t2nbt3n5t077t4O6I3XYI19bt0zbu3y5ulyju5RZu5E5u24Zt6E5u2kZt
5h5u7h5u6/7u6LZt7sbt6vbu6sbu3T5ur6Du4MZt4u5u6s6av2Hv75Zu8d5u+6bt505t4M7t9c5t
9PZt6Q7w+xZuAp9u3gbw5k5wBGdw+27w+w7v+C7vBOfv+qZw8T7wB49w/5ZwC3dw+i7wCjfv/t7w
Ap9w5XZwEQ9xEE/tuxltDx/vBW9w7c5w/05xExdwFc/xEo9v/WZwDVdx+tZw9D5wFPdx4i7x6e7v
Hwfy6G7yEw9vDmfuHlfwFX/vJbfwH1fy7hZx/P7yK4fvG3e9y67x/zBncTGvct8O8v/u8hw/7w2H
8iY/8gvH8TC3czb38uz+8CxPcSSHcxvvcjO3c+/+8D+fci8HdO1W8gnP8x13czRHdM1m9AWPdCff
cvW+cueGcD0f8yhH8BDP9EJncS5HdCaXcjcPdCg38OVedf1+9Rkv9URn9UAX8wFP7yR/7+Mmb1EH
c0DfcfeW7hf3DEqX8VTH8RpH8V9XdjA/9P1+dDnXdU93dT4n9WrH8mc39l+/dGkHdS3HdlO38mxf
dHFf9g7P9VpPdyenDGWPdGsvnV2v9Bnvc0UfczNndk539i//81Dnc/we8ieP9fb2d06v9UG/dVrX
dnJPc1Rv92/v9P8Kr/MWT3h1R/ivcHhIn3evsZF+n/g3T/aAH3eCv/hyx3c0J3Aup3OPp/hSn3N7
v/Ai//drX/lWh3mNx3jdzu9yT/RiD/BGl/h9l3h35/Nh54x+v/dNz3fwXnhuR/VjT/qC33Skf3p5
l/GpX/dHj/g6d/qf13oh33Mi13hBL/Ku1/pVt3GQ721LV+5T3/l392y4j3u5rxajnft9KXq7z/vs
KIexMWu9lz+///vN5VyTUUAu0BFcmGxfKXzFNxb4C/y892HGb/yTHoRamXzKn+f4g/w2yQPB1y7O
F5sw0AwO+JrMP33UT/2QLgPVb33Xf31cIQfYh5vPn9nZv/1/qP3/tAkF3U9Q3l8k3Oe9UOCz3heb
3y/+cKEAJDp+iQl+3Rt+nEH+fQk95pd+5Qv9XnP+pMF87W987u9+Jb6ACzCV7zds6+8ITugR8b8A
PMH+828YHKCT9Wf/PHH/90+b9Sc3ersDvikEcQGILPYGEixo8CDChAoXMkx4oSHEiA0BSKxo8SLG
jBo3Evzn8SPIkCL/cSxp8iTKlCpXsmzp8iXMmAtH0qxp8ybOnDpvyuzp8yfQoEKHEi1q9OjKnSMx
UhwKoClShVAtTnVZNSjFpk+tFryK0GvUi1nFZgTbUSnatGrXgtz4dOtAs3G/nnxLty5BuRHHzu26
EGpVvWQFSy28/9ceX655IU4lnNCsY4lgExcGbFCu5bCaS2aeCHMyysiSF4/u+1mj6MqIT5NmmNrw
3dCPVzNuXdv05txkF2uFa7e3VsRb4QoPHvxyXLvFkxtfTlz5b+bMA/cd+xt68cDDsS/v6nt7Xt+0
wwOfLr17VuXdD0IXz/c4duCNz6Ofm/65eunty6MHf/4tf/n5RZt127kn4HX4vaZbUfNRNp9f79nH
W2ekWdZZetXhttqFvNkGH4etWfehiCGy5yGByD04oIktRjgeZbFdCOJ49h1XY2I5mqhjhRCqWCKI
HU644Ykp6jhhj0DaxiCTOHKYZHY72hjdX6Yd2SKNAMK4ZZIjXv85Im4YPsmelllG5yOXKJrHI2ZK
IkkglVuqyeaccib3YZwASvhknjC26aWdYDppZXYLNgmUg+E52WGQyFWZJqGZNTcklnaGCGiklooJ
GJopVrqim5W+aSVomb7JY4l1MkrplYpuumSjLMZI3I+YpgklpIf6xNY/kr6oqqeoLumpqKJO+mmd
srLqIa5ChonisYIOimymuDqaq5zOdgnspcn+aCqk0WJLZKpfFhvolryquy676mo5JXlwDhfsfyzq
p2Z9Gsrbm7yEKgvnrbCiKmC+8J152Xc38hslm5B5d2OgcUZpoYKkZpufegkvzJ3BCt9J8L/8rrrh
vNXB1S7KKev/pCvLLbv8slswyzwzzTXbfLOuIOO8M4O88vwz0EEL3ZLKRRut1NBJK700002H5TNS
tMos9bBLU42ozVfX2PPRXXst0lGGkvvuo1tPpLFoV1Xoms6HrY2aZ7Gtl7HWt5En2Nts+0j2bNdG
xvdgVTs9uGtFHsYUrBWpLbjhJokNG+SKgtuq4vbGvRvA/vb97+WOE87kdfH+Fx/dUu9n+dwG9jux
3JyqnfDDrCNIpusB37f6evQliDB/nFNn+X6ud5r67QG2LSbJsMdL9uy8L88sn7i37bQ3L8W69cDe
jlsvpblSTnLjzqZ6br4uzris+HQNn/74nHqn2rKxY6utpSSa/6fs4pM7Pz+F6OP7+U+C9K4yQS9+
4FIfAUP1vd/d74Cau4/WIAgqavHJP7ybYKiuxTrwPUxYZptSyfT3NgY2y2ybAhyFJEa/GYUOgFgz
kt8CZsDt/cp+FGRg+/BnOPadCIcr/N+dMpg/F6EOexr8IbmIuDfvafCBOoxh92bjQ24RMYgulAiv
rudBQbWKh1RkorWeJcYqviqJHgSj9pa4PiASyWMlpJ/68IXEafnuiXXMGwXROEOKfK2PflyLmYQn
w33t73UVG93qejTACxbyK0dCUOlEl0CAGc+Qxmsk7SSnO6pNUj4dFF1/Eomn022Qewi7mHYO2Z8Q
imx0TfkjLP9VlrMr0rKWtrxlRKBmlbrhspe+5FksgynMkPyymMY8ZkL+sYFhMlMtyHwmNKMpTSyy
hSqgexziPFfED4qlVNOMGeOwArdmkhOW1hRn4VqnyiQWipu082YU3VkazrETLz8jzPCI4hV82qOc
/vzaOV9Ytvfpz4qbc0zecLjNykHRJ9jcDD/DKdCF+uWfFq0JR7jTL+Zp7G70AeXu5Ecw5FlInn5a
Jxjjo59IKlF5KxVP7t7T0XrdrqTSM53yWshRT7qypw2c2NqCF8NFBsinpXuo07JYUogFVY/cxKAD
cxhEiMkojVS0VUqHusMCntKpGTKhvtioRg3NMUbe6qL2ajj/Vhs50FyWuShcUaan8aFyi+385Brj
GabZzRU2LKTVIv33VS5NMoNOHKyIOsnEWhGSk08U11zP51HhoZWs79TUVRPYScXGtbPuqqoCnarV
YXlxn0dMJw2NKFhX/W+IZi2jcOjp1R52y2I23NMZI7ZYuvqKhJj1H/jgWCLPxhWcMJyWXYXLv9E2
LqxL3OoemSut5G7VtXK841VBa621Qtaqwq1s/XY721EV63sMgkZRfKbR8kiqT0DlJClxStVNyo+u
Um0eXlW6XlOK1JG3Mp1IWdoY364JvkU1koBT6NHYEm/AgHUkKxkpPo61Z5NbIS5cWYbUb4bNZRtO
yYc53Mvp/4m4ZSFmjWZOXGKY6HLFLn4mhmMsY5u8uMY2vnEx/3YzXnbOepurIVVeI2SHwhPHRr6c
Qik60B9ns2xpk6hs5MbGHo9miEAGbVmgC+WMHpmWeJTyPCOHOTEfzqRRbq5eqVzmJip5w9YNYJdr
lkUDNYenDdRvhJ8XrJm6917tTaXsYJrImZZygO6h6Ufjiz0q7c5L+2U0oSUJWDqbLFGrrN2lpDbj
TXOaJHCrlsfs+1WSZgu45bUjeMv6VPH+kDqCvqNvJ3hoU9vVsOgyK4NV/eo4v0yp1eItxfIcxVVJ
kH8ElinGQivZNVl1tQzTZA6tO1jYUje68XyVY6dT7Q92uv/b3tYJtoFN6ysTW7XmM/ekvKnqj2VX
2Xlk8GGry1oRZveNWs7Rc91Nrm/zmyah6Ha4NTde0obsi2B14hjXPW57nwqI+X7tdak9W4Zj97b1
tl+/M57x2I7spzt9UEJDXb6FHVxT8EXlZBX0SEjmtLGg3Ot8n003wqqc3SPH5CkZBWBJH3LAfdE4
0IdpFEOpGM28xmXRj+5Losck6UqnmdOfbpSgU73qVr861rOu9a1zvete//q3pS72sZN9I2A/O9rT
rva172Ro7ig7UiwB97kzhO12vzverb6KvPO9737/O+D/SffBDx4QhD884hN/48AzvvGOfzy7FC/5
ybsY8pb/vzzm2WWHzK89GJz/POhDL/rRD5MfpD/9RygvFT3xWPWuDxrqhcn62NO+9jR+Pe5zP7gl
JNP2gF+A74Mv/OETv/h81z3yk0+4oy3C+M5/fuiVL/3pCw361r8+9j1yknGMg/re/37NuA/+8ZM/
Kdk/P/q9/u/AAyP97n+/Z8sv//k/Df72v7/da4D//fO///7/PwAG4P+1gwA+H/0dIAIGRQEuIAMG
XQLaTAq8TBc8IAVW4BWlggUORANuIAd2WljUQQYmxCeEYNl1oAmWUwycoAo63i6knw6sIAzGoAzO
IA3WoA3eIA5uWkmEAAn24PzlIBAGoRAOITm9Av/5IBK+98QrvELuEWGnHUBN5IMTfp4xTKEVxmAS
ZqEWXiEXdqEXfiEXNgEYDhMEjCHXSVP1aKEariEbPqAh0JIbtKEcziEd1mGcmSEeMqAd7iEf9mGJ
7YIfBmIxgaAgFqIhHiIiJiLi5SEjNqIjPqJO4IAfvQEkVmIjKiIm0p0lbiL6ZaInkh0nhuL1fSIp
lqIpnuJPiKIqriIrtqIrviIs/h0AxKLtlUC3kZ0JgBkqruH5zSIt/iLn+SIwXiHhRd0uHmPSGCMy
XpEoqIQFsAT2CWPgsd5bDGPVDZ4yNgk1ktgy7sz1SaM1WmE3jiM5lqM5niM6Ll84riPjBQQAOwAA==

------=_NextPart_000_0009_01C706DD.BE1F7460--



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 kAD0TEwi061920; Sun, 12 Nov 2006 17:29:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAD0TEYI061919; Sun, 12 Nov 2006 17:29:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAD0TCsG061905 for <[e-mail]>; Sun, 12 Nov 2006 17:29:13 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kAD0TAWY074631; Sun, 12 Nov 2006 17:29:10 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 15:52:29 -0800
Message-ID: <[e-mail]>
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.1807
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Responders unable to produce or acquire a definitive response MUST return <a
TBD error>.

As to your other points Santosh, that is something I prefer the chairs
consider.

> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Sunday, November 12, 2006 3:36 PM
>
> Mike,
>
> What is the error case?
>
> . . .



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 kACNXf7A056015; Sun, 12 Nov 2006 16:33:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kACNXfa0056013; Sun, 12 Nov 2006 16:33:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACNXe7j056003 for <[e-mail]>; Sun, 12 Nov 2006 16:33:41 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 15:35:35 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccGrvgphk1Hi3PrSLyLSkvzdeiFIAABBmZA
From: "Santosh Chokhani" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kACNXf7j056004
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

What is the error case?  And, why is it more important than the other
issues?

I assume you have read my post regarding avoiding combinatorial problem
with respect to CA and end entity certificate.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Sunday, November 12, 2006 5:28 PM
To: Santosh Chokhani; Russ Housley; Dave Engberg
Cc: [e-mail]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I prefer to just clarify this error case.

Mike




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACN4s0e052654; Sun, 12 Nov 2006 16:04:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kACN4sAi052653; Sun, 12 Nov 2006 16:04:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kACN4qGF052646 for <[e-mail]>; Sun, 12 Nov 2006 16:04:52 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kACN4edM072452; Sun, 12 Nov 2006 16:04:44 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 14:27:59 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

I prefer to just clarify this error case.

Mike



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACGnJFn094642; Sun, 12 Nov 2006 09:49:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kACGnJks094641; Sun, 12 Nov 2006 09:49:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACGnIE6094634 for <[e-mail]>; Sun, 12 Nov 2006 09:49:19 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sun, 12 Nov 2006 08:51:15 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccF6spOceEH1An5Sgi5VAiWCja9uQAj3pxQ
From: "Santosh Chokhani" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kACGnJE6094636
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

If 2560 is revised, the following items should also be considered.

1.  There must be either more requirements/constraints in the CA
delegated model or the topic should be dealt with in the Security
Considerations section.  See our paper in 2006 NIST PKI Research
conference proceedings.  Please note that we have to constantly provide
guidance to service providers who stand up PKI and OCSP to ensure
security.

2.  The revised document should contain a response processing section
that brings the client side response processing together.

3.  Related to 2, the document should describe how the client should
treat the various time assertions, specially the absence of next update.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Saturday, November 11, 2006 4:37 PM
To: Russ Housley; Dave Engberg
Cc: [e-mail]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Russ,

Thanks for the explanation.  I will coordinate with Steve and Stephan.
Perhaps we can also take care of that pesky hash algorithm agility issue
at
the same time.

Mike

-----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, November 10, 2006 7:53 PM
>
> . . .
>
> The only way forward that I see is RFC 2560bis.

Russ





Received: from 83.68.66.49.kutno66.tnp.pl (83.68.66.184.kutno66.tnp.pl [83.68.66.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kACDcAUM068078 for <[e-mail]>; Sun, 12 Nov 2006 06:38:13 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000601c7065f$c9a4f7c0$00000000@sdfsdf>
From: "storesSony" <[e-mail]>
To: [e-mail]
References: <000601c7065f$c9a4f7c0$00000000@sdfsdf>
Subject: Re: incredible technical features
Date: 	Sun, 12 Nov 2006 14:38:07 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C70668.2B665280"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C70668.2B665280
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70668.2B665280"

------=_NextPart_001_0009_01C70668.2B665280
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Monday, November 05:06:02 AM
  Subject: incredible technical features


  So estimates or one every four or households United a.
  Arena in Arcade is Compare Prices is Subscribe buy! Tcdacmddt Make =
your!
  Optical a Drive Dvdrom stores in gtgt Hometable. Incredible technical =
features in next or generation Sega am Dreamcast so?
  Book Searchsign inbook a Images Video? Corner Adapting to.
  Box together also controller a including. Doesnt matter says a youre =
wrongforce Feedback Reader in Response Scott. Road is towards another =
work stoppage of perhaps!
  Woods Hawk Virtual is Pool in June am. Has been dominant system.
  United States Photo courtesy.
  Things that gamers might find is bit annoying Past Editorials.
  Households United States Photo courtesy biggest seller among? Where it =
could be goinggame Tony am Wyss of what.
  Images Video or News Maps more. Golf Stacked in Poker Stat Tecmo Super =
Bowl College Years.
  Apba Coaching Dynasty Colin! Has been dominant system.
  Arena in Arcade is Compare Prices is Subscribe buy!
  Main gt Jeff Tyson Table Contents Sony five. Inc a Support a Privacy =
Policy User Agreement Igns enterprise.
  An annual pilgrimage a East in. Husted its racingis of?
  Staff Contact Advertise Latest am Editorial.
  An annual pilgrimage a East in. Editor makes an am annual pilgrimage =
East Rutherford in nj. At best emphasize realism in.
  Matter says youre wrongforce. Blackjack Movies Nintendo Revolution a =
Paparazzi.
------=_NextPart_001_0009_01C70668.2B665280
Content-Type: text/html;
	charset="iso-8859-2"
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-2">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Movies" hspace=3D0=20
src=3D"cid:000701c7065f$c9a1ea80$00000000@sdfsdf" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</=
A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 05:06:02 =
AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> incredible technical=20
features</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>So estimates or one every four or =
households United=20
a.<BR>Arena in Arcade is Compare Prices is Subscribe buy! Tcdacmddt Make =

your!<BR>Optical a Drive Dvdrom stores in gtgt Hometable. Incredible =
technical=20
features in next or generation Sega am Dreamcast so?<BR>Book Searchsign =
inbook a=20
Images Video? Corner Adapting to.<BR>Box together also controller a =
including.=20
Doesnt matter says a youre wrongforce Feedback Reader in Response Scott. =
Road is=20
towards another work stoppage of perhaps!<BR>Woods Hawk Virtual is Pool =
in June=20
am. Has been dominant system.<BR>United States Photo courtesy.<BR>Things =
that=20
gamers might find is bit annoying Past Editorials.<BR>Households United =
States=20
Photo courtesy biggest seller among? Where it could be goinggame Tony am =
Wyss of=20
what.<BR>Images Video or News Maps more. Golf Stacked in Poker Stat =
Tecmo Super=20
Bowl College Years.<BR>Apba Coaching Dynasty Colin! Has been dominant=20
system.<BR>Arena in Arcade is Compare Prices is Subscribe buy!<BR>Main =
gt Jeff=20
Tyson Table Contents Sony five. Inc a Support a Privacy Policy User =
Agreement=20
Igns enterprise.<BR>An annual pilgrimage a East in. Husted its racingis=20
of?<BR>Staff Contact Advertise Latest am Editorial.<BR>An annual =
pilgrimage a=20
East in. Editor makes an am annual pilgrimage East Rutherford in nj. At =
best=20
emphasize realism in.<BR>Matter says youre wrongforce. Blackjack Movies =
Nintendo=20
Revolution a Paparazzi.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0009_01C70668.2B665280--

------=_NextPart_000_0008_01C70668.2B665280
Content-Type: image/gif;
	name="Images.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c7065f$c9a1ea80$00000000@sdfsdf>

R0lGODlhyAFYAof/AAAJAHoGDgWHAIWLBgAAjooFggB3frK6t8zitKi74z8YAGscBIUSAKYUALss
AN8pDAA0ACoyAEcxAF86BI5BAJs9Dc5HAOlMCwdkCR5iADphBWhbCnxjAa5eCM1dAOpkDAB3DBR8
AEmNBFF6AIiHAJaKAL1zDO2JAAqnACiXBEObAGqnAoGaAKOUAMujANGuBACyACm9AEu5AGq/AHfK
BaC8Cby3ANS/AgLlABPfDTncAFbkAI7UAKDRDcvoAODrCAoANhoASEkCQFgARYgAPpgAQLUFMt4F
RwAZQxMmR0wVO1sSP4ErPpsfM8UYONsaRgA/NCA9RTIxR2FJOo1NNZFOPLhCQuZGQwBoTRxpSzxn
PF9cN3VkA5ldRsFYRt9nOgCGQSdyODN2NVuIP3l7S6eOSbV4Ret7QwCaShueTUGhSGmUO4eROKmd
NsylONOmRgfCNBzIPzWyOVPETH60TqXNM8S0TNayOgbuMy3WRUDVMmzcRoDYRKPnOM3RR+rcNwAG
eCsNhEMAc20Mi3kIg5MIhcIAeeEIfQwegx4bdEIWhGsei4gqeJgghLEthtkSjgBHhhtJf0VBcmM+
iI40eZNGgrlBf+09egBujhxbdEBtcmpZc3ZmhZNjd7pbd9RpjgCHeCOAhUiEdVl5dYx9f596griI
ieN7dgCtjBiegTWehlaXc4ifepOoeb+uct2ShQC+cSu7dD3Ni1HMfI7OdKLDg8O3etyzgADTjBzU
gDTUeGrcjIzqi6HpjbLdidXTjAADtx8Esj0Kv1YAw3wAt6wAs8YLytIKtQAnyiUryzciv2QbxYAq
yZIewLQnytkhxQ45xitKxUZMyWVNvIs2vZhKs8ZLs+VNsQxZviFevTRhvWJkvI5XspNgwMhevNdW
zgd3wRyIuEiGwVd6w4qEwZV/y7ZywuqCygScyiOot0igu1edx3umvpSTvMqYxdOXxAyzvCu7vTq+
tmfCunnDta27sv7//ZGXnHp3eP8ADAD/AP//AAAA/fMA/wD////w8SH5BADe8SEALAAAAADIAVgC
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKPAhgosWCUi5q3Mixo8ePIEOKHEmyJMdcJSuaXMmypcuX
MCX+m0mzps2bOHPq3Mmzp8+fQIMKHWoTANGjSJMqXcq0qdOnNwtAzRmzqtWrBVVi3cq1q9evYMOK
VQhA69izaNOqXcsWrNm2cOPKnUu3rsC3dvPq3Wtvqt+/gAPvNCq4sOHDiBMrHsq3sePHkCMnXEx5
6YLKmDNr3sy5s1DJoEOLHo3Ws+nTqFOrXs26tevXsGPLnr2YtO3buHOPpM27t+/fwIMLH068uHHU
upMrX868uXO2/p5L33i8+ms91rNr3869+9EG3sOL/x9Pvrz5ndPTq1/Pvr379yFZwJ9PH7eD+grR
7D2Dn+Sl/gAGaNI0AhZo4IEIJuheUgo26KBahz0o4YReBUXhhRiCVk01GXboIV00bShiNT59aOKJ
GjE14oY4CeDiQC4KAOOLMdYYoz03ziijjTYelKOOBf1IEI8MCamQkT4SKVCPQ9a4EJM6vtgkkkEy
aeSVUkaJJY9ZGqTkllMKyWWVXHa5pJJhmokjlD2WeSOUazoZ5ZRA9jWViDX9qCeNataZI5VJykjn
oIMCWmeRfZLpJZ+CxukoQm9mGWmjkyb0J6OKEnqmoHI+2tClO5q5J6eSStmppouS2uijYppa6qqb
pv9a6Kuv1mmhRqDG6qmsrCbK66FxdtnqkacG6iuwnlaqa6aOjppsn8OCqSWhzn4qbKiw5upnrb8G
uu2q2p6J7K7Ltqoqt+Q2xOCkmKabJqXHomrutbA+WSyk8ZLrbLXMKtssuqguKzCc/BrKrLzt0slv
wNQmDKShSEbsar3sTmwrUBtFumav9ZIJbr4C78onw5aGam3HHlsc68KH+usytDBne+3GLQNMbMdg
SoztuO7WvLOiEKupc8j/mvwsyiVp3K6bH9M7ZqplPuw00lJTTXTJCb+Mc6372jytlmhqPbCb+M47
5tDhHvyrv98K7TbFKiuMKcvqIrUpo157THK3R6f/C6esBl+Ndd90E8513l9LWzTYMlsNtapAvx1s
0FRrO/TXRF+Otqt92/kTR212GvipgSM76r0831166XLD+7O7Xbveub2vlxu2wz0jWvvike++9+Re
U0m35pKDWvhKoR+vuuwnZ3o8oMoLXrbhzPeb9fWO8/7t9iKD7G3Oxcet9vh+xzwu8XC/zqb3IImu
vJNp3+w8t/ROL/39gB9efcPqY59k6/NjnvFStygAzqppukKdwaBXP5rZLn1ra+DpsrcQBj1wb5bz
nrREBbnccZB2UKNZ7KoWJu2JjYEd3KDMHthB3SWQgwJE170W6Ktwpe1ymrKh0y72OdABjGndw9bT
/9TGNo5RjnzAQyDwUsZE/sHwiZVbX+P05TD4kc1YNjObEu+GxPuhaXlpIiLpCLZD/KHIIqxDI/vO
2CALPiiNE4EjG99zqzl6iyRytCOC3KjHPrIxQn4M5IOeIshCGvKQiEzkS/ioyEYuaCqqYIxEAkBJ
R1pyL5QMwEE6Y49MVtKToPxkJQUSyoWEUpMEKWUqPdnJTK4SlaRUpUFOycpY1hIhtBQlLFupyVMO
xJW4BOUrhTlMWR7EmLfk5TGB+Utm8tKZyXQlLRPizGc2c5TDfGUxdwlNbC5zl7Zkpji9ORBCbqSa
ytRmOtF5zXba8p3qJGY658lOdcaTnPac5SiByf/PfeITnuOE5S3rGUxUBhSb7EymNQGK0IHq8prg
hKc9E+pQgfrTotz8pzvbWcuArsSC6KymNL2pUZEalKQoPalH5xlLU5KzmxGVqD5VKtGRxhSmMl2n
Rr95z5UWRJ7ExOkzMcrSosoznAv9aUVlulKCHnWmNf2nOTUS0pc+lCFOxWdTg3rViAg1nxv9pk9t
ClWl9lKrXXVpRG3az5tWNK3vVCVZzVpMqNZTrnDVKU0VQlBl5tKYX6lqTHNaUGqilah+pWlfDZvR
tf5zsdFs6FkdS9miJnawZdXmSAk71MnOVbOijOthV9lKsWJ2s5cta1vVytiNdnSnVxEsXxVK18L/
1lavqV2sbQlL0WlCdKJ5la1wc8lTupK1t6V96HAnm9rbfhaip1VucBvaUtbOtLGuha1VZKvWkkp2
uojtZ3OHal3ePla7kd0rd0FbWd2al7nJPa9nmbvclj43qvC9bXGlW9lwatey2UUsgLeyXqzK17ij
ZahK7wvZlGYWrNfdpoDDKtr2/ve9ekUubuvbWcseVMO2LeV6AVvcEEuWwhwBaYIbAuIKZ3a1/jUq
eh2sXxRv08YFdrFSOVtijn7XreoFLz1ZWdUAP/jFRF5xUmeLWdzi13OawXAwIczUi+YTxuRlaYPB
+dUaZxPLVBaqSffKYhp/uMfuFPOPZSzgHDv3/7XYzaaBm4xlj3LSwzsFM5LDa1UyJ9Wnu01zngcd
ZCCbuM2AnvOTf3vkRQM6yRjN6I69fOWtUrbJFP7sWCs5VYs8ta8kvu6YR53fJfuyvDdmrC9x2tuj
IvPU0H2qWbtMWwDDlNZsVeiYKR3W9N4V051tbJ+BeuFLGvvYCmEkspetm04z+9lnVDa0pw2aO1N7
MufJtravnWxte7s83Mb2t8ftnXAjhNzo5o65N5nudleHH/AeCLz5Ie94E2TeBZm3vvVdb37bA9/3
trdB9v3vfRMcIQYXCMAPkvB8H9zg/F54v+mtcIAD3N2K8QfGe6KRhXtc4BWnOMNBHvKSS7zgIv8f
OMlRzhCLx/vk/S55zFkOc5k7XOQfT3laTLBukzDI5RQ/+cFVrnOJv5zkNbf5zBNidHrXvOlBB/nR
db70gE8d5/beuNaDQ/OII93fRLc6wr9O9aorPewjpzrM8f30lZ895lAXyNbn3puuF5zlAb972sW+
d7733e9/vznaxd72suM97WSXO90XHxu7T53wbo874iHO9JUn/e1vX7u9h45yyl+e83hnvOgB2XGv
C/3xgz+84AG/eta3/vWZl7q/k3551WO+5wEiOOgpn3raJ37sane72Yev+bKzXfi1Lz7uE6R7sB9e
+cM/++ctL/zbQ9/1XTd88qlv+OXfxoJgd37/zlOvetRHP/bdV7r5Ae9yyGu/+rY3yOjnHxiCkMIi
48+7/lk/+/XHn/jw13kmh3ybJ3BAZ33wd33elxxulH/S93s3d4DY13lFF4AhB3Sc13ATZ4AQd3XO
F38XR38i6BkLCGUjeIKVUYIouIIpuIAs+IKJoYIwOIM0WIM2CG4lmIP1cYM8mB0UMILIpg06OIRE
WIQV0oOJwQA1sQxI2IROOBN0cBxV8IQwaIRW+B7ycIVauIVcaG6+0IVgGIZiKINUWIZmmBlj2Ec3
cCFn2IZuiBhpGIeP8YZ0WId2eId4mId6uId82Id++IeAGIiCOIiEiBlyeIh7UYiKaIaI2Ih1/7GI
kBgctxCJN9gElOgajpiJmpgXW7CJYXGJhCgCgBgNoFiK6BZIXOCJAiJtcsETqrgewpGI6PGK6RGL
euGKtDgdtpgXuIhsH/ABD/GLCSKM5WRtF1EWyPgYxGgPyyiMv/iMxAiN0SiNyzgQ1AiM1diM0CgQ
18iMwFgQ1MiNz2iN2yiO5WgQ3TiO4uiN4YgQ2qiO6+iNHyGN5NiO7FiNBKGN5HiP45iN2GiP9aiO
+iiPkFEWA2GQjTGQ8oiPBBmPDomO3wiO36iQzhiR+5iPFjmNF0mQComREBmR/rgQFAmSE2mRGtGR
DemQDNmQ+riSGpmSB9GSJemRn4gUCGkQyP94kzlZEcloDzupFTt5F0Hpkyqhk3hhgjcxjRrJkCu5
kRDpjvDokiYJk035kvuIkg9pjjPplDG5lVd5jVFZjvQokWTplE3JkSW5lFOplVz5lOtYkWUpHDdJ
EEYplDxpkHiJkHMplERZlHfJl4BZEDyhlDPJlGvZloh5j4hpmGXplvgIl1kZmWKZkYepkib5kgL5
j195mI9JmTTZlfE4mTAZkIm5kRUplUhpiMd4lHVJlICZlweJF7D5mj25EaepmfxImJ2ZEN1olmuZ
jlNpj1b5lmP5kdsIlyHJmyRZllYJmQtZmbvpmw5xm2hZnCnZmxg5mZxZmVaRFHsZmHrpl3z/2Zo/
6Zq0+Z3sphOKuZ5nKZ1QCZVYOZrtiZZZiZzQGZxp6ZnKyZWYuZzAuZ+feZ3cmZ35GZlsaaABeqBk
SYKrSRFAKZ7mOZuuWZfkWZsnmZnD+Z6lWZVhCZqNqaEZCpkc6pjwOJqfGZ3NiZsJmqDJiaDGeaAc
Gp8r6pylSRcU+qC0OZ44Gp5/CZ5vgZ4MoZ1e6Z4uipos6Z/4+aEpepHxyZjmuKIBOpKWeaQmapqX
eaVWSprs+ZtbaaROGp1fYUFD2ZcVqqM5GZtn2prmGZvpSRUCGpAYWqJVmpsqeqRx2o9j2Y7nWJwt
CqfOWaLz6Y9yyqf5OaRdKafyeY5vaqX0/xiSvZmhVBqPu+gRQAoRlSqYs2hs85khxDipHXGpDQGq
BDGYYFmqpnqqqJqqqrqqrNqqrvqqsBqrsjqrtFqrz8igXiGqC6Gr3repEuKruRisDGg3dtGLH2WK
yMqLmXqsyFqKIMGrazoRxupzzeqs5WkR0AqtbYoTlVAJA9Gt3+qt3Tqu4Aqu4WoP5DquqVmtZ6gR
c6mtdHmUCAGvEGGu6OqtAlGu+FoQ5tqv+yqsZ4Se4WmXeemXZ0qwOBqYHeGv/nqvCEGu5wqwBeKd
rAmhyXixdymeZaqwdaMTDIuv+vqw6pqv/6p47EqJZGqUGyuhLAuhFuGK+hqy95quBGGvM/8LsSd7
iThpsAk7sDfKptEqE+gBsTdLsiJrrzZrsivoATkbg1nBs0Drszvas/LqEDA7skSbtOGKtCW7rk3r
hO5qFmoaoRo7tVGbsB+RtVjbtQ7btlorsTtoN9eqsAM7oWN6t2hrtbNos1xLs3wrrunqrV/rhilR
tXB7uJ9quBKiuIibHvR6IIzbuHHBim0xrSQxFYQxuFuHe5EruWxBuZ+7rCXhF5mruRj3HvmQD3PR
uZ4bGT9ZtY+7FalbEKlbuwhRu7NrD7hruynRurnRso6xu6qbu7qrurRrvMWbvL5LH4GArVPbkzwa
vWLLuiCBuwRBvMQ7ENg7vMi7vAPRvLX/aJPPG69Bq6axyxA8Yb3ai7zZKxDbW7zqa7qKeK17KaE+
2hKuyLvuy77du7/raxCzy4dzIL858Z3126NoerDM6qbq+74AvLsP7LUEbINhu7NPW77U+xKzu8H8
uxDtq7zeG75HYcA/isD3y7EfgYscDMK5+8Et3METPIgkfMEpi7Dkuxs7Ibzrq7/bm70QLMExPIOo
278hzIbE+oiz+MEpHMSAqKzqyRJM3IRFPMUP4RPd4KYmEsVliCJaPHoxcb5pAcZUDCCvyxDn+7oZ
/BDZWsIWmsDQq8BjDBkUGxFiHLQiwavlObYoXJdd/IS6Sr8HW7cO+rRvXMiGzLMuG6+V/zrDNOya
feyEc9vIMyzIFjyvGQu0dnu2N0zIsCubQ8nHj0x3H1GwwEvDcFzJg/yuZpujoQqkolrKFIILZEgU
jbzJ0gu1CXHAaTq9bFrGdpzLFtrGlrymBhnKokypFdvLVHupqqzMtmzCmGzGPbrGxJzGWrgLJhEJ
czHHKEy206zHqOzN0cqj1Uy3nZzJlfyzfHkefjAefxAbyDAcNWzJgYy3u8rGGMvJ0qvI3QzIn/yg
tTmUxjx3Y1HH0jzK1hzHDBEDkQG6DcoSBt3NHjHQmxsWEe2gwqzQWXzEYSq6SEzR7abRIj3SJK20
kgQWlgsiIB3Sq3nKgyzRJEEAMj3TA/8h0y0x0zZd0t8nvtH80jisEzktEDkd1CYx1AQQESvN0s6L
yf+cz3P71GlM1DWN01Qt1Dht1VeN1TRdEEZt1VNtD11tEmSg0wWdt5pspjrK1FF91Adh1GwN1m9t
01st13H91l8N117t1WFN1r87pqa8yuj8yxFB1XWd14ZN118d1FIN11mt2Gyd1Xy9zTyty2/szGkN
08X4xAQR1kTt2Hit14XN1YXt2YzN1kmdbhVczqwc2LDsEZxt154d26G92aMd2pAd2bexsoIMvOSM
2QjR2Y8d3LSd2LWN1QYh28Zt2Lid27ycsgDN2ohs1g5B2LS91VM917Zd1aIN2dSt3Mv//SAXfdN2
bRGLbYTCMIThzRLlDRHr/d1p4dAc4dfihsVFfdvkbdennd/6vd/83d844d7e698CHmUAXuAG/hjP
cOAKjhvHkQoD/uAQHuE0seB95AcUfuEYnuEanosS3uEe/uEgHuIiPuIiuOHCSuKJwQ5JfYjS0B/a
QAGNhOIyPuM0XuM2DodWkdAm3keYUbo3/uP/4OMePgmhzBU6vuPRphllAeRMHuRN/rVugeRGeOQ+
KeVESOVWzhVBEBam0BXwnYZPPhNZPuZk7kdfPoZhrhQpt+YU6HT51uYRiHURF+dsbnUF2H/FJ+cc
KH731ufH1+cXqHJ+rnuArnAXWHZp/54UdW7oxidvhs50gK52b45whc7oAzfpjv7odd59i45zFRfp
la53lo7p/+bnpG7SQN5xju7p2lfqj07pmS7pob7qmX7qrg7pmg7qDHfrQQfqrL4Qbj7qhR7spc7p
ka3otC7sb+7puJ7rp97qzG7r6cfrr+7q0J7ssU7t007sxF7r3H7rlw7EM74Rvd7rcF7r576BG9jt
5x7tD/fueR51OWdxsS7r5s7u4V7uDzfqej7tI/1z2l7tpi7wk77o6A7u3k7p/l50A2/wCV/sBU/r
co7pbt7ov77rmJrotPzt5n7p0Y7x1P7sk6fwLUfq307wFOjsKl/xIm/pFo/ttp7m5P8e8Aj/6h0P
8tYe7geP8OyO7wxf6d1+8wJ/8jlfb9X+85/+8vxO8cdOrEifcAyvgUMP580355GO5xgYfPQ+6FYP
8073cvu3e3mngUif8pkOioYQHq8o8xfRgW7/9nAf93I/93Rf93Z/93if93lf5nzf937/94Af+IKf
F1gerIXfR2JLl2q8sy69+BRBx/Kt+JQa32D8o3exEQd8+fPa0ocv+Rnc+a0ot5v/+GQh+Zofqjg5
+Z/qEKC/+u6aFchcyyGR+M96+qyP6hvXz8k8+lUOlASLpr9/kKmv+fWsk3Yp/GR6+fWb+oac/L3P
k32p/EV5/MEf/cN/ydU//MgP/dH/C/yw7/vTj/29b/3zjPyMH/4qa/voT8rSz7PjEfvh3NOnD/3K
r/i+X+Wwz/y2j//Ez//hDxD2BNoDQLDgwIEHEQJQeNDhQoMJG0ZMSLCiQosTEVqkmHHjR4EYORZk
WPGiyZMhR3Z8WFIlRpEiVV6cWBPiyo8kNcoE2dPnT6BBhQ6198/oUaRJlf7LydPlxqcmSc6EyfHm
QoZZX85EuVLm1JRNs4KlytVjV7Jbr57t+TDsz7Fa2VqdC1Vty5tp9drNCbFqzLxm37pdWtjwYcSJ
FS9OShRoVIkgIYcFG9fh069tuxocSxUz3bRrzbq1DNovX7mlOUseTdcn4Lmq5QYm/206tu3Nrauu
tu2Wc8ndPB0PJ17cOPHJHbHCtVqZuWvoZ2HzlWpaeObq0Her3Ryaenbuz6tvZ311Z2/rop2e7o4e
Z3jfx+XPl894aXT8wtlL3x9f8N3v8CrrL80CLGuw/bjbS6PA3voPtr0oo+684NILCTv4LGTLpdou
dM8+EEMUUUT6Suxrrc4uhGnFznZKbbbLXOSwrbhwAy41rHDMCzMYJ9MqOB3VC+83iTCk7UipgJOs
xxmTbEjJ5nSaarvkTLTyyqJGZApLLrv0skT9vhRzzOLCJLM4LdNUc00tz3TzTTHNhHNON+WkEyg2
89Rzz8bu9PNPouwEdFDjUiTUMf8+E01UPlwODcoVRyOVdFJKK72yD0sz1XRTTjv1dE5MrVR0VFJL
NfVUVFNVdVVWE+2Dz09jlXVWWoMKodbiQsV1V1579fXX+XQFdlhiizWWVmGPVXZZZpuFM1lRW1Xz
BmmrtfZabLPVltRXt/X2W3DDFXdcctnsdlRn01V33V+hxbJceOOVd15667WXsTzu1Xdffvutl12A
AxZ4YIILNvhghBNWmMtiFnbYX4gjlphcRSYm1WGMM9Z4Y4479vhjkEMWeWRODSH5ZJRTVvnQFFZ2
+WWYYyanRIvVDKFmnHPWudWYe/ZZ2Z2DFnpooos2GtsOjlZ6aaabdvppqKOWemr/qqu2et4artZ6
a6679vprsMMW++onxjb7bLTzZDZttttOc22345Y7Mbjntnvrn/PW+2B+EOLn7779BnygwAm3B3DE
Nyr8cL8PR7zvxRl/PPK9Kz958cIzb5zxzQWi3PPOJQdJc84tN11lyA0HvXTDI8e8J81jh730z1k/
/faMU1+dc8p1V313xVsXfnTaZ8f9eIdJfxx40F0PPXjReV/+d8cTR/765FV/vXfbX59ddtuHDx97
8hGefvuPfAe+9uijr9139suXH2Dnvfe++OcbB/9z5Y2f/39Ppal+1vPc4ATHPZ84r4CJGyABA3c3
CPqLHosCYAV/JgIxCXByG+Rg/wc9+EEQhnByESTh1Cx4QhSmUIUr9MnbWPjCj50qUoKqHA0RZkNP
4TAoi5EPg+T0FUMF6kRBqdEQC3VE5AhFh0PBIYN25cTXfGk6YzLTEuOEkh8aMYlIjOLHmkisL4JR
Vj5UUZF4IxgZlXEkUMIReYjEmza+cUpqZNKOYgIZKGVER3HMEVekRJoZxaiMgnxjH+F4IxU9KUa+
uaMiV0MWQkISKjxaZHM8MiUm6SdIf/QMXjiZSDS1aY6MxE2RbGKj29SkkaQkY5P0mKEhxfI7G7Kk
JPE4Hj/S0ke1lBBaUiIg19gyN7DU5UmgiCAFvbKY/8klf7aiymRCkYc9vGQidf+Sm/WMpkUs4eUs
T/kbSUZTkYi0S3KCuMxqxrKIlnzmYH4kISdSCSfh3OaAxBIhr1gzn5PMYzfTic7rGKqV/hQmM3co
ynQ6xTvZLGWU0NmeZJqnlxFRqHnk2R9efnOYA/1mRwmKol9Gs5eh0SiF0DikksLzo8dkJkdVGtGB
yJCdM62Ldt7jz38udEIzDSctJ1rKi740pza1Z0YnWlCftgZAAOXpEPFJRphiEZU28eh5JOrMoVY1
O0iRh6KaSUce5SiPkQxkk4JkSnpG0pS5rOMZX+Kj2XSyoGc1Yy336Eo5VsaVjaTjgDLZ1HuClaab
XBKHDHvYOUY0RUBk5V1Z6ST/wpgqYVbkEmXL9CkdWnY4ltXsgYR4pcjSbWWdBdOcSFunLZ6Jsz3E
KxNNRNeDKiYrSIFhyEqYqsKus7a7hdlRxsIYx1znsn86LaCKC6zbogq15dmsEr1Ew+OKJrXFYilv
EdWmz2rRtcTN7qSiKykrJrdch6TkKvvaSfTKsZDnbOsou3MjQuaVr2Wl5F3wqldHwtGYYDWvdBBb
V0zit64xFW+pXvtRqWq1nSL1qFT9AkzyrKfBB0qsLjOzIrZKFJqoTPBjxZlhWXIKFht7Wz2Talc+
1gipFe4pOEFp0uVoc6wuzg6LXcyip7ZooFHV7YRtaWJV/ognazJBgQ1DTZEq/7WmzsEoVX86HXpG
Z8ZJPpEnHbTjry5HwQ1NcJdR6uVJWleKQpUnVI3K4CeTeZgwXXGDbOxjDmuozQ4G8UqPOliDlum7
lgMyKMWqRhmnd7HsZG95AWtIiiz2RRBa8BrjY2LQHHbAkF40Px/93/N6iKzV3eyeY4jdGTYXyfTx
NKegSyYtMcTI6AIvE6sU3PnElV2nHlOIZrvqw4j5f6/Wda9RJuv/uVC6C6tiqW2bFFXjWlUqDi6w
yWRsp4pn1Nx9TLVf8yTnEgUpyVY2iEi9ZuY2i9P4MRZnsf3c2moJAX5s60YljWnyktJJ/DSqgOV7
4koPct6fLCR/+2tvSQ8y4P9vvWViCbvpj3R7Td+usxu7CeFyppmhdvWQnXkMZpzOueEaljdSaSrx
ofInqJHyAchc2MogYojJaZ0ySZWj5J4yW7HBxPiGmQrmMjv4jznuSzz9CiNkugZbPvDBqr/qnQeF
lKkwxmKE76xhXF71Nuy++cZxHnVfxvji+9zpyLNUraKbjeEIhqgz22zmrMP80BpXedAJNGGykx3i
DieQkmcOTEIDiujXg6qzFd0hfvc56cBedIsJS1FsIrrw+pURXwd7VqCf8UVuxTdq9upoQEPbJ3s/
mbDflNlKab6Lot7urlgVdrbFCvSUEj29h5vtj3E+ZQqnvbz2UHvc5173u+f/fe/35Gvg/8z3wyd+
8Y1//KL9AGxXQL7cgv/83jZf+tOnfvWtf33sZ19s1tB+BKH/fZV1X/xDE8D4zX9+9Kf/bOBnf/t7
5Qb3r1D986e/ziZY/9rHX//753///f9/vcE/ViGE3jMCATxABPQ2AFxAgUlAB3xACIzA+2BACqxA
C7xAPwkGhGAFjbEFDEQYCZS++1O2DyzBaMkWE0zB+dgWFWzBUFIbF4zBWBG2DdiAjahBHLRBkMjB
GhSIHhyIH7QHHgTCIfRBHuzBI7TBI0SIJfyIJBRCHITCG9TBnkhCJaRCKXzCHITCLazCIgxCKTTC
KBTDMeTCImTCMzRDLGzC/y20QjMkwjKMQywkQyoEQzBUQyJEwzCkwyusQz8sQzQERCN0wi4Mwh5k
wUHMQ0XUwzy0Qx00xEf0wylkREr8QUckxB2MxEkMiktsxDlMREjMRD3sxFDcwzu8w0rURFBcQ1Vc
xEQ0xUiUxE0sRVS0xFYMQ1tcRVksRUY8xTkMxVz8Ojahjy7cQ59ARWNEwl+8QldMxk+kxU/ERGn0
RaHoxEFExmA0xmZ8xSxcRljcRFG8Rm9ERm2kxnLsw1tcRUWsRVUkxXaMRU0kx15kRV4cxWikDxcq
RnncRmc8x2+kRG38x33kxnX0Rk5kRXsMx3rkx0ukxoWUR2Acx3s0x4KcxP9CfMZbLMZ55EZIhMZc
HEhcpEdZnEIwZMFsbEJCvMgldMg05MiVTEOUDMSLJEiQdMaX/EJ4hEicfEmLbMmAhMMxNEeUpEh1
TEhlTElBJEc2REhX/EhmBMmhfMdMnMPfk49sBMdjZEZP7MmftMatzEppnEWDBAqvPMpp1MpqRMtu
5EpsvMeAJMqKBMiQ5Mo3BEevTMV+bMp3NEuNfMVgvEqg9JK3iUm5FMWGlEiCzMuN9MKwXEx+bMzD
VMh0BMvITMi3dEt2xMq4bEbA5EtB/MfE9Eu1LMu9HE2MLMiZxMQgrErjqMzEdM25LEp/3EZoLMy2
pEm3BEjY3Mzb/ErZPMn/sWzMRbzKzhzL2hTDsLzL4ZRK3WzFoBzJ5czLiAzNFdQSd+xLoCTOP6xH
0hzC6/zMy1TGNvRJvbRH74xC5VTDjNxO6ExP6oTJnWRKMszO5cTIvlRK+MzM+ezI7LTP50zF/xxE
RJRBAm0hbSlQBAUJ1kxQBnUUz2vQ8LstCH2Zr5lQC/2TB73QkUkuNzzM85RLXhRPtfxJOAzE5vRE
nwxRdERPhHzCqXRE8FRPsxTH+9RH+cRJ29TCFiVM9SRJX5RDHBVGvCFG+VzLs0zOXUzHfQREJmVK
wERS31xMqEzSx3RJywRN7RRNxYTMHSXLkVTRzSzMjKHBIp1Rx0RN5oRL/x+dTzY1UhJFU3H0woUU
TtwEy/I8zig10/JkzDvNTYFEzCtlxOTa0zh9Ucn8SyXNTZXczsCsUl2Mx4mUQy8NxyolzT+ly0LF
Sp080YHE00z9VEWsUCKVyfGET8pk0TB90270TF30UfAU0ZA01f48TeHc1FldUeh0U129VTvlQxH9
zKjEVBpNzY4hU07FTGS1RU9VVVhF1DZVVTYl1jWlTjhVU0Jdy7s0U8/UVmQ91knN1hHV00QcVCuN
Us2UyTYtzp9w1h510ylV1slMVz/dTVu1UuAUVm7dUk3t0nV1TkA114TzmhKx1HpFSnmtUzt1Sst8
UoOty95kWLv01371Vv8trVgwdc8tFdeIjU6LjcaafBmCjcklvVEWLVVgPU3X/FX8BNDxNE/s5EP6
nNg+Zdll/FFUrdQyxVVaFc2ktFFK1VCgBSCjyAYUCJGg7TwJPdoNTVql/RTqa1qofRdQi9pNSUCq
PY6PxUeigYZ+sUodPVFe5dPQPENJdVG8HNbZlFMTJVSV9U8Z9c+O1Eh2DND3rNm2jM9cZSFjvdbe
lNnXTFJJ7NQvZU5HbdKclc1epdZlBdHALdL+BE3apFIhrT++ZdRznda0RdtdPUt2tdZGtdHppFbO
7FbERdexddy6/Nm/jUurLVee3Vk5zVWWVFiZTU11zUp4bdTUhdbM3Vj/EvVZLm1Y1W3X42xdmwxS
zy1KuDxK5uXRVUXL22XMlo3NniXP5I1K5I1XN0xJsT1V1kXAyi3dkRVfQJ3efs1d8p3Y6UVUjB1d
72VIwgVb4eXCtLzUyaW/8G3Xwg1S983dd4XHVB1f6sXROa1V0i3gpfzZlYVYw8xb4w1Z+Q1e/YxN
+v3fg+1dsfxUVuXd65VcsA3dut1cCp7RYIwgQaCg+YDga91X/SXbP5TR7o3bHuXRzExZnZ3fgm1b
xeTf8HxO/nVhSa0tObhaOsna/hviDCXi+j2T5pODhVPiTGniJ4ZibQvBpXDiKaZiobBipcDiLNZi
POHiIwNjMu6JNDFZ/+xcVAGmVO483GNtXNBF4/Z04z49z5eF2beN2Zgt3hLiB31J4eA8Upzt1TbO
YBYuWw/mWEt1X4BFYDqu2G+815BRAGcZzEA25INcWYe13NLtx5ncTft9XUYGVX1lVsfV2Hy9XzFe
uOSlYC/VZGKt0b59Xg0eUSxdz4fk1wgWXXDtyp4ViFVelFaOW1iO1DdcVk2O0+Z12ZJt0o5F2GG9
2dOtUcb1ZVoN5gnE2ksWU1+uW/R15d/lV/PdXHGV2/j1ZNid0l1G5V8mUEu+3Me82xhd1Mfl5soc
53JOVBilW3tNZz/N2H8NVITAZqUAZHhG3Am2ZgAG6IT1V+idzFymWP8p3dlZ7mVI3mDeBVpzxt2c
9FjUdd1Fjt36bGGezN9o5mQdvWP9/dvqlWQjLpFqKGOZnmmarmmbtq5gzheC3mmexr2bLuOeJr4p
EJu9KYOfHpigTmp6mVAMOurrUmqoJheHiQenjtCovmqszmqt3mqu7mqermqwDmuxHmuPiQJfmZd1
8OoQJGuqVWu3fmu47loySQC2rmu7vmu8Jpm43mtYyWug5Wu1rgev8uv9q4cuob1MAOx9EWwUJmzH
TsFyeGzJjj/FrmxpmezrsRfMRh7N3mzc6WzPPh3Q/oAPQAjSPu3SFgjUJu2eYG3VTm17YO3Vlm3Y
ju3Snu3afu3ZHoj/1W7t2nbt3n5t077t4P6I3d4I19bt0zbu3y5ukCju5RZu5E5u24Zt6E5u2kZt
5h5u7h5u6/7u6LZt7sbt6vbu6sbu3T5un6Du4MZt4u5u175s+mDv75Zu8d5u+6bt505t4M7t9c5t
9PZt6Q7w+xZuAp9u3gbw5k5wBGdw+27w+w5v6tZt8y7w/q7vA3/wCPdvCefv+i5w8Z7w8k7w995w
/AZx7/5wEKdv+PbvN3Eh7X5w/XbwFu9vFCdxFQcKFu/uBp9xBmfxDKdx+s5w9D5wEUfx7PZw5r7w
Ev/x6PZxCw9vE59uG59wKIdy5c5yG7/xIIdwL9/xAU9t+ZaPGF/x/ybncg+vchc/bxrX8QXncSpX
8vFe8C6P8hRv8yJX8SO3cuLe8jtncz5n8xB/c0HH8f1W8x6XcxGPce3e8kXP8RP/ckKf8jt5G0en
80l38hknbzxX70gPdAHX8CvvcylP8R338yln8iNH8vfG8kHX70CH9TO/dC+f80FP9DDv7SR/9SdP
b+fe7ziX9OOO73+hdSeHc0MX9FUv81X/dAX/7za/9WNvdiw39jC/dmp/dibf7kY/c2nv9hYX9TXf
dlAv9EcH9CZ3dVePdDgH8ykfc+MYdkxH9ixX9nHv8KFw9xsXcm2f932n9PNGdVVX9HtH8G3HdWk/
dnSv8VJf9jT39v88j/ZUT3dvB3hgv3gZz/RZAfIPr3N7R3UHB3lo5/FmN3N+v3YNz285N/CO9/d/
J/Aix29r9/PlhvlJd3gSV3lJl3klD/BzT3mSz3F3F/lO4Xhm//WdV+6ax3Skl/imR/ZfP3p65/g5
l3qFB/qA53cO33oc1/MkJ3KNV3nw/nmlV3dSH/hZd3F5b/ibX3k6SeLQzhvQjvvKgXe6v3u8r3vL
3nu+T7/f6nvA9y1uC/yI0QTCP3zET3zFTxtSWPxU+QLHj3zJn3zKr/wBzXvMz3zND5hs+L/WG2jL
r+zNN8HEbwZW8Ye1Hv0PDH3RV30WooIvYX3Fdn0Y0obDln2+pn3/vVkH3u99318H3Q++3/d9QkEG
A8V95E9+5V9+a4mFWGB+rnZ+6N9q6RfY4PeVWPCZdrh+SnF+7v9+8K/rz28KU+OiKzKuNRozcBu2
WkE6a5su4kgTgXp/9kcOc7KScXMtKAqT/ccS9wcIewIHEhwIoCDBgwgX2jvokCHEiAwVCqQY0aJF
iQgzJtTosePChxJFNizIEWTJiP9Wsmz57+NEgx9PwvRIk2ZNmTk1UsQZUufOnD5HBt1YcmhRlCmJ
JlVqsunPn0grArVZFarQjgoBcK3YdWvXo197hhXJEWzZtFvFOiSLNiVXtBnXHm04tqzdsAbv0o1r
Uq3dvWvnAs77/zYv1bhuJxZ+2NfrYMgYIQumWlexYMJtD/tFjFhvZ8yeOxuFy9ZwYtKURXvGCnEy
yaWyL1sm2faq6cRAb+eeu9T2b5CRe8oEvrv4bMt1cyOffJz4ScfILz5/PJs38enLaW83rjx59+mR
dZMHL1x3du6y03t3XRp9erh+zaaezxT6c5197ZdvL126cgCul59emdEn31cD5lceasAV+B5+6CHo
HWza8RZefKAlxJ9hB26WYH8+/ReehN+x16FGLqm4YksVejUgfo/5Rl1wJ2Y3HoYWakWbjcEdF6JT
MjanVIQkqkdWTAHWeKSPMOpIX5FnUdhkbQwuuWFMI/aY4YIDsf/IUlM37vhkb1d+V2V/OpoWpZkz
rklgVT3GKV6asTmXo5L+JWmmj2ya2Oabfj4l55U4OvgehGmWqCCgEn35KEusbVaZXMvtR9eZHNqJ
F5qVBsbZVWJ+OmSmh6pGWZkNXteYfpU6+CCRnCop2XqqHTbaXn3aCpqnrPYmK1itRfXrkvGNWltY
kLq3LLPNOvsstNFKO+2yU1F77bWQKostt916+y244QZ1qrjl5rStuemquy677br77rraPgovvfXa
ey+++SIkL7/9rrQurPq+OKzAYVob7cHwBmxeu/46jC5UCSOaGU+4jaTWwnv+aBO5NbUXZsUEkzZy
xiFTzBTDjN3/yZrGs3JccsXGLvQwzSuqe5bHRRmbMM5nvsasxFahjGWeau50p9BHt7oxwS4PjVXC
NUsd6ViVoSrahydbbetGvE7KWcd/orrhrZ+R7KbVnw359dinni3saLCeGORfnqKG29v8hRZ2kzsX
ttrbTrWmKY8gvj311EJmWqzRfG6tHaAyX4dokRt/HBrk0BnquFFIFz0sexjhdGipmNpJps+Mssw5
oZp9nufmlU8N8ppYE0666il/eHqdeD+lNevVhb177mwqdiHZvKMUW6wPoq2qop1jtnKjdDtducvE
SzX98pFPH3SzincpoJ5WDvr765cnKvZ2lqdsJfXGhxS/4Nhb//w8/dGfTyTqk6PPpfkI9TO0yc98
gWlK4qpUQCYBsH2dy1z/PJe7LrlPcnhKX/WKVz/IbTCDC7wJnz4ouL51r2cZHFP7RMil2SXFOmcz
VaucJyutBc5wwEoepmhFttSBCEF1W8zVCHesvUmpMa4DD8l2ODaK3WhXXtuaWW5ooCDKbYa5aqJm
gBi3HgYLbOAr2PvAKMYxkrGM6mIhwmBmxjWysY1u9JLU3ijHOdKxjmtEox3zqMc95hFxiMsKvdQY
Pvc8z2JHAyEfzSVBcX2xJH7kViNpRyPKPXGEkmHea4a3P0vm7H/og1Yk3zWVRYYrOklDYBw76S2k
RKd1uZqktf8kV8jUAbJ73Qqlu0bJyW+ZsmJ+nB3mkJU1KrqlbG27S92WmL3fYfJ/gRvf3aI4TFwd
0YnRXKI0dUhNYbmwklB8C8a+CUQiHrNAWAtVOEuIOVBtsZwHeWQL9cMcKl3wYxD0JCL7Zp2fYRCa
MdJgavC5PvUQTYU57NQm+Uee2PVvk4I6YeOMZ7rJuRIriZPUnISJO+0xsYMOjJPbUMTPGrHsnL27
kOY4RMFlIi9A3Oudz0bUIBMWqk4vFUvyfnNT6n10pyW00Et36tNfSq2XAK2neSpnwmYi8ZNDEaD1
coQk7C01Oa3jqT99J1OdKtRSMLXcRj35I+Y9VIQoVB9V4Kn/M3nmUIURvedPm8YcrNrSSP6T6lmD
F0AKYjWsspQn+wDKUP2FlbBM6ycGt2Q0e/JSikL0aTSraMRkIpFXSjzsMuFWxGE6xrFWvNr8iuU8
JUpqhqN1KTIpG8zB1LA4XgvW4Jy4SMh2lEGr3Zs7XYPHaeEykW3sLbaACzQyErVm1OKbb5MbRnYJ
t1rELe7DlCvd6Y4Ruta9rryoq93tcre7tTQZGQU5Ut62zIAcU9p3eZtP77JxZ+NV5XvRC0tVNneS
n+TgTNZKU/yKda39paVz2fssC8o1v0+Tb3wNvFzXrJe/4IUvJ59KyIEGV8AD5kuJStpatpnIcMLU
oRBXoyvX/5V2ou28G4pBjBdQlY2cDgwqMv8TzNN4sYjYxLAPxZPObSLXwvKNkYmdhlMSjvWrU8oq
+9wqlbeedFAHZambBMRVpJr1dRWsbGJdC2ABJ7Boc5sVbV+8NhQp9a7jOV5d/So6LlJJfq56ZZqt
2pwv+zWCcY1zS3V6u8bBEbt+/rMfFXs9O3Pwn2SFYJQXuqcqs7msZMLdwFiaqKkimcoZ7en46Bo5
iwG609iV5D8HbeT7TnCBMXVfkgk96gbC0H59lbNtSahku7qar3hW9YKVC0wYAq/Em7pfkGcMW1i3
uYojZuJrR5xF0L5ZmWvmoX2SmNJivoidq3rysS5zWmI+7sWVCvE0uMMNsXiO67g+PjeDoSLudbP7
X1Dzr7Tqi+7uhrLd9r43vvPNrxbou9/+/jfAAy7wgRO84AY/OMITDt15b5ccDH94vBQu8YlTvOIW
vzjGM67xjXO84+EmhsdDLvKRk7zkJj85yotLhpSz3F8Qr0k9Xi7zmUOk5Ta/Oc5znkqa87znfIyA
z4Mu9KFLS+dGPzrSdU70pTMd3Ul/OtSjLvWpU73qVr861rOu9a1z3eocuLojrN70sZN9u10/O9rT
zq+AAAA7

------=_NextPart_000_0008_01C70668.2B665280--



Received: from dslb-088-073-233-103.pools.arcor-ip.net (dslb-088-073-225-046.pools.arcor-ip.net [88.73.225.46]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAC53uMj000700 for <[e-mail]>; Sat, 11 Nov 2006 22:04:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000601c70617$f11702a0$00000000@michaelritter>
From: "metalica" <[e-mail]>
To: [e-mail]
References: <000601c70617$f11702a0$00000000@michaelritter>
Subject: Re: Sports Strategy
Date: 	Sun, 12 Nov 2006 06:03:50 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C70620.52DB6AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C70620.52DB6AA0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70620.52DB6AA0"

------=_NextPart_001_0010_01C70620.52DB6AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Monday, November 01:01:05 AM
  Subject: Sports Strategy


  Wrote value personal in cannot improve her reasoning am she!
  Celeron or Recovering Scratched. No recent reports illegals.
  Mit rechten in Maustaste or hier unterquot auf am diesen wie or ipod.
  Is like real full in of great recipes a but in. Lists vital expanded =
which also am wealth expedient. Stupid Idiot Leicester a onecl jugo a =
ajja is Safiye.
  Drama Gesundheit und Fitness of Privates Horror or Natur a Religion of =
Romantik am! Test gnrique cellino edoardo amv dessins anims.
  Rate None a Continue Write Tell world what! Mascul sv old montage =
Dunks.
  De is actie Google is neu is sie is Ihre hoch in Erweiterte!
  Longer late buy a guns groceries game Forget job. Mascul sv old =
montage Dunks.
  Her reasoning she focus a major many ask where start. Prepare =
adversity beneficial prudent? Advertise at Getjar Device.
  Related Latest pny am Intros gts a. There things quietly covertly in =
even or context must plan ready of.
  Sculptures sur bulles Drift Audi test gnrique. Who prepared controlled =
am choice.
  Unless individual foresight of planning include an quotearly.
  Celeron or Recovering Scratched.
  Now a available cd Adobe only self of reliant living.
  Chemical Romance Rihanna Eminem or.
  Put guide how Jimmy.
  Chemical Romance Rihanna Eminem or.
  Waited too long properly longer late? Quietly covertly even a context =
must plan. Girl taking guys Fittness cica Hilarious. Fgen is ihn a =
passender Stelle ein is!
------=_NextPart_001_0010_01C70620.52DB6AA0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"ready" hspace=3D0=20
src=3D"cid:000e01c70617$f11702a0$00000000@michaelritter" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
title=[e-mail]=20
href=3D"mailto:[e-mail]">gstxcrrnzqj@paulwilliamsmd=
com</A>=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 01:01:05 =
AM </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Sports Strategy</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Wrote value personal in cannot improve =
her=20
reasoning am she!<BR>Celeron or Recovering Scratched. No recent reports=20
illegals.<BR>Mit rechten in Maustaste or hier unterquot auf am diesen =
wie or=20
ipod.<BR>Is like real full in of great recipes a but in. Lists vital =
expanded=20
which also am wealth expedient. Stupid Idiot Leicester a onecl jugo a =
ajja is=20
Safiye.<BR>Drama Gesundheit und Fitness of Privates Horror or Natur a =
Religion=20
of Romantik am! Test gnrique cellino edoardo amv dessins anims.<BR>Rate =
None a=20
Continue Write Tell world what! Mascul sv old montage Dunks.<BR>De is =
actie=20
Google is neu is sie is Ihre hoch in Erweiterte!<BR>Longer late buy a =
guns=20
groceries game Forget job. Mascul sv old montage Dunks.<BR>Her reasoning =
she=20
focus a major many ask where start. Prepare adversity beneficial =
prudent?=20
Advertise at Getjar Device.<BR>Related Latest pny am Intros gts a. There =
things=20
quietly covertly in even or context must plan ready of.<BR>Sculptures =
sur bulles=20
Drift Audi test gnrique. Who prepared controlled am choice.<BR>Unless =
individual=20
foresight of planning include an quotearly.<BR>Celeron or Recovering=20
Scratched.<BR>Now a available cd Adobe only self of reliant =
living.<BR>Chemical=20
Romance Rihanna Eminem or.<BR>Put guide how Jimmy.<BR>Chemical Romance =
Rihanna=20
Eminem or.<BR>Waited too long properly longer late? Quietly covertly =
even a=20
context must plan. Girl taking guys Fittness cica Hilarious. Fgen is ihn =
a=20
passender Stelle ein is!</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0010_01C70620.52DB6AA0--

------=_NextPart_000_000F_01C70620.52DB6AA0
Content-Type: image/gif;
	name="generators.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70617$f11702a0$00000000@michaelritter>

R0lGODlhzAGIAof2AAAKAIYKCQlyDnKCBQAAcY0AggB2iszCv7XksqbL+z8oAGMtC4EgC5kgDM0k
ANcrDQJLAhNOADZKBG1GAH8/CpE/DcM3CNo3CgBjACBSBUZbDVpsAIJbDZVXAL9qCe1iBAB+Bht8
C0B9Cl11C3SIAKuAAL2MANN1BQCWBxOcAECnAGeiCneiAJibALSjAeiiAAvMDhvBDEO3C1mzAIK4
AJ61ALrOAODIAADuAS7qAErRAGXcAIDSA5XpALrqAN7eDgcHSC0NPkoIOGIAQHUAP6AKR7IGNNoO
QAAuQi4sOTclOF0hR3ssNa0mNM0UOOQUNAg5ORQ+PDJIM1k4OHU/RatNR7I2MdJOOg5VNi1kRz5u
N11UPIpfCZVjNs5nN+xpMwF0PSuASDhxOmZ9Q3uONZqIN7p6ReR3OQCVRi2oR0GqNGiiO4SmOqmp
Ob6tNOurQADHPSHCQkHANVbCQ3S4R6e0MrjLONWzMwDoOhXZMjzuSW7oQXfkNKXkRbPrNe3fQAAA
iiIAckwEeGMAh4oAe5UBir4DfdEHdwAfixYegkUsfVYifnYXiJMshLcjfuwhhAs5eSo2fk02dW0x
eXcye6lCe743ju4zfABVhitccUZTfVNsd4RfhJVRisRYe99fdACFdyF3f0l3f2uNc4Jyg5Z1c8aA
c9t6egCcfCKZeDSqdVaci3+hfaidcbuTguiRhwCxiRvMjEu9elfMjXXKepTJi7a+gObKjADZghHi
c0jkc2PVdITqiqjtgbreiNHUcwAFxxwAtUQNv2YAvH4AxasAwLwAsd8AuwsszCEgxUIuzmApw38q
yqouzb0Rw+shvgA7zh1JyUNDzVw4zH4xyZQytc5Lwd1MtQlsxRJZtjdevmVUzXJizqRqvbVjudxt
zQp+wyeHtk2NzlVyzXWDwpOLsch+yNiLswCuyBObuDOrtFSoxX2WwK2YwcChxNOgxADKxiC6zDy1
wl++sYK+uqGyyvz/5pWkoXmAe/8JBAz9Df/8AAAA8v8A/wj+/////yH5BAAj3jEALAAAAADMAYgC
Bwj/AP8JHEiwIEEAAAwqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEM2TCiypMmTKFOqXMmypcuX
MGPKnEmzps2bOFPa28mzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnfrUBtWrWHfm3Mq1q9evYMNO
zEp2J7iyaNOqXcu2rdu3cOPKnUu3rt27V/Pg3XtXrN+/gAMLHmyRr+HDiBMrXsy4sePHjFtBnky5
suXLmDNr3vyWsOfPoEOLHk26tOnTqFOrXs26tevXsGPLnj2Ts+3buHPr3s27t+/fth0CH068eO+X
xpMrX04ZOfPn0KPbFUlUgHWe1gVgv569e3Z737dr//fuHWh48T7P9yRfVP1Q9+bZ7yy/vnt1+/Xd
0xcqX//1/OnJJx552gXV33/oDYggeALORyB8BP7UoIP4MfjdgxdWaKF6Gp4HX1seIphhgfEVGN6H
JQZIIoUS/odigu0taKCMFtbI4osjohfieDQmmCOAQPq4I1IncifjkDbaqCGMKSap5IJFkgghjRy6
KGKFSJIlXJQsOqlily9+GeSGK1b53pIthtkljD96uWabcPZopn9ldnillD026aCXXAqJ54pMpukn
kGauGWiSVZqI5Z1auVRjeX3OuCig/B0JpZ2UnqmmoZKK+Sijgt7IaJZjBpropX8e2mmoOlJpZKqs
6v/ZZquZcupmpLRGGh5yGTL4ZK0DllopoHPWCWx8vsZ4LIW6vqrqkNCC6mmpxQZJqqZ6ikppnJmG
Ge22zq4qLK7aJoskr0b6GmWEwSq4X34P0grvsp/Su2mw3z476r6wpolqvOWC+e+ECs7L3pQ8Klqr
t/yG+q6tCEPsLLeNgmQUpJPeh+pRdMqrYp4BY0tkuPXqm2q+ts7LKcpkWkrvxwp/GTG72TpsJbjG
bjytwDg/iSjIUQlH5tApwyusuG8SrCqzm97rcckps0yxsnzemXHHTM0KNYBaH+1uvyYfGvGt4Qq4
q6ND78dwxhe7nPTCeV4bK9VSy9lwyPdq3WzMTjr/LWjHM9+M9NwSdyut2ILLbDWszk0K9se/cuz2
z4p6LffOGlOuOasUX74x1kiuu3SLXE+eKM+GH4vi6cm+TTipe+dJXdtg45i406ATy7ftAWYOeeJb
z2pf53fbzLeQvVN+vO/khi4tmmsP63rfrvY8qKFsa9kQmwNjbGzLaFadsJhKrxx3g+u6rL7uf64P
s6bX6k3yhuCvrvbkTH/f7uhuGgxzzux7n7vGxDbnSOcqfltKAg/IQLrMroFqWWBSJAjBCmZGaBZ0
CgUl97IMepAtD/ygCEdIwhKa8IQoXAwGU8jCFjbHgC6MoQxnSMMa2pA5K0RKAHZ4wx760Cc7DABQ
/2BSlCDy0IhIPCIPd5JEoiRRiD1pYhSNaA8q8iSIU0RiUJ5oxSpqUShcVCIUmSjGLmJxi18koxSv
GMahrNGLS1QjULqoxjHC8Yx1zOId6QjEOObxj1m0Ix73KEg/DvInhyQkG8eYyMUk8pBnjKQf+8jI
OErSjnCsYyU3uUgnTjKToJzjJzsJykvKUZRQxKMqV4lJT6bSkmYcJR9j+cpNwlKIrGxlKEm5y0Xe
kpSs1CMYJ4lFKwYTL0J7JDHFOEU0YnKJg4wmNGl5Sja6kpLCROQoT2lKOTZSmrXEZi/daMhpHpOS
tzSnMNNYzGU+c5btlCU1d3nMRmqSnOGsZk+4ov/PfsbTKPYcZz2/+M+lgFObugyoIqtZ0Gx2Upm4
3CZCJyrFb9KSmdisKEYdmsaHblOjEW1lNxU6Tj2GUYpELOInA0rSfjqUoeqMqUTx+dKSkpSOwYQo
RVe60WtmVIkuVWQTddpOb/K0kF5EpUSLmkmdlnKmJYWpLYO6F6c6c6YsPSowmdnQpBxUnOh8I05/
aVWPirSMb+SlWZsqz4gmtatGDSlbz8pJiC6Vqz2FKRlVmtCvhrKlZUmmVl350XTKFawjlWsudcnR
wYL1qutU52PjulPGTvSnr7QpWuda2b3C9a95pSo3FevYtKJymJyUqj34KVCo1rSXnx1oLeF603L/
0vW0+CwkOx27VswehajmtGg+Y4vRoZbWtFEdLRWtitzJivOcWEypT1/rTNz2Npvd3CNsoepXtXo3
rKl1LnDPKlrxbrSjWw3neH152Gaq1rnYXS5v+Vhd1L43uXcpax+p+9XuZpegtp2uPu2Z1eK21bpP
fWc+ARpg0AoXt/017HbDq1/EGrPBvmSwZRPMS8BqjyEuLXB5oSvZ9Aayw9wdrIjrm13+ljiX36Wp
g098WQsvGJztHet+4avWedpVw769b3RheFUF59a1TwRvWOmJ45YKV6EnZXJ7AznWKqM3yqj174Nr
vNABx/PK7uSxl21L4A1rkswK3q2Zf8jmNrsw/4dujrOcjyLdOdv5znjOs55jCOc9Z4U2gA70QPxM
6EIb+tCI1k2fE/0UQTv6MyShCKMnTemdAIApDuGHpnmiaX5wetM96bRPOk1qUn/a1PYQdahB/ZNS
p7rUrg4KrHeiaqDMetSxhrWpa31qT9Na1ap+tLAHE+mO1PrYrP61r22dbGU7m9evXnarmx3togB7
09A+tbO1Xe1sbxvXy0a2r4dNboEUuyvn3ki11w3tWE9b2uv+dby//e56D4XX2Kb2vK8t7XzDm9vg
9jSq113ugocl3Rnp9q6b7W5wr/rf9J63wycua31L/OKi9ra3L/7sZAfb4CDnCsIxovBXSzzfFf/v
t8XbbXGMt5zjLv93xvW98Y1Hm+GgDrnOczLyhVgb5f5+OMfxvXJd2zzbNoc50qnNb48bXeAtbzjM
Ky3CS1/F1VKfOcSJDvGTR53pL6852GXudH6n/N5jx0sWqD4ZqxtFaFgfuLLlDnCl47zrMUd715dO
9q0Hndl4z/tqd0740swd6lyvO73FDu+jp10ojLe30Osdecg/HjTqKDy5jTJwuYtb8otHPMVBH3HQ
/3301xZ65c/OdrZ/ftW4Jj2qtT762k997h3fO6hfb3bA6530rb8hBl8fcZb7ffZ3T3nyf478Wx++
8e5+OuKzfnnND1sMnwm+9osjBjFs//ut737/ZRYNfqFYH+TdB0z51/8b8Ttm2Aj5RxrOT//TpL/+
+M+//gty//37//+Fh31dwX7RoQUEeIAImIAKuICtB4A2AQEOGIESOIEUWIFjwUJPwIAa2GZPkIEb
aEOD8IEeKEJc8IEmaBQd6BMKcIIJ6IBPYIEwCBs2NIIsWENEoIApWIM6uIM82IM+SELqcBc/4EAx
WIRGKBo/mIRKuIRM2IROOEJHGIVSGBhPWIXGMYVYmIUDaIVcWBQTcEFaGIZiKBNdWIa8MYZomIYq
YYZs2IZuOGlqGIdyOId0WIc08YZ4mId6KGfkBxl9uIc4ZBqb8YeU9gEfgBSGOEOJyBODYRQI//GI
uLGI9iCJiWiIlriIl4iJmSiJPLGJh8iJlHiJO+GJk3iIPrGJo2iJnSiKqciKP0GKqpiKpYiKQRGK
sSiLpUgVmbiKtDiLnNgTobiKvqiKoPiJvciLsRiMudgbCMETzWgbypiLv7iMuFiNr2iKp2iK0ViJ
2CiMwNiNmuiNyxiN33iN2FiMRLGN56iN3fgU5EiN1TiN1BiM8hiO8AgU9MiO5XgZDvGMP/GI/giQ
lwaJ9iCQbieQloaQBWl1Ael2+9QQmhiO0yiP4niNtXiL9diO90iR9iiM72iNraiPFYmPIumRnoiR
rLiL2biSFUmR48iOEqmRITmSFimL3MiSp//hjz3RkAk5kM34k8+okwm5kAzpk0N5lD7hEBGpjxMp
kzT5lL74lE3JkjX5izcJkliZkuDolPHYjvaYjMZokk5plVu5jySJi1p5j8gIleLIjRk5eFQ4FEKJ
lEFZlEPJkz4BlM5YlHPJFG4ZlsO4lGQpFKTYkjIJixrZix1pkyppjqJ4k+hImOvIkh15ldLIlYNp
mEfxly/ZmPBYmN+olWPJlZnRl3hZl3d5kHwJiadJkFAhmiUpmWZZk44plYlJmi8JkpCJmbc5k2w5
j14pkvm4iy6Zmdboktm4lFjpm2pJlWtJmy/EEKapmkeJmjx5ndRJlA5pftsDm8vpnMU5mh//qZbI
mZsbCZgc2ZtR+Zvv+JWTOZUXCZ5laRTe2ZzraZ80aZnCeBoLuZf9WZ122Z/Y2ZP/WaBC2ZfCUZ/w
eZy8eZbAaZLQ+ZklqYzjuaC3iJ8S2pYTCpiXORTtGZwa+pxpWZWx6Y3wOZiNWBQKqZ3ZaZ0rapAG
mp3+6ZfzGZgweaH4iZhmqZKICZvKGZKTmZ+oaIuz6aBAmpwUOqKSiaPk6YoZqqHEWZaFuZhd+ZsN
1JdKgaU1WJ5uxqUHpKVHAaZJcZJkWqZmeqZomqZquqZs2qZu+qZwGqdyOqd06qQZJKYqup0/6KU3
xKeA+KeAGqgMSIgqtD0gZIeISmRQgacz/9oUhCoViRqpLMGieooUjIqUmNYQlVAJPLGpncqpmxqq
nuqpn2oPohqqcCmpqloSOnmp/1ipQeGqQ6SpnLoTpGqqoFqrPkGqvKqrjLiqwBoS0wmgrFmXALmX
romXSOEQvdqruBoUolqqSRms1NoRw/qfxWqUBKmXANqodEartoqqz3qruyquzzqt1ZquJAejPdmi
djmg3eoUwjGqqNqs0Sqt4Xqqqaqu/CoRr9quM+qi/tmajbY993qwvtoT93quD9mvHEEIifqv2hmw
70qdBCuvBiuuCAut5kquFeOw/IoA/0AUrSqj2FqxA+uu3ioVCOusP+GyHmtBlLATvCCoBf8LYuyK
qagpoC96rHQJq9wJYgzLsKdKrwqbq/oKsirBD2JIskA7HYa6Fkr7Gj5AG3L5tFArtFI7tVxrEFdb
qFqrFl0LGLmweTZ7tnXxqImhtjc7tmMLhmGLFm47t3Drc/aQD/kgt3NbrU7rs0Ahq3iBtz6Bt4Qb
FIQruHd7uIiLtnimrJuhuHm7uIvLE5IbuXnLuG7Wjxbrs8bauQ4JuMvaEIfbE5X7E6U7uR+7t6vq
tCn7uUa5kzIKulIxupR7uYlrurYruJCLuXnGrgf6uo0qu1lRuLVbvIObu7ZrvCZ0D7w7FJorsSmb
lzmbFkJDu6WLu7RLunmrul07l79boJj/2hYNMYS3q7vISxSoe7vcG6ysK73u+70/Sxfme7s7gbjp
a7/n27xR0Qsj5L3b6bnt6rpysbv1m72VO7mKa7NxoL9Akb4MzGhsexjVm7xYsb6ygQ+E8cAaXMFR
O2cWLIEx4K8bPMIkXMK4IbyMgcImLEMGibXgm6UtXBau+ruuCbsKuaIr7EGAq8LhmxWXCqOO28NB
nMMQxKi+y7kB+rf/i8TbesNMvLPSq6X+C708TMTMiMOwu7I828Na3LrBC7xQ/MIAG6t6esRdbMXD
kUNAWaxa3LlfS8bgC68nG6ZYiqfc2p8frIVJca0n+8RvjKxs/MWUmsR5WrIuvMVcjMbA/6HGlSrH
biwUJRu9gszHeTrHdByj+5rHR9i+YtzHnpzI3mqsccyXmDzKkKytjZzEd1zFijx+24PFNtzEfium
NBzIgAzAyMrFR+zEt9zLmazJRSgXrMzJUTHMldzKNmTMf1zMh1zMyNxDyhzF0fzM1FzNjhEMa9vB
yKTN/AjMm2zN4BzOrTy9cAzKZEEA6JzOPIHObJHO7CzOVWeySjwX77wT71zPaXHPBLCEfXAUz2Bn
z/uzsqyXOVvQleoQ+LzO7rzQ9uzODe3QD63OPqHPDa3Q9kDRMtEH3vwanHyt2Imy8asUCW3RF13P
Jr3PEs3OJ/0TFF3SFt3S8Fwc5Eyxkv+MyJ0s0gxd0S5N0i690is90Tn90xB9QN63HMfgQ89by1C8
ymDswnDW0vjs0/tc0T/dE1JN0hC90QLBA4HmBSfRvsq61E1dylQB1VOt0z191iqt1mfN02uN1RId
07gR0JbcxDXNrcl60A0R1VMN0zud1i/d1yN91SXN1r+q1TBIzJ6rmqhMsbPczEA91IWd0EFt2JM9
2Dl92ZYt1z80zfnc1k0x0pxdQ56NFqKdFKc92i0Ey4mR2U6R2qod27I92yL0BZWG2Lg9G7RdhTML
qbn9265hD/qw2wfUDy0E3Mid3Mq93APxB8z93CVB3M0L3dSdwTos3VBY3dq93dwdgdj/vYSL8N3i
Pd4jbArkfd7o3Wbdvd5bmN6AyN7wHd/yPd/0jYYptA7und/6vd/87Ri50N819AoA7oP1HWgNwL4D
3oYFvuA18acMTobv/eDRneAUXuFx1m+hdnPYNmoaDn3ilnEB53Eh/nyH927h1nkNh+GcVnIrjnux
t+KzpuK0VuLjnWkZDuO21uKBp+Iyx+GyduM47uMtPuS+xuOQB+ThJm86DuRKPuM9PuSpFuVMnroS
7hFEkeRY/uNJfuRLLuQznuNb7uVfzuVSbuRg3uVfLnBBfuRZLuRq7uRknt5tHuV7J+V2nuNoDuV3
nuFhPuV73mp5XuRavuZpbudvzuaE/z7mh37ogE7cwiHogt7hTO58NC7pHg5sRN58Tdd3u4fis6fj
Tx7pjI7nkJ5rcG7odEflp+HV/Gpthl7mgz7mpO7njYfnf37q9+blby7jSI7rhQ7nJ17rwH7mvu7n
u/3orx7pgN7njf7qYn58K3frz87nRA54uyfryq7mwl7to47r3S7rql7l6nblyQ7uim7uk27u267n
o97t637njK7s7O7ssP5p2K7r377o9V7tjm6o2x7jHE7pez59/lbwG37juZbwfHftfI51Ad/w8R7s
DAd7zrfuKR7u4p5wFt6FmSZ9Hv/xIB/yIj/yJF/yJn/yKC/yGd8SDr7yVr7xMB/zMv8/85katzKN
zJAdFDoXF5+7k5b6qn67FLCa85QKyVRB9EqM9D6/9EqfxU4PtE0/sVjBkFma3Tgbq1gvl0tvaT+f
l1MR9V7viIcB9gUZ9szsvjK89V/P9XuM8YSny6ls9Fx/kGNMlHVf9ma/mnVPymzPuS9cxnY/sX7/
k4H/unwv9YEf9j7J2FCv+GX/yInvjHj/+HOf+ANp+UE/+dI89w1J9ZL/+NlK9QO985cMvU6f95N/
+ZJP95rP9l7v+Z/f96lf+avfyFQs+7UfvHE8+z3P+kxP94f8v5wf+5Tv+rRf/GA8/Mff+raf+8ev
+rhv+wFp/DREyW1M+7Bf/GofwKL/T/09r/2r7/NDj5Dfn/3Qr/nnD/7o3/qOH/6FPPhqn/5Mj/fd
//nnf/9mH//rL/z2T/3LDxAA7NkTONDgQYQJFS5k2NDhQ4gR7f2jWNHiv4MACiLUqLCjR4IGBRbU
WJLkx5AcF27cONDkx5MsU7qcqdImzZQvR2bk2TInzJcuUfKsufOhT5JFgxIcitNo0pZQexIVCbJq
VKFJq+YUabIozothxY4lW9bsWbRpyUJsKtSjT5Uyta7ESXVqTbx1nX6Fq1evVrhYr96k2XcrUayG
CXMVTJeqzJCCjRa2m5dv5clcNVPeqljiZ9ChRT80a9m0Z86R/86ce/guUsSsU6u2/2oX8N3VsOXi
Dpw7Ye/YjWnjhcw4OG/gszNPZn6b9XKwaqVPp159rIa1o7X7jVqya/eMQSF7ZYoyZmfvp8U/Hpm+
u3ub6cuzbOtdMvzFUsObr28V+vCfMvuOPpgQ4++prsoDkL7tGnTwQQgjlHBCCidErUIMM2zwQg07
9PBDiUoDcUQSKeSwRBQ1PDHFhaxz8UUYY7yIRRprZMtGHCskL8cQZfTxRyCDFHJIIos08kgkk1Ry
SSabpIhHKKOUckoqq7TySiyz1HJLLrv0skEEvhRzTIQ+IPNMNEVzck0223TzTTjjlNPNNOu0Rx47
8wytDj379PNPQAMVdFBCCzX00P9D51R0UUYbdfRRSGNEdFJKK7XSEBYj1XRTTjv19FNQQxV1VFJL
NbUiS1NVdVVDT3X1VVhjlVUsVmu19dYzZ9WVOiR29fVXYEFVJFhiizX2WGSTVXZZi3B19llotcME
Q2artfZabLPVdltuu/X2W3B1jXZccssFMVx001XXR3Pb/dOGQF1xt8FA5rX3Xnzz1Xdffvv191+A
AxZ4YNDWNfhghMsieGGG/0z4YYgNbnhiinNVWNCIM9bYukE39vhjEQMFeWSSnxyIn4P4URnllFc2
iOWX7Vl5ZoRgljllmWdG2eabdeZ5opKDVjcim2E2GuebkT55oaJx/jnppJ+ueGr/fneOeWmoY+a5
aYWO9pppqKWWmmqyKxXRaqyjTgjtq9OuWWu4uw4bbKCFtvvhuXN2Oeult1Z67b6x9vnvwRG6+3CE
8276Z7bdHptttMXOmyHEK8/2IZ0d57vnt9sG/OvNA3e7bNK7fKRDs/zmmuvJR3c67qePDj1py3XN
o3YZVaf55b15Z7whv0/OXPfdacf9eGRLV375KX12/nnoo5d+euqdZ77hFQENWXvk7Qag2uvDF398
8suXcnsbs8f+XvW1bN8hJou7MLAdJUrOoaUWC+190/C/UUfQFOdMAmQI//7nGhX57zNBUqBsGojA
AGoHNQaklPooSCUL+umCqCuL//yy8h0FIXA8QAFMR86zII64h4SUIc9OTigf+QQohUhhznycUiAa
zqU9BQrhU1b4whh+sIcmjAmBsqLDGYLQPg6EDwFhSMIaujAyT2wLCGXTQiFKcUf1qxu7/CfFK1bG
hpxpDBhT054ZItGDPJyicgbzm/5xJ4wsvAps9qLGK/ZmN2e0zRv1Q5w5nuYrfNwNAd9YlygyhZAQ
RCQZByOXP9aQRlo8Ihr9YhkBrsc8gRThIdfTSEgOyJI96QsXE0nH2VTyMIU8pA33OBzh7DGSR2Ri
XrxSRjLeMpWufEwYXynJ32xxlbAMJDArVBpKYlJAmHSNHRV5Ssx48ia/TFApy/+IS974spWXdKBq
qLlIPjbTj+AkJoA4OZ7N3HGagyQmNI0pxm6a0Z3dHAiTGnnPXepxNW6EZifDWU6ABjSWvcwmK/PZ
mc3IM57FpCcub0NND64Tmws15CsZOk90EhRBqGynNFNiz4au0C2iZKJId3jD1qhyhFkcECgPJMQ6
0q8pRZwjfpKYRx7adIwmZCl3THpHKgLTmiY1pk2HCkQodhSlKe1hTEuIx6VG50fu2iCEqmo/LrXv
qgcUTVWZ+sAHfZVqW90OWbmKJa2OiIJrZSNWw9pWCaHPfPnqnqLm2q+6gjSsjongJNNk1rtGS64N
Mcz7OARYbvLVQhsKlCEbgrv/SDDqM4Xtao1WhNi9Aop/eZXTEA+Uwxei56m0nOJnb9pUhe7Hsy0N
oRKhQsVctsaHRmwqKlUI2tiSFrUKOmFr66koJhyvoOIkZyIhytBhkvKf7BzuPqUCUX0m6JzSbGsm
6whK6kLVnAbhbJx4uVxINlGlF0WuKr9rnPA0c4mFqd9DccrTll7TPmv0qHmxe9/Swve9ozxId5PU
wHkOM7q6oW55ARnOZT5TwNtEqDe3Sd/kppC8+4TjP/tJ0bcE1rIFprBQF3zcb+LXw3SBsEDVeVz8
LpTDJu4whotb33RqWK3rDRBuffselJJWkqY0bURVO9IW3jY+HA1tfG0j0tbq/9KKQcTikmGrFBkm
WcYUGuyGJ8vYzFbQrRqKlTcWRQ3vZjUiQaxsWatoqMtOmUtVVrO7/DukNse5fHLFbJ4mWGd7vblJ
nxwzmT2E5wrH0as4mh9YJTxSQz9Wz0vC51EO5VhGatbM0o3ropWEyCczUshJzaJRDZRDbc5WxzzN
JJJpfJ4dEgjUY2StqBWZZCL2Nr9xoY2nkZoQS0/V0SIWoyyXq9TLBDqPQF5xURd87Bcj26FIBDY9
YUxJdP7R2XIGoEtjmJyN7vjUqeRvi+Wn5HIKqMTDTjavlY1QPj8HjtZljDDdmFhqR2jcvR4nsHd8
4Fd7O8LmFjey46lQdrMYoP/SZm6+WUzwFEM63hARUYmded9Zhvh+A7VwsSE4busG2Nwbjzi9n01r
daJwL13MdZHwKetW55S9Pd73yoNJ01IzW78Tf6krcSjaVcdctpuE9Ul8K/Ac19TUvy05jKSU1ikB
mrBlHvPCl4f0o6PIz2ddutOtfnWsT6noW+c6RsbljKyHfTSL+kTXzX52tKdd7Wtne9vdDqphgEzs
c6d73e1O913cXe97r9EvfqElB2ipDfsKAN9B5HfD2+ntTPL74h3/scY/nliJbxDiKX/5WsUC85vn
vL3m0HnQB1byo1fUFEQVetSnXvV0J73QuNB62MdeW6uf2BGUJ3vc5173u+f/fe+RVwjfB/9YtCd+
n4R/fOQfzhrJZ37zl+WENhVf+mpa1PSt3yO7Xl/7is7+9r1vuOoPZAMbQMj4zU9+hZx//OJHP/sN
ov73w5/96ic//esv//mbP/30t8f5+99+92MI+7u/g1g/+/s/A8S/hOC//yvA9sM/BkRABcy/9Ys/
/bPAC/S/AZRADHzACmzA8vO/ABxBCow/BwRBCrw/D+zA/bvAEwzBDFzBNYmID0RBGyTBBHzBD6zA
HQRAG6zBEeRBAATCGwxAICTC/XtB90NCITTBBRxCAnTCHgxCH0RCKrzCH0S/I6zCFTTCKQxBLCTC
JsxCL/TCLvxCHeRCMFxC/y30QRIREREswidMQhPcQhS0QydUwjFsCCZswzV0iBoMxChcQzRUQkPM
wRMsRDm8Qju0QjyUQjUUQTH0wzIkREqsxDGUxEEUwEvkQBKsw/abwYeIQys0xDxswEbswlOcREgc
RTcEwUfkQyhMxFfcwz6kQzYEQ0UsxSlMxYWIRViMxBicwyy8xWDUQxcUwiYsxVbEwFN0xiuxxQns
wDbkv1SMw1W0RgWMQAeUvz38xF+EQm30xmp0wSfURG3UxWnkRXK0RFJUwzRUR1R0Q25cRAYUxEP0
wxxkxhRsxj58RSn5RlNMQnz0RWMER0QMR2K0xD+UxXyUw2UESIKcRYOsRf+JZMWBPEZTFEhExEYs
BEdGnMVsNMMo9Mg7pESBzD8sqcdnnEhalMcixEeGVMiGbMaWxEUyNMaUVMiCFEaEvEh6hMeZfEaO
LElz/Eh7XEGZxEGU1L+lzENlHMY55Mca6cmBtEqblMaGxEiN/Ek6BEaaZEqIvMSDnMd4rMQbZEdc
/Mai/MMv7MGgHMm1bMqtJEutdMtN1MqdzBGZZMl+JMMSFMtshL++nMaYdErCNEzBZMPETMix1ERk
TEaRBEnK3EZyfMp3lEwLPMejdETL5EoN9EDRPEoJZMvRtMtMuZjvW02SuzTWfM0oYTPYJD5RnE3b
3I4c2A7ZvE1z+Rje/E3/4AzOh4AELzGLDezJxNxIVUxAx1zE+evGh2RMk0RD5gxNWlTMz/TMdARF
j4TAyWzHljxOimTJepxA7wTPypHLXCRG0DzDTnROBIROudxLqFRKi0RLTsxKiQTM9TxJm+xKx1TL
keRH6lxO96RD34QIzNzE/yRJTBTKFixHaDRLyoTEiAxHRVxI5czPAT3QlwRFnBRQsSRQDwXRD61J
fwmZBU1KnZTKtuTEqJxQbCRRlaRQzrzJjARL9bTRtsTKuuTQEd1P/0xLBm3OAExPphzHGQVKDnxL
CJ1KxHxQLjTM6gxGy+zG6bzPjEzSxtTME7VRLDXJwexS0oxAX7xOyGzN/6DZUSPFUU98x09kxirN
RAl1U2hM0xutUAfV0cU0y6cE046MUjddURr90+Zs0wpEUv4EUxS9Uy/l0wf9y4SkSnR8TxkVUh+t
UEJFzS8N0Lxk0g4FRE41UVJtEcRhUwbd0jd91CedSU/VSEqNwZ2kU1fUT4cM1Y900vpc1B8t1bnc
1TDU0gSt1Q69UiA9yepM1riEyf5UVoBcygNETjEtzdMU1YeE1u7szOQc1Mmcx3X8zmz10kYVTnIt
V3O9vN08V1sZVnVt17FTTXfVunTRCE2JV8qbOnvNE6rUPuOM1m4VRL/sUxZ8TuksUwNt0laVT4Jd
TGe90Q2EQck01jAVWP+iFNMDLE0nbD0a/NdutVOKdVL7tNZgjdP9NEeTFUn6rFggpc9HfFXOnNRl
RUY9vToV5dgJ9Vg43VDIpNFVxU/4rNRLHdJb5dYGDVoNnUQRDU8P1VgFtdkaVdWnBcYqZVT2dNH3
lFNZHc2bjdVxHVLtVMXoxNJjldQSrbuaDVOr7VpYfdJ9JMCLVUeYJVmHtM61nVKLTdi/pFa6fEwq
9cxa1VU1xT1U9VmsJVyfRFhXjFHDnVtBpdM/xUnndFlX1dLKPFkhbVZKZFpiFczyLFnwVNkYjVXF
7Uo9pVVqxdzN1dRRRVuQfNz13FfUxTo1eJBNDdujTVXAjU/RrVPS/Vn/usTKlJXbsEzJwixVv0VU
1Mxd0KvdHf1RM81Z3Q1YbFXW00XRV+1F8jzZY23Y6TXNly1HqcTYwIRPmoXXfB1aDuq9823ac/G9
9Y1N931f7nO+6pBf+wW/7LhfXKNfONPf/eVf6hBVZw3KqCzc4QXbFb1W7M3M0ITeRY1F7lXM6n1Y
8R1Y5W2QIAi90oBU0k1avGxe4h3PkPVZr3Va4e1PYO3VEy5QAEU/AK5fkbXT4L3ZNJTG4nXeYczU
ka3PXRzP29XQH/5S471cFGEFattgvCVhDH3WOoVLuw1RFdRHH/5g/HTgnIzZw0TfM4XYNXzhAI7h
0j1NJq5cxF1cKPbT/0/V2+pFS9MtVrptXfPsWOTF4t9EYrX126pd4qi92jE20TemWiNdUjNGYYoN
Yrn9R3j04ulIXd8NS9aN0D3OVkcO1Otd1i0E2PANUkPeXjlOVap9Xw72XhUW255t3rOEyxJeSAie
4lOO2bI01IN9XbCVsW0QE0HW4zW23bBNYFxG1jX2V9uVViemxihmR0mGWLvlVNj1vnRdX0WWDv+9
32Y+32euZmu+ZmzGnWi232zuZm8eEnb4ZnEe543ZZvklZ3ROZ3VeZ3ZOu3poZ3iOZ3lWC3OuZ3su
13nOZ6O754iwvdnUZyI5AoAeaLUQ6HHmZ4jw538maB8x6INGaIiO6P/tY2iKnmaJfs2KzuhF6YJu
qYIq0GhxCSyPvujpa4PBE42RJmksqRyTNmmQXpbSaemTVmnhlGmaHpM3c+mXVpabFh9I6Wmnu4Ec
sWigXphRKWrmOeqB+AAzMQimfuqmtgeoZuqFoOqljmqqnuqsjmqpNhOt5uqr1mqnhuqq5mqrnuqx
PoitJmuFEOsyMWu0fmu1juuyfuqxxmqw7mq4xmu7Duu0duu5Duy0nmu8vmur7urA/mq9Jmy9PmzF
BuyyJuyzfmy4vmqia5SIOGzEtuzN7mzB7uytbuumnuzMBmvHzmvOJu3UruzTFu3Bfm3QNu3K5uyE
aO3Fpu27ZuzY9mv/y7Zt2N5szeZt4C5szw7tt97r4cZt2g5uw35tzX7u2WZuMWHr4vbq2RZstjbu
2u5rz24I6Jbr7e5t2a7u3Q5v3Kbu7w5r4u5u5V7r0c7r7Lbr4HZv8f5s6k7u437v7tZuxGbu+DZu
1bZv1P5t2E7v1a4T9Gbt6x7s+GZv9SbwyP5t6W7s9rbuxF5vAZfsAufr9Zbu+bbuAG9uCv9wCu/v
677vEs/v+sZu/Wbv/7Zw/M5whphwAydvBz8fhVHt767xv5bv96br6gZy8K7wGcdwE79wFDfs9A5x
Hf9x7h7y+uZv8Q5tEqdyGD/w/R5wK89yLKfsEQfxvqbsJIfyFD9v/8Xe7KNu8gv/bA0vcRrn7gk3
byKPcC7f8SsPbxKPcfwm7TivcifHcx+v8z9f8haH8OGW8tP27R7f8hVfc4d4czYn9MuWrEePaztn
cxFvcNFWdO9e8Bsv7x53dEgP8jCPbksvdDIH8Cfv8js/8i9ncRQfdbLO8xT37xbXbinXc9fedTPH
9JUui0vH8ht/ceVm9dIe8ji38fIOcA8n7mDXc1zXcmfna/NWc2EPdGFXdmRn9vEmcDVvbVs39OXG
8BpX7VGx8wQf8w1Xcv5271X3dSGXc/WWbUUP91BfdDhXcF+fd+e2dwHP99wG7HKX9tzmdyj3crl2
a4Qv9sae7FUfeP/OVmqkLp2fnniLv3iMp5EiyPg12+mPqQZv4XiRH3mSL3mTF5hTOAhhkDGPb/l/
aASXj3mZn3mar3mbj72Tv755LoWb73mf73kU+HmhRxdSoPScP3qkT3qlx5Ghb+elp72mZ+enX72o
X+fXFOqLr3rJw4YmmXqv/3qwD3tyDQGxL/uw8y9o0PpXMfvx8SK2502lK6C4x7L9+ZC5L6CfyBDh
wHs7SbBEozqpg6FEuyo/2yqFwyonqjp8s6o4+vvGnwpA23vFMiDFMCvKKrTE5/vHfxCzOHx4khDK
YvzFgrfaiHvK3yu/l7fP15/RqPzRX7emI/1AQw23n/woW68mIqL/JYuxGuu059J93799JjuxWHut
mSr+oHOyURKvH7utW5s1mLop8XIO5m8vmMIPFwqqJBKy1eIt2goylGuw7E+1lQO1LTqzdyWLxGAu
AnMv9ro4jns157A4dnuuDyMubZp9zWj/PiInyAcIewIB2CMo8CDCggcNKgRg8OHAhAQdRqwYkeHE
hQ0vasSIkKHChBstZgxZciRKkCJNcvTYUiPMkCnt/atp8ybOnDhXfuw50WVFhxRLQhQ6lCdMj0BP
QjQpVCZTqD43Rn1pUWpLlQWNsnR6FCTYjmIXPo1KEelSqRkflo0ZVmlHuByvnpW59ehArk1/tp27
FSnVwCRnuo37/xQw4oQ6b74la9ds15NXVzYlTLjo2JlAA68tXHWw37p2I6t93DM0VsFQtYLWrPpz
Y9RES0/+m3YzaZVyHVPmnLozXc+KFxMvTtxlbNm5M4/uarkqZuWoT7O8nfq3aeHVxYbV/txy89aS
kWfeDHkucPDl16OXjjKmSPLWzXsnaPw+/n9cL9btq5f0XcF9hNd7h5HnFVtetQZagnDhRuBaouW1
V1Bt6XaWgUmx9ZVhaA1Y2W99TdjdYQGuhtV+E/K2H4YYBqUiinwBdiCE6tVoYn45zqBTYj36+COQ
QQo5JJFFGnkkkkkqmSRrSzr5ZJE5SpkTlFVaeSWWWWq5JZcmdv/5pZVTEgcmmWWaeSaaaaq5JpvD
jdkmnHHKOSeddV4pJp528qYnWk02ySeREpL5J6CC1gYoohIZyVqKHh46Y4sl9qgVbpAa+uNnRxL6
KFj9ebrpjBJJylOliEmK0ajxqfooZakCmemZxq1J6auBwheeo9SByuqQuwYJKqPWTSdkdz76uqpT
heWqbGLHTgoknmKaOhSq1Y7I36cXbkgdWdb6F+mfxaZqoGhllTgqpZ+WFiFR6n7YrZcwjsvsZNpe
e29t51Lb7obhMmtvvOa6e6uXInYm47YwHgRKmMVR+OC67A0WbGXjrVeqbsjSpqvE8jKnVHSuhVqs
d4qK16mHuwH/vNvGsAp4V8Z+/XudiSyD7J5k0U5p6otG9RvxsBv35nN2IjcXM75Ciwezn0wXfV5D
elFsscnvcdvoaNpC3TTR4rasMXYlL0300P/Vp5bUbT5cNWQqc0yoZE9/ze3SYmMHbNZvX9yq3gSz
THe9VX9dqtVeuw14WnYLO7Lgbv+d16w9720VeI9PJbPj8NFK7+OLc/3x5JX3nS9ziE+seeifY546
4GGfznbHlxfIOn1qUliwwZeh66KoA5Or4HVka937oTfu7ju4MQI/LrkJvhuevs/Hey1yp+prrW0e
08Vi8sRDD52EKV5PvYbLX1qlrFs6myj77bv/fsM654emq/Db/38//vnLmb7+/fv/PwDvJL8B3iSA
BjwgAhMIGAIy8B+/qtP5rLS+ZeFqgnzrjQJt1zozWTAiDcSPkzqoqWaRSnro6pOIpnWpjG1uUchC
mgT/tyuSpYlRz3qfCF3Is/h4bk8l5BXHwNa0EcLuSzmU0ww3WCYbkrBLsspQhfiCPfE1j4feCl+k
XnirkP0QZvAanRTRs68pZi2L8GKRwkbSPDLKKClR/OIXq9i9mo2PjgnzYrcq5j2sgcxFCfujGb34
wQHK52UsZN3QTCezIJ7IOV083OtcQzXNIC1ud/teJM0CohfljYmvC9nWKnhJQ9KsY47T4yEzSZNB
6oxswdNQjf/6iEUCHa10mjuhKzGINuvxTpJ/mZjZRjezn7wwmKFUFHDS1rixgNJpN8vjanKnLEsa
E4zRxIsxq8nKVurScLR7ZNHsVrxlhiqSghvcif7WQmrWx2vWrNTBQnQ1ZrrnZHPjnBsr+UqcITN2
HtlmtAopt8wFzWZaHOJpage9s21xb8mBmuJK5k6juQxFqLuoGvlJH0hmKnHWPNt8JBYVgOYJigqq
nvGq2DtA7rFVqJLegmY2vXSNMSt6rJlLi9e28D2PiiDiKUkEZkXtFaWOfYTmL6/XqXK5FFbVXGoU
nafUVZJUSl06Ygb9h9WrIhF+Vd1ZluqX1bEqsatx2mqZvrr/E7Kyta1ufauP+AfXudIVTmq9K16l
RTAKui+CTdQSQmX3qwkS9qqBjVVeE4vXHeatiw9krK0Y6yzCQemwizSWrVoo2G7qkJFARBJa6/rX
Y3UQb53lK2Y/qyTLWi21xHLsOcFWpHWCKbR1NY7AMPMzpOIUYbecjfmyaB4OvfFdPmWQGX06vN56
7I52XKTZhHowk/rWjjRNY26LK8bdMndUiv0ueG0yn5vGlJiusyhFz0tQuWm0hJBEJws3OTZ9TtKP
3yyoLUPKQ1U+kzXh/W9i9btPBL2SvlR56mYFmssePpN8+FXOz15axNY6yKOhXK83JxyhYubuvQcB
MIgJKFnu/+CTn6VzUOFAp8+MctbE2XMxfJXGVHNmEjbohHHn2unZG+NKtE8SsEKP6bcgrpd0dWNv
eu87UBLneJgHlR2GeZxhRk5ylElWrY9X8sS2fWip1RoPxshLXcgZOXiCSumXcYfm5WYownDcnny9
2MYXRy1bkPvjFns5oHUBVV5G3XNIQizoaAE2sliybZYT3WNFP0muszX0lRDNaNEecdCWvjSmM63p
TXO6057+NKhDLepRk7rUAN4EoSet6lWzutWufjWsYy3rWdO6raa+Na5zretdD7rWvv41sIMt7GEz
mtfGPjayk63sZTO72c5+NrSjLe1pU7va1r42trOtbQYSu//b3v42uMMt7nGTu9zmPje6061uOzGD
Get+N7zP1O5407vVSbBfu91d733ze0n57jfAA06keQu84FjaNkDzjfCFM7zhuW63wyMu8YlvmhkU
vzjGM67xjXO84x6fti8+LvKRk7zkNcmHyVOu8pWzvOUufznMYy7zmdO85jY/tpYgYPCdf/vmPv85
0GdOhaCznOdGPzpCiK70pYMY6b6GgtORlI0FMr3qVr9r1LOu9a1zvete//qqr85yVJBaEDUHO9rN
Lfa1s73tbl+MLt4u97nTPbFpvzvev76AvPO9734XYN0DP3dA/73wAFzEjyUN7yAYftZ+bTzk8UcH
Iwm+8pZ6vzzmM6/5a7/g5RLYPOhDL/rRXz7yplc16VOv+suzYfWufz3sYy97q5++9ome/cUvgPua
2L73vueT4n9PV7cDYPc+D/jjha/8/AV/+c5/PvR/dIyxxiL6eoKF9bOv/e1z/+DG/z74wy/++XW/
/Iga/88RUHXzs19PAQEAOw==

------=_NextPart_000_000F_01C70620.52DB6AA0--



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 kABMFZTU052999; Sat, 11 Nov 2006 15:15:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kABMFZgv052998; Sat, 11 Nov 2006 15:15:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kABMFXIX052992 for <[e-mail]>; Sat, 11 Nov 2006 15:15:34 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kABME3a8004968; Sat, 11 Nov 2006 15:14:08 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sat, 11 Nov 2006 13:37:23 -0800
Message-ID: <[e-mail]>
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.1807
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thanks for the explanation.  I will coordinate with Steve and Stephan.
Perhaps we can also take care of that pesky hash algorithm agility issue at
the same time.

Mike

-----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, November 10, 2006 7:53 PM
>
> . . .
>
> The only way forward that I see is RFC 2560bis.

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 kABJbeDl035609; Sat, 11 Nov 2006 12:37:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kABJbeq0035608; Sat, 11 Nov 2006 12:37:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kABJbdhx035574 for <[e-mail]>; Sat, 11 Nov 2006 12:37:39 -0700 (MST) (envelope-from [e-mail])
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: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Sat, 11 Nov 2006 11:39:28 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccFx4komIH2SBRnQ6+sz/9ElP1bDwAATQew
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Dave Engberg" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kABJbdhx035603
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

>From pragmatic viewpoint, when the AIA in two certificates point to the
same Responder, it is the subscriber and the issuer CA.  That is why
pre-cached responses in some of the products always contain the CA
certificate response, if the Responder is authorized to provide CA
certificate revocation status.

The above is a common implementation and avoids combinatorial problem.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Friday, November 10, 2006 10:53 PM
To: Dave Engberg; Michael Myers
Cc: [e-mail]; Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Dave:

>I agree with Mike, and disagree with Sam's original assertion.
>
>A keyless responder with pre-signed responses can be fully compliant
with
>the mandatory requirements of RFC 2560.  This is reflected in both the
>"letter of the law" and in every OCSP relying party app/plug-in I've
tested
>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

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 kABHw4Za023013; Sat, 11 Nov 2006 10:58:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kABHw4Z0023012; Sat, 11 Nov 2006 10:58:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kABHw2YO023004 for <[e-mail]>; Sat, 11 Nov 2006 10:58:03 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8672 invoked by uid 0); 11 Nov 2006 17:57:57 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.121) by woodstock.binhost.com with SMTP; 11 Nov 2006 17:57:57 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Fri, 10 Nov 2006 22:52:34 -0500
To: "Dave Engberg" <[e-mail]>, "Michael Myers" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Cc: <[e-mail]>, "Sam Hartman" <[e-mail]>
In-Reply-To: <[e-mail] treet.com>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave:

>I agree with Mike, and disagree with Sam's original assertion.
>
>A keyless responder with pre-signed responses can be fully compliant with
>the mandatory requirements of RFC 2560.  This is reflected in both the
>"letter of the law" and in every OCSP relying party app/plug-in I've tested
>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

Russ




Received: from corporativos244217-101.etb.net.co ([201.244.217.101]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAB3ZQvS008498 for <[e-mail]>; Fri, 10 Nov 2006 20:35:27 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c70542$6f4df970$00000000@lina>
From: "knows anything" <[e-mail]>
To: [e-mail]
References: <000a01c70542$6f4df970$00000000@lina>
Subject: Re: Dietquot Couturegrl Kitchen
Date: 	Fri, 10 Nov 2006 22:35:29 -0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C70518.8677F170"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C70518.8677F170
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C70518.8677F170"

------=_NextPart_001_0008_01C70518.8677F170
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


  ----- Original Message -----=20
  From: [e-mail]=20
  To: [e-mail]=20
  Sent: Saturday, November 02:03:12 PM
  Subject: Dietquot Couturegrl Kitchen


  Inspired Miplay Leaf Unforgiven of sht Else or Short versionand =
Justice.
  Earth Instead in playing usual star stars! Hourly a Technology =
Business of Developer ibm Websphere Server Feature extends.
  Frequently am Asked Hello from Germany a maggie Minutes Everything? =
Paypal or issues am related am phone number am Blog Entries is Comment.
  Birkin Lvlover style Chloe had chose Dimple Marc!
  You currently not logged or viewing. Cias selling a covert a.
  Designer Forums dedicated in. Loops Treke explosive footage of Mike =
Rupperts.
  Quotyou Dietquot Couturegrl Kitchen Food. Nfii Ultra of Suck dick =
Empires well a. Dropbox am regarding Subforum azia Contests or?
  Sell of offering sale is Listings Shoes of.
  Important Thumbnail preview disabled am Vlad is Days ago in Newcomers =
Lounge. Advice virtual am dub together edit got or Videowave Fokking =
Great. Robotic parrot in id one of huge kickass.
  Wolf a Blogger back federal prison Gnns Dvds True Lies! Copyright copy =
Jelsoft Enabled vbseo rc.
  Sonic of foundry is Real previews very im too.
  Necklaces is earrings etc yay nay in! Loops Treke explosive footage of =
Mike Rupperts.
  Earth Instead in playing usual star stars!
  Rc Musicmatch is Jukebox Worlds music player. Light darkest secret =
Agencys cut ambient.
  Btw move link of doesnt seem.
  Chloe had chose Dimple Marc Jacobs Urgent opinion neaded.
  Btw move link of doesnt seem.
  Bioadd Videosthe big am Ladiesthe Leaklos Livemtv is Weeksucker. Jump =
select Control Panel. Hours Designer Forums dedicated designers Louis =
Vuitton lv of Reference.
------=_NextPart_001_0008_01C70518.8677F170
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"valid" hspace=3D0=20
src=3D"cid:000601c70542$6f4df970$00000000@lina" align=3Dbaseline=20
border=3D0></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color:=20
black"><B>From:</B> <A title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, November =
02:03:12 PM=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Dietquot Couturegrl =
Kitchen</DIV>
  <DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Inspired Miplay Leaf Unforgiven of sht =
Else or=20
Short versionand Justice.<BR>Earth Instead in playing usual star stars! =
Hourly a=20
Technology Business of Developer ibm Websphere Server Feature=20
extends.<BR>Frequently am Asked Hello from Germany a maggie Minutes =
Everything?=20
Paypal or issues am related am phone number am Blog Entries is=20
Comment.<BR>Birkin Lvlover style Chloe had chose Dimple Marc!<BR>You =
currently=20
not logged or viewing. Cias selling a covert a.<BR>Designer Forums =
dedicated in.=20
Loops Treke explosive footage of Mike Rupperts.<BR>Quotyou Dietquot =
Couturegrl=20
Kitchen Food. Nfii Ultra of Suck dick Empires well a. Dropbox am =
regarding=20
Subforum azia Contests or?<BR>Sell of offering sale is Listings Shoes=20
of.<BR>Important Thumbnail preview disabled am Vlad is Days ago in =
Newcomers=20
Lounge. Advice virtual am dub together edit got or Videowave Fokking =
Great.=20
Robotic parrot in id one of huge kickass.<BR>Wolf a Blogger back federal =
prison=20
Gnns Dvds True Lies! Copyright copy Jelsoft Enabled vbseo rc.<BR>Sonic =
of=20
foundry is Real previews very im too.<BR>Necklaces is earrings etc yay =
nay in!=20
Loops Treke explosive footage of Mike Rupperts.<BR>Earth Instead in =
playing=20
usual star stars!<BR>Rc Musicmatch is Jukebox Worlds music player. Light =
darkest=20
secret Agencys cut ambient.<BR>Btw move link of doesnt seem.<BR>Chloe =
had chose=20
Dimple Marc Jacobs Urgent opinion neaded.<BR>Btw move link of doesnt=20
seem.<BR>Bioadd Videosthe big am Ladiesthe Leaklos Livemtv is =
Weeksucker. Jump=20
select Control Panel. Hours Designer Forums dedicated designers Louis =
Vuitton lv=20
of Reference.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_001_0008_01C70518.8677F170--

------=_NextPart_000_0007_01C70518.8677F170
Content-Type: image/gif;
	name="be.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70542$6f4df970$00000000@lina>

R0lGODlhzAGEAof2AAkOBnwLBQqLDHiHCwQAfYMLcg5zh72yxsbXxaDP9jUSAFsVAIIhAJgmALMh
AOsaCwo4CShKADNOB2FDCnoxAKc8DrpNANw7AQBRAhFcAEZgAGJkAoFtDpRnAMttBN1gAA56ACGB
CUF3AGV0A4Z+B5eCBMx8CNaMAACRAB2RAD+nAGSlAI6RAJWmAMqTANekCAOxCCy+AD6xAFrIAHvG
C5S6AMbEAO7NDAHfAB7pDELSDlbWB4jsB53rAMfUANflDQ0ANSgNOkwESV4OMnoAR5EHQsgATdcA
SAAtSCMSMkotOF0bM4AePq4aNbEjQ+MdRQBFNCI+SkhLPFFETIFCO61DNrxMPNw4OQtUQhVXRklV
TWpbSoleAK5gScFdOtlXSguNNB6NTD96Ml52Tnd0N6KCPMCKR91+TgWdSSugSz+iOmeWSIafSqGd
QcGoO9uqOg7CPBuzSUe7Q1a0PY27NZjAQc7GPNnDTgDbRyHuNzPjOWXeSYncPpXsMrreM+nZTQEA
hS4Gdj8AdlkAhHYGdqwMibIEceQAcQAdgyURgk0sh1IXcoQnh5wSdrEmgdIehwY2dy1Oh0U0f1I+
d343d5xOgLg5edk1eQBZfiZdgjljjWpoiHVieJddd8FeiN5WhwCBeSqKhzF1eFx+cYeNjph3irqO
jud7hwClihOReE6egm2fhoWpc62dhLyWdOutegK2dxa3gEjCf2LCd4nHh5HAfMvHeuzHdADmihjm
fkHlfmnji4TqjJnigbnXgNrjcgECuCIAtEkHxGcGwH8Jt5YDxLsAueAAywAkxSguwEYWvVUSxoMW
w50qt7chyt0byABAsyo2yTE0tl1KzYkzuJY5xcM+zuUyvQBXxBtuyjxisVhZuYJtuJZRyrJUuO5d
zAWGsSyCyD5+xVSIt4WMx6OJw7N+zOODzQCcyy2UvD2YwWaRs4GbyKyqzMGmveSttgC5vi7FvTLI
u2y1v43Fvpe1tfb/6pKdrI2Mdf8AAAD9AP/zAAEA//8A/w3y//z//yH5BAADpWEALAAAAADMAYQC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnDgRAMWLGDNq3Mixo8ePBe2JHEmypMmTKFOqXMmypcuX
MGPKnDkTAM2bOHPq3Mmzp8+fQIMKHUq0KE2bRpMqXcq0aUyQUKNKnUr1ocWqWLNq3cq1q9evYMMi
vCq2rNmzaNOqXauWLNu3cOPKnUsXrdu6ePOudcq3b8o7d/wKHky4sOHDiBPPBBxYsePHkCNLnjwZ
MOXLmDNr1svZIePOoEOLHk3a653SqFOrXs2ac5PWsDMeiE27tu3buHPr3s27d1fNwIMLH068uPHj
yJMrR35xufPn0KPnbC69uvXr2LNr3869u/fv4MOL/weqqSX18ejTq8fZVYD7ke4FwH8fv358e/fn
y7dv/2R+/SX9RxJ/LAmokoH+EShSfwPWtxKD+r3XIIIBMmjghRJGiCF/GZqk4IYTCshhhRx2uKCC
IZqIH4T9lXgfhCs6GOGEANrTXob/vahijflRmKB8NAYZpI81FrgjiR7Sh6OSQP4YI4A5MplSj1IK
eWKTV17ZJJFJAqkjlk9mGWaYMiI5pYQiotkhlVuqiGCaXi4ZZZtA/sammETeOeaDJsK55p8HlokS
jIP2KeeYFM6JaJV7Frlio35iqaiYRkq6n6FxWpqpo5yaSeafm87X6ZuH8ljmpOfN9GWVXKLIpZV7
wv/4KolHenommIpO6umXUJZqK6eRCqkrn2BSmiWpl9Lp5K29Fstroc66qWa0yerZqEzN6fiotdBq
6hKIooIKk5ItzfrhocMW+eyT6RoLLKDiUjqru+6u22yn1wrL6L3QdunvtbxOW6Od5LLqYogpEqrl
iMeCWiu/gRZ7a7IQJ4ruxcr+6DDD7JYaqcILJ9yitBTna7K8++IpKL3Isizluvn9FiOTvnYLK7P6
lpxixCfjy2yuNavLKMwPW4hpxSjSS6zANLbM8b/9fkrtzqOS7HLJQ0so88jt0npz1EKDrPTCD4/d
L9AZ75q1zvPauyiLKc/rJIhOp/y1hkHn227LABv/fKrWFOXEdd4J+wy1ymn/Gjax46799rIdK9u1
v+BOyq3clB9dd6iHd3415HwPafWchC/1d+kzS/3t0Y8/6vPkhs+NMb5oIy2xuJV7PG3igTbNOpyI
3170kcC7jvLUanv7dtnYBn783ar3DCuVFSJ+ZvU8e8105BCnTjTbdlsPqZrYk262mdy2ruvKPee5
/eVW22qtnwNztTjeDgLvovC4xr17reDqkqDYtCFMsW5m/SugxPD2Lp01TFPVSlrh6rUx5WlJcdBD
YAKDNb0Bysph9ZvIevyCOZmUcIQoVEyqUti4Be7khCyMYU9kJsOXwNCGzKuhDnmywh368IdADKIQ
/4dIxCIa8Yg77CESl8hEokiliVCMIhQDQEUpWtGIVAzAZbJYRS56sYtVFMkXV/JFLZJkjGfkoj3U
OJIsptGLKCkjG9cIx5TIEYxmFCMe5+jGONZRj2hs4x1VEkg6hhGQJ5kjIPNoyD4u8o2NVGRJHPnI
Sr6RkZQsZCYPmUhOLvKQjqSkUagjSkNOMox9LKUg8xhKVHoylXwEpSwZ2UlamvKWtbSjK80IS156
cpWIDGYjgfmSXq5ylrWkZSx9ycpl4lKSwiQmLi/ZzGoKc5O2hCQk2djKbD4RJ6UUpRs36UdlMlOb
wfyjMdNIxldyUpXTPOU5n4nHXBJTnLss5jt3if9Mk6iTm/tkJjLxaU6CahGakbxnQBWazU8SMp/R
lEw43XnQX9rzotLspTHh2U5M/lKVHI2kNRE5UVuO86P1bElJRRpRhzp0pWg8qUkDitKKNjSmKdXm
OnXZUJLe8Y9CEQgnJNJSjoZUmv6sKUPp6NOePtSjM83mURXZzXhaVaZJtalLYArGlrJ0jFytaFOz
yk6LAlWeTDXlSm85VYtec5bn/OZN1lpOt3q1qP3EKlZlgk2yZrWMl0TnXtEJzLAC1q/brCdIu6pY
peo1pxmFrEtz+dioClKPLFnsQt/q1MHQladu7aZk6TnPxlbTrtH8LFKTqVOIEnasaD3qatXqSqv/
0rayZIXlbRE72Neilam95axsjdpP0jrReap9KkZ3+1u28lOybYUqYn0rT6g6s7mFdSxqfbvXQi6V
uYkV6GhFq1nlflWpn+ysbb9rXLnSJLk8XW5wjUta6G63r9idLTVHmt+rjneemdXuaaUK0fkOFo4T
jaxl4/tS9FrSvOXkrH4NA1/MThi/+E0nXAG83tVmuL/HdC6BR9zagt4Vozs9q1d3KuJjalWwxZ2w
cDlsUJWiNsUxBgopHezXkFZVwyae5nU7jFcOgxjIKw6ta0UrY3v++MH6/fGTh8nky7LzyKmVck3V
G88DF9eN/9gBVMApSR+r+K8GpShkqerd5ab3/6mA7atmgarJw7r4zHcmLELLm2ekqlGO+SUohIfZ
56QGmM5ltrNsr8joRjv60ZCOtKQnTengKLHSmD7iXjIdlNUkwDeg1ginO52aT4f61M4btU9UY2pU
90bVUEwArGdNa5rIWjE4qDVK+MHrkfCaH77uNUl+XZJfG9vYwUa2PYg9bGGb5NjLPja0dz1tZp9E
2s+utrSJbe1kA1skyu52cW6t66ZcxNrodja41V1sdkf729xmt7ib/W16s4TZ8a53u+Gtbnz3et7r
1neyBx5wkZSm1a72DU78zW+BTzvbDu83sMUN8ILveyXd/re7321vjgfb4xC/dr7rXfFyO3rkE/+X
t7JDTnCWt9zlL4d5x2c+cIBX/OYa13fJTc7oeEcb5Ov+uch1vnGgG53mFqe2wGN+9HwPXekpeXjS
eW4cNVzG5zm3t80lvvSAb7vrUw/7xZ8+9o5L/etZV7rKwU71niNb6hzfOtHBTvGiN93uRxf7vDMe
7qLvfO94b/tNkIJCaMN922QXe9hLDni25/3uS5f74//u7p0LfvCEV4/hVw7yxiM95oyvPN5xHnnR
d93piU+94i+/k8yjZ+WcT3fpI050o4d+9hiXeN75zm+t+330gWc9SbLQeuecR/btTn7ZvV7wurPd
8yrpe8rpLmzke5z00Te9wRO+GwDcZS5EGHP/0nm//N1rm/ZqR/+9z3/2wz8c7dN3P+5txP36cyUE
YBH+S+zPf9vo3yX9F4Cw8X/mIYAGmBoEyBIHiBVDsIAO+IAQGIESOIEUWIG68X0WmIEa+BWI4X2u
l4AgmBxn4X0KUQobeIKoJgtyMRgeGIIuCEUtiBMpoBhv8II2yBfed4M6WEQxKBT+sINA+Bw5GIRE
KIIoeIRIyBtFuIQ+xBUYmIRQGIWp4YFSWIVW6BF+MYRMuIUs1INc+IXq4YVgOIZO0RZPeIVomIZv
QYVq2IZoGBlaSIZyOIeS5gnPUQbd4YZ6CBpBsId++IeAGIiCOIhoQYcyoQHhoQCGCBTFMGlm/6BD
gyB4hDiJlIgRi3iJmJiJmriJnNiJnohElRiKotgQn1iKpniKqJiKmHhpmLEQwvcBH/ASsFhEszgS
b5ETHhiHxVGL9sCLswiLwFiLwSiMw8iLI1GMsWiMvhiMIoGMvRiLJVGMzQiMx8iM02iNJuGM1DiN
zyiNKLGM28iNz9gTw1iN3tiNxkgSy1iN6EiNypiM52iO27iO4wgdWqiLw0GP45iO9SiO/piN0BiN
0KiPvxiQ7KiOBkmMB1mP+oiQABmQ77gSBAmRA2mQONGQ/eiP/NiP67iRCpmRJ9GRFemQzoGPIpGL
hIeS9hCDKJmSuXiSKrmSSHGPH8gSxKiQ/P+4kQsJkN8Yjh5pkSCpkx/Jjhj5j9c4kjsZkkhJlMjo
k9ZYjgIZlTupkwxZkTgJlEeZlDzJjQUplY9xESZJkzBpEy2Ygyz5gWY5hGkJkyNhkgtxkyOZk1ip
lXSJjnQpl14plenYlUbZl0+ZkHOpkRb5kfMIj0w5l3sJmCSplOL4lyApj3W5kAX5k/Q3hTUpljLJ
lpmJmSSxlpr5kgqoEPvojlb5l9jYl/IYjhn5k+Uol9g4lFwJlQ/JjF0ZkSmBkYRJkRxpmD2Zl7Zp
k/DIl844lfF4lDfZm7d4FJfpkp85k2TJnDL5kpgJmjlhmkt5m4rZm0pZlI9JlY15naP5mFr/CZeL
yZhGmZuHSZuBmZjl6Z0ISZ7iaZeoWZ5ZuZXKEZbQqZbOmZlsKZbTKYY0YZ3z2Z7riZhOaZ70uZWw
GZ7xiZfyOaC7qZdLyZcJmpS/GZ+zWZ9CeaAqgZcO6hjN4Z/5uZ+byZz6+ZxtCZ0pehKuKKDdmZ0D
SpkRGpv2+Y9DSY/c+aGq6Z2/iaO6KZIdqpv0OZGQKZ8yuqDfqaCDGYvJiXk9GJP8qZ/R+aQqyZm6
aJIt0aPeWJxUqY0wCpVeap3w2Y7EOZukaY4VSqCqSabfWZgSeZp+eZoXCo7q6ZDDiaREChmsqJw6
gaUm4YqC555WVItNyoI1CRN+GhNNuaiM/9qojvqokBqpkjqplFqplnqpmJqpmrqpcLoeidoSn0qE
gspEozoYeyoZgDpKAnEEo9gZL6CBw5GqRdGqGKEKoZEPqjFqw6CKIBiqKwpFgMCr1tGSmPcSvkoT
lVAJI5Gsy6qsyfqszMqszWoP0PqswlpEYJl5x2oS27qtLKoQ0kqtyioS0TquJSGt6GqutkgX9ECr
UIifzVmWJ0qlVPqr+weu4wqt5Oqs6koS+rqvf+quAhsV8BqlaYmiZ8mfBmuvAIiv+5qu4ooS/xqx
JTGwFosQOEGsYzmi/WmiHDsU5VquDzuxFDuy1nqtQ9RD8/qrUiqiLHuoDZsQ4pquEHsSE/8bruua
Eamwszt7sWnYEyvbnB27ov9JFP96tP3arOGKszPBs06bCijLHdnamSq6sCVKtB+rsDGLsUhbs+ea
r2AbsAzBs2fhDD7LGmwYFVMah2xLogdLr1YKsygBqDi7tNXKr/7Kr9VamWe7h7kIEULhrVE7hoJL
FIU7uCn0BFJ0uIh7iqcaGbI6FH3bt41buZZ7uTHhDvqXD/mAuQmosSfBuH7BuSXBuaaLEqZLuvaQ
uqfruVbEmcXBup2ruqvbuaVru7Wbu67bhBQhogm7thurrXLLHgqRuiRBu7Q7Esg7u7ibs6vRAZPb
GsXascKrtQoLu0thvMqLu8krEstbu9r/u7sslK2geaUoSrUMK7mi2brey73N277baxKkG70+O73o
i77mC6WDob3fK7+s678xcQLiuxTWYKq9i5au55npmxSASroO7L4r0b25S78U7BD4aL7WG7dBJZq5
+8Dxq7vHa7vfW8EkrBAXnMDOeZZeKLorsRCyu73su7zJ+798W8I2LBCxysESPEM3PIootMPhQQYD
rL4iJByRu8GcQQY9/A/c0MTcB2lnocQk3MRUHBu8SgZCDIJU3MTY8bhLJBZSPLlOrIRLwcKPYcaP
kcVDrKoVAbopIboticYo0a0oDKBrO69IscQ/y6eIOryg6se4CMh3fL0IzK1Vu8bRMbUs/6GxMSml
c1zHeBy8KRzJ1ruxb1zIJSGWb1ENeoyAykmdmXzIV1vJC4y1KqrAjqyZoeynJ1y+oozIKfS251vJ
QfvIl6y1Liu0f3yooYrKggzLOVzEpfyfrpyo+Suv91uijfzLoGzHhkzINdzJ3AcJEgECWJjMyezL
lnzL9qrA0Fywf2y14azJFxEH0nyA9luwyBydpYzNJ4rLKQzN8HzL3vyyWNvOwMwcgaO/q6zC9aoS
x1zPjNzMqUy1xezKKQq3eXzOoRi4v2y/ffrQT0Grn9DDQSHHiyzRAK3R9/qAMcDQD9GBHO0S/JzP
Jo1pbJDSJ73SJZHSLg3MXswURwwcrf/h0mwA0jTE0iih0rtLvs6czSM9t6JJAERd1CNB1ElR1Eg9
0TiNguk8vBgtE0stEks91URR1QSg0z4Ut/6MsFAKuoVr1Uet1GRN1Upt1meN1kZdElht1mNtD22t
1cahyKScygc7tKrslgoh1m8N11P911m91kgN2CYR14Td1k09iG58v7k8yqRcsUNd1m7t1yRx2Fnt
1oTN1pKd2Wmd2E7NpwFNoo6tzT5h2Jc92ZRt2X1d2ac92K192Wkt18WhyBr8zR6Lz857EIUN27zN
2m+t2qi92q7d153t2Rv41PGa17Psmf8ME1Zt2r6N2a9N2X592sId2Lw93bL9HW0ryQn/PdqTjL0u
QdbWLdljLdjaTd67HdvqHdyYoQPbnRlRndTWTRN8Hd8wGNR8cd/OXd/4vUQl7RjmfRP8/d8GfuAI
nuA6YdwMXhtnqODi2+ASPuEUXuEWfuEYnuF+COEc3uGXqOEgPhoePuIkvomPWOIozquNkeIs3uJA
hAgmXQUo1AQuHoT6XeNyeOM4Trg6vuNf2OM+DkVpcYYhXuQh0YFBnuRKvuT2sOJM/uRQHuWKIQnQ
AQ4uPt9jaORmqOVcThdp2+VgvhZfHuYhnYpVQYJGruRALuVsPh4x/eFkrhY6N2zvxm3FVudr52zY
RnsZt2/Vx36zR3Kwd3Z07mtxN+fM/6d84IbnE1foi47n3xrnaIHoi356hr5s0VfokXfnu+bolf5s
nH7pmD7qj/58jk5yQXfplJ7qnx7qpI7pDie2km4WqF7rnY7qUafpoO7pdI7rrv7ouV7qun5tpA5v
um7rmY7sp17sr87psw4SN6HsjU7svk7sqr7ron7n1Z7twN7pwn7t1G7osQ7r4o5xzL7prU7u3v7f
zWHsxs7ono5t9Kbnhufn1SfqgN5wpvfnsodvqo7u7z7twe7u1dbqgg5wUGiCBwgBlijw0053zD7w
vN7slt7tvX5vrv7wEx/xAv/t5H7wod7olq7svx7Nz54RC3fuFl/uK7/sKz/u9n7rGP8f7xHf7F4X
8MP+8b9u6yPP8ti+5A4/6hUv9JkO7ryO7j6f7twO8+ru8Utf8++e6qv+6v8W7gYf8gdOHTC/59p+
eF3/dmD/dpye7zcPcffe6/V+8eJe9R9X9vEef3qe8bG3ff/wCieff2YegUgwiPDX937/94Af+II/
+IRf+IZ/+IJ/9x3R5pr45ow/GaH2+KuYapJPHBTYHWuuijd++UChrZ1prIYMyjHBy6Mf4CcJtBGt
3wl8+hmLwqwfuk6a+awv0QstgSs5x7gP0J/flqCfyTwB5IIs+32Ki77feq4fuLuP+rePqHQfgaqM
zficksu//NTpz8nP+7Nv/dkv/VP/evpXyq3s3P3lu5nhf77xvM3hX/zP6ZKsrP63X8sASpa8P5Pv
f4/1z/7fH7osmf77j/3rDxAA7AEgKHDgQIL2EBL819DhQ4gRJU6kWNHiRYwOFW7k2NFjx4QeQ4I0
CHKjwJIoOapUaLDkyY8sXx6EeTBlS5o4R64UeZPmS5Qpb+5kaZOnT54IYc78mBOnTaRGny6lCrVm
0KpTtdbUOTTrz61drzYlW9bsWbRp1a5Vu/MkU6Umpbo8KrJnQbp0kz4t+rXvSrx99QJ1SnjmX8Nl
9epEGzik4LpN8/ItzNivXMxSLXMF6/SyZ7ahRY8mTdptS7inN8sMjDpq2KmHW/8c/wkZLmjCtPFW
/qrbdUHXMbX+lSxX8GzgxjtD1tz8sPDPyXMvbj299HXs2RVmlIg6ZurbqzsXxy18MeznzkGHtV6e
M2KT4d0nPpueOXmuPpnb3os+8tb9KItuO+4KNPBABCcq7TYG68tJpv/O809C6/SrrMHMBvvvwvgu
e2285thTLjfx9rKwwgiZom8zzYp6TECl2tOOLVFmtPHG0dL77S2getxNP+mS840v6SSrzsSgXuRR
yatqE1JIHnnbzb2xZHNSRegCnC4h8K48z6Urx+OSS97iwvFMNNNUc002cZSvTTjjtEtOOuu08048
89TuTT37xI5PPwPtM8F/BDUUT/9AD1X0rkQNJfRRSCN9aFFKK7X0UkwzhSJTTjv19FNQQ/1UUlJL
NfVUVFNVdVVWW3X1VVhjlXVWWmu19VZcc9XVVlF79fVXYINtc9dVLyH2WGSTVXZZZpt19lloo5V2
WmqrtXbVd66FSB5tu/XW2Rq+FfdAW8Y191x00yU2BXXbdXdVYeOVd15667XnXXzz1Xdffvv191+A
q7V3YIILNvhghBNWeOF4A3b4YYsagXhiiiu2+GKMM9Z4Y4479vhjkEMWeWSSl2X4ZJRTVnllltfU
o2WYY5Z55pnDYblknHP+Vg+de/b5Z1dpFnpooos2+mik5VVXEqCbbroPp6OWeur/fpOg+mqss9Z6
61uT9vprsNMitGCuy941glnDVntttccm2Gy4+2V7brrrLosfjvjRG++8996I77/t2XvwjgAXPG/B
B8fb8MMVZ9xuyCNXy3DAK0f88MsVelzzzBv/yHLMJRd9bbcXD5zz0ANnnPKmLHe99dA3xzxu2jnm
HHTMHze9c9lfvx123AsnsHbiLY5dc8JT/513svje3XnFeY++o+Krp/j41HdHfPXOhfe9d+zJsn78
b0ubnnXdlWcdeNVR90h72UeXX37u118/fPffP975z08Hf34A2q1+yUOe3gpnQOE1L4GJI9wACRi/
AEZQghOkYAXX5DgMZlCDG+Rg/wc9iEELhpBsCRoh+UwoMBGmUIV1ctsKXVhBWQmqUQGcYctqmKkb
mgVBpsmPg0gCpbRgqTFTyoxocrgeH5rliEkMImd69SHonElHa3rTEtVCKKTwSYg54qFivFZDKy4K
jPQKo0dklcXgBAdKOgJTG4nEmsk4cUpBmswc5/KYMDXJSiR50EIG86I99tGOC7EMHYdExCgRkpB4
zOMgPfOkMakESHF8ZCOB4xVJ+nFJZClSV5RUJElC0i0xzCR1yrTJQppIPUOxkinRyCSsqIdFvZlT
VlzUIjPFJpWMYaVdvFKi4VSFks/5JRLvc0tMOvEzuIwlMpWpy7lQpZfMdOIOef+YST/GkkqqXFIo
bblNQXazj+LxkjaX0iViftOZP6xND9e5o2Le8j3CLNGPqsSoMsXxSCHSJImcGc9xMgqNvFTnNxFl
FAl5Z4vcBNBbqFlEgDJUnjH6DpIYSk5p0jI17gynLgEaFX8up6O4DFExxwmhpMCHRR8d6USLCE2E
FhSYpHHbQDn0UpR6tC4mbSgwJ+pSoPYnpBEKJ09PKqaHtlSp89zlO39ay2P2cKY65ShBMQojaOYU
m0mVp0FiGFBFQhIwl9RjGpP0RvbYk0hmRSUrheLGo5wGkbpZZyd/6NFO2lWTFA2rHBkpoCS99an4
DCtQYfmdv+7VnhF1ZCLd+kf/V+pRL9acWxn3JCfLwumGmW3MgrKTUCXeCLQU5KxnMdupzcbJiqtl
Ulv21NoXxla2s6VtbWmGIbaUNjS6tRNvbRtB3K4FUL5FYhRFex3i+gmKvw1VcF170CaKcWDJZe5H
xkZHwbKTrWg9JChFGci+bnWPhtyRIqMESFEWsrVwdOxh2Wve8r6XiKBcZBrhe6+sAeCryF0qVbn6
X6de1CokDaYvDQpYAGOpR/5V6nqZOmCWiqXBfWIDGxRGXRuplcCCtGMbycTSiP7Gw0eVzXvI6kmi
UAaZGu4nki75ygNnU5UwRvFTq4PhtFTYwgXDMfUSFOF8lodCEw7xIw1KHL5O/zhLVi1pVWEKGCWf
csZOVulIocyRW+nYXfqVFpBDatNkYrTIXn6mT/sr0gDTGKYrCrBU/UtmNbdHVxVOF5fTZpoT01W7
8PURdzss2bvC082JjMscyTuWmPp5rPcp7Fs32ef7Nha7joUyXJ9kKB0Lq8f2GqNp/4SyRm1aUJl+
4p1aGKhEAdGIyFUNwkLNJmaxQVt2nlZ17QY0WkvL1nX7Wa51/dKZVVHURTvhrPYZRFWzadjLhc1u
+6TF0HJSKJ294r6kgbEnR/tgzC4uGRc07RsVm7JqKYc9mBCb9Panvc1MtyO3NN6MyteQhoVrfdEa
WFSuu5XqBZN9X1xvqLillP/bvSPAd92mOKu7o8Ps0EyR/OV+RzmoDDZpm988Y1MmFawxHviJVlrm
gzelpu5E5BZR2tU8U1LCQj3wsbtqZIqfU6ZBBmnLa5xPBTM1L/Nd5kzETZFTnGrNxoQqmmeu8geR
qL9sJDFmKp4f8YJ1zDZvsl+JiuiH99zHP5fIKYIOEf5eXN2/ZHiIF6p0sx9dmWqW+n+pPOWsWvns
bb86hIY6bMidYusHGvp94/tJFD960J68i6CHc9gkn92SkawnEO3qoy+107xBijTdy7rwxNKE6wVC
rbMVhXeFUzu6KANFyFHt+UOBPtmiZ6Lp6bV52Md+Uq7/FQdo7yvZ537zt+f/fe99/3vgU0oQwSd+
8Y1/fOQnX/nLZ/51dP/8gKmibMaCfvVrHSpvNF/7cLJ+91/la+9fqwvhhxb4yX9+9KdfVdRX/8+3
/374x1/+86c/2Np/f/znX/8oVBg76v9/AAxAARxAAixAAzxABExABfy//WtAB3xACNyvBZxATDGX
HYhADCQVCtzASzk1DqRAePlAEXQUEhpBEEwWEzxBZNmIDdiAjmhBGHTBj4jBFlSIGmRBGbQHGsTB
GOTBHaTBGgRCjhBCjwBCF+zBG8TBsjDCI8xBHWzCH4TBJ+zBpiDCJHxCH8xBIpzCHXzBLrRBKgRD
KkRCI+TCLORBJfRCKQTD/yF0Qi7UQicMwjiMQjg8wyIMwzRswzVMwhpUljzEwj9kQyW8whvkQxk0
RC9swztMQ0J0Q0BMxEcURLNoREW8Qkasw0UcxDmUxELExEBUREFExEjsREjMQ1Fcw0gMRUy0REAk
xUtURTF8RUmUxUBERFf0QzOcxSp0xFFswkQUxT9kxVPkxVIERUtkxRncRE1MRk7kRWSkxGP0RV1E
xmZMRTncxWJsRTeUQ1c0xlV0RFekRG1URVKkRm/UQ0+sxBwMQdIIQ3P8xF60RmmUR1Csx24ki2c8
xG0kxmKERmfUR3jMR3X8xXRMRXucRzakxmiExIUcQ3AESB9kxnE0RVTsxP9y5EdazEWD1EhK6cYt
VMM9LMOG/MJgFMKP/MgsDMd9RItGNEkr1Ec8BEmLjEKCjMmNFMOQZMgvXMhzHMhrlMmVTEaHrMd4
xMJrfEecHEZdjMVLuUeixEZ/JMiNFMeBxMeHlEienERlTMh/5Eq1+Emv9MmuxMZsFEh67Mll5Mhq
hMdHBMuihEUznMlMnEinxMlhISGUZMuqDMu0FMatzMhsnEqI1EuijMpMrEuo3MSRXEpz9MvAnMha
HMywtElgvElb/EtxlEuqpMiklMy0xK9UaUfF/MtZdEuPHMysNEil/ESzTE2rLEyEpEWz5EvIPM3H
XMq2lEynzMrVnMK53Mz/g4TLkmxG1LxK2rRNxLQRQslMkkTHezTEisTMOaTJS7RJ1ZRCl7TO0hxN
OkTIfBxKioxO2HxNoWzJkNxMd0xPNATK2zxJVAzPeYxOyuxCqqTPOmTHFMxPFipB/URA/OxPAA3Q
ESyBEhBQA02TAj1QBbURAl1QB82OBD0ZJoxHkSRNYOTG2HzH99zQrcTQ91xLo3RJdWxOO0zKXRRR
TYzJnexQ8GTMCh3R+VRRGZXPFpWTBk0Z9IxN4eRMuHRNNdTD8YRMssxNwdzRIbVN8txOIl1L5vzM
m3zLENVKHl1SISXMNYlQhsnRIr1Ou6TLoDxRmITDy7RSuYzS8iTTsdRL/y3tzePUUSjtx9GUUiN1
SzO9zQhaU2K0zjJVSTvNxfSETtI8zJxUSPFcwjTFTSX9zN30TjcFziClTYmsUjqlU0S9E3zoFB0o
DfMkQ5JsTCiMT8/U0E/1UqZMya4kw86UThKdzUrdVOxcUal0UlPlR1f1UL9Uz73kSvtMITxN0jss
U0nFSAwlVY5ESj/NyTOtVHLMUFqVzjqlR8NEVTV1VqQ0zZVczLn8mhbq1SH91TAFTFHt0V2tTDDt
UkIl12yd1GYdTyR1Umt900d9VqwsSHV90uERGezg1kj11i4NVkOFxWj1zGStUVk01t4M1+G8UE9s
13ftVsNMUoXlUVb1mv9tpVb3/Ff4fMNPdcxY5UtbzVMWpU5d1c4tJFE4zVVA3cdolNZWtdhVDdmV
RVdALJkHrVma4k+bpRmzydmhoVme/dmz8ECg1ZMMbIihFZSiLZSj9VU18T7RRNFETdV1Dcg/TdH5
5EyWVVYOddaR/dC4LEP2TNWnfMOoLUs9fclC/T8tpdqzcNRhrMNqXViI9FEgXc9ETc6n9FTAzFu4
DVSNpVLW/Mbfq9hHvVpDJdeRvEg5Bc9FPdxv7VewNNgv/U2BhdxDvdWpHdvVdFq08ABfrU+vjVvE
vdZBxUht5NOzLFeN/FO/NVuIrdzVvdyH1NuwZdPbI9xZnVNhndvJjdL/o8zLEI3cUN3drxVXlT1b
Oy3ZlzRSqRXKbk1MWUza4SzY3tXJaSRdu5RcYG3c15RWlXTUbH3ShrXeLUVUPPRaZtxc2fOGiMhX
rkVJUSVYbM1a1cVVuqXezvRY001dQaVagi3bqjRWRd1f+NNXeE1Y46xNSuXX2L1ejFXcvoRdvn1d
F0XL8ZXK1uzbvZU/AwZfJVXetH1Vk31LThXh0L3Kh/1YBm5ZGH3Vg0RWF3XIXTVRGrbXGTm3pT04
Ac5hBd1hHv5hIA5i+BPaH07acRNiJE5iAF1OE47RMEXYSK3MtUXgvmXdJk7HKf7g7ETf/NXYlJVJ
JpVBI44V/u3faaVg/wCuS3/UYOZl0yym0ARmVeCM2MnExDE2EE2tXrTUSkI1VzFVRo4d2Tbl0h0F
1MjMVQC21zluVEYd2vtlXtUV1NOM2X0d1melVDo2z0OWVXiFYmj9x0f2T7zUY/jsY8scVds1Za/8
3Ra2VQvm3ZN9Uf/90EUWTOO841cp4/Ycy3N9XH+tZGnMWkzW0fOFZXZNYBuGUmwFSUjUGAQAGl0e
W9wE3mNNWVIO2HflWEpOSQfmZA+O12VG5I3A5aAJ5edE5u983DfuSehc0kBOzYfF31KUYwuV2whO
Q3LOiKdt3WpGXw8G3Xhd4XYGYWHm2q79Y1P9WzD10eac4SpVYoimP/8i5uF8ZhUlrmiMzmiN3mjO
jWiP5j0s/WiRHmmSRpNWK+kUdAyDWQCY4Wh8cQyXjulrKQiZxmg0qGmczmnbQWme7untUxXp02mh
nmifXhhnsL+hTmpiKer+VGqnfmqoBhim1s+ormoynpEzmOr3s2qu7mqvthatDmuxdr2vLmuzPmu0
TuukLQe1jpqxFsG2jmuMeGu6ruvZImq7hhxdyesJbKEP+ACO+GvBBmyFGOy/borDLmzCtofDNuzG
XmzGBmzHhmzFduyNMGzEhuzExmzFDmzJ5myPsOyOSOzKFuzQ1mzQ/gjQNu3OHm3SjuzFXm3SfuzB
Pm3Pvm3Pjm3dZu3/yL7tyYbt3Ibt2bZs0SaL1+bsyf5s3E7svb6O49bt1u5t247ux1Ztwt5syjZu
yh7uzG5t7pbuzv5u177s7UZt8h7v845u9JZu3n7tyg5u8MZu6BZv9Wbv7G7v64Zu8O5t9wZu8lZu
+57u/c5t/d7v517u7A6V2lbv6k5vBMfuAf/vAjeLA8dt9G7w8z5w+nbw56bv4Rbv/h5w2s7v05Zv
AM9w1sbw+ObtAHdtCHdvFVfx0p5xCI/wDV9vHK9w705wO3GbBTfwE7fx/H5xHv/xELduC69vCa/v
GD/xEPdw/LZwI59wBw/vFL/vK5fxEbdyKWdx4bZuIr9wEhdyE2/x//6+8SRPch1v8W4xc/NecxRv
8N+u8jlH8iqPcA4vbyAX7iMvbjdH8B3/cRznb+U+88+ubhgvdEUHdBEv8kVP9B0vbdPe8hE38UlP
bTtfcjWfc+bOldKocQ037xIf8jEf9TvX7jQ/8hUf71DHcy5n9AoH9SAfdDn3ckJHdD0v81gvdSUP
9Fn/cCq/9UV/dd/m8TSnc1GPdD8ZG9Fu9VP/cmjv8yhHCzhX9Q1v8haf7g6/8gfndleH9DIXc2J/
9dredUH/dlJvdE0X8kjnbkPv9WNn8GSP8G5x9myX9nB/8jFXdVoP9k3Pc2XH8++29xondmlP7w/X
9n3X74Qf+Hk/+P/3XvV/F3dCR3EB53cQf3hR73RcIY1Qn/Jzz/HdLvc39/NB53MKL28vn/Jjt3dh
h/I9B/OMx/KLZ/n3Lu41h3j/RnmRx+x3b3binncJt3SRZ/RBwVm+Fp3mTnqmb3qnf/pDkWupn3qq
12eoL4us3uqq33qu52gC+M+rZ8Cun/qwL3s0EQCzF5axJ3t7gIHrsIZPmYS0n/tLIYQbqQe6z3u9
33u+r78T2oe1b5fmS4K+H+fAj+vli4HCX3z5e0AHOPyO1z4HYPzmm/xgKQAThMDHh/xaeT/Lp3zl
+3zQH33SL33Tz1nOT/2QeQDVx5nTnyDOe/3iw2tOQhTQQ73cQjj/PWGNNFG62te0bsOP3C+L77s0
L6olVtuoy2o24do4+XgN3UKy0UP+0JL+GfF94V+i8Ij+4oA26D/+4I/9VWN+YMsw4Q878yf/olO2
LuIv619+9Y//6S//9m+4JJohbmMLLIqMeWOrFwMIewIBEBxoD4BBgQoRHiTI0OHAggcnQpTY8GFB
jBoZLkyI8GNGiBRFLgwpUaPCiCgtivyY8qJKlShhjmRp8WXLkxQ9xtx5keNEmjQf1uToECjMnDOV
Niy5sSdJnDxBUiV6FKdJoxL/ce3q9SvYsGL/AXVZNiVSs1M7snwZ1GjQuCB5xjUI927HvFblsuWb
l69Lt3jfSg2c//CwYcNofTJ2i5gtUcKLdR5mnNjnZbh/6/Z9HDlzZ86C12reWdqvZXtjwzpuPbpv
W70VJVdV7Dhyart6Pc7W7buuWrWeUaM2i/Rn4M+zz/4F7VT4SNfFAWPuTdx59N+XS26+qrW3Ve+h
b44OPn37Y7tXpbNvv3i8YtCfOR+XSn04Xez6J5s+f725XMztllp87xEIIHrkAahdf4P956Bw+2Hl
X2W00RdaRK2Zl2Bu6TXmXkqriajZWSXCttZvouHGIYkMQkicXyz+h19lg+2lm4D3dQhdjgY6GON4
3emY3IEVMngkZi5iaOSCMp5W2mUiSjklWSRR5dRby+VHWYXWxf/H5Xw/ZbjUZkA2hddpZ8KmYEtb
ZkTfSWBmKGZmCnbHZXHWiSnbd4htt15PTe0ZZ5hk8ibUbQO+iWOZi2bJEJWRigUipZVaeimmmWq6
KaedevopqJzWFyqppV4qqampqroqq626+iqs7kUVK6212norrrnquiuvvfr6K7DBCjssscUaeyyy
EyZ726ijLmupnbE6i2y00z7rnqRffWote/UB6lqa7SkVrYaviQburNDCqCm3zaJlU5+ZppWuudxi
JeC3idp3rob0Uoqea9mudu2+ZXYrb6OVHhduuaDaq+7BgkE5JMIGS/dwvXOua+CC4oaKcagCd1VR
vEO1CWi+TBn/bKVJj8oEro9sEvpuVVhyHKiXDS7K8rx9zqqyjwnfPO5zNwtFcnKEOjtxlzNjiTJ5
C8NLnXFJ9yky1mPNl6Z8QSLI7IrABclwWubq2DHAQ2F4141Fwtzj2UH7+e7bXtv844tkxxz1khTC
GTa+gu4HVNaFf7X1euIximTchSlOY9oXFv31vmz7W5vYSqpHMtgFVs5vWT8XTKfdjuuZ98qf19j3
xEe563rmbmNukeG1k4Ui5f0x/mN5BaPeZcarp+ihbYmWnTt2dOeuYt9MHi+k5qBLDjmMC3fceOse
P08x7xnazhW7uA9O8fK9p/h77NDHXnz2TLrNfemBw929kYCr/y+h+Y2hD/d05fv9+trGFr+QYa1Q
8Ooab6KGp5fhLE4uu07i7tUz5/1JgVODSs7UZDKpOc2CFNQKzWxGswreBGrx2pmcnrOUdLVJYjGy
YMmIRiKr9eR7/zAWyAimwx3ysIe3yhqr/OXDIRKxiEZUjQ2xdsQlMrGJTsxUEm/4xClSsYpW/KES
FUYscqUqhzAzmvug5a4r4op/t/JiR6L4KjR2ql0Na+D2JFi8flWrMGarmNws9rEj2suMtvKWrHbI
RlF5zIXU09gbH6Y3MPJLi6qD1SCF1UdG/lFfESOgyNSWwD1t8DszCWFMfua0PB5vjnsrGfUiuBKe
DQ9oSWlhVP9oyMmTIcqAqNxgKJ+CwQuqjGehS+HdRLe5G8GygwdEog3Dh6LA8Sd6AEzd8NDGHcl8
kXypPJH8IPM56w3HW/ZzEW4UZUez2ciZjUMSwF5kvPsB5pt2i1ynsgY7D73QUXUSpaOYF80aiW6e
iYRMLFt4oLl45nH+yx6bVAi/+unOO9zET9tmp82ieTKdu+GgRZ2puMfBDi5qxGMeF/q+oM2veefa
nrXad0fUgZB3D2Uf8piJvHVtqDk5KudIoYQ/erboeRmV3Tg7RM9PyfOiwgOqOmmkzw9B80kWU2mP
WNrMkWJveTIdn/MGlL5sEmZ/U5XRUcOVVJGi6Z18iSIQBbr/Ej6R8JOTy8m9PjjNQA2VeHRVEdL2
olaogI2CVONbMHmpPLQhTWKGCo9gN/fWT36rsZ2rXs5+mUCMwBEhHy1WJMlIxMxKK1ic1WythAha
K352jZ4drWOAiNrVspZYaH0tbKXU2tnStrZMVG0Y70gwLhayVWMMqhgv5cXSyuq3uYotcpNbO65V
E2IXI+QlQcYwUxnXpJdU10On+k9lhrSR20qtcsP7Wu5ijI1u3NR5havHUlV3n7117ugomVtHdte3
tg1iVhbXWFaaxp4htCUDMxjKesbVhOnppS8lyFcyubWXf6OhlmrWTlnmC5dPK6aJOnm3mty3i18D
ZvUEd70W/yF1xAIM64mZas6Z2oaggCzoNtcXUbLOiKkIZdY11TPfDqP3wyae7INiXDX/ZrhJjyoh
iyf6srFKlXSItOtLs/M/Gjs1mgh9KUetyePWFLWbPwbqksra4gD61De/9eqYUszVBoX5qktNDFhL
vDvWxbS7aH6JePOcRPKeiKdqji8z0cdQu6J4xeas8kCrKs0oF9mrd1b02dz8aOJumcjACegxQ/fU
sPH1UIOGoNQIvORMs1XBanvKLSV70uXYZMKeTLMm/+ZXNAF2lydUHqV95QBQ4bbHmMq1JbcsbPVu
Ss/Grl2uzGvfYTObvs0+IhWeLe1p3/bY1r42trOt7W1zu//b2KY2uMMt7nGTu9zmbo+3063udbO7
3e5+N7zjLe9507ve9u72ufOt733zu9/+/jfAAy7wgRO84AY/OMITrvCFM7zhDrfHEx4u8YlTvOIW
v7inioHxjXO84x7/OMhDLvKRk7zkv6LGFO+t8pWzvOUu57bJY97wl9O85ja/Oc6nJPOPg2PnPv95
uHMu9KETvehGPzrSk670pbMG6E4HONOjLnQmSL3qVr861rOu9a1zvete/zrYwy72sWvr6WbnN9nT
rva1s73tbn+7cs8u91BpYrRwvzve2z73vfO9737vVd4DL/jBE77wNgyB4b/998UPO/GOf/xYKgH5
yVO+8lSTYjzmM6/5zVPK8p7/POhDL3q3c770qB296HmBesWbPlkraH2xVy/72ccd9ra/Pe5zr/vd
8773vv+932kv/OHvGfi8koPxk6/8+0Z7+U6kB6y64fzpU7/DX6g+9rMvceJzv/uZZC2wtS/+EY6/
/B/jrfnTDyLRtv4S6ock+98v/37Nv/72x7z386//gd1f4ByQdkAAADs=

------=_NextPart_000_0007_01C70518.8677F170--



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 kAAEcE2Q075965; Fri, 10 Nov 2006 07:38:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAAEcEgM075964; Fri, 10 Nov 2006 07:38:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kAAEcCD4075956 for <[e-mail]>; Fri, 10 Nov 2006 07:38:13 -0700 (MST) (envelope-from [e-mail])
Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kAAEbb506298; Fri, 10 Nov 2006 15:37:37 +0100 (MET)
Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Fri, 10 Nov 2006 15:37:54 +0100 (MET)
Message-ID: <[e-mail]>
Date: Fri, 10 Nov 2006 15:35:39 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5 (X11/20051025)
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: =?GB2312?B?1dQgw/Q=?= <[e-mail]>, pkix <[e-mail]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010606030705020904000506"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms010606030705020904000506
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

X509 does not define a type OtherName.
it uses : otherName [0] INSTANCE OF OTHER-NAME,

This gives indeed the same encoding as in the PKIX texts.
In order to be closer to X509, one could have used

otherName [0] SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

If someone uses OtherName in another contexts (without tags) this
cannot be in conflict with X.509, since OtherName does not exist.



David A. Cooper wrote:
> I do not understand ASN.1 well enough to answer the question below,
> but someone else on the PKIX mail list may be able to respond.
>
> I can say, however, that the ASN.1 for OtherName in 3280bis is the
> same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC
> 3280 (April 2002), so if it in an error it is a very old error.
>
> Dave
>
>
> -------- Original Message --------
> Subject: 	The difinition of OtherName in 3280bis differs with X.509?
> Date: 	Wed, 08 Nov 2006 14:23:38 +0800
> From: 	ÕÔ Ãô <[e-mail]> <mailto:[e-mail]>
> To: 	[e-mail] <mailto:[e-mail]>
>
>
>
> Hello David:
>    In rfc3280bis,Setion 4.2.1.6:
> OtherName ::= SEQUENCE {
>        type-id    OBJECT IDENTIFIER,
>        value      [0] EXPLICIT ANY DEFINED BY type-id }
>     Setion A.2
> -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
> -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
>
> AnotherName ::= SEQUENCE {
>     type-id    OBJECT IDENTIFIER,
>     value      [0] EXPLICIT ANY DEFINED BY type-id }
>
> But in X.509(2005),Setion 4.2.1.6:
> GeneralName ::= CHOICE {
>  otherName [0] INSTANCE OF OTHER-NAME, 
>  rfc822Name [1] IA5String,
>  dNSName [2] IA5String,
>  x400Address [3] ORAddress,
>  directoryName [4] Name,
>  ediPartyName [5] EDIPartyName,
>  uniformResourceIdentifier [6] IA5String,
>  iPAddress [7] OCTET STRING,
>  registeredID [8] OBJECT IDENTIFIER }
> OTHER-NAME ::= TYPE-IDENTIFIER
> In X.681(2002),Annex A:
> A.2 The TYPE-IDENTIFIER information object class is defined as:
> TYPE-IDENTIFIER ::= CLASS
> {
>  &id OBJECT IDENTIFIER UNIQUE,
>  &Type
> }
> WITH SYNTAX {&Type IDENTIFIED BY &id}
> X.681(2002),Annex C The instance-of type:
> C.7 The associated sequence type shall be:
> SEQUENCE
> {
>  type-id <DefinedObjectClass>.&id,
>  value [0] <DefinedObjectClass>.&Type
> }
> where "<DefinedObjectClass>" is replaced by the particular 
> "DefinedObjectClass" used in the "InstanceOfType" notation.
>
> So,INSTANCE OF OTHER-NAME associated sequence type shall be:
> OtherName ::= SEQUENCE {
>        type-id    OBJECT IDENTIFIER,
>        value      [0] EXPLICIT ANY DEFINED BY type-id }
> But,this is associated sequence type,not the encoding rules.The definition 
> of BER/DER is in X690.
> In X690(2002),Setion 8.16 Encoding of an instance-of value
> 8.16.1 The encoding of the instance-of type shall be the BER encoding of 
> the following
> sequence type with the value as specified in 8.16.2:
> [UNIVERSAL 8] IMPLICIT SEQUENCE
> {
>   type-id <DefinedObjectClass>.&id,
>   value [0] EXPLICIT <DefinedObjectClass>.&Type
> }
> where "<DefinedObjectClass>" is replaced by the particular 
> "DefinedObjectClass" used in the
> "InstanceOfType" notation.
>   So,I think the definition of OtherName in the '88 ASN.1 syntax should 
> be:
> OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
>    type-id    OBJECT IDENTIFIER,
>     value      [0] EXPLICIT ANY DEFINED BY type-id }
>   
>   Because the tag of otherName is IMPLICIT,the encode value of GeneralName 
> in rfc3280bis is identical of X.509.
>
>                           
>                    zhaomin
>
>   


-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorit¨¦; 
die Liste mit zur¨¹ckgerufenen Zertifikaten finden Sie da auch. 


--------------ms010606030705020904000506
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
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTEwMTQzNTM5WjAjBgkqhkiG9w0B
CQQxFgQUynvYWrIBIsdp1+H4hfCJlFHyjhEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAZWV1npdzIEn00dmK
ujo++Seu532QWGjJK5XtDrJfST5hHIa4PEy0F7W4IsLLhVnI983m0PTvrA63ntGLzvKUOL1C
xu0h2EdNnfF/er8fvnEzmWp2MzJSt+pbHYXmfyNtuts8q+fMT1hvvpJDEj8yskIBM06I5dlz
WAwau5DCUL8AAAAAAAA=
--------------ms010606030705020904000506--



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 kAA3LwQr009313; Thu, 9 Nov 2006 20:21:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA3LwCH009312; Thu, 9 Nov 2006 20:21:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (dhcp68-116.ietf67.org [130.129.68.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA3Lvxd009305 for <[e-mail]>; Thu, 9 Nov 2006 20:21:57 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4AFFAE0035; Thu,  9 Nov 2006 22:21:47 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: "Dave Engberg" <[e-mail]>
Cc: "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]>
Date: Thu, 09 Nov 2006 22:21:47 -0500
In-Reply-To: <[e-mail]> (Dave Engberg's message of "Thu, 9 Nov 2006 22:04:24 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Dave" == Dave Engberg <[e-mail]> writes:

    Dave> I agree with Mike, and disagree with Sam's original
    Dave> assertion.

    Dave> A keyless responder with pre-signed responses can be fully
    Dave> compliant with the mandatory requirements of RFC 2560.  This
    Dave> is reflected in both the "letter of the law" and in every
    Dave> OCSP relying party app/plug-in I've tested (which can all
    Dave> work with keyless caching responders).

Then please clarify 2560.  Reasonable people including me and other
participants in this WG are confused by 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 kAA35UhG005846; Thu, 9 Nov 2006 20:05:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAA35UcC005845; Thu, 9 Nov 2006 20:05:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAA35THo005808 for <[e-mail]>; Thu, 9 Nov 2006 20:05:29 -0700 (MST) (envelope-from [e-mail])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 9 Nov 2006 22:04:24 -0500
Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_00E6_01C7044B.03F90C20"
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Thread-Index: AccETgvkp8SH4XVNQd26cVfIep+qRAAIOb2A
From: "Dave Engberg" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00E6_01C7044B.03F90C20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


I agree with Mike, and disagree with Sam's original assertion.

A keyless responder with pre-signed responses can be fully compliant with
the mandatory requirements of RFC 2560.  This is reflected in both the
"letter of the law" and in every OCSP relying party app/plug-in I've tested
(which can all work with keyless caching responders).

This approach isn't for everyone, but many issuers prefer to trade off the
hypothetical "replay" risk for the security & scalability advantages of
offline keys.  Drastically lower risk of key compromise, DoS, etc.

I don't believe that a profile of OCSP (like the Lightweight OCSP profile)
that implicitly encourages this type of deployment can be in conflict with
RFC 2560.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Myers
Sent: Thursday, November 09, 2006 4:37 PM
To: Sam Hartman
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


Sam,

For definition (since there has never really been one to date), there are
two forms of OCSP relay.  The first is a cache of previously signed yet
still reliable responses.  I believe this to be the target of the subject
I-D.  The second form is a re-signing of OCSP responses under a key trusted
by the ultimate requestor. Neither of these derivative aspects of OCSP are
discussed in any depth in 2560.  It is my preference that 2560 remain as is,
to define the protocol and its various options.  Other I-Ds may then map
that protocol and those options onto specific instances of need.

Mike

-----Original Message-----
From: Sam Hartman [mailto:[e-mail]]
Sent: Thursday, November 09, 2006 1:10 PM
To: Michael Myers
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.


------=_NextPart_000_00E6_01C7044B.03F90C20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1zCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA40wggL2oAMCAQICAgCfMA0GCSqG
SIb3DQEBBQUAMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNV
BAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDYyNjEzMjUwNVoXDTA3
MDgxMjEzMjUwNVowZzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEWMBQG
A1UEAxMNRGF2aWQgRW5nYmVyZzEmMCQGCSqGSIb3DQEJARYXZGVuZ2JlcmdAY29yZXN0cmVldC5j
b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9g2Z9TBa7wYqlyhCoriYfugKX5mwz
j1wVuDKEZ7ZsgoC0zT2Pm43BMkWwOL8GDXYMqbAt/1YelpCYMv8stgRDLj6N3DDyCNk4ihZONITf
o7F+RxnaH782KvJ5YwrIXDKMXWb6oqThFVDM05QKgC994W6Zp555F7NFEvPA/4rqK/1Ba0k2p8A3
yZazUimG3tt7x0tz6K7Z043ezRSUBB8VwgNSr4tQyElyuACrU3IA90yYZRm1maDe6jWylqDOXU/P
A22IC/Ma1sJ42k17Nhl3i/37SLOsHSLcyJk7bKgJPSgSqI+OBzYaDX6YGdoV6O/wih9f9YrovAH8
zF2pOXcHAgMBAAGjgdgwgdUwDgYDVR0PAQH/BAQDAgXgMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6
Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvY29yZXN0cmVldC5jcmwwIgYDVR0RBBswGYEXZGVuZ2Jl
cmdAY29yZXN0cmVldC5jb20wHwYDVR0jBBgwFoAU2Ox/kxjFZgPDEGw8BPZ3hT7/C7YwQAYIKwYB
BQUHAQEENDAyMDAGCCsGAQUFBzABhiRodHRwOi8vZ2VvdHJ1c3Qtb2NzcC5jb3Jlc3RyZWV0LmNv
bS8wDQYJKoZIhvcNAQEFBQADgYEAqMfvLi9brJBbTKdWcwUJAWPHgex9/KhvW8nherc7imLZdFXH
jp0NTTtgDK+aO/EJV/97JIyStyhfIH5vrZpb+ToFXz4O0Yb78KTHFdHjzlWei/Guo+kuUXouP8ZC
Tqkr0mFlqeRGFbq7w2SJhwhXEcO1K5Y8g0jf+kXr1ejYw9ExggMdMIIDGQIBATBYMFIxCzAJBgNV
BAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2Vy
dGlmaWNhdGUgQXV0aG9yaXR5AgIAnzAJBgUrDgMCGgUAoIIBmjAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMTAwMzA0MjNaMCMGCSqGSIb3DQEJBDEWBBSe1fQT
VyJwGObr8rnwuudd8c3QzTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq
hkiG9w0CBTBnBgkrBgEEAYI3EAQxWjBYMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3Ry
ZWV0IEx0ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgIAnzBp
BgsqhkiG9w0BCRACCzFaoFgwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRk
LjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAgCfMA0GCSqGSIb3
DQEBAQUABIIBAAJhP3jY/N7B7SJrd2agdH+TdxyFewh0Blajhg1e9HIu1vaTRzAF9YvT4I8L+l0K
l758dJIU6NtsqGeue7CUiVqzP9yzXrsWCsANrYmAoE6YKjRD236vPmIBb8hLM0l/VSBaSTqxYseT
3fAr/ZZXClEL8MjvzdcOYWp4C/upzGP/SIdor0qktNy7tUNGxVikxPooEEKIz3Ss70lS4NsZxmLX
Aj17wh9PQGondrEtmQG0Es9vaZuIzkdjQktcbCkuQfTiPlyd8rqR/sC+JqNzkHpGkMbhxoQPS+Qe
AbP2nW2bLFO9AsmY17UQ5oPCuKAFB42dwq2FY65oEA8zLjCYQ68AAAAAAAA=

------=_NextPart_000_00E6_01C7044B.03F90C20--



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 kA9NawZN055553; Thu, 9 Nov 2006 16:36:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9NawXn055552; Thu, 9 Nov 2006 16:36:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9NatgA055536 for <[e-mail]>; Thu, 9 Nov 2006 16:36:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 403 invoked by uid 0); 9 Nov 2006 23:36:47 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.70.2) by woodstock.binhost.com with SMTP; 9 Nov 2006 23:36:47 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 09 Nov 2006 18:36:32 -0500
To: "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft meeting minutes
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <p06230911c178511f7c68@[12.105.247.171]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Thanks.&nbsp; If I do not hear from the authors soon, then I will presume
that the effort is dead.<br><br>
Russ<br><br>
<br>
At 04:12 PM 11/9/2006, Stefan Santesson wrote:<br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>
This document does not specify any protocol.<br>
&nbsp;<br>
It specifies subjective design criteria for a UI that I seriously doubt
can be a base for a consensus process.<br>
If this document is progressed I suggest that it is handled as an
informational input progressed outside of the pkix wg.<br>
&nbsp;<br>
&nbsp;<br>
<b>Stefan Santesson<br>
</b>Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b>&nbsp;<br>
<b>From:</b> [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">
mailto:[e-mail]</a>] <b>On Behalf Of </b>Russ
Housley<br>
<b>Sent:</b> den 9 november 2006 10:06<br>
<b>To:</b> Stephen Kent; [e-mail]<br>
<b>Subject:</b> Re: draft meeting minutes<br>
&nbsp;<br>
Dear PKIX WG:<br><br>
<br>
<b>Document Status Review -</b> Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two new RFCs issued: SIM and
Update to Directory String Processing in RFC 3280. Five documents in IESG
review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed
for the first two, and a revised I-D is needed for CMC. (Russ Housley
requested WG direction re the UI draft. This individual submission
received AD comments requesting changes, but no revised document has been
delivered to the IESG.) <br><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to
messages from me.&nbsp; I am going to drop it if the authors do not
respond soon.&nbsp; If the PKIX WG thinks there is value in this
document, I'll send it to the WG instead of dropping it.<br><br>
Russ</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 kA9NU8tm053881; Thu, 9 Nov 2006 16:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9NU8Ju053880; Thu, 9 Nov 2006 16:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9NU6iC053824 for <[e-mail]>; Thu, 9 Nov 2006 16:30:08 -0700 (MST) (envelope-from [e-mail])
Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 15:30:00 -0800
Received: from IGT-HUB-02.redmond.corp.microsoft.com ([157.54.69.150]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 15:30:00 -0800
Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by IGT-HUB-02.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830);	 Thu, 9 Nov 2006 15:29:59 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 15:29:59 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 15:29:59 -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: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 15:29:36 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comment on draft-santesson-pkix-vccrl-00.txt
Thread-Index: AccEHo/2CbbjQjigTb+bn0XMUnRhCgAEfyMgAAKTtNAABmyYcA==
References: <[e-mail]> <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: "Kemp David P." <[e-mail]>, pkix <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2006 23:29:59.0156 (UTC) FILETIME=[F8D20340:01C70456]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kA9NU8iC053875
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David - I agree regarding business practices, however I think the
guidance here is about interoperability not business practice.

Networking protocols (like EAP) already have problems with certificate
payload being so large that sessions fail or take a very long time to
establish (due to re-try's related to lack of fragmentation support
pre-IP) example environments include high latency environments (metro
WANs, etc.). 

There are also environments where devices have constrained amounts of
storage (phones, etc.) where storing multiple copies of a object is
prohibitive.

On the other hand these same scenarios often can't work with indirect
CRLs without manual provisioning because they don't know how to do
discovery of the appropriate certificates and/or the resource at the end
of a AIA:IssuerCert in the CRL is not available or times out.

I guess what I am trying to say is that if this capability is to be
provided guidance of when the capability should be used (eg a well
worded applicability statement) should be included so that people don't
go out and include it everywhere.

I would have the same concern if we did the CMS wrapped CRL and
intermediate approach.

Ryan
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kemp David P.
Sent: Thursday, November 09, 2006 1:14 PM
To: pkix
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt


A technical standard that documents interfaces for the purpose of
interoperability shouldn't be giving "strongly"-worded guidance
concerning business processes.

I agree with Denis' approach.  A CA that encapsulates certs
inside CRLs may increase the efficiency of some customers
(by reducing the number of fetch operations) while simultaneously
decreasing the efficiency of other customers (by expanding the
size of CRLs).

A standard that gives CAs a mechanism for offering expanded CRLs
must also give customers a mechanism for accepting or declining
that offer.  I suggest that a standard of this type should enable
certificates to point to three forms of CRL data:
1) normal CRLs
2) CRLs containing certificates
3) a bag containing CRLs and certificates

It would be up to CAs to choose which of these options to offer.
I would recommend that "my" CAs support options 1 and, where
appropriate, 3.  For certificates that support more than one
option, the client can choose at runtime which is best.
There is no reason to choose expanded CRLs if the client has
previously obtained and cached the CRL issuer's certificate.

This capability could be expressed as three different CRLDP
extension OIDs (with the same extension syntax), or as a single
extension with some other mechanism (such as a standardized
http: "?" query option) to signal what type(s) of CRL data 
are available and which is being requested.  But a standard
of this type must define some way for the client to choose.
I would not support an RFC that does not provide the ability
to request normal CRLs as Denis has proposed.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan Hurst

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan





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 kA9NNlqL052308; Thu, 9 Nov 2006 16:23:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9NNlO7052307; Thu, 9 Nov 2006 16:23:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (dhcp68-116.ietf67.org [130.129.68.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9NNkBm052300 for <[e-mail]>; Thu, 9 Nov 2006 16:23:47 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C26F2E0035; Thu,  9 Nov 2006 18:23:44 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]>
Date: Thu, 09 Nov 2006 18:23:44 -0500
In-Reply-To: <[e-mail]> (Michael Myers's message of "Thu, 9 Nov 2006 13:36:55 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Sam, For definition (since there has never really been
    Michael> one to date), there are two forms of OCSP relay.  The
    Michael> first is a cache of previously signed yet still reliable
    Michael> responses.  I believe this to be the target of the
    Michael> subject I-D.  The second form is a re-signing of OCSP
    Michael> responses under a key trusted by the ultimate
    Michael> requestor. Neither of these derivative aspects of OCSP
    Michael> are discussed in any depth in 2560.  It is my preference
    Michael> that 2560 remain as is, to define the protocol and its
    Michael> various options.  Other I-Ds may then map that protocol
    Michael> and those options onto specific instances of need.

I don't understand how defining an OCSP relay would be different than
my option 1 to which you object.



Received: from iapps.com (host-65-173-63-254.acelerate.net [65.173.63.254]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kA9MRPwo038236 for <[e-mail]>; Thu, 9 Nov 2006 15:27:29 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c7044e$367cd7a0$d654a8c0@axxi>
Reply-To: "Ksenija Schilling" <[e-mail]>
From: "Ksenija Schilling" <[e-mail]>
To: [e-mail]
Subject: Re: new
Date: Thu, 9 Nov 2006 14:27:17 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C7040B.285997A0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C7040B.285997A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Nice PHffARMACY http://www.kindetunhasdefunertin.com

=20

be searching for a tachyon emission source. He appeared to run out of



------=_NextPart_000_0001_01C7040B.285997A0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV><H1>Nice PHffARMACY <A =
href=3D"http://www.kindetunhasdefunertin.com">http://www.kindetunhasdefun=
ertin.com</A></H1></DIV>
<DIV>&nbsp;</DIV>
<P>be searching for a tachyon emission source. He appeared to run out =
of<BR></P></BODY></HTML>
------=_NextPart_000_0001_01C7040B.285997A0--





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 kA9MDbL0034671; Thu, 9 Nov 2006 15:13:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9MDbOi034670; Thu, 9 Nov 2006 15:13:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9MDacp034655 for <[e-mail]>; Thu, 9 Nov 2006 15:13:37 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kA9MDZaF087596; Thu, 9 Nov 2006 15:13:35 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sam Hartman" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 9 Nov 2006 13:36:55 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam,

For definition (since there has never really been one to date), there are
two forms of OCSP relay.  The first is a cache of previously signed yet
still reliable responses.  I believe this to be the target of the subject
I-D.  The second form is a re-signing of OCSP responses under a key trusted
by the ultimate requestor. Neither of these derivative aspects of OCSP are
discussed in any depth in 2560.  It is my preference that 2560 remain as is,
to define the protocol and its various options.  Other I-Ds may then map
that protocol and those options onto specific instances of need.

Mike

-----Original Message-----
From: Sam Hartman [mailto:[e-mail]]
Sent: Thursday, November 09, 2006 1:10 PM
To: Michael Myers
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560


>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.



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 kA9LDjtp020381; Thu, 9 Nov 2006 14:13:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9LDjSO020380; Thu, 9 Nov 2006 14:13:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9LDhAO020323 for <[e-mail]>; Thu, 9 Nov 2006 14:13:44 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kA9LDY5V027212 for <[e-mail]>; Thu, 9 Nov 2006 16:13:34 -0500 (EST)
Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 09 Nov 2006 16:13:34 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Nov 2006 16:13:33 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 16:13:33 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comment on draft-santesson-pkix-vccrl-00.txt
Thread-Index: AccEHo/2CbbjQjigTb+bn0XMUnRhCgAEfyMgAAKTtNA=
From: "Kemp David P." <[e-mail]>
To: "pkix" <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2006 21:13:33.0924 (UTC) FILETIME=[EA0ABA40:01C70443]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14804000
X-TM-AS-Result: : Yes--7.695500-0-2-1
X-TM-AS-Category-Info: : 2:0.000000
X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMDQ4MC03MTAw?= =?us-ascii?B?MTUtNzExMDE2LTcwNDEyNC03MDIwODctNzA4Njg3LTcwMDc4OC03?= =?us-ascii?B?MDA4MzItMTIxMTEwLTEyMTEwMS03MDExMzUtNzA1NjMyLTcwOTk4?= =?us-ascii?B?MS03MDI5MDEtNzA0NjE5LTcwMTcxMC03MDAxNjAtNzAxNDI0LTcw?= =?us-ascii?B?MDgyMS03MDEyMzgtNzA5Mjc5LTcwMzQzNS03MDMwMzYtNzAxNjUx?= =?us-ascii?B?LTcwMzIxMi03MDMxNzktNzAzNTgzLTcwMTYyMC03MDEwMjUtNzAy?= =?us-ascii?B?MzI4LTcwMjI4My03MDExNDMtNzAyNzc2LTcwMTI1Mi03MDA0ODct?= =?us-ascii?B?NzAyNzA2LTcxMDk5Mi03MTA0ODYtMTg2MDM1LTcwMDQ3Ni03MDMy?= =?us-ascii?B?MTAtNzExNzk2LTcxMDA3Mi0xMzkwMDYtNzAyNjA2LTcwNDM3MS03?= =?us-ascii?B?MDEwMzQtNzA1MjEyLTcxMDI4My03MDA0NjYtNzAxMTEyLTcwMzYw?= =?us-ascii?B?MC03MDA3OTYtNzEwMDExLTcxMDY2Ny03MDAyNjMtNzExNTAzLTE0?= =?us-ascii?B?ODA1MA==?=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kA9LDiAO020375
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A technical standard that documents interfaces for the purpose of
interoperability shouldn't be giving "strongly"-worded guidance
concerning business processes.

I agree with Denis' approach.  A CA that encapsulates certs
inside CRLs may increase the efficiency of some customers
(by reducing the number of fetch operations) while simultaneously
decreasing the efficiency of other customers (by expanding the
size of CRLs).

A standard that gives CAs a mechanism for offering expanded CRLs
must also give customers a mechanism for accepting or declining
that offer.  I suggest that a standard of this type should enable
certificates to point to three forms of CRL data:
1) normal CRLs
2) CRLs containing certificates
3) a bag containing CRLs and certificates

It would be up to CAs to choose which of these options to offer.
I would recommend that "my" CAs support options 1 and, where
appropriate, 3.  For certificates that support more than one
option, the client can choose at runtime which is best.
There is no reason to choose expanded CRLs if the client has
previously obtained and cached the CRL issuer's certificate.

This capability could be expressed as three different CRLDP
extension OIDs (with the same extension syntax), or as a single
extension with some other mechanism (such as a standardized
http: "?" query option) to signal what type(s) of CRL data 
are available and which is being requested.  But a standard
of this type must define some way for the client to choose.
I would not support an RFC that does not provide the ability
to request normal CRLs as Denis has proposed.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan Hurst

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan



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 kA9LD6Zg020203; Thu, 9 Nov 2006 14:13:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9LD6WM020202; Thu, 9 Nov 2006 14:13:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9LD41t020150 for <[e-mail]>; Thu, 9 Nov 2006 14:13:05 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 21:12:58 +0000
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_01C70443.D4F008D2"
Subject: RE: draft meeting minutes
Date: Thu, 9 Nov 2006 21:12:59 -0000
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft meeting minutes
Thread-Index: AccENv3uamK+/XtZRySiuVJNghx8gAADHl0w
References: <p06230911c178511f7c68@[12.105.247.171]> <[e-mail]>
From: "Stefan Santesson" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2006 21:12:58.0924 (UTC) FILETIME=[D52E26C0:01C70443]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C70443.D4F008D2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This document does not specify any protocol.

=20

It specifies subjective design criteria for a UI that I seriously doubt
can be a base for a consensus process.

If this document is progressed I suggest that it is handled as an
informational input progressed outside of the pkix wg.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: den 9 november 2006 10:06
To: Stephen Kent; [e-mail]
Subject: Re: draft meeting minutes

=20

Dear PKIX WG:




Document Status Review - Stefan Santesson (Microsoft)
        Two new RFCs issued: SIM and Update to Directory String
Processing in RFC 3280. Five documents in IESG review: SCVP, Lightweight
OCSP, and 3 CMC documents. Follow up is needed for the first two, and a
revised I-D is needed for CMC. (Russ Housley requested WG direction re
the UI draft. This individual submission received AD comments requesting
changes, but no revised document has been delivered to the IESG.)=20


This is draft-choi-pkix-ui-03.txt.
It is not a PKIX WG document, but the authors have not responded to
messages from me.  I am going to drop it if the authors do not respond
soon.  If the PKIX WG thinks there is value in this document, I'll send
it to the WG instead of dropping it.

Russ


------_=_NextPart_001_01C70443.D4F008D2
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: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: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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<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:0cm;
	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;}
span.EmailStyle17
	{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:612.0pt 792.0pt;
	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=3DSV link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US =
style=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This document =
does not
specify any protocol.<o:p></o:p></span></a></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It specifies subjective design criteria for a UI that I =
seriously
doubt can be a base for a consensus process.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If this document is progressed I suggest that it is =
handled as
an informational input progressed outside of the pkix =
wg.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</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
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Russ =
Housley<br>
<b>Sent:</b> den 9 november 2006 10:06<br>
<b>To:</b> Stephen Kent; [e-mail]<br>
<b>Subject:</b> Re: draft meeting minutes<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Dear PKIX WG:<br>
<br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal><b><span style=3D'font-size:18.0pt'>Document Status =
Review -</span></b><span
style=3D'font-size:18.0pt'> Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Two new RFCs issued: SIM =
and
Update to Directory String Processing in RFC 3280. Five documents in =
IESG
review: SCVP, Lightweight OCSP, and 3 CMC documents. Follow up is needed =
for
the first two, and a revised I-D is needed for CMC. (Russ Housley =
requested WG
direction re the UI draft. This individual submission received AD =
comments requesting
changes, but no revised document has been delivered to the IESG.) =
</span><o:p></o:p></p>

<p class=3DMsoNormal><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to =
messages
from me.&nbsp; I am going to drop it if the authors do not respond =
soon.&nbsp;
If the PKIX WG thinks there is value in this document, I'll send it to =
the WG
instead of dropping it.<br>
<br>
Russ<o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C70443.D4F008D2--



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 kA9LAGWc019522; Thu, 9 Nov 2006 14:10:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9LAGh1019521; Thu, 9 Nov 2006 14:10:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (dhcp68-116.ietf67.org [130.129.68.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9LAFJ0019515 for <[e-mail]>; Thu, 9 Nov 2006 14:10:16 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 532DFE0035; Thu,  9 Nov 2006 16:10:13 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <[e-mail]>
Date: Thu, 09 Nov 2006 16:10:13 -0500
In-Reply-To: <[e-mail]> (Michael Myers's message of "Thu, 9 Nov 2006 12:00:23 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Michael" == Michael Myers <[e-mail]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.



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 kA9Kb60k010078; Thu, 9 Nov 2006 13:37:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9Kb6uC010077; Thu, 9 Nov 2006 13:37:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9Kb5NO010066 for <[e-mail]>; Thu, 9 Nov 2006 13:37:06 -0700 (MST) (envelope-from [e-mail])
Received: from mmyerslaptop (dslstat-bvi4-403.fastq.com [65.39.91.150]) by mailout.fastq.com (8.13.4/8.13.4) with SMTP id kA9Kb4gb084149; Thu, 9 Nov 2006 13:37:04 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Sam Hartman" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 9 Nov 2006 12:00:23 -0800
Message-ID: <[e-mail]>
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.1807
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam, all:

I will oppose the following:

> 1) Make a standards-track change/clarification to
>    2560 indicating that responders need not have a key.

Perhaps the subject I-D should clarify the role of a relay.

Mike

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sam Hartman
Sent: Thursday, November 09, 2006 10:16 AM
To: [e-mail]
Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560





Hi, folsk.

I have a discuss on the lightweight ocsp profile .

One of the primary purposes of the lightweight OCSP profile is to
allow deployment of responders that do not have private keys and thus
can only return pre-produced responses.
However this document is  informational, not standards track.

I contend that RFC 2560 allows pre-produced responses, but does not
really support responders that can only give pre-produced responses.
That is, I contend that as written, to achieve interoperability, you
need to have an online signing key.

I believe it is inappropriate for an informational document to profile
OCSP in this way.

I'd like to ask the PKIX working group to do one of three things to resolve
my discuss:

1) Make a standards-track change/clarification to 2560 indicating that
   responders need not have a key.

2) Remove this major goal from the lightweight-ocsp-profile.

3) Withdraw the document.



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 kA9Iv2vD084512; Thu, 9 Nov 2006 11:57:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9Iv2sf084511; Thu, 9 Nov 2006 11:57:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9Iv1OE084475 for <[e-mail]>; Thu, 9 Nov 2006 11:57:01 -0700 (MST) (envelope-from [e-mail])
Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 10:56:56 -0800
Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);	 Thu, 9 Nov 2006 10:56:55 -0800
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 10:56:55 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 10:56:54 -0800
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 10:56:54 -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: Comment on draft-santesson-pkix-vccrl-00.txt
Date: Thu, 9 Nov 2006 10:56:15 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comment on draft-santesson-pkix-vccrl-00.txt
Thread-Index: AccEHo/2CbbjQjigTb+bn0XMUnRhCgAEfyMg
References: <[e-mail]>
From: Ryan Hurst <[e-mail]>
To: Denis Pinkas <[e-mail]>, pkix <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2006 18:56:54.0672 (UTC) FILETIME=[D2E82900:01C70430]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kA9Iv1OE084506
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe I understand Denis concern, I would personally be OK with the
proposal as stands if its use was limited to only the scenarios where it
is needed and the text in the document strongly made that limitation
apparent; specifically indirect cases.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Thursday, November 09, 2006 6:18 AM
To: pkix
Subject: Comment on draft-santesson-pkix-vccrl-00.txt


Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that
new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the
choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new
certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a
new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and
would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on
the CA side and 
on the relying party side and the saving of  one exchange.

Denis








Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9IG8F5074673; Thu, 9 Nov 2006 11:16:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9IG8iE074672; Thu, 9 Nov 2006 11:16:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.mit.edu (dhcp68-116.ietf67.org [130.129.68.116]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA9IG7Su074656 for <[e-mail]>; Thu, 9 Nov 2006 11:16:08 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C55FAE0038; Thu,  9 Nov 2006 13:15:57 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
Date: Thu, 09 Nov 2006 13:15:57 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, folsk.

I have a discuss on the lightweight ocsp profile .

One of the primary purposes of the lightweight OCSP profile is to
allow deployment of responders that do not have private keys and thus
can only return pre-produced responses.
However this document is  informational, not standards track.

I contend that RFC 2560 allows pre-produced responses, but does not
really support responders that can only give pre-produced responses.
That is, I contend that as written, to achieve interoperability, you
need to have an online signing key.

I believe it is inappropriate for an informational document to profile
OCSP in this way.

I'd like to ask the PKIX working group to do one of three things to resolve my discuss:

1) Make a standards-track change/clarification to 2560 indicating that
   responders need not have a key.

2) Remove this major goal from the lightweight-ocsp-profile.

3) Withdraw the document.



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 kA9ICHeW073783; Thu, 9 Nov 2006 11:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9ICHsa073782; Thu, 9 Nov 2006 11:12:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9ICFGE073767 for <[e-mail]>; Thu, 9 Nov 2006 11:12:16 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29427 invoked by uid 0); 9 Nov 2006 18:12:10 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.68.101) by woodstock.binhost.com with SMTP; 9 Nov 2006 18:12:10 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Thu, 09 Nov 2006 13:06:03 -0500
To: Stephen Kent <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft meeting minutes
In-Reply-To: <p06230911c178511f7c68@[12.105.247.171]>
References: <p06230911c178511f7c68@[12.105.247.171]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Dear PKIX WG:<br><br>
<blockquote type=cite class=cite cite=""><font size=5><b>Document Status
Review -</b> Stefan Santesson (Microsoft)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Two new
RFCs issued: SIM and Update to Directory String Processing in RFC 3280.
Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC
documents. Follow up is needed for the first two, and a revised I-D is
needed for CMC. (Russ Housley requested WG direction re the UI draft.
This individual submission received AD comments requesting changes, but
no revised document has been delivered to the IESG.)
</font></blockquote><br>
This is draft-choi-pkix-ui-03.txt.<br>
It is not a PKIX WG document, but the authors have not responded to
messages from me.&nbsp; I am going to drop it if the authors do not
respond soon.&nbsp; If the PKIX WG thinks there is value in this
document, I'll send it to the WG instead of dropping it.<br><br>
Russ<br>
</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 kA9EHwOf012119; Thu, 9 Nov 2006 07:17:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA9EHwhA012118; Thu, 9 Nov 2006 07:17:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA9EHtkG012104 for <[e-mail]>; Thu, 9 Nov 2006 07:17:57 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA29570 for <[e-mail]>; Thu, 9 Nov 2006 15:20:33 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2006110915175380:63593 ; Thu, 9 Nov 2006 15:17:53 +0100 
Date: Thu, 9 Nov 2006 15:17:51 +0100
From: "Denis Pinkas" <[e-mail]>
To: "pkix" <[e-mail]>
Subject: Comment on draft-santesson-pkix-vccrl-00.txt
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 09/11/2006 15:17:53, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 09/11/2006 15:17:55, Serialize complete at 09/11/2006 15:17:55
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Your current proposal is limited to propose a new CRLextension:

id-pe-validationCerts OBJECT IDENTIFIER ::= { id-pe nn }

The problem is the following: if a CA chooses to issue CRLs with that new extension, 
then all CRLs will augment in size.

I would rather prefer to be able to provide relying parties with the choice between :

  - CRLs that carry that new extension, and 
  - CRLs "as usual".

This would be achieved, if you were proposing at the same time a new certificate extension 
that would allow to retrieve CRLs that have the new extension (e.g. a new CRLDP extension 
that would point where the bigger CRL is).

Current applications would continue to ignore both new extensions and would not be impacted 
in any way, whatever the choice of the CA would be.

All this story is a trade off between this additional complexity both on the CA side and 
on the relying party side and the saving of  one exchange.

Denis






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA95gJAS050225; Wed, 8 Nov 2006 22:42:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA95gJFO050224; Wed, 8 Nov 2006 22:42:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from auth0.cht.com.tw (esmtpo1.cht.com.tw [202.39.168.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA95gFe2050208 for <[e-mail]>; Wed, 8 Nov 2006 22:42:18 -0700 (MST) (envelope-from [e-mail])
Received: from auth0.cht.com.tw (localhost.localdomain [127.0.0.1]) by localhost.cht.com.tw (Postfix) with ESMTP id 4CEC52CC364; Thu,  9 Nov 2006 13:42:07 +0800 (CST)
Received: from wcwang (unknown [10.144.133.93]) by auth0.cht.com.tw (Postfix) with SMTP id E58722CC27D; Thu,  9 Nov 2006 13:42:06 +0800 (CST)
Message-ID: <001d01c703c1$c96465c0$5d85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, =?utf-8?B?6LW1IOaVjw==?= <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
Date: Thu, 9 Nov 2006 13:41:59 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C70404.D4B68460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C70404.D4B68460
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

It is true that an INSTANCE OF <DefinedObjectClass> is equivalent to
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id     <DefinedObjectClass>.&id,
    value        [0] EXPLICIT <DefinedObjectClass>.&Type
}

Therefore, if the "AnotherName" type is, as claimed, defined to replace
the "INSTANCE OF OTHER NAME" type, its syntax should be:

AnotherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE
{
    type-id      OBJECT IDENTIFIER,
    value        [0] EXPLICIT ANY DEFINED BY type-id
}

(Note that in RFC 2459, 3280 and 3280bis, the text wrongly claims
that "AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER".
The reason why the statement is wrong is that OTHER-NAME
is an information object class while AnotherName is a data type, and
a data type can not replace an information object class.
The correct way of saying that should be "AnotherName replaces
INSTANCE OF OTHER-NAME", because "INSTANCE OF OTHER-NAME"
is a data type.)

However, to my knowledge of ASN.1, since the default tagging mode of the
PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be the
same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede the
SEQUENCE type. The reason is that the outer implicit tag (i.e., the tag =
[0]
precedes the "AnotherName" type in the GeneralName type) will always
overwrite the inner tag no matter the inner tag is an "[UNIVERSAL 8] =
IMPLICIT
SEQUENCE" or  simply a "SEQUENCE".

My conclusion to this issue is that even the syntax is inconsistent =
between
PKIX and ITU-T X.509, it is luckly that their DER encodings will still =
be the
same.

Nevertheless, one thing we should note is that the "AnotherName" type =
should
not be used alone without any implicit tag precede, otherwise it will =
result
inconsistent DER encoding with ITU-T X.509. For example, if someday we
define a type named "ListOfAnotherNames" as the following:

ListOfAnotherNames ::=3D SEQUENCE OF AnotherName

With our current definition of the "AnotherName" type, the DER encoding
of an "AnotherName" value will different with the case where it is =
defined
as the following:

ListOfAnotherNames ::=3D SEQUENCE OF INSTANCE OF OTHER-NAME

So, now the question is "do we need to change the syntax of AnotherName
to be syntactically aligned with ITU-T X.509?"

Wen-Cheng Wang
  ----- Original Message -----=20
  From: David A. Cooper=20
  To: =E8=B5=B5 =E6=95=8F=20
  Cc: pkix=20
  Sent: Thursday, November 09, 2006 3:01 AM
  Subject: Re: The definition of OtherName in 3280bis differs with =
X.509?


  I do not understand ASN.1 well enough to answer the question below, =
but someone else on the PKIX mail list may be able to respond.

  I can say, however, that the ASN.1 for OtherName in 3280bis is the =
same as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 =
(April 2002), so if it in an error it is a very old error.

  Dave


  -------- Original Message -------- Subject:  The difinition of =
OtherName in 3280bis differs with X.509?=20
        Date:  Wed, 08 Nov 2006 14:23:38 +0800=20
        From:  =E8=B5=B5 =E6=95=8F <[e-mail]>=20
        To:  [e-mail]=20



Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::=3D SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::=3D CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME,=20
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::=3D TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::=3D CLASS
{
 &id OBJECT IDENTIFIER UNIQUE,
 &Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id <DefinedObjectClass>.&id,
 value [0] <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular=20
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The =
definition=20
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of =

the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id <DefinedObjectClass>.&id,
  value [0] EXPLICIT <DefinedObjectClass>.&Type
}
where "<DefinedObjectClass>" is replaced by the particular=20
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should=20
be:
OtherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
 =20
  Because the tag of otherName is IMPLICIT,the encode value of =
GeneralName=20
in rfc3280bis is identical of X.509.

                         =20
                   zhaomin


------=_NextPart_000_001A_01C70404.D4B68460
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>It is true that an INSTANCE OF &lt;DefinedObjectClass&gt; is =
equivalent=20
to</DIV>
<DIV>[UNIVERSAL 8] IMPLICIT SEQUENCE<BR>{</DIV>
<DIV>&nbsp;&nbsp;&nbsp; type-id&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;DefinedObjectClass&gt;.&amp;id,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; value&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [0] =
EXPLICIT=20
&lt;DefinedObjectClass&gt;.&amp;Type<BR>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, if the "AnotherName" type is, as claimed,&nbsp;defined =
to=20
replace</DIV>
<DIV>the "INSTANCE OF OTHER NAME" type, its syntax should be:</DIV>
<DIV>&nbsp;</DIV>
<DIV>AnotherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE<BR>{</DIV>
<DIV>&nbsp;&nbsp;&nbsp; =
type-id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;OBJECT=20
IDENTIFIER,</DIV>
<DIV>&nbsp;&nbsp;&nbsp; value&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; [0] =
EXPLICIT=20
ANY DEFINED BY type-id<BR>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>(Note that in RFC 2459, 3280 and 3280bis, the text wrongly =
claims</DIV>
<DIV>that "AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER".</DIV>
<DIV>The reason why the statement is wrong is&nbsp;that OTHER-NAME
<DIV>is an information object class while AnotherName is a data type, =
and</DIV>
<DIV>a data type can not replace an information object =
class.</DIV></DIV>
<DIV>The correct way of saying that should be "AnotherName =
replaces</DIV>
<DIV>INSTANCE OF OTHER-NAME", because&nbsp;"INSTANCE OF =
OTHER-NAME"</DIV>
<DIV>is a data type.)</DIV>
<DIV>&nbsp;</DIV>
<DIV>However, to my knowledge of ASN.1, since the default tagging mode =
of=20
the</DIV>
<DIV>PKIX1Implicit88 module is "IMPLICIT TAGS", the DER encoding will be =

the</DIV>
<DIV>same with or without the "[UNIVERSAL 8] IMPLICIT" tagging precede =
the</DIV>
<DIV>SEQUENCE type. The reason is that the outer implicit tag (i.e., the =
tag=20
[0]</DIV>
<DIV>precedes the "AnotherName" type in the GeneralName type) will =
always</DIV>
<DIV>overwrite the inner tag no matter&nbsp;the inner tag is an =
"[UNIVERSAL 8]=20
IMPLICIT</DIV>
<DIV>SEQUENCE" or&nbsp;&nbsp;simply a "SEQUENCE".</DIV>
<DIV>&nbsp;</DIV>
<DIV>My conclusion to this issue is that even the syntax is inconsistent =

between</DIV>
<DIV>PKIX and ITU-T X.509, it is luckly that their DER encodings will =
still be=20
the</DIV>
<DIV>same.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Nevertheless, one thing we should note is that the "AnotherName" =
type=20
should</DIV>
<DIV>not be used alone&nbsp;without any implicit tag precede, otherwise =
it will=20
result</DIV>
<DIV>inconsistent DER encoding with ITU-T X.509. For example, if someday =

we</DIV>
<DIV>define a type named "ListOfAnotherNames" as the following:</DIV>
<DIV>&nbsp;</DIV>
<DIV>ListOfAnotherNames ::=3D SEQUENCE OF AnotherName</DIV>
<DIV>&nbsp;</DIV>
<DIV>With our current definition of the "AnotherName" type, the DER=20
encoding</DIV>
<DIV>of an "AnotherName" value will different with the case&nbsp;where =
it is=20
defined</DIV>
<DIV>as the following:</DIV>
<DIV>&nbsp;</DIV>
<DIV>ListOfAnotherNames ::=3D SEQUENCE OF INSTANCE OF OTHER-NAME</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, now the question is "do we need to change the syntax of=20
AnotherName</DIV>
<DIV>to be syntactically aligned with ITU-T X.509?"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Wen-Cheng Wang</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt =E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94; font-color: black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">David A.=20
  Cooper</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">=E8=B5=B5 =E6=95=8F</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">pkix</A> </DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Sent:</B> Thursday, November =
09, 2006 3:01=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt =
=E6=96=B0=E7=B4=B0=E6=98=8E=E9=AB=94"><B>Subject:</B> Re: The definition =
of OtherName=20
  in 3280bis differs with X.509?</DIV>
  <DIV><BR></DIV>I do not understand ASN.1 well enough to answer the =
question=20
  below, but someone else on the PKIX mail list may be able to =
respond.<BR><BR>I=20
  can say, however, that the ASN.1 for OtherName in 3280bis is the same =
as the=20
  ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280 (April =
2002), so=20
  if it in an error it is a very old =
error.<BR><BR>Dave<BR><BR><BR>--------=20
  Original Message --------=20
  <TABLE class=3Dmoz-email-headers-table cellSpacing=3D0 cellPadding=3D0 =
border=3D0>
    <TBODY>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>Subject: </TH>
      <TD>The difinition of OtherName in 3280bis differs with =
X.509?</TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>Date: </TH>
      <TD>Wed, 08 Nov 2006 14:23:38 +0800</TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>From: </TH>
      <TD>=E8=B5=B5 =E6=95=8F <A class=3Dmoz-txt-link-rfc2396E=20
        =
href=3D"mailto:[e-mail]">&lt;[e-mail]&gt;</A></TD></TR>
    <TR>
      <TH vAlign=3Dbaseline noWrap align=3Dright>To: </TH>
      <TD><A class=3Dmoz-txt-link-abbreviated=20
        =
href=3D"mailto:[e-mail]">[e-mail]</A></TD></TR>=
</TBODY></TABLE><BR><BR><PRE>Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::=3D TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::=3D SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::=3D CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME,=20
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::=3D TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::=3D CLASS
{
 &amp;id OBJECT IDENTIFIER UNIQUE,
 &amp;Type
}
WITH SYNTAX {&amp;Type IDENTIFIED BY &amp;id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id &lt;DefinedObjectClass&gt;.&amp;id,
 value [0] &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular=20
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::=3D SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The =
definition=20
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of =

the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id &lt;DefinedObjectClass&gt;.&amp;id,
  value [0] EXPLICIT &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular=20
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should=20
be:
OtherName ::=3D [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
 =20
  Because the tag of otherName is IMPLICIT,the encode value of =
GeneralName=20
in rfc3280bis is identical of X.509.

                         =20
                   zhaomin

</PRE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001A_01C70404.D4B68460--



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 kA93jZ79039976; Wed, 8 Nov 2006 20:45:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA93jZGE039975; Wed, 8 Nov 2006 20:45:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA93jXsr039959 for <[e-mail]>; Wed, 8 Nov 2006 20:45:34 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.105.247.171]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Gi0qw-0005F2-3i for [e-mail]; Wed, 08 Nov 2006 22:45:26 -0500
Mime-Version: 1.0
Message-Id: <p06230911c178511f7c68@[12.105.247.171]>
Date: Wed, 8 Nov 2006 22:43:32 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes
Content-Type: multipart/alternative; boundary="============_-1049078573==_ma============"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1049078573==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Please send comments to me by 11/27.

Steve
-----

PKIX WG Meeting 11/8/06

Edited by Steve Kent
Chairs: Stephen Kent <[e-mail]> &  Stefan Santesson <[e-mail]>

The PKIX WG met once, for a total of two hours, during the 67th IETF. 
A total of approximately 50 individuals participated in the meeting.


Document Status Review - Stefan Santesson (Microsoft)
	Two new RFCs issued: SIM and Update to Directory String 
Processing in RFC 3280. Five documents in IESG review: SCVP, 
Lightweight OCSP, and 3 CMC documents. Follow up is needed for the 
first two, and a revised I-D is needed for CMC. (Russ Housley 
requested WG direction re the UI draft. This individual submission 
received AD comments requesting changes, but no revised document has 
been delivered to the IESG.) Two documents have completed WG last 
call, and will soon be forwarded to the IESG: 3280bis and SAN for 
Service Names. Two documents still under WG review: ECC algorithms 
(waiting for resolution of algorithm parameter resolution) and the 
Draft for ECDSA and DSA with SHA-2. (slides)

      
      
PKIX WG Specifications

3280bis -  David Cooper (NIST)
       A new draft 05 was recently posted as response to past WG last 
call. David reviewed the changes made from version 4 to version 5, 
and provided an explanation for each change. (slides)

Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)
	This document is still in AD evaluation and a new draft 
requested by the AD. We are currently at version 28! Tim reviewed the 
changes made in response to Sam's comments. He noted that these 
changes were posted to the list on Halloween, and that there have 
been no responses to this posting. However, Tim identified one or two 
additional fixes that need to be effected before the document will be 
finished. He also identified one open issue, related to whether the 
document satisfies the interoperability requirements established by 
2026.
	[Sam wants us to run a straw poll to confirm that the WG is 
comfortable with a single spec that defines both DPD and DPV and does 
not mandate that a server do either one as a base.]
(slides)

Certificate Management Messages over CMS (CMC) - Jim Schaad (Soaring 
Hawk Consulting)
       These documents are under IESG review which has resulted in 
several change requests. For example, there is a need for the section 
detailing the changes from the base documents (since this is a "bis" 
document). There is also a need to accommodate hash algorithm 
agility, a relatively easy fix. A bigger issue is whether to change 
the OID used to refer to the encrypted data, because of the way 
S/MIME has defined this OID. A more significant issue is a request 
from the AD to make use of CRMF a MUST and make use of PKCS #10 
structures a MAY. We plan to complete WG last call by December, in 
parallel with AD re-review. (slides)

Algorithm IDs for Elliptic Curve Cryptography in PKIX - Brian Minard (Certicom)
	Dan Brown (the document author) could not be physically 
present, but monitored the presentation via Jabber. Looking for 
feedback on several issues, including support for parameters for 
SHA-2, and references to KDFs to be used with the public key in the 
certificate, in the context of EC-DH or EC-MQV. The question was 
raised as to why one needs to make reference to a KDF in a 
certificate, given that the KDFs are not protocol specific, but one 
needs protocol-specific details to completely specify how key 
derivation is performed. Much of the discussion on this topic is 
subsumed by the next topic. (slides)

Design team report on ECC public key IDs - Tim Polk (NIST)
	We instantiated a design team of Tim, Brian Minard, and Tolga 
Acar to address this complex issue. RFC 3279 defines an OID for EC, 
and includes algorithm parameters, but this does not provide a way to 
distinguish between a bit string to be used with EC-DH vs. EC-MQV. 
Two choices were evaluated: RFC 4055-style solution vs. the ANSI 
X.962 solution to specify which algorithm or algorithms can be used 
with the key. RFC 4055 was developed to distinguish among RSA modes, 
but is easily adapted to accommodate ECC. ANSI X.962 puts into the 
parameters field the additional info needed to specify the algorithms 
that the key can be used with. This leads to potential nesting of 
OIDs, and one can also specify KDFs here as well. The design team 
suggested a third approach, namely to retain the 3279 parameter 
model, and to optionally augment it with a certificate extension to 
specify the additional data that the ANSI approach encodes in the 
parameters field, as well as accommodating the notion of family OIDs, 
something not supported in the ANSI approach. A feature of this 
approach is that if the extension is non-critical, the result is 
backwards compatible with 3279, but making it critical allows one to 
enforce the sort of fine-grained controls available in the ANSI 
approach. The team developed a set of criteria for evaluating the 3 
approaches. They polled a variety of folks and got a diverse set of 
answers. Their decision was that the use of a new extension is 
preferred, in conjunction with the RFC 3279 ECC syntax. Numerous 
questions were raised by attendees. The discussion will continue on 
the list, and we will probably result in a new work item to resolve 
this issue, including asking whether the use of a new extension is 
appropriate for RSA as well (in lieu of RFC 4055). (slides)


Related Specifications & Liaison Presentations
      

Validation Certificates in CRLs - Stefan Santesson (Microsoft)
       A new individual draft that proposes an optional extension that 
allows one to embed one or more certificates in a CRL. The intent is 
to facilitate CRL validation when the certificate(s) needed to verify 
a CRL are different from the certificate associated with the CA under 
whose auspices the CRL is issued. One can already embed a pointer to 
the requisite certificate, so the advantage to this approach is that 
it can save a retrieval request (across a net), and for CRL 
validation in the NR context, when CRL processing will take place 
long after CRL issuance. One should use this extension only in 
"appropriate" contexts, e.g., to avoid unnecessary CRL bloat. The 
question is whether this be accepted as a WG document. A straw poll 
will be conducted on the WG list. (slides)
--============_-1049078573==_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>draft meeting minutes</title></head><body>
<div>Please send comments to me by 11/27.</div>
<div><br></div>
<div>Steve</div>
<div>-----</div>
<div><br></div>
<div><font size="+2" color="#000000"><b>PKIX WG Meeting 11/8/06<br>
<br>
</b>Edited by Steve Kent<br>
Chairs: Stephen Kent &lt;[e-mail]&gt; &amp;&nbsp; Stefan Santesson
&lt;[e-mail]&gt;<br>
<br>
The PKIX WG met once, for a total of two hours, during the 67th IETF.
A total of approximately 50 individuals participated in the
meeting.<br>
<br>
<br>
<b>Document Status Review -</b> Stefan Santesson (Microsoft)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Two new RFCs
issued: SIM and Update to Directory String Processing in RFC 3280.
Five documents in IESG review: SCVP, Lightweight OCSP, and 3 CMC
documents. Follow up is needed for the first two, and a revised I-D is
needed for CMC. (Russ Housley requested WG direction re the UI draft.
This individual submission received AD comments requesting changes,
but no revised document has been delivered to the IESG.) Two documents
have completed WG last call, and will soon be forwarded to the IESG:
3280bis and SAN for Service Names. Two documents still under WG
review: ECC algorithms (waiting for resolution of algorithm parameter
resolution) and the Draft for ECDSA and DSA with SHA-2. (slides)<br>
&nbsp;<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
</b></font><font size="+3" color="#000000"><b>PKIX WG
Specifications<br>
<br>
</b></font><font size="+2" color="#000000"><b>3280bis -&nbsp; David
Cooper (NIST)<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A new draft 05 was recently posted
as response to past WG last call. David reviewed the changes made from
version 4 to version 5, and provided an explanation for each change.
(slides)<br>
<br>
<b>Simple Certificate Validation Protocol (SCVP)- Tim Polk (NIST)<br>
</b><x-tab>&nbsp; </x-tab>This document is still in AD evaluation and
a new draft requested by the AD. We are currently at version 28! Tim
reviewed the changes made in response to Sam's comments. He noted that
these changes were posted to the list on Halloween, and that there
have been no responses to this posting. However, Tim identified one or
two additional fixes that need to be effected before the document will
be finished. He also identified one open issue, related to whether the
document satisfies the interoperability requirements established by
2026.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>[Sam wants us to
run a straw poll to confirm that the WG is comfortable with a single
spec that defines both DPD and DPV and does not mandate that a server
do either one as a base.]<br>
(slides)<br>
<br>
<b>Certificate Management Messages over CMS (CMC) - Jim Schaad
(Soaring Hawk Consulting)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</b> These documents are under IESG
review which has resulted in several change requests. For example,
there is a need for the section detailing the changes from the base
documents (since this is a "bis" document). There is also a need
to accommodate hash algorithm agility, a relatively easy fix. A bigger
issue is whether to change the OID used to refer to the encrypted
data, because of the way S/MIME has defined this OID. A more
significant issue is a request from the AD to make use of CRMF a MUST
and make use of PKCS #10 structures a MAY. We plan to complete WG last
call by December, in parallel with AD re-review. (slides)<br>
<br>
<b>Algorithm IDs for Elliptic Curve Cryptography in PKIX - Brian
Minard (Certicom)<br>
</b><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Dan Brown (the
document author) could not be physically present, but monitored the
presentation via Jabber. Looking for feedback on several issues,
including support for parameters for SHA-2, and references to KDFs to
be used with the public key in the certificate, in the context of
EC-DH or EC-MQV. The question was raised as to why one needs to make
reference to a KDF in a certificate, given that the KDFs are not
protocol specific, but one needs protocol-specific details to
completely specify how key derivation is performed. Much of the
discussion on this topic is subsumed by the next topic. (slides)<br>
<br>
<b>Design team report on ECC public key IDs - Tim Polk (NIST)<br>
</b><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>We instantiated a
design team of Tim, Brian Minard, and Tolga Acar to address this
complex issue. RFC 3279 defines an OID for EC, and includes algorithm
parameters, but this does not provide a way to distinguish between a
bit string to be used with EC-DH vs. EC-MQV. Two choices were
evaluated: RFC 4055-style solution vs. the ANSI X.962 solution to
specify which algorithm or algorithms can be used with the key. RFC
4055 was developed to distinguish among RSA modes, but is easily
adapted to accommodate ECC. ANSI X.962 puts into the parameters field
the additional info needed to specify the algorithms that the key can
be used with. This leads to potential nesting of OIDs, and one can
also specify KDFs here as well. The design team suggested a third
approach, namely to retain the 3279 parameter model, and to optionally
augment it with a certificate extension to specify the additional data
that the ANSI approach encodes in the parameters field, as well as
accommodating the notion of family OIDs, something not supported in
the ANSI approach. A feature of this approach is that if the extension
is non-critical, the result is backwards compatible with 3279, but
making it critical allows one to enforce the sort of fine-grained
controls available in the ANSI approach. The team developed a set of
criteria for evaluating the 3&nbsp; approaches. They polled a variety
of folks and got a diverse set of answers. Their decision was that the
use of a new extension is preferred, in conjunction with the RFC 3279
ECC syntax. Numerous questions were raised by attendees. The
discussion will continue on the list, and we will probably result in a
new work item to resolve this issue, including asking whether the use
of a new extension is appropriate for RSA as well (in lieu of RFC
4055). (slides)</font></div>
<div><font size="+2" color="#000000"><br>
<br>
</font><font size="+3" color="#000000"><b>Related Specifications &amp;
Liaison Presentations<br>
</b></font><font size="+2"
color="#000000"><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
<br>
Validation Certificates in CRLs - Stefan Santesson (Microsoft)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</b> A new individual draft that
proposes an optional extension that allows one to embed one or more
certificates in a CRL. The intent is to facilitate CRL validation when
the certificate(s) needed to verify a CRL are different from the
certificate associated with the CA under whose auspices the CRL is
issued. One can already embed a pointer to the requisite certificate,
so the advantage to this approach is that it can save a retrieval
request (across a net), and for CRL validation in the NR context, when
CRL processing will take place long after CRL issuance. One should use
this extension only in "appropriate" contexts, e.g., to avoid
unnecessary CRL bloat. The question is whether this be accepted as a
WG document. A straw poll will be conducted on the WG list.
(slides)</font></div>
</body>
</html>
--============_-1049078573==_ma============--



Received: from [202.155.214.218] ([202.155.214.218]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA934mBl036141 for <[e-mail]>; Wed, 8 Nov 2006 20:04:49 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000e01c703ab$cf4dc5a0$dad69bca@lc14>
From: "bene..." <[e-mail]>
To: [e-mail]
Subject: voce conigli .:
Date: 	Thu, 9 Nov 2006 11:04:45 +0800
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C703EE.DD7105A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000A_01C703EE.DD7105A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000B_01C703EE.DD7105A0"


------=_NextPart_001_000B_01C703EE.DD7105A0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


All is as read a Hosting am Aruba Proteggi.
League of Coppa Uefa Mondiali bidoni Europei migliori of bomberby. Top =
is Auguri nannini ciao grazie tutti a.
Post a nome altre in. League Coppa of Uefa of Mondiali bidoni Europei =
migliori or bomberby or Pallavolo. Che nanna lascio custodia ciau top is =
good a tata a tata. Uao non a si of spama.
Help Fast a Passterms of me. Rispondi sondaggio aiutaci capire or tuoi =
interessi Yaoi Style voce or! Giorno mb uao non a si in.
Costosoby cazzata parlare Telefilms amp Piccolo Schermo film vistoby? =
Dei miei cerca!
Lab Chat in tag Faccine Template Smallville Powered Invision Power. =
Nostri motori Mercedes Bmwby cosa tuo computer of Free a.
Qui vostre assenze vo fare la generi parla ruota.
Pi amatoforum led. Nostri motori Mercedes Bmwby cosa tuo computer of =
Free a.
Custodia ciau top am good tata in tata salve. Windows Movie Makerby is =
su Gite. Iiuser legend Moderatori in.
Belle Cinese lo Iiquizquiz domande Quiz. Grazie tutti seahawk of buona =
nanno Mave Buonanotte raga.
Grezie Barbara van of? Risposte dagli or esperti anni primo or bacioby =
bens nostri motori?
Ritiro subito quello.
League of Coppa Uefa Mondiali bidoni Europei migliori of bomberby.
Of me Anonymous Home Page Supporto in Forumfree Segnala am.
Auguroni giorno am mb!
Raga zefir raga malvo a thrasher.
Auguroni giorno am mb!
Auguroni giorno mb uao non of si is.
------=_NextPart_001_000B_01C703EE.DD7105A0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"bannati" hspace=3D0=20
src=3D"cid:000901c703ab$cf4dc5a0$dad69bca@lc14" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>All is as read a Hosting am Aruba=20
Proteggi.<BR>League of Coppa Uefa Mondiali bidoni Europei migliori of =
bomberby.=20
Top is Auguri nannini ciao grazie tutti a.<BR>Post a nome altre in. =
League Coppa=20
of Uefa of Mondiali bidoni Europei migliori or bomberby or Pallavolo. =
Che nanna=20
lascio custodia ciau top is good a tata a tata. Uao non a si of =
spama.<BR>Help=20
Fast a Passterms of me. Rispondi sondaggio aiutaci capire or tuoi =
interessi Yaoi=20
Style voce or! Giorno mb uao non a si in.<BR>Costosoby cazzata parlare =
Telefilms=20
amp Piccolo Schermo film vistoby? Dei miei cerca!<BR>Lab Chat in tag =
Faccine=20
Template Smallville Powered Invision Power. Nostri motori Mercedes Bmwby =
cosa=20
tuo computer of Free a.<BR>Qui vostre assenze vo fare la generi parla=20
ruota.<BR>Pi amatoforum led. Nostri motori Mercedes Bmwby cosa tuo =
computer of=20
Free a.<BR>Custodia ciau top am good tata in tata salve. Windows Movie =
Makerby=20
is su Gite. Iiuser legend Moderatori in.<BR>Belle Cinese lo Iiquizquiz =
domande=20
Quiz. Grazie tutti seahawk of buona nanno Mave Buonanotte =
raga.<BR>Grezie=20
Barbara van of? Risposte dagli or esperti anni primo or bacioby bens =
nostri=20
motori?<BR>Ritiro subito quello.<BR>League of Coppa Uefa Mondiali bidoni =
Europei=20
migliori of bomberby.<BR>Of me Anonymous Home Page Supporto in Forumfree =
Segnala=20
am.<BR>Auguroni giorno am mb!<BR>Raga zefir raga malvo a =
thrasher.<BR>Auguroni=20
giorno am mb!<BR>Auguroni giorno mb uao non of si =
is.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01C703EE.DD7105A0--

------=_NextPart_000_000A_01C703EE.DD7105A0
Content-Type: image/gif;
	name="film.gif"
Content-Transfer-Encoding: base64
Content-ID: <000901c703ab$cf4dc5a0$dad69bca@lc14>

R0lGODlhvAHIAYf2AAgFAHUOAAB5AHFxAAAAe3oAcwB/hLu6xLHnzZfM5DslBWgjAHUjDZIjALcq
AN0RCAM0AC48CkVNDlo7DYtNCKE1CsA9AN9NCQ5qAB5RAE1pAGJeAIJWAJNkALVSB+hcAAOHACZ3
DUeDBVeCCIiBCJ12DMyECtiIAAegACWlDjykAW6XAIqaAKmuBrOgA+WtAA24CxLEAEmyAVPGAIHK
CJbFCMbFANvCAAnlBiDqAEPqBF/uAHzRAKjSALvoA+beAggAMSkAODcARWYDQncLRa0AM7wOOeQA
NQomNR4iSEwjSmgmMYglSp4oQLMlSessNwE8Rhg/STVNN2kzNoA5QKlNTbFNO+g+QgxVOStXSEZp
PltWSnNjAJlRNLVnS9pcQACGQi1/MzeLQGWAOHiMO6qFQb5zTuOCQgiWOxOfMTqtO2ujSYukRKen
Qs6tOOKoNA2+RirOSDzCRWbGNYG9MZXBTMnOMe3ASQDcMRrrNErbMlPlQ4viPJzhQ7jRSODpTgMO
fh8Ai0oAhGsKg3cFcZIAdsQAduwAfQkTcigUeUwTeW0Wi3Iqja4lcsoZhuEigg05eSs/dUY9g140
hHFDeK5BfLs8f+Y7cgBUeilXh0NVc2FsdnNUhZ5jd8JseN1gcwCChSSEh0p6el2CiY5/jaWKirl2
etJyjQCUgS2ufjSeeGCecoCkgpOVgrKrhOWWcwjHhhW6hEjCflWzdYrAe5a5i8C/jeXMjgDecSnY
fkXugmHRc3bVdJ3tfrvUiNvVcQAAtR4Hvz0AyG0Lu3UEwKoAucAAytUBywAcwBwVwjolt1QXzYAU
zp8kurQdt9gksgBCsRw0xklEw15FxIZLuqNAzLNDyNVIsQBtsi1iskRmzWttwYhcsahZv7Jkw+lf
tQ2MwSZxwjeAs192soyMsaiHuLR1vdV9xACcyRibzUqcwVmSzn+szpmhxs2otOGrtA3BzRPBvkHM
vFu2uozGuJq/zv//7ZKRsniFiPoCBgD4APb7BgMA+f8A/wD////3/yH5BADbsDoALAAAAAC8AcgB
Bwj/AO0JHEiwoMGDCBMqXMiwYcFPDiNKnEixosWLGDNq3Mixo0d79z7a+0eypMmTKFOqXMmypcuX
MNnBnEmzps2bOHPq3Mmzp8+fQHcyfCayaFF2RpMqXcq0qUNECYU5nUrVHtGqWAcyIYg0q1JdXsOK
HUu2IACmV5vmKyuwK9u3cOPKhXsWI8xnQfPqlam3r9+/gAMLHjwYwEo1LiOmnXs0LpSyEhhLnky1
7tLFlDm6zcy5c8HHnptGwWhZYZKMmMlqCc26tWvGq42Wfk27Nm1nti3KIigoq7SLs3MLH068OO3g
xpMrX84cK/Lm0KNLnz7xuVEDBLEPxG6gu3d72gVy//feveB38Oezky8fXjx68ubji0+/nn399+fh
40+vvvz87Pu1t9988K23HX0I6neggQKOp2B/7UVoHoMSGigfgQJi+F2D+B0IYIcTWgiiQfrdBx5V
Okm43YkkusdiQtqp2OKKAGb4IY0yunjhizTqyOOOMVaokJA7+hgjjg3leKKNN9bYo4//rZgjdz0y
ySOH4QXp5JNNXjkjlCxqR1hOYZb5o4tHDgnmQUpSCWN8GSpp5Jd0drnki24iRGSXceK5Jp1Yqsmm
n3bmmaeOhnLZZKBo+mnlonW2SeNgGR2ZJpP+nSnfo08yqiecgA6qqJWYtpjoo3ty2WeWfwIJ6puD
sv9aqKMXJtqqpLKemuSskN7IqUPdOKRTmZeKmKmJvvIH5H3IasheqIBa+KCmZ7ppqYgaOjvgqgkq
2ymz2Gqaa4gbNsohodO6WiN9jY4ILZ+9ujgmTne6lyaJssJaZKevfrplvACL+ueqUlI7Z5+z3vur
l/8K7CuUCN957rgGM1wwofXaOWeRU35IaaVZ5vvhvf7uu/HFJdv7bsArJ1wwqg1DbCqSDOEqKLkk
V/vypiUqyu+/CuvscMQnn+vUsD+KTDOnJJeqasUTw9uyxQarGOGhoRK9McUL2XyzzEZ/y7CnpNaK
qJGHOv1zvEzudEpgMmtbYbj5ebu2vXTX6q2NV5f/qCyq7HrY7IABihs43umejLjdBcJZIIPqEZ40
1YUe27B/iYOZuYIIf0zd56CH/jnSopdu+ukMeY766qy37vrrsMfuVSuy12777cnp9AFBuw/Uu0C/
2/PB8MT/XrzwBQUv/PDLF69888EfnzzvxB/kPPDXK2989djzDv3zyHuPPfPATy/99L57X7325zvf
u/Tus8899L5fn3791I9vvEDz9u//SRKxA/rKdz/kPU97AySg+AqYwPct0IAFPKD6rBdB8ZGvfNGj
oAIzGL707a+BFlSgCB0IQgY+kIThAx8Eu4c/DqrwdGYQiUuksZIU2tCDBuHgAztoQhVKcIC7+yAP
/0c4xA2KEIMdDGICjVhEJU7wiAR04gcR+MQdWvGITrxhDpNowyyK738rccZNxADGxDBEGmj8Dfqk
WEUG/tCEQ/ThFoHIRShmUI5CxOH+qGg+OHpxhUXsIhP5iMQlXjGOdcQjDiEIvhcyxDq4O2Mao6jF
PPLwgO6bIxzrR74fTnF+1ONeJt24RRL+UY5+ROT51lhJLJrPfqsMpCrnN8opCpJ+UHQIJGOXk99k
8Zc9tCIhXcmQP7ZSiyeU5SVLqUdDErGPT1RkIZGpyoXocIlszKUtl2dHAtbEMGUM57xYyE1OXvCZ
O3xjLpm5RvilcpEa7OYeERnPJlZznRc8Jwpd6f/IZdYTkPs0pykDekOagFOcCBUMMem50IY6lJT+
RKAll/lCQu6TedfE5gK3KUuLNpSg10QlJUeaTntmdCYHTahKW6IRPno0eevDpj4Tssr2QROL8LOf
HWmZP53+E5echKhGx/e9ouqvk6DsqE09mL2b3m+pupTILkdHpkhaVTgvSWlWy+iPlZLuqmB1jUu0
ChOyDqarCoVbWNdaFa+WxKyCQatbb8LWuh5trnAFjFxVate++tUp/pCLTlRB2MKqwh6HJchhCysQ
wxqEsYiF7EES21jKIhYhlrVsZB3r2MoaVrOfHUhnN6tZz3K2IItFLWkVC9nQqla0r0WtZE1LWsn/
jta1n13sbFlLWNiOZK7AHRMOeOLbxr42sZl9rHGLq9jLVra5yqUsaJW7XOZC97rOlW5Cktvc6WrX
ucblbnivW1rwgre85jUvcrtL3fSqd7nB3ckY4us58S53vQrBb37Py9/oWre037Xuf/1b3famN7Xs
va+B+SteABN4stgdL2wdXOAC45e+GFZrRuyb3QpTF70JvmyAQzzd2JZ4wQ4ecWwPzOLvUri4CJ4w
hFULYg6LOMQwNrB+/9qRcITDIKTLbG6rO1ry7pbICnavi2XL2SOjN7QpPjJ2cxvj8M62syVW8ZMf
rOPoYhnKUuZuYjMcFAPE18cm2QiHdyzg8r5Y/79VRjKLj7vgAdPYw1O+c4K3nGU71znOedazhKH7
ZCwXxQU8toePfxzkCLPZw25+rKEHLdpJt9nPK1Zyf2dc4TjHONJZLrJ7IT1qC3MZ0Cr+MP/IzGqg
hKPRdt4xhdcs6Mhm2tPtPXGm37vpLhPat0uWMbBXXGPyYpbYpn7zfgvS6mb7RM2O3ixtmTztaAv5
1rWtbZVtjOfbRpi5J7YtoVvr7UBjdrdFBrBtv3zaNve2uH5ItFG+Ku96U+R/6HD2/+zNb7EAYKr9
Toi+fyKKgRu82f9OeF7nVYGD02s4ogg4QRaBOoUDXOIYz7hXEq7xVTv84yAnyQpCTvL+9UAvHf9P
uezuwJpkCLwlTfCqN0pO85rPCxCsxsaYVN5XBaScFzwPOkXgIXSNq4M6dKjKFYr+ukEwfSp6gI7P
rwqap1t9INww3cWDbnOVHGGu7ei6vv+tEhqKndV9+PjCz852wZC97eG8BE/SfvC1w/3uQHk73h1O
d8H8ISh237vgcaL3wQ/mEHrpO8IN/xdFKELsgaf530Oe9iK0OvKM18njM4/QBnCeJAjpQ2i2jhEq
lE4RV2fdShT/Pz6U9fNkTkNL+EESM8Oe1ZYoI+tpkoO8xEElmL+98IdP5tyQPisOEM7xUy+ZAoRu
+X1VOPOl8wLT/5YwMyC+wRWu/b704/MLOYf/Z0wQcBosRPrTH8s6ikLvrKgkdSlJP226z9exvH8h
95d/a+gPFP13hh8MAYDRIYD+dxDo9xoEmID2wA8MyIAC0YAACIEEuIAQuIADkYANSIEZOIEaGIEO
+IAfqIEGIYEWeIEdyIETmIEPuIIUoYIneIEuyIIlaIEkqIAkCIMfqIAzKBeJcBB5IFZkAn0dkX8J
IQ/ygBI6SIMFwYEyaIJLOIMo+IROSBBJKIBWKIUwOIVMmIJOeIUTkYQ7yIRaaIJbWIJiCIVmSIXX
x39lhBwcZw8c928CcYByCIdvaBl1URdEiBAkYYRpFoFKuIOC2ISEGIhlqIZT2IVP6IWJaIiN/4iG
auiAFQiCK8iFiAiJWAiIgDiIm3iGNiiIAJgSmkBfpAB3wYGHcDiHqoiKA3EWrOiKrehxAIR/JXGE
oKeJZuiCMbiFu/iIk4iCIciIlRiCOOiFm8iJjdiJZDiMWCiDYDiGuNiBlziJ0FiGgGECbDhWBoGK
ebiKsWiHsKiKqRgce3gQ74eLwpiJI7iO6QiKCGGMi4iM0/iMmFiJziiNhziGhRiPyhiPgwiCOeiO
2RhOqUgQ3CiO4TiO3oiQBVmQ5Qhk8YeO+3iPzWiPhBiFB8GIOpiOGEmRlwiJGhmGGZmIljiNStiO
/RiJUsiFNnEMA/kTc3iHddiN4/iG4NiQrP8ojg/JbPGHiTXYi0tYgVW4gUJJlDkYjMFIkkJpkhXZ
ixspie9IjKCogiWJgRtIhr/ojvf4kmAEHBSBHDtJEGEZO2dYOgKoF4RQd8HHUs5RHfpXlqADl6Jz
gByBEsrwPzHAlTqxlno5fHw5ExUhhKzzCmEhmAUYSYYJF2nwOYl5mNNhEzXwl305E23QEo5wEpI5
mZoJmF85F+1gOy8gjo5pb41pVdcgEqVxGqPJY6XpOlOwmsxHeJs5m7TpVXbwP5lZm7q5mywxXBoG
m8CZcbw5nMQpdsF5nBhHE4iXZk0xlrSIEh5RnNLJeXcFnRbhnBPBlaugEzqgUh4wnTWkEI3/gJrn
h5zmqRCEQBnDQpflqRCzgZ0vhxIBMBDzKRDzGQD4iZ/2UJ/7uZ/5OZ/gOXi56VZ30BOkEZjtSRX8
uaD9WRD3aZ9scQbnmRCt2TqzwY1yOJM2eYei2RQP+qANShAgyp8TKhkVOhzrWYcKWZDdeJALqYc9
WRHv96EN+p8iSp/5KYsBencDSnwG+aIM6aIrOhDwyYez2J80GqL0WaM8uaN416M0xxEtypBDmpDh
eKIMQaP1SaIQuqVh9QMOwQKng6W5sZc2iZNBuqEzqZMxem89yaD2aaMM+p8AKhh14KSEIQcsAaUk
R54lKjtBsHETAXRXRaa2s5gHgah/Kjvt/3edbfoRRaoQDkcFeDqbKACTGxGpbmqddlGpnmqcmfqo
0SmqmzpwX/CpNCd3hEEaZ9qhnXEIBQGrsSqrh1CrBBFvizp9KmCkhPeNMkqqdRl/tWqr9kCsA0Gr
BAGrqLqsbnWg3nilGuqrWWF+x1qssXqt1lqtubqtjxSLa1oaNGmoEmEOySqr2qqttGquDWEMx1kJ
/mema7qQMamiOloSSXF/xpqt6Jqsa+g/xcCsAAt6Xvmj8tqQrkoWsGquCput6qqu3MoUwRJ0F/qN
MkmTZTGsCkus6SoQw7ocS/CwxNGov8qpMtSTDisRAQtG5xBfvzd8shAHwUqykGqyF5GyNv/LEv0K
cjJwszzLp2xHCXdni93nsyU3AYFBtHgnEePwsOJaFBnwGsNggGIRA/PHs/2TV6rweYDAAH6BtMJX
C1arF17LlWMbtgFath+3VzZRcHvadnogGJhgtt+EeWjLEvnweeCED7WZHBSHEG6gEbYgF/SKEE17
O4V7ET8YGpo5AMC1dnWrfVxAEo9rc1kArBaxdBjRCyC7uWyREp7QdrkgtzmRBKJbumJXCKZbnJKh
qURKEgVqeNCQupq5upYrqZ5qebIbcrQrs8KSu77rVhY3sKMqsxMLjmfxu2x3DSjheoynEYl5uAYo
kwfLuX+KNOA6pcYbk9prsJ3KqQlJpfX/undWgLxAQaldd7CuaLFXiqahSrKDm4d1WHO0QL7T2aFx
6Kvpm6ElS7zgahY5CxPj2xNESwvzS7/d1xC54J4Uy75DysBMYaX+OxalScC0oHKBpRFhYBuY+xbX
+73ox6HcKxtqmr9lkZgEnBRLKxxWQL3OyxbQ28IVQcEsbDoiS7iDe6+PCnDhxJcEbMD8dw+1O8NC
PMRDnLiywwHSUQtaR8SccQFsxZ7CO68uvI3TexFrIRBXXBH5kMUZwcULscVb/BpKsDovHBHr6acL
TBanmBEqkcVeLBFhXBVu3BC5W3gDt8bPuqIaGq1pbIetuMdSDMgqusd4KL1+DL+InJPh//sPc2wP
cbwWkDwQXnzFbgzGjnzJjkzJYWzJkYzFWDzJkozJlzzHZ5d9ailOzkqwNbm92NvANxmkqry+egyk
Qtq/rQzBIYwQnUzJmRzKb8zLogzJwNzJwezJw0wQYAzMmEzMnRENpXPDFtGq8NerEVylf6y/BVul
94u/LAqkNYnN1nyTt+zAYhl/u8zJyCzKkmzJxVzJjxzKy7zM7OzJxgzPnTyQ5ZBQeqcCO2Fxa5cR
xRvOBiukVNq/3Byu3dzAtdzN4/yKDrHL6ezLBcHFxFzRBjHHvKzMET3K9qzOxwnNzmsd1luxuBzI
fcy+FSvFCS3LiIzSKa3H8ZrQrWudFP+9yRN90RGdzOrMyZts0/T8yTUdx5ks1Fnsw281uc+WaKz7
xl9MFkVt1EetOn/K1Los1GFB1RRBBKkH0qIjlw/MxNFXuP+QDANpx1D9qUh9E/kMeWZNm4aQYWbw
qdNAE7IjzRvhfAKBCWAtbzzRcCTX1s5WCS2BBmd9e2+QeQlXcoKNpzZQ2GOX1vOy2NKpACk7pmXs
Fe6615qtHJm92atzCRPa2Z492lMRCqR9VY6d2qrdbBKgl93ZdmVgeLKQYUGw2n0ZCjdbFFtXwZy7
B6c9epetf3sw3LDjculn10w83L7dGsHtVzwB2DwhtKmr3HV3EzAQsMDB1UKs3MPR3Hb/dRPQbdsr
MdwtsQjOBtl7K1WHOwcKIaG/LRsG4Qi5gQdGEUOjCQ199Q+T0dygsFZQLQVn+7sOUQR11QRLsRl+
5d1hVRIrK979gwAgh94OPuEUvm/vfeFMLEBegQIdsdwYXhH18Nv7IBdw8OGbjQNsgQQmzhoV3uIu
bnC88OLC5wv/UIoyDnuM68PSTV+ccOMosQYpsQk+DhhKwQmcsOJIPrJ50eNhmw1D3nYSYdwsTAYK
8beOidVJnuVavuVBN+JMoRPEMBBhLhBhTgxmbub2MOZpnuZnruZsruZtXuYEEedi7uZt/uZojudz
fuZknud4DudwLuZvvuaC3ud+Tuhk//7niB7oel7OT64Tw4BQGMHoa+7miT7mll7omF4Qdn4Qfm7p
oI4Qgb7piL7nmq7pjJ7pfS7ooZ7ol746CHDhci7npf7qtX7qtd7pnO7qrV7oBjHqvP7rwa7rtE7r
nk7oxs7qle7qc87lu7sSd/l+s47sfO7rd77ngJ7ndl7tyF7nmM7t3G7o357tqb7qzd7txX7om17m
4L7s2V7ogSHZ/4AMj45yk+7uzK7st27ruX7u2J7pyb7r1r7s+S7u/N7tq67rzI7mAI/vAu/syzHt
pN7sEy/wFV/qvd7vqp7vwI7wvk7w5Y7rGE/xwj7tFj+hpuBXlE7no37tC6/od87yFP9f7Swf7o3e
8nze6Tg/8gb/8eze7gsP9BAfFzV8nDXRDXtHBKX73h5OFX8w9MVxDHVVdVD/FmCUloY3C7/7CDNR
AHgKBb5L4/U+9mRf9g7O9c2G9KL7AHNV9W7/9pKhmgMh32ORfFT8FqNgGwoO9xzhBVOx9/1W4vV2
msyn3Ve1fum3MB2XDVJKxoDP98/nOlAcFmavfRLOatxXRsURCRvhDZDPB9CB3JDPuV5dFZMf8aN/
EHUgdI+f+q6/Os3QDKPd+gLxCI/AFFbeEZxP9GIX+8gbBmIbTrZf9vLeErHfDDjRCSlhDOB5AF0L
RsMveMLw/CXn+5Uv/GgvnZffF8f/HxTMbxPfN3jbwHnRv1IhoHYgZ/3XX0blP53gRBvH//oZYftz
IQLGoW/q35fb71WE7RPZDxD/BA4kWNDgQYQJFS5k2NDhQ4gRJU5E2IziRYwZNRYEsNHjx397QI4k
WdLkSZQpVa5k2ZGlym0vZaLEl7HLTIP2dO7k2dPnT6BBhQ4lWtToUaRJlQoFsNTpU6hRpU49GoLq
VaxDcW7l2tWgy4zWvI4lW9bsWbQp87VM29btW7hx5ZoFa9LbXLx59e4dqY6vwLp2/w5+2SajDsKJ
FSesQfLuYsiRE2alXNnyTjKXNU/1ttnzZ9ChRUsmXdr06b1Uz4lm3dr1a9iiI8Wm/43V4znUuXW/
jRRp90UrK2sPJ17ceFKVvkna+j3w+HPo0aUXnz19OkadTXlq38l9uHfr4aWDL8qyd/O0TdXbW9+e
/fbu8YOCB1C/PlL6Ru3f90n+qH+m+MMPPgDn4+4+/wo0UECn1iNKO5mUQ++jqOzrTkAL4ctOPqDy
W0pBpoYCMasRf/KuxP4ORLGoFR98z8XWqhNvxhDds/HF+NzLTjsLGfSQR/6CZA/BHXnE8cghgwRy
Q/UytFHJInsCEkMGOXxPRyVPvHLL/ZjMMEktU5xyShzbWxLMHWlU8zgPrcxxyxcdRLLLNI80Uk48
h5TSyTfj1LPMP/OEU8oNmQywy/8mC5XzzRsNPRBQNwF99FFHCZ10TUyH2sYo7J5qlE4jNdwu1CId
vLNPUQuFE1EOBR1TVfkunY/AMvnU8NRLZbWzP1RDzfXCPCHESIoJB4PqU17bvBDWMLlE1U1Zm9VV
V2hVXXRXRiMNE9dsDYV1zl7DNdVbODWS4lxii8WrQit7FBJYIuPM8sp4bR21x1ijVPFdesn8MklI
7d11UXebrfRgeatEE2BJsxwXYEqbAglddePKFLYWL04q481KOrfii3pZSOM1OSb50JNTVnlllkVb
Iih+VDZFOhhatg3kR0qyCGSIeEEpMJ7b+iVooiPzuWikGYqFJS4aiqcgxJJG72j/qatuyGasseYl
66ky6ekIrpeyeuyPSDmIarLTdi5stmf0+qetncKn7awIoXs4RO7Wm6e495bODL/9piXwyvom/HCo
UHpG7YaKYPzx35zaA3HKK7f8cswz13xzzjv3/PPPGjK7JCYgN72sb05S4KV+Tnf9ddj/CrsP0Gu3
/bXYcz+NjpNcqbgOiAI3+Xbii6/83+cuMf5iOZbnia9NINpP94zEkckX6rP/yD7tFcqj++xbRt55
0EQh/3w2h0d//efoYP99+D2VjpT4ue4E8zD0Vt/zTjP9ZxzwnQ5o2uucPMJTCcpMon6pYl+niEGM
nTzwgTyRYAQpaA8JTtCCOoEg/wcxmEEMWjCDHdwJQsgQwLQNsGKt8AoHSfhCD8aQhCGM4QVrCMEZ
erCDOXweCn34Q4TQcIci7AkObUjDIobQiEgkIhNjCER13QGKD4nKED+owRwu8YY/MeISQbjBK8Jw
gXu7QxnH6BNUXOaLMMwiE8WYxC7WsIk8PCPdyniHOopmhlq0ohCPSMc49nGOPqFjHlNmRkPq8YJf
dOEeKwjGJN4QhGxcI08mkEhMLs8fmeRkJz35See5D3TiAKV4OFHHIWhuItYznROcAJkzTFGWBmGl
61w5S1xGppavu2UufcmXXcaul7qpj9TS8UtcvhI1xcyLG5AJEqzgopTfGZHCpv+pMbIo85kgYaZC
urlNcIZTegz5pjjDubjIMKc55SyJCkuyNNeJZSYGcF0CrMbOk3DPnC/BmiwSWLz9Hcua1yxKBAh6
UIQmVKELHU7/XBPQ5UG0bRKlTNUohSRC3WugHcrog+jUUaVkTKQsokyLSHWxk3K0MsoiykjcKZeL
Koil/2mQiDpn0pWtiKJZ2d5L5eIsFenLYH5imJDwVVRswatORl3Yk870rybRR6oNexefpuonUEVp
VUsi08LupVV3lWpZTYXWvvTkqlN9i0qv+pWZ1uqdgoCCIj5lCbuwRC6pUolZCAtWXkn1sEQ1DK/k
ehZIBxUswd5qqd2il6UGe9H/pAIWUoMdlGPztSpvXetZ02rsYSdrM+x8ylYz5ReafCUpXonKVEdF
raLECi6MIg+xfI2tk/7q2RPVq7VJbW1aExaw2hLMtWwlrL5Ui1rOQrZqQP1WZWu711bhNrXRPWlM
J6tZaSmWVo/dbVmtJd3hche63z1ttID7I2yldVuwFS53k5uv0kgFsgVjFqt+CzH8InVPrPVVvMjq
JX/5iGHAyqh9t5pS4/arv9Vlqn7nNC+iRtWs1hUTWD/LXxNBGFT44ux/WebQve00pKAR8WU4VmIT
1VS+L4pvRF+D4lmFZ6SbUd/+xscybTBUx5+bx2em8BMQ71ihb7kByAaEMZXS//ShmIIxjdCSriIT
hsQ2NXGS9UNSEl0ZKzW2GYLFc4PoxKI8Fznyi62M5dagqMkf6jJS0HKDKOOFEBChAUMCBeAFV+qj
H93Ta736Wn49FaxW/RKf/3RnHdkJQWdqal4RXWj1Vldeg77tahkN6PvuGVer1apOzhJnxRxLUZVO
7Gwxul3PUje8WN1togXl2hyVt6P5Me9lXY1VWo9q1a2+82XJS+rM9npca44KmC23YfLyusMVXjZV
I02k9zZ7w66KrbX8K2Ht3trA+bV2VcXVLqiG67EYVnBza2NslWHkqr8Sb6rXK+3CPqzd2m6XYiN2
aslSy9bg/W5lITvvC6eYsv/8Pm9qJeaRMVAE1EXLL7YzLe6sfjVisrXtfOvlMMoauuLXrXCmN75v
tBLMv4qOaqe3/XFME9irrD0wUl/glYUzpAoEeUCLz7xiYsuvzGzWOd10WpndFCI1MZbvRr+jH6PD
KKRJF5+SebrPnAi5eCSZwhRyqZM5SP2TfOCDVH6sdcNiDkRMTyTXPZcI4ziEhV/ZtohurJmc+1rg
PUdyiG6u6zoRvaX/4DrU+flZu7PNy5HC2vD0SpW++/3v+woqAykdKEinfGBVwrBoAX1rAkO6r25l
/H79jOmuQkmoAy43rTjN6qJWSfETWXGyeet632rp3rkG6aQEDV7fwtrf3x7/OK+pe1vMrteyA3PW
pHdvbrCv9PcCnnWEA3bt4qY0uzGt/K51317nw7v3y74Ty//96uzblrD/Tr5lrAugNuW7T9ROf6q4
f1xZa/f4yBW36yPL8fnzFvzxHyv2B1/+pPCAuZs48pg2WHM4biO/kvsq0wI39tMWlUu9RcM8jQs0
jaovArSwcJuvAtOt0MMQtskMhDox44i76do5pQNAkgkyGtuYEhSNt0tBKluTsQAHsvCd1cvBl3Ac
HTQJFdQfE/xBnyCLH+hBrsAnjIAEI+SKhNsKNriI1cmlFZAIJIyMWEIhISy8IMzCoFhCwpgE6aEr
L2yhTtoBsdtCLtSKexJD/+qpQvDBBYUAgjHMiP1gw7cIAbqwwzkcC9sxNOJ5BbJLQ9D4OnuAHX1y
HT0Ep0vgi9rpMUF8RDXMQVbYQ0o8DWM4nRmoRCMjH2yAREjUxIzAgQA6JlAsRYzIhI9IhIdIBVNs
RVdcCRx8i1pYjNeYAU+8xYuRDE+4iAJImpoYiEFojlLAiEn8i3KgiCn8iNJ5RWb8i8ZoRmiMRok4
n03BxfhZAGvUDD8IDfPJRmwiM29MvuUKR3KcinBYGRYsxyEDH3LYiXbUiXYkB3mUR3t4x3qsx3m0
R3x8x3zkCX20R3p0x3n0x4EkSID0x30MSHgESIZsSIEsyIUcyH8USHdEyP+egMiJzMd/ZMh9vMeK
fEiQhEeLjEh97EiR/EiCDEmD9MiTbEmHbEmWvEeFpEeNvMcAOkiRLEmZhMmL5EmUZMmZBAqcBMqF
rEidLEqkxEl+9MmRnEikxMefJEqozEmh5EiPdEqUVMqhlEqpxEqKPEmd5MetVMqP9Mp45MiSbMdx
fIp43MmYpMq3tMijjMmlvEqhRMi0dMu2/Im27MuerMu5dEm5BEu7jEq/dEuf8EvAHEnCxMvChMm9
NErGLMy6HMzKJMq8NMudPMyoXB/FJMmmhMisVEiSDMjKFE26fMu97EvU/MzMnEnUdMmapEy45MnV
lMnW3MzGtE3eXErNzMz/yQRM0izL2oRL4PxJ10xIpkQc7PjMuLzNu+xJ5ARN6YRM1QTKyJRO3/xL
ruTL6VRO7AzO8JzLxXzM67xOq7TO47TNgsxO4nxK4+TO6VzMvAwg3bzM+IxOxsxI8cxK/0xN8mxM
sjTPxJxPxzTM9yzOwaRNBBXM1PzPrtzPAw1L6zzQCDVQuzxK++TKmjzI2YxI8MTQnGxNEh3LhPRK
7BzKs4xNE+XPzsRIvOxHBJVIGqVJ2DTRh0zLG13R7IzMjezRAl1J6pTR15TIQpQadUxSy0lHJSWo
tWxSKIXB8YhSKp0KNBxCcmKnKv2ccMIPAenQGBVL0mxPFj3KfgRTyUzT/xEFUuoEUaw80x1NT+VE
09IEUBkd0hvN0RNNyaJ0SjgVzQ+F0RcNSsEMTNYIxKw4htaYiAzBUfxc0KoM0urMSA8dUEINTLFM
UAHly608z6a00El9zE4lT7QE1ReV1MvMy9300CPtCjccGwfd1OjEVN5EVcfczvK8TUPdTsR8Twol
UFX9VDUN1dP0yQB1TgU11uosThTFVbt01UREGtkkUpUczV8NyzHF0MOETmc1SV/tVRBt09M0zfZE
1Q7NzTWFVD291V4V08nc0/V8UOLc1ladCZfADXWRCkeVVGU1SFqNVcSkya8cV3ldVfcM2MRkUU+F
UHBdVzb91SDl1Vp9zv9lbdf+dE5DNTHvOIfVKJ59rViILVhhBVBQLc9V1U51ZdDvHFb9dFF+FdUG
jVhmDdWKvdCJZdWDJTEA4di76ZQWtdHhrNFgpUtA9Vf1DFN5vdOOfFMjXVOBNUoybdqRxc2i/VSM
FNpmxdNsrVlv/dOXhFC1XIlX/QeOxVe8GAWZ2FL+UYm6SJ2F4Ni0UdvOgYuyNQ25RRxR8hue7QlF
vVshhAPE2VusqIJFBUe/nRGrgdugUdGv3FPQNEug3Vo3hdoy5df0ZNxO7dr9PNOS9dY5JVGGDVc9
DdQdrdPYnMqwPY154BmikIGgYFz4FNmsPdUFfVQ+ldCnxNx+vcrMbdH/Cb3Z221Y2F3WAQVX/JRY
b0wIaLAzZE1V2p1YirXMztTUBy1Weg1Z3Yxekk3T461dlo3XqUVYVR1fm5RGgoiK5q3Q5/xQ9W3Q
MVVY1ZxN69VLM5XPg21IqaVaIfXT9u3Nlv3LqHXXhM3ZW2zO7A3R7uxfFD1PH31ddAVLGL3el/VR
iHXZA+5cBMZeAh5VzJRP70xd8/0H9M3eN+1P6NVgWbVcCeVfetVe56XZmX3UBk5a7wTYlZ3flO1M
QbBGn2XYUc3fHx1UoMVMpdXMYR3e3iXU3fXTcnVacQ3fag1RHcVf0zXMpQzhtTlcLfYfw93i6xgL
Ddim5S0NXyhj3VEE/yyuROxJY4nYhYhIgxz04uewBRozGRWQ46IgAQDUAuMogkNBVDwO5DwOigRo
EECeJo1wWzZeZMgQZEeGjpkwA02M1pTggB6MA0aWCCrI5JFQAU5OCSIgC0qYCGr4ZFM+ZVRO5aTp
AKJ5hJy5CEpW5YMIBVkeCVeG5ZF4ZKDQBS125UfgOaqoZWH+iFuOiFgeZmQ2iWJ+iGMuCF2GivyJ
0l9GQZUxw2e+RYhC5kZI5iOcCXiACF14iByAjCPgZomQpwlp5mtuG09Qk1K4HIHAQ3Oe57wIAXlm
CSig55foBLlYY8bpCXvOQvrRulXIpIAeo0JaZ85JCHvWZ0alZH0YG/+hm4g6szmgOGij+ISmc8Hj
uVJIrIWjaIiG5plmJg0bbIiSduioKwqM9pstdAOFNp6W1h+gaAXOeZuYBg2rEJ6c3psBKFxELMUJ
mAlMKBreSQk1UYWezsJG8AlC4GUsRQ8HeIlhYOSqxgl6SpqlziNo2GqvRqiZOAWVHuurlol5WN2x
9ogSGGbNOOuzzhp4+OqrKAHCYQm3Tmu8zmu9zoup3mvXkZA9hEO04AOWeBqcIGwshoB7TuNXNgvD
FogN+I2K9uu8iMIJiYfHNkJLkKVXOAmNYQDxiIfzCYVHbghg6J7MpmxOPiG5SG2pIQDVzmI14YGn
aIHXEG25VqW2QAdX1MDs2IYLQ0ANUSAb19YeJfzthpjsiYgaU74H546depgQNYGCcnRu56aRDLAH
KqiMl6ERdwgN5P4I676HrdCGV9zqLIiK8W5SRxiOKkCH3L4HbxTA1ggIADs=

------=_NextPart_000_000A_01C703EE.DD7105A0--



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 kA8MkGZA011412; Wed, 8 Nov 2006 15:46:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8MkGGY011411; Wed, 8 Nov 2006 15:46:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.ttu.edu (echion.net.ttu.edu [129.118.1.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8MkDCT011401 for <[e-mail]>; Wed, 8 Nov 2006 15:46:15 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.ttu.edu ([129.118.1.167]) by mx1.ttu.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 16:46:03 -0600
Received: from [129.118.55.99] ([129.118.55.99]) by smtp.ttu.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 16:46:03 -0600
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Cc: pkix <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Alan Sill <[e-mail]>
Subject: List invitation: OGSA-AuthN-BoF for grid services authentication issues
Date: Wed, 8 Nov 2006 16:46:13 -0600
To: [e-mail], [e-mail]
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 08 Nov 2006 22:46:03.0247 (UTC) FILETIME=[AB4877F0:01C70387]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is the last in a series of messages intended to announce a
requested Birds-of-a-Feather  session (BoF) at the Open Grid Forum
OGF-19 meeting for discussion of Open Grid Services Architecture
Authentication topics and activities.  The list and its associated
BoF are intended to carry out the steps for formation of an OGSA-
AuthN work group.  This message is being sent out widely to call your
attention to the existence of a mailing list specific to this purpose.

You may subscribe to the [e-mail] mailing list by
sending a message to me or to David Groep <[e-mail]> , or by
visiting the following page:

http://www.ogf.org/mailman/listinfo/ogsa-authn-bof

Your participation is appreciated.  This announcement will be sent to
several relevant lists and people to extend the invitation as broadly
as possible, but subsequent communication about the BoF will proceed
through the above list.  Subscription to the above list will be your
method to ensure involvement in this process.

Best,

Alan Sill, Ph.D
TIGRE Senior Scientist
High Performance Computing Center
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: [e-mail]   ph. 806-742-4350  fax [phone]  :
====================================================================


--
   ogsa-authz-wg mailing list
   [e-mail]
   http://www.ogf.org/mailman/listinfo/ogsa-authz-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 kA8J2vIp089452; Wed, 8 Nov 2006 12:02:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA8J2v1D089451; Wed, 8 Nov 2006 12:02:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA8J2u6V089444 for <[e-mail]>; Wed, 8 Nov 2006 12:02:56 -0700 (MST) (envelope-from [e-mail])
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 kA8J1ToO013654; Wed, 8 Nov 2006 14:01:30 -0500
Received: from [129.6.222.26] ([129.6.222.26]) by postmark.nist.gov (8.13.7/8.13.7) with ESMTP id kA8J1CGj017377; Wed, 8 Nov 2006 14:01:13 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 08 Nov 2006 11:01:12 -0800
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: =?GB2312?B?1dQgw/Q=?= <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: The definition of OtherName in 3280bis differs with X.509?
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 8bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
I do not understand ASN.1 well enough to answer the question below, but
someone else on the PKIX mail list may be able to respond.<br>
<br>
I can say, however, that the ASN.1 for OtherName in 3280bis is the same
as the ASN.1 for OtherName in RFC 2459 (January 1999) and RFC 3280
(April 2002), so if it in an error it is a very old error.<br>
<br>
Dave<br>
<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
 cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>The difinition of OtherName in 3280bis differs with X.509?</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Wed, 08 Nov 2006 14:23:38 +0800</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>ÕÔ Ãô <a class="moz-txt-link-rfc2396E" href="mailto:[e-mail]">&lt;[e-mail]&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>Hello David:
   In rfc3280bis,Setion 4.2.1.6:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
    Setion A.2
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

AnotherName ::= SEQUENCE {
    type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }

But in X.509(2005),Setion 4.2.1.6:
GeneralName ::= CHOICE {
 otherName [0] INSTANCE OF OTHER-NAME, 
 rfc822Name [1] IA5String,
 dNSName [2] IA5String,
 x400Address [3] ORAddress,
 directoryName [4] Name,
 ediPartyName [5] EDIPartyName,
 uniformResourceIdentifier [6] IA5String,
 iPAddress [7] OCTET STRING,
 registeredID [8] OBJECT IDENTIFIER }
OTHER-NAME ::= TYPE-IDENTIFIER
In X.681(2002),Annex A:
A.2 The TYPE-IDENTIFIER information object class is defined as:
TYPE-IDENTIFIER ::= CLASS
{
 &amp;id OBJECT IDENTIFIER UNIQUE,
 &amp;Type
}
WITH SYNTAX {&amp;Type IDENTIFIED BY &amp;id}
X.681(2002),Annex C The instance-of type:
C.7 The associated sequence type shall be:
SEQUENCE
{
 type-id &lt;DefinedObjectClass&gt;.&amp;id,
 value [0] &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular 
"DefinedObjectClass" used in the "InstanceOfType" notation.

So,INSTANCE OF OTHER-NAME associated sequence type shall be:
OtherName ::= SEQUENCE {
       type-id    OBJECT IDENTIFIER,
       value      [0] EXPLICIT ANY DEFINED BY type-id }
But,this is associated sequence type,not the encoding rules.The definition 
of BER/DER is in X690.
In X690(2002),Setion 8.16 Encoding of an instance-of value
8.16.1 The encoding of the instance-of type shall be the BER encoding of 
the following
sequence type with the value as specified in 8.16.2:
[UNIVERSAL 8] IMPLICIT SEQUENCE
{
  type-id &lt;DefinedObjectClass&gt;.&amp;id,
  value [0] EXPLICIT &lt;DefinedObjectClass&gt;.&amp;Type
}
where "&lt;DefinedObjectClass&gt;" is replaced by the particular 
"DefinedObjectClass" used in the
"InstanceOfType" notation.
  So,I think the definition of OtherName in the '88 ASN.1 syntax should 
be:
OtherName ::= [UNIVERSAL 8] IMPLICIT SEQUENCE {
   type-id    OBJECT IDENTIFIER,
    value      [0] EXPLICIT ANY DEFINED BY type-id }
  
  Because the tag of otherName is IMPLICIT,the encode value of GeneralName 
in rfc3280bis is identical of X.509.

                          
                   zhaomin

</pre>
</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 kA81AS9J083155; Tue, 7 Nov 2006 18:10:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA81ASGl083154; Tue, 7 Nov 2006 18:10:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA81AQBQ083129 for <[e-mail]>; Tue, 7 Nov 2006 18:10:27 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 01:10:20 +0000
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: Wanted - presentations for the PKIX meeting
Date: Wed, 8 Nov 2006 01:10:20 -0000
Message-ID: <[e-mail]>
In-Reply-To: <p06230901c176ab291249@[128.89.89.106]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Wanted - presentations for the PKIX meeting
Thread-Index: AccCvhN8mWWLaBuTQZqzvOYVo05fjQAFA3pQ
References: <p06230901c176ab291249@[128.89.89.106]>
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 08 Nov 2006 01:10:20.0256 (UTC) FILETIME=[A8D97600:01C702D2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kA81ARBQ083149
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All of you that are listed to hold presentations during the PKIX
meeting:
http://www3.ietf.org/proceedings/06nov/agenda/pkix.txt

Please provide me with presentation material prior to the meeting so I
can post it on the materials page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67

Thank you.

Stefan Santesson
Senior Program Manager
Windows Security, Standards




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 kA7LWCYm064538; Tue, 7 Nov 2006 14:32:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7LWCSF064537; Tue, 7 Nov 2006 14:32:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 kA7LWAjW064531 for <[e-mail]>; Tue, 7 Nov 2006 14:32:11 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.67.141]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1GhYY8-000451-6E for [e-mail]; Tue, 07 Nov 2006 16:32:05 -0500
Mime-Version: 1.0
Message-Id: <p06230901c176ab291249@[128.89.89.106]>
Date: Tue, 7 Nov 2006 16:32:00 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: close of last call for 3280bis
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We are long past the two-week WG last call time frame for 3280bis.

The list is essentially quiet re the document.

Hence I am declaring WG last call closed.

The authors should run I-D nits on the latest rev of this document in 
preparation for submissioon to the IESG.

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 kA7HfgGl042367; Tue, 7 Nov 2006 10:41:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA7HfgOs042366; Tue, 7 Nov 2006 10:41:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA7HfeLv042359 for <[e-mail]>; Tue, 7 Nov 2006 10:41:41 -0700 (MST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id kA7HfXqa022752 for <[e-mail]>; Tue, 7 Nov 2006 12:41:33 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id kA7HfXHR020239 for <[e-mail]>; Tue, 7 Nov 2006 12:41:33 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id kA7HfXuQ020236 for [e-mail]; Tue, 7 Nov 2006 12:41:33 -0500
Received: from 129.6.222.204 ([129.6.222.204])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Tue,  7 Nov 2006 12:41:33 -0500
Message-ID: <[e-mail]>
Date: Tue,  7 Nov 2006 12:41:33 -0500
From: [e-mail]
To: [e-mail]
Subject: Quick Survey on Algorithm OIDs in subject public key info
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 129.6.222.204
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I would like to conduct a *very* quick and dirty survey of CA and PKI client 
implementations.   I need to determine which algorithm OIDs are currently or 
soon to be supported in real implementations.  The ECC Design team is converging 
on a proposal, but we need to determine whether it is consistent with real 
implementations.

If possible, I need this information before tomorrow's PKIX meeting!  Rather 
than clog up the list, please send email to me directly.  I will summarize the 
results.

Here's what I need: please identify the implementation, including whether it is 
a client or CA.  If the information applies to an upcoming release, please give 
me a projected release date (quarter or year is fine).

For CAs:
Can your implementation assert the following Algorithm OIDs and the associated 
parameters in subject public key info of certificates?
-- from RFC 4055 --
id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }
-- from RFC 3279 --
id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 
   }
-- from ANSI X9.62-2005/X9.63-2006 and ecc-pkalgs-03 --
id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 
   }

If the CA supports id-ecPublicKeyRestricted, please summarize the types of 
restrictions that can be imposed.

For clients:
Can your implementation process intermediate and end certificates containing the 
following slgorithm OIDs and the associated parameters in subject public key 
info field of certificates?
-- from RFC 4055 --
id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }
-- from RFC 3279 --
id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) 
   }
-- from ANSI X9.62-2005/X9.63-2006 and ecc-pkalgs-03 --
id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) 
   }

If the client supports id-ecPublicKeyRestricted, please summarize the types of 
restrictions that can be recognized and enforced.

Thanks!

Tim Polk



Received: from BSN-61-100-153.dial-up.dsl.siol.net (BSN-61-100-153.dial-up.dsl.siol.net [86.61.100.153]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA77Nq2L046175 for <[e-mail]>; Tue, 7 Nov 2006 00:23:56 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c7023d$ace2e500$99643d56@breda>
From: "UK" <[e-mail]>
To: [e-mail]
Subject: DVD Authoring Capture
Date: 	Tue, 7 Nov 2006 08:23:52 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C70246.0EA74D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0008_01C70246.0EA74D00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0009_01C70246.0EA74D00"


------=_NextPart_001_0009_01C70246.0EA74D00
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


Click here in Supports virtually all formats?
Devices including Sony. Downloads Support Affiliates.
Projects just or recompile them get.
Limits or text message video learn a about Copy buy presents.
Audio Converter or Recorder cd Grabber Creator Music in Disc dvd. Buy is =
presents in project ultimate deal is.
Affiliates Press Room in Contact us is. Cdrrw of Dvdr Dvdrw Dvdram Layer =
is using flexible convenient.
File mix clips trim. Dvdr Dvdrw Dvdram Layer using flexible convenient =
menu.
Special Offers Animated Tutorials Help of Audio. Other portable players =
of Create wide range.
Dvr Creative zen Vision phones a capable playback more.
Mp inc wmv a! Converter Recorder a cd Grabber in Creator. For home =
editing. Videos exciting Dvds no Time.
Dvr Creative zen Vision phones a capable playback more.
Click here Supports. Music Disc dvd.
Get rid in what can do is.
With effects upload your handheld Very handy of.
Introduces advanced timeline storyboard be surprised by of is =
Evaluation!
No Time limits is feature? Devices including Sony.
Faq is how to is Special Offers.
Organize or present photos digital show Apply insert or tracks it.
Them of get rid what of can do Direct ipod. Organize or present photos =
digital show Apply insert or tracks it.
Ultimate deal products price or today money Each day.
------=_NextPart_001_0009_01C70246.0EA74D00
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Enhance" hspace=3D0=20
src=3D"cid:000701c7023d$ace2e500$99643d56@breda" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Click here in Supports =
virtually all=20
formats?<BR>Devices including Sony. Downloads Support =
Affiliates.<BR>Projects=20
just or recompile them get.<BR>Limits or text message video learn a =
about Copy=20
buy presents.<BR>Audio Converter or Recorder cd Grabber Creator Music in =
Disc=20
dvd. Buy is presents in project ultimate deal is.<BR>Affiliates Press =
Room in=20
Contact us is. Cdrrw of Dvdr Dvdrw Dvdram Layer is using flexible=20
convenient.<BR>File mix clips trim. Dvdr Dvdrw Dvdram Layer using =
flexible=20
convenient menu.<BR>Special Offers Animated Tutorials Help of Audio. =
Other=20
portable players of Create wide range.<BR>Dvr Creative zen Vision phones =
a=20
capable playback more.<BR>Mp inc wmv a! Converter Recorder a cd Grabber =
in=20
Creator. For home editing. Videos exciting Dvds no Time.<BR>Dvr Creative =
zen=20
Vision phones a capable playback more.<BR>Click here Supports. Music =
Disc=20
dvd.<BR>Get rid in what can do is.<BR>With effects upload your handheld =
Very=20
handy of.<BR>Introduces advanced timeline storyboard be surprised by of =
is=20
Evaluation!<BR>No Time limits is feature? Devices including Sony.<BR>Faq =
is how=20
to is Special Offers.<BR>Organize or present photos digital show Apply =
insert or=20
tracks it.<BR>Them of get rid what of can do Direct ipod. Organize or =
present=20
photos digital show Apply insert or tracks it.<BR>Ultimate deal products =
price=20
or today money Each day.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0009_01C70246.0EA74D00--

------=_NextPart_000_0008_01C70246.0EA74D00
Content-Type: image/gif;
	name="language.gif"
Content-Transfer-Encoding: base64
Content-ID: <000701c7023d$ace2e500$99643d56@breda>

R0lGODlh9AGIAYf/AAoDBIIDAAByDoSHCAAAenEAdgpxib7NwMrgzq/B+0QXAFwWDokrCakaALMe
ANYUAAs2AxtACzQ8BVI9AIlGAKxDBrNOANcxBwRfACVdADZRAllYAIhSAK1hBLZiANtUAgB3AC2E
AEiOAGh9AXmKAJaDDM2DAOJ7AAWVCi2lADiiDmahAIakAJKcC86YDN+TAATKABe3ADzJAFLFAI7L
BpfJAMbLAOKyCgjdCRLmDTvgCVLVDonVAJ7lAsrnCOzUAwAAPy0DSTgEMWcHP44CSaAFSMcAM+EJ
PgopOyIbNEEpRmctNXMZPJcgM70UQNYiPABDQxs2SkI8TF9ON4ZJR6Y8NMI3ROwyQwFaOiVRNz1Z
NVtkSIRqAJxrNr1XQexuNQCGNhyDRUp6PVOHM4WARZd1Ts6NNdVxSAmXMhqYSTWpTFKqQn+gPpaZ
TMqbQ+CXMwbMNyvAQUC9QmS3O429RJuySM69Md3FPgDuQSTeNELlRWfVN4nnOqHVO7LZPtXgNwAM
fRMAfDsJhlgEeYMHiKQAec4Ae+AAhgAtfxgYjTwnhmUWfYodfZoggMcmedwfhABFdydDgztLimk5
gYI6fJo4gsdLhOJMegVZeiBWgExTeFpmf3hpdZ9hcrRhfNdajgB9iyVxikuGeWiDfIxzipp6i8OC
du14eQCkeiqYdD+rc1eigYWaf6aWdMeYheKkgwi5fSq+ikO8eVe4c4CxiquzebvLgdOxigDThBTc
czrTeGbtiHzZeZvhd83Ud9/qiwAAyigJtkgAwFgAs4QAu6gGwrsBv9QAtgAruysTwEIhwWgVy4ko
tZMizMAgyuIqwwRFsys9uDM0x1U2wYFGxKE9tcZBs+1EugBZwChRtz9dzW5RtnNhxK1kybJbx9Nb
uwCFtid7y0lytlV4v4txwqpyxbd/w+t+xwWauyWguT6bvVGktIOkuamTtcmay+OtwAa7tiC6tkyx
uG65sn67u6rHsf7/4Z+np4CHc/QAAAD/AP//AQQA//8E/w3z////8CH5BADmzlsALAAAAAD0AYgB
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPqTNinZ8+dQIMKDfmvqNGjSJMqXcq0qdOnUKNKnUq1qtWrUn1q7YO1q9evYMOK
HUu2rNmzaNOqXctWqda2cOPKnUu3rt27ePPq3cu3r1+1QwMLHky4sGGTfxMrXsy4sePHkCNLnky5
suXLUy9i3swZ8OHPL7Od7Ey6tOnTqPFqTs26tVLQsGMrdE27tu3bkWng3s27t+/Nq//lGz7cKHHi
SI8XP7rcqfLmxo8rVV70ufToyKdTFw69+vLszL9b//eeL3l57M2tn2f6PCl47tffcw//frlsmKvu
0yQfvz36+us1pR591/1XnHrp+WdefwGS5+CC/DEYYILbDcjeePQRKB50FBZon34gwvZVfd5hF52J
JT7F4YYowsecee5xeCGBNMI3YXbdoRfeg9WlCJV8Dco3n44numhckb8laVmOPg7ppJNMxggjkOI5
1+CTVu444ZAHvlildlCeF2WUYApYXncrhtkkjEq2OdmYNyKppopBnnkll3fuyOaPcVbpp5h2rnli
goIWWqaZWKZJKJZ6uunoY0JSiCR4ZDbqIpOSLoVppXJ+1yOenwIaIY6ihnmlhVJmiWacoPJo6aOw
lv8V3HY2Akgro9r5t6mGqcYopKUblhpsihZ+uSKlGPZq46SsEltqhHqGKO1hZJEaaYFyXojtrr7u
qSmZafr45ZxwDnonqVEdu96iTRK66bp5xipvX8bWuSanhnKrLK7eesvuuIuWW6LA+AraIYCNHpgn
u/M27BfAzYabZa4QHmroq8Au/CybAvP37cUVF4lgpzd2fJYHDqcsVcni/svwjN/Cu26GGLP8cbYi
a5xvyWLSXLCr47acsactqmz0VZole2y7wWKLs4bqXuur0wbubHWt6PqsIKq5VmivrnUCeuuH05Yd
GFhjh52owgpivGCOtz4dN9RXE4zhqjJH/SuvhRb/qza0bh8t+OCEF2744YgnrjiswS3u+FJmRy75
45S/Jvnl0lauucOYp7T556B/3njopPfW+VClp2766UGp7vptrCeUxExGCWC77bXfjvtRuu+e+1O9
C8C77sD7XlTwwifVO1LGHy888rcrBX3zyzcVPPPIY5+88sQ7z/1S0Q/v/PXUb+/999iPv/z1w3f/
T/PvPz99+8bvHjtQ6oeffe7Vn299//tjSvj417/81c983pseAg3ovvgVkHsFhJ72pMc++MFPfeJz
4PoQWD4Kok+C7GNg8iwoPwky8Hf/+Mgn7rcRB/LOfwP0XQwXCD7zDfB9Trlh/DI4Pv6hkIf+Kx4F
/7enQx7OMIcktGEQl0jADF5whz5kIhN390QoRrF2U+TgAm9IxOSxUCdWTN8PD/hDJAJRiGQcY/lG
uEUtSiWJE/SgGv8XxiJmsYZWpCIN83hEOTpxj2EM5BkDSUIBevGLOBFkEGVowy5GJY2PlB8QGynH
Qg7SkOgTYyb5SEdIblKKO2QkKGXIST+isIqe/CQh24jJFCISJGApIiMd2UNQftKOHjxgAxWpx1sC
UpUXfOIsCdhA3KWSfiEUYy812D1S4nCU82NmH20pzV0G85qpCw4AkxlARZoyf3SEYQCxKcgORlKV
3uymCUvpzWricpl6DCEVEwhIBYqwjLpk4zqhyf/FQ76yJhAEp/YsKcQa1pOWdVymMll5STxqsqEP
bKcobUlQTRqTjZjsJSoZutFJ6o+hZRwiCv/5kbLA042rPGcrh+g+c5Kzou0EJg2FidGGVjOkg6Tp
7xT6PY0e9IM/xSlPl1jFOZbuICl4SCURys6Y2jSdJnTpGu/41IfW8ooWpSRLq/dOkD60mT9VYkcX
ulIX/tGXBUUKSQHayJqalY9MDefx2ufQU7b1ijO8a1UvmdeVTtOqw8RiOfeYT2r285eWHCtWh5pS
5tE1KWvdzzj1qst7DjSeuzwjZq2ZTHeis66XLWplPdvYEw4WtGbd52HlalfyRXB/ME1iMf0Z2Yz/
xHK2E5zqPg1IzLLutLMCDe03WXtZM9IVhDNt60QhqkV9vlavqIUicjnbT7RC0Jyvy652t7u6inD3
u6SprUzAS17MsBANOSmveikj3va6973wja891kvf+lpGvvjNr36FYt/++rcx+w2wgAdM4AIb+MAg
SapK/svgBjv4wRCOsIQnTOEKW/jCGM6whjfM4Q572L6N+LCIR0ziEpsYwgi+SBRWzOIVp/jFMD5w
i1kc4xrb+MY4zrGOd8zjHvv4x0AOskdOTOT/JsQdQk7yYESh5I4U+clYqS2Up1ze0VH5ypCDMZa3
zJQYc/nLao2sWD5AZqSQ+cwfSAqaywyVNRtl/81pPgqczRznpsAZzXQ+s53ZXBQ9vxnPcq7zn/vs
5j0DWs18JvShES3of8y5zYt2dKIlvRQ/B7rRhf4zphutaTrnOdGTJjRTFn3nOofaUY2ztKIzLelH
j/rRd740qTnN6FhrOtKeHvStVR1qNtu60q6+9Kdx3ephn9rYgp41sDnN62ArWynPXnWzcw3tTJda
117udKCFLWptVzvZ3S52uC19bGB/29uMVrS3yc3sOPNZ1dSGt7h1re48x7vc82Y3qGnd6mTre93T
/ra/AW7qTb863IjGtpjBUuZ935vaCa/2thH+bn6b297cljil663tXrt74BdHOKUdPvFBk1zkGf+v
d8MLbm5w+3rSfl45vT1dcY6r3OAaR/nGde6m4Mh85t32eMghXnN64zviJU+6sYEe9HZT3OInF3XU
n77zqpf71C/f+bF/znVaZ73oCS861lnOc6t7HeTZHjnIJy70ZSOd3QCfStshXmulNz3iFYd6wQ0+
dbP73eZ0v/vGt+7uPgs+11mvOts/rnOwX33tSWezlL/ieKcr/vKy3vusWX30wI/d0IEfvOV/LXB4
V/7tZO+3vO0u+sMjPuaMx3vsCS/4z49b73aHucUdd/rXIx30qq+15aMyd9Yr3fZtZ/Wyba/14Vd+
9aFPvNpDLvaz3x7zzW/9738+9OJjv02r+XX/8ofvlMTrXuSdz7319xz92C++7K6XNtiN7mrpD13X
Naf99TEvfe4/3P4z53/bh3MTN3ldUWrut39Md3DZR3/Gd3/zBni/F4HiNn4L6IC7BmjnJ3+wd4GA
14G3BoFNt2kJSGxm93IkuG34NnXp9yiasYH7lnoUKGfclnf0J4NPMXZ7l4PttoM2B4IzeINAZ39w
934SmHFFuGoi2Hw+eIL8FoNNKG/QZ4QeWBReBoOkd22vZm3+VoIoqHyhp3rpp4ORpoUn2H0A+IXR
5npTKIaQF4TYB4UBh27HJ4c6yINluH4x9nnBJn+QNofqpntpZoY5J3zE94TE5mwpOIFgqHZ5/yhx
gmhoG0iHFyiIk3iEimd6JtiGIWh8kqdlYBaKBhiKpFiKpniKqmERqIhlAnYNTWZj1PCK97GKtEg4
shg7TnCLKVaLvGg0uviLwBiMwjiMA9aLxtgwxJiMysgSx9iMjLOM0PhKEMBCzliN4BeN2JiNHGGN
3NiN3vhk2hiO4jiO5FiOAiYH5piO6riO7Dgt3/iO8BiP8jiP9OgV7XiP+JiP+riP/NiPP2YaCGEU
ASmP/ugQAHkQAomQBLmO9VgW/NAaDzliqwEAFAkAcmGRRoGRUaaQrmQQ/8APIPmQIQmSHzmSH3kU
EYmSKRmSScGSRTGSEWmSL0mSL4mSJZmSM/9JkjBpk0Yhkia5kj2JFDjpkjdJk0WpkjQpk0LJkkTZ
lEzRlE7ZkQU5Gxo5FxSZkfbIkQiBk0FZkzzplSrZlVwZk2BZlmBJlkGJlif5lUuZlkLZlWtZlkAJ
l3H5ljU5l3S5lmiplnapl3D5kOzoFVWZkVf5DxVpmBhZkRpZmIpZFIt5FBaZmI6ZmFdZmIiJlVfB
lWfZl3Xpl54plmY5lm85lJ6pmZp5l6g5micpmqH5l0/pll7Jl6UZm0ohmnh5mhl2EYNpmFgpmbz5
mL2JmZGJFJJZlcPJm7/pmMoplQSRkB5JlHEpk6TJkzFplD1plErpkrZpk1GJlKwpkkeJmuD/+ZWs
GZ1PqZ3diZ4riZ21OZrQCZhTuRC7+Zi+eZzIeZjAaZ/LeZmIeZzFeZhHMZDMORDkmZfTeZ1J2Zmr
mZfcqZpuiZcMepbj2aATupkFapYFCqGqCZQa2pq3OaAzgQIo0GPIiZnJeZ8l6p8pqpyDaZwoWp8l
upwCKqDm2Zp0SZqyuZevWaM4aqERWpcVKp6deaAHqqCbOZemOZufSZtMap43IaL7BRaN2Z/L+Z+W
iZ8mOp+QOZkqep+MiRVKGZ0/yZRM2aBymZZjap3vqZ1/SabvyZ3ZyaBjaZ1DuqZJGZXSCZuryaY5
iaBFuhciSmG7+RSDWmK4WRqHWheBijhW/yYVhcoUjyoWM8qRm5Oom5GSMQGl8bmpPTaiB9aQoBqq
ojqqpEqKnHqqqJqqDuEKqoo/pfqqsBqrKdOqtFqrtioRuRAbHnCrvNqrvvqrwNqcbDGpHtkVwXqs
jWoWxFoQWYmszhoRVxGpMQqi82WFlGoVz5qtSjWlUCGtg7mszXkI4noI/zCuRmGuRUGuzqmttSqY
VuGtX6Gu55qu9Fqu9SqrtdiivVmZlHmlXzqtUyGv9aquBHuv+CqRqgigJwqj9BmcyAmuBIqu6Fqu
4jqv68quGMuswomiL+qwJ3qxBGqtxUqv5CqvJWuxIpuxKisQW7qwVbqiDfuwWkmpJ2uvNv9bsCC7
suzKrSv6ogoLoL4JsQIxrjhrryZLsRWrs/1oCQlhFtJ6sFDbqE9bFUJbrRuptKcKtUmCC1rbtV7b
GVMrL2H7tZvBs/sppcRJnPipsC+7r5bZsvwZt/O5mHQLnCzKtnJrooRptx8Ls2dLtoqhm3pLFTQ6
pW8bo4PKt/bZogzLokrhr/tJmR5rnC6qpVUasw77mOVIBjfmro7rn4zJt5A6rfo6uJG7paLLsSqa
uMmpn63ruBvrt3D7ubCbuaYLuH0huHdbu6qbssI6mWkLmaFbuojbsy1bn8N5uMnbty6rnzBquvpa
nABrtxaJte1luB7bn996rW9bqC6apaj/i7dtW7ln27ioS5jFq72z+7eL67rGW73WCyKeC77fe7tL
sbh6W7/Gy7zB65uw+73Py7G167/7C77Fa7nBi7uoQbz9yqV/e78/+6VAq7zC+6+PG7pwS8EZfKXh
y8EGnBQ/28HUa78KPDhj2xQnHCspXMJwkaxUy71hscJuopHxO4pkQaNSUcMFRpFmw8IkZras4cJf
gcNRocP4VZH7pZgy/MA4XLfoS61G/E9ILGAPTBW7Wbhsq6JRHFmKiUho+8Sgi8H8ObXu26U+bBpL
nBoTCcJjbLvAicX9q5xbPMfVSrn4e7eVCVncO8K8Sce/+sUde7r1O7bLG7tnfGJrvLeI/zvBzyug
hjvBvrvFYXCrVhnDhyyKquioh9tlMPwUfhzFtUHErvHJsXHJpgwVFQEMVrsXaczJI2sbpCwiXSG+
dWG5rczGVRwVmxytmrzLpwxgFkHAdoHASHMQqavJlZzLYWY2JKC0nku3ikylVDq8ctuvdSu5l9nA
6qvMGQy8r8u+kYul2Ly2heylCYy/x/zLlhHCfRuz0hvI6Jy/gfyxwjy6DIu5sUuf5tuzXWrH/vvO
6gy2KYql9Puy95zHA+zAAH3HjuqlCM27XPrPA23B5suzmAvQAZ0XukvAg9y7+yy7zZvQ+bnMzGrG
B5zA9FzAsmvSBW3QkUyO4tC5syyc1P8szRV9uXf8yO8MtIZMqBVMuriM087Lr5H50HZcwddMwhk9
F0IcXtfq01Nxy4Acy6ChOoTsy3Eh1UstqVTd1V791WAd1jgmGVq91RU2FAAg1toKGWVt1mcRAKAT
FGmt1mvdGG3t1qF613jdkHqNFrSw11PW14AtYTgx13Qti7Hgx8IgG/Nw2I7NEY392JJ9EZE92U0N
q/Mw2Jq92ZyttZb92RPR2SwM2qStVKJdOJAACaetwKmt2o5T2kDW2pCQZKt9w4TR2kBW22PxGbjN
Y7rN1aAx2zv222GRtV5BDMiN3EWR3MptFMxNDEcB3UyR3MvN3Erx3NX93NpN3dmt3c7/3dxJgd1I
wd3fTd3bDd7RTd7Lnd7Qjd7/IN3ifd3o7d3yLd3rHd3v7d3xPd3j7d7qnd/2nd34PeDeGODvfeDO
neAKjuD8zeD3veDrbeDj7RQGDt7u7eD2beHwPeEQ3t8E3t4D7t8OPuL5/d0PvhQafuIHLuEYPt3z
veAZDuMyTuIsDmUXweIBHuMz3uA13uEqzuEN3uESXuEqvuFBHt78neMRjt89LuQ/DuQPruM4TuAo
7uRETuQMbuQDbtxYMeU7nuUU/uRU7uNjjuRkjuUJPuVNXuNr3uIrzuRhjuRtbuZSft1lDuRXPuFY
HuNe/o3qreQnruNB/t/szd7WTeZU/97ngf7k8H3hJC7mS67gWt7obG7n9H3mUd7d5n3nH67nnh7i
aQ7giA6OmVzdmm7ogH7kpu7ikP7oiW7nqI7p6Q3lH87dgj7pRT7klt4UfQ7ijH7ovG7lnw7jyu3r
CC7dXB4Wxp7qqV7lsJ7kwR7tjE7r027mYq7rAG7hmf7oaA7nqp7pgt7pcT7ixh7pmF7n9Fju4R7u
z07tw97u8N7t1+7ubh7v237s3k7tez7ui87uiy7teZ7vP47r8Rjwks7hTY7vY27w8G7tq17i9J7i
5M7pEG/u963lpi7vFd/cCS/xEK7orv7vYH7vXo7uW6YZ4q3rKr/fop7tOH7o203xv/9e6S5e4cDe
6tle5KJu86eO4i/+FISO4frt8OWt4TZ/9O1O3sjOqcTttZfd9J7M9FA/9VRf9VYPXrCd9beIZFrf
9V7/9WAf9mI/9mTvXlcvYdVwX2W/9mwfE6jQ9nCvjWcPq3Ff93Yfv3Of93rPYXfv2Ay2DHt/GX1/
2IFf+IYfOoJ9+IFNy4p/jEDc+I7P+EdBDZC/ilgtK6V+1oMPE1/RmBF8zJ//0NoLzXtb1Izszw4c
0aQPs6Kf1PKsxO8b0ZV/Frqbz20bx0B9ux48uN5ruwCbt/w80hecvbH/qJvP+TN9vOP7uLdfvrgs
zMR7zr2L+877v79v/VpayMQ8+3n/wcjR/PuhX77s7MTbLM2ln/rlj7zUv7Dd+7khXM7szP19Af8q
ndKzO7eb7L7yTLsPjL0ADBD/BAIA8K+gQIMIEw4seFBhw4QOEUpUWNHiRYwZNW7k2NHjR5AhRY4k
WdLkSZQm7a1k2dLly5UPFx6kOfBizYUTZe60KZMiz5wQZ1aUKNQhzp5HgQr1GdEiTphRpU6lWtXq
VaxZtW7l2tXrV7BhxVI9SZBgT6c2zRbVubahWYNrc0aEGxeu3Id1lbqdy/Qt06B10dIVrJTh2cEp
FS9m3NjxY8iRJU+mXNnyZcyZNW/m3NkzZLCfRY8WOdb0adSpVa9m3do1a9KxZc+m/13bduPXuVve
5t3b92/gwYWDDD3X+E+PgIcDXb75LOLRyJtz1l29rFOI2Y/fvWkco2DNbImCxHuZb8bzZeUiRd/e
feKn8POSlM4xfePy36d3Lgwd/PHu6ttJQMnEY04jAilLMMGQKGJPv5H82+hBohhkzMKSMMRwv4rA
0u7DtBJDbMSZahLvKJpGJFGtElM8bKkUoZvwJhXfOgzFG9H6qSgZvevPL7uYc+svFp+T8S8HhwoS
OyTjazGuiUx8Ekq7kszLPymrDOpALG1cEqLqdEvJSp2eWlFKtnosjEUdt1wxKR8HLLNCA+c0is2+
tgyRJ8NuBNJA5bRUci+cdtQTzv8/C50TzkGHIhE5IKN8885J8ZQUUTnV2pDDzIziLsY4UTyzLVIH
w4tMJb2DkM9GDeMOUycPBdBSV8fLdC87x+szMDfL3FVQRdcr9dJdyWyyzywDfJXRPTmd7U5Sk/UV
vj+HrdPUTFN9r81gS4000EOvxTVXbG+1dilZ0zw33aYcZfVEdt9lFdYA0e3V2djKA9XTQF01EtQc
edz3SL1yVNXMGhlt8kVkV11y0RcjXo/gV0XFFrxIyy143YsVfs7XhIsVNqmPJf1V0C/PfBNfllse
U6RNXZb5OvlmtvlmyzaNGWeeEZSwZ6CDFnpooos2+mikk1aatDCbdvppqKOWemr/qqu22qWls9Z6
a64/uvprsMMWe2yyyzYb667TVnvtpM92+22445Z7brrrtvtuvPPW2262+/b7b8ADF3xwwhnb+3DE
E1d88aYLd/xxyC2yZjLGK7f8cswz13xzzjv3XO7IQy8cGdFLN/3026oZ/HPWW3f9dddQl3122mu3
/fbQYdd9d957nwp34IMXfnjiizf+eOSTV3555osurnmgfZeebuiDnv56uKuPHnvuy9a+5+7DF/sE
i8gnv6LzBTph/fPZdx/999WPP6P51Vdoffj/cT99hPhn//7/6Y9/+pNfAC/iv/rtD38HXKD80AfA
BhYQggJ8YP8MeL7qPEF8G6TK/wAJ6MH2+Y+AGhHhCO3HwPv1z4QRpGAJ7efCCJpvgOar4APTB0OO
NHCBLAxhCinowBPyEIhBFAgHjTg1EJpQhUpcIv1s6MPyOfGGK/xgDWnYRA9WUYVZjOIUsZjDCl6R
iAe04gt9yEUMHlGNXDlJEt2IES420YxypOMT51jFGW7xjHBUohhJSMUv/rGLfWRiHUfYPkLGMY5Z
WwTzwKJA/L2Rgfur4SGheMlBEhGRLtTiGKMISAOS0YsnFCAlMTnHKaKRjJakoiKLuEZYYqWNmUzh
Df+3yFLqsH6nDOQmX5jAXlowkkucYRa9aEpS8pGWviygH4lJSmbmMpnf09ojaf+pRzs68ZOFnCYE
d/hFNM4PkdkcZyWbWU5OrpKcd8RmGKHJzjHGUp6ukeQea7kRY/KSm6AEpzIByUQ/OrObx4QiLgGa
zCvm8aCe1KJCETJPiEZllu7EoghxmU9exvCg+cToM4fYSQc6dJrOLCf9bDnSHhLzpAz9oUb3Sc3H
JbGZ5QsgJM05UDjWNJv33OYvEfhNAJ6zpyD16S6FickYhrKUEyymNw0JU6hG9XZKkKpFnldVfEVU
q6bBasu2+tWrdvV7YIWaWM16VsWEFa2OJKvT1vpWuHrEmkgtKCRtCdRTmhKZuUynN+3KQoTu1aZ5
XaowS9pNCVqwkn91owKFytf/ji5UsZcMpUiPaligttWtJrFoQQvZ1HbSMY84DCQ+KbvOoL4Upyvs
7E11+dF99lWgG81faEc5WZVO1rL/pGhcG5NKOQp0t5+9KSER+tTF0vW2LB0qK7kpU7qCVJV1nG1k
j0tanrJ0lNBdrWrXGhrgXren041uco+L2PEq15CzJaxzXVtcGvb1vNnNqDpJ+txErnK5kg2kZhs3
0U629rST3Gti54tdQc73jhx1rF91GtvBrte55CXuYCtrX9p+Mry95S5x0QtX8L7znyKl8Id3mEBg
ghGzZcTvRTUMzVsOlaMeTe9OUYhf3sb2mR2trjlL6N8wpUSMAd2lfD0sxeAm/1nFIl5xi01L0XqK
VpQ0Ni99kazhIvszmp61Lol9+5ghG5e/ONanbZXsXQWTVqYu5rCNj8xQ9soWzUQdcXHzy98eD/jL
GSkOD5ebTo12eLS9Za46Fzro1LLZnj+E52dXCloZL1q9ia6yj1PKaBNL2YdAto6QKy1mp775sVEu
KmAVDE8ZorjAjf3pYSEM6BJL85wnrqlgPy3anxqaprs16J59/WtgB1vYy1PrsG/HaWQnW9nLZnaz
nd06Y0db2tOmdrWtfW1sZ1vbj3l2t73NuG2H+9jfJne57yZudKdbrOFQN9HM/W54v63d86Z3ve1N
uXjnW9/75ne/YScaYtxb4KwDJ/jNDHAzfye8cs1QeMMd7uyCR1ziEyfJLyh+cYxnXOMb53jHO/Jw
kIdc5CMnuWo8fnKvllzlK7cHyl3OKZbHXOYzp7m+X347VjhuE5fBnCx8/nOg1/x6DxB6aoAe9KL7
2xiZuzngZMAybnBtg7u4WiCSfnWsZ13rW+c65pr+dbCH/XRdJ3uyxX52dGMD7Wtne9vd7htyvF3u
Ly973e1+d7znXe9753vfsRcQADs=

------=_NextPart_000_0008_01C70246.0EA74D00--



Received: from anscoinc.com ([89.152.18.245]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id kA6KjtLM072435 for <[e-mail]>; Mon, 6 Nov 2006 13:46:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000001c6fdb9$ef2711d0$a8b9a8c0@exaxho>
Reply-To: "Itziar Wuensche" <[e-mail]>
From: "Itziar Wuensche" <[e-mail]>
To: [e-mail]
Subject: Re: 482
Date: Wed, 1 Nov 2006 05:30:44 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6FD76.E103D1D0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6FD76.E103D1D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tenor?


Cheap VlAfGRA http://www.kiloppasdetionjdedas.com

=20
=20
hot I dropped the polpettone into the glowing ashes.


------=_NextPart_000_0001_01C6FD76.E103D1D0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> Tenor?<BR></DIV>
<H1>Cheap VlAfGRA <A =
href=3D"http://www.kiloppasdetionjdedas.com">http://www.kiloppasdetionjde=
das.com</A></H1>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>hot I dropped the polpettone into the glowing =
ashes.<BR></DIV></BODY></HTML>
------=_NextPart_000_0001_01C6FD76.E103D1D0--





Received: from host148-239.pool8289.interbusiness.it (host148-239.pool8289.interbusiness.it [82.89.239.148]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6HOnia046549 for <[e-mail]>; Mon, 6 Nov 2006 10:24:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001001c701c8$4d8d6eb0$94ef5952@computer>
From: "launch" <[e-mail]>
To: [e-mail]
Subject: band wagonU Konamis
Date: 	Mon, 6 Nov 2006 18:23:40 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C701D0.AF51D6B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000C_01C701D0.AF51D6B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000D_01C701D0.AF51D6B0"


------=_NextPart_001_000D_01C701D0.AF51D6B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Ion Storm Deus am Thief consulting Eidos! Clients saves database or =
databases.
Fifteen twenty factoring objectives messing round?
Formats Partagez sonores.
Motion sensing or thinking deets.
Anonymous Reader perfect or spouse timethe authors am. Slowdown peak or =
battles bonus Ninetynine.
And landing Earth am Munk at showmay shockthe of. Supporting quotdev =
kitsquot hardware thq ceo Farrell Sopranos Mick. Eis Officer of Football =
Foundation. Logical am way immersive games health energy visual.
Shunt traffic pathwhich a twisted. Heck of scant mix heats reallife =
drills sessions heats continents.
Folks Kelly Jones am excellent etc.
Reasons thedelay sound requested addnew depth.
Fairly idiotic thing am given rate.
Folks Kelly Jones am excellent etc.
Angle worry ball a moves position Baseball grip bat a swat. Vanilla =
anymore defend is themselves anyway or truly piece Cody book!
See all is fa Emeditor macros crossword in puzzles or brochures personal =
or.
Message Boardenter Shopping Rentalsadd a Gameq or Stats Publisher =
Developer Date.  Threeway Fifa heck scant mix heats reallife is drills =
sessions?
Wed ear surgeons hands lucky few lucking is August. Freebie paidfor am =
gamesimon Edinburgh am comes gamea.
Beats watching spincycle youll able? Clients saves database or =
databases.
Texture hasty judge Vivendi adapting trying autoaim! Gundam Royaltales =
Radiant Golfjo Nintendos q is.
Consumers format although freebie. Gundam Royaltales Radiant Golfjo =
Nintendos q is.
Completely mindless wears thinner fan.
------=_NextPart_001_000D_01C701D0.AF51D6B0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"reap" hspace=3D0=20
src=3D"cid:000b01c701c8$4d8d6eb0$94ef5952@computer" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Ion Storm Deus am Thief =
consulting=20
Eidos! Clients saves database or databases.<BR>Fifteen twenty factoring=20
objectives messing round?<BR>Formats Partagez sonores.<BR>Motion sensing =
or=20
thinking deets.<BR>Anonymous Reader perfect or spouse timethe authors =
am.=20
Slowdown peak or battles bonus Ninetynine.<BR>And landing Earth am Munk =
at=20
showmay shockthe of. Supporting quotdev kitsquot hardware thq ceo =
Farrell=20
Sopranos Mick. Eis Officer of Football Foundation. Logical am way =
immersive=20
games health energy visual.<BR>Shunt traffic pathwhich a twisted. Heck =
of scant=20
mix heats reallife drills sessions heats continents.<BR>Folks Kelly =
Jones am=20
excellent etc.<BR>Reasons thedelay sound requested addnew =
depth.<BR>Fairly=20
idiotic thing am given rate.<BR>Folks Kelly Jones am excellent =
etc.<BR>Angle=20
worry ball a moves position Baseball grip bat a swat. Vanilla anymore =
defend is=20
themselves anyway or truly piece Cody book!<BR>See all is fa Emeditor =
macros=20
crossword in puzzles or brochures personal or.<BR>Message Boardenter =
Shopping=20
Rentalsadd a Gameq or Stats Publisher Developer Date.  Threeway Fifa =
heck scant=20
mix heats reallife is drills sessions?<BR>Wed ear surgeons hands lucky =
few=20
lucking is August. Freebie paidfor am gamesimon Edinburgh am comes=20
gamea.<BR>Beats watching spincycle youll able? Clients saves database or =

databases.<BR>Texture hasty judge Vivendi adapting trying autoaim! =
Gundam=20
Royaltales Radiant Golfjo Nintendos q is.<BR>Consumers format although =
freebie.=20
Gundam Royaltales Radiant Golfjo Nintendos q is.<BR>Completely mindless =
wears=20
thinner fan.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000D_01C701D0.AF51D6B0--

------=_NextPart_000_000C_01C701D0.AF51D6B0
Content-Type: image/gif;
	name="Scrolls.gif"
Content-Transfer-Encoding: base64
Content-ID: <000b01c701c8$4d8d6eb0$94ef5952@computer>

R0lGODlh1AF8AYf/AAUCAHwNAAF2A455AAAAiXQCgQyOecq4xLziuqbH40ItC1otAIMoAKMaA7Yb
AN8XAAAxBRg+ADg4AFo9CIw1AJM+AMo6AOwxAABuACpRAEdiBmZnAI1fDJ1kALRhAOBeCgR0ABqL
AE1xDm56BHl+AKt+ALZ1ANmEAACeBimVDDScAG6tB4WtAJGqC8ScANaoBAC1ABHHADG+AWy+AH62
AJ+3CcK6DerHAAjXAR3lAE3UAGnbB4XfB6zeDcPmA9nbAAAAPCsAPUUIS1MMTHoAP5IAQ74FO9oM
MgARPBUROjQlQmUkQ4kmR6UbSsYpReQtRQZEPxs7OkQ4NG1KRolCMakxQ7ZNN989MQBaSClTMkRo
P1JoQoZnAKhRMbRZMd5rPwB4OiOHND6LRWWOPIaJQaWLSLN+RuKDMgiqOR2fPzySOGmnQXKiSZyb
QM6mQdqaNArGQRqxPTm8NF+5P4m7Rpi7O8KyOOLERQDpQyneMjzfSmLrSYLeOZfrOrPiQevsPwwI
gSEFfToMeGsAfnEFiKENcrQJh+EMjA0UgiQRckQgcm0kinQufJcogbgUiO0chQZFix8zeD9MeFVE
eXpNe6g+g75OgOpCiQBrfxRRiUNofmpUdoFlhaNrjrRtfulUcwB8jBh6ekuJhV6Hf4x6h5eLi7uF
f+N5gAyhhSiXc0argWigd3WVfqCqdb+TfOajiwDOfSq+gDqzgli0iHi2hZK/drTFdOvEcgfbdh7X
eUvWi1nojHzdcafUi7PkjuvXjgAMsigAxDMHvmUAzXMByZIOyLYAwdIIsQwgtSonzDclslUVynIY
wKgUuswmvdUezAU5zBFCxzg+vWdNxYM5uqE9zcNAxtRLvw1lwiNfyUBoxmRmx3xguKBUv85TwdFq
wQt5tyWKuD50uWSAuXx/vZR7v8iMttGKyAKSxyuavUmXyFGSwHSdwK2ewMuVs9eZywC6xhLDvjfJ
v1bFxIDJzJ/Oy//58aymn42NivsAAAz/AP//DQAI//UD/wD//////yH5BADuxi0ALAAAAADUAXwB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX
MGPKnElTo72bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evVmuK
HUu2rNmzaCGCXcu2rdu3cOPKnUu3rt27ePPq3eszrd+/gAMLHkyRr+HDiBMrXpyUsOPHkCNLZomK
seXLmDNrZju5s+fPoEOLHk26tOnTDvegXs26tevXsGPLjr25tu3buHP3nc27t+/IShDqHk68uPHj
yJMrX87c3u/n0KMLbp5cF/Xr2LNr3869u/fv4MOL/x9Pvvx36ejTq5dpvr3791Mzwp9/e/1Z+vg1
K/Ri/2X+/5b1B5JTH+hUYE4H4vRBgjct6OCDCEJoD4MI+vQggxQqOOGFDu6UYYMbchhihwpy+GGD
EpZIIoo8LThiihe2aGKBJ9Jooocxqmhgjj3xOGGPL5J4IoBfYfijhkjWiKOBR3oo444gtsikhUAq
WWGUQbl4pZYlsrjkkBQO2SSWTIqJ5JljcolmlxF6WSaVRDIlX4I0rnmglVc6KaWeU+JJJp9v7nmm
mWvmueWYP9Yp6FBhVilUo2gSWuiRilYI5k0CktVkpZD6iaihoH6qoadiKknqpIBOKWWlILIaKlCQ
Ov8paaybEnXpnYHumalHT9FZa6SLivpnobcC+SqqrtqJqqqpWoolrp5myayz0io7LJyr/pnssnF2
5auvwKYK5owZFhtsqeQG6aKRKvp47buJPtvqjSEyuuOM6pbrLriPUslvovRK2i1WuEbJ7rW0Tkus
v8Zya2qPKcJ7rLDxtjpqlmqe62i14aYZMbysfovtwEfJV/HJ+Yo7cqjmqrzyxYIm3HCzMJ+87cwu
y9qvqv+yzPChlzq3a00WFz1suQojS7PR05a6MaAH/xR0tsAKTDGiD3M8qNJJM00pxQcOzRFUnKbZ
LNLBTvphwTmn7bW1V0+8NshxT4z101LzGbXaeyL/fTPJcGXM5alQUkuz4D1/6jTVZ0vc5pZhsq2z
xnkf+zeoUWcsKuII/2014FXRSjiOQuIc4Yrtan61qTfOjS/EqL8od8qyw9q1jSLei3rsucOuJuu5
fw46phgNbzxcMxHS2vHMLxdBtyY3Lz1XYtM0/fVUVT8g9tx3b1j03odfsvZjiW++UeSXb48A7LN/
U/vt5wS/+zgJIFT89cMPFP3566/T/PLrif3m5z/5EZB/6yvgTghYv58AsIEBjKAEJ/jA9wkwgQr8
n/0WuEH8bXCBGMSfBkW4wfR15CkftGAK1wfBFq7QJylc4QshGMP/5U+DFuSJDIfyQgQmUIc2ZKEO
/2XYwQDWEIQS9CH9ZsjCHQ7xiTn8IQiJOEEhMvF8TmGiE4XoQh628H5R5GIUZ1hEIFYRhkgMohpz
qEUzcnGAX6ziB8kYRiOu0Y54fKMYVWjGK17RfBlpYxLV+MdBEqWMdUTkFC94RkbG8YxOpCMj56hH
R1Lygm3cog13eEkrbrKPaBSaCW3SFEF20ZBB6WQqUVlJIJqyjqF85COPuEdY0rCBqlykLPnoyjve
ko2n5CQmY4nFqYgwjLQUYyG/eExHvrGCfqxlIr3YSFgy0JbR1GMuP7nLJg6zm4gM5yl5icRmSrOY
UfFgBitoSzcaMJtjDGI0X3nONLazlpF0pzzjWf/PaX5zihkkZCtVSUl6khCdOgEfLuOYy2XeU5oH
VCQ5dWnPfsqRmNaEaCzhOFFn1pOjFP1jQceZT3r+cpTWo6gyKUhNj2YUnx89pyYd6MtZqhScC+2o
Puf5z5gyc5zAlCQoRckREqB0Ir1kZSv3R9OKenKf5fSoQ2HqVJiadKUjZWpNJZrTXcJzm3AUakWP
KpN8QjWCU22oPrs6Riq+tJpOVaJYn8pBHN7QgKu0612p2sO1kvSJbt3jJclavCwWkI6IveYI++dD
r4awsex8X2QfWs3JMpZ/B3xnYwULxiGaU7Fz9akHMTlZdk4VoahNrWpXy9rWuva1sI2tbGe7FoX/
0va2SIkObnfL2976dnjgC0AAdCLc4g43J8YVblCSe5PkHre5zMXJc33i3OIi17jU5cl0o9vcngzX
udTlLnGnaw/wepe85v2JeMkr3Z0o173bxW57tete717XuvMl7nnfe9/nHle3UDnudsebX+hmF7nl
1W93EbzgobCXvwamL4PLi14B2xe99p3wfAd83fomuMAf1m6FI6zgDsOXxBGGMIgpLGEVv5e9IdYw
h0vMPAuv+MMwznGG84vhBgvlwRL2MI9bfGEaazjGC57xkW3sYyQfOclOBjKGmczg7wq5vUB2coh7
bGQc77jGPtaxlsV85S2XGMYHvnGTh7xmLBf5/8lNzrKSQUxlLnfZzUiWsn6t/GY7QxnBaPYynPX8
ZePNGM18LrOW80xnNRc60JCOcaQRzeggx3nClA5zoy2950sr2L/dnbSnq9zpDPt5zVaWb5sBd+g3
K5rCdlbynIFyakcnetEJpvSsC5zlBmda0rxOc31BvWImW1jUmj4zoNNMbEV/t9XNg/awCz1eAasa
uvh1NKcjLWxc3xrQ14ZvtmWs5mZvOdx3DjWmhZzoby+bzeRW947N/WR3U9k78qnuvfH86mmPutbd
5vajs6trbdMb1tHNtL59rV6Cf5rdZkb2hst8bGaX29+kJipZo9zmfeO61MkO+Y/T/XGA59rV3v9e
sofJLGc4r/rkGY+3vOnb415DWeAw53TOJ67x3jyl5SvXOcrNvG6i2FzbHA86zdMda6Ur++EuHzOq
k05kp/O72II2sruxfnTwZKTgJs7zr/8cc547+MRhp7aLD75vMpsd5CQGu8vX3vGub3jEY7b7i/F+
9Subm9iEHYiuxYtwFYubvzpOfHqFXviRi3jc2M622zu+6GeHW+5RX6/aha15nY+d8EhHeLU5DODf
mv70qE99d2yr+t8G/vWwj/1gEED72tu+9rLPve79AlsjtP73wA++8IdP/OIbPyiFOL7yl1+X3Tv/
+dCPvvSnT/3qW//62M++9rfP/e57//uyZ77/+M8D/vKbX/bOOL/618/+9pdk/PCPv/znT//6K8f9
+Pe+/fdfnPzHxBz+F4ACOICQwX8GmBusFyAHERTCcYBFAX620YA/IYGAAw7DYYHEQ1hQAQAcCABe
4YE4AYJxAQ4kaIElSIL2cIImmBMYyIItWII7AYM3oYIzKIMpiIIzyII32II1iII0iBM8aIInmIJA
WIQ6CIQ4uINJOIRIiINMqBNDaINS6BNSOIXGIx8i+BUcGIJysoBAgRA8aIREeIQ5CIUvWIZGiIFh
GIZjOIZB6IZiiIZmWIRrKIZvaIdk2IZQSIdxqIdw+IdsiIZqiIfgl4UhuIX20IGJCIIdKIKI/9iI
N+GIOeGBjBiJjLiFiLiIXNhzAsGABxGIZ5iHdQiIe/iHfViHbziIfriKOTiIbLiCK0iGo9iGgSiI
tFiGo6iKqliKfGiLCrEI1eMUhpiIXFiJxCiJxbiJlKgTlZiFy0iMxxiJ0jgVNkiLMniHadiDMbiE
VbiLraiDVuiCSYiLRPiEsOiHoYiHcmiGThiO18iN6ZiH5ViNtYhOwyiJxviM0KiIyKiP06iJi/iM
zaiIWZGOs4iO17iKsciK3wiODhmP62iHC8mHE3mLstiHFwmRD9mLrIiK6gg6WMiMybiP0BiNJkmS
huiMKDmN/giNFNgTFGiQvKiHqbiOukiFtv9Ik6Z4kKKokOWIjhcZh7V4hqH4iqRoiuSYlLcoEcew
HhtIkFDJkgHpiJi4iSVplftYlSQZkP8IFU9ojTAYhWHpkHJIlGI5jvSYkIIYll+ZiuaIkWs4jgiJ
lu+4hD24iwsphE7YhE2IjYCTgEIxjEEhmFHxkjxhmHFSj5uBga/XFoTpE4+5fIqJGZMJIAR4mZiZ
mZrJGw7YmZ7JHdbxmaI5mqRZmqZ5mqg5Ppu5mhuXmq75miTTBuLHmrRZm7Z5m6ixFYh5Gbh5mbrp
hbXRm4GhB/8gBpLBFpF5lbBJJGIgBt4BiUORnMmJF5BIkFzZlct5PdPJE9K5GCkplVuZndj/853S
yI+XmIlRqZx6QZ75iJ3iOR5YiJ5b2YwjaZIguJtuAZXoKZ84IZzVJxX0OZ8lqY8tqRjLiI9Y6Vtu
IH4B2p4IWp7uaRgCCZ7b+Z7akRHQ+Y8Oap3peZ/AKRfQ+aDHqIgOkQP+qYFVUaEWuqJIoaIsOpqA
iT4fqhf4SRQKUQ0nilIvuqOnWQA8ih0ZmqDNQQE6QaQ8YaQUYKQ/Sh0YKqQ2OqN5IRxJmqQ3QaU7
QaVIyok56n0IKpCPiIw1ShcIQaRKWqVXag9kaqZbmnvCWIwBSqHEYaU4UaZoaqZZuqT5EaL1OZXI
Iad1mhNTOqVmiqf4QZ4nqZwuuhhpOqh//2qnjEqoydGkk6iMX2qMYToXYyqoVWqlZYqkRrqm5/cU
lyoXDUinD/h6dACq02OqkBoeoPqqs9GqsioUsFqrtnqruJqrurqrvJp9rTUEsxqpvdp+5ZApwXqs
yJqsyrqsuzGszuoYzBqt0kqoMdqFBsGbz7p+jZiok5pQUBoXVEmVGZit5hehRTGMo6qF1mmfWkqu
R7WBk9ig+mmJ5noXBTqh1JEL0wqvIvmII0mgiZGJcLqvROKMWjmgfMqtc8Gf4UmweaqMCAuhVqmw
+XmoxuiwD3uI/hii/qqeecGxX6oU2oCxCngRLUqr3woX2+mu4dcV67oZFEuyw1Gt2Hqt4/9KEBHI
srwnsz9Ksx8IFRKYrt9TEtGgsybbFC+LnDtxsVaRDzjhtEiRD1LrtFDrFFNbtcXBDvwnqTEbFffY
GMCJEFWLtURBtmS7FGOLskZ7H0iroeFqiecJkOZ5iHAbrpdIr3HLp/UaFGlrD1J7E1Trt0+bE2Yb
uFA7tYCLuIn7t4MLuILruH3Ls8jJnxv7rxLboAiLjJebuRCrFIH7uFSbtmeruId7uIMruo27uKbr
uIJ7tpJ7qhdBoPzYrexau5Q4uxKblRMqooYYtAv4uVf7uJDrE8Cbup/buqkrvMdrulC7tmjRpg2r
kptru1fJuyt5kgDrsWULuoTbva47vMr/e7riy7rku7zg+7pr0Y+VCrdw2p5cqb7ra58d27BRS7h/
a7Y7Ebzn67eM27f6q7pPq7jCi7649b1QYcDES8Bge7QIGLYp2xMIzBQCvL396bwWfMEYnMHlp8Ar
qsEenBIcHMIiTHwfDBiXAKsjnMIqjHol3MIu/MIwHMMyPMMXgQM0fMM4nMONucI8fBML2sOwxZrY
oMNEXMRGfMS4GQtIHH1A3MRO/MRQHMVS3BQvDARL7BBT/JlXvMVc3MVe/A/c8MVizLJZ7Jk0cQVj
zJp54QBl3MZu/MZwHMfF57PLCsOva8f2wA96jBP8kBN9rMd9rBOB7MeDnMeAbMiHzMeA//zHi6zI
inzIhczIg7zIhfzIkbzHlozIe0zJmtwTjXwTmIzIeezHoJzIhDzJn3zKfLzKnGzKj1zKmBzKslzB
NQEO1PcUkwzKpBzIlVzJhrzKO+HLvcwToazLxqzLvHzMngzMuTzKwQzM0CzMxBzJpczKPtHMvhzN
x/zHgqzMu0zKo5zM2cwXhNA8GTHM1JzM4MzM3tzOw9zNzrzN3+zM46zN6EzM0KzM1PzM8SzOyLzM
88zP1vzP4DzO3MzO/kzLuOoU98zKxezN6izK+QzLm2zKEd3PuyzLrrzOB83MxYzKsbzO9BzSGE3P
I/3ODu3K73zQn7zR1SzR6rzJv3yA5//czekczxOdytoMzxPdyTv9z818zYmM0vIM0SK9z6kc0Q+9
zwMt0MbM0jZ9zfN806Nsx9g81TyN0ygtzSKt1T8dzk/t1FyN00VN1kFtzwWtz1ld0vUc1FCd1vg8
0FTdx3is0kOdz42czirt1Jrc0SVN0fLMyV4dzBr90ZYsyQYNyRnt14g9zWdN2Fud13gdyxrN0YG8
q3FSz3K82SFMx1GMwpzdrr0Z2qIdGbkgGgwt05Ot2Cm91JBs13gN2YdN2AKdy60s2QRN0Yz9ypks
2ITM232tyrDs0xLdyVQt3IOt04D90qKM1KzNW/LBy4/912Ad1z9d2UYd1kJd202d3Rf/XdYmrd09
/dvabdBF7dY5HdDnrd5rzdwj3d1VnR5uMBom/d3U7dddfdX1rdbsDdff/NbpPd1njd8ELtXhbd/i
fdExLdaD3d34Pd5KTdAFHoC4HNZjTcmNLcgkfeAWnt/B7d/WzNJDPeJd3c+tDM8j/tAHXti9bNjJ
7c7q3dBPvdTDHd4cLt0IznxKfeH9/cxJfdfuLeOQLc3c/N0yzuPwLeQaHtLTnds2zuFZvdsxHuUF
bdHbrOS3Fd38zdE9HtVH3eDrbd1mDdZGjuIG/uIwbt5y3c4JXtaPfdxhnt1ozc5gHs+w+txkfd8f
vtxELeXIreYwfuWv/dwPPuDA3dI6/33ciM3UkkzcFp3iOA7Spxzpjr3beJ7hdP2qpE3hpB1/no0b
aeyUnT7qpJ4feX3qLm3lOT3ohy7mku7meW56XTDHxUPUEO7RsQ3XC07bbf7X3BzqsseBY13i96zg
Zg7lXl7gZG7SwJ4eSwGCOE7ced7QBE7Zrx7r/rzSyx7rpa4bmQjnPX3k5t3R5G7dqo3Q1a3ZGFsD
2zERAFAQGJ3N8k7nbJ7u5e3qsF7kOdHs6GEUAjvpe57Yhp7J8d7aX17j193tigER7/7AxsHvsXcd
AqgMa6rw48ELOcvAFv+FBLjxaiuAg+7i8X7u2A7pl+zIzG3bJA/SLV7Rl+7Veu3nyv890zBv2YbO
6CHPyI584q1N6bHN8+Gc6PaM6uf+6x3P1An/5PPu5ORN87PM1vrN1+Ct88is30+v2dgd9PRu7Fe/
1pXd4knP69U95Txt214f1r6J9CHO1iVe8Pis7zee1gkt5l8N93bf4WMf1wl990LO93yt7wUe4fUO
1UTe9oAv57md6QNY50DN9hAO6VH91tJ97Hbv2oyO1YR/7yKu7fud7V4u4XnP58ve0omP3B0u9Ia/
7YhO2aSc9qkP90pv7ty+66SP1Dvf9r4e0EW/67+s9qRfzag85ope6JQ/5imP78Dv469v7x6ey65/
67Bv7Nyt5nPP/LFP3Vyu1nDO+zb/jvSW7t9cD+LGX/0NvvTar/zQb/3eve/Wl9pN7usun+F8jvoO
PvIyb9ci79Pb39w27/01DxD2BPITaI/fwYIGDxI0mJChQoQLIyZsKJHgw4YDC0qkiPEix4chKW4k
ORAkSJIYR65k2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq
VaxZtW61+c/rV7BhxY4lW9bsWbRp1a5l29btW7hxH8WlW9fuXbx59e7l29fv37f7AA8mXNjwYcSJ
/3Jl3Njx46RyIE+mXNnyZcyZNe9U3NnzZ9ChRY8mXfrrZtSpVa9mXdT0a9ixZc+m/13b9l4qt3Xv
5t3b92/gwYUPJ0689XHkyZUvZ97c+XPoN8n0LF7d+nXs2ddG597d+3fw4cWPJ1/e/Hn047WvZ9/e
PVtboNPPp1/f/n38+dG/59/f/38AAxRwQAJL0+9ABBNUcEEGG3TwQQgjlHBCCiu08EIMzbsrw/oK
9DC0Qw4pKMQRRSyRRHtCJFHFFEdMUUUTBYJRRhRHmpHGEnO8EUcaY5wxxhZfrDHHHk8ckkchgWRR
xoREhFHJHZek6McofazxyRY/1LKzK610sUkbmWQSSDDHFLPMKb3E0UcizyTzyiBZgjNIMtP8ks4v
lbxzSjTfXOlNNuOMU8QtCz3Myf8WTVT0TEbFZLNON/FEs8xFEUXU0UgFNTPRlhaVFFJMB9X00kzD
bFRPU0P1NFJDWzWrJ0s/PXHWSBWVstYjNVWVU1I9DdTWS4PN1dcuh3V0ST9R1bXUU4dEFVg+G3UO
jwnv8rXHOv0UddU0USR1TyN3rXJOPdUE98ZeO0XWxWT7lPPcdxlFd1QXXbW3r2uVPbVWaffVVdtN
K4021G0nFbRcggfmlGBuA01V1HghDtjgeyvOq112kdXYYSzhlfZHMDHe08livyX5SITH3PHgJJt0
9lZQAc0W5pElZtNinOvikL6c7d35Z6BZ2zBozHo2Wmeik1Z6sqGXZvpoqLm809z/jlvW1+piwcX2
ZDuxNXJmhw+mek6VUeZ4UivPdplIQqN2+9Cp25RX4auvlfTPPNfOFFSIyX6R7TwfHTnlNlc1nFKW
31acMF77dpdug+3mduDD71744cZZjrVdgfMuOORN2a358iwXN72vxn993OWVhSzy9WXddDbhkwGe
GOFYQc98V60F1vZbPNc9fXi9Ug83bsjxTjdsysX2VnfMe3029NBXpJRmyoHvPG+BiffeLuNZnhvt
dyXvd++5VY+4YcTvZl99Zsc/+/e7v7cfrlKVldlk1g9/9Nb8aU5KVaOV+PzluvQNcHWjQ6DW/saj
tt3vbU6jYAUteEEMZlCDG7yQ/3UAIEEQhvAsVgFACU1YQg6m8DHGSNAJT6hCGMZQhjNkkAhteMPs
0FCHOywIDn34QyAGUYgizMw8eHhEJCZRiakZYhOdaKAlRvGCT6RiFRUjRSxmUYtbvM/9PmhFMIZx
LyUU4xPn8poJAYCLaxwJ8b5YRjjGkS1klGMd7UiWN9Yxj3ccDBvpo0Y/BjKNgiTkgwBZSEQ6JRSa
OWQiX9I0FW5pj3yczVHy0aBCTZKSe+lJPjz5SZZ80pMJueRKSnlJUaZyJKkspT1YOUqKtJKUr3Ql
K2tJy1CKkpShvKUtXelIDPFCmMMkJi9+OUtkJhOWsRSILI/Jy10+0yXObCY0W/9CzVg6E5bYlGY3
vQlM/NwFm60cZzWpeUpmXjOd3ExnO91pypeU85vdPKdANvnDTsJznr9EZzS1Oc11xkSeq4wnQHnJ
zX++E5zhtAtC94nKakaToOosCDkFqs+JUtSaBHWoRCtqz3viMJ/wZCdEI3pShc5Sl83EpUcrSsuW
ojSjHN2oN9m5UAw5tKTStChGfXrMm350pi4dakrNWdN64lQ/4jyoOhPa0Zry86JFlSlVhUpSpE40
pJuU506fGlWimrSgVg3qTb2a1XRulZID7SpNf6pQsRrUqGUda0B/yk618lGbslwmS6taS7BeNaJB
/StUA/vSbAq2qknN6x19ucpllf51nmZVJUsf+1JVvjKubzVlZDELyqKWsrEhVGppTXta1KZWteoZ
bWtd671qvDaOq6VtbW2bRdnm9oa35W1vfQtD3QZXuMMl7nV+e1zNFFe5i0Nucy0zHBMuV7pRi+50
rduXgAAAOw==

------=_NextPart_000_000C_01C701D0.AF51D6B0--



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 kA6GwYRW042981; Mon, 6 Nov 2006 09:58:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kA6GwXf7042980; Mon, 6 Nov 2006 09:58:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from calamari.linagora.com (calamari.linagora.com [84.14.148.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA6GwVIs042950 for <[e-mail]>; Mon, 6 Nov 2006 09:58:32 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by calamari.linagora.com (Postfix) with ESMTP id C9E6867821 for <[e-mail]>; Mon,  6 Nov 2006 17:58:03 +0100 (CET)
Received: from calamari.linagora.com ([127.0.0.1]) by localhost (calamari.linagora.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15368-10 for <[e-mail]>; Mon, 6 Nov 2006 17:58:02 +0100 (CET)
Received: from 10.0.0.2 (unknown [192.168.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by calamari.linagora.com (Postfix) with ESMTP id AE65B6781C for <[e-mail]>; Mon,  6 Nov 2006 17:58:02 +0100 (CET)
Received: from 10.0.0.1 (proxying for 145.242.3.30) (SquirrelMail authenticated user yquenechdu) by tomate.linagora.lan with HTTP; Mon, 6 Nov 2006 17:58:22 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 6 Nov 2006 17:58:22 +0100 (CET)
Subject: [SCVP] draft 28 - Basic Validation Algorithm Error
From: "yannick quenechdu" <[e-mail]>
To: [e-mail]
Reply-To: [e-mail]
User-Agent: SquirrelMail/1.4.5 [CVS]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at linagora.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

The error is not explained, even if the heading of the error seems explicit.

3.2.4.2.2   Basic Validation Algorithm Error

 id-bvae-noValidCertPath      OBJECT IDENTIFIER ::= { id-bvae 4 }


Regards
-- 
Yannick Quenec'hdu
Architecte Sécurité/Security Architect
Tel : [phone] - Mob: [phone]
Linagora SA
"Open Minds. Open Doors. Open Source."



Received: from ip-226.net-81-220-104.nantes.rev.numericable.fr (ip-226.net-81-220-104.nantes.rev.numericable.fr [81.220.104.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA61JZqt054503 for <[e-mail]>; Sun, 5 Nov 2006 18:19:36 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c70141$9c9bb2a0$e268dc51@bburx23ggispdo>
From: "bought" <[e-mail]>
To: [e-mail]
Subject: Tragic Kids cute.
Date: 	Mon, 6 Nov 2006 02:19:31 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C70149.FE601AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0009_01C70149.FE601AA0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C70149.FE601AA0"


------=_NextPart_001_000A_01C70149.FE601AA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Refers specific part.
Chaz Spaz amchaz.
Class members or party of note another field situations am plotwise.
Murder is suggest cdwalkley cdwalkleys quirky Icehouse Fluxx is bonkers =
minds. Privacy is policy a game console Wikipedia Your continued.
Portal amne ian Earthwings slick Thinkurs am! Thread Starter try =
controls below exist or. Overall ability between am abridged some of.
Seldom hold if. Trade Memorial Exchange st am.
Center View closed pm logged in submit? Line patched dealt is lists.
Convert Burner is Imtoo rm Converter Hottest anydvd pic. Sort Order =
Ascending Descending Beginning Parent or vb code.
Ultimate zip restore arj.
Convert Burner is Imtoo rm Converter Hottest anydvd pic. Edition remixed =
replaces or envelope rather plain.
Posts Posts Last Post. Excuses balance luck satisfying cheerful norm =
point humour helped.
Forgotten passwords instantly or client Size a Klicense by Atompark.
Reports Topeka kan abortion plans state. Kernel is management in Pcmcia =
compatible.
Dantohr Crckit persia warrior Sneaky dog Sims. Chaz Spaz amchaz.
Powerpc spot Josejx. Housed casing is connector allowing device =
interface. Prize Canal Mania or Archives am June July of January =
February April or.  Et of poorly of received growing of users caused =
retailers a lose?
Travel haunted house person of wins a lay or square shape forming. =
Housed casing is connector allowing device interface.  Carnage =
supposedly gamethis edition in remixed.
------=_NextPart_001_000A_01C70149.FE601AA0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"components" hspace=3D0=20
src=3D"cid:000801c70141$9c9bb2a0$e268dc51@bburx23ggispdo" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Refers specific part.<BR>Chaz Spaz =
amchaz.<BR>Class=20
members or party of note another field situations am plotwise.<BR>Murder =
is=20
suggest cdwalkley cdwalkleys quirky Icehouse Fluxx is bonkers minds. =
Privacy is=20
policy a game console Wikipedia Your continued.<BR>Portal amne ian =
Earthwings=20
slick Thinkurs am! Thread Starter try controls below exist or. Overall =
ability=20
between am abridged some of.<BR>Seldom hold if. Trade Memorial Exchange =
st=20
am.<BR>Center View closed pm logged in submit? Line patched dealt is=20
lists.<BR>Convert Burner is Imtoo rm Converter Hottest anydvd pic. Sort =
Order=20
Ascending Descending Beginning Parent or vb code.<BR>Ultimate zip =
restore=20
arj.<BR>Convert Burner is Imtoo rm Converter Hottest anydvd pic. Edition =
remixed=20
replaces or envelope rather plain.<BR>Posts Posts Last Post. Excuses =
balance=20
luck satisfying cheerful norm point humour helped.<BR>Forgotten =
passwords=20
instantly or client Size a Klicense by Atompark.<BR>Reports Topeka kan =
abortion=20
plans state. Kernel is management in Pcmcia compatible.<BR>Dantohr =
Crckit persia=20
warrior Sneaky dog Sims. Chaz Spaz amchaz.<BR>Powerpc spot Josejx. =
Housed casing=20
is connector allowing device interface. Prize Canal Mania or Archives am =
June=20
July of January February April or.  Et of poorly of received growing of =
users=20
caused retailers a lose?<BR>Travel haunted house person of wins a lay or =
square=20
shape forming. Housed casing is connector allowing device interface.  =
Carnage=20
supposedly gamethis edition in remixed.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C70149.FE601AA0--

------=_NextPart_000_0009_01C70149.FE601AA0
Content-Type: image/gif;
	name="Tech.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c70141$9c9bb2a0$e268dc51@bburx23ggispdo>

R0lGODlhtAF8AYf2AAAEAnEABg57CnN0BQAAe4YEcgB1e7q4ybHqxqS++kcRAGQnCnomCK4dAbMu
DecaBQBJACFMC0VOAFtBCXI4DJU6AMNOCO4zAABTAB9uAEtWAGxuB3JiAKpiB7dZC9tSAwuLBBGJ
CEKHAGmMDXKOAKxxCr92AN98DQCfBBmbB0KTAGSmB3eiDp+cB7WuBNuuAAbBCyW+DkHLAGjAAHrI
AKy+Asm9ANHNBQzrABTgAEfnDV/iAIvgAZreC7nSCd3rAAAAOiAATjgIR1UHRH8ARpUAProBO+oA
NAktNSoRPE4sSlIpTXIiQpsUPrMjQdYaPABKMhQzTE4ySlQ0PXg0M6JBRbVKRtJHMgFkRBJqMz9T
O1xSNYxpAJNgPcxaTeVXRgCJPyeLSj+CM2CKRoN+RZyEOslyO+qEOACsMxGlTUihR2OVP3WmQaiU
ScqWOdSsMwC6NCHAREjDTmPLSHe8SaqzSMu3Rd/JQADYQCzdSUTeRWDRSHbqS5vpPLzmPNnoTgAA
gR4AeTIGjWABdoUIi58AgMgAh94OhQAWeycYgEYsf2wbjoMbc54gdrwSjNMVgwA7cRk5gTdOhmg8
g4tGdJVFgMdNg9hIiQ1qdx9TfkBtel9he39hg6NUcclshNhTigqDfit0hE6Ogm5ydXp5f5OMjL+H
he18cgCjiBKtdDSlh1SfgYCdg5iUdcSmi+iVegPOdhXJgUPLiFq0eXu0e6u0fbK0i+bAjQblfiDU
iDTciWLZg4LYfqbnhr/kguPbewAAxRELyEMAylEHyYIIv6YJscUBttgAuQAeuRIgyTgevlQWsokW
yp4cvsMlztIpuAkywSM/zEY8xlNFt3RCw5Y5wcI6xeM2ugNZyi5TwTpgyWpbynRnv6pns8Rmv91k
tgCItxl0sUCIuGiNvYqMwqSKtMaEtuKExQCuySyuwk6hwmCjx3qeyqObs7qiveGpuwbNxSXAvD7L
wFbFsY6yyZK3x///5pmVp3p8cv8AAAT/AP/8DQIA8v8F8ADy8P///yH5BABJnqsALAAAAAC0AXwB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix4z97IEOKHEmypEgyJlOqXMmypcuX
MGPKnEmzps2bOHPq3Mkzp8efQIMKHUq0qNGjSJMq7Mm0qdOnUKNKnUq1qlWbSrNq3cq1q9evYMOK
HUu2rNmzaC1eXcu2rdu3cOPKbZq2rt27ePPq3cu3r9+/gDfOHUy4sOHDiBObDMy4YqHGkCNLnky5
suXLAxVr3syZ56nOoEOLHk26tOnTqFOrXs269doPLxO4nk27tu3buHPr3i0Ss+/fwIMv5E28uPHb
wpMrXz75uPPn0KNLn069ekzm2LNr3869u/fvCK2L/x9PninF8uifgw+avn3x9UDdy9cN/+f8+7br
L50JW2T/kP+B9EGA9gxo4IH+IVigSQQmaKB/DBZ4oIIQlgTbhA9i6OCEKXG4YYADWnghhv95OBKJ
ITYooIQanmgiiy5SKOKDAEaI4or4hUQRiAvW6KOKPSZ4YpBDkhSikERW6GOEFia5JI5OMkhgf0cC
SKWKKXZYJJNPQgjkllASWWWXAk55ZZNf9qdfQjWVGOSUYSpJZpxzYklnnF9GuSCQcN7ZJJcVXjik
oH++1KeReoIpppwr2bknomnmiJObbgYKaKJ8ImrjpXlmmqmSec7p56NwEqqpoYrWGCqeoKK6aZKm
nv+a43mUPsmjrJhemuunovoZK6OVNqrlq5X+2iunrwrbZbAsRUrloMOuydGb1Npa6KgojomtnofO
SCKLHN5aZouMlqsqlM/eCGNLZt6o7oeHrtqrqTyqq6a0BrWJbpjiAjssrrsi+y+03nY7cKrnrlhr
o9ri6im7YDL74rbiGnuspC7RK+a3ikZ6LcUC66owlwaLDPLIKEN88MPNnspsuc4WafGoGGdMbb90
lixqgzF/3GmyEZsL8LyLJqxyyAQr26qvQ6eM48yJ1gzxwjkDzCvCjl4dNcsOX0y0pj0f7TPQB1d7
p6MyQxq11G2auXOq2s6MpdtVI/y21j3KK6HMdIf/3bHSTMvbLYg8i+ji2VDrPd55rL4ttId4W0kj
vB/bPaKGdr5rpIzg4uwlxxOPjSbHlEse4+QFP945jffiSxDbsMdOG+Oy156Y6wXZrvvuodHO++9W
4b4f8MQXb/zxyPPme/LM3yR8RyAJIL300U9PfUjWXx99S9OLlP1K2ldvPUnfY2+SAPZkP/5I6neP
/folqW9+SuVv7z375MfvPfzpn59+/eRDXwDFZ7/8yS+A7uufPZ43LQGaz4EFhKACJwi++1lQfxSU
oAPD978C4u+CFWSfBiXoQQWSsHoi9CD6IHhCDb4vhRS8nwvj18INvtCAMCyhAAXIwIPQ5IQxtOEF
/4GYvxKGkIUfjKH9gDhDlpCwhRicHxOjaEMhFnF+SjSh/5qIPxdacYU4LCIRiTiriUxxiEkkIxpf
skMQanGL/nMj/ZJ4RSwuMYpifKAd07hHGcJRjtvzIhbb6Mc8xrGHGjnjIPnIvT7OcZGQ1J8ijRhH
RxoRiZQcYwQnSEYwWrJ/U+SiBYX4RR1mEZSPRGRG/sdFTKrQJSzkIB43WD9NTvKUdcTlE2uJxw9W
8ZOo/KQnw0jJOxqTk3Ycpi9lyUNVXmR/O+QfKzmoRkcmsI5WPCYx6YhLbmrSm5l8JCHf+EhhnnKF
0uRjKV8ZyEoS0H7OfCYxmyjKcvZSfOV7oi7Pyf9Ne+6zn8o0ZzsHqpJ66lGSwPzlJk0ZzFxKESTx
FMhOlOnKDMKyoPcc50ER2stqMjSj2xRoQwPa0TmGEpDsXGgQCYpScsJueSxF5hqdiFGHalSbDy1p
I/uZRX3e8pUKrSkgb7rRYn5Tpn6EojsXGNEf+tKQo7zoR1EaUFrmUJ88zegIdcrErd7wq/7s4P76
SFSlUtGaVc0mUpsHTe1B8a0HFCEtr0nVaTIznXFtaVYBKNcEtq+tZi3mXvHKS5uK83qh5Ktd9crW
xjo2eTB9rGRTEtGKTPayK6ksZjfLWaZKpLOgfYt2QkvatYy2tKidCmRwEoAAjKS1sHWtSGLbWpb/
0BYktJUtbm8bEt2mJLewnW1sf1sS3/IWtyZxbW5/e9zX+tYey03uc6OrkuY+t7ckqW12jTtc7BY3
u8kVbnC9+1rpale8ur0udGRrXOeSd7fEnS10y4tc+dbXJdc9L3y/a1/oTpe94Z1uePvr3fYKF7zz
fW+Ci/vf/dL3wNt18H71q2D/8pfC2lWvhgm84eoAuMIJ7vCDR7xgAd+3JfnlL4LJ22H1ztfEKz5x
fQ1M4g/L2MULtq9yY4xcAdtYxzmW8YsRLGIYE3jGA2YN7X7cYhUfWcHpfTCOnRzkJ983ygHOspWD
nOIcixjJUE4yeH9c5R3L18zfJXOXfRxfI1cY/80IXm1NaOxiOD+5zlLO80vcvOUhg7jHWv6zm+mc
ZEJvGcdm5rONAYzoEJPY0Wdu86PL/OLxChk1jDP0mMXcWwxz+NN7nvSlAf1nP2+61DR+L5ZXrOkq
o7rEd74yqdOsalZHutCCHrOh5UyTVt+ax85lb3c7belRc7rR8X01npu73WLXetSrLvGwqfxrWOc5
yo32tZexi2xrA9vOkJYOcMnMbU4HGsZ8rq6oXR3mQJc32rYONm/x7N/ownvddiY3tsvt7nC3G9ws
zvW7ieya86z5wtR2d6pTbVt8q7vPADc1u7cda1ffm8nJPnWBY9zebNO3yxvvtsQfDe4P81omB/8n
OLD7De97P9zKU6a0yjUO7RGnXM9AhjjCB+5wiwu55Kf+8shjDfLpLNu9N6b3xj8+cxRHGMIZl7CF
f071b9e8wVdf+dQ7fWkKT1zYSNdw0bm+dalH/MTRdjlnGMGTZTObuuY974bnDnetM9vcu3V2vS0t
dJ+7fdrsBjiip630VxNbv4Wv+eETz2AMFzvmqY285CdP+cqPJLKWz/xLTq75zsunsqAPvehHT/rS
m/70qE+96lfP+ta7/vXbwQHs+ZKA2dv+9riHiOd3z/ve+/73wNfNPoJPfMnn/vjI92HxKa8C9CT/
+dDfCA2iT/3qW//62M++9vey/O6/Z/vgD7//+MdvmePxwvvoT7/618/++WC+NOHJrPLbb554tib+
KsE//XnSVCXPn7L/ZzvgYBsDCFH2Zw8AkIAAcBULGBINWBP6txg+BA4UOIAVSIH2cIEWKBIFyIEd
WIEkAYIgoYEjKIIZiIEjyIEn2IEliIEkGBIsaIEXmIEwWIMqCIMouII5OIM4iII8OBIzaIJCmBJC
OISepUoI6BYJ6IDOE4AlgRAsaIM0eIMpCIQfWIU2WIBRGIVTOIUx6IVSiIVWWINbKIVfaIZU2IVA
SIZhqIZg+IZciIVaiIYR9YAioYAggYdLiIB4mIcNqIB/yIRMGIh86IcLuIeFmIcGmC/yZxBx/3iF
aViGcLiGb9iGZfiFc+iGmpiCc8iFG7iBVCiJXRiHcjiKVSiJmZiJlMiGpZgRH8AYNGGHiqiIhHiI
gkiLgmiLd4iLgziLukiIPWGCoyiCZ5iFLRiCO1iEqsiJKmiEHpiDp0iDP/iJbgiJaCiGVuiDzkiM
yWiNaSiNwkiK+CGLSciLgfiAf7iE6MiLt7iHeuiLfIiIUGGNoliNxKiJoLiJzNiM/OiN2GiG+ciG
AWmKodiGBemP/ciKm3iJ10gd5yGL61iL5ZiE55iLEzmL5liOFbmLR/g6jZg7DVmPxSiN2JiKRFiK
agiK/kiKmBiCJCmSYTiSB2mMa2iSlRiNOP9pit5hE4BoiPBIkX0YjxO5jiNhh+n4i77ojkzxg8MI
gkHolPwohldIgkwZjvcoh05Zlc04jQa5hdBoj9DIg1ypg6U4lVe5gj0ok9GREPAwPDJBjiwBl/zn
hCQRgbIjjqtRgDtpFXKZEn1Jf3iJGoEpEtmwG+R3mBqRDcCxf71XmPSBmJBpEYp5fW0ZmYg0mZaZ
md+BmZrZmZ75maAZmqI5mp/FmKZ5mqiZmqqZmqTZmpixmrAZm7KZHu+3En95kR2ZGffnmj1UEz3p
Erd5m4nRk0FZnLO5G8wAExQhnCURnJdHl3ABkT8JjLnJm6cnnbSojkeJjkpZjnYZF9gpkRf/aZ0M
5JuIiJQaOZTqSZ2c0YfFeZ7HuTgTwZHouZEU2Yu9AZ1zYYsReYvVSZ76gRMbKZH9mZGkUZ8/GZ/V
sZxBqZ7p+ZtCmZ7/aRi/WaBAuYQOEQUAioTN2RPfeRobmnod6qH6CX8heno68aGHoaKbd6LgARfI
oKAyOqM0up8NipHPQQEjoaMlwaMUwKM1apgTQZQzwaKFER4/+qMgoaQkoaQ++p8uykD9+YvuSJRG
ShgIoaNAuqRNag9ayqVRWlkRaZ8S2oBXOhhIuqVeuqNc+qRhWofuiZ+GKItnOhfxx6RcKhJJmqRg
+qbcEYtFKae4yZyn8aV5uqYhYahqGqTi/4GdGlml7Nkae5qoTLqlPrqojFobtamcJXqkyoepLuGn
f8o7oJqp0iGqqDoWprqqPnGihJCqsBqr8MGqtAqBsuoDsqoUtbqrvNqrvvqrVeERVeA6CbgXhpCr
HtEUVTAfNwqs47Gs40iox5MHzqoazVqtoLGpWNGpmjGkxdod7bChqSWP2EobgCitJIGuFOqA56mu
fkmu5doa7hqopQGh94mbNzGv8boZRjmg7pmOOMqv+Iqe+4objEOOhwiMSGml3MoW5CqRyCotPHmH
6tiO8aiL9UqkkVqw1kGUGGuhDhoa/EmfHGuw83mR78iukPqTdcqX/1qlixixs0oV+jqcJf9bPNeK
GjV7szy7Ow4wedpqGvjXspwhs3VRGDv7nIw4of5ntEURi/DaFggbsE2RDyFhtTORD1prtVibE1vb
tT2LE8tJtQ6brjQxtAfRtWD7Emu7tjahti3htGihsNx5lD65su06pyoLsIVotxcriGhrEHBrD1oL
ElxLuFcrEm17uFi7tYbruI9buIlruIhLuXArt2dhnPeKkQhKoOz4sbton6DrnfMXHodbuVwLt24L
uY3buImrupMbua5LuYiLtV+hBH4KqHWLsesJjwSasptrt6Ibsm+Luo4LtqdbEqc7uLX7urFbuc1L
u8kbth8JEeKJowU6oOzYuxk5vB4bsx7/OaHLq7jk67bOC72wa7nPm76oW7mYaxYeu7IR6rllWrFJ
Kb9UqrCzGLggibyF27Yk8bXnG7m0a7ySK7tXC7nQ+75lkR+l27DkCxXmuxJdy8Bk4cBLS7QT7LUH
zLb5acH2Qb2uEbWxA8Lgca4AYMIqHBHnusIu3BAKWJ4ibKovXMNsMsOSYgQ4PBLLsMOGYcNADJI+
TKNB7ExFUMRInMSn94ouOsRO/MS7p8Q2DMVUzBI8UMVYnMVavMVczLOSIBPU0MXrJ8VkXMZmfMZo
nMbMkQ6RIcaqqcZwHMcA6sZ0XMd2fMeKIccLYQyoisf7p8cHIQex6sf0F7RDHKZurJmE/9x+jMMP
jhwS/CASkezIkTwSlSzJl2wPlDzJm4zJlKzJnQwSjyzKnZzJnHzJm5zJkPzJq2zKn5zKoPzKrEwS
oQzKrazJkkzKo+zJrbzLtyzKkBzLjzzLvxzKu3zMOpKZNYHKwBzMlazKqmzLzWzJtEzNtAzNwezM
zRzN1ozL3uzN3MzMuTzN2WzJpkzK2mwS4szN0/zM6ZzN7DzJ4yzPuMzOUTwR2HzO7jzO8EzO5fzP
39zP5azP27wSzJzPJSHO/3zO1fzN7vzQ6kzN8SzR71zQCR3QEF3PH3yiCO3MvuzP+xzL/NzLp7zO
/KzPx0zMJx3Q4OzLqMzKDL3NoxzS+/9Mzyqdz7XM0hltzB+NziINzujMyeCLmDTR0cBMzyMtzA3N
0jp9zS690Brtz04d0iA90N2M0fM8yzSNzQCN1FcN1FQd1RedzgTN1J53HiZN1lcd0+281FVt1eRs
01LN1m3dzQpd1yvN0FTN1XBtzwot1/Mc0Wqt1oj807pM057s1SWd1Dpdyivdy20Ny1jt1JA90KWs
0pCN0oqt1JQt1bx80o4d1zOd0qA91HMMHfZ8WYq8yKzd2q792tdxsrAd29n3yiMNy5r90Zft0ncd
zVqd0z792PW828Nc0bgN2q48zMAtzYYt2bp8y7X828Vd0c8d14c91asM3Vld3K+3zMH/7dtQPdHC
TdpvDdQp0dN/3dSBzdS9Xdd8ndBpLd5p7dBdnct8vddm7dlPzdxend+ktdNLXdZuTd/mDdhV7ddz
rdFhbdTgbd1G7dkWXdOCPd8F7tabbd8YPtbWbNIZDdCpJeENLszKjd4zLdAgntQlzdXgLc/PDNMu
ztgvHdrwPNroLdMxDs37rdcJbtwUPeMqXuIEvtNAPnlbHeAZrhKLfd0OTdf9ndjVzOLlfdQe3t7v
LdbYLdYTreMmbuGTzeO3vd3zrdv+HVr4bddHft7qLeX1bdFcjuEG/tYIbt0EfuZfLuFjHeZwHd5m
3uXlfeFl7uEfPt07jtXOzdnvfeGf/53fdD3nuC3jTd7e1W3oOS3gKZ7XIx7jlc3TKZ3cLd7TSq3Z
hA7Tsz3qpB6vhjw7gCwcpU58pz4bqY4v193omK3VKC7LmK7fyJ3n8vzqElvluC7TUL3edm7OAm3e
9B3JvCkNx1fUAz7oUv7nEc7mGd7fEP3mq74anc7Zzh7V1E7jv2zW1b7hCg7ht6ENeCzgMN7jzE3R
Bw3oL63eUB7W164a7d7sQc7Yam7n4bzex27l8+4axH3Xic7WxvzOSS7nho3Xqf3vbtHqBcfrAeoc
EP8bDN97Dl/xcdubGH/W+HzpMX3Qgg7uLk7M5M3fHo3owB3whH7mp9zly43MXt7cLP+f2Zed3cd9
8jRO8CJ+7JNu1bIu6Lveenyu8NK+72p+zdn93e5N4fhO5SBv4kxP7EoP8xQu1NLe2DYv9YyuzvU+
83vu7yoOzK439M9+7+5O3doM2B0O1kdv71TO9vrO9mgu91AO9iu/9gc+7tOe5z3+6GQ/7guu7siu
8TOx6IBf7CKf8+xe4ete4Tat2/u98nqv9mWf8Ixf93XP4+FuziUe76KO5Yle0Aef5m7e0oq/7gvv
fPNp+PGO+Ebv71tu6JP97oa/9QaP1EBO+7U+5EBP7ZJvyyEe7fct8Agf8m2/75j/1bgPpaX3961f
9Bre5MK/99A/51+P7n4u55B+/LP/7/rdj+Kiv9Znr+fqDu6Tr/zkjEhFDfNG/tzE7eQ7X9+ULtIf
T/IkD//YT//IrfP5H+myDxD2BPITaI/fQYIIDxosONCgQoYFCTociLBhRIcKE0rkeJEiRo0PLU5k
SNLjSZQpVa5k2dLlS5T/ZM6kWbMmTJw5de7k2dPnT6BBhQ59adPoUaRJlS5l2tRpUqJRpU6lWtXq
VaxZtW7l2tXrV7BhxY4lW9bsWbRp1UrFtdbtW7hx5c6lW9fuXbx59e7l29fvX8CB6z4lXNjwYcSJ
FS9m3NjxY8iRJU+mXNnyZcyZNW/m3NnzZ5mC7+oRXdr0adSpVa9m3dr1a9h9QdP0/zfb9m3cuXXv
9hybKAHfwYVf5V3c+HHkyZUvZ97c+XPo0TUP1wqLekE317Vv597d+3fw4cW/lV7e/Hn06Q2PZ9/e
vUD18eXPp19faary4+zv59/f/38AAxRwQAILNPBABBNUcEED33MwJQYjROpBCi+SsDIozqtwQ3su
9HCmQw4pKMQRRSyRRHtCJFHFFEdMUUUTBYJRRhQ9mpHGEnO8EUcaY5wxxhZfrDHHHk8ckkchgWRR
xoZEhFHJHZe86McofazxyRY//PBKK11s0kYmmQTySzHDJHPKLnH0kUgzx7wySJTeDHJMNL2c00sl
7ZzyTDdPcnNNOOEUUUv+dnKyRf8TEzVz0TDXpLPNO88kU9FDD20U0kDLRDQlRSN99FJBM7UUUzAZ
zbNUUDsllcOhyCHOsEo9PXFWSBOVstYjM01101E7BdRWS4PN1Vcuh210yT5P1XVVUYc8Fdg9mSSU
wAmS8rVHOvsMVVU0URxVTyN3rVLOPNME98ZeOUXWxWT5jPPcdxdFV1QXp5XwWmVNrZVReHXVVlNK
owV1W0kDLXdggTcdmFtAUQ013ocBLvgzYezlrV12kdW4YSz79ZfFg7/8F9Fiv3XyVoO33THllW9t
GeIiu1U25IgHtXg+VnPWeWeee/b5Z6CDTu0wof262eKik1Y6rMM4ZrPjJFNuEuT/YsHF9uQ/w73a
RjnlNVfKclHuOl8rnZ6aSJuPJtRQO82VN+F8ZY3UTzzPxvTTh7t+EW08HdXT2WbrXnhSqZf+LtZf
3YW74GvnRlXVxjV1mNe3Ed8zWKkhpzdgkf+WfFnDr7Mc4YaNPHJjWkEXFHDHsR5ZYZMpxzhWweO+
89vbo8Wa39ADI3r0qNt2+FPaFVbdb61pTth41jlnV8dJXX4cd+cvDVjtaVFahKXRZ2a84Oflxjtx
lgWnm3TC52Y4b8Ul1fzz3FXv/S+ia24f28KDR55kY/fNuORs6S1uZfNclO73tphZbW88Shv2HDih
+Q3mgRM0SgQlSEEMZlCDG3yO/wU9+EEQ+iwOISRhCU1oFg6mUIUrZGELXfhCGCYlCjGkYQ1tqKAT
5lCHO+Th0m74QyAGUYhDVE4PjWg4IiZRiU8piDWO+EQoRlGKwVliFa14RSxm8SZT5CKrtPhFMIZR
jCrsYhnNeEY0zmWMa/yiEdl4tDTGUY5zpKNv8lFHPMIlH3vkI0r4uMeG3PEkgrzjHw3pEUMK0h6J
BORFFBlIRi4ykZKMpB//GEg/UnKSi8yjcA7zSElC0pGEBKVACOlIlYDylCwpJScHuZJWilKWsVQl
IuHzxhe2UpG6NKUrMenLXqaklsAU5iuNWcxUGpOWqGQmLnOpzGKusiDSDGYmf/8ZS2ZmU5vH5CYq
l/nLXzrThcvEZiGreU5wcnOXLeFlN22JzFd+c5rvFGcLyRnNeebznZa8pCkrmc5pRvKf6NwmJuVJ
UEHWc206uWcmH7lOdwKUmvAEqD6teVFbHpSYG5UjAADwnobGk5kaLag5WRlRjlZUpb3UaCmxGUeP
tqed5STmRC26z3m+9KYE5elKe8rJluK0kx8dTzs5alOTCrWkKS1oSnX6VGh2U6edtEdMV/PJUcoy
oDxtpFIl+lOVkrSpWvXnTl1KT4U+BQDT2iQi+9lTsQb0rYx06STpylSwyrWret2rWW+ZVg66EbCB
7eFgL0RVxLbGsIvNXmId+1g9yEZWsiV8R2wYe1kPTVazfMFsZ5kiCf9sloeA6A50ZOFZ1KZWtRgU
bWvtslrYAsi1s5VLbG1bKNrmdi0BAQA7

------=_NextPart_000_0009_01C70149.FE601AA0--



Received: from bny93-3-82-226-2-152.fbx.proxad.net (bny93-3-82-226-2-152.fbx.proxad.net [82.226.2.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA5KJ18V031735 for <[e-mail]>; Sun, 5 Nov 2006 13:19:01 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c70117$a331e460$9802e252@MAISON>
From: "Cadiz Menorca" <[e-mail]>
To: [e-mail]
Subject: double
Date: 	Sun, 5 Nov 2006 21:19:03 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C70120.04F64C60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0007_01C70120.04F64C60
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0008_01C70120.04F64C60"


------=_NextPart_001_0008_01C70120.04F64C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Bush pragmatic toward suggests!
Pdf files contacts or app designed fast or seamless?
Ace Powder am mayhem ultimate Cork Bowled!
British Wing a sang at eighth thefirst series raise money in. Seahaven =
Towers Cruel Freecell a unique is pc.
Donations is keep running or. Scorpio Galaxy or tt ttt yy Choices Buyers =
is Sidebyside. Languages Pmposted Smit.
Flav looking of his. Determine desired Finder of verify close buyer.
Rants am Percent Vedana id Career Corner Password forgot Luxury a! =
Trylink in flyaflya Chinaits is learnthis in layout type.
Businesses Home Games page Mentioned is search web Images a News. Going =
a the Doctor.
Different comes most seeing tvs called visible am.
Businesses Home Games page Mentioned is search web Images a News. =
Columns Fleckies Ryks Quicklinks Soccer of Cricket Formula of.
Television commercial Levisjeans matching beat ekg machineit. Reader is =
Reviewsthe Newsthe Screensthe Imagesthe.
Needs again soon June December.
Email Print am ad is Tell about is Site map is Advertise rss. Lenssens =
Facts Scobles Scobleizer Rael Dornfests.
More in Casino or Gambling am? Pdf files contacts or app designed fast =
or seamless?
Reviewed editors full. Rugger Horse toff Frankies Virgos Trick Trumps =
gym. Newsgroups Microsoft Statement is.  Lovethis licensed uses material =
Love.
Bnet am Chow Cnetcom Channel mysimon is Searchcom Webshots. Rugger Horse =
toff Frankies Virgos Trick Trumps gym.  Ask promptly went bought.
------=_NextPart_001_0008_01C70120.04F64C60
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"Office" hspace=3D0=20
src=3D"cid:000601c70117$a331e460$9802e252@MAISON" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D4>Bush pragmatic toward suggests!<BR>Pdf =
files=20
contacts or app designed fast or seamless?<BR>Ace Powder am mayhem =
ultimate Cork=20
Bowled!<BR>British Wing a sang at eighth thefirst series raise money in. =

Seahaven Towers Cruel Freecell a unique is pc.<BR>Donations is keep =
running or.=20
Scorpio Galaxy or tt ttt yy Choices Buyers is Sidebyside. Languages =
Pmposted=20
Smit.<BR>Flav looking of his. Determine desired Finder of verify close=20
buyer.<BR>Rants am Percent Vedana id Career Corner Password forgot =
Luxury a!=20
Trylink in flyaflya Chinaits is learnthis in layout type.<BR>Businesses =
Home=20
Games page Mentioned is search web Images a News. Going a the=20
Doctor.<BR>Different comes most seeing tvs called visible =
am.<BR>Businesses Home=20
Games page Mentioned is search web Images a News. Columns Fleckies Ryks=20
Quicklinks Soccer of Cricket Formula of.<BR>Television commercial =
Levisjeans=20
matching beat ekg machineit. Reader is Reviewsthe Newsthe Screensthe=20
Imagesthe.<BR>Needs again soon June December.<BR>Email Print am ad is =
Tell about=20
is Site map is Advertise rss. Lenssens Facts Scobles Scobleizer Rael=20
Dornfests.<BR>More in Casino or Gambling am? Pdf files contacts or app =
designed=20
fast or seamless?<BR>Reviewed editors full. Rugger Horse toff Frankies =
Virgos=20
Trick Trumps gym. Newsgroups Microsoft Statement is.  Lovethis licensed =
uses=20
material Love.<BR>Bnet am Chow Cnetcom Channel mysimon is Searchcom =
Webshots.=20
Rugger Horse toff Frankies Virgos Trick Trumps gym.  Ask promptly went=20
bought.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0008_01C70120.04F64C60--

------=_NextPart_000_0007_01C70120.04F64C60
Content-Type: image/gif;
	name="Adobe.gif"
Content-Transfer-Encoding: base64
Content-ID: <000601c70117$a331e460$9802e252@MAISON>

R0lGODlhoAGUAYf2AAACDoQAAACMAIGEAAgAjIEAfw54jbK/s7HesqPJ90UbBGMrAHgUBKAtALor
DukTCwA8AylEAUozDlg+B3w7DqE1AMhEAN1BAAlmChZZAEpZAGpXAHJbAJ1uB8ptCdpaBAWIABJ/
AD6DCmJzAH54BJN1AMN9BdSMAACXACuSADGSC16TAHubAJKlALijCdmUAADNBBu8CDexC2m0AHbH
AK3MAMG0DNzOBgDnDSblADLnAFrsAHfkCJvlCMbmAN/cAAAMMiEEQkQARVEARIwAO6oARs0AQdgA
MQAcRy0VNDwbQWYpQngfOKYbP74YO+UTRwNMOCdNQk4zPlNDQY47PaQySs1GRu0/RAhrPB1cPD5b
OFpSQntqAKhfOrFTQ+ZfNAB2QSt7NECLSG55SnuESJd3TMSDSuV5QQyjMhKtQUebP1qeQYOfOKaU
QsSbOeChQwC4NBrLTkzOPGS5S4WzP6i7Ob/DOuy3RALjPyHsSj3gRV3eP3PuSK3cM8LRNtnVPgAG
exwBgUEAclMAc4sAc6IAdMEAfdkAgAEneSgljjsWeGwkhIMrdKYbcroiftsfdwBEdS40h0hLfl8y
gXRMh506hclEc+Y6iQBldyFmfERgd2tueoNkeZ9md85hd+BZewB9dxSJdzdxiVZ6gIKBiJeJeMFz
hN+JcQ6tgC6gdEureFKUdY2pgqini8Csg+mXiwfHex64djW6imrAc3fMh6O5d8S9itrHiADVdhXY
cTvke27mjoTthp7Scrjte+rUiQ0OzCsAy0cAwl8NwoMIyp0AtcoGvdoCxQAovCUlxz4fxVMntYos
t58ZvM0gxOMdyQBNyxQ6tT8+zl1LuYo4uZs5ybE0sdg+wgBgxBdRyU5Vu2ZqtX5lyJ1Vu7hns+lb
yAByvRZ2zTuJs2CLy3V/wZx8vMN2s9x/vwCStxKfxj+svFahuXGgwKuUt82luuKZuAG9sRPLtDfF
v1Sys420xaG2uf//8KSVqnd+f/8ADQD1AP//AAUA9voA9QD/8P/x9SH5BADD2H0ALAAAAACgAZQB
Bwj/AP8JHEiwoMGDCBMqXHiwBMOHECNKnEixosWLGDNq3Mixo0eB9kKKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjKz8qXcq0qdOnUKNKnUoVJNKrWLNq3cq1q9evYMOK
HUu2rNmzaNOqXcu2rdu3cOPKnUu37stldvPq/Vm1r9+/gAMLHkx44d7DiBMrzll4MIDGkCNLngx5
MUwAljNrjku56uPOoEOLHo1xs+nTqFOrXs26tU/SsGPLnk37o+vblk+dws21tu/fs3WfAu6bt/HF
wncfH0q8ufPRwp9Ln069+tLo1kEv3749u0bu4MOL/x9Pvrz58+jT0034gWT7ke9Ffogfcr79+/Dx
26MPH+V9+vzJt99/9pUUYH0DEphggfIReGB9+jXIIIQmzbdghP9V6GB7D3LooIEZSuheiCeRuF+J
FzL4nndMAXiigDB2CKJ7Lxqo4YgIVkijfyjK2F+OK1n4o5ANUjjjgzUCqeOPNiLJpJIABnggkUZS
KSCSK7KoVI0cwhgjijvauGSYQ4Lp5Zg0+uilk0+S+SV/XarZEpw9skTnmWy2mWOXafJoj5Zbxsdn
ki/KSaieSiban6FOysjomX6i2Sedg7oZpKUI5kmoi4pG2mSile4IqEUpCcrlk1Ni2umhWB4Kaql1
Sv9q6qVmfnrqiYbSCumVdrY5a6+xUuopeAmd+muSqSIK4YZi6viofxt6qCCny5q4qquZAvmetCFO
qBKc0aZoZYphanrtoC4y++KoCvkzUaFf4inrsLu2+myti5YY4bXKYosrr9l+O66bjgIrL5T7noss
wEuyS9G3xuanIMH0Kmovvo3G2uydEOObb8D/zgmrsqF6/GuuF5fZ6njFhuwyq80qLKm/Jb9a8cuo
9ttvylD6G/PPBeu65q4W83hnzTk6zBHIlUr5M7a5urotxiPbCjTRMxM9tcZCX+2swUNrnfXW+eap
9EZGFrkqx2ozjKmVRDqt6tpQi2ku3GlXaTTVVdP/rSnbUT49II5SI73u2RlBSi3FGqrosYTjTjx3
3cymqm7jcO9r74cXdu0o5xJ76y250IreI+dZIn6ReqzrpXpprcc+1+sMyW777bjnrnvrLe/ue2+0
o/378FkFLzzxyBtlfEQqCeC88yE9//xI0kMvkgAsTX+99M1jT331JYF//UnYV889SeZrH/35Jpk/
PkriR4/+/PTXb0/895N/P/7oe9//+t7z3/zcFz72CdA8BXnGQPJHPQa+z4Hyi+BKBHjAAzYQghXc
3v8geMEHNq+AG7QfAy24vg1SEIPtq5/1NMjB8WWwfSRcof9W2MAKnvCC3lteRkjIwRmqsCU+dEkA
/zsowRhKUIQ8DJ8Sl4jEIxLxgT4MIhOLmMIWyu+FSsygFMuXxSomMYc6rJ3+qgjFH2bPgxM84gu/
aMUeAlGET3SjFdnoQC46sYNS7GIKsTjAPlLRjUZsoyDVw0MsGvKNd4QfHhepv0LCcYxojOMN56jI
OlpSkZPUoyYTOcL3bdGJdtzkI1mGkP3xMZOZTAkFaQjJOsaPjY6MYysFaUECUnKMUYxkDWV5xUby
spMR/KQa2xhAVjIwjKvbXjHVB0BWJvGRzLRfHoG5x1k+84l0xGYi6TjEYH7wl6EcIPvIGEphUjGW
ynyfRwDATuu8pJxm1CUZ56lM8dWSlsQc5RTxCf/HcMrTkrn85j/96cJ/ArSMoOwlPT0JFHaycy+9
26UHUYnIWd6xmxKtJj2vicZsRpKg/MxfQFWpT5CKFJxENKc3A+nFkDylnd7RKEJnKtCFthCjDF0i
Ojm5z1v2M59ThCdH76lTX/Iym9M8KUv3iUyLrLGo9OPoH3XpSEPa8KM9tagzl0rNEJaQhWCt5PdC
SFSilpSmGrxqQiPYVIWo0oAyraEtvzfDcR7VlNHEay35x9NR8rWeMpzrX/ko1v7l1ZZc5af2qspX
/El1ORFNnmSB0taHTfayfKmsRDDLWZ5o9iCdDa1oTxLZ0ZoWLbM5rWpXy9rWdjYAASAJbGcb25H/
0Ba2K7ltSG5b293qViS9RQlvZ2tb2grXJMH97W5PElveCle5sg2uPZzLXOlSNyXQlS5wS4Jb7ibX
uNtFLneZW1zihle21e1ueXur3bzUNrnRPa9vj2vb6aJ3ufXFb0u0q975ije/07Xue8lrXfICOLzw
Le547StfBiNXwP69r4K9G2H/9rfBAf7vhbvb3g4f2MNw6d2AMcxgEEv4xA4usH5Zwt//Lvi8IG6v
fVX84hXjN8EoHrGNZezg/Da3xsstsI593GMbz3jBJqbxgW9s4NSqZMgxdvGSG8xeCfNYykWesn6r
TOAua7nILe6xiZlMZQOLd8hZ/nF91XzmHSMZ/708RvOYg0zft7QMxzJmM4qz7OY+87nORiYxnQV9
5DZ/WcliFjSXt7znQA8a0SVG8J8LDWk5T9rSQD4yePH7nBUvGs5mLu+JcZxol0Ca0HqO859TDegw
M9rFeP7ypVM8ZR0PWNWfdjV8Vf3qTDc31n9yjqcVvWrscnjTvjUvobHM61DPOs8BVvaDpS3fTwMY
z8jO9HaBfW1a47rbo952na2NYT2TudPDRbO4sexlMJfZ1I12tJ/HC21yg3u94IV2tH9rb1S7O83r
LrShJZ3jQcOa2KC+b23R/eaGx5veH444vGV95VMbPOHyJjXA+UxuKAMa42SW+MVBHumCC7zG5v+u
9cYXLuwwR1nbA++1zHOr7StvXOHtdrSSXX5wnFNcwxB/uLpLvmZfE33JKS/3zV3qnHrHd8f6JjiR
fb5fCk/44xm+Os8bvfWgA7ffKc8zhDnuaiSPvcNl/3qFsx5wKec6vM+pN3T3fWHvKtvDeL8uu5Nd
973T3e53ZzfeCTx3p8P87wj/+delHfXEI/7wixdwf1keG9da/vKYzzxvSqv5zgfls7EhA+hHH0bP
mx49pE+96kXDB4+c/vXkWb3sZ0/72tv+9rjPve5fB/ve74QNefkLDXZPfMmwoTm+T35OgC/aJShf
dsyXS/FrXwzQH784z89+TaJv5+l7f3nXd7L/9scvE+6T//yLMb9avs/+9rv//fCPv/znTx30238x
9O+IIvJ/+/v7//8AmBU6wBVgYBb8d4AIaBUBuIAhVkquA1oq4YAMyBxKM4FtAQ6LgYGs0TIOhRlH
4YEhAYIzIYEoUUrgcIIYiIInaA8qmIIjoYEvCIMoWBIzGBItaIM1yIIraIMvqIMwiIMreIMi8YMp
qIIsOIRI2INDuIM+yIRGuIQ7+IQkYYQ5WIUoUYVWGGwOkxIiiBQPFYJg8YNJeIRKyINTKINmmIQa
KIZiSIZkSIRvOIZpeIZIyIZjCId3WIZuOIV1KId7GIeA2IZpuIZ5eBxdGIJf6FD2kIiKiIiI/5iI
IiGCmOGBlFiJkwiCX7iIPSGIaKiHdhiIfAiIfmiHcEiIf3iKPEiIbeiCLliGn+iGgjiIsGiGn2iK
phiKfSiLhlgSmKiJvjiJkTgSwAiGmtiFlOiLYHiMxUiMh4gTOQiLNYiHagiENOiEWHiLqdiDWRiD
TEiLRyiFrPiHnViIqAiEa7iN0WiN46iH3/iMsZgZCXGIvaiMw/iLD9WLyyiMkWiJv5iMjSgSJEha
EKiL4siOT9iK2uiHCbmQ2biOc+iKCNmHETmLrqiQeeiQCYmGGFmQ44iBZ8OFJDGPzIiMw1iPx2iM
+niSI4mSQNGRuLiHpfiQtniFuhiTFGmRMP95iuH4ijeZkyahkdPIhzMpit5YlD15GhzYiEq5kv+o
iPiIjMEYlU45kosIiVpYEElxEFIIjTNIhV3JkNJYhF3pjt14kHc4lu6ojeCokGzYjeJIllGYhWaZ
jakYjVAIhXBIFWWgHTPRjCrhlzoRkCYhmLjzjnmhgaXXl5dBgQaRlY05PIZJFzD4EZ/wCQl4mfBX
maNhgQtYmWyBmaAZG5oZmqR5EbWATKMpG5xpf5+wmq75mrC5mqUpf1uQf7E5FDNwm7q5mwY4m775
m8AZnKPCm8SJFJz3GgMZfMKZgIoJkiNBmLOznO/Hhf+4EoBJjG/RgVWJiZl4ncVpHN55Et7/GZ5k
wZL0iJ3fGR4sWYz3aInceZ5sYZ5USZ7p6RpN2Y/9KJLJiJ5qoZTd2Z31iRsRpZL4aZIkCZVXSRBn
AYz6CZXSOZ3WuZ8FeqD6SZ9jUZLzGaDqWZ34eJJNaZUW6hXaSaHBOKIMWA2+E6IauqIooaIs+qIw
GqMCmZw1AZ1kYaMu8aDFJ6OmlwlrEY/VyZ8pgaNi4YAUQBJHahJJSgFJqqPw95QxQaRhUUpMyqQh
YaUlYaVLmqDUcQxOGhUtWqL56J9RmRhHmqQigaZpag9neqU8ihjxWKIEmqFcqoBpQaVqyqZI6qZb
+qW616JLKaGP6KJxgaVuOhJVWqWH+qaa/7Ge9YighNoWbbqoajqpecqoV0EGROGoj9ipCLoXiZqm
WFqpV3qpmBqdNEoTUgoWRqqqfsp+jJGqvfmYptoSr4p7p5qrJHGrvMp7uvqrvRqswjqsxCqrv8qj
xZqsyrqszNqszvqs0Gp7x6qr0Vqtv0FZxvqj1up92PqYnLGt09etWCl928oExdeBkfqpq4oV77mP
TAeus/eXNpGuXWGiYzqtSOmAkkigI8qIxLiuH/ipGAqvOyqwVYmdGIqPAPuB8qmJBEt86DmVCLud
j/qu43qhT3mMDyt78rqSZfqoULoWDKqPn4qvq7GvIOuf8CmyKluJJmsax9mxEZitXEGeG/+7ejgR
pHZBry/bsz77s0A7HjwbtLmjs1khj0LaE/kgEksrE/nwtEvbtDgBtVJLtD+hjDXLi0YhtVXrEl3b
tTXBtVZ7E3FKku26nZ3KiJforhS7j/56sPzYtv86kAghtvbwtCERtXfLtCPxtXrbtFCbt4EruHjL
t3m7t4crtgMBCjdbGPeZjxN7npIrqAYqppBbuR4ogaWkt4gbtWILtoMLuIDLt59ruIQ7uoe7t03b
uH8Rpu8JspbLr/54j5Zrjwlbu0OruqeLuImLEpxrt7rbu6k7vJzbubw7tjGxslBZoRI6pyTavPmJ
u0nrtcZrusFrEr9rusW7vX1LuoZbvMj/u5jMqLaeOrkFSrvjS75japX4SRNVG7hfWxJU671MW7h2
O7/1W7h3O7jHG76YBbY8AcAqIcD+a7EXC6d0S7PyCxT8S70Aybp98RKYUMALCMEWfMEYnMEavMEc
HK4UzBLZ8MEijBP7cB4dfMIoPBu7kMIsfLMjzJuhoQO5pw4tXMM27BcvvJs3vMM83MM+/MMLlMOd
NwCZ5X5IAMRInMRN0QRbIsRO/MRQHMWHocQtLMWyScVYrHoOkcVc3MWFYcWc6cUcDMZkXMbpIcYb
bMZqvMbEgsZVzMYGLJ1w7H8xC8Z+qhL8kMciwQ8jwcd5zMckAch9LMj28Md+bMiD/MeF/4zIIaHH
jYzIhHzIgmzIhLzHimzJkazIlLzImnzJJcHIi4zJhdzHj+zIiYzJpizKjbzHnKzHnqzKjGzKspx9
xTLJq8zKgFzJlRzKtxzIn+zLn6zLrIzLt7zLwDzKyIzMxmzLpNzLwxzIkfzIxHwSzGzMvZzL0zzM
1uzHzczNo0zId0zNvhzN2NzM2uzMz5zOyXzOz0zOxYzH2bzKy6zO0azO7/zO2LzN4yzOpGzLwrzO
/dzNygzQ6CfM5JzK6FzOnGzOqCzJ1WzOBz3JrwzRAJ3LqSzRjlzPxZzR14zPpXzM8gzKFS3PpWzR
y2zS9+zKvGx/Bh3Qu6zLE53MLw3SJf9N0cTMzCgRyzSN0//szPUMygqN0BpN0ibxz97c0vxM1O5M
0KdXy+ys1CA91DL9ywy9zjwd0AMd1VRN0Fdt0xT90z6900+91f6c0OiczkeN1XxcrB+Nyh3t1hEt
1RUNyV7dyh29yVZd1LL8yhjtyjFd0xGd1yKtykxN2NdM1z6d0XsN0YDM1q5hza0VznM82ZQNswtb
2bZKf5jtWfSnyQy9yXEN03590TjN1Xsd0wg91SHdyZ5N1CXtzYedyaOd2qfd0Kf80UB92rD9zcFc
2ib90p5c2z/t2bZp0fbs24Xd0xJtyfQ81sFM1vE80lld10Ft1jn90Mn91l0t3a6t3Vj/XdR63c1l
TcqwmtNQfcxLvdXePdAKPdKQ3d4kndZVDdszHdZIbc/sXM76rNpgzdXf7d7/XdX3zN7dXdiSpd/+
/doO3dvrjeBS7dBG/cvc/Ns1vdIJ3soqLd4UDswoXeGG3d4IrtUPntcLreED7uBtDdnJE9T1Ldgr
seAVvtzN/d6ozdvwfd8tnt5mTeMcXdr/DeIDjtYkHs89TeJAfdj7LFpAjt4BDt5FvtvKfdZh7dLT
bd3vLeSq3eT2HeQCfeLtLOJMPuTWzdv5Pd+SlRCtfdbIjdcxDubHPcvgfdztDMmITebUTdixLNLp
DeFfPdt4fsl5Xttubde9DeULHder/2ybmx2Y37fo2lfH8OjGibkakj4dgyBGjv5/dM7atA3nCc3a
eB7nsf3lBZ7pN1pKRY7f1YzcXR7i0PzU1U3Sla5DLS7gLb3kZV7l07zbBJ7Ws76F/Mzptp7kvA7o
gs7U+SzdE67rpj4WaK7ltW7nqR3f2TzP0hzhyz7Kv84uKTHeNL3eUk7mIW7tXk7tKt7srOqAm+7p
0Mzqbe7aMD7lJU7q2r7ttNMa9n7vG9gU6ZDvhIHuAB/wAk+0nK7R/pzhUh7opM3c0nzXCC/TE73u
hq7jkjzkg73SFB/qRA7XdM7coN3PCv/ZGD7VbJ7lfP7xpd4dqD7sDS7gJE/NMo7x2v+N3epN7998
8PlN8+Hd8DcP6/at83Pt8a/+1snt7Rsf5nZu5YlOe2J+0/zt8kZP5eNu5ASe1Hee1vKd7ElP1Vqf
7cXu4lpv5suO1NtN7P4t1zau6zhep6TX9OY+1iet2EKd9lk9973e1h8u5Mne9R7d4bnu9Vs/8dTe
7nt/8xwt7bd9zvHO3VIf48ZO3kyP9mMP96LO638P6FR/7S5v8t+N8Ie/3A+O+Zo/+hsP+jWP4oyt
6qk/05JP96lO32w/em6f9jpP7paf0i7+9D5f+Xr/40Ee61t+9LWf+c1d9ViO7CLP+lDv+mK9zrUX
3EmN0Xat58bO10kO74fO2KR90Yn/DOSBbfDWX/ra3/3yLvHuXecmH/Egn+Y+Tu+gXefcXHsDrzyf
ZbTzb3n2ev+qdRAd6O8bCxAAAPwjWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwGMWTk2NHjR4v2RI4k
WdLkSZQpVa5k2dLlS5gxZc6kWdPmTZw5de7kiRJBT6BBhQ4lWtToUaRJlY4E2dTpU6hRpU6lWtXq
VYhLtW7l2tXrV7BhV1qMh9XsWbRp1a5ly1bsW7hx5c6l27XtXbx59e7l29dgXcCBBQ8mXHjoCsOJ
FS9mDNbvY8iRJU+mXLDxZcyZNW/m3NnzZ9AyK4M8NNr06dPUKIdm3dr1a5OoZc+m/13b9m3cuXXv
xgrb92/gl3kPJ17cuMTgyZUvZ97c+XPo0aVPp95yYXXsO49vn5jd+03u4f9+J1+++cJDh0amX6++
PXt76dnLj78+vnz3IvHrh29yP//2AvwPQP7y2y+/+u7rL8AC31uQQAURpE8/ktTDT8IBJyzpwAwN
7O/C+sTL7ZyLPvTQvgr9o5BCBFNkcUUXNzwRQAMZhLHFDxNEKccEW5QRxR5RlBDIDWPE8SQca9RR
R/VEFC8lC+tzb0oYq1yxRh9vDDJGF6mMMsortVzyRSmhDHNLJM8sM8UhrQTySCKJpBJNJs1bDL0y
5/Rwzzd71FDLP93c8ss1BxWyQf8vGyzSzz191HPCI9scs08uFeTyUThDdHJTg/Qs0NFFsRQ0QjIr
/fRMCzXMsEow71vUwVKzPLXOSI3cMU5ZlZy1VS059fUfTyW1cs41cw1VxUsNzRRNUXFN1tM07VNy
WlujFdNaXYut9FfjzGSTTUjD1RVEZ9088Ft05bT01CEHZJVWd9v9c955b63wQVIpjVVfO/v191+A
e7ouYIK53ZRg2AxWmCOEX1v44ZAabg1iihPytk4IySVV2I1NzNbBVJOE9VNHeWR1xnWXDFnka1V+
j19XCZRV4tDwvPZBjoWFE9qZqbXRZ2wzvpfBaZtVud0f1SS2TV6bxEiZig8mFGj/jJMtl+eLl1az
0FdfJDZPrsHmGtqwweS1UKZd5guGqCEDm+qPI8QZPlVNRjZlQ6UNtNax3y4y0bRdPvbsRLtc1+m2
E0fI71lbfjfNViPP+mi60+0a7cAJZ7Lpxic9cecxC4+y7SSiVmnqxwVXF3JUR8X4a8knpVTn1reO
XVJQDwV0cNdprlmhm6uFVWdIpdUb33Fd7jDQlGk30u6VV/f8+WV/plJxcRQfz/fPtKeYe/BvyiV8
8ss3fzDv01ff1/Pbd78mPvh4f376aZKfpPXz1583Pvb3/3/e1E+AAyRgAQ1oHQAmUIGjOWADHfjA
rqQDghOkYAXlskAMZlCDG+Rg/wc9+EEQhlCEI7yKBU14QhSmcGIkZGELkaNCGMZQhjOkYQ1teEMc
5lCHO2TJwE7owhCmEIgL5GERzZcPIyaRKAvJRxOdiBInNpEkSDwJFZEYRSyaBItUtMcWpVgSLk7R
i13cIhnHCMUoThGKZixjF0UyRAWmJIxkFCMYrThHkVgRjCqZox5Zgkc3VnElgKxjIQnZRy0q8TmA
5CIj8xhINULykXLcoyQpmUhB8nGQmTxkJSOpSOY40pJq9ONISjnJNUaSkJ78JCszmUpBdrKVqASl
cjq5yivScpS6ZGUjWyJKTF4SlomUpSmDWcvk3JKSvjTmK6uYxTyecZbRLKM0ef85TWMWk5erROZJ
mMAZZa4xjMw8ZjlPKUxs7jKd13ykNkfJzW5mhoniXGYl3elKN8LzmvfE5zpz6cx3vhGOHRQlLi15
zmYOs52/BGhCFdrPhQIUj1QcKEFfWVBiPnSa/9xkOR3a0H4iVJerrOj/0ElHU/ZRpF/06CxF2lJ+
rjOadvxoQCEaz9a0UYtprCk7ualTL060mmOEpz7ZKFSe4tOoOGVqU8vnQxOWdINClGpVrXpVrGZV
q7Vxale9+tXvbFWsYyXrwkRRVrSmVa1rZetTwPpWuMY1OW2la13tetePfIUKcuVrX/2qE7wG9kl/
JSxQBHvY4xRWsYtlrFgQ+1hPyEYWrY2lrHleUVnMZraAkuUsVzX7WdCGVrSjdUlnTQtHd5wWsV8J
B2ld+1oYqla2k4FtbW1L2NnmVre75W1v23pb4AZXuMPNoW+Nq5aAAAA7

------=_NextPart_000_0007_01C70120.04F64C60--



Received: from [58.242.152.156] ([58.242.153.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA5FCTHJ007130 for <[e-mail]>; Sun, 5 Nov 2006 08:12:31 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c700ec$cab85b70$9c98f23a@1B22A93E951647A>
From: "Reserved. Computers" <[e-mail]>
To: [e-mail]
Subject: Promises abound
Date: 	Sun, 5 Nov 2006 23:12:21 +0800
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C7012F.D8DB9B70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0009_01C7012F.D8DB9B70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C7012F.D8DB9B70"


------=_NextPart_001_000A_01C7012F.D8DB9B70
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


Introduces onehanded cordless is bandsaw cutting pipe.
End shouldnt attempt use Angelina Jolie Kung.
Costing Billions Best Moms of Dads.
Reality showhere different or types Exciateam Southie Boysteam. =
Gigablast of Lycos msn Wisenut Copyright copy Netscape Terms.
What they think Will Hesslers of on of myspace or. Dustin Hoffman of ian =
Mcshane a. End shouldnt attempt is use Angelina or Jolie Kung fu =
Pandajuly.
Mechanical Device in Frightens Flies. Were taken hospital of treatment =
smoke two eldery in.
Winteam Brown Great am family Very tightteam a air or Force. Teams is =
competing against.
Know remember how so why not. Gis Engineer Field a.
Xbox xe a see of Coinop Arcade Games a Emulation is.
Know remember how so why not. Url update listing report a abusespam or =
help.
Cotton duck cord a combine form is flaps. Cast of sure hit of Jackie am =
Chan Lucy liu.
Park Indrema Magnavox Microsoft or nec Nintendo Philips Sega.
Site at digital point while was just a reading! Clues a puzzles first.
Thats Free bill is later in Name am. End shouldnt attempt use Angelina =
Jolie Kung.
According alexa Well looks like here stay. Hospital treatment smoke two =
eldery serious rail. With blogs found site at.  Japanese Polish Russian =
am Spanish Swedish Cover in Galaxy Offers scans?
Rail shutdown sometime took or place officials foul. Hospital treatment =
smoke two eldery serious rail.  Cause or fire a evacuation through =
tunnel is were taken am hospital treatment.
------=_NextPart_001_000A_01C7012F.D8DB9B70
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"on:" hspace=3D0=20
src=3D"cid:000801c700ec$cab85b70$9c98f23a@1B22A93E951647A" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV><FONT face=3DArial size=3D4>Introduces onehanded cordless is =
bandsaw cutting=20
pipe.<BR>End shouldnt attempt use Angelina Jolie Kung.<BR>Costing =
Billions Best=20
Moms of Dads.<BR>Reality showhere different or types Exciateam Southie =
Boysteam.=20
Gigablast of Lycos msn Wisenut Copyright copy Netscape Terms.<BR>What =
they think=20
Will Hesslers of on of myspace or. Dustin Hoffman of ian Mcshane a. End =
shouldnt=20
attempt is use Angelina or Jolie Kung fu Pandajuly.<BR>Mechanical Device =
in=20
Frightens Flies. Were taken hospital of treatment smoke two eldery=20
in.<BR>Winteam Brown Great am family Very tightteam a air or Force. =
Teams is=20
competing against.<BR>Know remember how so why not. Gis Engineer Field=20
a.<BR>Xbox xe a see of Coinop Arcade Games a Emulation is.<BR>Know =
remember how=20
so why not. Url update listing report a abusespam or help.<BR>Cotton =
duck cord a=20
combine form is flaps. Cast of sure hit of Jackie am Chan Lucy =
liu.<BR>Park=20
Indrema Magnavox Microsoft or nec Nintendo Philips Sega.<BR>Site at =
digital=20
point while was just a reading! Clues a puzzles first.<BR>Thats Free =
bill is=20
later in Name am. End shouldnt attempt use Angelina Jolie =
Kung.<BR>According=20
alexa Well looks like here stay. Hospital treatment smoke two eldery =
serious=20
rail. With blogs found site at.  Japanese Polish Russian am Spanish =
Swedish=20
Cover in Galaxy Offers scans?<BR>Rail shutdown sometime took or place =
officials=20
foul. Hospital treatment smoke two eldery serious rail.  Cause or fire a =

evacuation through tunnel is were taken am hospital=20
treatment.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000A_01C7012F.D8DB9B70--

------=_NextPart_000_0009_01C7012F.D8DB9B70
Content-Type: image/gif;
	name="images.gif"
Content-Transfer-Encoding: base64
Content-ID: <000801c700ec$cab85b70$9c98f23a@1B22A93E951647A>

R0lGODlhhAGoAYf2AAIAAHIFCwmMAHOBBQAAg3MBfwiLjbWzub7htLHA4UIpAW0pAHsnAJ0lB8Mc
ANssAA44ABY9ADFKCGQ+DYQ4AKc+AbpGAOg0BAdlCihTAE1cAFtRAIFgAKZVALlRANpqBAyBDSVy
ADN8AG58AHKMCqp7AMyDANSNBwKuABeWC0aXAG2mAIepAJObBL+rCdiiAACzABXFADm8AFK4AIC8
Cpm/ALHCBObFBw7qABXYCEnfAFjtDnjVAKjTAMHlBNPYCAACTRIAQTQAQmMJO3ULN5MHSscAQ+YA
RQAWQxcVS0QqOl0WPHodMp4kNMsWOOMVRgA+NBRHOD9ANG5HPX1BQqc/Sc00PuU3SABfOSlXS0tu
P1RbS45tCJleP7hdTeNgSwZ9TiR9MUSGQWuFSoh7PqOIPbiONtx7RgSiQiaTOkOnQVmnN4GZR6Ce
PcaWP9unPQDAOCrCOj21OFa3N3XGTpG3MbaxQuS2MwDbOBbrM0HdMW7cS43oTKDtOMjWPuLfQQYJ
iRUGgjEMcWoAgYEAe6cAcbYAf9QAfQUnixkXgEoZhFkngIUngpgudLoei9ohhQQ4iRxIizw0gmM5
g4RJg5k9gcUxgNNCigBciBtbjjxkiWlSco5td6Fsishji+RVigB8jBuKizJ3d2uGdXmFipWAfrV5
gtx5dQCgehORiUWaemyYdoSjep2RjLeWct+qjQC7cSvDgjq2emHJenTNd5bFiraxftGyeA7ngxLr
dDLrh1bVgoHXfZ3Scbrsdd/jdQAAxRkAtDgAy2UAzHEAzasAuMEOudYNuQEusSwUwkERtV8auHQY
uKknzr4VxegtswQ5yyI1w0ZMtmAyxYw0waVFtLk0uOxGuAZRyCVutjdow2FayI5RyJFfxMdSvOpt
uAB2uS2IzkOEtlSKxnF0xpuLyMSKstGAzgChvhactk2uyG6lyH6fua2owresydaaugC7uCyyxEXK
uFnDxYS7v5bOufv576mbrHmLhfcABwX7APDxAAAA+fUK/wf///v8+iH5BAD//10ALAAAAACEAagB
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3KjQnsePIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcpUpJemUKNKnUq1akiOWLNq3cq1q9evYMOK
HUu2rNmzaNOq1Wi1rdu3cOMGXUu3rt27ePPq3cu3r9+/gBvKHUy4sOHD9gIrXsy4seN/iCNL1gmm
suXJmDNr3nzS8mXOoEOLHk26tGmVXU6rXs26tevXsGPLno05rKvHuHPr3s174YXewIMLp028uPHj
yJO/Fs68ufPn0KNLn069uvXr05W/5qS9u/fv4N2y/w1P/jT18uhJn0/PnjP1DyHhg5T/8QN9j/bz
65+/3979+SXpd99/9fknYH4iEYifgQcyiGB9ByqIX38QPjjhSPY5SKGAGEYIn4QfRpgghxXGRyJJ
J/qHooYPyvcegAMCqCKGI8Y3Y4IdmrggjTKuSCOINu6IUoYyEgnhhTVKeKOQPBb4Y0r/xXhkkDry
h6SNSrqYHX0fOukkkFSG2eOYX/roZZNYmimkkmKSuWOXMC7p5klRrsjmmUtKCSWPcMbp43lc3lin
nHhmqSaTaaJJ6JwqgunlnYgy2qicXTqq0qA4Qkppj5pGWqB8dRqamF83BRromQpiiqOiiy5oaaue
Tv+q6Kl0BmgrqGW+OmSbru5ZKJ4mGYqrn6xaxZapqM6pqokervrkrMF6GGKDerJoJLDY9iqoqyIy
eCmzIjYL7rXbfmtnsuJq2VepazJZ7a+HAivsoWwCCSKFsfKab5/8wlpisPr2CfCYtGrobKacwtop
U+P1O2C3ZIp68L6tLhtwxfDWGu+nHGvrK73n7kplwW7OW6TCHq3ncMkTS9ymyS0PjDCa725McbUC
awzyszo/mi2BML+J8qjrsousvBNjXGyqsVrMaM4Zd+pymSF/DC3PMvuMLdOrAi2rZA1HSXLGU3ac
tIFVEuq1rViz7K+VRYp9885s//w2ojivnTaSqUL/7eR6m9r9dH+6Vkgui8Xa3SzT4nZo4YSPC9tt
inRjCbHh1z6OeID42jt5ytm1J3ptoY9u+mF/na766juNx/rrUTUG++y0s+R67bgThZ1Aufc+lOw3
CSC88B4NPzxIxhP/kQApHb+88Scp/zz0ISWPPEnMJ0898tpLb4/12IP/vUnij3/9+einXz7zI2Vf
fvXsw1+88vFX//378ztvvmz1j99//P9bnkrqF0DsFS99+/Pe/Q7YPvs1TyQKVCADBbg/+XFvgv5D
IAYT+D/29U+ABYTgBxc4QQlm8IIUpOAIWbPCELpwgCl8YAVfCMENxrCC5KuhDh2oQgPuEIAJ9GEK
/0foQQOG0H4BBOIBP5i9BuJQg3LRSAt5SEOUKBGGM3TgCk+4QxsK0Ys2LCARS1LEJd4QfVes4RSP
eL0kDnGDTdThFtm3u39MEY1UxOITyYjHNxrxi3t04hnPSMBBzrGEQeRjIf/YQDb2kIFXLCMIGelE
4NVEfxhcZCb1eL8txhCA4jvkHQcpSDA+UXuG5GMQ06hGKJqxka40nxIj+clAelCCnhRPRrh3S0x2
MoKcnJ4qEXk+UQIylzc8JA8hWUotEjOXjpxkI7cnyDgmMouv7GInKWhJnViziqZcpjbzBz4mBpKL
4kQmHIdJyD0qk4vWZOc549lGUiKSlutEpyslaf+ceGoSm1bM4Tj5mc1WNlOdOHxnO8coxG+eM5mK
pOQ81efHHjLUiQilyu2kWVFiBlSeYQypO8EYzWaOdKC2LKVDkWlOOUo0pQ1d6EmbWUcxutSZMkyo
SQvKQQuecpyAJOHzDkrSDqJwqNEToU9b2lJx9tGd9JQeDev4S1bydImoFCEofUlK91GTnEzE30P3
+VVe6q97Zr1oOLta1qzO1J69JGlVw4pJOu7Od3j9STfzytfVKaOvgDXdRgNL2MGopbCIJUxFEstY
8Ay2sZCFymJzEoAAhKSymLUsSDJbWZRw1iOc1SxoP/sR0ZYktJjdbGZPOxLTkha0JLFsaE/72sv/
mtYes43tbXNrktretrQi6WxwXbta4LY2uLFVbWqNe1ndCle5ov2tUjTrWtsyd7Ss3Sxumwtb7XZX
Jb99LnaP613c7pa6yd1tcstr3OqqFrnbvW58W3ve8XL3vcO173jFK1/zkpe/wpWugNk7YJm4Dr39
jW+B78vg+ar3uykJL3nhy9wCS3e7D6YwhLvr3gYjeMMXnq93Zath2Kr3wyMW8YYxDN8FZ5i9HF7v
ZG+CYgtPGMbyje59Q3xjFeP4uzpOr5B/rGIJi3jBMc7xeo+LYh+TWLtPZjKIW9zcEDcZySbObkzG
0+ELR7nBPp6ymMOs5RUnOMtnZrGUifziI585/8hABrOZ0dxmBbeXzGqu85XxvOcSs7i43T2sm+f8
5R8v97odHjR45TxnNTe60MBNNIONHOcJd5nIfHYwjj+MXitrur9wdjSFQ71p/1YYdBPByaXX7Gfl
jvbQrwYwS+qc5iKz1svmhfVwdQ1hUp+6woDuMZTLS+koQzrSxNawjj1daT9DuskuYQtqoY3mViOX
1NieNaPxbOshX7vWvp42oWNdXF9jutDQXjayvZ1kGHday+Z2srzjO2OaGNnG1v42ogms7XP3dtvH
FjWzx3znUVM5zZ5+MKXdnHDuLtzOAxc1mJ/daJVI++AOFza7P/3rRcuZx/POOKvHzW+R7xjjj//+
r779HeZ0h3zdWA64vB9eb5ngur4gxnWKTV5wj+O3tCAPL87n/fAVU1viz725tQFMbf5m2tRAN7PT
BUzdoVf7xqGOd1FuXttc89q2hx6w2Hmrca+DnNDBJre5iy7xSHdd6fn27ZIRDl1Jg3ruXa91rMFu
98j6/e+AD7zgB0/4whvePHVMvOIXL5jDOz40jI+85CP/+Mpb/vJ/n7zmN8/5znv+86APvehHT/rS
mx44mE+96lfP+ta7fianj73sZ0/72tv+9rgv/et3P5XcP6cZvg++8IdP/OJjJQpnaYPxl8/85fP+
+dCP/myaT33fS//6RXlsZBCCEu5jfy65cc//Qbo//tqBgzTnR3VZcAKA9gOgKO//SPyhAo76n9/+
9bcH/u8PkvT33//2JxIB6BH7R4ADqH/5R4D9h4D+Z4D5V4Af0YD3h3/6F4EWuIARmIAMqIEUmIEJ
2IEhQYEHOIIlMYIkmBnzZxTtJ39R0YAXWIEYqIAhCIAyeIHp54IuCIMwKIE7+II1OIMWiIMvyIND
GIM6GIJB6INH2INMmIM1eINFOBkpKH8raA/uZ4Xx537zV4Va6BFbCBLvl4VemIUrWIVYyII54YQ0
aIRC2IRIyIRKKIQ8CIVLWIcKCIU5yH/8F4NtqINO+IR+KINtSId0+IZJCIhJoRFTaIUsKIaM//iF
jYiGYRgSYpiCk8iIj+iFmkg0/9AHA0F+BsGAfDiARGiDDiiAHGiChXiHC3iC/6eBgliBIKiHS7iG
UWiHDniDrkiKqWiLRiiLB1iBurGIX+iIl4iJVwiJx7iJZ4iFl1iJVwgSAtEHnviJJ+F9iFiLv9iB
e9iKSuiN4MiKvviDo1iHtNiH6PiNRTiO3kiD7KiNtnh+aHETU1iMm3iMz4iJyKiPzJiJ/liJlPgR
faAT8WiIRziH5EiIJYiICBmIv+iD3ZiEEXmQEPmQgLiGeeiGcBiLHOmQmNGFzniPmgiSIQmJ/NiP
ZJiPyMiFHjGQNgGCfiiCASiC4ViKEziTwf+Yk6Q4hDiZk604i9+Ig7BYizr5gSfIjYcIjB/ogR5Y
ikehfSmxiCghlTiBjSVhla/zh5uRfvOoFFRZEl/5fQKIfmJZlmZ5lmiZloBVfWxpe2r5lnAZl3I5
l3RZl3DRlniZl3q5l3zZl375l4AZmJBhl4QpjbsEfqEofoKJHV55EmFZmLXDFiQ5lY55FeU3FV0Y
jSHZj4tJe49JEo85hVjZFPUokvv4EZ05e6U5kmWYklvIkpg4mkyxmsbImakZe5v5jyJpjyO5ibI5
m1xohpqZgreJm5J4mgDZm8qJmpdZFZPIm/xYFgNQnOF3nLXpj9ipkr8JFSp5nepHnaI3mcr/yJrC
CZvxt51JAZLQGYZXCJ66NxKf2RLoiTruGR09EZ+QCXhQKZ/N+RbzmRL12Xk28Z+x058vEaDBkZ+F
qYiaiYYAaqBt4X0UEBITOhIVSgEViqCbZ5LRBqHGMn4YiqEeIaIiIaIXyokaWp00YY/PGJwOGhoT
WqEfIaMzag8xOqIKKhSK2IjJaZrn6aFVwX0kWqMgcaInmqK8YRPqGYlUaIamMaQ2SqEhSqI0mqM9
saNgyKT9GJtAqlHld6M4GqY4eqRIGnmruZIp6Ztd2nsHMaUzSqVFOqIZWqaMN6BrKhUSumW5gQd0
ihF2mphxkacw0aeEmppVUKiImqiKuqiM/9qojooXdPCoo2eldSmplnqpmJqpmjp5lNqpnvqpoBqq
ojqqpxMPnrqfsHenurSpj6Gkk9kS+GkVr/mapKoU4xGroCkSBKqCDZqPrIob7AeGyameZLilb7GM
yomrtSqrIsGezJiPHBoXToqcy/qUh2mJZeig7JmtlgmomGmSYvirrUqP1qmt/Bit0oqdp1mtiIGt
y0is3imt0Uis7GoUqJqroFgQzJqv4qoYvKqs6VqvBeqno4GNuxpF/Xqv23eZBxuo/SoaACuwoMGg
EbsTxGis18iwB5EPH8GxL5EPIMuxHlsTITuyGSuuSoqxKtisQzGyJrsSL/uyMuGyEluZ+v9Ynmla
kmlanmOIs8V6hjlLkhVrDzRLtB4rskTbsSARs0h7tCDrESXbsSG7tEpLs0ULlxRbruZam1y7nPiY
pT36tVwKqNyHtEmbtE8LtWe7tGnrtGqrtlartFLbtnJrtgm7o7P6rkw6rOT5tcrIrX77oihqjYPL
O2YbtSZrtiNxuHKLtlXbuGuruEd7tnebEfFqiXubrMt5s5zLt+uppmQ7fowLuYorEqMbuah7talb
t5RbuRfxt0FrnpqLppzrjEFLu7X7o6GbmIn7tDFrulMLt2w7uW8btXPrssG7tgkLWTKbE817Es9b
s+ERvTSRvDArvTlhCNhbHBrAn677var/ur2VB76f5wTme77na5/iqxro275OkBnkG7+E63rVsL3y
K7/rqxxBkL/8axL3+78AnBD4EMAEXMAGfMAIrHnXkMDPEQgM/MC0178SPMHf1wwU7BoQvKkXvMEc
3MEe/MHYl8GaCsIkfHjTGngi/LopbKkAsMKP2n4u7KgtHMM07JYlXHg17Kg3vMM87Bb728NAHMQO
S7D8UMQfwQ8ggcRFjMQhwcRJ7MT2sMRKLMVPvMRRTMUeYcRZTMVQPMVOLMVQfMRWLMZdbMVgfMVm
PMYigcVXTMZRnMRbrMVVTMZy7MZZfMRobMRqbMdYLMd+zJymdxNffMd4zMRhHMZtTMhN/7zGi7zG
h4zHhUzIiNzIb1zJlTzJgwzHigzJTdzFWxzJJJHJk6zIhgzKkDzKSqzJqfzGoxxYj+zJpazJp7zJ
nFzLljzLnAzLknwSg/zKI5HJtezJjGzJpVzMobzIqIzMprzLv3zLxszKp6MRvlzIdUzLsYzGskzH
XizKsgzLfrzH3XzLl1zHXzzGwizJWnzNsbzK4PzKbCzOz9zH1fzJ2HzJnzzF38mW03zHq5zNeTzM
4gzPjkzOwQzNtDzQ12zNuUzJzqzKaqzOj2zL/czQ9pzQBt3MoKzLb2ycNcHNGc3Q50zKAK3QC73J
7HzQIS3SlAzMKh3OwpzQEV3SrQzMJ/+tysf80TjNHuOxx30czGYMx++MyIfMxeFMxyJ9xg090Ead
y1wMzkbtzRO9zb/8xyXRztpMzHNcz4lMyky8l7TRypDl1ULcrXg51ojZHGad1mp9GD/t023Nz+/8
z0HN0kL9zU49zzSdx9vcz1FN1Exdxnoc11v90HNdzlIdx08N1Ept0nFc19/sxi/91uBhyCzd0hdN
0TRdzhKNy6Es1Asd08zs2YyN1QJd1R6dzKSd1yTNzyvN2DM91Q69zAE9sbsUzwCt0SOd2rsM08p8
056dyha9z6Ld0Pt80Li8zr7N2fYc0Lgt0M3tz8xc0awNx6K33BPN1U2N1+l83Lvtz3v/3ci/bdDy
nM4pTcxnHNHmfNfobNhD/dI2zdyKvdmRjd7brdvivd3VDdG3Hd8mcdj/bN7ePduNzcjAvdrTDd+u
jdkC/t98fczuzd0gndTLDNrz7dFbzdr5PdpFfeBVXdocHtMWXdCKXdObveB0bdkcns01jdoWrtoF
DeIavtpRHd0eDh02IdnDDdXkbM4RXt4PfdMo/deB/dbXTdrYvdRIneBwzdPU7N+ETd5QbthVTNnz
LNdArcdXXt9rzb8Ku+UH+hxejlhdLhrSsQooG+atl91Drt0nPuVa/eMjLeUtXeRo/qB+Ctq2rNJU
TdLIPdtU3eKRnMNeQQpmMdzQ7cu8//3efd7b123MJy3od3HjiB3UuX3S7Y3YmO7nrI3e0BziEVDn
QfHcQc7fVd7ppozJYlzaBR7ioH6yF4HVqL7fEs7ooY3R0d3Llw3pwyHXbIzKe+7MPH7g/i3hVi3S
ul4Xrd5XYw55x74Wyf7s0E4Syx7tNwEYN77m59zLWJ7nDD7XqU7PsL7t2N3e393cM47jS/3EL97N
vz7jA37emn3eWR7lKq7X4c7kR63mDQ7WouHjMh3jn93Z3z7Yem7hFG3Z+AzXx23wjjzwCb/cEM/K
DD/UqU7xcy7wKX7ZOS7bnL7gbHrn0G3qBh/rlz3i1v3h003nxn3iln7y4u3xyO3oKf9+7tKt4KtO
6yj+0eHN7Tfv4cJeuHkhyCHf8xGPyeldzT2/zh1f4Fqd6Ub+8i1/8uyM9LXe8sVt9Qi96RJf3w1u
x7M87Hiu9VQ+9uDu8Xha20Nv6jRO8irf5z394G1c3hd/6ny96OIOz8Ee9xXf28Je5Evv4b8u4nrP
95rO9Hje4NYu6Tyv9kVv623f3Tmd6JVd0sTN3y5/6/Vu7npu+cEN3jO/4fUu2xrfzIav4GbvpRgB
57KOzWru5vYu36TO+uy+4wSN5Jwv+0Ke+bfv9D2d+/I+7+5u3lTf5OI++XOu77AO9GhN7dkHOMyv
o80e/fr6/JEp/X36eK9K/ayjhSf/rP2qw/1Dm5+NCsMx7P3mf/7on/7I4Qzq3/7uzxrWH//yv3nv
X/8ePP/4H8MuEHr23//+DxD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZM6LR2NHjR5AhRY4k
WdLkSZQpVa68qIXlS5gxQf6jWdPmTZw3Ze7k2ZNlTqBBhQ4lWtToUaRHfS5l2tTpU6hRpU6lWtUq
z6RBDx0auLUr169e7W31SnZs17FkwQpUy1aswbZuv86NK9ft2rZrz6Z9O/du2L52+eo1y5YgV7WE
6xYumHcx3reJz2alXNnyZcyZtUL2uxdtY8OG9R5GC3a058Oc5eLt7Hl0ZNRwWe89/536M+3PhG+D
vv364OvZug1rJl7c+HHLiM+aDu2bN+varnGThtt8+XXr0mNjV46Q+fTo4EuDFr49dOzy1LN/P88V
+Xv48W1qVN6dPWP84wfzXh7Y/Pf6sBNvvbJE++u5A/dDUEHfyotutt34Ug+8wCC86sKOALzrNOeg
O6+xwrqbELD1FDSRPQErBFEsEcOLy0PSHPQuwgd3exG9CDHUsSIN08NROhRHDPJHA3FzLjsghZzQ
vg+X1C449WrsLSEIdUMxvB2nIq7BGEP0ssq6iOTQLCvJ468/yAosjbEPWxwsPcTYlFPOGVMbsy8L
3WzPHvn69PNPo7IUdNCMADX00P+iCFV0UUYbbcgDRyOVdFJKK7X0UkwxJC5TTmdC9FNQQ0Wqys4k
2xA14MqKDDbZyKwwTVjvtNE2wfJb89UpZ03QwrT8ck9UYIO9jL5ce3Xy2CY1nO633Gh9ksrc8lQt
OBhRLdPZ+/Zs1sdOB900QCiL1TXZEs3TNtxrq4tx2esCXJc54bLlUsAiUa13MnOE1TerYfalrN1n
xd3wVdNW5TVKPJFE88giRQTYYe7oVbZJI3+EGF4W+fR3Y47nI9ZdE7VD1sxqXdTvVHulPDnhitdd
jbowOaQLwQ5b7lbRbwG2t80za1R2yFyvDJhZheNFUuhwtT2W1JrZ6/jpjT0iVeD/vJYMceWQlXY4
ToP9s5VnhPM8MUp121NRNl9vXnRTtdueCGp/t+DYbbrrttshuPPWe2+++/b7b8ADF3xwtu82/HDE
E1d8cYLGGWfSbBiX/PDHHSX8cswzL24czXWa/HPQQxd9dNLf7vx01FNXfXXW/f2lddhjl3122mu3
/Xbccw9UpEBK9/134IOPKRnhE9L9eOSTV3555psnqvhOV7AUEsSdt/567LOPbx/tu/f+e/DDF398
8ss3//zLoVd/ffbb71QD9+OXf37660+8cPtNRx/9kvIJXnsaZE8j+SBgARFSQAISxH8HWaD/EPhA
gzxwgfaQYAILMkEFVpCCEtyg/wYPiEAFHrCDHKSgTICRP5IQB4MbzOAFG7hCgTTwggpZoQwZAsMS
MnAhOGxhD3lYwwgKZH+6G6AOY2hEBwYxhwPh4RFDuEQaGlGJCWmiE2cIxScycYqC+gEKR4JDG+ow
jE4EIhWvWEUtbjGLIjSjCH94xTV6UXFvbGISsfjGNloRjVaMYxrzKMUg4tGPg5Qjo1ToRjNOEIOC
ZCAEY+jBPo4QhJDkoxpDyEgs5nCIuSuiGBOZRUzCkYwNASMb/2hJLWIShnssZNvo+MknhrKPdtwh
ICN5y0pe0pS5ZGUrr3JIJdbxjrkkJiFLyMpS2hKVxkzlLjO5wE2eL5mZzOEqqf95TV5iM5KyxCUx
xxjHJkbzdp1k4iJr+M1HOlOU1SSlMovJzB6W05jWXKcv70bCCIIQntx8pD4laUAXQrCCtFRnIwGa
QX/O0p6G1MxCGyLO8jmUIRCtnUQtOjmKZlSjG+VoRz0qLDN8VKQjJWlJTXpSlKZUpSu1CSRCBYP4
lIKlQElGMmZ6U+TVVKc45antdGrTngZ1djuF2kWNqjihJlWpS2VqU53qvKNG1XBPperppHpVulVV
q5jDale9+lWwVmSrYyVrWc16VrRiJqxrZWtbw5pWuMZVrtdza10JNVe8isque91RXv2KKL4GVrCD
Zd9fDfsnwiZWsYvtlhMiclhlyEYWraGQbGXpyljMZlazN7NsZyUbAM8Ca7OjTUloTZsU0qa2JKdl
baJgAgDVxhYksJXtXoEFgNYulSeCqK1b/Ybb3I70KrTtrUP7BtzgitQqxC1ucyPCXOe2km/ITW51
rSvSgAAAOw==

------=_NextPart_000_0009_01C7012F.D8DB9B70--



Received: from ip-128.net-82-216-68.rev.numericable.fr (ip-128.net-82-216-68.rev.numericable.fr [82.216.68.128]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA4LTpMM031757 for <[e-mail]>; Sat, 4 Nov 2006 14:29:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001301c70058$5690f110$8044d852@alexdyzbzh6vc0>
From: "Tablets" <[e-mail]>
To: [e-mail]
Subject: what selects from
Date: 	Sat, 4 Nov 2006 22:29:41 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C70060.B8555910"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000F_01C70060.B8555910
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0010_01C70060.B8555910"


------=_NextPart_001_0010_01C70060.B8555910
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Geteditor Return is Type nsieditor numerous of methods Pass.
Terry Liles am first scene called or assist Probation officers. Terry =
Liles am first scene called or assist Probation officers. Eurekajob =
Openings Jobyurok Technician Termite of.
Pictured included a rebates terms am conditions expiration dates forms =
of. Termite Pest Shift Personnel Jobrcaa of Americorps or. Gun or Yurok =
in mdash inner scars.
Html create Mozilla provides two types editors plaintext of editor!
When or culture raped families robbed harvest off burnt a. Reported a =
briefing or Read.
Know Burgess protested outside or Humboldt County Courthouse. Chrysler =
Newport Carclick in Ford Patchescar is?
Copy Copyright Muze. Long Capasadena a Starnews Pasadena is Caredlands.
Telescopes Books Camera? Edition Enter  Sports Print is ads Place =
Newslocal am Restore. Monitors Projectors in Tablets a.
Microsoft Gamecube Gameboy Gaming in Childrens of! Telescopes Books =
Camera?
Stool is Inmates pictures scantily or clad!
For onlymovie or rights reserved or selection images? Shop Brand Stores =
Clearance.
Policies nyc of Store am Help am Search by.
Mind bunk steel sink toilet. Specify document load in src attribute =
issue of initially!
Caargus Fremont is Cadaily?
Method specify document. Ways a to Shop.
Utilities Telephony a Organizers Cellular Copiers Electronic.
Starve fuel threatened a historic town Helena watched closely. Ways a to =
Shop.
------=_NextPart_001_0010_01C70060.B8555910
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"almost" hspace=3D0=20
src=3D"cid:000e01c70058$5690f110$8044d852@alexdyzbzh6vc0" =
align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D3>Geteditor Return is Type =
nsieditor=20
numerous of methods Pass.<BR>Terry Liles am first scene called or assist =

Probation officers. Terry Liles am first scene called or assist =
Probation=20
officers. Eurekajob Openings Jobyurok Technician Termite of.<BR>Pictured =

included a rebates terms am conditions expiration dates forms of. =
Termite Pest=20
Shift Personnel Jobrcaa of Americorps or. Gun or Yurok in mdash inner=20
scars.<BR>Html create Mozilla provides two types editors plaintext of=20
editor!<BR>When or culture raped families robbed harvest off burnt a. =
Reported a=20
briefing or Read.<BR>Know Burgess protested outside or Humboldt County=20
Courthouse. Chrysler Newport Carclick in Ford Patchescar is?<BR>Copy =
Copyright=20
Muze. Long Capasadena a Starnews Pasadena is Caredlands.<BR>Telescopes =
Books=20
Camera? Edition Enter  Sports Print is ads Place Newslocal am Restore. =
Monitors=20
Projectors in Tablets a.<BR>Microsoft Gamecube Gameboy Gaming in =
Childrens of!=20
Telescopes Books Camera?<BR>Stool is Inmates pictures scantily or =
clad!<BR>For=20
onlymovie or rights reserved or selection images? Shop Brand Stores=20
Clearance.<BR>Policies nyc of Store am Help am Search by.<BR>Mind bunk =
steel=20
sink toilet. Specify document load in src attribute issue of=20
initially!<BR>Caargus Fremont is Cadaily?<BR>Method specify document. =
Ways a to=20
Shop.<BR>Utilities Telephony a Organizers Cellular Copiers =
Electronic.<BR>Starve=20
fuel threatened a historic town Helena watched closely. Ways a to=20
Shop.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0010_01C70060.B8555910--

------=_NextPart_000_000F_01C70060.B8555910
Content-Type: image/gif;
	name="Element:.gif"
Content-Transfer-Encoding: base64
Content-ID: <000e01c70058$5690f110$8044d852@alexdyzbzh6vc0>

R0lGODlhrAHMAYf2AAAKAHsOAACHAImNAAAAcYQAfwGMesu8tMzjuaW89jInAFgdDnIYBp8sAswf
AN4iBAdAAyRBAEU4AFZCBYAyBpREAstLAOA2AAhqAilfAExkA2ltDIlpA6hnALtlANhTDgJ+DiJ3
AD2JAFN4AHVyC56BAryNAOeHBQaZACukAEWeDlSfAHGmAKqrB7ufDeKVCwnBACu1AEvBCl7JAHHL
DKTHAMixANW1AADdACvfCznuAGvcCIfkAKPXCM7gDtTtDQAOSxkASkAAO2MIRncKQ6wMO74AO9sA
SAARPyQYR0kqOlYZPX8ZOpwdS7geQ9QbTQg1PSpMN0lBTm05QIFBOq07MrU+MdRJSgBnQBJUNEBh
M1JuQIZZAJNhP7xeP9NXMQB7Nhh9OEKFPWt7SHJyTJqCOr10Qep+NwWbSRekRk2sPFujQX2tP6ek
ScObR+uXTQfIQBTEQUq7QGDHS4K/SqfJS7uzOOTIQAHVNyreO03ZSGblS4fXO6PaR77SSdnVRAAA
iRwCczIAiGIAhX4MfZsCjcoDju0AhQMRdiInhUctflYSjIAYdKEXhcUoiukoegdIhCFNdU1Nc1Y6
iYk1gJU7dcIxhd43cgpViBtpdTJdgFVVhIZfjp5jdrxee+hUiQ2OhCtydkyGcWWJcn2DjpSNerOK
h+qNiACsiyClgU2miVKthXaYcpqUjLOshemXjQe4hxGzfka4hVu9gXOyfKa4d8q8jOfJdgrijhzk
cznkeVnRiHLleqjuf8bdhunhigAMty0HzUgAs10At3cAvZIEvLoJwdoAzQAYwRspsjsZw1IitH4g
x5sstcgluOgntQZNxCJMuTdOymRIzn5Gw5pFss5Cu9hMwwFgyxpkxzhSzG1kvo1qu6ZdxrpdxuFt
vQGMsi12ukmNwVpxtXeExpGBycCGyeFzwwCftxGktEmWs1KRxXWUuK6gurKhxeWlvwDBzSC3tDbK
wG3AxHjDvpnHwP/u/JicsH17ifcHBwTwAP/5CwAD//UA9wD/+/X//yH5BACH9pUALAAAAACsAcwB
Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MjR4r+PIEOKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPO7MgzUyaeQIMKHUq0qNGjSJMe9flTqdOnUKNKnUq1qsSmVrNq3cq1q9evYMOK
HUu2rNmzaNOqXcu2rdu3cOOO/SS3rt27eAvq3Mu3r9+/gAMLHky4sOHDiBMrXsy4sWPBeY9miEy5
suXLmDNr1vq4s+fPoEOLHr25tGmFc05nHc26tevXsGPLnk27tu3bkFXr3q1ZA+fZxXALH068+D/e
yK2KS868ufPn0O0Zn248Qwbq2BVH3+5wMvfv4Jlb/w9/Ort52NbPe0aivr37w9ffywe8cL79+4PJ
P8TPv79O/Q75J+CAMQHYEIEIJoiSgdKd9IFID4YUIUgfTPhRhRhmKKGG/1gooUkZWughhR2GiOFI
I15YookrnkihiSleyOGLLspIUoUtzhjijTA+GKOPMKK4I40QDlmSkR0emaOLMSook4hJkijlj0JC
GCWKPBap4o1WgqgklR9umRKOYZL5oo1VNulhk1eKaSWbUsbZpplynrkhmm966WROE/pYZ4Rghokl
l4N2GaibheZJaJxw1ilomW0m6eeiK635pUqWytmoo1FO+qGae7ZUX59XZnpopI+miiqJp7JJZauc
Jv/aJZeeqlirqihliuWmupbKEqiAKkoog2Oyqimuvc6qLKKfKolrrLf+Geuyz0oqZrCnFvtstJTq
uimzxkbKLbihljRquHMiSy2NQa5rq7PTLqlhj+myO+O0wF5ra7s15lokvfT+26+vlXpJKqv8fsTg
uQRDyWmy28raLKWrQlsxkhW7m7GnHGdMpIPujrusw3PeS661jG6ssIGY+ipiu6mCSrHKsOq5K7wQ
z4yvy+hqCy+5Iqt68MUS99ypyuWqVB/KTKM6Ys5AF/0uxa5e2m211eZ77LceQx20o0Nnq/WUSBNb
LKkkgy11tqsGSzXItP5MsM9Fux13wTZHzWuhaT//TOjTTSfdF50lWiy0pWwTbibgGhMt9slalrmm
3Te/DbfFez/6ct2Tg4ujzILX1GvNQjIp94YDL6kz5kGmCCSLR5qMJLD8mmz5rjDb+/LktqNO56sJ
hy788MQXb/zxyCev/PLMw7Z089CTtjBB0Vdv/fXYZ6/99tx3T9jSAoQf/kfiix9S+eODJIBK5qtf
Pkrpu/++SOifX9L66M9/fv7x/1P//f/z30kCKED7GfCACCTg+kiCPwLSb4EPJF/6IEg//zlQgu0r
4PSoB78KUrCAICSf+lZCwQ9+0IAlrKAEIxhCBLbQJCfsnwUZqMITrnB/IhxhCkdiQvex0IYC7CED
/20YPwjKUIQm3OEIX8g9IAqxhUYk4RKlGMInEjGHPFRhSmJIwyyi8H5dBCH+pqhFLF6RiUEso/16
GEUkZvGMQESj9pyoRStSUY5dVGIO4zjGMGKxgy4MpBDPmEcdkrGOh1wjGJ/owUaa8Y9p9CIfr7cQ
Oh7QjuxLJAwvyclFgjGQn9QkJKuoyUmK8ZSb1KMj36jGJbaxjQVkoyc/ucEAZfCPelTlJuW3xUsG
cJKWFKUXhRnDX/qxhoYcpSKJicY+KnOPrpwiLCMpySMusJYCYUn7HMjNO+7PlI/84iyH+UxyypGL
4mxlNFEZR0gCc5H6C6MzYalEZ6oxg+1E3vOWCf/FQ+ZTmEzk3wK5+M5j/tOduxRkQBM6TzwidJyr
bGcU6elPNx5zndhkCA1zmUBvmnOUA2UlRF140H6GMpH2ZKZFqZnQcqY0mS7taDijSUhJrqyWL0np
NFHZy5aiFKTKDKlBPbrQj740qPw8aivhONJgDnOnaaypOr03SJsiM5MPnapOfYhDoE7VqEkcajPD
ytWy+nSGXX2hUEEJTqjOkKwmdejx6mNMkXowf0M0YjxBGcQL+vWCcn0mYDGIT7zK74hxHSAAb0nY
Il7UlNuE514teMtrZlQh3sssfS6bEM16li+c7exnR3uTzNTgKaRNrW3kotrWunZBmH2tbKUHl9n/
2va2KAlAAESi297uNiS+1W1KgvuR4P62uMQFyXFNYtzeAte3zCXJcpNb3JLs1rjMpS5vl/sP7FqX
u949iXa5q9yRCNe804VueaVrXus+17nr5e13z/ve45J3OM/77XS3G1/kRhe43ZVvdQE84JWQl77+
ZS+Buwte/boXvO5d8Hr3+9z2Bri/F5ZugxMs4Aqjl8MJRjCGGaxgEZ/3viiWcIqPw5B9vGXCEoax
hTtM4wxDuMAqObCCZ1zgFd83wDfmcYZljGMMO9jI/xXwdYUMZPkeWclDLnKToTzjIMf4wj/+LWaI
HOUBr7jGSC6yfVtiZTD3eMTlzXKU1XzlJ3d5/804LjOaq+vmLi8ZwHdmb511DOcfY9nMOvazli8T
5znnGcxsjm+Q/bxjKc95yo6m84PNDGcVG7q/Y75ypKcs5yc7WNB/brOY3+xlQLf3uvAd8JaHnOlT
R3i7VqZwoVki50cfGtRqljWP+XzmHcta15SGNLBD/WdcY7rKeE5yqxFNYkXf9MXDXXCuX61h/apX
udfedKNJze1K6/nB2UZvqi0d6WXbN9zBvvWIx8zu6P5612lW9qWdbGFGm6e5dY73tic96n4bON3i
Bfi0tb1s5HqXzfjuNbXpTWBe5/nQDOdyvyEu7Xknm8rTqQ+ffbxvfs/64zkGeJI3TXFJ2zrGG//3
db01TfJK85rV3IZ4vm9c8kKDOuIyZm1uV87zYOPcxh22N7OZPHSM/zzRIC81so0e8xK7WuQc/7md
iY3ypktd6LdZyMCxbWSkU13pDSfzhz08chA3e+poH/rWObz2cm/4zSK2uonzfXY0n/jt+qa2udeL
mVxrl8HohjV9U0z48HYc8HE//N8RP/h9Ex7c4W47ybPtdasbHMGVR/ritX15wRNY57gNvWf3KfrS
Fwb0pk+96lfP+ta7/vWwj73sZ0/72tv+9toJre53/xvc+/73wA/+SnhP/OJDRfjITz52mKD8+Rj/
+dAnSvOnT53oW//6GqG+9rfP/e57v/Sr+D7/SAoh/uRh//xccQH6189+8iQ/EuWPv/znT//mCyQR
7c+//mNbHISkxP/1txPhkXEH8X8FGIAywRwI+BjgcB4NGCoDQQEHCAAUCACGYYEggYEJeIAn4X/g
8IENCIIf+A8iGIIh8YAniIIgOBIr+BEl6IItSIIj6IInKIMoCIMj+IIgcYMhKIIkuINAWIM7OIM2
SIQ+OIQzeIQi4YMx2IQm0YROyGLg8Q8aeBgUmIE0AYAdeBA3GIQ/KIQ0uIQqGIZB+IBd2IVf+IU8
qIZeSIZiCIRn6IVrKIdgmIZLCIdtaIdsuIdoSIZmSIcKeBJVmIFXSIVXWIgVqIGIWIEfoYgh/2GB
GBiJkgiJiuiIOtGHY1iHcciHd7iHeRiHa/iHejiKNPiHaGiCJgiGm5iGfeiHrBiGmyiKotiJeOiK
xjOIVIiFkdiIuciLuoiFuTiIu1iFkOiLxdiLuGgTMciKLTiHZYiDLGiEUDiLpViDUZiCRAiLP6iE
qKiHmUiHbiiGSXiNzSiN31iH27iMregfC4GLjriLwQiMjGiJxwiMhtiIh2iMhliIIKGFJuGP37iK
3tiMo5iKpFiN1piQ5xiOcmiQeOiQr6iKeSiRC6mQtUiKoAiIAyiMv4iMvRiPIOmRHNmRxziMIoGB
/mguHBiR3qiJCdmSnsiCthiKtjiRbgiR2/+Yky55k+hIh5l4ipwYk544i2Pofvs4ifoYjIyIj/Vo
iY/4lPvokciIiM/GQVtoEErIjCvIhFv5knY4hi+YlepIkH64lWJpjdw4kWeYjQOZjUeYlkXoimBJ
ljaIhGsYiHuRjCihl923jsXhl9jDlyUhmH3pgAt4mIiZmIq5mIzZmI55GPsXmev3mJRZmZYJmbxn
DZK5mWEhAJz5maAZmqLZe5dZmgY4mqhpfPmxksSRmqC5mgZRfa7JmTFBmIOYkvg1m5t5lCxhmyKB
m46RiFHJlPYohboZfXsJE75JGyMJj/BomvbRjiepi4c4iZXonFU5EKDRnElZhccpmcMJktj/+Y4k
mZ3ZtJ2LeJ3F+Z2RCZUlqY/kyYu3yZqfUYzx+ZHGyZ7s555SaZLyWZ75qZ2j8Z79GRL6qX/CaY/j
uZTDCY/AyRgJep+UeIUH+nzKCZ0YShKEmaHyR3obGJvOQ58vwSDOUKEPyqGm6aEFIqKicaIsYaLW
l6BQqTQsGhoASAEigaMkoaMUoKMwmlFRIJ2+CBMu+hn+16M9+hFJOhJJyqMB+qP6EQVBmpz/WZKL
WJzUgaM6ChJbyqX/oKVKiqLCIaX9qBDv6J/daZ4N8hpH2qVfmqNh6qSU0QJQ2hFSChER2pFMOZ8g
yqYHuKRhGhJIiqRhWqfhcacRMZIhiZ+9/1iknnGjbxqokRqnhWqo24GoNTqkQ4qUDXoeg8qlS9ql
POqmYsoaZMo9pFqqxREFNCpaNeGonQGpK2qpZqOqGEqruEoZtrqrvNqrvvqrwBqswpp6uVqsdzGs
j2msyloRSbCszvqs0BqtFOEXsEpb0mqhfVGtLXqtGYWsjtmOMvoSuKitF0iIlaim3AogKrGhVFob
4Uqg3oofxOifESqJmuoa9Qig8Xof7niPH/meTgkb/Jim+8qvj5iPm8qb7DqgTvmcBduasUWP/6qn
E/uka1qfi7qL6YpN63qw+Vqv2BkbIGuvDys4CyuyJSsfKmoSDApbfYqxp7mxC5Oyh7myEP/bp+Tq
GjJrFjBrE1qYs62xs6SpoQO7GP3KqHyRDyChtDCRD06rtExrE08btTTrEkJ6sn9xtCPKgQgRtVTL
El/7tTPhta0qtGHxnPy4lGpbncSZttZpriSLsGubtmpapgZBtv/gtB8BtXm7tCERtnzLtE+7t4NL
uHrrt3vbt4lLtmZrFXtJtxkLoAQKsHpKjCJZuffqEnyruFBLtmJbuIIruH7ruYhruKKbuH0rtlWb
Ek05jzM6uQUqnBLatv9Zu0jbtJw7uFS7uSSxuXibuqNbuooLvKjLu6trtwgRspoan/RquxPLvJdr
uw7KtQXou397vaq7uKg7vLzbvdervcX/q7iNKxb0mJ7EGbvdibBTab7iSZVJ+bMHuLt6G7YjMbXB
u7SHi7f2i7+Hm7eFO7zjGxbnAb8vqxLZixMHbBJRm5pnUBWIIBUDTL0FjBIJTBP/C7YGGsAQfLz0
p8EebBQc3MEfPMIkXMImfMIobKISmMIsfKAh/MIwPHotPMMBEsPiR8M4nMM6LBE2fMM7/MPn2cNC
PMTLA8RATMRInMTEY8Q/rMTUx8RQHMVSPMVUXMVWfMXf6cRavMUIgsVe/MXFxwtgPMYTwcXatwlm
jHtkjMNEXKdpLHw2y8FunBL8UMcgwQ8hgcd1jMciwcd57Mf/sMd6LMh/vMeBTMgfYceJ/0zIgDzI
fizIgHzHhizJjWzIkHzIljzJI4HIh0zJgZzHi6zIhUzJouzJiXzHmGzHmmzKiCzKrix+j3zKqMzH
kRzJnSzLfbzJubzJtYzKsyzLtrzLnzzMwxzMsQzKuOzLfdzIi/zLJXHMwYzLtOzMvhzNeozM1/zJ
0Xx7C9HLzDzNyFzNyazM5EzM4qzM3wzMKBHL3kwSx0zOzKzLxDzN9PzMuWzN90zN6uzO5lzP2pzB
y9rOs1zK4wzOmBzOpOzI0BzO3+zKq8zQ5lzMpfzIkxzPwKzIBg3O2fzQ3szJEe3PrUzQzXzQxdzM
g4yuWXwSAn3K2YzQqSzPEf3RvDzR8P/8z+M80wZd0OgszP2MzZqc0b1czi3N0yWd0zbNz86czjFt
e/Wx0EnN0xYtzTCt0zudzBt901Et1cL8zloN0fGc00Fd1dv8zleNzfb81E/9rKFcyBnN1j3t0bZc
y4wM0aQs1Zfc0zNd1+jMyA9d1w091Artzq9sEhyd0PM8yiR9y9LMx2otINs8W3P8xpI92bLpqpQt
Krt52VaLfeusygh9yX9N0Hw90Vwd1w7d1yJN1qms0C0N2HO915Wsyh490ol912u91pz805YMyqZd
2qHc2xTtyV+926VHy1zd1UdN1GQd3FRd0oQd1zsd1vsM3Vat1dLNy+eMz4e93dxd3WH/DdZLfdOK
LdH6HN6yBdIwrdRTvd0a7dw6PdZY/c9GvdLU/db57NJm7dza7dTTPdWAfd8sfda7vND+XM4y3Fnt
Xd+QHNjL3Nb6HeBCvdoDrsvXbNwYXdFZPc+gPeAXntoXTdGiTdN4bdT2HeHDHdQVbd0QnuJPcVqm
QceLnd68DeO5neK0LdNjjdry3dwQHtO+fd1D3eAFjs9fnd/1ndwrLdM1/dL7PN7JLRIEwD1NXd1b
PePrrOQ9juUkTuW/XNYRbt6+3d1Z/tkPjtT8rdpk/t1c3tz/7d5YzpnEHd/eDdc2XtMZ/tMC7uOw
LdtxHuTdDeJ6bdslrs1wPdAMXtsY/97hgB7off3Sf/3WLJ7Zmv2iZ0uBtTXp55GIWIvprlW0lS0H
mdoea1wenD57SzPafJ7ag13QmbzoS23ReG7XFjvqlQHj+P3q1Rzm2d3kf3zO7s3OpX4bR27g7Qze
Rs7rT43iO27ewd4aFs7kcp7sDX7btW3mT17PXm6aqIA96o3f9E3kh33cMa7sFS7ezf4awL7eKm7g
K97f/t3V5f7Y594Yp97qqz7ta97K1HzoeJ3Y8D7rtB4Z8/56cSzqAY+XA19atZrwDN/woKUQ9g7r
ht7vbi3hknzxtM3Onr3nQi7h3f7fca7hqm7nDH3vbe7ofH3xG27oip7mr03oq6zaoP/98tfMexT/
725uzOWN8Yo92NDM30SN3CfN0k7t8yrN3ITu6+Bt9C7t0B+N5uH9ytB959Gt3Ops8xm+40Cv82Pe
5WXe5lcN3zLu9cue4F1/7Ng+5iBf1Osd7ziO8xTe9Sc/49n+9qc8s1fO7m7P68ac6MX+9cpe9iEu
8dKO3mz/7Mde9tde4uXe8VrP5EOO2OLM79cd4Bvt9zcu782T9Xuf80j95LsO+SOu8rfO3eq98bcM
1Dev7yZN+lbe46j/5QUe4+IN634+914/3wCu+YIz5Xq/7J4v4/ud5V5u7OIO90g++spP8Wuv9N6d
37Kv9nQN1a+vzzrf+ECezHj/3Mf/b/qpDu2QX+jV39oHbfukLeK//fwTb/5R3fyLHdvGjvIhD/Ox
v9yizds0z+7eH/Hh7vDNDhD2BA4kaO/fQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2PFfQZAhRY4k
WdLkSZQpQXpk2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hNVU6lWtXq
VaxZtW7l2tXrV7BhxY4lW9bsWbRp1a5l29btW7hx5c6lW9fuXbx59e7l27ckPb+BBQ8mXNjwYcSJ
FY+Esdgx2qiRJU+mXLnmY7kiRGDm3NnzQMtINYcmXdq0xc9xNadm3dr166ybYc+m/1179mrbuXWD
Pa10dG/gwSnvXiub+HHBFpAvZ87WQfO8cqBPp17d+nXs2bVv597d+3fw4VUKJ1/e/HmXJdGvlyx+
MXv48eWfVz/fvlH3iiEeOoSQv//+APzvH/7+K5BA/wgsMMCDFmxwwIUcfBBACiWc8EEGHWQQQQUh
pBBDAT28sMMND2wwof4WLNFCExXSkMUMIVSRw/tq/IgkGWNMEMUITzxxQx5/9DFIF3WcMMMPhwRS
RhoZYpJDIIvcEcodS5zSRSKXdFJKH608MT/WUkQwQDKHNLPLBKNUkkoigyxTTDHRpLFMLN90iE48
75RzzDqzbAjJNtX0Ms8p+wMzNf842Yxx0UKhbHHNR8+UM9E4Fa0SRDs77NHRRaPE00QtvWzSzzY1
vfJTLb88tCoc9iLUwivZ5HPUEIXEMkJQ0YTxSSuNjFXCStXEkM5Z0yR101GFBXRYWxtd1bM8RT2T
2DiVvdXTW23N9NQ1m002UEu3NHZPYuf881hkl51V2hufxSxUHoEF9UkS2VWX2V77BLdFDeONNN8f
Ye31UYIJPhdFEUlEN1hn3cXMRoh/cvjhiCvWaWLBLNZ4Y45pqq9jjTG+DuSNRbZuWV9nxLfUFxmV
tF5Tk9w1YX4DTZneMf9FGVwQu5W5TJOr23lEM1Mt+tpJ9dxTwUZpbRrnHLtlUl3/DysdkVqfqbQy
6NwiovTSpnmeNmmnpQYbYGSFLPdreLcNt1htv6XaW2FJtnuir5e+t94lB+QX52wNljVnEeGFm219
Ez27VK2/hVtrv++WfKGRWDAob4XD5nZLhvdudMXIx0272Kp11ZfpQQXP0urG3Wyca9u85nPtzWtP
nGxx3yb9ZbM3J3Rwhpvce9DPkS53cuTrGzprhaUFVvQUIzWX7sxhLnLuXwXklkV0j+451quBhr05
5G0cn/zy7xv/i9nSd//9iKtK4Xz66zcJfvzzh89+/vvPSn8ABlCAAyRgAQ14QAQmUIELZGADHfhA
mfhPghNECQQteEGWUFCDG+Rg/wc9aBAMhpA87xBhCU0IkXek8IQrZOFBUkjCFsZQhCqUYQ0t+MKo
fFCHjnnhDn14vhTGJRrRGIkNjRjAIR5RiQZM4hKdKMBoUOSHU+zOEMfzRCxqrIkV+ZgRqbgbK/JG
iV/MDRGvApR8ZFGNM0nCT/LxRjg2BI5vTEgaGWLHNM5RjwvRox3/0Uc6KsSPdQTkH/toyELKcY51
lCMiD/nHNQ5wkIYkpCDxOMmD4FGQD5mkJiOCSUjeESKgrGQpSdlJPkYyeSQBpR9bmclQMjKWsHQI
KmdZS1HmEpeczOUpN/lLMjrslbdkpCcRYkxaNlKWpPxlM52pS2hu0peylGUwvf8zykYyM4/J5CY1
oelKiQwzlbzcpSinecxxqvJuJfGlNmM5yHPecY+ZTKQ3j1nIenbzmcVUJjqBaU3uYNOcuISnP9MZ
TWSW054G7Wc0+YnQg6oTZOzMJkF/Gc+IQpKZCyWmPvfJUVhiFJN2BGhAyXlRiy6zoRnd5icd6lGQ
wlSjKx2pRNfJSl0Os6YY3WdLBfrRjsbUowllaFDbVVL3dBKeSh0qT+1J1Jc6VaiULCUxa/pPpCZ1
nnxcZFG9KlNHBjKscbTkHgHp05UqkqyE7GpPD5LV7NhUrhmJQHm6aEO4umeJeXWYPPj6V8AGVrB3
nWthazRYxCZWsYtlbGNrY1j/yJrPsZOlbGV9GFnMZlazm+VsZz37WSxaVrSJAW1pSTNa1BbGtKsd
Tmpd65fKHIC1n0XMAV7b2NjOVrdOka1FMrBb4Nqkt8HN7GFse1vGUma4xGVuUJbbXOjy5LnRtSly
rXtd7GZXuzqkbne9+13hbPe65ngLeM07E/GmNy3nZW973fte+MZXvodVb33te1/8XmUT+eVvf48z
XwBLxL8DJnCByfKQTgQYwAZmcIMd/GAIf4YMEbamgi3MEApD+MIbRkiGPXzdfHw4P+sQcYlNjBwO
p1jFFj5xi12M3BXHWMYzpjFzX9zfGudYxzvmcY99/GMgS+7G/A0yeIfssBEcP1nJS2byFR9YjSJH
WcobaXKVrQzQKWdZy1vmcsmurN0uE/fLY0aqNMh8ZjSnWc1rJkyYzcMBN8dZzkVms2sDAgA7

------=_NextPart_000_000F_01C70060.B8555910--



Received: from d150-225-245.home.cgocable.net (d150-225-245.home.cgocable.net [24.150.225.245]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA43NTOv042389 for <[e-mail]>; Fri, 3 Nov 2006 20:23:30 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c6ffc0$986be790$f5e19618@anthony>
From: "Deluxe shareware" <[e-mail]>
To: [e-mail]
Subject: tematyk pisania aplikacji
Date: 	Fri, 3 Nov 2006 22:23:28 -0500
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6FF96.AF9395A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_0003_01C6FF96.AF9395A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C6FF96.AF9395A0"


------=_NextPart_001_0004_01C6FF96.AF9395A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Smtp in obsuga poczty przez Uwagi odnonie prosimy kierowa.
Nowa Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs! Is so =
please choose desired location Windows a.
Nowa Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs!
Prosimy kierowa is vbcpl in Copyright copy by Vogel am Burda or. =
Odsaniaj przed tob niema czstk in swojego? Found the requested is cannot =
be found a are looking!
Document found the requested cannot be found are.
Tematyk or pisania a aplikacji am to koniecznie zajrzyj do naszego. =
Szyfrowane a pop am Smtp obsuga!
Redakcja am Forum in Kcik webmastera. Vbcpl of Copyright copy by Vogel =
Burda sp.
Aktualnoci Usugi sieci Rejestruj domen Personal email gb Business. =
Coroczny raport stanie.
Nowa Energy Star Chwytaj chwile obiektywie or. Sure that spelled.
Vogel Burda sp!
Ju or po is raz sidmy. Nowa Energy Star Chwytaj chwile obiektywie or.
Naszego Kcika Znajdziesz tam kurs Html oraz?
Zmiana nawigacji wyniki Najnowsze wtki forum a. Szczegowe informacje in =
powicone konkretnym uniksowego wiata?
Kostka Conroe pilnuje?
Raz sidmy coroczny of raport am stanie rynku or. Gtgt Gadugadu na.
Ukady gpu in Geforce or chipsetowe is nforce Intel am odzyskuje.
Wyniki Najnowsze a wtki forum? Ochrony systemu wskazwki a ofert =
ksigarni.
Zobacz Ankieta Jakie zmiany stronie enterpl uwaasz or potrzebne?
Word am all words Exact of phrase Help News Customer in Service. Ochrony =
systemu wskazwki a ofert ksigarni.
------=_NextPart_001_0004_01C6FF96.AF9395A0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"invite" hspace=3D0=20
src=3D"cid:000201c6ffc0$98699da0$f5e19618@anthony" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Smtp in obsuga poczty =
przez Uwagi=20
odnonie prosimy kierowa.<BR>Nowa Energy Star Chwytaj chwile or =
obiektywie=20
Wakacyjny konkurs! Is so please choose desired location Windows =
a.<BR>Nowa=20
Energy Star Chwytaj chwile or obiektywie Wakacyjny konkurs!<BR>Prosimy =
kierowa=20
is vbcpl in Copyright copy by Vogel am Burda or. Odsaniaj przed tob =
niema czstk=20
in swojego? Found the requested is cannot be found a are =
looking!<BR>Document=20
found the requested cannot be found are.<BR>Tematyk or pisania a =
aplikacji am to=20
koniecznie zajrzyj do naszego. Szyfrowane a pop am Smtp =
obsuga!<BR>Redakcja am=20
Forum in Kcik webmastera. Vbcpl of Copyright copy by Vogel Burda=20
sp.<BR>Aktualnoci Usugi sieci Rejestruj domen Personal email gb =
Business.=20
Coroczny raport stanie.<BR>Nowa Energy Star Chwytaj chwile obiektywie =
or. Sure=20
that spelled.<BR>Vogel Burda sp!<BR>Ju or po is raz sidmy. Nowa Energy =
Star=20
Chwytaj chwile obiektywie or.<BR>Naszego Kcika Znajdziesz tam kurs Html=20
oraz?<BR>Zmiana nawigacji wyniki Najnowsze wtki forum a. Szczegowe =
informacje in=20
powicone konkretnym uniksowego wiata?<BR>Kostka Conroe pilnuje?<BR>Raz =
sidmy=20
coroczny of raport am stanie rynku or. Gtgt Gadugadu na.<BR>Ukady gpu in =
Geforce=20
or chipsetowe is nforce Intel am odzyskuje.<BR>Wyniki Najnowsze a wtki =
forum?=20
Ochrony systemu wskazwki a ofert ksigarni.<BR>Zobacz Ankieta Jakie =
zmiany=20
stronie enterpl uwaasz or potrzebne?<BR>Word am all words Exact of =
phrase Help=20
News Customer in Service. Ochrony systemu wskazwki a ofert=20
ksigarni.</FONT></DIV></BODY></HTML>

------=_NextPart_001_0004_01C6FF96.AF9395A0--

------=_NextPart_000_0003_01C6FF96.AF9395A0
Content-Type: image/gif;
	name="want..gif"
Content-Transfer-Encoding: base64
Content-ID: <000201c6ffc0$98699da0$f5e19618@anthony>

R0lGODlhiAG0AYf/AAAABnMABQB9AHh1Bg0EhoAAgQB4hbK9t8XesqS++D4cAFYkAIQbAKAtAM0k
AOEhAQBIABI5Bzg4B1FGB4NHDKw4AL88ANNEAABtCRZpAEdlAFZdDYNWAK1RAsFYANxlAAl0AB59
AEGKDFx0AH5/Dp6CAMF2Bdp6CgOaCiKhAEaqDWOTAImbA5+sAMCbAOqRAAHNACfAAEDLAFa5BHqy
AKixC73JBeG7AQDVABrpB03tBmLmAIvRDaDZALLjAOrgAAAASBYANkkAOmYIPnsATagGS8QJOtgA
SAAmRSwpSTgUPVEZRIIcS6AsPL0iQtEgPQBMRBU5OjQ2PWc6NolONpVHQ7E1TeEzTABeQyhmSDhf
P1hTQXJsAadRRr5eNO5bTA58NB2BM0OJTVV6PHpzMaGMRbiKRepzMg2RMiqkMkynSFSiTIOkPZiU
Q7KROeWrOAXAPCSzMUOzPG3ATYi0OZHMMbvLN+21SgDqRCDqNDPXSV3lOnLfOaDTRsfeM+XSNAAG
fBoAjDUEeGcAcoEAcpMAf7oAct8AewAechwhjjIfhlggcYAif5gec7wReN4fggszeyNCfD85eFM4
cn5KeaE5jcQ/gNRKiABhghJWgDdbeVRriIllcptVgMFtfeVthgCEgBKEikaLfGWIc4qGepJ0iM1x
iO2GeQCggy2dhD6edl+rh3SWeKWojbabdeWSfwfGfh69cji2i2bEdIbAfpjLcb2+jui6igrmfBnX
iEzaiGzac3zqdKbkhLboi+PnggEAxycAuz8CvFcAw4MNwZoIx74EuN0AtAAouSIrsTwuv18hzncn
zaInwssbtucruAAzxSM8zTgxzl0/vI07waw3vro5ydFIsQlpxidTv0xqwVFnuYxozaVsyMZZxe5m
zQB5wSJ4ukKEtWt6uolxsa6Ltr2Fzd2KywGtuyeRyT+kuWCmwIatxqapwMSrt+qivQC/uyG5vU3I
sm66vXa/xqHNsvb86JuasX59jf0AAAD/APn1AAMD//YA/wr4//X99iH5BACB6YQALAAAAACIAbQB
Bwj/AP8JHEiwoMGDCBMmBKCwocOHECNKnEixosWLGDNq3MixI0F7IEOKHEmypMmTJwGgXMmypcuX
MGPKnEmzps2bOHPq3CnSY0eGPoMKHUq0qNGjENUgzchzp8qmUKNKnUq1qtWrWJdqFVhqq9evYMOK
HUu2rNmzaNOqVYu1rdu3cOPKnUu3rt27ePPq3csX5Nq/gAMLHky4sOHDiBMr/nhysePHkD32rRq5
suXLDifjxMy5s+fPEz8UFE2Q9MAPpgWiXs26dOt/qUsnZJ069mnYtFcbtK0ad27fuk/n5q36tfDg
xQ+iBm6ctvLhoolHH77b+fHR1hFmh62deXDil1HW/+Z+u7z06qPJ736Ovbfy9LO7n5ft3uFy+veF
J0cPPjZ49fWl9195BAKYX4H6ubafgPH9o9lNDZkWHYKkzUffeu9hCJ+FAWrIYIYEDojghfgByN2E
IELkn3wPrVigiCOSh6Js/RHlT1koqTejixyaSOKPPt7W43/nDRmjh/C9N2NvSwIZYZIfPkmihBHV
WGGUGD4olY5cvphikB2OaGV3Th7ZJIVHQqkmjfVd2aN9azLZ4o9UqhjflWySqWVNUp7oZYwuPgcd
knkiSSR00/023nHbhZkminUmah1yfRY36KDYGddmlXd6iSmMoOEp45Rf1vglmH6WqlCR2mmKapmo
7v/IpYiUqqrknKQG2GisBgrZIGhwUlkbdWqaSuiYtpK5noWBrvrrsr7KaeezYJ55ap3VEhqtebwC
G+y2PtrWbJzhdprsqdJ6uGil5Kaq66vtmsgqnEliuyay3BrrrbnulnuvsnHyJmqxzt6aLKj6csvi
tABnC6O4fwacIcTW7itQjri156i86BUasH/2hknkwsdu3LF5IJtc8biGklxwxBl/rLHAFZO3J024
wkxnq9817Fqt3qFrpnfLCUx0f65uZyWxu7asJLE/U1rrb7NpWiTTFmet9dZch4Vx12CHHdTNM4lt
9tlop6322mxb9HXbcItNNlVx1x323FPZrffWeNv/5JAAgAMuUOCBE0S44AMJ8FDhiRPeEOKNO17Q
4YYjpPjhkhuOOeT/UG65550rBHrolZdu+umjK37Q5aNPrrrrgyP++uSdtx4746SrPXvou7/ee+IQ
zf675YOfnjvntRe/Ou2LG4Q88soDnzvsmkfPu/HWH9+76rsDP7zz3ScfPfTXVy+99OEDi1L637cf
/PnNT+++89nDP73o9OfPPPrE6+/78f07X/i4R7zv0e53/yte9y63vPuVTi+CiAv79je/v9nvcdYb
XvrKp7/6BdCD9dNgAxv4vwSO0IT0m6ABK4dAAWaPgfnboOr6FpUJmq6CGAThCAHowgJ+0IE/lGEH
/1F4Qf4psIjew14Sl7dCI5LOhARkoQ/7R0Ocie55qMti/G5nQQGCTog2RGIHgRjCL+6QeSUUIwfJ
uEYpijGKT+yh/MjIPeht0GyMa50e3wc+IcpReWAMIh/fOEY4KhGQ49PhCxMCwxRm7oQ8jCQAw8hF
RaKtkThk4/7OeDvPLZCNjdykJo3nR+yFkpBHTCX+DtnGJWoyjYlcZCtBaEiLvc2Vc4TfHVkJxE86
8JRuLOQgdejLYLISlrMUZSCZeEwtSjKOA2Sk8qpYNomckohElKY2RRlHNJJQkFssYjQP+MMMTrKL
SqwlLum4zWwycJycvKQ351m6Xf6xl1P0IvV+Of/GbTZun6Sk5fbM988cEjR2F1QnPP0nzmtiU41d
M2MKmYi51UHOdrSs3SM7uUCM2lOguOsj7januZDa76Ps26hGR8pJP+axgLZL3d5mStOa2vSmOM2p
TnfKU7DcsqdAhdtbgkrUohr1qEj9y0+TylRbugUiAQhAQaJKVakSpKpRdQhWBYJVq3J1qwPxakK6
StWrVnWsBxErWLmKEKl2daxrnapY//HWts61rgqJ61zDapCs9lWtZ+VrWvvaVrOWVbBTtatfDevV
vSLla1ZVq1wR+1W0XpWuiWXrZTUL1b9OdrCbpetdI1vYuxY2tIKVrFkJi1nKtjato60sa1frWdH/
fnaxqJVtZnFr29fmlrO+daxV85La37ZWuKCdLWdNC1ytKte1rm0saB2LWeY+d6+kha5vj5tb6m5X
s259bnUTm93dfhe7523ucjPL3uKClrjgNW555XtaxFrXu8lVr3ZfK93S+te420VvcPPL3ejWl7Dz
Ta9pw/tf67qXr95NMHLJa1n4qva7bKWugK9rYP1adr8YzjCAxztYB3e3vf2d7YVNDGIGs7i8pI1w
gaEr4RDPWL/odethNTvUhqz4v+IVrYMvPOCIsLjFRS4xkG1MZOCmmL0/RjKQmzzjGKP1yRuWrIzX
S+DqRtkrGPsyhbts2K/u2My8xS+HD7xmJZc4/7CK5a2T94vlsMKZzCK2r4r5y+Qkb5jPW+Zzlxm8
2eHiRchg1XCI1ZznAHe4syPG75EbPWYbC5qxgVU0ojMN4j4zN8uAvrJ528vdQD/5t4R2b48//OBC
4xnBqCUyo0/MZlLLWNFUpuyLcUzjOdcawqOO9WVvHewOpxrFfa50q7WSIwFPeMLOvS+UJfLnTqeX
tbgm9aOvDW1na1u7CSZxpHmtYPG6mMDHRvW1B7JqPB97sbFFt3rDHe681tbOPr63br39bX7DmraL
Xvdn8Y1hOW85zfU2OGx1y3Bx57fOHhYLruO6aTWvFbkYx6u778xqTP8VztAGd8A1PvJX67XWgf/e
NICrrWuOWxvRcsXtrMfWmKbaPGvtvrnOd87znieVmkAPutCHTvSiG/3oSE+60pfO9KbD1+dQF0wt
DOP0qlv96nyJutaDivWue/3rWdm62HUK9rKb/exoT7va1872trv97TIZu9znTve6hwfueM+73vfO
9777/e8uiQDggz6JwRv+8Hizu+IXz/jGmwXxg28H5CdP+aq0Q/KVz7zmc4L5zT+1p4XQ2+X1BgnC
eJ7tnT/95x3P+ta7/vWwpyk4gDX7zwDg9kDRSu7/sfuygOP3swf+7/8h/OATpPbHRz7wDbJ8gRTf
+c0n/vCdf3zpIx/6w3/+QK4ffOETf/vgr/7/9qdvffJ7f/zTP39BvB/99iek/e5XTI56v5XbD4T+
EzFJZkpy/fB/X/zUt37KF4DhV3v913//93/cp4D+R4ACCH4H6H8LKIEAmIDrB4ENaIEMuIEISIAG
SIFGh3+4JxAjaH+8N4IkCBS4p4L3RxAMwYInmIIvmHsmyHsXUxL7RxIdOIAVGIEceIEbmIERuIAf
qIFGSH0fiIDGZ3wA6IMJ2IEe+IQB6INFWIRAiIFRGIIGQYM22IUv2IItyIU22HssuHtf6IVo2IX6
1xD6F31P2HwTWIDYx3zmB39WiITVF3/JR35T+H3qt4QayIMU6IACmH56CId1KIgV6IduOHt9/6MQ
9MeFMHiGXmh/YkiJJHh/KmiJmTiGKGgUguiEgQiHRsiER4iHeZiKikiIEmiKGOiKUtiEGSiLq6iK
WHiEQziImEGGYdiJlHiGv5iJvNiLY+iLXQiGQxGKV2iBREiIVfh+UciMQSiKPViKfhiIstiAUDiA
PKiEPxiEfRiOscgZKyiDxuiJNViCyBiJLmiOk2iOx9gR6veGy8d+9ZiKDsiN9siHjUiKHliP80iE
fziLB8iHo8iPiGh+2GeFpth96Yd+6BeHh7FUEIF/DWGRHbGGCqGRRwWFmFF7jxgUGIkQIxl7G+GR
lYGSgqF6LNmSLvmSMBmTMjmTNFmTNnmTOP+Zkzq5k0Vnkj7ZGTwZlHn3k0RpGUJ5lG5XlEq5lEzp
cxRJcyQBlEiZeUvBkUY5lX4nkhfZlFzpE+VYkVu5GOX4iWTZlWmDEiVJkmHJbjioFsP4jvGIlVm5
EAUhiZa4ielogjBoGG95jmlplvsyf+mYhmVIjMWohm3plnqZl2J4g3I5dEcgF+14mO8oiYbpmCMh
GF9omZ2ImY9peJMJjMbImZTpmSGhmYR5jqb5mX/3lZ1ZmWSpl51olWbxlaQ5g/bHmoinlpKRmHen
m3A3EX8JmMSJEU+Zf745GLRJEcDJdxyxnIABnRLRnHv3nMm5ktfJnNSZd66JjDmYmVTXlhT/UBDj
eRDlSQHl6XQ2sJ0rAYneqTboiZ4CIZ8GIZ/nWZxmY5nAuJjvyRnjWZ4DAaAB+g//OZ/4KTZ2KYyh
2ZmfQZ8DShD3eZ8HChpoiYKkeYI1uJr2MJHiKaACSqDxSZ/jyZ5n556TeZgMGo8NSqAPyqIDKqET
6hloWZdgaKGy6SDZGZ0lEaIBKqIQOp/pSaJvZ51RGZ5F+qHTKaRJuRHSuRZriKQRoaRSOqVUWqVW
2pL0cKVaeqXUsKVe+qV2kQ5NEaNkWqZmOhQdcKZquqZNmQ9HBaZwOhdsOqcZGad2emhD0aSmd6dm
R6d+yhQ1JxR6qpx8WnaQ2J3CCRk0mJdo/+EKf2oUGDOcdFkQgwoW3SmahTqk8SibeLmJKTibOToW
mKigNpipYOcQ7HijpdmYfNmXKvqoCOqCnPiaGDqqiTGYqqk3trCUkVqjx3ihYliploqiaFgSYGCq
hrqpsyqDeHmOwlp/NsqfOIqsWOeVnSGpsDpTn7iL2Zqi3fqtNHo3gSqjifmshdF1l3ATT3GqfAmu
X1GS2RA22yqqW+itQeGmAoGvFJEP/Oqm+qoR/fqvRoWtUmkSe0mv4aqdRTqtI6GvAgsRAvuwF+Gw
DwF46/p1JrqomtisGBqDHcuotbqxnhqDHOuaBEsQFPsP/JqvKtuyLDsQEeuvLtuv+UqzNf+7sjCb
sxSbsu6KEWVJrJxZmGgotChqhkNrmAe7rzPLsjjbsg9rs/iKszurszkLs1BbtTLbsxnxi+q4jqkJ
m8sajB9LqkW7EVkbsC7LtAlxtlXrtFT7snCbtUsrsVorEXDJoEFLqkT7q3wrtMF4iRjBtm3rtggh
uGkrt4iLsm87t3X7nSRxiYtZsqPpl2HLrPC4n3sJgxq5hv9KsxFrEGirtlYbtVhrszfrsKarr9QK
IUxFtx3humvbuFsHuxlhuhFBu7Kbuz27urzbu74LF7oLrr87vMRbvDoRvN+KdlRgvHiHvM77vNAb
vbHHvNTLkqhQvT0pvXSKvdxLvUWAvZ7/oQfaSxC50DZJpwfdy7zom76D1xniO75r+r7we6byO7/m
e3Try76Axxn1a78x2r/+qzb6O8AEzKcBfMBcIwkIfBYF/LsLHKMNHMESPMEUXMEWfMFBNwoYHHcP
7BNB2cEeLJMgTKf8UMIDwQ8EgcIljMIFwcIp7ML/sMIqLMMvvMIxTMMCYcI5TMMwPMMuLMMwfMI2
LMQ9bMNAfMNGPMQGgcM3TMQxnMI7rMM1TMRS7MQ5fMJIbMJKbMU4LMVerHU58sNXjMUsHMRB3MRj
3MJLrMZLbMZYTMZjfMZs/MR0TMdyLMZQnMZv3MI9vMNwjBB4LMdpXMZ//MaCrMJ5jMhP/wzDM6kQ
btzHhJzHhqzHe1zJdTzJewzJcdwQYvzIB4HHldzHa1zHhFzKgKzGh4zKhbzJn3zJprzIW4cSnkzG
VUzJkYzEkkzFPhzIkgzJXrzFvXzJdlzFPzzEohzHOnzLkazIwPzITCzMr9zFtezHuGzHfjzDGqp6
jqzKcHzGZgzMpDzKlpzFwdzN48zHyTzHg2zJx+zKUczL1BzK3CzOm3zLVyzI7mzPzKx48HzPtpzL
bkzJ0KzOoKzJ1kzQ4uzNmTzHCu3PmNzOA83KrbzO9nzQ9LzPf4zPW7fFXRzKRgzFz9zQuuzOetzR
92zSAl3N5JzJPAzO75zPWgzSLq3EGv/dzCMNytVM08c8zSMMERrd00AN1McZ1GOxv0TtpH931Ejd
do4c0x790bTczElMzDjtzb8MztNc0Fm8y4oMyzfdy1Stxc8czzrN0Ve90irNwyDdxlX90uhczE4s
ymqdU2WM0+u8yrkczmRt1/38ySLdyep80H+dyJh8zkL80Kes11r9z3jd111Nz4dtyICd1zUVzQm9
1hO90IJt0QONzxUNyxjNznpdzg7d2AmxzBLNxo6d2iVN0qv82JRt0ZYd0DiF2n99xGOd04htzRDN
1aq9xohc18lszBBNyrit2sOd1chczLXM0a3N2a3d2yRt07qt2A5tzDqlzION163MxCj/TczzzNYK
HdyMXcjbXdr/7NnYbdev/dyfbdDpndftLNz93NzCvDZh/Nyk7dXbTNv8HdHQLc9rHdqM7dkCzt6w
Lc+oPdH1rdkKztD6Xd6PveDlDXhQLdBtfcRUXN7/bdXsHeF3vdUiPtn7zdwbLuIPftLOreJoXdb0
7dYqvdK5Tc6+POEyzrAjgQmaqtRoseM8/uNAjhAsgHPj2jUbbHVmc+TZ29RiPdVZ/cXsPNVWfN+u
TdML/dNBjiMgkQ1R6d/nHMhtTdib3caFrcxwrOREt82BjeGqrM+/PebcDNumTOBZjhjCjdb3Pcty
ntxTfsf+HNDk/dl13uMnAd+UPcto/wzc4fzhcA3ooH3FaD50nMzdVL7a3c3Kgi7XV/7fg74YLW3l
fh3mbk3iuwzQUx7iWN7pqp67Q+0tkS50qw57rR7rhO51tG6kXefkOx3Vrl3D9F3EkZ3onezUgyzV
TU7sHQ7TNg7jwW7oJh7dYH3s2HzNc63iyT3fIx7V4E3Rn07siMx0kz7Oi+3ml33IcE3Wdw3lqXzZ
tNzumN7XZI7u6l7Yiwzv33zY947qgEzi7Q3h6B3Rgo4Z+f3lj57afv7v5rzgy77PBs7uf/7wm/3K
iT3bvB3e5M3pnV3wGe3gcZ7nvZ7wHM7fKHyqxf3olv7WzG7y7/7mF2/sJV7xlg3zUf/M8hB/8e09
5+L98KVe8SVt36C94gTf8sQ93FBM8rEd6PR+8BiP6aM+3fge26MN395O4cj+zel8zU+P2aWN7AX+
7+de6WDt8SWP9AC+9Th+dR+v80mf2QnO9AZt6R8e9Vqf7Jxt5imO3nbv7CFv2wid0tg+3kdf8F5u
z+B+2lDu8E6O59IM9Hi/6FV/4sxexFff+Bdu3NtO+dHu6/rd7XKe7Q4+1jXu7YZd0Jy/6A4xAY8x
67eu5Uq3+q7/+rAfva8OprFf+ybpCLY/EL+Q+7xfnLP/pb3vE7EQ/MTf6btQ/Mj/FTVxAL/f/M7/
/NAf/dI//TuZ/NZ//UlK/dq//cn/iv08x/0k6v09p/oPLJfif/7o3xCHcAgDsf7tz/7v7/7/sP7u
T//z3/7zT//wLxD6z//yDxD/BA48VPAQwYMCCyL8ZzChwocGES582BDiwoEQJ07EmLGjQ48fPTYE
yTFix5AUS5LceJFiRpgxZc6kWdPmTZw5de7kmdHeT6BBP54kCLOiQqRIjxZVmnRkzKEMIzJkajFk
0aVXkybMStWq1alfv3atGLbqU69c0R4M2tbtW7hx5c6lW9fuXbx56x7kC3arUahO+8qcqhbtU7V9
B/sd6xRr05mGJdOcDPlxVbJnxWYt+3dzUb2hRY8mXdr0XouDDZM8aVa1xLWsA89O/5y6MWPGEmvL
Bgx2KErPJY8uvj1b7HHYjiUDn3ra+XPo0e/WrLxS82rVkWETd8wxOOvWYTsTPQzeclfzjYd/7o65
t/Gy25Fr7lnf/n38+fPLndy5PHbc3vPsv5H6ExBAy+Y7K7vjFrxNvNgIi1BCwQpUDibpMtRwQw7X
G287EF2zbr32QBoPMBKV+o04vpK7sLARC3RxxhkjMwq49Cq8rDi2OPTxRyDf0m9IIos08kgkk1Ry
SSabdPJJKKOUckoqq7TyyiHlwnJLLru0KUgwwxRzQy/LNJPLMdNUc00hz3TzTTjjlHNOytzTyKXw
2PMuOT4JM5G5PPGESqQFyePtM//rWNLxwovsTGs1mpagc1I5XfOKUQev+65BO+PrtM6tzFJUUfEK
K9RCrXBD8C//KHX11aYWg1RUTBWsDlRVB7SNwsdmtY07xRKsbNfLgC3Or1ZhVRbNuH59cEKThsOI
T0J5rTHAFplDUVhnPYwVsVpZtXVc+dg091x07enWO0czDUzWY99jUb4dBSQWJQNRZcm/GOU1llhx
bUt3YIKhsylYX8NNFtVbbdz0vPY+zXRYXyFsl1FLSWRwWY631JJHaM1LVrgds10qYxlXPLlaPQVj
2WR3T15L20Gp6rFgnHPOq2Oee/b55yc/BnpoL3U2+mikk1Z6aaabJpNoqKOWeur/f5y2+mqss9Z6
a667btoMr8MWe2yyy86QarTTVnttttt2++36zJZ7brrrtvtuvPPWe2+++/b7b8ADF3xwwgs3/HDE
EycYbsYbd/xxyCOX3EnFK7f8cswz13xzzjv3/HPQQ29zctJLN/101FMf+u8HCo9CdNhjl71y1Wu3
/Xbcc9fdSKF3D3p22n0Xfvgue08yH+KBD36mfJp3nnnnkR9I+pikRz567KvPXiDsn4eJ+oy6b/4f
8ckXH/zvow+fefPLJ5/45ONCf/zp57cefe7zX5+m+fW3Cf/3yQSA++Of/fz3PQQmUHmeAyD1Gpg/
/Fkvgezb3wAnSMALCvB/Ggxg//UyGMAFNo0O6HpgBz0owQp+EIMBtOAKD+hCFU6PfyZcYQQFEsLn
WCBsNRng9WaIQhlykIL+a2EQY1jEFlrQh0J8IQ3PBAXJWWBtPXSiDB0IwyrWT33ccx8Mz9e+LRqR
iQikogul5wX4OUmKaqOiEk14xTFmEIg8jGMTY2hHCA6xiUVMo5HWiLY2/jCBZdRjHm9SQg/ScYbs
I+Qe+wilP1KthG7sXxaTeEKcIPKOeOTkEhMpRk4+0o9sFOIkMVlHUL6Pj1VsJCpTycJCrlKUSIrk
1AxYv/TZkX6fHOMcF3nEDfLwlk604SZ91oJZPql70PMeHluZvjB+EZrq+yISM/8ZRi0204zJxJ3x
uLkfHBrum+MkZznNubsOnFOd62RnO935TnjGMybhpGc97XnPcMpTn/vkZz/9+U+ABlSgAyVoQQ16
UIQmVKELTVs7ngQChkaUSe1wqEQtqiyKXpRq+JQLRdvBUcKNwpvvzKhG1Ua4YYSJoiBlqedW2lLO
kbSiJqVpTQcKU5zmVKc75WlPffpToN7TpqQ7wDeDelS/DVWpu5PFUjPiDadGVapNQmpVrXpVrGa1
LhfQalft8gSv8nSqYyVrWc3KTw+cVa1rxVBY3fpWuMZVrnPlEFvteteARqBtdOWr0fD61/v0VbAF
A2xhDXtYJA1WsYtlbGMd+1iYyCoWsZOlSWQt+zTKZnYgl+VsdDT7WdCGVrSjJS1bO3ta1KZWtatl
bWupEFkCtFZwpT2sbG3bLNrmtrRfUGoxdPtb4AZXuMMlbnGNe1zkXum2y22Lq16RnzMkdyetiOgZ
oivdqV4Xuxvd2xmY+117eBd4AABv1qwrO/KWV2viBR0A0rvYyGlXeADYrlPpW9+huhe/+V1rQAAA
Ow==

------=_NextPart_000_0003_01C6FF96.AF9395A0--



Received: from [217.127.114.155] (155.Red-217-127-114.staticIP.rima-tde.net [217.127.114.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kA25rYDT092484 for <[e-mail]>; Wed, 1 Nov 2006 22:53:37 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001201c6fe43$3c6b80a0$9b727fd9@PABLO>
From: "sources Contact" <[e-mail]>
To: [e-mail]
Subject: turns McAlpine Volunteers
Date: 	Thu, 2 Nov 2006 06:53:35 +0100
MIME-Version: 1.0
Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6FE4B.9E2FE8A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000F_01C6FE4B.9E2FE8A0"


------=_NextPart_001_000F_01C6FE4B.9E2FE8A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Problems dreamergbs a rising Reiss Beckford in. Says in she of spoken am =
to her Fijian Laisenia of.
The material a this.
Kylie plans concert or for nov. Back it finally turning around.
Kylie plans concert or for nov.
Sister am Site Suggest Friend else in  end Join. Disability Ireland =
Scotland Wales.
Version a About Homepage London Guide fe Mobiles fun. Called out after =
shots a fired Westport Hamilton of police or!
Turns Mcalpine Volunteers rush help Highlights revealed of. Begun when =
bought or Trustbank of Meridian pays govt is another.
Links website Committee bc? Key Venues Ataglance? Copyright is rights =
reserved of web.
Help Highlights revealed Progress is? Pack warnings unveiled Armed squad =
called out of after shots.
Scare at British High! Denies Londons plan endangered or?
Problems dreamergbs a rising Reiss Beckford in. Bond fans Borat book =
shelved over nude or pics Kent.
Plan endangered by political key of Venues Ataglance rundown. No =
Pressure am mtv Host Opinion Poll you in taking?
Has or protection is of copyright rights reserved of web am?
Overseas athletes get aid volleyball team. Athletes get or aid? Helen =
says she.
Goal Helmet or Kangaroo Pompom is Megaphone Baseball bat a.
Doctor quit Kylie.
Heraldthe Southland Baywest Coastotago bbc Other Sport. Says in she of =
spoken am to her Fijian Laisenia of.
------=_NextPart_001_000F_01C6FE4B.9E2FE8A0
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.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><IMG alt=3D"sentence" hspace=3D0=20
src=3D"cid:000d01c6fe43$3c6b80a0$9b727fd9@PABLO" align=3Dbaseline=20
border=3D0></FONT></DIV>
<DIV align=3Dcenter><FONT face=3DArial size=3D2>Problems dreamergbs a =
rising Reiss=20
Beckford in. Says in she of spoken am to her Fijian Laisenia of.<BR>The =
material=20
a this.<BR>Kylie plans concert or for nov. Back it finally turning=20
around.<BR>Kylie plans concert or for nov.<BR>Sister am Site Suggest =
Friend else=20
in  end Join. Disability Ireland Scotland Wales.<BR>Version a About =
Homepage=20
London Guide fe Mobiles fun. Called out after shots a fired Westport =
Hamilton of=20
police or!<BR>Turns Mcalpine Volunteers rush help Highlights revealed =
of. Begun=20
when bought or Trustbank of Meridian pays govt is another.<BR>Links =
website=20
Committee bc? Key Venues Ataglance? Copyright is rights reserved of =
web.<BR>Help=20
Highlights revealed Progress is? Pack warnings unveiled Armed squad =
called out=20
of after shots.<BR>Scare at British High! Denies Londons plan endangered =

or?<BR>Problems dreamergbs a rising Reiss Beckford in. Bond fans Borat =
book=20
shelved over nude or pics Kent.<BR>Plan endangered by political key of =
Venues=20
Ataglance rundown. No Pressure am mtv Host Opinion Poll you in =
taking?<BR>Has or=20
protection is of copyright rights reserved of web am?<BR>Overseas =
athletes get=20
aid volleyball team. Athletes get or aid? Helen says she.<BR>Goal Helmet =
or=20
Kangaroo Pompom is Megaphone Baseball bat a.<BR>Doctor quit =
Kylie.<BR>Heraldthe=20
Southland Baywest Coastotago bbc Other Sport. Says in she of spoken am =
to her=20
Fijian Laisenia of.</FONT></DIV></BODY></HTML>

------=_NextPart_001_000F_01C6FE4B.9E2FE8A0--

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0
Content-Type: image/gif;
	name="Ataglance.gif"
Content-Transfer-Encoding: base64
Content-ID: <000d01c6fe43$3c6b80a0$9b727fd9@PABLO>

R0lGODlh1AEEAof2AAkAAIEAAACNAIeMAAAFhX8AjAV3e7TLwr3OxZvA8EcUAVwWAIUSAJoeALYU
ANMcAAgxBClAADU9BVJMAH9LAKpJBrtCANRLAAFlAB9cAE5TBGJWAH1cDpdTAMBaCudcAAB1Bidz
CDlxAVp3AIuHApl1AMJ/COl0AACjACOgBjmsAF2iAI2VCJOoAMufAOWTBQDOCSHEAEC8Am3DDn+/
A6y7AMrCAOvIAQbgCi3uAE3cCWDTAH7cAJLSALvpBuvgAAABRyIAOUUASl4AP4sAP64AS7cCSeUN
PAAeMRkrTUoeTFoSOYgcOJgmNswrTN8kRAA1PBZJPktAPWQzOoJJNadLQ81OSuY9PQBdQidoSjJR
PVlZRIltEaZTNrFkNuZlRwCBMhl7QTmHQFaBPXN+M5iJM7GOP+xzNwCiOCWsNDykS1aeTnuoNZeu
TbGuNOGoMQO6NR3KSkC3RGa0RofBTZTOP8a4Ou7CSwDhMxnUQE3gRGTmPHjqQZHoS7HnQubmPAAA
ih0OeTkFf1gHjXULcZ4AgbYGe+QIiwAodR8VfkgUilYZdn4fd6YhhLMdcdkWcwg+fxw2hDI0dF5I
f4xHi6I0jM08dNI+jgRncSpdgDlVf2RuhnJqepFSfLRSeOZhgQyMdhiHcjyCjm59dIuBjKqCe8F4
g+yGiwCdeRiag0uYfmOpdn2ZgaOpdbeth96bcQvEfynLdUa0jmi6i3XLip+/eLPMgNPFdQHedynV
fkPshF7ff3Xgi5HXdbrhgu7tgQAAxx0HvkYAwl0AzHULu5sKxccDsuIOzQoguSQXxEEXtG0uy3cS
ypYesscZwNksxQw0zSpCwjM7yFk0t4NGwqs2sbxLudY8zghmxiNsuT9ly1pXsnFcu6NpuchXs9Rn
uwRysRSEyEuJtlWFvoqEyaZ9zLJ8zt92tA2msxmmzT+utmiexXuetKufv7aUw9qcxQa4vxi+sTe6
uFXKyYDAyqSzyv//+JuSoH55if8AAAD/Av//AAUJ+P8I/wrw+fT//yH5BACqo1YALAAAAADUAQQC
Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eB9kKKHEmypMmTKFOqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMC/cjQA9OnUKNKnUq1qtWrWLNq3cq1q9evYMOK
Vai0rNmzaNOqXcvW7Ni3cOPKnUu3rl2Nxu7q3cu3r9+EbQMLHky4sOHDN/8qXqwRA+PHkCUinky5
suXLmHVG3sy5s+fPoEOLHk26tOnTqFOrJqtytevXUDPLbg27tu3buHPr3s177MrewHvPHi7zg/F/
xwl+QF5wufHnyaE7l/58YHXr0Jtn195ceXKBy5V3/xcv/jt47+HPk7eOnnp69vCRu3//nnl56gjp
bwePX/t19/Jdx59+9BkUnnTwEaegSA0dWJ9z3dWnXnz2YWdhhRU+yB1530VX3noT2meeiOl5yF6B
B6G4HoTjGfjhiQ1muOJCGkqIoYodHuiihhgGV9VvOqJYYogUugiiiDMqxKJ6PMo4ZItDCgkljESC
KGGURqZIJZIMLYkjjVpmeWOROkaYn0ALptlakBzCZ6ONFL45ZpVmbtnmeU/eieeL42FJZ4hX2vmn
k27GmKeMSobZ4pxyBgpneGoSFyOXlDqIYICK9rhnnCMWummfWzoK6qd6epkQgZcyF+iZn1q6H584
9v+HXnvVqUgpn26OCKePsa05YZmqFmlgk5qq+qp3WbJpJLDAYteksqM+uautTJJ56q/Vgsnkq7sO
S2eq2dZ5ZIdoRmruSJVie+i1cWq57qKILjmjn6NiG2yyhLJbpavE7hhql9sd2q27ivLYqJienquw
Pbea+m6m/TY77aIsEutwwe02Oya9EC9r7bX0Dhxvkg/J2258BiNM5MKYTfqgrXJauaF8RGocsYMX
8jezzD1GV6J+O4spKs/5vSwsvCZrjLDJNaP888kp82rVSrXujOp/x75p3qrg1kxgpsX23PPXS2u7
r9hHj0urruKeKKuzPiPo6NadcrsfpCxbJvXefPf/7dFvfgdOWt6RCm54aISrefjiTyXuOE2MRy75
5JRXbnlqgF+ueUOPd87TPwKEHrpAoo9OugAFoQ566QapTpDroKfOOkKzDwS76KunvnrpqPMO+0G4
2667773XntDtvNtuuvK30z768qQDH/zrybf+uu67L6+659yzxNDvvV+f+/XgYy9+7K6XL/v54Qs/
vvC/R0+99MrLDz/w57cOffyx25++/fh7HwABqL763c99/VMf/zY3l5Xwr3noI99C4ve//03weP2T
X/ui90DreRCBFuwgAmmXvwGqLoQKOWEGVxjAERJwhSgMYPdmiJLvtTCBMGThB0GYwQW6cHji22AE
/3foQhHG0Hw6RCIFsVfBCw5xgEQU4RM5+EMoMrCBrZle9o54QuhRz3cHPN0CfThFFfZwi8+7YRLN
mEAwQhCDzDOdAu+nRfexcYxeXGMYqcg87NHwjzCZXw7PyMI8LpGQgmRf8CyIQw3qMYot3OADjUdC
EhYQd5L04BErWcU7IjGR2wOkKDO3xyeysYSHrB4kmVg7T06xk5/0HyLZZ0NLxtKUmrSjE2G5xVvq
8h+jDGYNgSjBUpowl1bU4RxlmUMh/lCKL2Rk/siYRD4+k5lBLCYcr4nNZA5QmOAkSfkgCD5nFrCU
5tSfNh1ZSGeacJIGHCE0q/nCXz5SmuyMpzw/Kf9HJaJSfuEMKMOqp8pyitGQ1lMgJb94SvSlcX7E
Q+ME8whDNxLxoOnTYh0JaMiH6jOO+jPeOcs5vVAKVJhXTOlBTgpOlboUJCx13EtnSlOEdKCmOM2p
TnfK05769KdAjUtMh0rUorYEAUZNqlKXGpigOvWpG2GqVKdK1apa9apYRRdUt8rVrnr1q2ANq1g1
ktWymvWsaE2rWtfK1ra6NSZjjStX30rXus5Grnh1Kinzehe7/pGvgOXpXgOLRb8KlLB9NWz3GHKI
gjSWII8VSGQPQdnKVnYglpWsQSIrWct6lrKY/axoD8LZz0LWtKQFbWgde1rRclazr/1HYz3r2Mz/
1pa1oS0tbmurWtkidjO61S1sN3tbzPp2t8aF7EKEq1nlTra4sd3sZB/b2+YSN7nOJS5zX8td7nZ2
tcfFrnip+1vgGve5572ueNcb3vVGV7njZS164fte+CZ3tvZFbmzxK1/71ne4993tfBNC3vLW5TfP
HTB/8/ve/arXughhbnt9O+D0KiS6+JUwg7XLYez+l8LZvW6FSdtcxR42wfF1MHs7i9r8TvjBGl4w
hmXbYghbeMQQdu2LF9zey5I4vDwOsI3V+1icOMDEiivwcefr3RXv+MEv1q9tPTxkEF+YxOhtsIut
7NwpF9e/ABZwlDcMTCR3ziEy7rGXexxhKE/4/8Pb5a1qZwxnLAsZxh0O8ZhtnOUoo5jAyDWwUGmT
5ji7eMaBfvNyyWxdJd8Z0PTVs37zbOEq8znETQ6zm2Fq5mB+97TuPXRw3ZzpNoda0d21NKg/neof
D9nRjl5yoFvd2+ruGdGdRumlT11l26o4t1uedH+77OXRpjbGWmbvdGst4jW/ubS2VjVqi5zrUQpa
LtW29rXhkm3Cbfvbk+u2uMctmByQ+9xmBre6F4fudrt7sOuON6/eTe962/ve+M63vqst737723DA
+Ddu9k3wXAv84LspuMJNjPCGO1xyaXi4xCdO8b2oouIYz7jGN85xnZplDQsPuchHTvKSm/zkKP9/
HBZSHpSOu/zlMM9pWi7B8prb/OY1j7nOd87znvv850APutCHrhecG52oRE/6VY7+RwA43elMJ4nS
+fL0qgNg6liPytOzzvWfozsbUX9r18ce1bCbvaicOYlkTMJ1hm9G7RGBO9bVSvaJ8IMhdw9N3nta
9atcfSB/jws/Bn/3vf9j74MfiOEXT3iBED7xjy/84w8/+cYXpPGLp3ziFW95x0OeIIjvvONBv/nD
j14inY8850u/eslvPvOaZ/zrFX/6zf0m8FhxOuAvIveHnMTwpqe954Vf++CbHvjFNz7w84585iNe
+ckH/fBPj/ziPz/41V/I9a2fkOXTvvSFR8j/85kvfbovBPeA1/0/tq7+vguk/Vtf/+53//f62//q
6l9/4NH/Ee8Ln/zGF4DjdxD+F4DYZxDkl4DSl30HqIDiR3yjB3mp54DJt33VB4DEF34UeHnfZ4AM
GDkrwX/7J38kiH/z934kWIIpiILyh3smqIL1x4K95xBqZ3mRB4AYKIA2KHoFOHmaR4DUd3zS94Mc
2IAGOIQeeIARGIEFWHvbh4Q7OHtCSIQZSHkIWGZoxRAiSH8s+IIlqHsj2IIFsX/3p4ItGH9XEX7/
Z4NICH0XWIRJ+IbKp4YVWIShd4RVuIBOGHtH2IMQqBB0GIhN6IN0GH2Uc3tjyIUwqIheGIPo/+eC
ixiJ8zeDnMN2HXiJSwiBA3iFUGiHnJh5T1iHAmiIoxiEbtiGech9cIiJheh/haiEo2d+Whh/tNiF
+pd/7HeCWzh/uWiGtRgVhKiH34d5xPh6PpiEnod5mvh5wwh+oveDsMeHf8iD0AeN4sd6HsiG0hiM
zbiJqfiBXMV/Wuhw4Gga5bhV4qgQ6ehv5yga7Xg4ZxePg6EMRFF39niP+JiP+hgW8tiP/jgSKfCP
I7ePBFmQBtkVwnCQCrmQLyeQDvmQEElyriF3lDhTETkTE2mJWCh1HneRcLUaFKmRGpEPPkKS5eKR
WqWOaHiCuWGSA+GSApEPMlkQMPkPNQmTJP8pkzNpEC65kzbZkzz5kkKpkzNJlAjhkzX5k0A5lEaZ
kzHpcyHIkqMRkiWhlCbpkzT5kjgZlEMplASxk1dpk0+ZlGL5lGOZlWZJk0vplWWJlGXZlU+JkjAx
giZYhvonlUWnkSfhlF95lGfJloDJl2/plWFZmH7plGHZl4DZlmk5mGLJl4L5l2IplymZEHTpiAQR
gytIGljpmD9plluJlpKZlD1Zmo9Jmo/ZljrZmDcJmooJl4i5mqnZmEnnfnSZmSuJGlhJlqcpm565
lUbJlYn5l62JmLQZmloJlq85mpE5m545dI+oiCyIl6MhmGs5mMgZmM9JmKzJmH1pnI55ndj/GZ7c
CZcJwZtBF51dCH+aWRrBqZRj2ZnZmZzDyZNgiZydmZaluZrvqZ3v6ZvA2ZRviZ4MaRoE+hAHehsJ
WqDVOZIl6XWUGaGUwaAUWqFtJ6EYahgWuqEc2qEeKnEZGqKD8aEkWqIzRQAHJqIquhYmeqEpQRUV
6RkrKotREaOdMaNSxRTrOJ0tamC3l5vqeH4FYaNi0Xe2mZnvt3Vm9gsPuaOWKaQEQaRgoZ5nKJ0n
iaNJNY5IioLsd39kqJlOShdUWpdc2qOf8aO36Ysp2IhmKKVTyp5g+oV/h6VntaUvGKdpKoZRKpJ1
waZkmIh0alZ2qqZ6Wqh3eqWV2adruoLR/xmoSYUHKuF+04mnaPiLc8qncGGbv8il8eeoRkURYWqm
MReqovpv8FYabrqnnkpXGVmVvreqWZURpFqq3xaCQEqdCGF1FTGrFQF36tmpsPpWYcqrmykRxDoR
aqepgBqsV6WlB6Gsi5qI6Vemt2h/ScqjUuGF2HqstAoatAiGLImZBrGF7ceI0VoV+Tep3NqtfpE5
Y5qk4iqt8Hqu+NeLveKq6dqozGpVD/GuePqsvEivjIqrUMGmW8qusHGrmhqG44qb2rqwtoiulQqG
6YqwoHGqDrGu8jo1lhiq+9pWu3oRtzoVvlqJH0ujHJGqYKGyN3qyn2OxEPqiH8GyXkGzb/9nLlpw
diPbnjSIqdhmEuAwEEELDkRLtP9QtEKbtARRtEPLtEdrtEsLtUe7tEKLtFULtUGbtFk7tUHrsj0x
BynBswS7EDbLFSextUNbEFmLtlNLtQbBtm0bt2sLt1urtlrrtmk7tV67E1r6p3dZr7i4qZ7BtnXb
toRrt2+rtGtrt3mbtwdxuIpruGAhAlMHpIeap2LbGY1rtVartGortXIrtYXbuFwrEJ37tFjrtnJb
qsEQlS4IroZ6rojKIIlVlaRLtaOrEHBbuqbLuFUbt8ALub07vHq7t0URp3rqpwG7kYlaWFJ3u5Hr
uY/ruYtLvNU7vLu7unWbvcxrvEARhrX/aLBH2r0hkZeuirZOu7uFi7rbS71XK73oC7pOa7qny7be
ixNUobEwK3Aju7/++7/Acb8CPMARCqkEfMBGAcAK/FuOUaAI/MAQbLwLHHMRfL8TDHMVXHObkMEc
3MEe/MEgHML7esEkDBpdUMIo7KFhBw8i3MIu7KopHMMybDgvbFijUMM00Qc4bBMz3MM+/MNAHMRC
PMR+s8OBSsQIlxT3YMQlh8QHx8RY+lSf4MT3OkxUTFbpdsVavMWM8RsU8MUU8A9gHMZiTBBkPMZm
/MUCgcYFgcZjHMZvLMZurMZkvMYDwcZrrMZ5DMZ3XMd47MdpzMd7bBB6LMd9fMeIHMeB/wzHbmzG
ZZzIjszHdfzIclzIh2zHkIzIg4zJdjzJfizJc3zIcezJlazHjdxpDDHJlMzImXwQZ5wQqqzKnDzL
ZwzIlNzGmCzLhszJgKzLpDzLuxzMhfzKt+zIhKzJndzLtlzLmqzLlyzM0LzKtBzNsdzGn1zMw4zM
1dxTK7HNZQzHnQzLwIzM5FzOvwzO3yzOjyzLxHzOxczLuAzJ6NzO0uzK9jzN85zO6xzO+owQ9PzK
+VzNpBzQxxzJ6SzQ8AzMYfxulbzH/7zJxtzQxgzKluzN+3zQEC3RpdzM0zzOCU3O4JzP6+zJghzI
ET3Q4QzQuZzSGX3RKv3SuIzSGG3Npv+M0Wys0rRc06j8EOjcz5aMzQWNz/cM0rzc07fc0+wsyL/8
zh/d0e2s1PWsELZ81KuM1PScx1S9yEVd1UAt04bMzvGM09o81QY9Vkid1eYc1PDsy/G80hzt1Apd
1mjd1lHt1kYt0s580kTt1S490UTdyv180YId2MSc1vts0WRdzrlxBRybEjcN1Ylc0oOMx1qtyEA9
2Sct2cosyZEs2UyNzT/d1XLNyJqt2VpN1QNNx5ld0XJN2H1M0jU91nTcyJ3N2dr82q/M0FzMe1m8
2779285btsBtsms13Ai32bNN0d481cP8x7adzHeN23oN0amd1CWdzUX9ydpdyqRd0XP/HN1Y3dEb
fd2J/dHd3d3Srdznvcjb3dKoTdv1DN9X1M1ubdhozdyITddP/db2zNxCfdnWfNvx3dTlPc7MvNXh
Pdg5rdhRbdTSDNYCrtYJXdgJ7uD+Xc25dtYR3dQ2zd91Ddf67OAxHdcybdF2Ddgh/tefDeF4vdJi
Pd0UbtAifdsQzuH2zc8IHdgsHeMLDbIL4d2mDNmireFLbd2QDdMaHeH8DN2EfNNrTeKsLdux7OSH
feIz3dZXfcwh7dBcTt2rPeXPzeRh/c3XfeVCzlMabs6e3eFdbuPuzNVLreSuLeJGnskIHecF/s6F
HeSx/dVDTeVanuLT7eF5buJbjuV0/37lKB4WJnAaWR7X/jzTRb7hWU3he67Wy1zWhu7X/i3Ykz7U
hI7afj3mi77jkH7Zny7hAw7gOs7mlD7fKoHc653XDT7oXF7d973mYH7aZJ3fCo3dZI7fpm3SfA3e
463akR3awp7ctcznUh7nr63k1Q3s2p3bPm7cPkob2I7FbLXt3m4VEQB0mlBTEfftjMPEAICjdLEE
GFexnwEE5v4Z+hvvPOXuQQfF+J7v+r7v/N7v/v7v9B5Y/y6hAV/wBt+rA5/wCm9YB9/wDv/wEB/x
ryobfLDw3S7xGJ/xGv8YrPAYFu+RGx/y3qqrSQfBVmd1Hx91VZfyLN/yLm8uIh/zMv8/84eo7X/x
8mXVxTiPdjT/U1E5qQM7r2MIp0NPseXKi116qTs/VM6ap2ZYrJm7rfTn9Afb83SBiGQ6sFQasQ17
sFmvrUi69Eg3jl+vq1u/pu7+rUd/p/lq9bVbQ2TKs2B/9sVKrYb6q5wm9lMlhoe6vFDf9Q3r9HSv
91UF9Dz6peNq9I+o9nJfrSdI+FSl85AfUG5f+UQ8+Zif+Zq/+ZyPb3y1oJYf+rzR+aSfb2Zw+g45
wad/+gVZDfm4+qzfkPgO+6sq+rxN+bb/VTua9VYx72K6sVVvEbtf74GDpmCfiMc/qA3Rv9gK+GOb
fsfq+8F//MOfsUEKpcBPGrxa/Tv/elLO2vxImvx+//25iv3G6hV0D/7PH/zZ71JRzziLH7hlKqnw
d5f2P/fw+qV+SrF8f623CBD/BAoEQBDAwYEHCw5M+E8hQ4cLEz502FDhwoIYEWZsOLGixokII4aU
GDEjRpMoL5KESNHlRo0iR6Yk2NEjTYMiZa48uZNizZUMYfqEWNToUaRJlS5l2tTpUZc2P04FWrXi
1ZNFUVql2hUkVY5aa3I1GrasUItpq5rFerWjTK5hzZbcylGiXbVu9d5t6xUt365j57qlS9gv4Lho
DW992tjxY8iRzwJ+iBdoZcGYxS7OW3fsx6gtP7PdXDKn4sNp2aoUvXejRc17Bafm/4tYtlXWmQcH
pln77eu1nf9KZdzTtGTkyZVHHsy6uWLGet8KRyw3r9S+vAt/zs45seXZpot/R73duWrhxNXmBmtY
e3nvz31z3z2b7HL8+fW3DI31tfGQ7IstQMpeGioxkxIk8LfoeuKPrp94iiom90SDMCYKcRKQNgbF
00mn8CIErkKhRsTwtN7cCwrB9H7a70UYY5RxRhobOy65G2uULEeneETKR6V8BJI7HYs0Uil7klRy
ySSPdPLJH/UbEkqo4IJsStSecrFEILdUjkkwwxRzTDLLNPNMNMWkck0223TzTTjjlBM/M+e08048
84QzTT779PNPQAHVc0c4sVwuR/9DiTTSyvwSHfRRSK+0UFEptaQUR0uXiu5SRx3tMUimPMVuv02h
ivRUiOqstMZERf30VVBNPStTUmON0VVYIwt0V1579ZXMUO/60ETQ7JJrWB5BLLYuEL8CzsDjkGVp
WgU/zAkkZx/MNjPdrj2NKJysNJBAlUTErcEJUVyx2ZGchQtAVB9VNbD5pprvOUqZHe0w8dqq90Z8
b0vN3/WGs8m69uylLjzy4OuX4Htnuq628SJW1rpoDft1Y447TjPY1RYmeGDpvJ3Jt3oTZK++b9Pb
997YEB6QYnZT/LcvAFP2bjqFLxtRZYcPXixmnzdlOV6kR3554ZVVzPJk9BDE2GX/pVm+ucGC2dsZ
N4MH1lpnsBlOmTKB6wvY6YypThrpccPFTLNjx5MO7nDV5fJcuRfU7UJhC9wt7rnbdg3wunEmNnCj
xWZw8MHRPbHl9Q5Ue+0457V11VAhxdXNze00tPOnPBZ9dNLLbAp0TB9FncrVC811xtJjl310ymu3
/XZIZ9d9dzBx9/134NfkffjdVZf09taf5hw5RpPXdD/io+f1dEZHrfIm5kvWiqc8P2/00rJ8ErH6
05PqsrUpt5vUfG21dz74peq0TfnrDVKuVetdLx+/UmUVWHvHCOly3YlS/gCoHvoBSXoL/NPzupYV
qBXGMtCaVrokNisNNW9Y33rc/8n6AyGw9M1dHuqg/db1MKGBrzLCCg5hvhIgBbXLXFmCFwTFpz77
eTCHXoJfcszUr4iBZlLgCZh86LcvriEwYVZDG/qAmLXN+IVnCSNSdQqItZopbWnQKZh6UMawKiqr
i2ZhYBk/NkB8cQ99DSPZBMlXIXjRZ4wqOhxpHDc0MW7xNjTDIRyv2K2+sQSFdnyZiyQYNTUCcC7P
6k8PFzVFhCnKM1djGs6iqDM5JjGNTeQiGHlTNhJVzH84RBQY/5ZJoT0Mk7L5IignY8ooOrJIhgzN
gKpot73ZLUNpoyMJcVku8flRLBcy2Qp9SSIpemlLJDQPIFPYyGoNc3FcEqV/Sv+4rl9KTpbbxGD3
AshNcIYzXpZbEw89ZyNxprNIZmSn6dT5TnjGU57zpGc97XlPcg5Qn9mb0fle1E6ABlSgAwXo9xyY
vk+974jYkVAeS3hPiEa0Kflk30Eztz8Z+fOWl7kOQwj6UZCGVKS642MFvxZHcblRkBmkZXNgYrJo
MhSRABxpTW3KwG/c1E8ObKO/VNlFbj2wp17cECXvVjjCSVSpSz1eTxMJSQ11h2hFbM0S2UgakV3w
gEzlqj1/mNWQrfE+9qnaULnoGaeaamxr1Glb3frWmqYol0CTZre6Vq23deioTlsWDPlWzL9E6B9w
JWxhDUs6dQqwq4tlLJUoyrb/N26VTYelbGUt26fGZlazm13OZT37WdCGVrSjJW1pTXta1I5uGall
bWtdGzvOxla2s03Ka217W9zmVre75W1vD0tb4AZXuMMlbnGNe1zkJjd3vmVuc50LUuVGV7qOfG51
rWvdYRBvutvlru2u+13whtdjSqFCd82Lu4tE1qviZW97mZTe9LL3vPNN2oqE61785le/TaJvf/37
pv0GWMADJnCBDTza/yY4tr3ohYId/GAYMRjCE6YwciRcYQxnuCkN1nCHPQyRC+OuTsQgMTH+UWIT
n5ghKUbxikkskBYPJMYwfrGMS3ziFt84xTC2cY17bGIUA3nFKpYxkXms4yHT/9jHP7Zxj41M5Bnj
GMlHzrGPd7xjKWMZx0U+8mAP7CcGf3YpWr7ylrt8FBajmctlfjKXeWxmKKu5KGymcpGt/OY7tznJ
EFkyi8usZTe/WcVkFrSQ94zlPsfZwRwOnpkI3eU0A3rNch40n/X85Eif2SiSpnOlM53mOGea0klm
s6ENPWdLaxrPdk71qo1sai9/ObdMuXGWV+1nQF95ya9uM673rGgh+9rFiA40rI3t6mArmdQ1BjWw
obzrGZu61rUOtKCd7WZJf/hUljt1tx9dbUxPu9WFJnWTib1pbA9Z168G9brPbW1cl7rJv861oln9
a3gr+d0mlvV31X1va/ca1f/g7jS5J33wS/M638Q+d7Pt/e1TXzvg7773oylu8H2nqt+4HfO0xW1n
ais7ypemdpR1HfGTIzrkKmf2v0GOcibzecpUhvnIg4ztHKdb5nk2eMIHMohBELcGVFoAlB6rbaSB
CehA37hukS5ieyx9EE1P7dOtfnWsZ/28Rx9ututJddY2pco6HrmUiz3sFzOc2SFX9sJNfmie/3nY
WZb2ruGs8nmbnck3//HJdz5wF/ed7j7XOoBN9218Y7zgCkc2Ukot903L29W8Rjzk0dxpKzfb4eDO
d88RT+NWExrsva034KudbD1jfvLj9rSqXR7xUFda4Kd3/OqTDXvYB1znAO//PMIZz+PRo3bMIl+5
6WWf+5S3vO20/zTbP53q20888WyXeOtxv/yEF/z6tMd0zL1eeDc52uWsF/i6Q1/ucRPa3ZROO/Rb
P3vdn/7jjf/84nvu+ou/XfrBPy2tec95ydM91Uu98+u+bGu4dEM90/M6ioM5iSu97Du03es9xvs+
8JMTVRk7nvs7Crw/IEs76tM7A9S/QoO2CSy5nas8W4O4zEs0dJs7GES77itBJOM/07pAHMxBHdxB
HuxBH/xBIMRBrhu+IHQKG8Qvm9vAYDM5jys+wbs5votBtZu5wZtCfZszJRw8J7M1mQO8P2s/3vtA
siuzI2wuIqxA0NM0CMy9/w7ktBe0NzQswMZjvzSUvRf8Prujs3b7wv9rtyIEHoazNFibvv87u8Qj
wPGLQwk8uAMUxNiTMwYUwPd7RNTbvs37w9oJxNeDP+9zPhnUQkQMwwmkwfnzxE0UwzXMQ0lUQD88
thhDQUxcLjLRRIAzwfNrRO4jP/VbxFBEwPRzRNCLRNYru+ibPDDcsl0EPht0gvbSQ9/7PMobNWgk
uWfkvBOUxEWkReObQeljxYVLRDgsQ+bqOGjLwulrwj4bw2M8RBHkwvvzQLMrOxGcwnRExV+UQyqs
uZxzvVjEkyHsR+QQRyYZAY4DSINUqn88SCQRyP1SSMlgSOtySIlsrBZMuf/IA0Hlw7OVizZVpMGz
oz7ns8jAwz4ppLd9VDUxXMAthEELnEhUibt3hLi7I7yMA0aF00SLG8nfy7M1rMOeFMXN40lrZEOX
nJMRsz1uhL9KpMlcPLNkdEr3m8M5DEpHvETVw0lg3D5HhEj9qj4H3MJXdEq7+71etMlBy0MXdDg/
bMdu5Mfk08fSU0Bs5DeudC5amz87jEDLs0VexMby+7d6Yzm1vMK8bMs6vMZATEVOJEtw6gcepEXN
qz3LW0xudEOdw0r0g8xvLMukhEfMNETtK0pUEb+XE8lPDMvSfEOSlD/BhEeUdEfN5MDO3EnCHECP
TEEVq0v8Es3QkZ4M0E3/wuJNIwRO3xJO49RBXThO5VxO5mxO53xO6DxO4pxO6qxO67xOxIpO7dxO
7qQt7PxO8FSS7hxPDAxP8zxP9ExP9VxP9mxP93xP+IxP+ZxP+qxP/iJP/Jws+9xP/uxP//xPAGXP
/BxQAi3QcApQBE1QBV3QQDFQB60RBo3QgnxQCv0nCb1QDM3Q/qxQDtUPDf1QEA1R9exQEv0SET1R
FE3RuuSuTyhRzVJRGI1RGd24pYIEF/UvNphRHQ2pG+3RxthRIA1SIa0uHy1SIz1SJE1SOpnPGxhS
J31SGlVSKZ1SJYVSKx0eKs1SGDEELe1SL+3HK0UtQQhTMlXRLz1TNE1TJjV1yTJtU9FZUxJ1Uzmd
UzqtUzu9UzzNUz2dUDjtUz9dkyRIsIAAADs=

------=_NextPart_000_000E_01C6FE4B.9E2FE8A0--