RE: Comments on draft-ietf-pkix-ac509prof-05.txt

["David P. Kemp" <[e-mail]>]

Sharon,

Thanks for clarifying the distinction between the "controlling" Holder
option and other options used only as search aids.  That's what I get
for reading the AC profile without being thoroughly familiar with the
base X.509 document :-(.

I agree that the precedence shown below is correct, and withdraw my
suggestion for mutual exclusion between entityName and the other
options.

Dave



> From: Sharon Boeyen <[e-mail]>
> To: "'Steve Hanna'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> Date: Fri, 27 Oct 2000 15:51:34 -0400
> 
> Yep I can explain - the second text is not text from the standard, but my 
> explanation of what I believe is intended and you are correct that in the 
> Holder, the order is not as I indicated (it is in issuer though and that's 
> where the confusion krept in). What I meant specifically was: 
> 
> - if entityName and baseCertificateID are present, then ONLY baseCertificateID 
>   may be used and entityName is a potentially helpful search tool 
> - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may 
>   be used and entityName is a potentially helpful search tool 
> - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo 
>   may be used and baseCertificateID is a potentially helpful search tool
> 
> - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY 
>   objectDigestInfo may be used and entityName and baseCertificateID are potentially 
>   helpful search tools. 
> 
> Sorry for the confusion and thanks for catching it. I shouldn't have
> tried to lump it all together. 
> 
> Sharon 




Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06071 for <[e-mail]>; Tue, 31 Oct 2000 13:47:34 -0800 (PST)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA28051 for <[e-mail]>; Tue, 31 Oct 2000 16:32:28 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 31 Oct 2000 16:46:36 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ErIfFE6qjuml4VjDp4o9Ug==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Sharon,

Thanks for clarifying the distinction between the "controlling" Holder
option and other options used only as search aids.  That's what I get
for reading the AC profile without being thoroughly familiar with the
base X.509 document :-(.

I agree that the precedence shown below is correct, and withdraw my
suggestion for mutual exclusion between entityName and the other
options.

Dave



> From: Sharon Boeyen <[e-mail]>
> To: "'Steve Hanna'" <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> Date: Fri, 27 Oct 2000 15:51:34 -0400
> 
> Yep I can explain - the second text is not text from the standard, but my 
> explanation of what I believe is intended and you are correct that in the 
> Holder, the order is not as I indicated (it is in issuer though and that's 
> where the confusion krept in). What I meant specifically was: 
> 
> - if entityName and baseCertificateID are present, then ONLY baseCertificateID 
>   may be used and entityName is a potentially helpful search tool 
> - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may 
>   be used and entityName is a potentially helpful search tool 
> - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo 
>   may be used and baseCertificateID is a potentially helpful search tool
> 
> - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY 
>   objectDigestInfo may be used and entityName and baseCertificateID are potentially 
>   helpful search tools. 
> 
> Sorry for the confusion and thanks for catching it. I shouldn't have
> tried to lump it all together. 
> 
> Sharon 



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA22060 for <[e-mail]>; Mon, 30 Oct 2000 13:02:05 -0800 (PST)
Received: (qmail 43386 invoked from network); 30 Oct 2000 21:08:16 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 30 Oct 2000 21:08:16 -0000
Received: (qmail 28904 invoked by uid 1183); 30 Oct 2000 21:08:35 -0000
Date: Mon, 30 Oct 2000 22:08:32 +0100 (MET)
From: Magnus Nystrom <[e-mail]>
X-Sender: [e-mail]
Reply-To: Magnus Nystrom <[e-mail]>
To: Tom Arnold <[e-mail]>
cc: [e-mail]
Subject: Re: WAP X.509 Certificate profile specification
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Tom,

I would suggest that you send them directly to me, unless they are
pkix-related. I will make sure to forward them to WAP's security group
mailing list - and Cc: you.

Thanks,
-- Magnus

On Mon, 30 Oct 2000, Tom Arnold wrote:

> I've downloaded the document and am beginning to review it.  My company is 
> not a member of the Wap Forum...  As such, if I have comments, where should 
> I send them? I'm assuming the PKIX list is not the correct location...
> 
> At 04:19 PM 10/26/2000 +0200, you wrote:
> >Dear PKIX members,
> >
> >On behalf of WAP's security group WSG, I would like to inform you that
> >a document named "WAPCert-20000309" can be found at
> >
> >http://www.wapforum.org/what/technical.htm.
> >
> >This document describes X.509 certificate profiles to be used for those
> >cases when X.509-compliant certificates will be sent over-the-air in WAP
> >protocols (or stored locally in WAP clients).
> >
> >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> >
> >Comments and suggestions related to these documents are welcome and
> >solicited.



Received: from rigor.cybersource.com ([216.34.12.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20571 for <[e-mail]>; Mon, 30 Oct 2000 11:57:09 -0800 (PST)
Received: from t_arnold-1.cybersource.com (dhcp-7-137.office.cybersource.com [10.2.7.137]) by rigor.cybersource.com (8.9.1/8.9.1) with ESMTP id MAA13023; Mon, 30 Oct 2000 12:01:50 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 30 Oct 2000 12:04:19 -0800
To: Magnus Nystrom <[e-mail]>
From: Tom Arnold <[e-mail]>
Subject: Re: WAP X.509 Certificate profile specification
Cc: [e-mail]
In-Reply-To: <[e-mail]. se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I've downloaded the document and am beginning to review it.  My company is 
not a member of the Wap Forum...  As such, if I have comments, where should 
I send them? I'm assuming the PKIX list is not the correct location...

At 04:19 PM 10/26/2000 +0200, you wrote:
>Dear PKIX members,
>
>On behalf of WAP's security group WSG, I would like to inform you that
>a document named "WAPCert-20000309" can be found at
>
>http://www.wapforum.org/what/technical.htm.
>
>This document describes X.509 certificate profiles to be used for those
>cases when X.509-compliant certificates will be sent over-the-air in WAP
>protocols (or stored locally in WAP clients).
>
>An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
>
>Comments and suggestions related to these documents are welcome and
>solicited.
>
>Thanks,
>-- Magnus
>Magnus Nystrom
>RSA Security



Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: [e-mail]
Main: 650.965.6000
PGP Fingerprint: 2EB6 F7F0 6D80 A8E5 9BEC  A05A 0295 0ADE 8F42 EB0D
PGP keys located on PGP and MIT servers at pgp.com and mit.edu

---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18818 for <[e-mail]>; Mon, 30 Oct 2000 10:38:27 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 30 Oct 2000 10:44:32 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 30 Oct 2000 10:44:31 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id <VSC4G8J5>; Mon, 30 Oct 2000 10:43:01 -0800
Content-return: allowed
Date: Mon, 30 Oct 2000 10:41:31 -0800
From: Peter Williams <[e-mail]>
Subject: RE: TSP-11 comments.
To: "'Denis Pinkas'" <[e-mail]>, Parag Namjoshi <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Deferred-delivery: Mon, 30 Oct 2000 10:43:00 -0800

 
 

The various policy signals are appropriately
signaled by the certificate policy ids, as qualified
by users, for each signing algorithm, by WIPO usage
control parameters noticed in the OCSP
or TSA signing block.

 



-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Monday, October 30, 2000 5:08 AM
To: Parag Namjoshi
Cc: IETF-PXIX
Subject: Re: TSP-11 comments.


Parag,
 
> Hi Denis,
> 
> Some comments about TSP-11 draft.
> 
> 1. The sixth point in security considerations text does seem to consider
> the possibility of deliberate replay of requests. Consider a service
> provider who charges for timestamping. Client sends a (possibly signed)
> request. The attacker replays the request as many times as he likes !!!
> The attack will be detected when the subscriber gets an impressive bill at
> the end of the month :-) This can mess up any logging done by the server.
> The server could possibly maintain a window of recent nonces to reduce the
> intensity of this attack (Replay then can be attempted again after the
> window has moved on.) This can cause big problems with billing systems of
> the server. To defeat this attack, the requester should include his local
> time in the request. Server can then verify the timeliness of the request
> by verifying the time included in the request against its timesource and
> issue token accordingly.

Authentication of requests is outside the scope of this document and can be
made using various means. Replay protection is dependent upon the data
origin authentication mechanism which is outside the scope of this document.
 
> 2. The text for the sixth point is little unclear. Perhaps replay
> detection at server & client should treated under two different bullets.

If you have a better text, I would be happy to consider it so that it could
possibly be included next year when we will go from Proposed Standard to
Standard.

> 3. Removal of 'policyQualifiers' effectively disallows CPS like structures
> for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate
> requirement for a TSA. Wouldn't it be worthwhile to reintroduce
> TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS
> capability to avoid it ?

Russ Housley gave arguments. This is not necessary. 

> 4. The draft does not define OID's for  "standard" policies.e.g.
> * The conditions under which the time stamp may be used.
> * The availability of a time-stamp log, to allow later verification that a
> time-stamp token is authentic
> This may lead to interop problems. Could the draft define a few standard
> policy OID's like RFC2459 ?

This is a valid proposal. This could be the topic of new document. Let us
discuss this on the amiling list and/or at the coming San Diego meeting. If
this is agreed we would need to extend our charter.

Regards,

Denis
 
> Regards,
> Parag.


Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14348 for <[e-mail]>; Mon, 30 Oct 2000 09:02:51 -0800 (PST)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id SAA63527 for <[e-mail]>; Mon, 30 Oct 2000 18:09:00 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.9.3/8.9.3) id QAA72989 for [e-mail]; Mon, 30 Oct 2000 16:04:40 +0100 (CET) (envelope-from tho)
Date: Mon, 30 Oct 2000 16:04:40 +0100
From: tho <[e-mail]>
To: [e-mail]
Subject: a TSP-11 compliant implementation
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
X-Operating-System: FreeBSD

hello,
we have upgraded our timestamper in order to meet version 11 specs and 
we also added the http protocol interface in addition to the "tcp" based
one.
if you are interested in doing some testing the following is the url
where you can find further informations: http://195.223.2.6:8080

thanks to Peter Sylvester for being the very first to test it. :)

tho
-- 
(__)                
(oo)                       
 \/-------\         
  ||     | \    
  ||---W||  *  



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28975 for <[e-mail]>; Mon, 30 Oct 2000 05:02:08 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA47262; Mon, 30 Oct 2000 14:13:52 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA21494; Mon, 30 Oct 2000 14:07:41 +0100
Message-ID: <[e-mail]>
Date: Mon, 30 Oct 2000 14:07:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Parag Namjoshi <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: TSP-11 comments.
References: <01c701c0426f$94cd00c0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Parag,
 
> Hi Denis,
> 
> Some comments about TSP-11 draft.
> 
> 1. The sixth point in security considerations text does seem to consider
> the possibility of deliberate replay of requests. Consider a service
> provider who charges for timestamping. Client sends a (possibly signed)
> request. The attacker replays the request as many times as he likes !!!
> The attack will be detected when the subscriber gets an impressive bill at
> the end of the month :-) This can mess up any logging done by the server.
> The server could possibly maintain a window of recent nonces to reduce the
> intensity of this attack (Replay then can be attempted again after the
> window has moved on.) This can cause big problems with billing systems of
> the server. To defeat this attack, the requester should include his local
> time in the request. Server can then verify the timeliness of the request
> by verifying the time included in the request against its timesource and
> issue token accordingly.

Authentication of requests is outside the scope of this document and can be
made using various means. Replay protection is dependent upon the data
origin authentication mechanism which is outside the scope of this document.
 
> 2. The text for the sixth point is little unclear. Perhaps replay
> detection at server & client should treated under two different bullets.

If you have a better text, I would be happy to consider it so that it could
possibly be included next year when we will go from Proposed Standard to
Standard.

> 3. Removal of 'policyQualifiers' effectively disallows CPS like structures
> for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate
> requirement for a TSA. Wouldn't it be worthwhile to reintroduce
> TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS
> capability to avoid it ?

Russ Housley gave arguments. This is not necessary. 

> 4. The draft does not define OID's for  "standard" policies.e.g.
> * The conditions under which the time stamp may be used.
> * The availability of a time-stamp log, to allow later verification that a
> time-stamp token is authentic
> This may lead to interop problems. Could the draft define a few standard
> policy OID's like RFC2459 ?

This is a valid proposal. This could be the topic of new document. Let us
discuss this on the amiling list and/or at the coming San Diego meeting. If
this is agreed we would need to extend our charter.

Regards,

Denis
 
> Regards,
> Parag.


Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27606 for <[e-mail]>; Mon, 30 Oct 2000 04:43:58 -0800 (PST)
Received: from risk (risk.fcpl.co.in [196.1.104.25]) by getafix.fcpl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VQZNMQQN; Mon, 30 Oct 2000 18:21:23 +0530
Message-ID: <01c701c0426f$94cd00c0$[e-mail]>
From: "Parag Namjoshi" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
Subject: TSP-11 comments.
Date: Mon, 30 Oct 2000 18:17:33 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C4_01C0429D.AC0C9BA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

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

Hi Denis,

Some comments about TSP-11 draft.

1. The sixth point in security considerations text does seem to consider =
the possibility of deliberate replay of requests. Consider a service =
provider who charges for timestamping. Client sends a (possibly signed) =
request. The attacker replays the request as many times as he likes !!! =
The attack will be detected when the subscriber gets an impressive bill =
at the end of the month :-) This can mess up any logging done by the =
server. The server could possibly maintain a window of recent nonces to =
reduce the intensity of this attack (Replay then can be attempted again =
after the window has moved on.) This can cause big problems with billing =
systems of the server. To defeat this attack, the requester should =
include his local time in the request. Server can then verify the =
timeliness of the request by verifying the time included in the request =
against its timesource and issue token accordingly.

2. The text for the sixth point is little unclear. Perhaps replay =
detection at server & client should treated under two different bullets.

3. Removal of 'policyQualifiers' effectively disallows CPS like =
structures for TSA. I feel "Timestamp Practices Statement" (TPS) is a =
legitimate requirement for a TSA. Wouldn't it be worthwhile to =
reintroduce TSAPolicyQualifiers or is it so detestable, that we  =
sacrifice TPS capability to avoid it ?

4. The draft does not define OID's for  "standard" policies.e.g.
* The conditions under which the time stamp may be used.
* The availability of a time-stamp log, to allow later verification that =
a time-stamp token is authentic
This may lead to interop problems. Could the draft define a few standard =
policy OID's like RFC2459 ?

Regards,
Parag.

------=_NextPart_000_01C4_01C0429D.AC0C9BA0
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 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>
<DIV>Hi Denis,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Some&nbsp;comments&nbsp;about TSP-11 draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>1. The sixth point in security considerations text does seem to =
consider=20
the possibility of deliberate replay of requests. Consider a service =
provider=20
who charges for timestamping. Client sends a (possibly signed) =
request.&nbsp;The=20
attacker&nbsp;replays the request&nbsp;as many times as he likes !!! The =
attack=20
will be detected when the&nbsp;subscriber&nbsp;gets an impressive bill =
at the=20
end of the month :-) This can mess up&nbsp;any logging done by the =
server. The=20
server could possibly maintain a window of&nbsp;recent=20
nonces&nbsp;to&nbsp;reduce the intensity of&nbsp;this attack (Replay =
then can=20
be&nbsp;attempted again after the window has moved on.) This =
can&nbsp;cause big=20
problems&nbsp;with&nbsp;billing systems of the server.&nbsp;To defeat =
this=20
attack, the requester should include his local time in the =
request.&nbsp;Server=20
can then verify the timeliness of the request by verifying the time =
included in=20
the request against its timesource and issue token accordingly.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. The text for the sixth point is little unclear. Perhaps replay =
detection=20
at server &amp; client should&nbsp;treated&nbsp;under two different=20
bullets.</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>3.&nbsp;Removal of 'policyQualifiers' effectively disallows CPS =
like=20
structures for TSA. I feel "Timestamp Practices Statement"&nbsp;(TPS) is =
a=20
legitimate requirement for a TSA.&nbsp;Wouldn't it&nbsp;be worthwhile to =

reintroduce TSAPolicyQualifiers or is it so detestable, that we&nbsp; =
sacrifice=20
TPS capability to avoid it ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>4. The draft does not define OID's for&nbsp; "standard" =
policies.e.g.</DIV>
<DIV>* The conditions under which the time stamp may be used.<BR>* The=20
availability of a time-stamp log, to allow later verification&nbsp;that =
a=20
time-stamp token is authentic</DIV>
<DIV>This&nbsp;may lead to interop problems. Could the draft define a =
few=20
standard policy OID's like RFC2459 ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Parag.</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_01C4_01C0429D.AC0C9BA0--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17182; Mon, 30 Oct 2000 02:49:54 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA16164; Mon, 30 Oct 2000 12:01:15 +0100
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA17102; Mon, 30 Oct 2000 11:55:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 30 Oct 2000 11:55:00 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: Call for papers: INFOSEC 2001
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAB17186

INFOSEC 2001

15th exhibition and conference on the security of information systems and
communications

29.30.31 May - CNIT Paris-La Défense - FRANCE

CALL FOR PAPERS

Topics may be addressed from a technical, juridical or organizational
perspective. For 2001, the Programmes Committee will essentially, though not
exclusively, emphasise the following themes:

E-business, e-commerce - Insurance coverage for information systems -
Personal data: risks, means of protection - Competitive Intelligence (CI)
and counter-CI - Crisis management - Law : digital signature - Employees
control - Digital evidence and computer forensic - Specific product security
(NT, Linux, Oracle, etc.) - etc.

PROGRAMMES COMMITTEE

President: Pascal LOINTIER, ACE Insurance

Members: Prof. Danilo BRUSCHI, Université de Milan, Italie - Michèle
COPITET, EGONA CONSULTING - Michel DUPUY, SGDN/DCSSI - Cert A - Paul
GRASSART, CLUSIF - Frédéric HUYNH, ARTHUR ANDERSEN - Jean-Philippe JOUAS,
2SI - Me Bruno P. LANGLOIS, ALAIN BENSOUSSAN - AVOCATS - Patrick LAUTIER,
CLUSIF - Robert LONGEON, CNRS - Pierre-Marie LORANG, THOMSON CSF-DETEXIS -
Marie-Christine MARTEL, SGDN/DCSSI - Denis PINKAS, BULL - Paul RICHY, FRANCE
TELECOM - BR/DACR - Philippe ROSE, LE MONDE  - INFORMATIQUE - Stéphane
ROUHIER, CIGREF - Serge SAGHROUNE, ACCOR - Paul TRESCASES, GIE Cartes
Bancaires - Marcel VIGOUROUX, OCLCTIC

Organisation: Maryse DELERIS, M.C.I.

Sponsorship of CLUSIF ([e-mail]) Club de la Sécurité des
Systèmes d'Information Français and SGDN Premier Ministre - Direction
Centrale de la Sécurité des Systèmes d'Information (DCSSI).

DEADLINE TO SUBMIT A PROPOSAL : 31.12.2000

PRACTICAL INFORMATION

Authors have to send their proposal to M.C.I. (letter, fax or e-mail:
[e-mail]) by December 31st, 2000: an abstract (maximum of 3
pages) indicating: TITLE of the subject - and complete address of author(s)

At the end of January 2001, authors will receive the Programmes Committee's
decision. Selected authors will have to send the paper (following detailed
instructions) by February 25th, 2001 to be reviewed and definitively
accepted. Authors will have to certify their paper will not be published
prior to May 31st, 2001. Overtly " commercial " presentations are
inappropriate. 

Free admission offered for speakers (congress and exhibition).

INFORMATION  & ORGANISATION
M.C.I. - Manifestations & Communications Internationales
19 Rue d'Athènes - 75009 PARIS - FRANCE
Tél. : [phone] - Fax : [phone]
E-mail : [e-mail] - 
Web : http://www.mci-salons.fr/infosec


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26172 for <[e-mail]>; Sun, 29 Oct 2000 11:01:44 -0800 (PST)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id OAA21851; Sun, 29 Oct 2000 14:03:26 -0500
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Sun, 29 Oct 2000 14:03:25 -0500 (EST)
From: Polar Humenn <[e-mail]>
To: "Covey, Carlin" <[e-mail]>
cc: "'Dale Gustafson'" <[e-mail]>, [e-mail], "Linn, John" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 27 Oct 2000, Covey, Carlin wrote:

> Polar, see comments embedded below.
> 
> > -----Original Message-----
> > From: Polar Humenn [mailto:[e-mail]]
> > Sent: Friday, October 27, 2000 2:02 PM
> > To: Linn, John
> > Cc: 'Dale Gustafson'; [e-mail]
> > Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> (snip) 
> 
> 
> > A public key can be cross certified by an "attribute authority"
> > merely by issuing another PKC hand it back to the Holder. 
> 
> (snip)
> 
> > Granted the CA/RA of the original public key would be different, 
> > but that information may be included in the PKC as an extension should 
> > that matter to the Relying Party (it might and it might not, depending 
> > on RP's belief in the attribute authority's due diligence).
> 
> [Carlin]:  By "cross certified by an 'attribute authority' " I assume
> that you mean that a CA acting in the capacity of an attribute
> authority (as opposed to an AC Issuer as defined in the AC Draft)
> issues a new PKC using the subject identifier and public key from an
> existing PKC?

Yes, I believe that's what a cross-certification is. I was told that
basically, any public key certificate that is not self signed is a cross
certificate.

> To this new PKC the CA-cum-AA adds some extensions that specify
> certain attributes. At first glance this is appealingly simple, but
> upon reflection it does raise some issues.

Yep.
 
> Issue #1:  PKC's are supposed to be accepted by the subject before
> they are made generally available, whereas there appears to be no such
> requirement with respect to AC's.  

There might be a convention that the subject accepts a certificate before
it's "deployed", but that doesn't really have to happen. What does
"accept" and "generally available" really mean without some context of an
specific application?

> Do you envision that the subject would request the new PKC via some
> standard protocol that incorporates a notification of acceptance?

The only real purpose for these attribute certs as I see it, is so that
effort of retrieving them them and possibly caching them is left to the
client, not the Relying Party, which may be a high throughput server. I
was told that these kinds of servers don't want the overhead of the
authorization lookup. However if that is the reasoning, then with ACs now
they have to do not one, but *two* fairly expensive path discovery and
chain verifications, which may require two calls to an OCSP server at the
very least, if not countless look ups for CRLs, etc.

> Do you envision that the CA-cum-AA might initiate the issuance of the
> new "attribute-enhanced PKC", and would solicit an acknowledgment of
> acceptance from the subject?

I imagine so. I would think that the Client would have to get the
certificate (although that's not strictly necessary).

> Issue #2:  The same public key now appears in two different PKC's
> issued by different CA's.  The CA-cum-AA is obligated to maintain the
> revocation status of the new PKC.  I suppose the new PKC could include
> a pointer to the original CA for certificate status (or to the status
> distribution point specified in the original PKC), but this would not
> allow the attributes in the new PKC to be revoked independent of
> original PKC.  This would not be a problem if the new PKC were
> short-lived and was not intended to be revocable.  But if the new PKC
> were longer-lived, then the CA-cum-AA would be obligated to track the
> revocation status of the original PKC as well as the revocation status
> of the attributes in the new PKC, and for the benefit of RP's for the
> new PKC.

Well, therein lies the crux of all the problems with public key
certificates, revocation. Certificates in my mind, merely certify that a
public key is associated with certain attributes, such as the DN, and a
validity period for the CERTIFICATE, NOT the public key.

I would imagine that if my "new" PKC is valid only on the revocation
status of the "original" PKC (of which you really have no absolute
knowledge that it is "original"). Yes, you would need a pointer to the
status of that certificate. Okay, so? revocation isn't that complex
already?

> Issue #3: The original PKC might be "renewed" prior to its
> "not-valid-after date" by being revoked and replaced by a new PKC with
> the same public key, but a later validity date.  Must the
> "attribute-enhanced PKC"  also be revoked and reissued?

I don't see why. When you issue a new PKC all you are doing is naming a
context for which the public/private key will be used. If its valid enough
for the Relying Party, then fine. The user who acts with the Relying party
has to do what he has to do. If that means getting a new
"attribute-enhanced PKC" then so be it. If you have such complex
revocation strategies/policies, you got a problem anyway, especially if
the public key is cross certified elsewhere. I don't see what the
difference really is.

> Issue #4: Is the CA-cum-AA obligated to mimic the original CA in the
> RP's trust model?  

I would tend to doubt that. The Relying Party may have it's own PKI where
it is a single level CA, and just issues the new "attribute enhanced" PKC
with the public key from some users PKC that it trusts in some form or
another. That CA performs what ever due diligence is needed. The user is
given the new "attribute-enhanced PKC" which she can use for
authentication, signature, authorization in the context of that PKI and is
subscribing Relying Parties. I had thought that is the real way
cross-certification is supposed to work, except for merely the
"convention" of only cross-certifying CAs and not "users".

> If the original CA was directly trusted by the RP,
> then I suppose the CA-cum-AA must also be directly trusted by the RP.

Quite obviously. However, let's get rid of this notion of the "original
CA". As far as a Relying Party is concerned, if the CA-cum-AA is trusted,
then the "original" doesn't enter into the equation, unless there is
something in the "new" PKC that says it should.

> If the original CA is cross-certified with other CA's I guess the
> CA-cum-AA is not obligated to cross certify with those other CA's.  

I don't see why it would. It's only cross certifying the public key to be
used in the context of authentication, signature, and authorization that
is relevant to the Relying Party.

> But is it permissible for the CA-cum-CA to cross-certify with CA's
> with which the original CA is not cross-certified?  Note that this
> would make the subject's signature valid outside of its original
> context.

No, the subject's signature is valid for the context for which the
certificate is created. Any cross-certifications merely put further
constraints on that validity with respect to the Relying Party.

Cheers,
-Polar

> Polar, I don't expect you to address these issues (unless you want
> to).  I was just trying to point out that the simple approach may not
> be so simple after all.
> 
> - Carlin Covey
>   Cylink Corp.
>                       
>  
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from tycho.ncsc.mil (tarius.tycho.ncsc.mil [144.51.3.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21695 for <[e-mail]>; Sat, 28 Oct 2000 08:21:39 -0700 (PDT)
Received: from zanyclown.tycho.ncsc.mil (zanyclown [144.51.3.100]) by tycho.ncsc.mil (8.9.3/8.9.3) with ESMTP id LAA25874 for <[e-mail]>; Sat, 28 Oct 2000 11:27:11 -0400 (EDT)
Received: by zanyclown.tycho.ncsc.mil with Internet Mail Service (5.5.2650.21) id <VVLBZJFG>; Sat, 28 Oct 2000 11:25:59 -0400
Message-ID: <[e-mail]>
From: "Gary W. Seehousz" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Sat, 28 Oct 2000 11:25:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11316 for <[e-mail]>; Sat, 28 Oct 2000 00:31:34 -0700 (PDT)
Received: from mega (t1o69p69.telia.com [62.20.144.69]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA21098; Sat, 28 Oct 2000 09:37:16 +0200 (CEST)
Message-ID: <001001c040b1$b95d1c50$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Dale Gustafson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Sat, 28 Oct 2000 09:35:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA11318

Dale et al,

>Actually, I'm hopeful but not sure.
>
>Had you asked me three or four years ago to predict when I could routinely exchange secure email with others or login to a commercial web server using a private key / certificate rather than a simple user name and password, I would have guessed a year, maybe 18 months at the outside.  That hasn't happened yet and we have to wait for that to be put into place before subsequent elements, like Timestamp servers and ACs, can come into play.
>
>So, we appear to be in a similar position to the people who worked on x.509 v1 certificates back before SSL and S/MIME were proposed >then standardized -- they may have felt that good things were likely to happen but they must have been taking quite a lot on faith early on.

Question: What does support for ACs really mean?

Being an implementor/deployer I see some problems for let's say Microsoft to actually know what to support
as the "Product Matrix" is pretty large given the current AC draft.

Issuing: To issue ACs with cryptographic links to existing PKCs is very different compared to issuing ACs with
just a name reference.

PULL model: Easy to support (and to replace with other systems).  But is it that useful? Does it scale?

PUSH model: This *could* require changes in TLS, browsers, Client OSes and is therefore a major task/risk to pursue.

I.e. the AC *format* is only the tip of the iceberg.

This is a product manager's nightmare which typically causes a "wait-and-see" situation.

Just my 2 öres.

/Anders




Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08716 for <[e-mail]>; Fri, 27 Oct 2000 15:35:36 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <VBLVX7LH>; Fri, 27 Oct 2000 15:37:23 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: Polar Humenn <[e-mail]>
Cc: "'Dale Gustafson'" <[e-mail]>, [e-mail], "Linn, John" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 15:37:21 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Polar, see comments embedded below.

> -----Original Message-----
> From: Polar Humenn [mailto:[e-mail]]
> Sent: Friday, October 27, 2000 2:02 PM
> To: Linn, John
> Cc: 'Dale Gustafson'; [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

(snip) 


> A public key can be cross certified by an "attribute authority"
> merely by issuing another PKC hand it back to the Holder. 

(snip)

> Granted the CA/RA of the original public key would be different, 
> but that information may be included in the PKC as an extension should 
> that matter to the Relying Party (it might and it might not, depending 
> on RP's belief in the attribute authority's due diligence).

[Carlin]:  By "cross certified by an 'attribute authority' " I assume that
           you mean that a CA acting in the capacity of an attribute
authority
           (as opposed to an AC Issuer as defined in the AC Draft) issues a
new 
           PKC using the subject identifier and public key from an existing
PKC?
           To this new PKC the CA-cum-AA adds some extensions that specify
certain
           attributes. At first glance this is appealingly simple, but upon 
           reflection it does raise some issues.  

           Issue #1:  PKC's are supposed to be accepted by the subject
before they
                      are made generally available, whereas there appears to
be no
                      such requirement with respect to AC's.  Do you
envision that
                      the subject would request the new PKC via some
standard
                      protocol that incorporates a notification of
acceptance?
                      Do you envision that the CA-cum-AA might initiate the
issuance 
                      of the new "attribute-enhanced PKC", and would solicit
an
                      acknowledgement of acceptance from the subject?

           Issue #2:  The same public key now appears in two different PKC's
issued
                      by different CA's.  The CA-cum-AA is obligated to
maintain the
                      revocation status of the new PKC.  I suppose the new
PKC could
                      include a pointer to the original CA for certificate
status (or
                      to the status distribution point specified in the
original PKC),
                      but this would not allow the attributes in the new PKC
to be
                      revoked independent of original PKC.  This would not
be a problem
                      if the new PKC were short-lived and was not intended
to be revocable.
                      But if the new PKC were longer-lived, then the
CA-cum-AA would be
                      obligated to track the revocation status of the
original PKC as well
                      as the revocation status of the attributes in the new
PKC, and 
                      merge these into a single revocation status mechanism
for the 
                      benefit of RP's for the new PKC.

            Issue #3: The original PKC might be "renewed" prior to its
"not-valid-after 
                      date" by being revoked and replaced by a new PKC with
the same public 
                      key, but a later validity date.  Must the
"attribute-enhanced PKC" 
                      also be revoked and reissued?  

            Issue #4: Is the CA-cum-AA obligated to mimic the original CA in
the RP's trust 
                      model?  If the original CA was directly trusted by the
RP, then I 
                      suppose the CA-cum-AA must also be directly trusted by
the RP.  If
                      the original CA is cross-certified with other CA's I
guess the CA-cum-AA 
                      is not obligated to cross certify with those other
CA's.  But is it
                      permissible for the CA-cum-CA to cross-certify with
CA's with which the
                      original CA is not cross-certified?  Note that this
would make the subject's 
                      signature valid outside of its original context.

Polar, I don't expect you to address these issues (unless you want to).  I
was just trying to
point out that the simple approach may not be so simple after all.

- Carlin Covey
  Cylink Corp.
                      
 


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06503 for <[e-mail]>; Fri, 27 Oct 2000 14:01:00 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA19358; Fri, 27 Oct 2000 17:02:25 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 27 Oct 2000 17:02:24 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "Linn, John" <[e-mail]>
cc: "'Dale Gustafson'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 27 Oct 2000, Linn, John wrote:

> Dale wrote:
> 
> > Hi Anders,
> > 
> > Actually, I'm hopeful but not sure.
> > 
> > Had you asked me three or four years ago to predict when I 
> > could routinely exchange secure email with others or login to 
> > a commercial web server using a private key / certificate 
> > rather than a simple user name and password, I would have 
> > guessed a year, maybe 18 months at the outside.  That hasn't 
> > happened yet and we have to wait for that to be put into 
> > place before subsequent elements, like Timestamp servers and 
> > ACs, can come into play.
> > 
> > So, we appear to be in a similar position to the people who 
> > worked on x.509 v1 certificates back before SSL and S/MIME 
> > were proposed then standardized -- they may have felt that 
> > good things were likely to happen but they must have been 
> > taking quite a lot on faith early on.
> 
> Recalling those pre-PKIX days, when PEM was the motivating driver for
> considering PKI's application to the Internet, makes me conclude that faith
> should be carefully measured.  As experiences suggest, infrastructures
> usually take longer to deploy than is first anticipated; the "inevitable"
> can spend a long time "just around the corner" and may or may not still be
> inevitable if and when it emerges, depending on how the world has changed in
> the interim.  PKI is now increasingly mainstream in the Internet (yes!!),
> but this result follows more than a decade's worth of activity.  
> 
> I believe that a separate PMI can afford powerful generality and that
> specification of ACs should be pursued. Against the historic backdrop,
> however, I'm also concerned that such a PMI may take a long time to become
> pervasive.  Given this concern, the prospect of placing attributes in PKCs
> and thereby leveraging the now-existing PKI directly and incrementally seems
> attractive, where consistent with organizational responsibilities and
> attribute lifetimes. 

I agree. A public key can be cross certified by an "attribute authority"
merely by issuing another PKC hand it back to the Holder. The holder can
then use that certificate to certify that he indeed does have those
privileges should he have the capability, such as in SSL, to deliver the
Relying Party the certificate which only defines the privilege context in
which the user is using its authentication. Granted the CA/RA of the
original public key would be different, but that information may be
included in the PKC as an extension should that matter to the Relying
Party (it might and it might not, depending on RP's belief in the
attribute authority's due diligence).

I also agree with Bob Jeuneman that when coming to attribute authorities,
there may need to be certificate chains of authorities constraining, just
as the name constraints work in PKCs, the ability to grant only certian
privileges, and the prevention of granting certian privileges to
constituents. I don't see that working currently with ACs.

However, I imagine if somebody will build some of this stuff, somebody
will buy (or get sold) it somewhere down the line, and spend a lot of time
and money integrating their applications with it. I don't see that as a
bad thing, that's the way we all make money. 

Cheers,
-Polar


-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA04209 for <[e-mail]>; Fri, 27 Oct 2000 13:32:48 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Oct 2000 20:36:59 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA00643; Fri, 27 Oct 2000 16:34:57 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <VL6GPR6P>; Fri, 27 Oct 2000 16:38:37 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Dale Gustafson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 16:38:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Dale wrote:

> Hi Anders,
> 
> Actually, I'm hopeful but not sure.
> 
> Had you asked me three or four years ago to predict when I 
> could routinely exchange secure email with others or login to 
> a commercial web server using a private key / certificate 
> rather than a simple user name and password, I would have 
> guessed a year, maybe 18 months at the outside.  That hasn't 
> happened yet and we have to wait for that to be put into 
> place before subsequent elements, like Timestamp servers and 
> ACs, can come into play.
> 
> So, we appear to be in a similar position to the people who 
> worked on x.509 v1 certificates back before SSL and S/MIME 
> were proposed then standardized -- they may have felt that 
> good things were likely to happen but they must have been 
> taking quite a lot on faith early on.

Recalling those pre-PKIX days, when PEM was the motivating driver for
considering PKI's application to the Internet, makes me conclude that faith
should be carefully measured.  As experiences suggest, infrastructures
usually take longer to deploy than is first anticipated; the "inevitable"
can spend a long time "just around the corner" and may or may not still be
inevitable if and when it emerges, depending on how the world has changed in
the interim.  PKI is now increasingly mainstream in the Internet (yes!!),
but this result follows more than a decade's worth of activity.  

I believe that a separate PMI can afford powerful generality and that
specification of ACs should be pursued. Against the historic backdrop,
however, I'm also concerned that such a PMI may take a long time to become
pervasive.  Given this concern, the prospect of placing attributes in PKCs
and thereby leveraging the now-existing PKI directly and incrementally seems
attractive, where consistent with organizational responsibilities and
attribute lifetimes. 

--jl


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02021 for <[e-mail]>; Fri, 27 Oct 2000 12:54:23 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <VXK1DHM0>; Fri, 27 Oct 2000 15:59:44 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 15:51:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0404F.4FA0B4A0"

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_01C0404F.4FA0B4A0
Content-Type: text/plain;
	charset="iso-8859-1"

Yep I can explain - the second text is not text from the standard, but my 
explanation of what I believe is intended and you are correct that in the 
Holder, the order is not as I indicated (it is in issuer though and that's 
where the confusion krept in). What I meant specifically was:

- if entity name and baseCertificateID are present, then ONLY
baseCertificateID
  may be used and entityName is a potentially helpful search tool
- if entityName and objectDigestInfo are present, then ONLY objectDigestInfo
may
  be used and entityName is a potentially helpful search tool
- if baseCertificateID and objectDigestInfo are present, then ONLY
objectDigestInfo
  may be used and baseCertificateID is a potentially helpful search tool
- if entityName, baseCertificateID and objectDigestInfo are present, the
ONLY 
  objectDigestInfo may be used and entityName and baseCertificateID are
potentially 
  helpful search tools.

Sorry for the confusion and thanks for catching it. I shouldn't have tried
to lump it all together.

Sharon

> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Friday, October 27, 2000 1:00 PM
> To: Sharon Boeyen
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> 
> I think there's an inconsistency here:
> 
> > Sharon Boeyen wrote:
> > "If baseCertificateID and entityName are both present, only the
> > certificate specified by baseCertificateID may be used. In this case
> > entityName is included only as a tool to help the privilege verifier
> > locate the identified public-key certificate."
> 
> ... then later ...
> 
> > the final present element is the ONLY one that is to be 
> used and that
> > any other elements of the SEQUENCE that are also present 
> are provided
> > ONLY as hints to enable verifiers to find the object.
> 
> If baseCertificateID and entityName are both present, this would argue
> that entityName should be the ONLY element used for validation (since
> entityName is the second element in the Holder SEQUENCE and
> baseCertificateID is the first).
> 
> Can you explain this?
> 
> -Steve
> 

------_=_NextPart_001_01C0404F.4FA0B4A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Yep I can explain - the second text is not text from the standard, but my </FONT>
<BR><FONT SIZE=2>explanation of what I believe is intended and you are correct that in the </FONT>
<BR><FONT SIZE=2>Holder, the order is not as I indicated (it is in issuer though and that's </FONT>
<BR><FONT SIZE=2>where the confusion krept in). What I meant specifically was:</FONT>
</P>

<P><FONT SIZE=2>- if entity name and baseCertificateID are present, then ONLY baseCertificateID</FONT>
<BR><FONT SIZE=2>&nbsp; may be used and entityName is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may</FONT>
<BR><FONT SIZE=2>&nbsp; be used and entityName is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo</FONT>
<BR><FONT SIZE=2>&nbsp; may be used and baseCertificateID is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if entityName, baseCertificateID and objectDigestInfo are present, the ONLY </FONT>
<BR><FONT SIZE=2>&nbsp; objectDigestInfo may be used and entityName and baseCertificateID are potentially </FONT>
<BR><FONT SIZE=2>&nbsp; helpful search tools.</FONT>
</P>

<P><FONT SIZE=2>Sorry for the confusion and thanks for catching it. I shouldn't have tried to lump it all together.</FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Steve Hanna [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, October 27, 2000 1:00 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think there's an inconsistency here:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;If baseCertificateID and entityName are both present, only the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate specified by baseCertificateID may be used. In this case</FONT>
<BR><FONT SIZE=2>&gt; &gt; entityName is included only as a tool to help the privilege verifier</FONT>
<BR><FONT SIZE=2>&gt; &gt; locate the identified public-key certificate.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ... then later ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; the final present element is the ONLY one that is to be </FONT>
<BR><FONT SIZE=2>&gt; used and that</FONT>
<BR><FONT SIZE=2>&gt; &gt; any other elements of the SEQUENCE that are also present </FONT>
<BR><FONT SIZE=2>&gt; are provided</FONT>
<BR><FONT SIZE=2>&gt; &gt; ONLY as hints to enable verifiers to find the object.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If baseCertificateID and entityName are both present, this would argue</FONT>
<BR><FONT SIZE=2>&gt; that entityName should be the ONLY element used for validation (since</FONT>
<BR><FONT SIZE=2>&gt; entityName is the second element in the Holder SEQUENCE and</FONT>
<BR><FONT SIZE=2>&gt; baseCertificateID is the first).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Can you explain this?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0404F.4FA0B4A0--


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29719 for <[e-mail]>; Fri, 27 Oct 2000 12:04:55 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14023; Fri, 27 Oct 2000 12:10:44 -0700 (PDT)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28814; Fri, 27 Oct 2000 13:01:41 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id NAA12666; Fri, 27 Oct 2000 13:01:40 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 27 Oct 2000 12:59:47 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think there's an inconsistency here:

> Sharon Boeyen wrote:
> "If baseCertificateID and entityName are both present, only the
> certificate specified by baseCertificateID may be used. In this case
> entityName is included only as a tool to help the privilege verifier
> locate the identified public-key certificate."

... then later ...

> the final present element is the ONLY one that is to be used and that
> any other elements of the SEQUENCE that are also present are provided
> ONLY as hints to enable verifiers to find the object.

If baseCertificateID and entityName are both present, this would argue
that entityName should be the ONLY element used for validation (since
entityName is the second element in the Holder SEQUENCE and
baseCertificateID is the first).

Can you explain this?

-Steve


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21551 for <[e-mail]>; Fri, 27 Oct 2000 09:56:13 -0700 (PDT)
Received: from bpsi.net (port413.bpsi.net [209.54.245.213]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9RH1fT23896; Fri, 27 Oct 2000 12:01:41 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Fri, 27 Oct 2000 12:05:00 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <000c01c03f64$8de553b0$[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA21554

Hi Anders,

Actually, I'm hopeful but not sure.

Had you asked me three or four years ago to predict when I could routinely exchange secure email with others or login to a commercial web server using a private key / certificate rather than a simple user name and password, I would have guessed a year, maybe 18 months at the outside.  That hasn't happened yet and we have to wait for that to be put into place before subsequent elements, like Timestamp servers and ACs, can come into play.

So, we appear to be in a similar position to the people who worked on x.509 v1 certificates back before SSL and S/MIME were proposed then standardized -- they may have felt that good things were likely to happen but they must have been taking quite a lot on faith early on.

Best Regards,

--dg



Anders Rundgren wrote:

> Dale,
> You seem convinced that ACs have a bright future. How about e-commerce and ACs?
> I have yet to see a single *practical* example of what the AC-promoters expect the application
> of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed
> orders, quotes or bills? Just to take the 99% of the e-commerce field.
>
> Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems?
>
> To me ACs "feels" like a wet dream (*) for the military and governmental sector but
> for the business sector....
>
> Anders Rundgren
> X-OBI
> co-founder
>
> *) Some dreams are only good as long as they are not materialized.
>
> -----Original Message-----
> From: Dale Gustafson <[e-mail]>
> To: Bob Jueneman <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Date: Wednesday, October 25, 2000 15:55
> Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
>
> >Hi Bob,
> >
> >A couple of comments:
> >
> >1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.
> >
> >2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
> >
> >3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.
> >
> >4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.
> >
> >5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.
> >
> >Best Regards,
> >
> >--dg
> >
> >
> >Bob Jueneman wrote:
> >
> >> Dale,
> >>
> >> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
> >>
> >> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
> >>
> >> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
> >>
> >> >Al, Polar,
> >> >
> >> >Let me also try to summarize.
> >> >
> >> >I think we've arrived at the current state because the group genuinely perceives
> >> >the need for Attribute Certificates.
> >>
> >> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
> >>
> >> >I think there is a common sense that there
> >> >is or will soon be a compelling need for secure applications to distribute and
> >> >utilize tamper-resistant, application specific data elements within the global
> >> >PKI.
> >>
> >> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
> >>
> >> >It is envisioned that authoritative entities will deploy Attribute
> >> >Authority systems that manage the life cycle of these special certificates.
> >>
> >> I could agree with that.
> >>
> >> >We
> >> >further speculate that each authoritative entity will work with it's various
> >> >constituents to define the form, fit, and function of a specific attribute
> >> >certificate that will be utilized by a well-defined set of applications.  This
> >> >application specific certificate's format and content will be updated from time
> >> >to time as the applications evolve, etc. under some management process
> >> >controlled by the authoritative entity.
> >>
> >> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
> >> >
> >> >Past experience has strongly suggested what NOT to do but has not necessarily
> >> >indicated the most appropriate course of action.
> >> >
> >> >Logically, and assuming the need is real, there are at least three possible
> >> >approaches:
> >> >
> >> >1. Embed the Attribute Certificate information in x.509 v3 Identification
> >> >Certificates
> >>
> >> This is of course my strong preference.
> >> >
> >> >Each industry or market group (banking, finance, insurance, communications,
> >> >government, et. al.) can create a set non-critical extensions that allow their
> >> >application-specific information to be carried in a common public key
> >> >certificate or certificates.
> >>
> >> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
> >> >
> >> >In the near term (at least) this is the most effective approach because each
> >> >design can take a free ride on all of the PKI infrastructure that is being put
> >> >in place at great expense.
> >>
> >> Exactly.
> >>
> >> >The downside is that the combined certificate
> >> >retains all of the properties of a public key certificate irrespective of
> >> >whether that makes sense for the attribute information and the secure
> >> >application(s) that will utilize it.
> >>
> >> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
> >> >
> >> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
> >> >
> >> >This has been suggested in the past but was not well received, likely because it
> >> >was obvious that significant additional overhead would be added to each
> >> >attribute certificate but it could not be shown that such a close coupling of
> >> >the attribute certificate and public key certificate would have technical merit
> >> >that justifies the cost.  Problems of keeping the ID certificate and attribute
> >> >together are eliminated but there are still two certificate chains.  The
> >> >infrastructure for and deployment of ID certificates can be utilized "as is".
> >>
> >> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
> >> >
> >> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
> >> >
> >> >This approach appeared at the outset to be the most elegant and, most
> >> >importantly, appeared to be the most flexible.  It has just now become more
> >> >apparent that creating a reliable, "dynamic" link between the two certificates
> >> >is difficult.  This has been discussed at length recently.
> >>
> >> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
> >> >
> >> >Perhaps others can recall other approaches that have been suggested.
> >>
> >> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
> >> >
> >> >My sense is that the real value of a separate attribute certificate is that it
> >> >invites others with specific application expertise to join the process "earlier"
> >> >without making everyone's work overly complex -- if (and only if) that's true,
> >> >will people be willing to pay some reasonable price to accomplish the necessary
> >> >up-front planning.
> >> >
> >> >What appears to be missing is a framework that enables secure application
> >> >builders to understand when they can "have at it" knowing they have a reasonably
> >> >stable environment around them.  That is, allows and encourages their innovative
> >> >work to move forward in  parallel with that of other industry and market
> >> >groups.  In order for that to happen, there needs to be a common understanding
> >> >that the basic problem is bounded and within range.
> >> >
> >> >A framework for attribute certificates might better define many of the things we
> >> >have recently discussed:
> >> >
> >> > - encode / decode methods supported (ASN.1, XML, other)
> >> > - commonly used data elements
> >> > - encryption methods (selected attributes, full certificate)
> >> > - delivery methods (SSL, S/MIME, directories, other)
> >> > - certificate path creation / signature validation
> >> > - certificate status checking
> >> > - summary:  distinction between ID certificates and attribute certificates
> >> > - other ?
> >> >
> >> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
> >> >expert would have to look long and hard at the overall requirements for
> >> >attribute certificates before deciding that a single approach would suffice.
> >> >
> >> >Comments?
> >> >
> >> >Best Regards,
> >> >
> >> >Dale Gustafson
> >>
> >> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
> >>
> >> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
> >>
> >> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
> >>
> >> Regards,
> >>
> >> Bob
> >>
> >> Robert R. Jueneman
> >> Security Architect
> >> Novell, Inc. -- the leading provider of Net services software.
> >



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28036 for <[e-mail]>; Fri, 27 Oct 2000 05:56:13 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <46BW0K34>; Fri, 27 Oct 2000 09:03:00 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 08:53:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04014.E68DF340"

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_01C04014.E68DF340
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dave, I want to clear up one point that you raised, from an X.509
perspective:

--stuff deleted--

> 
> The profile does not specify how to handle an AC where both entityName
> and baseCertificateID are present; it treats them as mutually 
> exclusive
> options.  What should happen if both are included in the AC and
> entityName matches and baseCertificateID does not, or vice versa?  I
> suggest that the AC profile formalize the mutual exclusion assumption
> and say:
> 
>    If the holder field uses the entityName option, the holder 
> field MUST
>    NOT include baseCertificateID or objectDigestInfo.
> 
> But my top priority is Steve's last recommendation - if either of the
> suggestions above are at all controversial, then forget about them.
> Let's move the AC profile forward.
> 
> Dave

------> 

X.509 is very clear on the situation where both entityName and
baseCertificateID are present. In clause 12.1, in the paragraph that begins
with "The entityName component, if present..., you'll find the following
text:

"If baseCertificateID and entityName are both present, only the certificate
specified by baseCertificateID may be used. In this case entityName is
included only as a tool to help the privilege verifier locate the identified
public-key certificate."

That is the reason that the syntax was made a SEQUENCE with all optional
elements. If you include only the baseCertificateID, what you have is the
"issuer" name and a serial number. This is probably not going to be terribly
helpful to a verifier that may need to try to locate that public-key
certificate for a holder in a repository. At present, at least, these
end-entity public-key certificates are typically stored in the subject's
directory entry. The issuer name isn't very helpful from a searching
standpoint. Therefore the ability to also provide an entityName (ie a name
that identifies the subject of referenced public-key certificate) for the
holder is there. There is NO requirement that the value of entityName also
be contained in the publicKeyCertificate pointed to by baseCertificateID
however. entityName is nothing more than helpful hints to the verifier to
try to locate the actual certificate that is REQUIRED to be used.

As X.509 editor, I believe that I inadvertently did not include the same
text for the combination of baseCertificateID with objectDigestInfo, the
combination of entityName with objectDigestInfo or the combination of all 3.
This is probably because we had followup discussions with the PKIX editors
following the X.509 meeting to finalize syntax and the primary issue was the
objectDigestInfo. Once we agreed the syntax, I suspect I forgot to add the
appropriate text. I have raised this with Hoyt Kesterson (who chaired the
X.509 meeting) and a few other folks who were present. Hoyt and I both agree
that the text should have been added and that the intent was identical to
that which is currently there for entityName baseCertificateID (i.e. that
the final present element is the ONLY one that is to be used and that any
other elements of the SEQUENCE that are also present are provided ONLY as
hints to enable verifiers to find the object. For objectDigestInfo then, if
it is present in the SEQUENCE, then that is the ONLY thing that can may be
used. entityName and baseCertificateID, if present are included only as
tools to help the privilege verifier locate the identified object. We have
not finished digging into our notes from that meeting to ensure that this is
in fact an editorial error, so I can't say for sure that this is how it will
be fixed. We also need to discuss it further with those who were present at
the meeting. However I did want to clarify that the entityName
baseCertificateID combination is valid and actually quite important from an
X.509 perspective. I believe the other combinations are as well. In some
operating environments, the object that was hashed (e.g. a public-key, a
public-key certificate, a software object), may be provided to the verifier
at the time the privilege is asserted. In those cases the additional hints
are not required. However in other operating environments, the object will
not be provided and the verifier will need to retrieve the object. If the
verifier has nothing other the hash it will have a very difficult time
locating the object.

Sharon

------_=_NextPart_001_01C04014.E68DF340
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dave, I want to clear up one point that you =
raised, from an X.509 perspective:</FONT>
</P>

<P><FONT SIZE=3D2>--stuff deleted--</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The profile does not specify how to handle an =
AC where both entityName</FONT>
<BR><FONT SIZE=3D2>&gt; and baseCertificateID are present; it treats =
them as mutually </FONT>
<BR><FONT SIZE=3D2>&gt; exclusive</FONT>
<BR><FONT SIZE=3D2>&gt; options.&nbsp; What should happen if both are =
included in the AC and</FONT>
<BR><FONT SIZE=3D2>&gt; entityName matches and baseCertificateID does =
not, or vice versa?&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; suggest that the AC profile formalize the =
mutual exclusion assumption</FONT>
<BR><FONT SIZE=3D2>&gt; and say:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; If the holder field uses the =
entityName option, the holder </FONT>
<BR><FONT SIZE=3D2>&gt; field MUST</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; NOT include baseCertificateID =
or objectDigestInfo.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But my top priority is Steve's last =
recommendation - if either of the</FONT>
<BR><FONT SIZE=3D2>&gt; suggestions above are at all controversial, =
then forget about them.</FONT>
<BR><FONT SIZE=3D2>&gt; Let's move the AC profile forward.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
</P>

<P><FONT SIZE=3D2>------&gt; </FONT>
</P>

<P><FONT SIZE=3D2>X.509 is very clear on the situation where both =
entityName and baseCertificateID are present. In clause 12.1, in the =
paragraph that begins with &quot;The entityName component, if =
present..., you'll find the following text:</FONT></P>

<P><FONT SIZE=3D2>&quot;If baseCertificateID and entityName are both =
present, only the certificate specified by baseCertificateID may be =
used. In this case entityName is included only as a tool to help the =
privilege verifier locate the identified public-key =
certificate.&quot;</FONT></P>

<P><FONT SIZE=3D2>That is the reason that the syntax was made a =
SEQUENCE with all optional elements. If you include only the =
baseCertificateID, what you have is the &quot;issuer&quot; name and a =
serial number. This is probably not going to be terribly helpful to a =
verifier that may need to try to locate that public-key certificate for =
a holder in a repository. At present, at least, these end-entity =
public-key certificates are typically stored in the subject's directory =
entry. The issuer name isn't very helpful from a searching standpoint. =
Therefore the ability to also provide an entityName (ie a name that =
identifies the subject of referenced public-key certificate) for the =
holder is there. There is NO requirement that the value of entityName =
also be contained in the publicKeyCertificate pointed to by =
baseCertificateID however. entityName is nothing more than helpful =
hints to the verifier to try to locate the actual certificate that is =
REQUIRED to be used.</FONT></P>

<P><FONT SIZE=3D2>As X.509 editor, I believe that I inadvertently did =
not include the same text for the combination of baseCertificateID with =
objectDigestInfo, the combination of entityName with objectDigestInfo =
or the combination of all 3. This is probably because we had followup =
discussions with the PKIX editors following the X.509 meeting to =
finalize syntax and the primary issue was the objectDigestInfo. Once we =
agreed the syntax, I suspect I forgot to add the appropriate text. I =
have raised this with Hoyt Kesterson (who chaired the X.509 meeting) =
and a few other folks who were present. Hoyt and I both agree that the =
text should have been added and that the intent was identical to that =
which is currently there for entityName baseCertificateID (i.e. that =
the final present element is the ONLY one that is to be used and that =
any other elements of the SEQUENCE that are also present are provided =
ONLY as hints to enable verifiers to find the object. For =
objectDigestInfo then, if it is present in the SEQUENCE, then that is =
the ONLY thing that can may be used. entityName and baseCertificateID, =
if present are included only as tools to help the privilege verifier =
locate the identified object. We have not finished digging into our =
notes from that meeting to ensure that this is in fact an editorial =
error, so I can't say for sure that this is how it will be fixed. We =
also need to discuss it further with those who were present at the =
meeting. However I did want to clarify that the entityName =
baseCertificateID combination is valid and actually quite important =
from an X.509 perspective. I believe the other combinations are as =
well. In some operating environments, the object that was hashed (e.g. =
a public-key, a public-key certificate, a software object), may be =
provided to the verifier at the time the privilege is asserted. In =
those cases the additional hints are not required. However in other =
operating environments, the object will not be provided and the =
verifier will need to retrieve the object. If the verifier has nothing =
other the hash it will have a very difficult time locating the =
object.</FONT></P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C04014.E68DF340--


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11616 for <[e-mail]>; Fri, 27 Oct 2000 01:58:07 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id TAA16313; Fri, 27 Oct 2000 19:10:30 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <V2TYALHS>; Fri, 27 Oct 2000 20:02:26 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Anders Rundgren <[e-mail]>, Michael Zolotarev <[e-mail]>, PKIX-List <[e-mail]>, Al Arsenault <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 20:02:15 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Anders,
> 
> To proceed to RFC-level should probably be a snap.  To get 
> this implemented
> by the manufacturers that control the world is unlikely as 
> Bob pointed out.
> 
> Do I have a problem with this? Nah, the problem is that there 
> will be a few people that will
> ask for ACs and won't get it and they will not understand why 
> they can't get it when
> it is an Internet "standard".

That wouldn't be a problem. If the standard is out, but renders itself
useless or obsolete or deficient, you can always justify supporting 'other'
standards to your clients.

It took us too long to get the draft to its current stage, and the industry
in the mean time has moved on significantly. So that the image and the avail
of AC is greatly distorted by the abudance of the other approaches and
initiatives. Yet, there is nothing currently defined by the IETF which can
fill the need for PKI-based authorisation. You are saying 'we don't need
PKI-based authorisation'? Probably. But not definitely. You are also saying
'there are other initiatives addressing and solving the same problem'? Well,
that is always true with almost every standard and solution. We don't have a
time machine, so we cannot go back and stop the standard on its track 2
years ago. I believe that IETF will have enough dignity to say, if it comes
to it, that AC is dead, long live the King. But today I suggest we let it
proceed to RFC, and we call for fair judgment when the mud settles down.

Just my personal opinion (as always :)

Michael


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03395 for <[e-mail]>; Fri, 27 Oct 2000 00:53:28 -0700 (PDT)
Received: from mega (t1o69p29.telia.com [62.20.144.29]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA23299; Fri, 27 Oct 2000 09:58:55 +0200 (CEST)
Message-ID: <007d01c03feb$92d745e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, "PKIX-List" <[e-mail]>, "Al Arsenault" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 09:57:35 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA03398

Michael,
 
>> I.e. the whole idea to cryptographically link a user PKC to 
>> an AC is IMO flawed. If this
>> is optional (?) ACs are just a restricted form of signed 
>> messages and therefore superfluous.  
>
>Yes, it is optional. You don;t have to reference PKC from AC. The draft
>allows defining the Holder using just GeneralNames. So that the attribute
>certificate efectively links the name to the set of roles/priviliges. Isn't
>it what you are asking for?


No, 
There are already a lot of other groups, forums, consortiums that work with defining 
signed data object for various uses. BizTalk to name one. Few if any have AFAIK based
their work on  ACs. And equally few newer schemes use ASN.1. They typically use XML. 

So ACs w.o. a cryprographically secure PKC link have plenty of competitors while 
ACs with such links have too few applications to be justifiable.

IMHO, regardless the application, it looks pretty bad for ACs. 

Note: 2-3 years ago when this was initiated things looked different but this happens 
all the time: Solutions become obsolete. Sometimes already on the drawing board! 

To proceed to RFC-level should probably be a snap.  To get this implemented
by the manufacturers that control the world is unlikely as Bob pointed out.

Do I have a problem with this? Nah, the problem is that there will be a few people that will
ask for ACs and won't get it and they will not understand why they can't get it when
it is an Internet "standard".

Anders




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25455 for <[e-mail]>; Fri, 27 Oct 2000 00:14:49 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA16106; Fri, 27 Oct 2000 17:27:16 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <V2TYALF0>; Fri, 27 Oct 2000 18:19:11 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Anders Rundgren <[e-mail]>, PKIX-List <[e-mail]>, Al Arsenault <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 18:19:05 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Anders,

>although I remain skeptical 
> about receipts linked 
> to a user's PKC instead of just being a digitally signed 
> document referring to the
> user's name and customer number. The link to a user PKC make 
> things a bit too 
> "fragile" IMHO. 
> 
<skip>
> 
> I.e. the whole idea to cryptographically link a user PKC to 
> an AC is IMO flawed. If this
> is optional (?) ACs are just a restricted form of signed 
> messages and therefore superfluous.  

Yes, it is optional. You don;t have to reference PKC from AC. The draft
allows defining the Holder using just GeneralNames. So that the attribute
certificate efectively links the name to the set of roles/priviliges. Isn't
it what you are asking for?

Michael


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20729 for <[e-mail]>; Thu, 26 Oct 2000 23:56:15 -0700 (PDT)
Received: from mega (t4o69p5.telia.com [62.20.145.125]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA10651; Fri, 27 Oct 2000 09:02:06 +0200 (CEST)
Message-ID: <006701c03fe3$a2a91550$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>, "Al Arsenault" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 09:00:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA20734

Al,

<snip>

>Anders, my company firmly believes that that ACs have a very bright
>future in e-commerce.  In fact, we believe it so much that we're
>spending a lot of money building a line of products that
>issue/manage/consume ACs.  (Okay, they're actually ACs augmented with
>some other stuff; we call the conglomeration "digital permits".) Here
>are a couple of quotes from the web site (which is www.dvnet.com, by the
>way; we're not www.diversinet.com :-)  :
>
>     "Digital Permits are digitally signed documents that are linked to
>the public-key certificates
>      of users.  Digital Permits could be used in a wide variety of
>applications, including
>      coupons in loyalty programs, lines of credit for auctions, access
>control for applications,
>      receipts for financial and stock trading, pay per view tickets via
>set-top-boxes, and 
>      assigning digital rights for subscription services."


These applications look possible although I remain skeptical about receipts linked 
to a user's PKC instead of just being a digitally signed document referring to the
user's name and customer number. The link to a user PKC make things a bit too 
"fragile" IMHO. 

Coupons: I don't understand how this works. What you would like to have is a 
digital non-forgeable coupon that does not require the coupon-consumer to identify the user 
Otherwise you only need some kind of trivial bookkeeping behind the scene. 

I.e. none of the above scenarios seem to justify the inclusion of a *user* PKC reference 
and then you are back to square one: You simply need (AA-)signed data objects and for 
that purpose we already have CMS, PKCS #7 and hopefully soon XML-sign. Or you use 
Bob's solution and include authority in the user PKC itself. 

I.e. the whole idea to cryptographically link a user PKC to an AC is IMO flawed. If this
is optional (?) ACs are just a restricted form of signed messages and therefore superfluous.  

>Let's fix up the wording and get this document published as an RFC, please.

That XML is not taken seriously in this context is pretty alarming as this is where the 
rest of this industry is going. 

<snip> 

Regards 
Anders Rundgren 
X-OBI 
co-founder




Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09840 for <[e-mail]>; Thu, 26 Oct 2000 18:24:37 -0700 (PDT)
Received: from [192.168.1.2] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Thu, 26 Oct 2000 18:26:13 -0700 (PDT)
Date: Thu, 26 Oct 2000 18:26:43 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Help! question about cert thumbprint
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Carol,

> 
> Hello, everyone !
> 
> When I double click a cert file , it'll display details of certificate.
> There are a thumbprint algorithm and a thmbprint value.
> I calculate in many ways, but no one lead to the same result .
> Who can tell me how to calculate thmbprint ?

The thumbprint (or fingerprint) of the certificate is the hash of the binary
certificate (DER encoding). The hash algorithm is either MD5 or SHA-1.

Hope this helps,
Aram Perez



Received: from sina.com ([202.106.187.168]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA08548 for <[e-mail]>; Thu, 26 Oct 2000 17:40:46 -0700 (PDT)
Received: (qmail 17597 invoked by uid 99); 27 Oct 2000 00:49:06 -0000
Message-ID: <[e-mail]>
From: pki_wby_cn <[e-mail]>
To: [e-mail]
Subject: Help! question about cert thumbprint
Date: Fri Oct 27 00:49:06 2000
Content-Type: multipart/mixed; boundary="----------97260774617571SINAEMAIL---"

------------97260774617571SINAEMAIL---
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Type: text/plain;charset="gb2312"

   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol


______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn
ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ 
http://sms.sina.com.cn/


------------97260774617571SINAEMAIL---
Content-Disposition: attachment;
Content-Transfer-Encoding: 7bits
Content-Type: message/rfc822;

Return-Path: pki_wby_cn<[e-mail]>
From: pki_wby_cn<[e-mail]>
To: [e-mail]
Subject: About Thumbprint
Date: Thu Oct 26 08:24:38 2000
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3


   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol


______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn
ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ 
http://sms.sina.com.cn/------------97260774617571SINAEMAIL-----


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04054 for <[e-mail]>; Thu, 26 Oct 2000 15:30:31 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA192942; Thu, 26 Oct 2000 18:35:52 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id SAA56048; Thu, 26 Oct 2000 18:35:22 -0400
Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin/Watson/IBM" <[e-mail]>
Date: Thu, 26 Oct 2000 18:35:44 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.4a |July 24, 2000) at 10/26/2000 06:36:21 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     I hope the following quibble will not be considered as so
controversial that it causes your rewording to be dropped.  It is legal for
an entityName to be attached to a single PKC if the PKC is not passed with
the message or protocol, so entityName need not be mutually exclusive with
objectDigestInfo.  I have a suggested rewording of your mutual exclusion
rule below.

          Tom Gindin


"David P. Kemp" <[e-mail]> on 10/26/2000 05:49:31 PM

Please respond to "David P. Kemp" <[e-mail]>

To:   [e-mail]
cc:
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt



I agree with Steve that the profile should accommodate both privileges
attached to names, and privileges attached to public keys.

In the case where privileges are attached to names, Holder can only be
entityName [1] alone.

In the case where privileges are attached to a public key, any of the
other 6 combinations ( [0], [2], [0]+[1], [0]+[2], [1]+[2], [0]+[1]+[2])
are possible for Holder.  I see nothing wrong with having the AC
profile make a recommendation changing:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field. However, section 7.3
   specifies how this optional feature MAY be used.

to:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field.  However, if the holder
   field uses the baseCertificateID option, the holder field SHOULD
   also include the objectDigestInfo option.  Implementations MAY also
   use objectDigestInfo without baseCertificateID or entityName as
   specified in section 7.3.

Following this recommendation causes no loss of generality in the
privileging model.  But there may be circumstances where calculating or
verifying the objectDigestInfo is problematic, so I don't think the
profile should raise the SHOULD to a MUST.

The profile does not specify how to handle an AC where both entityName and
baseCertificateID are present; it treats them as mutually exclusive
options.  What should happen if both are included in the AC and entityName
matches and baseCertificateID does not, or vice versa?  I suggest that the
AC profile formalize the mutual exclusion assumption and say:

   If the holder field uses the entityName option, the holder field MUST
   NOT include baseCertificateID or objectDigestInfo.

[Tom Gindin] If the holder field uses the entityName option, the holder
field MUST NOT include baseCertificateID.  If a holder field using the
entityName refers to a single known PKC, it MAY include objectDigestInfo,
but otherwise it MUST not include objectDigestInfo.

But my top priority is Steve's last recommendation - if either of the
suggestions above are at all controversial, then forget about them.
Let's move the AC profile forward.

Dave



> [Steve Hanna] If you can't run a PKI securely or don't believe in names,
you
can base
> your PMI on public keys instead (by using ObjectDigestInfo). But I see no
> reason why we should recommend this in general. So I don't support
> discouraging the use of baseCertificateID or entityName (although a
warning
> about their dependence on PKI integrity would be wise).
>
> [Tom Gindin] I don't think anyone is discouraging the use of
> baseCertificateID.  What I and some others are suggesting is to use
> ObjectDigestInfo with it to make it unbreakable.  It is perfectly true
that
> if you have a single trusted root you don't really need to do this.  As
far
> as entityName is concerned, the current draft seems to prefer
> baseCertificateID when either might be used.
>
> Likewise, if you don't want to use ACs for your PMI, you are perfectly
> welcome to include attributes in a PKC or store privilege information in
a
> directory (or in a database or whereever you like). But many customers
want
> to separate management of authorization and authentication. Let's enable
> this by moving the AttrCert profile forward.
>
> Steve Hanna




Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03002 for <[e-mail]>; Thu, 26 Oct 2000 14:50:46 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA16787 for <[e-mail]>; Thu, 26 Oct 2000 17:35:51 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 26 Oct 2000 17:49:31 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: aDvlpKIKmsOExzOOfAXMtw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

I agree with Steve that the profile should accommodate both privileges
attached to names, and privileges attached to public keys.

In the case where privileges are attached to names, Holder can only be
entityName [1] alone.

In the case where privileges are attached to a public key, any of the
other 6 combinations ( [0], [2], [0]+[1], [0]+[2], [1]+[2], [0]+[1]+[2])
are possible for Holder.  I see nothing wrong with having the AC
profile make a recommendation changing:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field. However, section 7.3
   specifies how this optional feature MAY be used.

to:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field.  However, if the holder
   field uses the baseCertificateID option, the holder field SHOULD 
   also include the objectDigestInfo option.  Implementations MAY also
   use objectDigestInfo without baseCertificateID or entityName as
   specified in section 7.3.

Following this recommendation causes no loss of generality in the
privileging model.  But there may be circumstances where calculating or
verifying the objectDigestInfo is problematic, so I don't think the
profile should raise the SHOULD to a MUST.

The profile does not specify how to handle an AC where both entityName
and baseCertificateID are present; it treats them as mutually exclusive
options.  What should happen if both are included in the AC and
entityName matches and baseCertificateID does not, or vice versa?  I
suggest that the AC profile formalize the mutual exclusion assumption
and say:

   If the holder field uses the entityName option, the holder field MUST
   NOT include baseCertificateID or objectDigestInfo.

But my top priority is Steve's last recommendation - if either of the
suggestions above are at all controversial, then forget about them.
Let's move the AC profile forward.

Dave



> [Steve Hanna] If you can't run a PKI securely or don't believe in names, you 
can base
> your PMI on public keys instead (by using ObjectDigestInfo). But I see no
> reason why we should recommend this in general. So I don't support
> discouraging the use of baseCertificateID or entityName (although a warning
> about their dependence on PKI integrity would be wise).
> 
> [Tom Gindin] I don't think anyone is discouraging the use of
> baseCertificateID.  What I and some others are suggesting is to use
> ObjectDigestInfo with it to make it unbreakable.  It is perfectly true that
> if you have a single trusted root you don't really need to do this.  As far
> as entityName is concerned, the current draft seems to prefer
> baseCertificateID when either might be used.
> 
> Likewise, if you don't want to use ACs for your PMI, you are perfectly
> welcome to include attributes in a PKC or store privilege information in a
> directory (or in a database or whereever you like). But many customers want
> to separate management of authorization and authentication. Let's enable
> this by moving the AttrCert profile forward.
> 
> Steve Hanna



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA01456 for <[e-mail]>; Thu, 26 Oct 2000 14:30:16 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 26 Oct 2000 15:35:24 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Thu, 26 Oct 2000 15:35:24 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Attribute certificates and extranets
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA01458

Dale,

Thanks for your courteous and thoughtful reply.  

I understand that people are getting tired of this issue and want to vote it up or down, but when someone is suggesting that a draft standard that a number of people have worked on is either premature or a less than optimal solution to some problem, as I and a few others have suggested, "a decent respect for the opinions of mankind" requires some justification for that position, I believe.

I certainly do agree with the need for a "tamper-resistant data object containing application or user group specific data," and I think there is a clear consensus on that point (although even that need is developing rather slowly).  The question on the table is how best way to implement this requirement, and whether the time is ripe.

The real issue, which I think is appropriate at a Final Call stage, is whether the complexity and cost of implementing the Attribute Certificate solution is justified by the benefits, or whether we should go back to the drawing board and look for alternative solutions to whatever problem we think we are solving.  Although I have no doubt that Attribute Certificates as presently defined could be made to work, the overall complexity and the amount of additional code that would be required in both certificate issuing software, and in particular the changes to existing relying party software, is completely out of proportion to the benefits that would be derived, IMO, and particularly when compared to the option of including those same kinds of attributes as an extension within an X.509 v3 certificate.

In a sense, an attribute certificate without a public key is similar to a directory attribute that is bound to a user's object, e.g., by reference or association with the user's directory name.  The attribute certificate at least contains the signature of the authority who issued it, but it isn't organized in directory form.  That is a good news/bad news situation.

The good news, I suppose, is that the user wouldn't have to have a PKI certificate or a private key at all  They could use whatever authentication mechanism the authorization function supports, and have their additional attributes or rights conveyed by the attribute certs.  This would be essentially the equivalent of a user logging on to a directory or some other authorization service, using user name and password or whatever, except for the fact that the user's attributes are not viewable or manageable (from the Relying Party's standpoint) at any kind of a centralized location. 

The bad news is that those "attributes" (rights) may end up being granted to someone based on a very weak identification and authentication function that is not necessarily tied to a public key, and that the only coupling between the user's identification and the rights being granted is a not necessarily distinguished name, i.e., not necessarily globally unambiguous, for all the reason Polar has described.  Worse yet, the organization that is granting those rights does not necessarily know the strength of the authentication mechanism that will be used to make use of them.

If the rights were only being granted to employees and associates within an single Enterprise, as they might be by referring to a locally trusted directory, then this problem wouldn't be too bad, because the local directory can almost surely be trusted to disambiguate names.  The major problem, however, comes when people want to do what is really hard, but presumably very valuable, and that is to control access to users on an extranet basis, i.e., to semi-strangers that are outside of the local Enterprise.  I may not know the individual in question, but I do know the organization he belongs to, and I will trust what they say about him, at least to a reasonable level.

The original model of attribute certificates, as I understand it, was that an authoritative agency would issue identity certificates as though they were the equivalent of passports or at least driver's licenses.  Then other "attribute authorities", whether the Provo Board of Realtors, or the California Medical Association, or Ford Motor Co. would issue attribute certificate that tied back to that well-established identity certificate in order to grant specific rights for use within their community of interest.

Although that is still a possible model, and especially within Europe with their Qualified Certificates initiative; based on the various discussions we have had with our customers, that model really doesn't seem to be going anywhere from a business perspective, especially within the US.

What I envision as happening instead is that commercial enterprises are increasingly going to issue their own certificate to their employees, either using  CA toolkits to create certificates themselves, or by using RA software to request that a certificate be issued by an outsourced CA function such as VeriSign or Digital Signature Trust.

Within those enterprises, the names CAN be unambiguous, either because they are qualified by OUs down to a level where no name collisions occur, or by the use of a unique identifier such as employee number to qualify the name.

Now, here comes the really important question.  How are people outside of that organization or enterprise going to be authorized to gain access to resources within that enterprise, and what mechanisms can be used to assure that the right person, and only that individual, is granted the appropriate rights?

One solution, whether you use a directory type of authorization server or a collection of attribute certificates, is to require Enterprise A to know the name of every individual within Enterprise B that will be likely to require access to Enterprise A's resources, and for Enterprise A to explicitly preauthorize each such user.  This is of course technically feasible, but it is highly unlikely that this will scale well from a management perspective. In most organizations Enterprise A has no way of knowing all of the employees of Enterprise B, much less know which of them are entitled to certain rights, or when those rights should be revoked because someone leaves Enterprise B.  So that approach doesn't work very well, whether the solution is a local directory or attribute certs issued by Enterprise A.

An approach that would seem to be workable would be to have Enterprise B grant certain rights or role to their employees, and then have Enterprise A recognize and honor those roles within their own organization.

>From a purely technical access control perspective, this type of role-based access control doesn't even require a name at all, just the role-based privilege.  In the case of a hospital, for example, it wouldn't matter what the doctor's name was, only the fact that he was a doctor.  But realistically, we know that this is almost never the case.  The requirement that events be audited normally means that the individual causing some action to be taken has to be identified by name, or at the very least identifiable by some unique identifier that can be traced back to a specific individual in case something goes wrong.  And in that case, I contend that the Attribute Authority probably knows that individual's name/identity at least as well, and perhaps better than, the PKI certificate issuer.  So there is no really good reason not to include the name. And if we did, and if the attribute cert also contained a public key, we'd be done.  We'd have an X.509 cert with a rights label in it, which is what I would like to see.

In addition to the issue of unique naming, there is the issue of whether a given Attribute Authority is considered acceptable by a given Relying Party, and in particular for what rights.  IMO, it is absolutely unacceptable for this process to be managed by controlling the root certificate of each Attribute Authority.   Not only does that make the already too-difficult issue of out of band trusted root management that much more onerous, but it tends to require a root per individual privilege. Now the number of "trusted" roots will really balloon.

If I am the Relying Party (access control mediator) within Enterprise A, I may choose to allow someone with role or rights X as granted by Enterprise B to access some resource, but NOT allow someone with role X in Enterprise C.  Vice versa, someone with role Y in Enterprise C may be allowed access to that same resource or some other, but not someone with that same role from Enterprise B.

For example, let's take something as simple as order processing.  If Enterprise B is a legitimate customer, I will allow Parts Department personnel within Enterprise B to order parts.  But if Enterprise C is my supplier for those same parts, I will NOT allow their Parts Department to cause orders to be placed though me back to their own company, for obvious reasons.  Likewise, I may allow the Account manager that handles my account within Enterprise C to look at my inventory status and run-rate information, in order to give them a heads up on demand  to facilitate just-in-time shipments. But I would not allow some Accounts Manager in my customer, Enterprise B, to access the same data.  If the data were to show that I had an excess of inventory, he might demand a lower price, and if it showed that I was very low on stock, he might order more out of fear, leading to boom and bust demand cycle.

So if I am allowing Enterprise B and C to issue rights to their employees, whether in the form of an attribute certificate or some other method, then I absolutely must have some highly granular way of controlling precisely which individuals within those enterprises are allowed to have such rights, and which are not.

In particular, since Enterprise A is not issuing the certificates to those individuals, I believe it is absolutely necessary to have a way of DENYING someone a particular right, and even more importantly the ability to deny a particular right to an entire class of users based on their Enterprise or particular Attribute Authority.  Just controlling the roots is NOT sufficient, because one Attribute Authority may be acceptable for some right and not others.

At a minimum, I believe that this requires an entire chain of Attribute Authorities, and the ability to either grant OR DENY particular rights to a given AA and any of their subordinate AAs or end users.

But as currently defined, since the rights being granted are not contained within the certificate that contains the public key, nor are they deposited in a centralized directory the relying party can manage, then all rights must be granted positively -- granting a root AA all rights and then denying those rights to lower level AAs is not an option.  And because Attribute Certs don't contain a public key, I can't create a chain of attribute certs in the normal PKI fashion. Instead, I would have to have both an attribute cert and a normal PKI cert for each Attribute Authority, as well as for the end-entity.

It therefore appears that the Relying Party must somehow apply or grant a set of rights to the EACH root AA, and then each AA must explicitly grant or withhold those rights from subordinate AAs and end-entities.

Unless I have missed something, this requires a total of THREE completely independent sets or chains of certificate: One for the end-entity's PKI certificate, one for each of the AA's public key certificate (since the AA can't be a CA, according to the spec), and a set (nor really a chain) of attribute certs tied back to the public key of each AA to manage the rights that are delegated to those AA's.

Now all three of those sets/chains are going to have to be managed, each certificate is going to have to be checked for validity, expiration, and most importantly revocation, using either CRLs or some kind of online check such as OCSP.

The total signature validation processing time has now increased by a factor of three, as has the bandwidth required to retrieve all of those certificate chains and CRLs/OCSP responses.  And nearly all of this processing is on the server side of the system, where the resources are the scarcest.  

And for the privilege of spending three times as much in the way of resources to do something that could easily be accommodate within a basic PKI certificate, we get to write a lot more software, modify a lot of existing applications, and introduce a LOT more incompatibilities and instability into an industry that is still struggling to implement some meaningful basic PKI capabilities.

Such a deal! :-)

Sorry, but I think the answer has to be NO.  There has to be a better way.  (There is, I believe, but modesty suggests ...)

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software


>Hi Bob,
>
>A couple of comments:
>
>1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute 
>Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form 
>described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted 
>draft document on the table.
>
>2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
>
>3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that 
>includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here 
>as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right 
>now.
>
>4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the 
>draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to 
>become fully developed.
>
>5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for 
>individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more 
>important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your 
>proposal and "how long it takes" for that to happen.  Good Luck.
>
>Best Regards,
>
>--dg


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24258 for <[e-mail]>; Thu, 26 Oct 2000 12:55:21 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA258564; Thu, 26 Oct 2000 16:00:42 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id QAA52732; Thu, 26 Oct 2000 16:00:29 -0400
Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin/Watson/IBM" <[e-mail]>
Date: Thu, 26 Oct 2000 16:00:51 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.4a |July 24, 2000) at 10/26/2000 04:01:11 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     Response below.  If an organization wishes its RP's to use one or a
few SOA's but a fair number of reputable CA's, ObjectDigestInfo with
baseCertificateID or entityName seems like a good precaution.

          Tom Gindin

P.S. - The opinions in this memo are mine, and not necessarily those of my
employer.

Steve Hanna <[e-mail]> on 10/26/2000 11:28:31 AM

To:   [e-mail]
cc:
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt



It seems to me that this discussion boils down to a rehash of some old,
oft-debated issues: whether to use names in certificates and how
authorization information and other attributes can be accessed securely.
Here's my summary:
(snip)
If you can't run a PKI securely or don't believe in names, you can base
your PMI on public keys instead (by using ObjectDigestInfo). But I see no
reason why we should recommend this in general. So I don't support
discouraging the use of baseCertificateID or entityName (although a warning
about their dependence on PKI integrity would be wise).

[Tom Gindin] I don't think anyone is discouraging the use of
baseCertificateID.  What I and some others are suggesting is to use
ObjectDigestInfo with it to make it unbreakable.  It is perfectly true that
if you have a single trusted root you don't really need to do this.  As far
as entityName is concerned, the current draft seems to prefer
baseCertificateID when either might be used.

Likewise, if you don't want to use ACs for your PMI, you are perfectly
welcome to include attributes in a PKC or store privilege information in a
directory (or in a database or whereever you like). But many customers want
to separate management of authorization and authentication. Let's enable
this by moving the AttrCert profile forward.

Steve Hanna





Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18103 for <[e-mail]>; Thu, 26 Oct 2000 11:35:40 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Thu, 26 Oct 2000 11:41:29 -0700
Message-ID: <[e-mail]>
Date: Thu, 26 Oct 2000 14:42:40 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Dale Gustafson <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <000c01c03f64$8de553b0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
> 
> Dale,
> You seem convinced that ACs have a bright future. How about e-commerce and ACs?
> I have yet to see a single *practical* example of what the AC-promoters expect the application
> of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed
> orders, quotes or bills? Just to take the 99% of the e-commerce field.
> 
> Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems?
> 
> To me ACs "feels" like a wet dream (*) for the military and governmental sector but
> for the business sector....
> 
> Anders Rundgren
> X-OBI
> co-founder
> 

First off, I'll apologize to one and all for what might be interpreted
as a plug for my company's products.  I'd like to follow the excellent
examples set by folks like Steve, Carlisle, Russ, Stephen, et alia and
keeping product stuff off this list in favor of technical discussion. 
However, the only way to respond to this message from Anders is to
mention something.

Anders, my company firmly believes that that ACs have a very bright
future in e-commerce.  In fact, we believe it so much that we're
spending a lot of money building a line of products that
issue/manage/consume ACs.  (Okay, they're actually ACs augmented with
some other stuff; we call the conglomeration "digital permits".) Here
are a couple of quotes from the web site (which is www.dvnet.com, by the
way; we're not www.diversinet.com :-)  :

     "Digital Permits are digitally signed documents that are linked to
the public-key certificates
      of users.  Digital Permits could be used in a wide variety of
applications, including
      coupons in loyalty programs, lines of credit for auctions, access
control for applications,
      receipts for financial and stock trading, pay per view tickets via
set-top-boxes, and 
      assigning digital rights for subscription services."

     "Permits are associated with X509- based or Diversinet public-key
certificates"

And, to the best of my knowledge, none of our current customers using
these products are military or even Government at any level. 

Now, will this be the "winning model" of e-commerce five years from
now?  Darned if I know.  This is our best guess at the best technology
right now. We're certainly not as big as Novell or even many of the
other PKI companies whose employees are active in PKIX, and we might
wind up missing the technology boat completely.  But we really don't
think so.

Thus, I think that Steve Hanna said it best (certainly better than I
did).  If you can run a PKI securely, then you almost certainly can add
a PMI without blowing up your security.  Further, there are enough
people who believe that there's a business case to refute arguments that
we shouldn't do this because there is no business case. 

Let's fix up the wording and get this document published as an RFC,
please.

                  Al Arsenault
                  Chief Security Architect
                  Diversinet Corp.

(PS: I removed a couple of the omg mail lists from the cc list.  If
those folks are still interested, feel free to forward this message to
'em, but we ought not bomb other mail lists with PKIX discussions unless
they're really, really interested - in which case we can show them how
to subscribe to PKIX.)


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06026 for <[e-mail]>; Thu, 26 Oct 2000 09:50:06 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <VBLVXW5T>; Thu, 26 Oct 2000 09:51:50 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: Steve Hanna <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 26 Oct 2000 09:51:47 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve,

I wholeheartedly agree with you!  Let's move the AttrCert profile forward.

Here are some comments I prepared on the same topic.  Steve, I apologize if 
they are redundant with your comments, in part; I was just completing them 
when I received your email.

- Carlin Covey
  Cylink Corp.

----------------------
COMMENTS ON THE NAME COLLISION PROBLEM

Assertions made by CA's and AA's

When a CA issues a PKC, the CA is asserting to the world that the subject of
the PKC (or the subject's agent) has presented sufficient proofs to convince
the CA to accept a certain amount of liability concerning misidentification
of the subject and the subject's public key.  Similarly, when an AA issues
an AC the AA is asserting to the world that the holder of the AC (or the
holder's agent) has presented sufficient proofs to convince the AA to accept
a certain amount of liability concerning misidentification of the holder and
whatever holder attributes are expressed in the AC. 


Authentication by AC Verifier

When a Relying party wishes to verify that the public key in a PKC is
associated with some particular EE, the RP authenticates the PKC via the
usual certificate path validation.  But the RP is free to choose the method
by which the RP becomes convinced that the "John Smith" who is the subject
of the PKC is the same "John Smith" with whom the RP wishes to communicate.
The situation is similar for AC's.  The AC verifier must validate the AC via
the usual certificate path validation, and now must become convinced (or
not) that a particular privilege requester is the same EE as the holder of
the AC. 

The requester may present to the AC verifier some cryptographic evidence
that is associated with a particular PKC, and the AC verifier may choose to
verify both that evidence and the PKC.  Assuming that these verify properly,
the AC verifier now knows that the presenter of the evidence has the
identity asserted in the PKC. 

The AC verifier still faces the "John Smith" problem.  That is, the AC
verifier must now become convinced that the "John Smith" known to the CA is
the same as the holder of the AC.  If the AC identifies the subject via a
particular PKC, the cryptographic evidence mentioned earlier is convincing.
However, if the AC uses some other identifier for the subject, then some
other mechanism is necessary to bridge the gap between the holder identifier
in the AC and the subject identifier in the PKC. 

Name Collision Problem

This brings us to the crux of the discussion concerning name collisions. 

Some persons have suggested that name collisions be eliminated via name
constraints or other techniques.  Other persons have expressed the opinion
that this is insufficient.  I believe that this is really up to the AC
verifier.  Different solutions, technical or not, may be acceptable to
different AC verifiers.  IMHO, the AC Draft should not mandate what is
acceptable to all AC verifiers, not should it be thrown out because it does
not mandate this. If the AA expects the AC verifier to authenticate the AC's
subject via a PKC that is linked to the AC via a DN, then the AA's practice
statement should either point out the possibility of name collisions, or
claim that significant effort has been made to avoid name collisions. 

The AC verifier has to make other fuzzy "is this MY John Smith?"
correlations, and this is just one more.  The AC verifier may choose, either
because the privilege being requested is minor, or based upon other
supporting evidence, that "John Smith" in the AC is the same person as "John
Q Smith" in some PKC (despite the admonition in the AC draft not to do so).
However, if the AC asserts some particularly critical attributes ("John
Smith is a board-certified brain surgeon"), then the AC verifier should
probably insist on some convincing evidence linking the privilege requestor
to the AC before turning over the scalpel to (the presumed) Dr. Smith.
Note that the convincing evidence need not be cryptographic.  The AC could
contain biometric identification information that might be presented as
evidence. 

AA's Evidence Recommendations

I believe that the AA should identify the holder authentication evidence
that the AA believes is convincing.  This may be the same information that
the AA used when issuing the AC, or it may be some other evidence that the
AA has reason to believe is convincing.  Here's an example of the former:
"I may not be certain of the name of the AC holder, but the person whose
fingerprint matches the digest in this AC passed the driver's license exam
because I graded the exam and I took the fingerprint."  An example of the
latter is the case when the CA and AA are affiliated:  "I haven't proofed
the subject of the PKC myself, but the HR person who issued the PKC vouches
for the person's identity and I, the HR AA, am now granting the subject of
that PKC the right to change the subject's home address and telephone number
in the company database via a request signed using that PKC." 

How should the AA identify the evidence that the AA thinks the AC verifier
should use?  If the AC identifies the holder only by baseCertificateID, this
implies that the AC verifier should use cryptographic evidence related to
the PKC named by the baseCertificateID.  Otherwise, the recommended evidence
should probably be identified in the AA's practice statement.  (The same
attribute authorizer could run multiple AAs, each with its own practice
statement.) If the same AA issues different types of AC's that require
different authentication evidence, then the required evidence should be
identified within the AC.  This identification could be a PKC digest, a DN,
a biometric, or some required or optional combination of these.  Note that
the AC draft permits more than one identifier for the AC Holder, but does
not indicate what evidence the AC verifier should use with the different
identifiers.  This is OK.  That information can go in the AA's practice
statement.  A later version of the AC standard can deal with more
complicated evidentiary scenarios.  

- Carlin Covey
  Cylink Corp.

> -----Original Message-----
> From: Steve Hanna [mailto:[e-mail]]
> Sent: Thursday, October 26, 2000 8:29 AM
> To: [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> 
> It seems to me that this discussion boils down to a rehash of 
> some old,
> oft-debated issues: whether to use names in certificates and how
> authorization information and other attributes can be 
> accessed securely.
> Here's my summary:
> 
> If your PMI is based on names (using ACs whose Holder is only a
> baseCertificateID and/or entityName, for instance), you must be very
> careful about how you map names to public keys. In 
> particular, you must
> ensure that you can't be tricked into mapping the name of an 
> authorized
> user to the public key of an unauthorized user.
> 
> But that's exactly the job of a PKI! If you can't run a PKI securely,
> why bother implementing a PMI? It *is* possible to run a secure PKI.
> Have a small number of trust anchors (one is best). Make sure 
> that they
> (and any cross-certified CAs) are managed carefully to ensure that
> duplicate names are not possible. If you want to include less trusted
> CAs and certificates in your PKI, use name constraints and certificate
> policies to ensure that they cannot be used to gain access to more
> secure applications.
> 
> If you can't run a PKI securely or don't believe in names, 
> you can base
> your PMI on public keys instead (by using ObjectDigestInfo). But I see
> no reason why we should recommend this in general. So I don't support
> discouraging the use of baseCertificateID or entityName (although a
> warning about their dependence on PKI integrity would be wise).
> 
> Likewise, if you don't want to use ACs for your PMI, you are perfectly
> welcome to include attributes in a PKC or store privilege 
> information in
> a directory (or in a database or whereever you like). But 
> many customers
> want to separate management of authorization and authentication. Let's
> enable this by moving the AttrCert profile forward.
> 
> Steve Hanna
> 


Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03002 for <[e-mail]>; Thu, 26 Oct 2000 09:01:58 -0700 (PDT)
Received: from erwin.isode.com by woozle.isode.com (local) with SMTP; Thu, 26 Oct 2000 17:07:13 +0100
Received: from erwin.isode.com (localhost [127.0.0.1])  by erwin.isode.com (Postfix) with SMTP id CE2F479006; Thu, 26 Oct 2000 17:07:05 +0100 (BST)
Sender: [e-mail]
From: Bruce Stephens <[e-mail]>
To: Steve Hanna <[e-mail]>
Cc: [e-mail]
Subject: Re: WAP X.509 Certificate profile specification
References: <[e-mail]> <[e-mail]>
Date: 26 Oct 2000 17:07:01 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 15
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Steve Hanna <[e-mail]> writes:

> Before I can download and read these documents, I apparently must agree
> to a license stating that I will not "do or permit others to do any act
> or omission in relation to a Document which is contrary to the
> objectives of the Licensor as stated in its Memorandum and Articles of
> Association." I cannot find the Memorandum and Articles of Association
> on your web site. Could you supply a copy (or a URL)?

The document is available from here
<http://www.wapforum.org/who/qualify.htm>, in MS Word format.

-- 
Bruce Stephens			[e-mail]
MessagingDirect(UK) Ltd		<URL:http://www.MessagingDirect.com/>



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01359 for <[e-mail]>; Thu, 26 Oct 2000 08:46:47 -0700 (PDT)
Received: from mega (t3o69p94.telia.com [62.20.145.94]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA19641; Thu, 26 Oct 2000 17:52:20 +0200 (CEST)
Message-ID: <000c01c03f64$8de553b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Dale Gustafson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 26 Oct 2000 17:51:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA01363

Dale, 
You seem convinced that ACs have a bright future. How about e-commerce and ACs? 
I have yet to see a single *practical* example of what the AC-promoters expect the application 
of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed 
orders, quotes or bills? Just to take the 99% of the e-commerce field. 

Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems? 

To me ACs "feels" like a wet dream (*) for the military and governmental sector but 
for the business sector.... 

Anders Rundgren
X-OBI
co-founder

*) Some dreams are only good as long as they are not materialized.


-----Original Message-----
From: Dale Gustafson <[e-mail]>
To: Bob Jueneman <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Wednesday, October 25, 2000 15:55
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt


>Hi Bob,
>
>A couple of comments:
>
>1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.
>
>2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
>
>3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.
>
>4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.
>
>5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.
>
>Best Regards,
>
>--dg
>
>
>Bob Jueneman wrote:
>
>> Dale,
>>
>> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
>>
>> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
>>
>> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
>>
>> >Al, Polar,
>> >
>> >Let me also try to summarize.
>> >
>> >I think we've arrived at the current state because the group genuinely perceives
>> >the need for Attribute Certificates.
>>
>> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
>>
>> >I think there is a common sense that there
>> >is or will soon be a compelling need for secure applications to distribute and
>> >utilize tamper-resistant, application specific data elements within the global
>> >PKI.
>>
>> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
>>
>> >It is envisioned that authoritative entities will deploy Attribute
>> >Authority systems that manage the life cycle of these special certificates.
>>
>> I could agree with that.
>>
>> >We
>> >further speculate that each authoritative entity will work with it's various
>> >constituents to define the form, fit, and function of a specific attribute
>> >certificate that will be utilized by a well-defined set of applications.  This
>> >application specific certificate's format and content will be updated from time
>> >to time as the applications evolve, etc. under some management process
>> >controlled by the authoritative entity.
>>
>> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
>> >
>> >Past experience has strongly suggested what NOT to do but has not necessarily
>> >indicated the most appropriate course of action.
>> >
>> >Logically, and assuming the need is real, there are at least three possible
>> >approaches:
>> >
>> >1. Embed the Attribute Certificate information in x.509 v3 Identification
>> >Certificates
>>
>> This is of course my strong preference.
>> >
>> >Each industry or market group (banking, finance, insurance, communications,
>> >government, et. al.) can create a set non-critical extensions that allow their
>> >application-specific information to be carried in a common public key
>> >certificate or certificates.
>>
>> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
>> >
>> >In the near term (at least) this is the most effective approach because each
>> >design can take a free ride on all of the PKI infrastructure that is being put
>> >in place at great expense.
>>
>> Exactly.
>>
>> >The downside is that the combined certificate
>> >retains all of the properties of a public key certificate irrespective of
>> >whether that makes sense for the attribute information and the secure
>> >application(s) that will utilize it.
>>
>> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
>> >
>> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
>> >
>> >This has been suggested in the past but was not well received, likely because it
>> >was obvious that significant additional overhead would be added to each
>> >attribute certificate but it could not be shown that such a close coupling of
>> >the attribute certificate and public key certificate would have technical merit
>> >that justifies the cost.  Problems of keeping the ID certificate and attribute
>> >together are eliminated but there are still two certificate chains.  The
>> >infrastructure for and deployment of ID certificates can be utilized "as is".
>>
>> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
>> >
>> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
>> >
>> >This approach appeared at the outset to be the most elegant and, most
>> >importantly, appeared to be the most flexible.  It has just now become more
>> >apparent that creating a reliable, "dynamic" link between the two certificates
>> >is difficult.  This has been discussed at length recently.
>>
>> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
>> >
>> >Perhaps others can recall other approaches that have been suggested.
>>
>> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
>> >
>> >My sense is that the real value of a separate attribute certificate is that it
>> >invites others with specific application expertise to join the process "earlier"
>> >without making everyone's work overly complex -- if (and only if) that's true,
>> >will people be willing to pay some reasonable price to accomplish the necessary
>> >up-front planning.
>> >
>> >What appears to be missing is a framework that enables secure application
>> >builders to understand when they can "have at it" knowing they have a reasonably
>> >stable environment around them.  That is, allows and encourages their innovative
>> >work to move forward in  parallel with that of other industry and market
>> >groups.  In order for that to happen, there needs to be a common understanding
>> >that the basic problem is bounded and within range.
>> >
>> >A framework for attribute certificates might better define many of the things we
>> >have recently discussed:
>> >
>> > - encode / decode methods supported (ASN.1, XML, other)
>> > - commonly used data elements
>> > - encryption methods (selected attributes, full certificate)
>> > - delivery methods (SSL, S/MIME, directories, other)
>> > - certificate path creation / signature validation
>> > - certificate status checking
>> > - summary:  distinction between ID certificates and attribute certificates
>> > - other ?
>> >
>> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
>> >expert would have to look long and hard at the overall requirements for
>> >attribute certificates before deciding that a single approach would suffice.
>> >
>> >Comments?
>> >
>> >Best Regards,
>> >
>> >Dale Gustafson
>>
>> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
>>
>> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
>>
>> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
>>
>> Regards,
>>
>> Bob
>>
>> Robert R. Jueneman
>> Security Architect
>> Novell, Inc. -- the leading provider of Net services software.
>



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00327 for <[e-mail]>; Thu, 26 Oct 2000 08:41:55 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10904 for <[e-mail]>; Thu, 26 Oct 2000 08:47:21 -0700 (PDT)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA10407 for <[e-mail]>; Thu, 26 Oct 2000 11:30:24 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA05513 for <[e-mail]>; Thu, 26 Oct 2000 11:30:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Oct 2000 11:28:31 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It seems to me that this discussion boils down to a rehash of some old,
oft-debated issues: whether to use names in certificates and how
authorization information and other attributes can be accessed securely.
Here's my summary:

If your PMI is based on names (using ACs whose Holder is only a
baseCertificateID and/or entityName, for instance), you must be very
careful about how you map names to public keys. In particular, you must
ensure that you can't be tricked into mapping the name of an authorized
user to the public key of an unauthorized user.

But that's exactly the job of a PKI! If you can't run a PKI securely,
why bother implementing a PMI? It *is* possible to run a secure PKI.
Have a small number of trust anchors (one is best). Make sure that they
(and any cross-certified CAs) are managed carefully to ensure that
duplicate names are not possible. If you want to include less trusted
CAs and certificates in your PKI, use name constraints and certificate
policies to ensure that they cannot be used to gain access to more
secure applications.

If you can't run a PKI securely or don't believe in names, you can base
your PMI on public keys instead (by using ObjectDigestInfo). But I see
no reason why we should recommend this in general. So I don't support
discouraging the use of baseCertificateID or entityName (although a
warning about their dependence on PKI integrity would be wise).

Likewise, if you don't want to use ACs for your PMI, you are perfectly
welcome to include attributes in a PKC or store privilege information in
a directory (or in a database or whereever you like). But many customers
want to separate management of authorization and authentication. Let's
enable this by moving the AttrCert profile forward.

Steve Hanna


Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA29575 for <[e-mail]>; Thu, 26 Oct 2000 08:39:13 -0700 (PDT)
Received: (qmail 97130 invoked from network); 26 Oct 2000 15:45:01 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 26 Oct 2000 15:45:01 -0000
Received: (qmail 18206 invoked from network); 26 Oct 2000 15:45:19 -0000
Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 26 Oct 2000 15:45:19 -0000
Date: Thu, 26 Oct 2000 17:43:09 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[e-mail]>
To: Steve Hanna <[e-mail]>
cc: [e-mail]
Subject: Re: WAP X.509 Certificate profile specification
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sorry Steve,

It is not "my" documents, it is the WAP forum's documents. I am working
for RSA, who is a member of the WAP forum (as Sun is), not for the WAP
forum, and furthermore, I am not a lawyer. I read through the license
agreement before posting my message, and found it somewhat reasonable. I
don't know where the Memorandum in question is.

-- Magnus
Magnus Nystrom
RSA Security

On Thu, 26 Oct 2000, Steve Hanna wrote:

> Before I can download and read these documents, I apparently must agree
> to a license stating that I will not "do or permit others to do any act
> or omission in relation to a Document which is contrary to the
> objectives of the Licensor as stated in its Memorandum and Articles of
> Association." I cannot find the Memorandum and Articles of Association
> on your web site. Could you supply a copy (or a URL)?
> 
> I hope this is not "denigrating the integrity of the Copyright"
> (prohibited in the license agreement), but I find it a bit much to
> require us to agree to a license in order to read or download your
> documents!
> 
> -Steve
> 
> Magnus Nystrom wrote:
> > 
> > Dear PKIX members,
> > 
> > On behalf of WAP's security group WSG, I would like to inform you that
> > a document named "WAPCert-20000309" can be found at
> > 
> > http://www.wapforum.org/what/technical.htm.
> > 
> > This document describes X.509 certificate profiles to be used for those
> > cases when X.509-compliant certificates will be sent over-the-air in WAP
> > protocols (or stored locally in WAP clients).
> > 
> > An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> > 
> > Comments and suggestions related to these documents are welcome and
> > solicited.



Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23032 for <[e-mail]>; Thu, 26 Oct 2000 07:49:35 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15385; Thu, 26 Oct 2000 07:55:07 -0700 (PDT)
Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA00152; Thu, 26 Oct 2000 10:55:05 -0400 (EDT)
Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA04093; Thu, 26 Oct 2000 10:55:04 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 26 Oct 2000 10:53:12 -0400
From: Steve Hanna <[e-mail]>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Nystrom <[e-mail]>
CC: [e-mail]
Subject: Re: WAP X.509 Certificate profile specification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Before I can download and read these documents, I apparently must agree
to a license stating that I will not "do or permit others to do any act
or omission in relation to a Document which is contrary to the
objectives of the Licensor as stated in its Memorandum and Articles of
Association." I cannot find the Memorandum and Articles of Association
on your web site. Could you supply a copy (or a URL)?

I hope this is not "denigrating the integrity of the Copyright"
(prohibited in the license agreement), but I find it a bit much to
require us to agree to a license in order to read or download your
documents!

-Steve

Magnus Nystrom wrote:
> 
> Dear PKIX members,
> 
> On behalf of WAP's security group WSG, I would like to inform you that
> a document named "WAPCert-20000309" can be found at
> 
> http://www.wapforum.org/what/technical.htm.
> 
> This document describes X.509 certificate profiles to be used for those
> cases when X.509-compliant certificates will be sent over-the-air in WAP
> protocols (or stored locally in WAP clients).
> 
> An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> 
> Comments and suggestions related to these documents are welcome and
> solicited.
> 
> Thanks,
> -- Magnus
> Magnus Nystrom
> RSA Security


Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20876 for <[e-mail]>; Thu, 26 Oct 2000 07:15:37 -0700 (PDT)
Received: (qmail 96208 invoked from network); 26 Oct 2000 14:21:23 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 26 Oct 2000 14:21:23 -0000
Received: (qmail 5814 invoked from network); 26 Oct 2000 14:21:42 -0000
Received: from mnystrom-lap.d.dynas.se (172.16.13.246) by spirit.dynas.se with SMTP; 26 Oct 2000 14:21:42 -0000
Date: Thu, 26 Oct 2000 16:19:51 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[e-mail]>
To: [e-mail]
Subject: WAP X.509 Certificate profile specification
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear PKIX members,

On behalf of WAP's security group WSG, I would like to inform you that
a document named "WAPCert-20000309" can be found at

http://www.wapforum.org/what/technical.htm.

This document describes X.509 certificate profiles to be used for those
cases when X.509-compliant certificates will be sent over-the-air in WAP
protocols (or stored locally in WAP clients).

An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.

Comments and suggestions related to these documents are welcome and
solicited.

Thanks,
-- Magnus
Magnus Nystrom
RSA Security



Received: from sina.com ([202.106.187.174]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA16703 for <[e-mail]>; Thu, 26 Oct 2000 01:31:46 -0700 (PDT)
Received: (qmail 1364 invoked by uid 99); 26 Oct 2000 08:24:38 -0000
Message-ID: <[e-mail]>
From: pki_wby_cn <[e-mail]>
To: [e-mail]
Subject: About Thumbprint
Date: Thu Oct 26 08:24:38 2000
X-Mailer: SinaMail 3.0Beta (FireToad)
X-Priority: 3

   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol


______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn
ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ 
http://sms.sina.com.cn/


Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16235 for <[e-mail]>; Wed, 25 Oct 2000 13:11:09 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <VBLVXTZZ>; Wed, 25 Oct 2000 13:12:50 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: Request for consensus call on AC draft
Date: Wed, 25 Oct 2000 13:12:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Mike,

Thanks for suggesting that the chairs "call the question."  My feeling is
that we should make only minor tweaks to the AC draft, and vote the draft up
or down as it stands in December.  That said, I reserve the right to propose
some minor tweaks, as below.

- Carlin Covey
  Cylink Corporation. 

-----------------------------------------------
Proposed tweak 1

[Quoting from the AC Draft]: "4.2.9 Extensions 
<snip> If any other critical extension is used, then the AC does not conform
to this profile. However, if any other non-critical extension is used, then
the AC does conform to this profile." 

[Carlin]: Perhaps this is nit-picking, but if an AC contains both an "any
other critical extension" and an "any other non-critical extension" then the
AC both conforms and does not conform to the profile (for any arbitrary
definition of "any other").  Perhaps the wording could be changed slightly
to 

[Suggested change]: "If any other critical extension is used, then the AC
does not conform to this profile. However, the use of any non-critical
extension does not make the AC nonconforming to this profile."  

------------------------------------------------
Proposed tweak 2

[Quoting from the AC Draft]: "4.3.2 AC Targeting 
To target an AC, the target information extension, imported from
[X.509-2000], MAY be used to specify a number of servers/services. The
intent is that the AC SHOULD only be usable at the specified
servers/services. An (honest) AC verifier who is not amongst the named
servers/services MUST reject the AC. "

[Carlin]: Why does this draft contain imperative language with respect to
the AC verifier?  The same server could choose to grant the same privileges
without any AC.  If a "non-targeted" server chooses to accept a AC targeted
for some other server, does that make the first server dishonest, or merely
foolish? It seems to me that such imperative language belongs in the AA's
practice statement, prefaced by words like "This AA will not be liable for
any damages resulting from a server relying on a targeted AC if such server
is not a target of that AC."  I suggest that the Draft be reworded to say 

[Suggested change]: "An AC verifier who is not amongst the named
servers/services SHOULD reject the AC."
 
-----------------------------------------------
Proposed tweak 3

[Quoting from the AC Draft]: "4.5 Profile of AC issuer's PKC 
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension
in the PKC MUST NOT explicitly indicate that the AC issuer's public key
cannot be used to validate a digital signature. In order to avoid confusion
regarding serial numbers and revocations, an AC issuer MUST NOT also be a
PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC
issuer's PKC MUST NOT have a basicConstraints extension with the CA BOOLEAN
set to TRUE. "

[Carlin]: So the AA's PKC cannot also be a CA's PKC.  But could the AA's
public key be the same as a CA's public key, or even a public key used to
sign simple email?  Nothing here seems to preclude this, so I suppose this
is permissible (but probably not desirable).  I suggest that the following
words be added to section 4.5 of the Draft:

[Suggested addition]: "It is considered to be poor practice for an AC
Issuer's keypair to be used in any context other than that of an AC Issuer."



 
-----------------------------------------------
Proposed tweak 4

[Quoting from the AC Draft]: "7.4 AA Controls
<snip>
When AAControls are used, the following additional checks on an AA's
   PKC chain MUST all succeed for the AC to be valid:

   1.   Some CA on the ACs certificate path MUST be directly trusted to
        issue PKCs which precede the AC issuer in the certification
        path, call this CA the "AA CA".
   2.   All PKCs on the path from the AA CA down to and including the
        AC issuer's PKC MUST contain an AAControls extension; however,
        the AA CA's PKC need not contain this extension.
   3.   Only those attributes in the AC which are allowed according to
        all of the AAControls extension values in all of the PKCs from
        the AA CA to the AC issuer, may be used for authorization
        decisions, all other attributes MUST be ignored. This check
        MUST be applied to the set of attributes following attribute
        decryption, and the id-aca-encAttrs type MUST also be checked.

[Carlin]: Due to cross certification or multiple trusted roots, there can be
more than one CA that meets the definition of "AA CA" in check #1.  In this
case, should checks #2 and #3 be interpreted to mean that there must exist
at least one certificate path that passes both these checks?

[Suggested change]: "When AAControls are used, the following additional
checks MUST all succeed on at least one AA PKC chain for the AC to be
valid:"

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


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Tuesday, October 24, 2000 9:09 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Request for consensus call on AC draft
> 
> 
> Chairs,
> 
> The multi-authority AC model is ultimately the more likely 
> while the single
> authority model has near term practical utility.
> 
> Stephen Farrell's text is responsive to this polarization.  I 
> propose a
> structured consensus call on that text.
> 
> It's otherwise predictable that this issue will come to the 
> floor in San
> Diego with a likelihood it'll go back to the list anyway.  I 
> for one would
> just as soon avoid that given all the bandwidth already spent 
> on this issue.
> 
> Mike
> 


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03995 for <[e-mail]>; Wed, 25 Oct 2000 06:45:45 -0700 (PDT)
Received: from bpsi.net (port443.bpsi.net [209.54.245.243]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9PDomD23367; Wed, 25 Oct 2000 08:50:49 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Oct 2000 08:48:23 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA03997

Hi Bob,

A couple of comments:

1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.

2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.

3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.

4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.

5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.

Best Regards,

--dg


Bob Jueneman wrote:

> Dale,
>
> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
>
> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
>
> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
>
> >Al, Polar,
> >
> >Let me also try to summarize.
> >
> >I think we've arrived at the current state because the group genuinely perceives
> >the need for Attribute Certificates.
>
> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
>
> >I think there is a common sense that there
> >is or will soon be a compelling need for secure applications to distribute and
> >utilize tamper-resistant, application specific data elements within the global
> >PKI.
>
> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
>
> >It is envisioned that authoritative entities will deploy Attribute
> >Authority systems that manage the life cycle of these special certificates.
>
> I could agree with that.
>
> >We
> >further speculate that each authoritative entity will work with it's various
> >constituents to define the form, fit, and function of a specific attribute
> >certificate that will be utilized by a well-defined set of applications.  This
> >application specific certificate's format and content will be updated from time
> >to time as the applications evolve, etc. under some management process
> >controlled by the authoritative entity.
>
> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
> >
> >Past experience has strongly suggested what NOT to do but has not necessarily
> >indicated the most appropriate course of action.
> >
> >Logically, and assuming the need is real, there are at least three possible
> >approaches:
> >
> >1. Embed the Attribute Certificate information in x.509 v3 Identification
> >Certificates
>
> This is of course my strong preference.
> >
> >Each industry or market group (banking, finance, insurance, communications,
> >government, et. al.) can create a set non-critical extensions that allow their
> >application-specific information to be carried in a common public key
> >certificate or certificates.
>
> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
> >
> >In the near term (at least) this is the most effective approach because each
> >design can take a free ride on all of the PKI infrastructure that is being put
> >in place at great expense.
>
> Exactly.
>
> >The downside is that the combined certificate
> >retains all of the properties of a public key certificate irrespective of
> >whether that makes sense for the attribute information and the secure
> >application(s) that will utilize it.
>
> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
> >
> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
> >
> >This has been suggested in the past but was not well received, likely because it
> >was obvious that significant additional overhead would be added to each
> >attribute certificate but it could not be shown that such a close coupling of
> >the attribute certificate and public key certificate would have technical merit
> >that justifies the cost.  Problems of keeping the ID certificate and attribute
> >together are eliminated but there are still two certificate chains.  The
> >infrastructure for and deployment of ID certificates can be utilized "as is".
>
> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
> >
> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
> >
> >This approach appeared at the outset to be the most elegant and, most
> >importantly, appeared to be the most flexible.  It has just now become more
> >apparent that creating a reliable, "dynamic" link between the two certificates
> >is difficult.  This has been discussed at length recently.
>
> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
> >
> >Perhaps others can recall other approaches that have been suggested.
>
> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
> >
> >My sense is that the real value of a separate attribute certificate is that it
> >invites others with specific application expertise to join the process "earlier"
> >without making everyone's work overly complex -- if (and only if) that's true,
> >will people be willing to pay some reasonable price to accomplish the necessary
> >up-front planning.
> >
> >What appears to be missing is a framework that enables secure application
> >builders to understand when they can "have at it" knowing they have a reasonably
> >stable environment around them.  That is, allows and encourages their innovative
> >work to move forward in  parallel with that of other industry and market
> >groups.  In order for that to happen, there needs to be a common understanding
> >that the basic problem is bounded and within range.
> >
> >A framework for attribute certificates might better define many of the things we
> >have recently discussed:
> >
> > - encode / decode methods supported (ASN.1, XML, other)
> > - commonly used data elements
> > - encryption methods (selected attributes, full certificate)
> > - delivery methods (SSL, S/MIME, directories, other)
> > - certificate path creation / signature validation
> > - certificate status checking
> > - summary:  distinction between ID certificates and attribute certificates
> > - other ?
> >
> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
> >expert would have to look long and hard at the overall requirements for
> >attribute certificates before deciding that a single approach would suffice.
> >
> >Comments?
> >
> >Best Regards,
> >
> >Dale Gustafson
>
> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
>
> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
>
> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
>
> Regards,
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc. -- the leading provider of Net services software.



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28729 for <[e-mail]>; Wed, 25 Oct 2000 03:10:26 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23247; Wed, 25 Oct 2000 06:16:08 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-11.txt
Date: Wed, 25 Oct 2000 06:16:07 -0400
Sender: [e-mail]

--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 Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-11.txt
	Pages		: 24
	Date		: 24-Oct-00
	
A time stamping service supports assertions of proof that a datum 
existed before a particular time. This document describes the format 
of a request sent to a Time Stamping Authority (TSA) and of the 
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing 
requests to generate responses. A TSA may be operated as a Trusted 
Third Party (TTP) service, though other operational models may be 
appropriate, e.g. an organization might require a TSA for internal 
time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-11.txt

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-time-stamp-11.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-time-stamp-11.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-time-stamp-11.txt

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

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

--OtherAccess--

--NextPart--




Received: from disappearing.com (IDENT:root@[63.77.39.203]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16965 for <[e-mail]>; Tue, 24 Oct 2000 15:59:57 -0700 (PDT)
Received: from dnai.com (michael.disappearing.com [63.77.39.227]) by disappearing.com (8.9.3/8.9.3) with ESMTP id QAA12073; Tue, 24 Oct 2000 16:05:26 -0700
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 24 Oct 2000 16:05:26 -0700
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: FW: I-D ACTION:draft-legg-ldapext-component-matching-00.txt
References: <000e01c03e0c$8a05cee0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven Legg wrote:


The source of many evils, including URL wrap:
	X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0

> Behalf Of [e-mail]
> Sent: Tuesday, 24 October 2000 21:10

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00
> .txt

http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00.txt


Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16490 for <[e-mail]>; Tue, 24 Oct 2000 15:42:37 -0700 (PDT)
Received: (qmail 24195 invoked from network); 24 Oct 2000 22:49:33 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 24 Oct 2000 22:49:33 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: FW: I-D ACTION:draft-legg-ldapext-component-matching-00.txt
Date: Wed, 25 Oct 2000 09:48:32 +1100
Message-ID: <000e01c03e0c$8a05cee0$[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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Tuesday, 24 October 2000 21:10
To: IETF-Announce: ;
Cc: [e-mail]
Subject: I-D ACTION:draft-legg-ldapext-component-matching-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: LDAP & X.500 Component Matching Rules
	Author(s)	: S. Legg
	Filename	: draft-legg-ldapext-component-matching-00.txt
	Pages		: 44
	Date		: 23-Oct-00

The syntaxes of attributes in an LDAP or X.500 directory range from
simple data types, such as text string, integer, or boolean, to
complex structured data types, such as the syntaxes of the directory
schema operational attributes.  The matching rules defined for the
complex syntaxes, if any, usually only provide the most immediately
useful matching capability.  This document defines generic matching
rules that can match any user selected component parts in an
attribute value of any arbitrarily complex attribute syntax.  Generic
string encodings for attribute and assertion values of arbitrary
syntax are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00
.txt

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-legg-ldapext-component-matching-00.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-legg-ldapext-component-matching-00.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.



Received: from jlc.net (3ff83a80.dsl.flashcom.net [63.248.58.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12344 for <[e-mail]>; Tue, 24 Oct 2000 12:26:14 -0700 (PDT)
Received: (from pkoning@localhost) by jlc.net (8.9.3/8.8.7) id PAA00942; Tue, 24 Oct 2000 15:31:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 24 Oct 2000 15:31:51 -0400 (EDT)
From: Paul Koning <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid

>>>>> "Tom" == Tom Gindin/Watson/IBM <[e-mail]> writes:

 Tom> By the way, a typical US driver's license is also a Permanent
 Tom> Identifier with an assignment authority of C=US, ST=xx,
 Tom> O=Division of Motor Vehicles (or DMV).  The opaqueness and
 Tom> meaningless to outsiders of a driver's license number (at least
 Tom> in those states which don't use SSN's) are typical features of
 Tom> PI's.

Clearly SSNs are neither opaque nor meaningless, but there are also
non-SSN examples where the same is true.

New Hampshire uses a simple and well-known algorithm to derive license
numbers; if you know a person's name and birthdate, you get the number
directly.  For example, assuming your birthdate is April 1, 1952,
you'd get 04TGN52011 (or, with low probability, 04TGN52012).

	paul


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11840 for <[e-mail]>; Tue, 24 Oct 2000 12:14:39 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <VHSN6MD2>; Tue, 24 Oct 2000 15:19:47 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'todd glassey'" <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: The Time Stamp Protocol (v10)...
Date: Tue, 24 Oct 2000 15:19:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DEF.5F0205A0"

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_01C03DEF.5F0205A0
Content-Type: text/plain

Hi Todd,

> ----------
> From: 	todd glassey[SMTP:[e-mail]]
> Sent: 	Tuesday, October 24, 2000 12:34 PM
> To: 	Denis Pinkas; IETF-PXIX
> Subject: 	Re: TSP. Version 10
> 
> What I suggest is rather than advancing this effort to a Draft Standard,
> that some thought of what the protocol is supposed to accomplish in the
> real
> world and under what constraints it must be operated to accomplish these
> things be added to the draft as well as the processes it already
> memorializes.
 
The plan is NOT to advance this effort to "Draft Standard", but rather to
"Proposed Standard" (i.e., the first step in the standardization process,
not the second -- although this has taken so long it's surprising we're not
at the third step by now!).

As far as I can tell from occasional glimpses at the never-ending threads on
time stamping, you are the only one asking for the above additions to the
draft.  Not only does no one else seem interested in these "use models",
constraints, etc., but such things appear in no other PKIX documents either.
Is it, perhaps, a fair observation that "rough consensus" is not on your
side with respect to this topic?  In fact, it seems to me that "rough
consensus" is rather on the other side, and so is "running code", which
suggests to me that we're done (i.e., this document can be submitted to IESG
as-is).

> With that said I am off to rewrite the opening paragraphs of the draft - I
> will post them shortly!
 
The first couple of sentences of your posting go as follows:  "I figure this
will start several small brush fires and that is not my intent. So I
apologize to the group at the outset ...".  Regardless of the merits of your
proposed text, I think it's safe to say that the absolute *last* thing this
document needs at this point is new opening paragraphs that "start several
small brush fires".

Let's submit the -10.txt version to IESG.  There will be lots of time to
revise the opening paragraphs (if the group really feels this is necessary!)
in the future when we try to progress from Proposed to Draft.  Furthermore,
it has been suggested in the past that you write a separate Internet Draft
describing the "use models", constraints, etc., that you feel are an
important addition to this specification.  I whole-heartedly support this:
let this separate document be debated and advanced (according to rough
consensus) on its own, and let the protocol specification progress now.

Carlisle.


------_=_NextPart_001_01C03DEF.5F0205A0
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.2651.67">
<TITLE>The Time Stamp Protocol (v10)...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Todd,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">todd =
glassey[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, October 24, 2000 12:34 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis Pinkas; =
IETF-PXIX</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: TSP. Version 10</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What I suggest is rather than =
advancing this effort to a Draft Standard,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that some thought of what the =
protocol is supposed to accomplish in the real</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">world and under what constraints it =
must be operated to accomplish these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">things be added to the draft as well =
as the processes it already</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">memorializes.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The plan =
is NOT to advance this effort to &quot;Draft Standard&quot;, but rather =
to &quot;Proposed Standard&quot; (i.e., the first step in the =
standardization process, not the second -- although this has taken so =
long it's surprising we're not at the third step by now!).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As far as =
I can tell from occasional glimpses at the never-ending threads on time =
stamping, you are the only one asking for the above additions to the =
draft.&nbsp; Not only does no one else seem interested in these =
&quot;use models&quot;, constraints, etc., but such things appear in no =
other PKIX documents either.&nbsp; Is it, perhaps, a fair observation =
that &quot;rough consensus&quot; is not on your side with respect to =
this topic?&nbsp; In fact, it seems to me that &quot;rough =
consensus&quot; is rather on the other side, and so is &quot;running =
code&quot;, which suggests to me that we're done (i.e., this document =
can be submitted to IESG as-is).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">With that said I am off to rewrite the =
opening paragraphs of the draft - I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will post them shortly!</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The first =
couple of sentences of your posting go as follows:&nbsp; =
&quot;</FONT><FONT SIZE=3D2 FACE=3D"Arial">I figure this will start =
several small brush fires and that is not my intent. So I apologize to =
the group at the outset ...</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Times New Roman">&quot;.&nbsp; Regardless of the merits of your =
proposed text, I think it's safe to say that the absolute *last* thing =
this document needs at this point is new opening paragraphs that =
&quot;start several small brush fires&quot;.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Let's =
submit the -10.txt version to IESG.&nbsp; There will be lots of time to =
revise the opening paragraphs (if the group really feels this is =
necessary!) in the future when we try to progress from Proposed to =
Draft.&nbsp; Furthermore, it has been suggested in the past that you =
write a separate Internet Draft describing the &quot;use models&quot;, =
constraints, etc., that you feel are an important addition to this =
specification.&nbsp; I whole-heartedly support this:&nbsp; let this =
separate document be debated and advanced (according to rough =
consensus) on its own, and let the protocol specification progress =
now.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03DEF.5F0205A0--


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10412 for <[e-mail]>; Tue, 24 Oct 2000 11:11:36 -0700 (PDT)
Received: from tsg1 ([12.72.112.141]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001024171037.EISA4021.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 24 Oct 2000 17:10:37 +0000
Message-ID: <000501c03ddf$9ef4f970$[e-mail]>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Denis Pinkas" <[e-mail]>
Subject: The rewritten opening statement and some thoughts on the goals!
Date: Tue, 24 Oct 2000 10:26:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all - and Denis,
I figure this will start several small brush fires and that is not my
intent. So I apologize to the group at the outset - but let me share a
bizarre concept with you - 'We humans are the problem, not the answer with
Digital Evidence Models' and by using Time Stamping digital trust operators
are supposed to address this.

Digital Evidence models are made weaker by having to have humans testify as
to their validity. Its a simple concept.  You see machines don't have any
consciousness, so they cant "lie" per se, but we as humans can, and do - all
the time. So any proofing model that does not include methods of abstracting
its reliability away form "Human Reliance" is broken (IMHO) and that is
really that.  What I think that this means is that the Time Stamps that are
produced by such a system have no way of separating themselves form the
system they were created on or the people that ran that system, and this is
the key flaw to the big picture.

And as long as I am talking about qualifying the parametric data the TSP
uses, we need to have a new document, a timing practices statement added to
the trust model.  This defines the proofing models for where the time data
came from, and needs to be a part of the evidentiary trail and since the
draft ignores the concept of  a Timing Practices Statement.


So I suggest something like the following to clean up the opening
statements:
-------------------------
Digital evidentiary models require that digital events have some a method of
stipulating the time in which a digital event took place. These models also
require the ability to be run in computers unattended as part of a larger
audit process and proofing system. Because of these emerging requirements,
this Draft proposes a distributed method of associating time and event data.
This document then describes this complete protocol  to provide this
Distributed
or TTP based Time Stamping.

The facility of the TSP provides a proofing process to demonstrate that a
digital
event  occurred or existed as per the policies of the Authority running the
Time
Stamping (TS) System.  Thus it can be used to satisfy both policy based
decisions
as well as stand for producing a basic level of evidentiary content. The TS
Draft
defines the infrastructure or format of a request  sent to a  Time Stamping
Authority
(TSA) and of the response that is returned. It also establishes several
security-relevant
requirements  for TSA operation, with regards to processing requests to
generate
responses.

The protocol defined herein is envisioned to be typically operated as a
Trusted Third
Party (TTP,  but its protocol (or API) may be implemented as an embedded
system
to address  single platform use of a time stamping.

< and then the ISO NR words!>

Non-repudiation services [ISONR] require the ability to establish the
existence of data before specified times. This protocol may be used as
a building block to support such services. An example of how to prove
that a digital signature was generated during the validity period of
a public key certificate is given in an annex.





Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09776 for <[e-mail]>; Tue, 24 Oct 2000 10:54:40 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA49926; Tue, 24 Oct 2000 13:59:51 -0400
Received: from d02ml237.somers.hqregion.ibm.com (d02ml237.sby.ibm.com [9.45.4.171]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id NAA70430; Tue, 24 Oct 2000 13:59:09 -0400
Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: "David P. Kemp" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
From: "Tom Gindin/Watson/IBM" <[e-mail]>
Date: Tue, 24 Oct 2000 13:54:29 -0400
X-MIMETrack: Serialize by Router on D02ML237/02/M/IBM(Release 5.0.4a |July 24, 2000) at 10/24/2000 02:00:20 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

     By the way, a typical US driver's license is also a  Permanent
Identifier with an assignment authority of C=US, ST=xx, O=Division of Motor
Vehicles (or DMV).  The opaqueness and meaningless to outsiders of a
driver's license number (at least in those states which don't use SSN's)
are typical features of PI's.

          Tom Gindin

"David P. Kemp" <[e-mail]> on 10/23/2000 07:38:37 PM

Please respond to "David P. Kemp" <[e-mail]>

To:   [e-mail]
cc:
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt




> From: Polar Humenn <[e-mail]>
>
> If we take this model. You don't just check the attribute certificate
> (i.e. the drivers license). You check some identifying information on
that
> license that ties the certificate to the person giving it to you. A
> picture, some bio information, (age, height, weight, eye color) (however,
> incorrect, I might add :) that correlates the "certificate" to the
entity.
> Those are *identifying* attributes, not authorization attributes. In the
> PKI space, the *identifying* attribute is the public key.
>
> A drivers license has only has one authorization attribute. The privilege
> to drive a car.
>
> And that certificate is really issued to an entity that matches the
> *identifying* attributes. On that certificate, the entity may be given a
> name, an address, and possibly a number, for easy look up. That look up
is
> only relevant in the DMV's own directory, not in the post office's
> directory, or at the hospital.


It's always dangerous to use analogies, but in this example, the driver's
license is an identity certificate.  The bio information (picture, height
weight, hair color, hair presence :-) is, as you say, the "public key".
The date of birth is a certified attribute which can legitimately be
used, contrary to Aram's claim, for purposes other than the privilege
to drive a car.  The common name and the number are part of the DN, which
in full, might be: "c=US, st=CA, o=DMV, sn=S-678-109-876-432, cn=John
Smith".
One does not have to be very imaginative to suppose that VeriCertCo and
DigSigZone and PkiBoys could all issue certificates for each of the 50
states, or for each of the state agencies, or for each person licensed
to drive in the US, and that a compelling case for fraud or malfeasance
could be made if there were a single collision in names following the
"USDriverPerson" (analogous to InetOrgPerson :-) schema.


> The amusement park "would like to" include sufficient identifying
> information (such as a name and a driver license number), but, it cannot,
> because by the standard, it is limited to the DN given, "CN=John Smith,
> O=Smith". If attribute certificate adds anything else to the DN, then the
> correlation fails where it should succeed.
>
> If there is insufficient information to begin with (i.e. capability for
two
> John Smith's one with a driver's license, and a Bob Smith's 13 year old
> named John) then the correlation can succeed where it should fail.
>
> Isn't this called a hole?

As above, no.

The driver's license number doesn't have to be meaningful outside the
DMV's database, it only has to be a unique identifier which the DMV
will not issue to some other person.  I use the same authentication
credential to request a music download attribute cert (paid for with
e-cash or a regular credit card) and to perform the downloads; the
identifying information is irrelevant as long as its unique.  If
I get a new ID cert with a new public key from the DMV, I can still
use all my old attribute certs.  And if the relying parties ignore
the CN when matching ACs to PKCs, I can even change my name.

Dave






Received: from cs.ida.org (cs.ida.org [129.246.101.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09125 for <[e-mail]>; Tue, 24 Oct 2000 10:38:17 -0700 (PDT)
Received: from ida.org (vpnserver.ida.org [129.246.101.254]) by cs.ida.org (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA27253; Tue, 24 Oct 2000 13:43:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 24 Oct 2000 13:43:22 -0400
From: "Edward A. Feustel" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000929 Netscape6/6.0b3
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <v04220820b61a5d8e1f99@[171.78.30.107]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html><head></head><body>
<blockquote type="cite" cite="mid:v04220820b61a5d8e1f99@%5B171.78.30.107%5D">I do not believe that the
 proposed document: "X.509 Certificate Policy for the Federal Bridge Certification
 Authority (FBCA) Version 1.06, October 23, 2000" which can be obtained through NIST PKI Office has been mentioned. </blockquote>
Under section 3.1.4, Uniqueness of Names:<br>
" Name uniqueness across the FPKI (Federal Public Key Infrastructure) must
 be enforced. The FBCA, Agency CAs and RAs shall enforce name uniqueness
 within the X.500 name space which they have been authorized. When other
 name forms are used, they too must be allocated such that name uniqueness
 across the FPKI is ensured.<br>
<br>
The FBCA and Agency CAs shall document in their respective CPSs (Certificate Practice Statements) :<br>
<ul>
  <li>What name forms shall be used,</li>
  <li>How the FBCA,&nbsp; Agency CAs and RAs will interact with the FPKIPA to ensure this is accomplished, and</li>
  <li>How they will allocate names within the Subscriber community to guarantee
 name uniqueness among current and past Subscribers (e.g., if ' Joe Smith'
 leaves a CA's Community of Subscribers, and a new, different 'Joe Smith'
 enters the community of Subscribers, how will these two people be provided
 unique names)."</li>
</ul>
<br>
Under 3.1.5 Name claim dispute resolution procedure<br>
<br>
" The FPKIPA shall resolve any name collisions brought to its attention that may affect interoperability using the FBCA."<br>
<br>
Assuming this policy is signed off, if a community wants to do business with the Feds,<br>
they will need to keep their PKI aligned with the Feds in terms of using unique names.<br>
<br>
Ed Feustel<br>
<blockquote type="cite" cite="mid:v04220820b61a5d8e1f99@%5B171.78.30.107%5D"><br>
</blockquote>
</body>
</html>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA08755 for <[e-mail]>; Tue, 24 Oct 2000 10:32:48 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 24 Oct 2000 11:36:19 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Tue, 24 Oct 2000 11:08:23 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_EFB72E83.53325C07"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_EFB72E83.53325C07
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Someone complained that the page I cited locked up his browser, for =
unknown reasons.

If that happens, try http://developer.novell.com/repository/attributes/pkis=
v10.pdf

Regards,

Bob

--=_EFB72E83.53325C07
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 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 8pt MS Sans Serif; MARGIN-LEFT: =
2px">
<DIV>Someone complained that the page&nbsp;I cited locked up his browser, =
for=20
unknown reasons.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If that happens, try <A=20
href=3D"http://developer.novell.com/repository/attributes/pkisv10.pdf">http=
://developer.novell.com/repository/attributes/pkisv10.pdf</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV></BODY></HTML>

--=_EFB72E83.53325C07--


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07484 for <[e-mail]>; Tue, 24 Oct 2000 09:56:49 -0700 (PDT)
Received: from tsg1 ([12.72.112.141]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001024161759.DUPU4021.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 24 Oct 2000 16:17:59 +0000
Message-ID: <008a01c03dd8$4423efd0$[e-mail]>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "IETF-PXIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: TSP. Version 10
Date: Tue, 24 Oct 2000 09:34:08 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Denis - I want to rewrite the opening paragraphs and will have my versions
of them out to you and to the list in an hour or so..

Please understand I am not against this as a TSP, it is a very well thought
out scenario but I as you are well aware have some fundamental questions
about

    a)    how it is to be used to satisfy any digital evidence models and
which ones it ascribes to.
    b)    how it is totally leveraged against something it does not address
in the slightest, that being the Timing Practices Statement of the Time
provider, and how this is propagated into the marques that the TSA produces.

What I suggest is rather than advancing this effort to a Draft Standard,
that some thought of what the protocol is supposed to accomplish in the real
world and under what constraints it must be operated to accomplish these
things be added to the draft as well as the processes it already
memorializes.

With that said I am off to rewrite the opening paragraphs of the draft - I
will post them shortly!

Todd


----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "IETF-PXIX" <[e-mail]>
Sent: Friday, October 13, 2000 4:02 AM
Subject: TSP. Version 10


>
> A new version of the Time Stamping Protocol has been placed on the web
> server. A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt
>
> This version addresses the comments received during the IESG last call
> period.
>
> Besides the changes made to accommodate the 24 comments raised by Russ
> Housley, the abstract and the introduction have been modified, by myself
and
> Steve Kent, in order to address some of the concerns raised by Todd
Glassey.
>
> If there are no major editorial errors, this version should (hopefully) be
> the version to be published as an RFC. Should there be a few minor errors
> left, please tell me, since they can still be corrected directly by myself
> when the RFC editor transforms the document into an RFC (there a 48 hours
> time window to do so).
>
> FYI, the abstract and the introduction are now as follows:
>
> Abstract
>
> A time stamping service allows to prove that a datum existed before
> a particular time. This document describes the format of a request
> sent to a Time Stamping Authority (TSA) and of the response that is
> returned. It also establishes several security-relevant requirements
> for TSA operation, with regards to processing requests to generate
> responses. A TSA may be operated as a Trusted Third Party (TTP)
> service, though other operational models may be appropriate, e.g. an
> organization might require a TSA for internal time stamping purposes.
>
> Non-repudiation services [ISONR] require the ability to establish the
> existence of data before specified times. This protocol may be used as
> a building block to support such services. An example of how to prove
> that a digital signature was generated during the validity period of
> a public key certificate is given in an annex.
>
> (...)
>
> 1.  Introduction
>
> (...)
>
> This standard does not establish overall security requirements for
> TSA operation, just like other PKIX standards do not establish such
> requirements for CA operation. Rather, it is anticipated that a TSA
> will make know to prospective clients the policies it implements to
> ensure accurate time stamp generation, and clients will make use of
> the services of a TSA only if they are satisfied that these policies
> meet their needs.
>
>
> Denis
>



Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06015 for <[e-mail]>; Tue, 24 Oct 2000 09:05:03 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA22096; Tue, 24 Oct 2000 09:05:55 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <VJHZWDGR>; Tue, 24 Oct 2000 09:09:29 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Request for consensus call on AC draft
Date: Tue, 24 Oct 2000 09:09:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Chairs,

The multi-authority AC model is ultimately the more likely while the single
authority model has near term practical utility.

Stephen Farrell's text is responsive to this polarization.  I propose a
structured consensus call on that text.

It's otherwise predictable that this issue will come to the floor in San
Diego with a likelihood it'll go back to the list anyway.  I for one would
just as soon avoid that given all the bandwidth already spent on this issue.

Mike


Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA07486 for <[e-mail]>; Mon, 23 Oct 2000 21:17:14 -0700 (PDT)
Received: (qmail 21778 invoked from network); 24 Oct 2000 04:23:45 -0000
Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 24 Oct 2000 04:23:45 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: comments on draft-ietf-pkix-ldap-schema-01.txt
Date: Tue, 24 Oct 2000 15:22:52 +1100
Message-ID: <000b01c03d72$143d9480$[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 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <39F1BF79.24531.F9869C@localhost>

David & Tim,

> -----Original Message-----
> From: David Chadwick [mailto:[e-mail]]
> Sent: Sunday, 22 October 2000 2:08
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
> 
> 
> From:           	[e-mail]
> To:             	[e-mail]
> Subject:        	comments on draft-ietf-pkix-ldap-schema-01.txt
> Date sent:      	Thu, 21 Sep 2000 14:18:15 -0400
 
[snip]

> > 
> > Section 3.2:
> > ------------
> > In the BNF for "GeneralName", a single whitespace character appears
> > (e.g. "rfc822 +").  Was this intentional?  It seems out of
> 
> I dont really mind either way here. I will let Steven be the 
> authoritative voice on this

I'll strip out the spaces in the next revision.

> 
> > place/misleading.
> > 
> > Editor's note on AuthorityKeyIdentifier:
> > ----------------------------------------
> > Seems to me that authority issuer name and authority certificate
> > serial number could be useful.
> 
> What we really need is some LDAP server vendor (IBM??) to 
> implement these matching rules and to give some feedback about 
> which fields are really useful for users to use. At the moment we 
> can only guess at what people will want to use in practice.
> 
> 
> > 
> > Section 4.1:
> > ------------
> > In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> > is OPTIONAL, correct?  It should only be needed if
> > "DistributionPointName" is specified, I think.
> 
> Yes we could change the ABNF to put the  $ inside the DP 
> construct.

I'll make the "$" conditional on DistributionPointName being present.

Regards,
Steven


Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00457 for <[e-mail]>; Mon, 23 Oct 2000 17:41:38 -0700 (PDT)
Received: from [192.168.1.2] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Mon, 23 Oct 2000 17:37:40 -0700 (PDT)
Date: Mon, 23 Oct 2000 05:39:47 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

David Kemp wrote:

[snip]
> It's always dangerous to use analogies, but in this example, the driver's
> license is an identity certificate.  The bio information (picture, height
> weight, hair color, hair presence :-) is, as you say, the "public key".
> The date of birth is a certified attribute which can legitimately be
> used, contrary to Aram's claim, for purposes other than the privilege
> to drive a car. 

I never claimed that is could not be "legitimately" used, and I did state
that it is accepted business practice (in the "real world). But a liquor
store or cinema only asks me for my license if I don't meet certain
criteria, i.e., if I look too young. But I've reached that level of maturity
where I do not ever get asked to present my license :-(  In the PKIX world,
I *must* present my certificate every time, whether "I look too young" or
not. And if any of the attributes change (my weight), then my certificate is
no longer valid. Should a liquor store or a cinema ask to see my license,
they do not care whether my apparent weight matches what my driver license
states, only whether my picture is a "close enough resemblance", and if it
is, then I am old enough (based on the date of birth). You can't ignore
attributes that are no longer valid or have a "close enough resemblance" in
the PKIX world.

Regards,
Aram Perez

[snip]



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA28743 for <[e-mail]>; Mon, 23 Oct 2000 16:51:53 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 23 Oct 2000 17:56:51 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 23 Oct 2000 17:56:47 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA28744

Dale,  

You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.

Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)

But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.

>Al, Polar,
>
>Let me also try to summarize.
>
>I think we've arrived at the current state because the group genuinely perceives
>the need for Attribute Certificates.  

As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.

>I think there is a common sense that there
>is or will soon be a compelling need for secure applications to distribute and
>utilize tamper-resistant, application specific data elements within the global
>PKI.  

On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.

>It is envisioned that authoritative entities will deploy Attribute
>Authority systems that manage the life cycle of these special certificates.  

I could agree with that.

>We
>further speculate that each authoritative entity will work with it's various
>constituents to define the form, fit, and function of a specific attribute
>certificate that will be utilized by a well-defined set of applications.  This
>application specific certificate's format and content will be updated from time
>to time as the applications evolve, etc. under some management process
>controlled by the authoritative entity.

If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
>
>Past experience has strongly suggested what NOT to do but has not necessarily
>indicated the most appropriate course of action.
>
>Logically, and assuming the need is real, there are at least three possible
>approaches:
>
>1. Embed the Attribute Certificate information in x.509 v3 Identification
>Certificates

This is of course my strong preference.
>
>Each industry or market group (banking, finance, insurance, communications,
>government, et. al.) can create a set non-critical extensions that allow their
>application-specific information to be carried in a common public key
>certificate or certificates.

Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
>
>In the near term (at least) this is the most effective approach because each
>design can take a free ride on all of the PKI infrastructure that is being put
>in place at great expense.  

Exactly.

>The downside is that the combined certificate
>retains all of the properties of a public key certificate irrespective of
>whether that makes sense for the attribute information and the secure
>application(s) that will utilize it.

Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
>
>2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
>
>This has been suggested in the past but was not well received, likely because it
>was obvious that significant additional overhead would be added to each
>attribute certificate but it could not be shown that such a close coupling of
>the attribute certificate and public key certificate would have technical merit
>that justifies the cost.  Problems of keeping the ID certificate and attribute
>together are eliminated but there are still two certificate chains.  The
>infrastructure for and deployment of ID certificates can be utilized "as is".

This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
>
>3. Provide a Link from the Attribute Certificate to the Public Key Certificate
>
>This approach appeared at the outset to be the most elegant and, most
>importantly, appeared to be the most flexible.  It has just now become more
>apparent that creating a reliable, "dynamic" link between the two certificates
>is difficult.  This has been discussed at length recently.

If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
>
>Perhaps others can recall other approaches that have been suggested.

The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.  
>
>My sense is that the real value of a separate attribute certificate is that it
>invites others with specific application expertise to join the process "earlier"
>without making everyone's work overly complex -- if (and only if) that's true,
>will people be willing to pay some reasonable price to accomplish the necessary
>up-front planning.
>
>What appears to be missing is a framework that enables secure application
>builders to understand when they can "have at it" knowing they have a reasonably
>stable environment around them.  That is, allows and encourages their innovative
>work to move forward in  parallel with that of other industry and market
>groups.  In order for that to happen, there needs to be a common understanding
>that the basic problem is bounded and within range.
>
>A framework for attribute certificates might better define many of the things we
>have recently discussed:
>
> - encode / decode methods supported (ASN.1, XML, other)
> - commonly used data elements
> - encryption methods (selected attributes, full certificate)
> - delivery methods (SSL, S/MIME, directories, other)
> - certificate path creation / signature validation
> - certificate status checking
> - summary:  distinction between ID certificates and attribute certificates
> - other ?
>
>Perhaps this has already been done elsewhere.  I suspect even an all-knowing
>expert would have to look long and hard at the overall requirements for
>attribute certificates before deciding that a single approach would suffice.
>
>Comments?
>
>Best Regards,
>
>Dale Gustafson

You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.

But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.

For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28330 for <[e-mail]>; Mon, 23 Oct 2000 16:40:01 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id TAA04772 for <[e-mail]>; Mon, 23 Oct 2000 19:25:12 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 23 Oct 2000 19:38:37 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4g82OrOAn8m/97vhvTUpUA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Polar Humenn <[e-mail]>
> 
> If we take this model. You don't just check the attribute certificate
> (i.e. the drivers license). You check some identifying information on that
> license that ties the certificate to the person giving it to you. A
> picture, some bio information, (age, height, weight, eye color) (however,
> incorrect, I might add :) that correlates the "certificate" to the entity.  
> Those are *identifying* attributes, not authorization attributes. In the
> PKI space, the *identifying* attribute is the public key.
> 
> A drivers license has only has one authorization attribute. The privilege
> to drive a car. 
> 
> And that certificate is really issued to an entity that matches the
> *identifying* attributes. On that certificate, the entity may be given a
> name, an address, and possibly a number, for easy look up. That look up is
> only relevant in the DMV's own directory, not in the post office's
> directory, or at the hospital.


It's always dangerous to use analogies, but in this example, the driver's
license is an identity certificate.  The bio information (picture, height
weight, hair color, hair presence :-) is, as you say, the "public key".
The date of birth is a certified attribute which can legitimately be
used, contrary to Aram's claim, for purposes other than the privilege
to drive a car.  The common name and the number are part of the DN, which
in full, might be: "c=US, st=CA, o=DMV, sn=S-678-109-876-432, cn=John Smith".
One does not have to be very imaginative to suppose that VeriCertCo and
DigSigZone and PkiBoys could all issue certificates for each of the 50
states, or for each of the state agencies, or for each person licensed
to drive in the US, and that a compelling case for fraud or malfeasance
could be made if there were a single collision in names following the
"USDriverPerson" (analogous to InetOrgPerson :-) schema.


> The amusement park "would like to" include sufficient identifying
> information (such as a name and a driver license number), but, it cannot,
> because by the standard, it is limited to the DN given, "CN=John Smith,
> O=Smith". If attribute certificate adds anything else to the DN, then the
> correlation fails where it should succeed.
> 
> If there is insufficient information to begin with (i.e. capability for two
> John Smith's one with a driver's license, and a Bob Smith's 13 year old
> named John) then the correlation can succeed where it should fail.
> 
> Isn't this called a hole?

As above, no.

The driver's license number doesn't have to be meaningful outside the
DMV's database, it only has to be a unique identifier which the DMV
will not issue to some other person.  I use the same authentication
credential to request a music download attribute cert (paid for with
e-cash or a regular credit card) and to perform the downloads; the
identifying information is irrelevant as long as its unique.  If
I get a new ID cert with a new public key from the DMV, I can still
use all my old attribute certs.  And if the relying parties ignore
the CN when matching ACs to PKCs, I can even change my name.

Dave



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26932 for <[e-mail]>; Mon, 23 Oct 2000 15:45:14 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id IAA22272; Tue, 24 Oct 2000 08:57:22 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <V2TYA2NC>; Tue, 24 Oct 2000 09:49:01 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Peter Sylvester <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Tue, 24 Oct 2000 09:48:57 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I second the proposal.

> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Tuesday, 24 October 2000 3:10
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: TSP. Version 10, Removal of SIA Extension
> 
> 
> 
> 
> A TS certificate contains the an access information was a feature in
> the text, having this removed may not easily allow to get it back
> in a next round. 
> 
> I would consider to include the complete definition of SIA in the
> TS text since it is not or not yet defined anywhere else, and
> maybe mention that it is expected that it will be removed later. 
> 
> In this way the feature is described and stable, and when
> as soon as part1 gets updated and the TS text gets moved from
> proposed to draft, one can remove it without having added
> or removed any functionality. 
>  
> > Michael,
> > 
> > > Sounds like its time to get SIA back to TSS draft, Denis :)
> > 
> > "son-of-RFC2459" has not yet passed WG last call, nor IESG 
> last call.
> > Waiting for it would create a delay that could be estimated 
> to be, at best,
> > about two months and thus would mean issuing the TSP RFC 
> next year. :-(
> > 
> > We now need this long-awaited RFC. 
> > 
> > Denis
> > 
> > Note: I have just posted to the web editor an update 
> (version 11) that
> > incorporates the changes that have been noticed (plus one, 
> un-noticed in the
> > ASN1 module !)
> 


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25586 for <[e-mail]>; Mon, 23 Oct 2000 14:48:33 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA12293; Mon, 23 Oct 2000 17:49:40 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 23 Oct 2000 17:49:40 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "David P. Kemp" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 23 Oct 2000, David P. Kemp wrote:

> Polar,
> 
> You keep paying lip service to the idea that "standards are not a
> substitute for system engineering", and then turn around and say that a
> technical interoperability profile MUST require certain behavior, and
> that PKIX must somehow mandate that whatever infrastructure is out
> there today must be made "secure".
> 
> That just isn't the way things work.
> 
> A driver's license is a paper certificate which binds some information
> (name, address, date of birth, photo) using some security info (special
> lamination, holograms, etc).  It is issued according to well known
> business practices which give relying parties some measure of the difficulty
> of obtaining one which contains incorrect information.
> 
> Relying parties (check cashers, liquor stores, cinemas) use the
> driver's license to make access control decisions based on their own
> judgement of the strength of the authentication mechanism and the risk
> of loss.  They DO NOT have a contractual relationship with the issuer
> of the driver's license, nor do they rely upon standards stating what a
> license must contain.  They rely on what's in front of them and on the
> generally accepted business principle that the 50 states can be trusted
> to issue ID cards usable for the purpose of keeping a check written out
> to one person from being cashed by someone else.

If we take this model. You don't just check the attribute certificate
(i.e. the drivers license). You check some identifying information on that
license that ties the certificate to the person giving it to you. A
picture, some bio information, (age, height, weight, eye color) (however,
incorrect, I might add :) that correlates the "certificate" to the entity.  
Those are *identifying* attributes, not authorization attributes. In the
PKI space, the *identifying* attribute is the public key.

A drivers license has only has one authorization attribute. The privilege
to drive a car. 

And that certificate is really issued to an entity that matches the
*identifying* attributes. On that certificate, the entity may be given a
name, an address, and possibly a number, for easy look up. That look up is
only relevant in the DMV's own directory, not in the post office's
directory, or at the hospital.


> An attribute authority (someone issuing a season pass to an amusement
> park) will include sufficient identifying information (such as a name
> and driver's license number) to ensure that John Smith's (senior) pass
> cannot be used by John junior, or by some other John Smith.  This is all
> done without any contractual relationship between the state DMV and the
> amusement park.

The amusement park "would like to" include sufficient identifying
information (such as a name and a driver license number), but, it cannot,
because by the standard, it is limited to the DN given, "CN=John Smith,
O=Smith". If attribute certificate adds anything else to the DN, then the
correlation fails where it should succeed.

If there is insufficient information to begin with (i.e. capability for two
John Smith's one with a driver's license, and a Bob Smith's 13 year old
named John) then the correlation can succeed where it should fail.

Isn't this called a hole?

If I issue an amusement park pass to a guy with a drivers license, I
really have to either extract the same identifying attributes, picture,
height, weight, eye color, (in PKI, the public key), or I have to name him
by including his indexing attributes, such as his name, address, and
possible number, BUT I also have to say where that index is relevant, i.e.
the DMV of California, if not further classified by the State Authority of
California, certified by the State Registry of the United States of
America, certified by the Nation Registry of the League of Nations,
certified by Verisign. :)

Cheers,
-Polar

> As PKI and PMI are used to automate real-world business processes,
> system engineering is required.  I don't consider the following, which
> you seem to be proposing, to be a reasonable approach:
> 
> 1) Look at all the SSL certificates that are already out there,
> 2) Impose technical constraints on attribute certificates, in an attempt to
> 3) Solve a general unspecified access control problem.
> 
> Don Flinn and others have well expressed the need for both due
> diligence and system engineering when applying PKI and PMI.  I agree
> with them, and I am unconvinced that your approach of applying
> technical constraints to solve a procedural problem will meet with any
> success whatsoever.  I am therefore opposed to specifying in an AC
> profile the precise (or even the imprecise) conditions under which a
> compliant AC issuer MUST link an AC to a particular PKC.


> Dave
> 
> 
> 
> 
> > From: Polar Humenn <[e-mail]>
> > 
> > Denis,
> > 
> > I am in agreement with you on your approach of including the objectDigest
> > Info along with entityName or baseCertificateID. I think in environments
> > where the Relying Parties, Attribute Certificate Issuers, and Subject
> > Entities do not know and trust a priori the certificate management
> > environment they all are emphatically working in, then the entityName
> > and/or baseCertificateID must only be used in conjunction with the
> > objectDigestInfo.
> > 
> > A good thing would be to figure out under the precise conditions in which
> > a compliant Attribute Certificate Issuer MUST include objectDigestInfo.
> > 
> > I can think of one of the conditions right off.
> > 
> > In applications where there is no absolute assurance by all three classes
> > of possible parties, i.e. subjects, attribute certificate issuers, and
> > relying parties, are privy to each others business practices about the
> > use of DN's.
> > 
> > I am not yet sure how you can write such requirements without getting
> > agreements from all three parties.
> > 
> > -Polar
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com





Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24984 for <[e-mail]>; Mon, 23 Oct 2000 14:27:48 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA00128; Mon, 23 Oct 2000 17:33:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220820b61a5d8e1f99@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 23 Oct 2000 17:32:23 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>Steve,
>
>We have discussed this before, but unfortunately, name subordination 
>does NOT solve all of the problems, in part because of the legal 
>entanglements caused by treating wholly own subsidiary corporations, 
>Doing Business As firms, franchises, etc., as though they were 
>organization units of a larger parent organization.
>
>I got a very stern, lecture on that subject from the lawyers when I 
>was with GTE.  GTE Laboratories, Inc. is NOT an OU of GTE Corp., no 
>way no how, according to them.  And neither is GTE of Pennsylvania, 
>GTE of California, etc.

I appreciate your adherence to the advice of the lawyers for MY 
company, but we're working on an access control problem, not an NR 
problem, and I would not ask any lawyer for help in addressing 
technical issues in an access control framework.  After all, their 
assistance has been so great in the NR arena, ...

>The concern that was expressed was that to identify such 
>organizations, which are wholly owned but separate corporations, as 
>organizational units might subject the holding company to liability 
>that was incurred by the subordinate organization, which (in 
>general) is precisely the reason why separate corporations were 
>created in the first place -- to shelter the overall corporate 
>structure from lower level liabilities.

Like I said, I would not ask for their help. If we move this 
discussion to the DNS arena, we have plenty of experience, lots of 
history, and recent legal wrangling. In the case of your example, we 
have various DNS names for different parts of Verizon Communications, 
and setting up CAs aligned with the management of those DNS subtrees 
is not a bad idea.

>Granted, this approach doesn't always work -- witness the Dow 
>Corning vs. Dow Chemical breast implant suits.  But the corporate 
>attorneys I have talked to are virtually unanimous in agreeing with 
>this position, at least as long as the conventional name of the 
>attribute is "organizationalUnit".
>
>If this is the position with respect to holding companies, I have to 
>believe that it would also be the position of any CAs with competent 
>attorneys -- they are not going to allow the name of the CA to used 
>to used for such purposes either, even if the sequence of RDNs is 
>O=My CA, O=Your Corp.

I am not convinced that organizational CAs issuing certs for access 
control purposes need the help of corporate attorneys.  Did any of 
these attorneys advise us on appropriate password lengths, on the use 
of ACLs vs. capabilities, etc?

Steve



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA24484 for <[e-mail]>; Mon, 23 Oct 2000 14:12:51 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 23 Oct 2000 15:17:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 23 Oct 2000 15:17:39 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA24486

Steve,

We have discussed this before, but unfortunately, name subordination does NOT solve all of the problems, in part because of the legal entanglements caused by treating wholly own subsidiary corporations, Doing Business As firms, franchises, etc., as though they were organization units of a larger parent organization.

I got a very stern, lecture on that subject from the lawyers when I was with GTE.  GTE Laboratories, Inc. is NOT an OU of GTE Corp., no way no how, according to them.  And neither is GTE of Pennsylvania, GTE of California, etc.

The concern that was expressed was that to identify such organizations, which are wholly owned but separate corporations, as organizational units might subject the holding company to liability that was incurred by the subordinate organization, which (in general) is precisely the reason why separate corporations were created in the first place -- to shelter the overall corporate structure from lower level liabilities.

Granted, this approach doesn't always work -- witness the Dow Corning vs. Dow Chemical breast implant suits.  But the corporate attorneys I have talked to are virtually unanimous in agreeing with this position, at least as long as the conventional name of the attribute is "organizationalUnit".

If this is the position with respect to holding companies, I have to believe that it would also be the position of any CAs with competent attorneys -- they are not going to allow the name of the CA to used to used for such purposes either, even if the sequence of RDNs is O=My CA, O=Your Corp.

Bob

>
>>>> Stephen Kent <[e-mail]> 10/23/00 11:01AM >>>
>Polar,
>
>As you and I discussed off list, while one cannot guarantee DN 
>uniqueness across all CAs, one can use the nameConstraints extension 
>in a cross-certificate to ensure that certificates issued by a given 
>CA, and evaluated in the domain of the issuer of the cross 
>certificate, are within a specified name space. This approach 
>addresses the naming concern cited in your message.
>
>Steve




Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23979 for <[e-mail]>; Mon, 23 Oct 2000 13:58:12 -0700 (PDT)
Received: from [192.168.1.2] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Mon, 23 Oct 2000 13:45:50 -0700 (PDT)
Date: Tue, 24 Oct 2000 01:47:38 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-reply-to: <[e-mail]>
To: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

David Kemp wrote:

[snip]
> 
> A driver's license is a paper certificate which binds some information
> (name, address, date of birth, photo) using some security info (special
> lamination, holograms, etc).  It is issued according to well known
> business practices which give relying parties some measure of the difficulty
> of obtaining one which contains incorrect information.

There are at least three "attributes" with incorrect information on my
current California Drive License: the weight is wrong (I won't say in which
direction ;-) and my picture shows me with glasses (I wear contacts now) and
much darker hair (I have a bit more gray :-(

> 
> Relying parties (check cashers, liquor stores, cinemas) use the
> driver's license to make access control decisions based on their own
> judgement of the strength of the authentication mechanism and the risk
> of loss.  They DO NOT have a contractual relationship with the issuer
> of the driver's license, nor do they rely upon standards stating what a
> license must contain.  They rely on what's in front of them and on the
> generally accepted business principle that the 50 states can be trusted
> to issue ID cards usable for the purpose of keeping a check written out
> to one person from being cashed by someone else.

I've stayed out of this thread, but you've touched upon one of my "hot
buttons". I'd like to make two points:

1. Since when does my driver's license prove that I have enough money in my
bank account to write a check, or that I am "authorized" to buy liquor (and
get drunk) or that I can go see an R rated movie. The only thing that my
driver license states is "This license is issued as a license to drive a
motor vehicle: it does not establish eligibility for employment, voter
registration, or public benefits." So the only thing it "authorizes" me to
do is drive a motor vehicle. And given how I look, I'm sure that if I walked
into a liquor store and bought some whiskey, I wouldn't be asked to show my
license. Maybe I'll start a campaign to change the license so that it states
"... it does not establish eligibility for employment, voter registration,
or public benefits; not does it guarantee payment for check written by this
person, or authorizes the person to buy liquor or to watch adult movies" or
even better "This license is issued as a license to drive a motor vehicle,
to write checks, to buy liquor and to watch R and X rated movies: it does
not..." ;-)

2. I won't try to change the "real business world" where it's accepted
business practice to confuse identity with authorization. There is a big
difference between "generally accepted business practices and principles"
being used today and trying to develop technical standards based on
presumptions of only right and wrong. Electronic relying parties can not
follow the same business practices or principles because certificates
(whether identity or attribute) can't have "almost correct" information.
Should I ever be asked to show my license to buy liquor, I would be allowed
to because my picture is "close enough" to how I currently look.
Paraphrasing Ed Gerck, "The lifetime of a certificate is inversely
proportional to the number of its attributes." Why? Because changing 1 bit
invalidates the certificate, even though in the real world changing an
attribute does not invalidate my license.

Just my thoughts,
Aram Perez

[snip]



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20412 for <[e-mail]>; Mon, 23 Oct 2000 10:57:47 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA23910; Mon, 23 Oct 2000 13:41:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 23 Oct 2000 13:54:24 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Sdv7bt5DBMMTuuVlDN5kAA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Polar,

You keep paying lip service to the idea that "standards are not a
substitute for system engineering", and then turn around and say that a
technical interoperability profile MUST require certain behavior, and
that PKIX must somehow mandate that whatever infrastructure is out
there today must be made "secure".

That just isn't the way things work.

A driver's license is a paper certificate which binds some information
(name, address, date of birth, photo) using some security info (special
lamination, holograms, etc).  It is issued according to well known
business practices which give relying parties some measure of the difficulty
of obtaining one which contains incorrect information.

Relying parties (check cashers, liquor stores, cinemas) use the
driver's license to make access control decisions based on their own
judgement of the strength of the authentication mechanism and the risk
of loss.  They DO NOT have a contractual relationship with the issuer
of the driver's license, nor do they rely upon standards stating what a
license must contain.  They rely on what's in front of them and on the
generally accepted business principle that the 50 states can be trusted
to issue ID cards usable for the purpose of keeping a check written out
to one person from being cashed by someone else.

An attribute authority (someone issuing a season pass to an amusement
park) will include sufficient identifying information (such as a name
and driver's license number) to ensure that John Smith's (senior) pass
cannot be used by John junior, or by some other John Smith.  This is all
done without any contractual relationship between the state DMV and the
amusement park.

As PKI and PMI are used to automate real-world business processes,
system engineering is required.  I don't consider the following, which
you seem to be proposing, to be a reasonable approach:

1) Look at all the SSL certificates that are already out there,
2) Impose technical constraints on attribute certificates, in an attempt to
3) Solve a general unspecified access control problem.

Don Flinn and others have well expressed the need for both due
diligence and system engineering when applying PKI and PMI.  I agree
with them, and I am unconvinced that your approach of applying
technical constraints to solve a procedural problem will meet with any
success whatsoever.  I am therefore opposed to specifying in an AC
profile the precise (or even the imprecise) conditions under which a
compliant AC issuer MUST link an AC to a particular PKC.

Dave




> From: Polar Humenn <[e-mail]>
> 
> Denis,
> 
> I am in agreement with you on your approach of including the objectDigest
> Info along with entityName or baseCertificateID. I think in environments
> where the Relying Parties, Attribute Certificate Issuers, and Subject
> Entities do not know and trust a priori the certificate management
> environment they all are emphatically working in, then the entityName
> and/or baseCertificateID must only be used in conjunction with the
> objectDigestInfo.
> 
> A good thing would be to figure out under the precise conditions in which
> a compliant Attribute Certificate Issuer MUST include objectDigestInfo.
> 
> I can think of one of the conditions right off.
> 
> In applications where there is no absolute assurance by all three classes
> of possible parties, i.e. subjects, attribute certificate issuers, and
> relying parties, are privy to each others business practices about the
> use of DN's.
> 
> I am not yet sure how you can write such requirements without getting
> agreements from all three parties.
> 
> -Polar



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18505 for <[e-mail]>; Mon, 23 Oct 2000 10:08:30 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA22588; Mon, 23 Oct 2000 13:14:00 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220809b61a2056bd5b@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 23 Oct 2000 13:08:03 -0400
To: Polar Humenn <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Polar,

Al pointed out in his experience, and the rule is true in a more 
general context, the folks responsible for managing access control 
are not the same as those responsible for managing identity (and 
maybe keys). This is a good motivation for use of ACs. Use of ACs 
allows each authority to manage authorization separate from one 
another, and from the identity issuer. Changes to your authorization 
in one context can be made without having to coordinate with other 
AAs, or with a CA.

Steve


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18115 for <[e-mail]>; Mon, 23 Oct 2000 10:04:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA13940; Mon, 23 Oct 2000 19:09:56 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 23 Oct 2000 19:09:57 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA07130; Mon, 23 Oct 2000 19:09:55 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA04482; Mon, 23 Oct 2000 19:09:55 +0200 (MET DST)
Date: Mon, 23 Oct 2000 19:09:55 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP. Version 10, Removal of SIA Extension
Cc: [e-mail]

A TS certificate contains the an access information was a feature in
the text, having this removed may not easily allow to get it back
in a next round. 

I would consider to include the complete definition of SIA in the
TS text since it is not or not yet defined anywhere else, and
maybe mention that it is expected that it will be removed later. 

In this way the feature is described and stable, and when
as soon as part1 gets updated and the TS text gets moved from
proposed to draft, one can remove it without having added
or removed any functionality. 
 
> Michael,
> 
> > Sounds like its time to get SIA back to TSS draft, Denis :)
> 
> "son-of-RFC2459" has not yet passed WG last call, nor IESG last call.
> Waiting for it would create a delay that could be estimated to be, at best,
> about two months and thus would mean issuing the TSP RFC next year. :-(
> 
> We now need this long-awaited RFC. 
> 
> Denis
> 
> Note: I have just posted to the web editor an update (version 11) that
> incorporates the changes that have been noticed (plus one, un-noticed in the
> ASN1 module !)


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17696 for <[e-mail]>; Mon, 23 Oct 2000 09:58:54 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA20944; Mon, 23 Oct 2000 13:04:27 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220808b61a1e844fd9@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 23 Oct 2000 13:01:12 -0400
To: Polar Humenn <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Polar,

As you and I discussed off list, while one cannot guarantee DN 
uniqueness across all CAs, one can use the nameConstraints extension 
in a cross-certificate to ensure that certificates issued by a given 
CA, and evaluated in the domain of the issuer of the cross 
certificate, are within a specified name space. This approach 
addresses the naming concern cited in your message.

Steve


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16581 for <[e-mail]>; Mon, 23 Oct 2000 09:31:19 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA104870; Mon, 23 Oct 2000 18:42:24 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA20370; Mon, 23 Oct 2000 18:35:46 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Oct 2000 18:35:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: [e-mail]
Subject: Re: TSP. Version 10, Removal of SIA Extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael,

> Sounds like its time to get SIA back to TSS draft, Denis :)

"son-of-RFC2459" has not yet passed WG last call, nor IESG last call.
Waiting for it would create a delay that could be estimated to be, at best,
about two months and thus would mean issuing the TSP RFC next year. :-(

We now need this long-awaited RFC. 

Denis

Note: I have just posted to the web editor an update (version 11) that
incorporates the changes that have been noticed (plus one, un-noticed in the
ASN1 module !)


> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Friday, 20 October 2000 6:26
> > To: Denis Pinkas
> > Cc: [e-mail]
> > Subject: Re: TSP. Version 10, Removal of SIA Extension
> >
> >
> > Tim and I have already started the addition of
> > subjectInfoAccess in the
> > next son-of-RFC2459 draft.  I assigned the OID for it
> > yesterday.  I posted
> > it to the IMC Web site earlier today.
> >
> > Russ
> >
> > At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
> > >Francois,
> > >
> > > > Hi Denis,
> > > >
> > > > I just noticed that in the latest draft you completely
> > remove from Section
> > > > 2.3 the text about a TSA's certificate possibly
> > containing a Subject
> > > > Information Access (SIA) extension. From the many
> > comments received during
> > > > last call against the previous draft, I did not recall
> > anyone asking for
> > > > the SIA extension to be removed.
> > > >
> > > > Did I miss anything or is there a particular reason why
> > the SIA extension
> > > > was removed?
> > >
> > >You read the draft very carefully, congratulations !
> > >
> > >I forgot to mention this point. At the Barcelona ISSE
> > meeting, I had a
> > >discussion with Stephen Kent about the progression of this
> > draft to RFC. We
> > >came to the conclusion that this draft should not be delayed
> > any longer.
> > >Since the SIA extension is not defined in RFC 2459, we would
> > have had to
> > >wait until "son-of-RFC 2459" is published. However, we did
> > not wanted to
> > >hold the draft until "son-of-RFC 2459" got its own RFC number.
> > >
> > >Since the SIA was not mandatory to implement, it has been
> > suppressed. We now
> > >have two options:
> > >
> > >1) either to re-incorporate it when the TSP Proposed
> > Standard will move to
> > >Standard,
> > >2) or define this extension directly in "son-of-RFC 2459"
> > (Tim can you hear
> > >me ???)
> > >
> > >Regards,
> > >
> > >Denis
> > >
> > > > Regards,
> > > >
> > > > Francois
> > > > ___________________________________
> > > > Francois Rousseau
> > > > Director of Standards and Conformance
> > > > Chrysalis-ITS
> > > > 1688 Woodward Drive
> > > > Ottawa, Ontario, CANADA, K2C 3R7
> > > > [e-mail]      Tel. [phone] ext. 419
> > > > http://www.chrysalis-its.com     Fax. [phone]
> >


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15342 for <[e-mail]>; Mon, 23 Oct 2000 08:52:09 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA11715; Mon, 23 Oct 2000 11:53:20 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 23 Oct 2000 11:53:18 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Denis Pinkas <[e-mail]>
cc: Russ Housley <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Denis,

I am in agreement with you on your approach of including the objectDigest
Info along with entityName or baseCertificateID. I think in environments
where the Relying Parties, Attribute Certificate Issuers, and Subject
Entities do not know and trust a priori the certificate management
environment they all are emphatically working in, then the entityName
and/or baseCertificateID must only be used in conjunction with the
objectDigestInfo.

A good thing would be to figure out under the precise conditions in which
a compliant Attribute Certificate Issuer MUST include objectDigestInfo.

I can think of one of the conditions right off.

In applications where there is no absolute assurance by all three classes
of possible parties, i.e. subjects, attribute certificate issuers, and
relying parties, are privy to each others business practices about the
use of DN's.

I am not yet sure how you can write such requirements without getting
agreements from all three parties.

-Polar

On Mon, 23 Oct 2000, Denis Pinkas wrote:

> Russ,
> 
> In my last E-mail on that topic I said: 
> 
> > Russ,
> > 
> > > An attribute or extension is the only acceptable approach to me, unless we
> > > coordinate with X.509 agrees to make the same change to the base syntax.
> > 
> > Since you said ... "unless we coordinate with X.509 agrees to make the same
> > change to the base syntax", there are two solutions, not a single acceptable
> > approach. On that basis, I agree with you.
> > 
> > We can certainly attempt to coordinate with ISO, since the Orlando meeting
> > is coming. I am a member of the ISO defect report team and can certainly
> > bring the attention of the ISO group on that topic. :-)
> 
> After some side discussion with Tom Guidin, Tom made a very good
> observation. The current syntax is:
> 
>    Holder ::= SEQUENCE {
>       baseCertificateID   [0] IssuerSerial OPTIONAL,
>               -- the issuer and serial number of
>               -- the holder's Public Key Certificate
>       entityName          [1] GeneralNames OPTIONAL,
>                -- the name of the claimant or role
>       objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
>                -- if present, version must be v2
>    }
> 
> This syntax could be used without any change, since we have, as Tom noticed,
> a SEQUENCE of OPTIONAL elements and not a CHOICE. So we would only need to
> fix the text without changing the ASN.1 syntax, by adversing the combination
> of the use of both the baseCertificateID and the objectDigestInfo
> parameters.
> 
> Here is an extract of the ISO text, which does not explicit mention that
> combination (but does not prevent it either):
> 
> " The version number differentiates between different versions of the
> attribute certificate. If holder includes objectDigestInfo or if issuer
> includes baseCertificateID or objectDigestInfo, version must be v2.
> 
> The holder field conveys the identity of the attribute certificate's holder.
>  
> The baseCertificateID component, if present, identifies a particular
> public-key certificate that is to be used to authenticate the identity of
> this holder when asserting privileges with this attribute certificate.
> 
> The entityName component, if present, identifies one or more names for the
> holder. If entityName is the only component present in holder, any
> public-key certificate that has one of these names as its subject can be
> used to authenticate the identity of this holder when asserting privileges
> with this attribute certificate. If baseCertificateID and entityName are
> both present, only the certificate specified by baseCertificateID may be
> used. In this case entityName is included only as a tool to help the
> privilege verifier locate the identified public-key certificate.
> 
> Note: There is a risk with the sole use of GeneralNames  to identify the
> holder, in that this points only to a name for the holder. This is generally
> insufficient to enable the authentication of a holder's identity for
> purposes of issuing privileges to that holder. Use of the issuer name and
> serial number of a specific public-key certificate, however, enables the
> issuer of attribute certificates to rely on the authentication process
> performed by the CA when issuing that particular public-key certificate.
> Also, some of the options in GeneralNames (e.g. IPAddress) are inappropriate
> for use in naming an attribute certificate holder, especially when the
> holder is a role and not an individual entity. Another problem with
> GeneralNames alone as an identifier for a holder is that many name forms
> within that construct do not have strict registration authorities or
> processes for the assignment of names.
>  
> The objectDigestInfo component, if present, is used directly to authenticate
> the identity of a holder, including an executable holder (e.g. an applet).
> The holder is authenticated by comparing a digest of the corresponding
> information, created by the privilege verifier with the same algorithm
> identified in objectDigestInfo with the content of objectDigest. If the two
> are identical, the holder is authenticated for purposes of asserting
> privileges with this attribute certificate."  
> 
> Some small changes to that text *might* be needed to say that the
> baseCertificateID may be used in conunction with the objectDigestInfo
> component. In fact the use of that combination might even only appear in the
> PKIX profile, while it would be "better" to have the two documents aligned.
> 
> Denis
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14754 for <[e-mail]>; Mon, 23 Oct 2000 08:40:44 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA11692; Mon, 23 Oct 2000 11:41:16 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 23 Oct 2000 11:41:14 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Don Flinn <[e-mail]>
cc: Stephen Farrell <[e-mail]>, Dale Gustafson <[e-mail]>, Stephen McConnell <[e-mail]>, Electronic Commerce DTF <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)
In-Reply-To: <005501c03d00$6f19a5a0$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Don,

In general PKI, has the problem that I "uncovered" with the Attribute
Certificate. So therefore CSIv2 does have this problem as well, especially
if it must rely on products and services in this space.

Trust relationships that you cite may be mandated by contract law,
provided you have contracts! However, if one is throwing around cliches,
then how about this one "Locking the barn door after the horse got out",
or "Houston, we have a problem". In open interoperable environments, you
may not have contracts, you may not have practical recourse of the law
anyway, say in international deployments.

All you can really get from PKI is the fact that the same entity that is
identified in the Attribute Certificate (the Holder) is the same entity
the Relying Party is correlating it with. That Holder is the "holder" of
the private key, not merely something named by an arbitrary DN. The
Attribute Certificate Issuer must be able to provide evidence that he is
indeed identifying the holder of a private key. A DN alone doesn't do it.
A DN of the entities issuer doesn't do it either for the same reasons.

BTW, a DN is just a bag of bits as far as I'm concerned. Its conventional
use cannot be enforced or relied upon. Its structure only serves as a
"tool" or an optimization of finding "things" that may be related to it.
You cannot infer an the subject's issuer from the subject's DN. If the
attribute certificate is not tied to a public key and you trust that. You
must have a highly constrained environment. That's not "interoperable".

Below you state only *one* situation in which all parties MUST "trust"
each other by basically subscribe to one TRUSTED DN server (which does DUE
DILIGENCE on updates), where all names are unique and all party's business
practices concerning DNs are well known to all parties, and contracts are
written on it between all parties together. Otherwise, you'll just get
into a finger pointing situation. If we want to make that a requirement
for CSIv2, then so be it. 

Cheers,
-Polar


On Mon, 23 Oct 2000, Don Flinn wrote:

> I assert that CSIv2 does not have the problem that Polar uncovered. Let's
> see if I can defend that assertion -:)
> 
> CSIv2 defines a wire protocol to facilitate secure interoperability.
> Therefore, if CSIv2 provides a way to support the resolution of the problem
> that Polar uncovered then CSIv2 is sound.
> 
> CSIv2 provides for the transfer of a chain of Authentication Certificates
> for the initiating client and a second chain of a Privilege Attribute
> Certificates (PAC) followed by the Authentication Certificate chain
> verifying the AA who issued the PAC.
> 
> The Holder field in the PAC points to one and only one Authentication
> Certificate identified by a CA and serial number which is unique to that CA.
> 
> Given the above, there are a series of trust relationships that must be
> supported by a security service implementation of CSIv2 and an application
> using that security service - namely:
> 
> The Application must trust the AA.  This can be accomplished by the
> application, supported by the security service implementation, using an
> authentication certificate in the PAC chain.  For example, the application
> stores authentication certificats of trusted AA's.  The security service
> implementation verifies the chain against one of the stored, trusted AA
> authentication certificates.
> 
> The application must trust the user's SSL certificate when using the default
> CSIv2 mechanism, SSL. (A similar statement holds true for other mechanisms.)
> This is accomplished the same way as above but for the user's certificate,
> i.e. establish trust in the user's CA or some CA in the chain.
> 
> The AA must trust the CA that issued the user's certificate.  In this case I
> am using the Holder field in the PAC.  The AA points to a user certificate
> issued by a CA that it trusts.
> 
> The CA has done due diligence in issuing the user certificate.  This is what
> I meant by the AA trusting the user's CA, i.e. the AA assures that the CA
> referenced in the Holder field of the PAC it issues has done its due
> diligence with respect to the user.
> 
> Given the above trust relationships lets look at the two "Henry Ford's".
> Henry Ford is defined by CA-1 as, e.g.
> o=Ford Motors,c=US,ou=Truck Division,ou=accounting_derborn,CN=Henry Ford.
> If the CA has done its due diligence then there can be only one Henry Ford
> with that full X.501 name.  If the full X.501 name does not point to a
> unique Henry Ford then that CA has not done its due diligence and can be
> sued to recover any damages done by its lack of due diligence.  If CA-2
> issues a certificate with the same full X.501 name then it is the same Henry
> Ford as that identified by CA-1, if CA-2 has done its due diligence. (I
> bring up law suites as an example of the recourses of an aggrieved party.
> An analogy is a bank which you trust and to which you have recourse if they
> fail in their due diligence and cost you money.  This is not the purview of
> the technology but of the law.)
> 
> If the AA issues a PAC that points to a incompetent or bogus CA then it has
> not done its due diligence and can be sued to recover any damage done by its
> negligence.
> 
> The trust relationships that I defined above are not the purview of CSIv2
> *nor* the draft-ietf-pkix-ac509prof-05 specifications.  The specification of
> the trust relationships are the purview of a higher level protocol or
> specification.  CSIv2 and the draft-ietf-pkix-ac509prof-05 specifications
> provide the protocols to support the ability to establish the trust
> relationships.  Note that I am not ignoring all the excellent discussion on
> the original thread related to tightening the language of the
> draft-ietf-pkix-ac509prof-05 specification.  What I am cautioning against is
> "throwing out the baby with the bathwater"  and mixing the intent and
> purview of these two specificcations with those of a higher level
> specification.
> 
> OMG is in the early stages of writing a Request for Proposal (RFP) which
> will/should address the higher level AA issues.  This RFP, I assert, should
> specify authentication servers and services and define their
> responsibilities as well as the interfaces to interact with them in a
> Federated situation.  The specification is tentatively called the
> Authorization Token Layer Acquisition Service, ATLAS, and has a mailing
> list - [e-mail] .  All who are interested in this issue are
> cordially invited to join.
> 
> Don
> 
> > -----Original Message-----
> > From: Stephen McConnell [mailto:[e-mail]]
> > Sent: Thursday, October 19, 2000 12:10 PM
> > To: Polar Humenn; Dale Gustafson
> > Cc: [e-mail]; [e-mail]; [e-mail]; Electronic
> > Commerce DTF
> > Subject: Impact on OMG's CSIv2 (was - RE: Comments on
> > draft-ietf-pkix-ac509prof-05.txt)
> >
> >
> >
> > Polar et. al.
> >
> > Some comments from an OMG/EC perspective:
> >
> > 	- EC has a significant subscribed list of end-user
> > 	  organisations that will end up using this stuff,
> > 	  possibly not in the pure IETF model of data
> > 	  structures, but in terms of the real application
> >         level problems based on the emerging CSIv2
> > 	  OMG's cross-domain security interoperability spec).
> >
> >   	- Members of EC are watching closely the CSIv2 process,
> > 	  because we know the CORBA security doesn't work beyond a
> > 	  single enterprise, and the CSIv2 is the silver bullet.
> > 	  Because CSIv2 depends on Attribute Certificates, this
> > 	  means  that the strength of CSIv2 is limited by the
> > 	  strength of X509 (2000).  If there are holes in X509
> > 	  (2000) it means that there are holes in CSIv2.  CSIv2 has
> > 	  been adopted. It will be presumably enter a finalisation
> > 	  phase during the next meeting.  Based on several emails
> > 	  sent out on this thread, my conclusion is that
> > 	  X509 (2000) isn't ready for prime time - adding a
> > 	  "by-the-way there are security holes and there are
> > 	  optional vendor fixes (if they want to) but, ooh,
> > 	  by the way, you, the customer, you should be selecting
> > 	  your provider on the basis your technical due-diligence"
> > 	  (etc.) ... simply sucks. But lets look at what this means
> > 	  in terms of the impact on CSIv2:
> >
> > 	  1. CSIv2 is dependent on the strength of X509 (2000), in
> > 	     particular, the dependence that CSIv2 places on
> > 	     Attribute Certificates
> >
> > 	  2. Holes have been identified by Polar in the Attribute
> > 	     Certificate model and confirmed by several other
> > 	     authorities on this list.
> >
> > 	  3. What I'm missing here is this thread is the distinction
> > 	     between the following:
> >
> > 		   OMG CSIv2 functionality
> >
> > 	            - why CSIv2 needs Attribute Certificates
> > 			  in the first place ?
> >
> > 			- is there any reason why CSIv2 cannot use
> > 			  X509 Classic instead ?
> >
> > 		   OMG PKI Service functionality
> >
> > 			- currently defines mechanisms for
> > 			  certificate issue and verification,
> >
> > 			- is missing an extendable valuetype
> > 			  definition of a certificate to sync X509
> > 			  and CSIv2 with the PKI service
> >
> > 		   Application level functionality
> >
> > 			- getting a clear distinction between
> > 			  application level (which is where I would
> > 		  	  have through Attribute Certificates are
> > 			  relevant) as opposed to CSIv2 service
> > 			  functionality.
> >
> > Cheers, Steve.
> >
> > P.S.  Please consider this email as a vote for fully expanded
> > acronyms.  For
> > myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
> > Consulting"!
> >
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from alpha.it-sec.com (alpha.it-sec.com [195.141.254.202]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08670 for <[e-mail]>; Mon, 23 Oct 2000 07:48:02 -0700 (PDT)
Received: from svzh0004.itsec.ch (localhost [127.0.0.1]) by alpha.it-sec.com (8.9.3/8.9.3) with ESMTP id QAA26589; Mon, 23 Oct 2000 16:51:27 +0200 (MET DST)
Received: by SVZH0004 with Internet Mail Service (5.5.2448.0) id <4WFG8VR0>; Mon, 23 Oct 2000 16:52:22 +0200
Message-ID: <F5545CEFBE7CD31190C90004AC4C1B64389626@SVZH0004>
From: "Teiwes, Stephan (iT_SEC)" <[e-mail]>
To: "'Maxim Masiutin'" <[e-mail]>, "Teiwes, Stephan (iT_SEC)" <[e-mail]>, "Hartmann, Peter  (iT_SEC)" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Use of the IDEA Encryption Algorithm in CMS
Date: Mon, 23 Oct 2000 16:52:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"

Dear Mr. Masuitin,

thanks a lot. We'll consider your comments and try to improve the draft
accordingly.

*Stephan Teiwes
iT_Security AG
www.it-sec.com

-----Original Message-----
From: Maxim Masiutin [mailto:[e-mail]]
Sent: Montag, 23. Oktober 2000 16:41
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Use of the IDEA Encryption Algorithm in CMS


Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!


I have a question about following paragraph in
draft-ietf-smime-idea-07.txt:

-----------
If IV is specified as above, it MUST be used as initial vector. In
this case, the ciphertext MUST NOT include the initial vector. If
IV is not specified, the first 64 bits of the ciphertext MUST be
considered as the initial vector. However, this alternative of not
including the IV SHOULD NOT be applied in CMS or S/MIME.
-----------

  The last sentence:

"this alternative of not including the IV [into "iv OCTET STRING" of
IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
applied in CMS or S/MIME.


Could you please expand this sentence by adding one of the short
explanations that I've proposed?

I do also have a question about the following paragraph:

------------
The SMIMECapability SEQUENCE representing the IDEA symmetric
encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
field and the parameters field MUST be absent. The SMIMECapability
SEQUENCE for IDEA encryption SHOULD be included in the symmetric
encryption algorithms portion of the SMIMECapabilities list. The
SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
------------

  Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
  representing IDEA as well as DER-encoded value? Please add ASN.1
  notation to the draft. Also, please clarify the byte order.

  And a test sample of CMS-message with IDEA will help me a lot!

  Thank you in advance.



-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/



Received: from karloff.boston.amer.iona.com (karloff.boston.amer.iona.com [63.65.132.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08499 for <[e-mail]>; Mon, 23 Oct 2000 07:46:55 -0700 (PDT)
Received: from dflinn (DFLINN.boston.amer.iona.com [63.65.133.203]) by karloff.boston.amer.iona.com (8.9.3/iona-1.02-sjamison) with SMTP id KAA19080; Mon, 23 Oct 2000 10:50:09 -0400 (EDT)
From: "Don Flinn" <[e-mail]>
To: "Stephen Farrell" <[e-mail]>, "Dale Gustafson" <[e-mail]>, "Polar Humenn" <[e-mail]>, "Stephen McConnell" <[e-mail]>
Cc: "Electronic Commerce DTF" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)
Date: Mon, 23 Oct 2000 10:49:23 -0400
Message-ID: <005501c03d00$6f19a5a0$[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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <001201c039e7$10421a10$[e-mail]>
Importance: Normal

I assert that CSIv2 does not have the problem that Polar uncovered. Let's
see if I can defend that assertion -:)

CSIv2 defines a wire protocol to facilitate secure interoperability.
Therefore, if CSIv2 provides a way to support the resolution of the problem
that Polar uncovered then CSIv2 is sound.

CSIv2 provides for the transfer of a chain of Authentication Certificates
for the initiating client and a second chain of a Privilege Attribute
Certificates (PAC) followed by the Authentication Certificate chain
verifying the AA who issued the PAC.

The Holder field in the PAC points to one and only one Authentication
Certificate identified by a CA and serial number which is unique to that CA.

Given the above, there are a series of trust relationships that must be
supported by a security service implementation of CSIv2 and an application
using that security service - namely:

The Application must trust the AA.  This can be accomplished by the
application, supported by the security service implementation, using an
authentication certificate in the PAC chain.  For example, the application
stores authentication certificats of trusted AA's.  The security service
implementation verifies the chain against one of the stored, trusted AA
authentication certificates.

The application must trust the user's SSL certificate when using the default
CSIv2 mechanism, SSL. (A similar statement holds true for other mechanisms.)
This is accomplished the same way as above but for the user's certificate,
i.e. establish trust in the user's CA or some CA in the chain.

The AA must trust the CA that issued the user's certificate.  In this case I
am using the Holder field in the PAC.  The AA points to a user certificate
issued by a CA that it trusts.

The CA has done due diligence in issuing the user certificate.  This is what
I meant by the AA trusting the user's CA, i.e. the AA assures that the CA
referenced in the Holder field of the PAC it issues has done its due
diligence with respect to the user.

Given the above trust relationships lets look at the two "Henry Ford's".
Henry Ford is defined by CA-1 as, e.g.
o=Ford Motors,c=US,ou=Truck Division,ou=accounting_derborn,CN=Henry Ford.
If the CA has done its due diligence then there can be only one Henry Ford
with that full X.501 name.  If the full X.501 name does not point to a
unique Henry Ford then that CA has not done its due diligence and can be
sued to recover any damages done by its lack of due diligence.  If CA-2
issues a certificate with the same full X.501 name then it is the same Henry
Ford as that identified by CA-1, if CA-2 has done its due diligence. (I
bring up law suites as an example of the recourses of an aggrieved party.
An analogy is a bank which you trust and to which you have recourse if they
fail in their due diligence and cost you money.  This is not the purview of
the technology but of the law.)

If the AA issues a PAC that points to a incompetent or bogus CA then it has
not done its due diligence and can be sued to recover any damage done by its
negligence.

The trust relationships that I defined above are not the purview of CSIv2
*nor* the draft-ietf-pkix-ac509prof-05 specifications.  The specification of
the trust relationships are the purview of a higher level protocol or
specification.  CSIv2 and the draft-ietf-pkix-ac509prof-05 specifications
provide the protocols to support the ability to establish the trust
relationships.  Note that I am not ignoring all the excellent discussion on
the original thread related to tightening the language of the
draft-ietf-pkix-ac509prof-05 specification.  What I am cautioning against is
"throwing out the baby with the bathwater"  and mixing the intent and
purview of these two specificcations with those of a higher level
specification.

OMG is in the early stages of writing a Request for Proposal (RFP) which
will/should address the higher level AA issues.  This RFP, I assert, should
specify authentication servers and services and define their
responsibilities as well as the interfaces to interact with them in a
Federated situation.  The specification is tentatively called the
Authorization Token Layer Acquisition Service, ATLAS, and has a mailing
list - [e-mail] .  All who are interested in this issue are
cordially invited to join.

Don

> -----Original Message-----
> From: Stephen McConnell [mailto:[e-mail]]
> Sent: Thursday, October 19, 2000 12:10 PM
> To: Polar Humenn; Dale Gustafson
> Cc: [e-mail]; [e-mail]; [e-mail]; Electronic
> Commerce DTF
> Subject: Impact on OMG's CSIv2 (was - RE: Comments on
> draft-ietf-pkix-ac509prof-05.txt)
>
>
>
> Polar et. al.
>
> Some comments from an OMG/EC perspective:
>
> 	- EC has a significant subscribed list of end-user
> 	  organisations that will end up using this stuff,
> 	  possibly not in the pure IETF model of data
> 	  structures, but in terms of the real application
>         level problems based on the emerging CSIv2
> 	  OMG's cross-domain security interoperability spec).
>
>   	- Members of EC are watching closely the CSIv2 process,
> 	  because we know the CORBA security doesn't work beyond a
> 	  single enterprise, and the CSIv2 is the silver bullet.
> 	  Because CSIv2 depends on Attribute Certificates, this
> 	  means  that the strength of CSIv2 is limited by the
> 	  strength of X509 (2000).  If there are holes in X509
> 	  (2000) it means that there are holes in CSIv2.  CSIv2 has
> 	  been adopted. It will be presumably enter a finalisation
> 	  phase during the next meeting.  Based on several emails
> 	  sent out on this thread, my conclusion is that
> 	  X509 (2000) isn't ready for prime time - adding a
> 	  "by-the-way there are security holes and there are
> 	  optional vendor fixes (if they want to) but, ooh,
> 	  by the way, you, the customer, you should be selecting
> 	  your provider on the basis your technical due-diligence"
> 	  (etc.) ... simply sucks. But lets look at what this means
> 	  in terms of the impact on CSIv2:
>
> 	  1. CSIv2 is dependent on the strength of X509 (2000), in
> 	     particular, the dependence that CSIv2 places on
> 	     Attribute Certificates
>
> 	  2. Holes have been identified by Polar in the Attribute
> 	     Certificate model and confirmed by several other
> 	     authorities on this list.
>
> 	  3. What I'm missing here is this thread is the distinction
> 	     between the following:
>
> 		   OMG CSIv2 functionality
>
> 	            - why CSIv2 needs Attribute Certificates
> 			  in the first place ?
>
> 			- is there any reason why CSIv2 cannot use
> 			  X509 Classic instead ?
>
> 		   OMG PKI Service functionality
>
> 			- currently defines mechanisms for
> 			  certificate issue and verification,
>
> 			- is missing an extendable valuetype
> 			  definition of a certificate to sync X509
> 			  and CSIv2 with the PKI service
>
> 		   Application level functionality
>
> 			- getting a clear distinction between
> 			  application level (which is where I would
> 		  	  have through Attribute Certificates are
> 			  relevant) as opposed to CSIv2 service
> 			  functionality.
>
> Cheers, Steve.
>
> P.S.  Please consider this email as a vote for fully expanded
> acronyms.  For
> myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
> Consulting"!
>



Received: from gate.ritlabs.com (IDENT:[e-mail] [212.56.195.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08002 for <[e-mail]>; Mon, 23 Oct 2000 07:35:40 -0700 (PDT)
Received: from fido (max [212.56.194.250]) by gate.ritlabs.com (8.11.0/8.11.0) with ESMTP id e9NEfKE06783; Mon, 23 Oct 2000 17:41:22 +0300
Date: Mon, 23 Oct 2000 16:40:46 +0200
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.47 Beta/8)
Organization: RITLABS
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], <[e-mail]>
Subject: Use of the IDEA Encryption Algorithm in CMS
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!


I have a question about following paragraph in
draft-ietf-smime-idea-07.txt:

-----------
If IV is specified as above, it MUST be used as initial vector. In
this case, the ciphertext MUST NOT include the initial vector. If
IV is not specified, the first 64 bits of the ciphertext MUST be
considered as the initial vector. However, this alternative of not
including the IV SHOULD NOT be applied in CMS or S/MIME.
-----------

  The last sentence:

"this alternative of not including the IV [into "iv OCTET STRING" of
IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
applied in CMS or S/MIME.


Could you please expand this sentence by adding one of the short
explanations that I've proposed?

I do also have a question about the following paragraph:

------------
The SMIMECapability SEQUENCE representing the IDEA symmetric
encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
field and the parameters field MUST be absent. The SMIMECapability
SEQUENCE for IDEA encryption SHOULD be included in the symmetric
encryption algorithms portion of the SMIMECapabilities list. The
SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
------------

  Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
  representing IDEA as well as DER-encoded value? Please add ASN.1
  notation to the draft. Also, please clarify the byte order.

  And a test sample of CMS-message with IDEA will help me a lot!

  Thank you in advance.



-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04523 for <[e-mail]>; Mon, 23 Oct 2000 05:45:58 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA214374; Mon, 23 Oct 2000 08:51:04 -0400
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id IAA36440; Mon, 23 Oct 2000 08:50:15 -0400
Importance: Normal
Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
To: [e-mail]
Cc: <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
Date: Mon, 23 Oct 2000 06:10:39 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.5.dev00 |October 4, 2000) at 10/23/2000 08:51:30 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

David,

Thanks for the comments - I've added further comments below prefaced with
TJH>

Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]


"David Chadwick" <[e-mail]> on 10/21/2000 11:08:25 AM

Please respond to [e-mail]

To:   Timothy Hahn/Endicott/IBM@IBMUS, <[e-mail]>
cc:   [e-mail]
Subject:  Re: comments on draft-ietf-pkix-ldap-schema-01.txt



From:               [e-mail]
To:                 [e-mail]
Subject:            comments on draft-ietf-pkix-ldap-schema-01.txt
Date sent:          Thu, 21 Sep 2000 14:18:15 -0400

> Greetings,
Tim
Apologies for the delay

>
> Section 2:
> ----------
> I would prefer that the phrase "use the subschemasubentry attribute in
> the root DSE" be changed to "use the subschemasubentry attribute from
> the namingContext entry which is found in the root DSE".

I disagree with your proposed change for the following reasons:

firstly the namingContext entry is not found in the root DSE, but
rather a pointer to the namingContext entry is found in the root
DSE. But this does not help, as the subschema subentry itself is
only mandatorily pointed to from the rootDSE, and not from the
namingContext entry. This is assuming I have read 2251 correctly,
viz:

If the server masters directory entries under one
   or more schema rules, there may be any number of values
of the
   subschemaSubentry attribute in the root DSE.

TJH> I should have used the phrase "namingContext attribute in the
TJH> root DSE".  The trouble I see with multiple values in the
TJH> subschemasubentry attribute in the root DSE is that because
TJH> attributes contain un-ordered sets of values, how does one
TJH> correlate a specific subschemasubentry value with the
TJH> particular namingContext value (DN) under which the client
TJH> intends to add, modify, or delete an entry?  Thus, I still
TJH> feel it is better to obtain the subschemasubentry value (DN)
TJH> by first getting the namingContext value (DN) from the
TJH> root DSE, then performing a base search against that DN
TJH> to get the subschemasubentry attribute value.  It's not
TJH> guaranteed that entries below that "namingContext entry"
TJH> aren't in yet another namingContext (in some other server)
TJH> but getting the subschemasubentry value in this fashion
TJH> would give you a much better chance of getting the schema
TJH> that governs the particular sub-tree (namingContext)
TJH> that the application is interested in interacting with.
TJH> Multiple subschemasubentry values in the root DSE is just
TJH> confusing because they aren't "correlated" to the
TJH> namingContext attribute values.

>
> Section 3.2:
> ------------
> In the BNF for "GeneralName", a single whitespace character appears
> (e.g. "rfc822 +").  Was this intentional?  It seems out of

I dont really mind either way here. I will let Steven be the
authoritative voice on this

> place/misleading.
>
> Editor's note on AuthorityKeyIdentifier:
> ----------------------------------------
> Seems to me that authority issuer name and authority certificate
> serial number could be useful.

What we really need is some LDAP server vendor (IBM??) to
implement these matching rules and to give some feedback about
which fields are really useful for users to use. At the moment we
can only guess at what people will want to use in practice.


>
> Section 4.1:
> ------------
> In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> is OPTIONAL, correct?  It should only be needed if
> "DistributionPointName" is specified, I think.

Yes we could change the ABNF to put the  $ inside the DP
construct.

>
> Section 5 - ISSUE:
> ------------------
> I am not qualified to provide an opinion on this one.
>
> Section 5.3.2 - first Editor's note:
> ------------------------------------
> I would like to see attribute type names (not just OIDs) be allowed.

The AC profile specifies that the attribute MUST be identified by its
OID in the AC. Therefore if the user interface allows attribute
names to be presented by the user, something has to map this into
the correct OID, otherwise a wrong AC will be found by the LDAP
server. If we specify an OID in the matching rule, then it must be
the user interface that does the mapping. If we allow string names
in the matching rule, it must be the server that does the mapping.

What do you think?

TJH> I think that pushing OID <-> friendlyName mappings onto
TJH> clients is a bad think to rely on.  Anything we can do
TJH> to lessen complex schema interaction by client programs
TJH> is a good thing IMHO.

>
> Section 5.3.2 - second Editor's note:
> -------------------------------------
> I would find 5.3.9 Time Specification Match to be useful.  I don't
> have experience with the others.
>

Thanks for that.

David
>
> Regards,
> Tim Hahn
>
> Internet: [e-mail]
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: [phone]     tie-line: 8/852.6388
> fax: [phone]


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************





Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02528 for <[e-mail]>; Mon, 23 Oct 2000 04:54:23 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA70890; Mon, 23 Oct 2000 14:05:16 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA17092; Mon, 23 Oct 2000 13:57:54 +0200
Message-ID: <[e-mail]>
Date: Mon, 23 Oct 2000 13:57:55 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, Polar Humenn <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

In my last E-mail on that topic I said: 

> Russ,
> 
> > An attribute or extension is the only acceptable approach to me, unless we
> > coordinate with X.509 agrees to make the same change to the base syntax.
> 
> Since you said ... "unless we coordinate with X.509 agrees to make the same
> change to the base syntax", there are two solutions, not a single acceptable
> approach. On that basis, I agree with you.
> 
> We can certainly attempt to coordinate with ISO, since the Orlando meeting
> is coming. I am a member of the ISO defect report team and can certainly
> bring the attention of the ISO group on that topic. :-)

After some side discussion with Tom Guidin, Tom made a very good
observation. The current syntax is:

   Holder ::= SEQUENCE {
      baseCertificateID   [0] IssuerSerial OPTIONAL,
              -- the issuer and serial number of
              -- the holder's Public Key Certificate
      entityName          [1] GeneralNames OPTIONAL,
               -- the name of the claimant or role
      objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
               -- if present, version must be v2
   }

This syntax could be used without any change, since we have, as Tom noticed,
a SEQUENCE of OPTIONAL elements and not a CHOICE. So we would only need to
fix the text without changing the ASN.1 syntax, by adversing the combination
of the use of both the baseCertificateID and the objectDigestInfo
parameters.

Here is an extract of the ISO text, which does not explicit mention that
combination (but does not prevent it either):

" The version number differentiates between different versions of the
attribute certificate. If holder includes objectDigestInfo or if issuer
includes baseCertificateID or objectDigestInfo, version must be v2.

The holder field conveys the identity of the attribute certificate's holder.
 
The baseCertificateID component, if present, identifies a particular
public-key certificate that is to be used to authenticate the identity of
this holder when asserting privileges with this attribute certificate.

The entityName component, if present, identifies one or more names for the
holder. If entityName is the only component present in holder, any
public-key certificate that has one of these names as its subject can be
used to authenticate the identity of this holder when asserting privileges
with this attribute certificate. If baseCertificateID and entityName are
both present, only the certificate specified by baseCertificateID may be
used. In this case entityName is included only as a tool to help the
privilege verifier locate the identified public-key certificate.

Note: There is a risk with the sole use of GeneralNames  to identify the
holder, in that this points only to a name for the holder. This is generally
insufficient to enable the authentication of a holder's identity for
purposes of issuing privileges to that holder. Use of the issuer name and
serial number of a specific public-key certificate, however, enables the
issuer of attribute certificates to rely on the authentication process
performed by the CA when issuing that particular public-key certificate.
Also, some of the options in GeneralNames (e.g. IPAddress) are inappropriate
for use in naming an attribute certificate holder, especially when the
holder is a role and not an individual entity. Another problem with
GeneralNames alone as an identifier for a holder is that many name forms
within that construct do not have strict registration authorities or
processes for the assignment of names.
 
The objectDigestInfo component, if present, is used directly to authenticate
the identity of a holder, including an executable holder (e.g. an applet).
The holder is authenticated by comparing a digest of the corresponding
information, created by the privilege verifier with the same algorithm
identified in objectDigestInfo with the content of objectDigest. If the two
are identical, the holder is authenticated for purposes of asserting
privileges with this attribute certificate."  

Some small changes to that text *might* be needed to say that the
baseCertificateID may be used in conunction with the objectDigestInfo
component. In fact the use of that combination might even only appear in the
PKIX profile, while it would be "better" to have the two documents aligned.

Denis


Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA19500 for <[e-mail]>; Sun, 22 Oct 2000 22:56:42 -0700 (PDT)
Received: from mailsv.nec.co.jp ([10.7.68.90]) by TYO202.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id PAA19239 for <[e-mail]>; Mon, 23 Oct 2000 15:02:13 +0900 (JST)
Received: from mgw1.netlab.nec.co.jp (mgw1.netlab.nec.co.jp [133.201.4.10]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP id PAA22212 for <[e-mail]>; Mon, 23 Oct 2000 15:01:56 +0900 (JST)
Received: from mail.netlab.nec.co.jp (mail.netlab.nec.co.jp [172.16.3.22]) by mgw1.netlab.nec.co.jp (8.9.3/3.7W-MGW1_NETLAB) with ESMTP id PAA04866 for <[e-mail]>; Mon, 23 Oct 2000 15:02:11 +0900 (JST)
Received: from splpe918.netlab.nec.co.jp (splpe918.netlab.nec.co.jp [172.16.5.109]) by mail.netlab.nec.co.jp (8.9.3/3.7W-MAIL.NETLAB) with ESMTP id PAA13550 for <[e-mail]>; Mon, 23 Oct 2000 15:02:11 +0900 (JST)
Received: from localhost (localhost.netlab.nec.co.jp [127.0.0.1]) by splpe918.netlab.nec.co.jp (8.9.3+3.2W/3.7W) with ESMTP id OAA18392 for <[e-mail]>; Mon, 23 Oct 2000 14:52:56 +0900 (JST)
To: [e-mail]
Subject: CA key pair changeover
X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Mon, 23 Oct 2000 14:52:56 +0900
From: Mine Sakurai <[e-mail]>
X-Dispatcher: imput version 980905(IM100)
Lines: 36

/FYI/

Hi,
We are managing experimental CAs in WIDE project. 
We had a CA key pair changeover experiment in June 2000, including
Apache+openSSL, Netscape Communicator, and Internet Explorer.

We wrote a report. You can get the report from the URL
http://www.wide.ad.jp/wg/moca/CAkeychangeover.txt 

(in japanese,
http://www.wide.ad.jp/wg/moca/CAkeychangeover-j.txt )

Any comments or suggestions are welcome. 

Abstract:
 A lot of CAs have been managed for several years, but we've not yet
 seen a situation where CA key pair was changed due to CA
 certificate expiration. We had an experiment of CA key pair
 changeover. In this experiment, we examined how a CA key pair
 changeover would make influences to existing applications. As a
 result, we found that some of the existing applications required
 change of CA distinguished name at the same time of CA key pair
 changeover for smooth transition.
 Have you ever discussed whether it is important for a CA management
 policy to change the CA distinguished name or not? If CA name change
 is not allowed in some CA management policies, we think existing
 applications should support the CA key pair changeover without change
 of CA distinguished name. 
 Please send any comments to "[e-mail]".

Best Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mine Sakurai          E-mail: [e-mail]
5th Laboratory
Development Laboratories, NEC Networks, Tokyo, JAPAN


Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26522 for <[e-mail]>; Sat, 21 Oct 2000 08:02:52 -0700 (PDT)
Received: from dwc-acer ([62.252.109.249]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20001021150814.TLVJ13676.mta03-svc.ntlworld.com@dwc-acer>; Sat, 21 Oct 2000 16:08:14 +0100
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: [e-mail], <[e-mail]>
Date: Sat, 21 Oct 2000 16:08:25 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
Reply-to: [e-mail]
CC: [e-mail]
Message-ID: <39F1BF79.24531.F9869C@localhost>
Priority: normal
In-reply-to: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.12c)

From:           	[e-mail]
To:             	[e-mail]
Subject:        	comments on draft-ietf-pkix-ldap-schema-01.txt
Date sent:      	Thu, 21 Sep 2000 14:18:15 -0400

> Greetings,
Tim
Apologies for the delay

> 
> Section 2:
> ----------
> I would prefer that the phrase "use the subschemasubentry attribute in
> the root DSE" be changed to "use the subschemasubentry attribute from
> the namingContext entry which is found in the root DSE".

I disagree with your proposed change for the following reasons:

firstly the namingContext entry is not found in the root DSE, but 
rather a pointer to the namingContext entry is found in the root 
DSE. But this does not help, as the subschema subentry itself is 
only mandatorily pointed to from the rootDSE, and not from the 
namingContext entry. This is assuming I have read 2251 correctly, 
viz:

If the server masters directory entries under one
   or more schema rules, there may be any number of values 
of the
   subschemaSubentry attribute in the root DSE.

> 
> Section 3.2:
> ------------
> In the BNF for "GeneralName", a single whitespace character appears
> (e.g. "rfc822 +").  Was this intentional?  It seems out of

I dont really mind either way here. I will let Steven be the 
authoritative voice on this

> place/misleading.
> 
> Editor's note on AuthorityKeyIdentifier:
> ----------------------------------------
> Seems to me that authority issuer name and authority certificate
> serial number could be useful.

What we really need is some LDAP server vendor (IBM??) to 
implement these matching rules and to give some feedback about 
which fields are really useful for users to use. At the moment we 
can only guess at what people will want to use in practice.


> 
> Section 4.1:
> ------------
> In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> is OPTIONAL, correct?  It should only be needed if
> "DistributionPointName" is specified, I think.

Yes we could change the ABNF to put the  $ inside the DP 
construct.

> 
> Section 5 - ISSUE:
> ------------------
> I am not qualified to provide an opinion on this one.
> 
> Section 5.3.2 - first Editor's note:
> ------------------------------------
> I would like to see attribute type names (not just OIDs) be allowed.

The AC profile specifies that the attribute MUST be identified by its 
OID in the AC. Therefore if the user interface allows attribute 
names to be presented by the user, something has to map this into 
the correct OID, otherwise a wrong AC will be found by the LDAP 
server. If we specify an OID in the matching rule, then it must be 
the user interface that does the mapping. If we allow string names 
in the matching rule, it must be the server that does the mapping.

What do you think?

> 
> Section 5.3.2 - second Editor's note:
> -------------------------------------
> I would find 5.3.9 Time Specification Match to be useful.  I don't
> have experience with the others.
> 

Thanks for that.

David
> 
> Regards,
> Tim Hahn
> 
> Internet: [e-mail]
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: [phone]     tie-line: 8/852.6388
> fax: [phone]


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19643 for <[e-mail]>; Fri, 20 Oct 2000 09:01:13 -0700 (PDT)
Received: from bpsi.net (port435.bpsi.net [209.54.245.235]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9KG3YD00720; Fri, 20 Oct 2000 11:03:34 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Fri, 20 Oct 2000 11:01:11 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: Polar Humenn <[e-mail]>, "Linn, John" <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al, Polar,

Let me also try to summarize.

I think we've arrived at the current state because the group genuinely perceives
the need for Attribute Certificates.  I think there is a common sense that there
is or will soon be a compelling need for secure applications to distribute and
utilize tamper-resistant, application specific data elements within the global
PKI.  It is envisioned that authoritative entities will deploy Attribute
Authority systems that manage the life cycle of these special certificates.  We
further speculate that each authoritative entity will work with it's various
constituents to define the form, fit, and function of a specific attribute
certificate that will be utilized by a well-defined set of applications.  This
application specific certificate's format and content will be updated from time
to time as the applications evolve, etc. under some management process
controlled by the authoritative entity.

Past experience has strongly suggested what NOT to do but has not necessarily
indicated the most appropriate course of action.

Logically, and assuming the need is real, there are at least three possible
approaches:

1. Embed the Attribute Certificate information in x.509 v3 Identification
Certificates

Each industry or market group (banking, finance, insurance, communications,
government, et. al.) can create a set non-critical extensions that allow their
application-specific information to be carried in a common public key
certificate or certificates.

In the near term (at least) this is the most effective approach because each
design can take a free ride on all of the PKI infrastructure that is being put
in place at great expense.  The downside is that the combined certificate
retains all of the properties of a public key certificate irrespective of
whether that makes sense for the attribute information and the secure
application(s) that will utilize it.

2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate

This has been suggested in the past but was not well received, likely because it
was obvious that significant additional overhead would be added to each
attribute certificate but it could not be shown that such a close coupling of
the attribute certificate and public key certificate would have technical merit
that justifies the cost.  Problems of keeping the ID certificate and attribute
together are eliminated but there are still two certificate chains.  The
infrastructure for and deployment of ID certificates can be utilized "as is".

3. Provide a Link from the Attribute Certificate to the Public Key Certificate

This approach appeared at the outset to be the most elegant and, most
importantly, appeared to be the most flexible.  It has just now become more
apparent that creating a reliable, "dynamic" link between the two certificates
is difficult.  This has been discussed at length recently.

Perhaps others can recall other approaches that have been suggested.

My sense is that the real value of a separate attribute certificate is that it
invites others with specific application expertise to join the process "earlier"
without making everyone's work overly complex -- if (and only if) that's true,
will people be willing to pay some reasonable price to accomplish the necessary
up-front planning.

What appears to be missing is a framework that enables secure application
builders to understand when they can "have at it" knowing they have a reasonably
stable environment around them.  That is, allows and encourages their innovative
work to move forward in  parallel with that of other industry and market
groups.  In order for that to happen, there needs to be a common understanding
that the basic problem is bounded and within range.

A framework for attribute certificates might better define many of the things we
have recently discussed:

 - encode / decode methods supported (ASN.1, XML, other)
 - commonly used data elements
 - encryption methods (selected attributes, full certificate)
 - delivery methods (SSL, S/MIME, directories, other)
 - certificate path creation / signature validation
 - certificate status checking
 - summary:  distinction between ID certificates and attribute certificates
 - other ?

Perhaps this has already been done elsewhere.  I suspect even an all-knowing
expert would have to look long and hard at the overall requirements for
attribute certificates before deciding that a single approach would suffice.

Comments?

Best Regards,

Dale Gustafson



Al Arsenault wrote:

> Polar Humenn wrote:
> >
> > Hi Al,
> >
> > The problem is that an Attribute Certificte Authority must be separate
> > from a Identity Certificate Authority, because it has control over the
> > attribute information. So, if we have the IDentity CA issues a certificate
> > of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
> > the Attribute Certificate Authority issues a new certificate (effectively
> > cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
> > difference to having a separate data structure?
> >
> > Do you really think the correlation problem of a separate AC at the
> > Relying Party is that easy?
> >
> > Cheers,
> > -Polar
> >
> >
>
> In THAT particular system it was, because everything chained back to
> what was essentially a single trusted Root CA. (It was called a "Policy
> Approving Authority" or PAA, but it was in effect a single
> globally-trusted root.) And, name constraints were enforced throughout
> the system, providing a guarantee that unless some CA screwed up
> somewhere or a trusted human was an active attacker, every DN was indeed
> unique. (And such a screw-up or attacker would ultimately be detectable
> through other means.)
>
> Now, in other scenarios which don't have such a strictly-enforced
> policy, it's a different ballgame.  I've been dealing with it a lot
> lately, though, because my company primarily sells two products, one of
> which is a CA/PKI product and the other which is essentially an
> Attribute Certificate/PMI product. When implemented properly, each
> product is secure, and if they're integrated properly, the combination
> is secure (for whatever values of "secure").  But if some customer wants
> to do something new with them - which happens a lot, because attribute
> certificates are so new in practice - we work carefully with them to
> make sure that they're not doing anything foolish, or that will inhibit
> the desired security level.
>
> The bottom line on all of this is that there are ways to do things
> "securely", and ways to do them "insecurely" for whatever definition of
> "secure" you prefer.  What we need to do in the standards world is (1)
> do the best we can to ensure that "secure" is possible with conformant
> products; and (2) make clear where the risks lie.  I give a talk on
> occasion whose theme is "standards are no substitute for proper system
> engineering."  I really believe that.
>
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.



Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12710 for <[e-mail]>; Fri, 20 Oct 2000 06:33:03 -0700 (PDT)
Received: (qmail 31484 invoked from network); 20 Oct 2000 13:38:12 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 20 Oct 2000 13:38:12 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 20 Oct 2000 08:38:09 -0500
Message-ID: <[e-mail]>
Date: Fri, 20 Oct 2000 06:38:12 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: simply a bad name model?, was Re: Comments on  draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[trimming CC list]

Dave:

As we know, PKI DNs are quite arbitrary when compared with IP numbers, which
are constants in routers and are further defined by a physical topology.  PKI DNs are
also quite arbitrary when compared with DNS names, which are in turn also quite
arbitrary when compared with IPs. So, DNS names are fully  independent from the IP
addresses used and PKI DNs have no relationship whatsoever with any of them.

Thus, I find the argument to change DNs not so compelling as with changing  IP
addresses. Any organization can and should be able to change its PKI DNs without
worrying about the needs of the network layer!

We should ask the question whether  this WG is not creating artificial constraints on
names simply because a bad name model is used and not how can we justify the bad
name model used.  It is OK IMO for this WG to use a bad name model but it is not
OK for this WG to raise this choice to the level of a "requirement."

Cheers,

Ed Gerck

"David P. Kemp" wrote:

> It's happened before, when organizations with isolated IP networks
> decided to connect to the Internet.  It was a royal pain to get a block
> of official IP addresses and renumber all your machines, but it was
> necessary, so people did it.  (This was before NAT and masquerading,
> of course.)
>
> At some point, organizations with isolated PKIs might decide to get an
> "official" DN subtree and issue certificates within it.  After an
> organization makes a decision to operate in a coordinated way with
> other organizations, implementation of name constraints in cross certs
> and replacement of user certificates is not particularly daunting.
> Less daunting than IP renumbering, at any rate.
>
> "Compliance" is not the problem.  The problem is understanding that an
> Inter-PKI cannot really work if users pick their own DNs any more than
> the Internet could work if users picked their own IP addresses.

> Dave
>
> > From: Polar Humenn <[e-mail]>
> >
> > But this condition of operation for the AA still hinges on the fact that
> > the DN space MUST be unique after cross certifying PKI's.
> >
> > Can you really see that happening?
> >
> > I cannot see that happening in the real world. Especially with many
> > players, and especally when you need to do things quickly. Forcing one
> > organization or both to comply with the other, is a lot of work, and
> > figuring out name constraints for both could be a daunting effort, not
> > mentioning getting it correct.
> >
> > Cheers,
> > -Polar



Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16524 for <[e-mail]>; Thu, 19 Oct 2000 18:06:05 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA19403; Thu, 19 Oct 2000 18:06:58 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <46FY5G8Q>; Thu, 19 Oct 2000 18:10:27 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Polar Humenn <[e-mail]>, Al Arsenault <[e-mail]>
Cc: "Linn, John" <[e-mail]>, Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 19 Oct 2000 18:10:26 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Polar,

Earlier you wrote to Al that:

> . . . an Attribute Certificte Authority must be separate
> from a Identity Certificate Authority . . .

I disagree.  An authority in control of identity may also be authoritative
for attributes associated with that identity.

Mike


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12410 for <[e-mail]>; Thu, 19 Oct 2000 14:42:47 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA06280; Thu, 19 Oct 2000 17:39:08 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 19 Oct 2000 17:39:07 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: "Linn, John" <[e-mail]>, Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 19 Oct 2000, Al Arsenault wrote:

> Polar Humenn wrote:
> > Do you really think the correlation problem of a separate AC at the
> > Relying Party is that easy?
> 
> In THAT particular system it was, because everything chained back to
> what was essentially a single trusted Root CA. (It was called a "Policy
> Approving Authority" or PAA, but it was in effect a single
> globally-trusted root.) And, name constraints were enforced throughout
> the system, providing a guarantee that unless some CA screwed up
> somewhere or a trusted human was an active attacker, every DN was indeed
> unique. (And such a screw-up or attacker would ultimately be detectable
> through other means.)

True. However, all parties know (or should I say suspect) extactly what
the common trusted root is.

In the general case of PKI, all I really have is a notion of being able to
authenticate a holder of a particular private key. That's it! I have some
"hint" called a certificate which may give him a name in some space. BTW,
He doesn't even have to give me that hint. But if he does, the certificate
he gives me may not mean anything to me. That is, I might not trust the
certificate's CA. However, it might help me find a certificate I have for
him that I do trust, (under the same DN, or a different one?). I guess
this is called path discovery?

Some SSL implementations don't really work like that. The client delivers a
chain to a root, and its compared against a "trusted" root certificate
registered in the servers space. That's not really a
"cross-certification", but is the practical side of things. 

To cross certify, I should really have my bonafide root CA create a
certificate by extracting the public key from the "trusted" root
certificates and giving the new certificate a name. Correct?

This approach I believe is the approach that Carlisle suggests. 

On the cross certify, especially with a ubiquitous directory, I would like
to use the CA name in the "trusted' certificate given to me. That would
make it easy to locate. However, that may violate name constraints of my
own CA because I may not be allowed to issue certificates in that space.
Isn't that right? I would have to use a different name.

I guess that's why I'm skeptical that names actually work at all between
at least three parties. Of course, as you have concluded and determined
still takes a lot of work, you need to initally have all parties *believe*
they are under the same trusted root. (and actually implemented it as
such).

> I give a talk on occasion whose theme is "standards are no substitute
> for proper system engineering."  I really believe that.

I agree. However, when you want to be "interoperable" it would be nice if
the standards could constrain, if not eliminate, the risks where possible.

Cheers,
-Polar

> Now, in other scenarios which don't have such a strictly-enforced
> policy, it's a different ballgame.  I've been dealing with it a lot
> lately, though, because my company primarily sells two products, one of
> which is a CA/PKI product and the other which is essentially an
> Attribute Certificate/PMI product. When implemented properly, each
> product is secure, and if they're integrated properly, the combination
> is secure (for whatever values of "secure").  But if some customer wants
> to do something new with them - which happens a lot, because attribute
> certificates are so new in practice - we work carefully with them to
> make sure that they're not doing anything foolish, or that will inhibit
> the desired security level.
> 
> The bottom line on all of this is that there are ways to do things
> "securely", and ways to do them "insecurely" for whatever definition of
> "secure" you prefer.  What we need to do in the standards world is (1)
> do the best we can to ensure that "secure" is possible with conformant
> products; and (2) make clear where the risks lie.  I give a talk on
> occasion whose theme is "standards are no substitute for proper system
> engineering."  I really believe that.
> 
> 		Al Arsenault
> 		Chief Security Architect
> 		Diversinet Corp.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11589 for <[e-mail]>; Thu, 19 Oct 2000 14:11:25 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id HAA09393; Fri, 20 Oct 2000 07:23:11 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <VAHVDBCD>; Fri, 20 Oct 2000 08:14:30 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Russ Housley <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Fri, 20 Oct 2000 08:14:26 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Sounds like its time to get SIA back to TSS draft, Denis :)

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, 20 October 2000 6:26
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: TSP. Version 10, Removal of SIA Extension
> 
> 
> Tim and I have already started the addition of 
> subjectInfoAccess in the 
> next son-of-RFC2459 draft.  I assigned the OID for it 
> yesterday.  I posted 
> it to the IMC Web site earlier today.
> 
> Russ
> 
> At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
> >Francois,
> >
> > > Hi Denis,
> > >
> > > I just noticed that in the latest draft you completely 
> remove from Section
> > > 2.3 the text about a TSA's certificate possibly 
> containing a Subject
> > > Information Access (SIA) extension. From the many 
> comments received during
> > > last call against the previous draft, I did not recall 
> anyone asking for
> > > the SIA extension to be removed.
> > >
> > > Did I miss anything or is there a particular reason why 
> the SIA extension
> > > was removed?
> >
> >You read the draft very carefully, congratulations !
> >
> >I forgot to mention this point. At the Barcelona ISSE 
> meeting, I had a
> >discussion with Stephen Kent about the progression of this 
> draft to RFC. We
> >came to the conclusion that this draft should not be delayed 
> any longer.
> >Since the SIA extension is not defined in RFC 2459, we would 
> have had to
> >wait until "son-of-RFC 2459" is published. However, we did 
> not wanted to
> >hold the draft until "son-of-RFC 2459" got its own RFC number.
> >
> >Since the SIA was not mandatory to implement, it has been 
> suppressed. We now
> >have two options:
> >
> >1) either to re-incorporate it when the TSP Proposed 
> Standard will move to
> >Standard,
> >2) or define this extension directly in "son-of-RFC 2459" 
> (Tim can you hear
> >me ???)
> >
> >Regards,
> >
> >Denis
> >
> > > Regards,
> > >
> > > Francois
> > > ___________________________________
> > > Francois Rousseau
> > > Director of Standards and Conformance
> > > Chrysalis-ITS
> > > 1688 Woodward Drive
> > > Ottawa, Ontario, CANADA, K2C 3R7
> > > [e-mail]      Tel. [phone] ext. 419
> > > http://www.chrysalis-its.com     Fax. [phone]
> 


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA11205 for <[e-mail]>; Thu, 19 Oct 2000 14:03:27 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA28911; Thu, 19 Oct 2000 14:07:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 19 Oct 2000 16:26:03 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: TSP. Version 10, Removal of SIA Extension
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim and I have already started the addition of subjectInfoAccess in the 
next son-of-RFC2459 draft.  I assigned the OID for it yesterday.  I posted 
it to the IMC Web site earlier today.

Russ

At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
>Francois,
>
> > Hi Denis,
> >
> > I just noticed that in the latest draft you completely remove from Section
> > 2.3 the text about a TSA's certificate possibly containing a Subject
> > Information Access (SIA) extension. From the many comments received during
> > last call against the previous draft, I did not recall anyone asking for
> > the SIA extension to be removed.
> >
> > Did I miss anything or is there a particular reason why the SIA extension
> > was removed?
>
>You read the draft very carefully, congratulations !
>
>I forgot to mention this point. At the Barcelona ISSE meeting, I had a
>discussion with Stephen Kent about the progression of this draft to RFC. We
>came to the conclusion that this draft should not be delayed any longer.
>Since the SIA extension is not defined in RFC 2459, we would have had to
>wait until "son-of-RFC 2459" is published. However, we did not wanted to
>hold the draft until "son-of-RFC 2459" got its own RFC number.
>
>Since the SIA was not mandatory to implement, it has been suppressed. We now
>have two options:
>
>1) either to re-incorporate it when the TSP Proposed Standard will move to
>Standard,
>2) or define this extension directly in "son-of-RFC 2459" (Tim can you hear
>me ???)
>
>Regards,
>
>Denis
>
> > Regards,
> >
> > Francois
> > ___________________________________
> > Francois Rousseau
> > Director of Standards and Conformance
> > Chrysalis-ITS
> > 1688 Woodward Drive
> > Ottawa, Ontario, CANADA, K2C 3R7
> > [e-mail]      Tel. [phone] ext. 419
> > http://www.chrysalis-its.com     Fax. [phone]



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08676 for <[e-mail]>; Thu, 19 Oct 2000 12:15:13 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Thu, 19 Oct 2000 12:20:27 -0700
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 15:21:40 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: "Linn, John" <[e-mail]>, Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar Humenn wrote:
> 
> Hi Al,
> 
> The problem is that an Attribute Certificte Authority must be separate
> from a Identity Certificate Authority, because it has control over the
> attribute information. So, if we have the IDentity CA issues a certificate
> of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
> the Attribute Certificate Authority issues a new certificate (effectively
> cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
> difference to having a separate data structure?
> 
> Do you really think the correlation problem of a separate AC at the
> Relying Party is that easy?
> 
> Cheers,
> -Polar
> 
>

In THAT particular system it was, because everything chained back to
what was essentially a single trusted Root CA. (It was called a "Policy
Approving Authority" or PAA, but it was in effect a single
globally-trusted root.) And, name constraints were enforced throughout
the system, providing a guarantee that unless some CA screwed up
somewhere or a trusted human was an active attacker, every DN was indeed
unique. (And such a screw-up or attacker would ultimately be detectable
through other means.)

Now, in other scenarios which don't have such a strictly-enforced
policy, it's a different ballgame.  I've been dealing with it a lot
lately, though, because my company primarily sells two products, one of
which is a CA/PKI product and the other which is essentially an
Attribute Certificate/PMI product. When implemented properly, each
product is secure, and if they're integrated properly, the combination
is secure (for whatever values of "secure").  But if some customer wants
to do something new with them - which happens a lot, because attribute
certificates are so new in practice - we work carefully with them to
make sure that they're not doing anything foolish, or that will inhibit
the desired security level.

The bottom line on all of this is that there are ways to do things
"securely", and ways to do them "insecurely" for whatever definition of
"secure" you prefer.  What we need to do in the standards world is (1)
do the best we can to ensure that "secure" is possible with conformant
products; and (2) make clear where the risks lie.  I give a talk on
occasion whose theme is "standards are no substitute for proper system
engineering."  I really believe that.

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07918 for <[e-mail]>; Thu, 19 Oct 2000 11:51:11 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id OAA06074; Thu, 19 Oct 2000 14:52:10 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 19 Oct 2000 14:52:09 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: "Linn, John" <[e-mail]>, Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Al,

The problem is that an Attribute Certificte Authority must be separate
from a Identity Certificate Authority, because it has control over the
attribute information. So, if we have the IDentity CA issues a certificate
of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
the Attribute Certificate Authority issues a new certificate (effectively
cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
difference to having a separate data structure?

Do you really think the correlation problem of a separate AC at the
Relying Party is that easy?

Cheers,
-Polar

On Thu, 19 Oct 2000, Al Arsenault wrote:

> To further expand on John's comments:
> 
> "Linn, John" wrote:
> > 
> > Polar writes, excerpting:
> > 
> > > Quite frankly, I'd like to understand why attribute certificates are
> > > needed at all? Why not just put the attributes in the subject's PKC?
> > >
> > 
> > X.509 allows attributes to be stored in PKCs, specifically within the
> > subjectDirectoryAttributes element, as an alternative to representing them
> > within separate ACs.  Early in the development of the PKIX AC profile, I
> > suggested that PKIX also reflect this option.  This choice was unpopular in
> > discussion and therefore not adopted, partly because of concern (also
> > discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> > inclusion of attribute data within PKCs would imply a need for more frequent
> > revocation and partly because some environments dictate management of
> > identity vs. attribute data by separate authorities.  
> 
> AWA: It should also be noted that numerous contributors to PKIX
> (including myself, in a former life) have a lot of experience (10 years?
> longer?) with a very large, very expensive operational PKI that did
> exactly this - put all of the attributes - clearances, privileges, etc.
> - in the subjectDirectoryAttributes element of an X.509v3 certificate. 
> (Actually, that was the second iteration.  The first iteration, which
> was built prior to X.509v3 and thus used X.509v1 certificates, put all
> those attributes in the subjectPublicKey field.  My, that was fun!)
> Experience in that system indicated that a lot of those attributes
> changed very frequently - on the order of every few months, if the
> reorganizations were spinning out of control again, and on the order of
> every couple of years as a matter of business. When the system was
> small, this wasn't a major problem - you just revoked the old certs
> every time you reorganized and issued new ones.  But then this led to
> the situation that revocation checking got ugly - big CRLs or lots of
> real-time checking - and the number of certificates in the system at one
> time exploded.  There was a massive groundswell of support for moving to
> a structure whereby the actual PKC had information that was reasonably
> stable, and didn't normally change too often; and to find some other
> structure in which to put the "transient" information.  Attribute Certs
> seemed to fit the bill.
> 
> And, as John points out, there's also the issue of who controls the
> attributes.  As a general rule, the people who are responsible for
> certifying identities and issuing PKCs - often called the "Pass and
> Identification" people - have no jurisdiction over most of the
> attributes under consideration. So it was easier to have the Attribute
> Authority be the entity that actually controlled the attribute, instead
> of some CA doing it on the basis of "well, he said so."
> 
> Now, as John correctly points out, this case is in some ways unique, and
> the circumstances will not be the same in other situations.  I can
> easily conceive of situations in which attribute certificates do not add
> substantial value - several of my customers fit into that category right
> now.  But the structures were advanced and supported by some set of
> people because in actual experience it seemed to be the right answer.
> 
> 
> >These factors are
> > valid, though may apply in greater or lesser degree in different cases and
> > under different operational assumptions.  It's possible, I believe, that
> > representation of attributes in PKCs can be workable and effective in some
> > contexts, particularly if revocation is accomplished via on-line techniques
> > rather than via CRLs.
> > 
> 
> AWA: I agree, although I'm less convinced that OCSP-vice-CRLs is
> important.  I think it's more closely related to how often the attribute
> changes.
> 
> > --jl
> 
> 
> 
> 
> 			Al Arsenault
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07262 for <[e-mail]>; Thu, 19 Oct 2000 11:34:05 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Thu, 19 Oct 2000 11:39:19 -0700
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 14:40:34 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'Polar Humenn'" <[e-mail]>, Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To further expand on John's comments:

"Linn, John" wrote:
> 
> Polar writes, excerpting:
> 
> > Quite frankly, I'd like to understand why attribute certificates are
> > needed at all? Why not just put the attributes in the subject's PKC?
> >
> 
> X.509 allows attributes to be stored in PKCs, specifically within the
> subjectDirectoryAttributes element, as an alternative to representing them
> within separate ACs.  Early in the development of the PKIX AC profile, I
> suggested that PKIX also reflect this option.  This choice was unpopular in
> discussion and therefore not adopted, partly because of concern (also
> discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> inclusion of attribute data within PKCs would imply a need for more frequent
> revocation and partly because some environments dictate management of
> identity vs. attribute data by separate authorities.  

AWA: It should also be noted that numerous contributors to PKIX
(including myself, in a former life) have a lot of experience (10 years?
longer?) with a very large, very expensive operational PKI that did
exactly this - put all of the attributes - clearances, privileges, etc.
- in the subjectDirectoryAttributes element of an X.509v3 certificate. 
(Actually, that was the second iteration.  The first iteration, which
was built prior to X.509v3 and thus used X.509v1 certificates, put all
those attributes in the subjectPublicKey field.  My, that was fun!)
Experience in that system indicated that a lot of those attributes
changed very frequently - on the order of every few months, if the
reorganizations were spinning out of control again, and on the order of
every couple of years as a matter of business. When the system was
small, this wasn't a major problem - you just revoked the old certs
every time you reorganized and issued new ones.  But then this led to
the situation that revocation checking got ugly - big CRLs or lots of
real-time checking - and the number of certificates in the system at one
time exploded.  There was a massive groundswell of support for moving to
a structure whereby the actual PKC had information that was reasonably
stable, and didn't normally change too often; and to find some other
structure in which to put the "transient" information.  Attribute Certs
seemed to fit the bill.

And, as John points out, there's also the issue of who controls the
attributes.  As a general rule, the people who are responsible for
certifying identities and issuing PKCs - often called the "Pass and
Identification" people - have no jurisdiction over most of the
attributes under consideration. So it was easier to have the Attribute
Authority be the entity that actually controlled the attribute, instead
of some CA doing it on the basis of "well, he said so."

Now, as John correctly points out, this case is in some ways unique, and
the circumstances will not be the same in other situations.  I can
easily conceive of situations in which attribute certificates do not add
substantial value - several of my customers fit into that category right
now.  But the structures were advanced and supported by some set of
people because in actual experience it seemed to be the right answer.


>These factors are
> valid, though may apply in greater or lesser degree in different cases and
> under different operational assumptions.  It's possible, I believe, that
> representation of attributes in PKCs can be workable and effective in some
> contexts, particularly if revocation is accomplished via on-line techniques
> rather than via CRLs.
> 

AWA: I agree, although I'm less convinced that OCSP-vice-CRLs is
important.  I think it's more closely related to how often the attribute
changes.

> --jl




			Al Arsenault


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06057 for <[e-mail]>; Thu, 19 Oct 2000 10:56:59 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id NAA05974; Thu, 19 Oct 2000 13:57:57 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 19 Oct 2000 13:57:57 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "Linn, John" <[e-mail]>
cc: Dale Gustafson <[e-mail]>, [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 19 Oct 2000, Linn, John wrote:

> Polar writes, excerpting: 
> 
> > Quite frankly, I'd like to understand why attribute certificates are
> > needed at all? Why not just put the attributes in the subject's PKC?
> > 
> 
> X.509 allows attributes to be stored in PKCs, specifically within the
> subjectDirectoryAttributes element, as an alternative to representing them
> within separate ACs.  Early in the development of the PKIX AC profile, I
> suggested that PKIX also reflect this option.  This choice was unpopular in
> discussion and therefore not adopted, partly because of concern (also
> discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> inclusion of attribute data within PKCs would imply a need for more frequent
> revocation and partly because some environments dictate management of
> identity vs. attribute data by separate authorities.  These factors are
> valid, though may apply in greater or lesser degree in different cases and
> under different operational assumptions.  It's possible, I believe, that
> representation of attributes in PKCs can be workable and effective in some
> contexts, particularly if revocation is accomplished via on-line techniques
> rather than via CRLs. 

I see your point. However, since one may have *many* certificates relating
to a public key, or a even a DN, there is no need to revoke the "previous"
certificates.

In the needs for "other" authorities to issue attributes, they can issue
different certificates with the same public key, and quite possibly the
same DN (but let's not get into that :), and not have to revoke the
original certificate.

And in this day in age, I agree with you that revocation should be
accomplished via on-line techniques and NOT CRLs. They just go back to the
day where your credit card was looked up on a book at the cash register.
Still the cashier called in any over $50. My credit card now gets get
checked on-line all the time, even if I spend 64 cents on a cup of coffee.

Cheers,
-Polar

> 
> --jl
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA04887 for <[e-mail]>; Thu, 19 Oct 2000 10:22:58 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Oct 2000 17:26:36 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA28570; Thu, 19 Oct 2000 13:24:41 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <RNKLWXLA>; Thu, 19 Oct 2000 13:28:07 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Polar Humenn'" <[e-mail]>, Dale Gustafson <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 19 Oct 2000 13:27:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Polar writes, excerpting: 

> Quite frankly, I'd like to understand why attribute certificates are
> needed at all? Why not just put the attributes in the subject's PKC?
> 

X.509 allows attributes to be stored in PKCs, specifically within the
subjectDirectoryAttributes element, as an alternative to representing them
within separate ACs.  Early in the development of the PKIX AC profile, I
suggested that PKIX also reflect this option.  This choice was unpopular in
discussion and therefore not adopted, partly because of concern (also
discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
inclusion of attribute data within PKCs would imply a need for more frequent
revocation and partly because some environments dictate management of
identity vs. attribute data by separate authorities.  These factors are
valid, though may apply in greater or lesser degree in different cases and
under different operational assumptions.  It's possible, I believe, that
representation of attributes in PKCs can be workable and effective in some
contexts, particularly if revocation is accomplished via on-line techniques
rather than via CRLs. 

--jl


Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03097 for <[e-mail]>; Thu, 19 Oct 2000 09:06:47 -0700 (PDT)
Received: (qmail 19322656 invoked from network); 19 Oct 2000 16:11:59 -0000
Received: from e004.dhcp212-17.cybercable.fr (HELO home) ([212.198.17.4]) (envelope-sender <[e-mail]>) by camus.cybercable.fr (qmail-ldap-1.03) with SMTP for <[e-mail]>; 19 Oct 2000 16:11:59 -0000
From: "Stephen McConnell" <[e-mail]>
To: "Polar Humenn" <[e-mail]>, "Dale Gustafson" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Electronic Commerce DTF" <[e-mail]>
Subject: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)
Date: Thu, 19 Oct 2000 18:10:13 +0200
Message-ID: <001201c039e7$10421a10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800

Polar et. al.

Some comments from an OMG/EC perspective:

	- EC has a significant subscribed list of end-user
	  organisations that will end up using this stuff,
	  possibly not in the pure IETF model of data
	  structures, but in terms of the real application
        level problems based on the emerging CSIv2
	  OMG's cross-domain security interoperability spec).

  	- Members of EC are watching closely the CSIv2 process,
	  because we know the CORBA security doesn't work beyond a
	  single enterprise, and the CSIv2 is the silver bullet.
	  Because CSIv2 depends on Attribute Certificates, this
	  means  that the strength of CSIv2 is limited by the
	  strength of X509 (2000).  If there are holes in X509
	  (2000) it means that there are holes in CSIv2.  CSIv2 has
	  been adopted. It will be presumably enter a finalisation
	  phase during the next meeting.  Based on several emails
	  sent out on this thread, my conclusion is that
	  X509 (2000) isn't ready for prime time - adding a
	  "by-the-way there are security holes and there are
	  optional vendor fixes (if they want to) but, ooh,
	  by the way, you, the customer, you should be selecting
	  your provider on the basis your technical due-diligence"
	  (etc.) ... simply sucks. But lets look at what this means
	  in terms of the impact on CSIv2:

	  1. CSIv2 is dependent on the strength of X509 (2000), in
	     particular, the dependence that CSIv2 places on
	     Attribute Certificates

	  2. Holes have been identified by Polar in the Attribute
	     Certificate model and confirmed by several other
	     authorities on this list.

	  3. What I'm missing here is this thread is the distinction
	     between the following:

		   OMG CSIv2 functionality

	            - why CSIv2 needs Attribute Certificates
			  in the first place ?

			- is there any reason why CSIv2 cannot use
			  X509 Classic instead ?

		   OMG PKI Service functionality

			- currently defines mechanisms for
			  certificate issue and verification,

			- is missing an extendable valuetype
			  definition of a certificate to sync X509
			  and CSIv2 with the PKI service

		   Application level functionality

			- getting a clear distinction between
			  application level (which is where I would
		  	  have through Attribute Certificates are
			  relevant) as opposed to CSIv2 service
			  functionality.

Cheers, Steve.

P.S.  Please consider this email as a vote for fully expanded acronyms.  For
myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
Consulting"!



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27397 for <[e-mail]>; Thu, 19 Oct 2000 08:11:11 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27590; Thu, 19 Oct 2000 17:21:51 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12484; Thu, 19 Oct 2000 17:15:20 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 17:15:23 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail], Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: TSP. Version 10, Removal of SIA Extension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Francois,

> Hi Denis,
> 
> I just noticed that in the latest draft you completely remove from Section
> 2.3 the text about a TSA's certificate possibly containing a Subject
> Information Access (SIA) extension. From the many comments received during
> last call against the previous draft, I did not recall anyone asking for
> the SIA extension to be removed.
> 
> Did I miss anything or is there a particular reason why the SIA extension
> was removed?

You read the draft very carefully, congratulations !

I forgot to mention this point. At the Barcelona ISSE meeting, I had a
discussion with Stephen Kent about the progression of this draft to RFC. We
came to the conclusion that this draft should not be delayed any longer.
Since the SIA extension is not defined in RFC 2459, we would have had to
wait until "son-of-RFC 2459" is published. However, we did not wanted to
hold the draft until "son-of-RFC 2459" got its own RFC number.

Since the SIA was not mandatory to implement, it has been suppressed. We now
have two options:

1) either to re-incorporate it when the TSP Proposed Standard will move to
Standard,
2) or define this extension directly in "son-of-RFC 2459" (Tim can you hear
me ???)

Regards,

Denis

> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [e-mail]      Tel. [phone] ext. 419
> http://www.chrysalis-its.com     Fax. [phone]


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27095 for <[e-mail]>; Thu, 19 Oct 2000 08:07:10 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA05573; Thu, 19 Oct 2000 11:08:10 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 19 Oct 2000 11:08:09 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Dale Gustafson <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Doug et al,

BTW, I took OMG Electronic Commerce Group <[e-mail]> off the list,
because Doug Moss complained.

On Thu, 19 Oct 2000, Dale Gustafson wrote:

> Polar,
> 
> To attempt to get at your concern about what happens when the holder needs to
> update their signature key and certificate -- perhaps we could consider adding an
> optional URI pointer to the AC that tells the RP where to find the AA's "key
> update" service.

I don't think it's my concern any longer. I cannot see how an AC can
reference an entity by a DN, because that DN has no hope of being unique
unless there is a ubiquitous TRUSTED directory. That is impossible.

An AC can only reference a public key. If the public key is updated, the
AC must be updated as well.

Quite frankly, I'd like to understand why attribute certificates are
needed at all? Why not just put the attributes in the subject's PKC?

The correlation problem is more complex than certificate verification
itself. The certificate chain verification problem is so complex servers
were invented to do it for us, creating yet another kink in the trust
model. Is there now a need to create server that verifies the PK
certificate chain and AC and its certificate chain together?

I've talked with a couple of vendors so far, and they just create
extensions in their X.509 certificates for various things concerning
access control and auditing. This seems to be much cheaper. Also, that way
they don't have to change anything, like SSL stacks, and other things that
just look at PK certificate particulars. Relying party software that
doesn't pay attention to the new attributes also doesn't have to be
re-engineered. An if it does, it only has to look in the PKC, and not
other information delivered by other protocols, i.e. the AC.

Is the only real reason for the attribute certificate to issue attributes
to identifiers that do not have public/private keys, such as a Kerberos
name, or an email name?

Cheers,
-Polar

> If requested by an RP, the service would be able to, given a particular AC,
> provide a newer PKC (or list of PKCs) that can be used to verify the holder's
> digital signature.  Conceivably, this is one method that would allow an AC to
> reliably reference PKCs that do not exist at the time the AC is issued.
> 
> Questions:
> ----------
> 
> Is this additional capability important enough that a (perhaps not-free) service
> would be a viable solution ?
> 
> Is it almost always better / cheaper / faster to simply reissue the AC(s)
> whenever the holder's PKC is updated / replaced?
> 
> Are there technical reasons why this approach wouldn't work?
> 
> Best Regards,
> 
> Dale Gustafson
> 
> 
> Polar Humenn wrote:
> 
> > Tom,
> >
> > I like your suggestion of tying the AC to a particular certificate, or a
> > effectively its public key.
> >
> > The requirements I stated in my proposed text for using only DNs to
> > identify the Holder or its issuer are flawed.
> >
> > They required the AA to decide the root CA certificate was used to
> > identify the Holder along with itself , i.e. a single PKI as Carlisle
> > suggested.  Unfortunately, I think that is not such a good idea since
> > cross-certifications can be all over the place. Therefore, that
> > requirement for using only DNs to identify Holders isn't even good enough.
> >
> > The AA may not have any idea of who the RPs are or will be. (I think this
> > was mentioned before). Specifically, I can imagine, that whoever the AA
> > thinks is its root CA may not be what the RP thinks the AA's root CA is
> > because of cross-certification. Correct? If this is the case, how could
> > the RP really tell what the AA thought the root of its PKI is?
> >
> > In other words, the RP would have to find the root CA certificate that was
> > used by the AA to make its decision that the Holder's DN was actually
> > within the AA's PKI. Unfortunately that is on the other side of the
> > stockade fence. The RP may have the "can't get there from here" problem
> > with respect to finding the exact root CA cert that the AA used to make
> > its decision about the Holder being in its own PKI.
> >
> > The AC has to point to the Holder PKC, as Tom's suggestion point out, so
> > the RP emphatically knows who has been authorized by the AC.
> >
> > It seems that one of the key factors here that is causing the problems is
> > that is NOT desirable to restrict the AC to an entity certificate (or
> > really its public key). This seems to be the crux of the problem. If the
> > AC were restricted to the public key, then the problem goes away.
> >
> > I am tending to agree with Bob Juenema that affixing privileges to names
> > in this arena is pretty dangerous. Especially for critical applications.
> > At least there is that option of basing the AC on the public key of the
> > holder. Although unfortunately, the profile says that it doesn't have to
> > be supported.
> >
> > So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
> > recursively consistent naming constraints, a reality? If not then the AC
> > cannot name the Holder via DN unless it knows who the RPs will be and
> > knows that the RPs know who the Holders will eventually. That would be a
> > highly controlled, closed, and protected environment.
> >
> > I understand how it's suppose to work. Mathematically, there should be a
> > least upper bound for all AA, RP, and Holders based on public key
> > signatures through the proper cross-certifications amongst all parties.
> > Names are completely factored out of that reasoning, only public keys
> > matter.
> >
> > In practice, I don't see ACs with just DNs working all the time because of
> > naming conflicts, and I don't see a way to make that work unless all
> > parties are guarranteed to work in environmental constraints, perhaps
> > by legal means instead of technical ones.
> >
> > I'll regretfully back off, as I cannot really see how to make it work
> > verifiably in general.
> >
> > The solution in an wide open environment must be to always bind the AC to
> > the public key. Alternatively, the only reason I can see to bind the AC to
> > the holders PKC is to ensure proper advisory information is used, such as
> > in auditing with the subject Alt names, and other possibly other policy
> > constraints. Is that correct?
> >
> > Cheers,
> > -Polar
> >
> > On Wed, 18 Oct 2000 [e-mail] wrote:
> >
> > >      Since ObjectDigestInfo is already in the standard, those new syntaxes
> > > I suggested earlier today are redundant, and I hope that I will be forgiven
> > > for them.  IMO the correct thing to do in the profile is to recommend that
> > > all uses of baseCertificateID SHOULD also use the objectDigestInfo field
> > > with digestedObjectType publicKeyCert.  In those cases where entityName is
> > > used with underlying PKC authentication but it is the AA's intent that only
> > > one PKC be permitted, the objectDigestInfo field with digestedObjectType
> > > publicKeyCert SHOULD also be used.
> > >      Do we need a new extension to permit the listing of multiple PKC's (by
> > > cert digest) for the same entityName when it is the AA's intent to allow
> > > the use of such for a single AC and all the intended PKC's already exist?
> > >
> > >           Tom Gindin
> > >
> > >
> > > Russ Housley <[e-mail]> on 10/18/2000 02:23:10 PM
> > >
> > > To:   Polar Humenn <[e-mail]>
> > > cc:   [e-mail], [e-mail], [e-mail], [e-mail]
> > > Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> > >
> > >
> > >
> > > An attribute or extension is the only acceptable approach to me, unless we
> > > coordinate with X.509 agrees to make the same change to the base syntax.
> > >
> > > Russ
> > >
> > >
> > > At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > >On Wed, 18 Oct 2000, Russ Housley wrote:
> > > >
> > > > > Polar:
> > > > >
> > > > > You are proposing syntax that is no longer compatible with X.509.  I am
> > > > > very unhappy with such a deviation.
> > > >
> > > >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > > >Do you feel that an attribute extension would be warranted instead?
> > > >
> > > >Cheers,
> > > >-Polar
> > > >
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > > > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > > > > >
> > > > > > >> [SNIP]
> > > > > > >    ESSCertID ::=  SEQUENCE {
> > > > > > >         certHash                 Hash,
> > > > > > >         issuerSerial             IssuerSerial OPTIONAL
> > > > > > >    }
> > > > > > >
> > > > > > > and, in that case, having IssuerSerial present.
> > > > > > >
> > > > > > > Then we would need some additional text in the explanations to say
> > > > that the
> > > > > > > hash of the certificate should also be tested.
> > > > > > >
> > > > > > > In this way, at the time of verification, there is no ambiguity
> > > > about the
> > > > > > > link between the AC and the certificate, even if the CA has the
> > > same
> > > > > > name as
> > > > > > > another CA certified from a different root key.
> > > > > >
> > > > > >Dennis,
> > > > > >
> > > > > >I still think that this solution doesn't quite solve the problem, but
> > > is a
> > > > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > > > >yours. So I'll sort of work off of that.
> > > > > >
> > > > > >The fact is that the entityName option still contains a DN and the RP
> > > MUST
> > > > > >be prepared to accept it. However, on what conditions should the RP
> > > accept
> > > > > >the Holder as a DN? (Especially if this verification is offloaded to
> > > some
> > > > > >remote verification engine).
> > > > > >
> > > > > >Perhaps there is a way to word the USE of a DN entityName?
> > > > > >
> > > > > >When using an AC that contains the Holder specification as a DN
> > > entityName
> > > > > >option, the DN MUST verifiable and uniquely name an entity within the
> > > PKI
> > > > > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
> > > MUST
> > > > > >ONLY create AttributeCertificates with the Holder as a DN entityName
> > > in
> > > > > >this fashion. This constraint is subject to the entire PKI for which
> > > the
> > > > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > > > >verification is subject to the trust the RP places in the AA and its
> > > PKI
> > > > > >together to conform to this behavior.
> > > > > >
> > > > > >[Note: this approach still does not solve the problem that Denis
> > > brings up
> > > > > >below as comment 43. A subordinate CA may be compromised within the
> > > PKI of
> > > > > >the AA and create impostor certificates, grabbing privileges.]
> > > > > >
> > > > > >Therefore, it would still probably be better to use the Issuer/Serial
> > > and
> > > > > >a hash of the Issuer's certificate, even if in the same PKI.
> > > > > >
> > > > > >Of course, when an application authenticates to an RP using PKCs this
> > > ties
> > > > > >the authorization to a particular certificate. Apparently that was not
> > > > > >desirable due to the effect of key rollover and new certificates being
> > > > > >issued to the same subject entity.
> > > > > >
> > > > > >However, I think that if as Carlise pointed out, that if the DN is
> > > only
> > > > > >used in the case of a single trusted Root, then everything will be
> > > fine.
> > > > > >
> > > > > >So, as Russ asked me to propose text, here it goes:
> > > > > >
> > > > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > > > >that is already defined in the document for the certificate Hash).
> > > > > >
> > > > > >Section 4.1:
> > > > > >
> > > > > >    Holder ::= SEQUENCE {
> > > > > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > > > > >                 -- the issuer and serial number of
> > > > > >                 -- the holder's Public Key Certificate
> > > > > >         entityName          [1] GeneralNames OPTIONAL,
> > > > > >                 -- the name of the claimant or role
> > > > > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > > > > >                 -- if present, version must be v2
> > > > > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > > > > >    }
> > > > > >
> > > > > >    IssuerSerialCertID ::=  SEQUENCE {
> > > > > >         isserCertDigest          ObjectDigestInfo,
> > > > > >         issuerSerial             IssuerSerial
> > > > > >    }
> > > > > >
> > > > > >In section 4.2.2 Holder add:
> > > > > >
> > > > > >When using an entityName that contains a DN, the DN MUST verifiably
> > > and
> > > > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> > > by
> > > > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > > > >MUST ONLY create AttributeCertificates with the Holder as a DN
> > > entityName
> > > > > >in this fashion. This constraint is subject to the entire PKI for
> > > which
> > > > > >the AC issuer belongs to behave in its creation of unique DNs.
> > > Therefore,
> > > > > >verification is also subject to the trust the RP places in the AC
> > > issuer's
> > > > > >PKI to conform to this behavior.
> > > > > >
> > > > > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
> > > 1,
> > > > > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > > > > >
> > > > > >To be valid an AC MUST satisfy all of the following:
> > > > > >
> > > > > >1. The AC signature MUST be cryptographically correct, and the AC
> > > > > >    issuer's entire PKC certification path MUST be verified in
> > > > > >    accordance with [PKIXPROF].
> > > > > >
> > > > > >2. When the AC holder is named by a DN using the entityName option,
> > > > > >    the holder's PK certificate MUST be uniquely found under the same
> > > root
> > > > > >    CA as the AC issuer. The entire certification path of that PKC
> > > MUST be
> > > > > >    verified in accordance with [PKIXPROF].
> > > > > >
> > > > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > > > >    certificate MUST be uniquely found under the same root CA as
> > > > > >    the AC issuer. The entire certificate path of that PKC MUST
> > > > > >    be verified in accordance with [PKIXPROF].
> > > > > >
> > > > > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > > > > >    named holder issuer's PKC must be found, and that PKC MUST
> > > correctly
> > > > > >    digest to the digest value contained in the
> > > verifiedBaseCertificateID.
> > > > > >    The entire certificate path starting with the holder's PKC and the
> > > PKC
> > > > > >    of the issuer the holder's PKC MUST be verified in accordance
> > > > > >    with [PKIXPROF].
> > > > > >
> > > > > >.....
> > > > > >
> > > > > >Note: there is *still* a problem with AC targeting and proxying using
> > > > > >just DNs.
> > > > > >
> > > > > >Cheers,
> > > > > >-Polar
> > > > > >
> > > > > >
> > > > > >-------------------------------------------------------------------
> > > > > >Polar Humenn                  Adiron, LLC
> > > > > >mailto:[e-mail]      2-212 CST
> > > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > > >Fax:   [phone]           http://www.adiron.com
> > > > >
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]      2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com
> > >
> > >
> > >
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26441 for <[e-mail]>; Thu, 19 Oct 2000 07:49:57 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <4VMHWPJ4>; Thu, 19 Oct 2000 10:55:14 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Thu, 19 Oct 2000 10:55:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C039DC.962B91C0"

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_01C039DC.962B91C0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Denis,

I just noticed that in the latest draft you completely remove from Section
2.3 the text about a TSA's certificate possibly containing a Subject
Information Access (SIA) extension. From the many comments received during
last call against the previous draft, I did not recall anyone asking for the
SIA extension to be removed.

Did I miss anything or is there a particular reason why the SIA extension
was removed?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[e-mail]      Tel. [phone] ext. 419
http://www.chrysalis-its.com     Fax. [phone]


------_=_NextPart_001_01C039DC.962B91C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: TSP. Version 10, Removal of SIA Extension</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Denis,</FONT>
</P>

<P><FONT SIZE=3D2>I just noticed that in the latest draft you =
completely remove from Section 2.3 the text about a TSA's certificate =
possibly containing a Subject Information Access (SIA) extension. From =
the many comments received during last call against the previous draft, =
I did not recall anyone asking for the SIA extension to be =
removed.</FONT></P>

<P><FONT SIZE=3D2>Did I miss anything or is there a particular reason =
why the SIA extension was removed?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[e-mail]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
[phone] ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. [phone]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C039DC.962B91C0--


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24294 for <[e-mail]>; Thu, 19 Oct 2000 06:51:19 -0700 (PDT)
Received: from bpsi.net (port413.bpsi.net [209.54.245.213]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9JDqYD12364; Thu, 19 Oct 2000 08:52:34 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 08:50:10 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: [e-mail], Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar,

To attempt to get at your concern about what happens when the holder needs to
update their signature key and certificate -- perhaps we could consider adding an
optional URI pointer to the AC that tells the RP where to find the AA's "key
update" service.

If requested by an RP, the service would be able to, given a particular AC,
provide a newer PKC (or list of PKCs) that can be used to verify the holder's
digital signature.  Conceivably, this is one method that would allow an AC to
reliably reference PKCs that do not exist at the time the AC is issued.

Questions:
----------

Is this additional capability important enough that a (perhaps not-free) service
would be a viable solution ?

Is it almost always better / cheaper / faster to simply reissue the AC(s)
whenever the holder's PKC is updated / replaced?

Are there technical reasons why this approach wouldn't work?

Best Regards,

Dale Gustafson


Polar Humenn wrote:

> Tom,
>
> I like your suggestion of tying the AC to a particular certificate, or a
> effectively its public key.
>
> The requirements I stated in my proposed text for using only DNs to
> identify the Holder or its issuer are flawed.
>
> They required the AA to decide the root CA certificate was used to
> identify the Holder along with itself , i.e. a single PKI as Carlisle
> suggested.  Unfortunately, I think that is not such a good idea since
> cross-certifications can be all over the place. Therefore, that
> requirement for using only DNs to identify Holders isn't even good enough.
>
> The AA may not have any idea of who the RPs are or will be. (I think this
> was mentioned before). Specifically, I can imagine, that whoever the AA
> thinks is its root CA may not be what the RP thinks the AA's root CA is
> because of cross-certification. Correct? If this is the case, how could
> the RP really tell what the AA thought the root of its PKI is?
>
> In other words, the RP would have to find the root CA certificate that was
> used by the AA to make its decision that the Holder's DN was actually
> within the AA's PKI. Unfortunately that is on the other side of the
> stockade fence. The RP may have the "can't get there from here" problem
> with respect to finding the exact root CA cert that the AA used to make
> its decision about the Holder being in its own PKI.
>
> The AC has to point to the Holder PKC, as Tom's suggestion point out, so
> the RP emphatically knows who has been authorized by the AC.
>
> It seems that one of the key factors here that is causing the problems is
> that is NOT desirable to restrict the AC to an entity certificate (or
> really its public key). This seems to be the crux of the problem. If the
> AC were restricted to the public key, then the problem goes away.
>
> I am tending to agree with Bob Juenema that affixing privileges to names
> in this arena is pretty dangerous. Especially for critical applications.
> At least there is that option of basing the AC on the public key of the
> holder. Although unfortunately, the profile says that it doesn't have to
> be supported.
>
> So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
> recursively consistent naming constraints, a reality? If not then the AC
> cannot name the Holder via DN unless it knows who the RPs will be and
> knows that the RPs know who the Holders will eventually. That would be a
> highly controlled, closed, and protected environment.
>
> I understand how it's suppose to work. Mathematically, there should be a
> least upper bound for all AA, RP, and Holders based on public key
> signatures through the proper cross-certifications amongst all parties.
> Names are completely factored out of that reasoning, only public keys
> matter.
>
> In practice, I don't see ACs with just DNs working all the time because of
> naming conflicts, and I don't see a way to make that work unless all
> parties are guarranteed to work in environmental constraints, perhaps
> by legal means instead of technical ones.
>
> I'll regretfully back off, as I cannot really see how to make it work
> verifiably in general.
>
> The solution in an wide open environment must be to always bind the AC to
> the public key. Alternatively, the only reason I can see to bind the AC to
> the holders PKC is to ensure proper advisory information is used, such as
> in auditing with the subject Alt names, and other possibly other policy
> constraints. Is that correct?
>
> Cheers,
> -Polar
>
> On Wed, 18 Oct 2000 [e-mail] wrote:
>
> >      Since ObjectDigestInfo is already in the standard, those new syntaxes
> > I suggested earlier today are redundant, and I hope that I will be forgiven
> > for them.  IMO the correct thing to do in the profile is to recommend that
> > all uses of baseCertificateID SHOULD also use the objectDigestInfo field
> > with digestedObjectType publicKeyCert.  In those cases where entityName is
> > used with underlying PKC authentication but it is the AA's intent that only
> > one PKC be permitted, the objectDigestInfo field with digestedObjectType
> > publicKeyCert SHOULD also be used.
> >      Do we need a new extension to permit the listing of multiple PKC's (by
> > cert digest) for the same entityName when it is the AA's intent to allow
> > the use of such for a single AC and all the intended PKC's already exist?
> >
> >           Tom Gindin
> >
> >
> > Russ Housley <[e-mail]> on 10/18/2000 02:23:10 PM
> >
> > To:   Polar Humenn <[e-mail]>
> > cc:   [e-mail], [e-mail], [e-mail], [e-mail]
> > Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> >
> >
> >
> > An attribute or extension is the only acceptable approach to me, unless we
> > coordinate with X.509 agrees to make the same change to the base syntax.
> >
> > Russ
> >
> >
> > At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> > >On Wed, 18 Oct 2000, Russ Housley wrote:
> > >
> > > > Polar:
> > > >
> > > > You are proposing syntax that is no longer compatible with X.509.  I am
> > > > very unhappy with such a deviation.
> > >
> > >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > >Do you feel that an attribute extension would be warranted instead?
> > >
> > >Cheers,
> > >-Polar
> > >
> > > >
> > > > Russ
> > > >
> > > >
> > > >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > > > >
> > > > > >> [SNIP]
> > > > > >    ESSCertID ::=  SEQUENCE {
> > > > > >         certHash                 Hash,
> > > > > >         issuerSerial             IssuerSerial OPTIONAL
> > > > > >    }
> > > > > >
> > > > > > and, in that case, having IssuerSerial present.
> > > > > >
> > > > > > Then we would need some additional text in the explanations to say
> > > that the
> > > > > > hash of the certificate should also be tested.
> > > > > >
> > > > > > In this way, at the time of verification, there is no ambiguity
> > > about the
> > > > > > link between the AC and the certificate, even if the CA has the
> > same
> > > > > name as
> > > > > > another CA certified from a different root key.
> > > > >
> > > > >Dennis,
> > > > >
> > > > >I still think that this solution doesn't quite solve the problem, but
> > is a
> > > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > > >yours. So I'll sort of work off of that.
> > > > >
> > > > >The fact is that the entityName option still contains a DN and the RP
> > MUST
> > > > >be prepared to accept it. However, on what conditions should the RP
> > accept
> > > > >the Holder as a DN? (Especially if this verification is offloaded to
> > some
> > > > >remote verification engine).
> > > > >
> > > > >Perhaps there is a way to word the USE of a DN entityName?
> > > > >
> > > > >When using an AC that contains the Holder specification as a DN
> > entityName
> > > > >option, the DN MUST verifiable and uniquely name an entity within the
> > PKI
> > > > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
> > MUST
> > > > >ONLY create AttributeCertificates with the Holder as a DN entityName
> > in
> > > > >this fashion. This constraint is subject to the entire PKI for which
> > the
> > > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > > >verification is subject to the trust the RP places in the AA and its
> > PKI
> > > > >together to conform to this behavior.
> > > > >
> > > > >[Note: this approach still does not solve the problem that Denis
> > brings up
> > > > >below as comment 43. A subordinate CA may be compromised within the
> > PKI of
> > > > >the AA and create impostor certificates, grabbing privileges.]
> > > > >
> > > > >Therefore, it would still probably be better to use the Issuer/Serial
> > and
> > > > >a hash of the Issuer's certificate, even if in the same PKI.
> > > > >
> > > > >Of course, when an application authenticates to an RP using PKCs this
> > ties
> > > > >the authorization to a particular certificate. Apparently that was not
> > > > >desirable due to the effect of key rollover and new certificates being
> > > > >issued to the same subject entity.
> > > > >
> > > > >However, I think that if as Carlise pointed out, that if the DN is
> > only
> > > > >used in the case of a single trusted Root, then everything will be
> > fine.
> > > > >
> > > > >So, as Russ asked me to propose text, here it goes:
> > > > >
> > > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > > >that is already defined in the document for the certificate Hash).
> > > > >
> > > > >Section 4.1:
> > > > >
> > > > >    Holder ::= SEQUENCE {
> > > > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > > > >                 -- the issuer and serial number of
> > > > >                 -- the holder's Public Key Certificate
> > > > >         entityName          [1] GeneralNames OPTIONAL,
> > > > >                 -- the name of the claimant or role
> > > > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > > > >                 -- if present, version must be v2
> > > > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > > > >    }
> > > > >
> > > > >    IssuerSerialCertID ::=  SEQUENCE {
> > > > >         isserCertDigest          ObjectDigestInfo,
> > > > >         issuerSerial             IssuerSerial
> > > > >    }
> > > > >
> > > > >In section 4.2.2 Holder add:
> > > > >
> > > > >When using an entityName that contains a DN, the DN MUST verifiably
> > and
> > > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> > by
> > > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > > >MUST ONLY create AttributeCertificates with the Holder as a DN
> > entityName
> > > > >in this fashion. This constraint is subject to the entire PKI for
> > which
> > > > >the AC issuer belongs to behave in its creation of unique DNs.
> > Therefore,
> > > > >verification is also subject to the trust the RP places in the AC
> > issuer's
> > > > >PKI to conform to this behavior.
> > > > >
> > > > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
> > 1,
> > > > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > > > >
> > > > >To be valid an AC MUST satisfy all of the following:
> > > > >
> > > > >1. The AC signature MUST be cryptographically correct, and the AC
> > > > >    issuer's entire PKC certification path MUST be verified in
> > > > >    accordance with [PKIXPROF].
> > > > >
> > > > >2. When the AC holder is named by a DN using the entityName option,
> > > > >    the holder's PK certificate MUST be uniquely found under the same
> > root
> > > > >    CA as the AC issuer. The entire certification path of that PKC
> > MUST be
> > > > >    verified in accordance with [PKIXPROF].
> > > > >
> > > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > > >    certificate MUST be uniquely found under the same root CA as
> > > > >    the AC issuer. The entire certificate path of that PKC MUST
> > > > >    be verified in accordance with [PKIXPROF].
> > > > >
> > > > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > > > >    named holder issuer's PKC must be found, and that PKC MUST
> > correctly
> > > > >    digest to the digest value contained in the
> > verifiedBaseCertificateID.
> > > > >    The entire certificate path starting with the holder's PKC and the
> > PKC
> > > > >    of the issuer the holder's PKC MUST be verified in accordance
> > > > >    with [PKIXPROF].
> > > > >
> > > > >.....
> > > > >
> > > > >Note: there is *still* a problem with AC targeting and proxying using
> > > > >just DNs.
> > > > >
> > > > >Cheers,
> > > > >-Polar
> > > > >
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]      2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > > >
> > >
> > >-------------------------------------------------------------------
> > >Polar Humenn                  Adiron, LLC
> > >mailto:[e-mail]      2-212 CST
> > >Phone: [phone]           Syracuse, NY 13244-4100
> > >Fax:   [phone]           http://www.adiron.com
> >
> >
> >
> >
>
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14339 for <[e-mail]>; Thu, 19 Oct 2000 01:26:07 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA19848; Thu, 19 Oct 2000 10:36:41 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA18902; Thu, 19 Oct 2000 10:30:01 +0200
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 10:30:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Polar Humenn <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> An attribute or extension is the only acceptable approach to me, unless we
> coordinate with X.509 agrees to make the same change to the base syntax.

Since you said ... "unless we coordinate with X.509 agrees to make the same
change to the base syntax", there are two solutions, not a single acceptable
approach. On that basis, I agree with you.

We can certainly attempt to coordinate with ISO, since the Orlando meeting
is coming. I am a member of the ISO defect report team and can certainly
bring the attention of the ISO group on that topic. :-)

Denis

> Russ


Received: from getafix.fcpl.co.in (getafix.fcpl.co.in [196.1.104.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA12546 for <[e-mail]>; Thu, 19 Oct 2000 00:21:57 -0700 (PDT)
Received: from risk (risk.fcpl.co.in [196.1.104.25]) by getafix.fcpl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V1KN2LJR; Thu, 19 Oct 2000 12:58:44 +0530
Message-ID: <017d01c0399d$b8c48730$[e-mail]>
From: "Parag Namjoshi" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: TSP. Version 10
Date: Thu, 19 Oct 2000 12:55:13 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Hi Denis,

A few minor details.

1. The PKIXTSP ASN.1 module does not define/import PKIFreeText.
2. The text on page 8 refers to PolicyInformation, which is no longer used.
I believe text should refer to TSAPolicyId instead. (ASN.1 module imports
PolicyInformation too.)

Parag.

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "IETF-PXIX" <[e-mail]>
Sent: Friday, October 13, 2000 4:32 PM
Subject: TSP. Version 10


>
> A new version of the Time Stamping Protocol has been placed on the web
> server. A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt
>
> This version addresses the comments received during the IESG last call
> period.
>
> Besides the changes made to accommodate the 24 comments raised by Russ
> Housley, the abstract and the introduction have been modified, by myself
and
> Steve Kent, in order to address some of the concerns raised by Todd
Glassey.
>
> If there are no major editorial errors, this version should (hopefully) be
> the version to be published as an RFC. Should there be a few minor errors
> left, please tell me, since they can still be corrected directly by myself
> when the RFC editor transforms the document into an RFC (there a 48 hours
> time window to do so).
>
> FYI, the abstract and the introduction are now as follows:
>
> Abstract
>
> A time stamping service allows to prove that a datum existed before
> a particular time. This document describes the format of a request
> sent to a Time Stamping Authority (TSA) and of the response that is
> returned. It also establishes several security-relevant requirements
> for TSA operation, with regards to processing requests to generate
> responses. A TSA may be operated as a Trusted Third Party (TTP)
> service, though other operational models may be appropriate, e.g. an
> organization might require a TSA for internal time stamping purposes.
>
> Non-repudiation services [ISONR] require the ability to establish the
> existence of data before specified times. This protocol may be used as
> a building block to support such services. An example of how to prove
> that a digital signature was generated during the validity period of
> a public key certificate is given in an annex.
>
> (...)
>
> 1.  Introduction
>
> (...)
>
> This standard does not establish overall security requirements for
> TSA operation, just like other PKIX standards do not establish such
> requirements for CA operation. Rather, it is anticipated that a TSA
> will make know to prospective clients the policies it implements to
> ensure accurate time stamp generation, and clients will make use of
> the services of a TSA only if they are satisfied that these policies
> meet their needs.
>
>
> Denis



Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08443 for <[e-mail]>; Wed, 18 Oct 2000 21:18:20 -0700 (PDT)
Received: by florida.melco.co.jp (florida) id NAA23221; Thu, 19 Oct 2000 13:17:34 +0900 (JST)
Received: by mailgw.melco.co.jp (mailgw) id NAA24099; Thu, 19 Oct 2000 13:18:05 +0900 (JST)
Received: by mr02.melco.co.jp (mr02) id NAA09596; Thu, 19 Oct 2000 13:18:04 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id NAA28346; Thu, 19 Oct 2000 13:18:03 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id NAA06644; Thu, 19 Oct 2000 13:18:02 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id NAA07256; Thu, 19 Oct 2000 13:18:40 +0900 (JST)
Message-ID: <027001c03983$cc048080$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: "Frank Balluffi" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: question about certificate path length
Date: Thu, 19 Oct 2000 13:19:38 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Mr.Frank Balluffi

Thank you very much for your relpy.

I have refered the X.509 document
cited in draft-ietf-pkix-new-part1-02.txt.
In the document, while the relationship between a delegation
path length and the pathLenConstraint component of the basicAttrConstraints
is clear,
but the relationship between a certification path length and the the
pathLenConstraint
component of the basicConstraints seemes to be not clear, I think.

So,  the description of the certification path length in
the 6.1 Basic Path Validation in draft-ietf-pkix-new-part1-02.txt
is clearer to me.

# I mistakenly have described "certification path" as "certificate path" in
# my posted mail. "certification path" is correct.

Hiroyuki Sakakibara.

> Hiroyuki, draft-ietf-pkix-new-part1-02.txt
>
> I believe that your understanding is correct.
>
> Note that draft-ietf-pkix-new-part1-02.txt's definition of the basic
> constraints extension (section 4.2.1.10) clears up ambiguities found in
RFC
> 2459's definition. For example, draft-ietf-pkix-new-part1-02.txt states:
>
> This extension MAY appear as a critical or non-critical extension in end
> entity certificates.
>
> where RFC 2459 says:
>
> This extension SHOULD NOT appear in end entity certificates.
>
> Frank
>
>
> In the case of validating Cert_b as  EE certificate, the
> > certificate path is
> > Cert_a -> Cert_b,
> >
>
> When validating
>
> section 3
>
>    end entity:  user of PKI certificates and/or end user system that
>                 is the subject of a certificate;
>
>
>
> 4.2.1.10
>    This extension MUST appear as a critical extension in all CA
>    certificates.  This extension SHOULD NOT appear in end entity
>    certificates.
>
>
>
>
>    This extension MUST appear as a critical extension in all CA
>    certificates.  This extension SHOULD NOT appear in end entity
>    certificates.
>
>
>
>
>
> > -----Original Message-----
> > From: Hiroyuki Sakakibara [mailto:[e-mail]]
> > Sent: Tuesday, October 17, 2000 2:55 AM
> > To: [e-mail]
> > Subject: question about certificate path length
> >
> >
> > Hi.
> >
> > I have a question about difference between "certificate path
> > length" and
> > "pathLenConstraint field in the basicConstraint extension".
> >
> > >Internet X.509 Public Key Infrastructure
> > >Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> > >July 14, 2000
> >
> > >4.2.1.10  Basic Constraints
> > >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> > >   In this case, it gives the maximum number of CA certificates that
> > >may follow this certificate in a certification path."
> >
> > SNIP
> >
> > >6.1 Basic Path Validation
> >
> > >To meet this goal, the path validation process verifies, among other
> > >things, that a prospective certification path (a sequence of n certi-
> > >ficates) satisfies the following conditions:
> > >      (i) for all x in {1, ..., n-1}, the subject of certificate x is
> > >      the issuer of certificate x+1;
> > >      (ii) certificate 1 is issued by the trust anchor;
> > >      (iii) certificate n is the end entity certificate; and
> > >      (iv) for all x in {1, ..., n}, the certificate was valid at the
> > >      time in question.
> > SNIP
> > >(inputs)
> > >(a) a prospective certification path of length n;
> >
> > >State variable initialization
> > >(l) max_path_length:  this integer is initialized to n, and is
> > >      reset by the path length constraint field within the basic con-
> > >      straints extension of a CA certificate.
> >
> > Referencing "Internet X.509 Public Key Infrastructure
> > Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> > July 14, 2000"
> >  I will describe my understanding.
> >
> > For example,
> >
> > CAa : trust anchor
> > CAb : subordinate CA of CAa
> > CAc : subordinate CA of CAb
> > CAd : subordinate CA of CAc
> > EE   : subordinate user of CAd
> >
> > Cert_a : CAa's self-signed certificate
> > Cert_b : CAb's certificate issued by CAa
> > Cert_c : CAb's certificate issued by CAb
> > Cert_d : CAb's certificate issued by CAc
> > Cert_user : user's certificate issued by CAd
> >
> > In this case, certificate path is
> >
> > Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user
> >
> > therefore, the length of the certificate path is "5".
> >
> > On the other hand, if CAa restricts the number of subordinates
> > CAs, 3, actually to CAd in this case, the pathLenConstraint value
> > in Cert_a is 3.
> >
> > because
> >
> > >4.2.1.10  Basic Constraints
> > >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> > >   In this case, it gives the maximum number of CA certificates that
> > >may follow this certificate in a certification path."
> >
> > So, in general, the length of the certificate path means
> > that, the number of
> > chained
> > certificates, from the trust anchor CA's certificate to

> > user or CA)
> > certificate,
> > as shown above
> > ( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).
> >
> > In the case of validating Cert_b as  EE certificate, the
> > certificate path is
> > Cert_a -> Cert_b,
> > therefore the length of the certificate path is 2.
> >
> > Consequently, if someone handles the Cert_a as the trust anchor CA's
> > certificate,
> > he sees that the maximam path length is 5, because pathLenConstraint
> > in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then
> > gets the length as
> > 5.
> >
> > Am I misunderstanding ?
> >
> > ---------------------------------------
> > Hiroyuki Sakakibara
> > MITSUBISHI ELECTRIC CORPORATION
> > Information Technology R&D Center
> > 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> > PHONE: [phone]
> > FAX:   [phone]
> > E-mail : [e-mail]
> >
>



Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA05825 for <[e-mail]>; Wed, 18 Oct 2000 19:42:21 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA212902; Wed, 18 Oct 2000 22:46:28 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with SMTP id WAA53978; Wed, 18 Oct 2000 22:45:51 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525697D.000F28C8 ; Wed, 18 Oct 2000 22:45:34 -0400
X-Lotus-FromDomain: IBMUS
To: Polar Humenn <[e-mail]>
cc: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 22:45:34 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Polar:

     I am actually not trying to tie an AC to a single PKC, just to allow
AA constraints on AC-PKC mapping to be enforced by RP's.  What the
suggestions I made were intended to do was to allow an RP to verify such a
tie when the AA intends one in the first place, and also to permit an AA to
verifiably tie an AC to a small set of PKC's characterized by the same
naming attribute (I think this attribute would be likelier to be e-mail
address or PI than DN, but I may be prejudiced).  If an AA wants to allow
future PKC's with the specified naming attribute to have access to the AC,
I would let him do so.  I gather that you (and probably Bob J.) would like
to prevent that on the grounds that it's a security risk.  Certainly a
comment in security considerations that the absence of ObjectDigest places
relatively high demands on the rigor of the entire web of cross-certified
CA's would be appropriate.
     If ObjectDigest is used, or the extension with multiple
ObjectDigest's, I think having a single PKI is not a major security issue,
although it certainly simplifies verification.

          Tom Gindin

Polar Humenn <[e-mail]> on 10/18/2000 09:50:23 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[e-mail]>, [e-mail],
      [e-mail], [e-mail], [e-mail]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt




Tom,

I like your suggestion of tying the AC to a particular certificate, or a
effectively its public key.

The requirements I stated in my proposed text for using only DNs to
identify the Holder or its issuer are flawed.

They required the AA to decide the root CA certificate was used to
identify the Holder along with itself , i.e. a single PKI as Carlisle
suggested.  Unfortunately, I think that is not such a good idea since
cross-certifications can be all over the place. Therefore, that
requirement for using only DNs to identify Holders isn't even good enough.

The AA may not have any idea of who the RPs are or will be. (I think this
was mentioned before). Specifically, I can imagine, that whoever the AA
thinks is its root CA may not be what the RP thinks the AA's root CA is
because of cross-certification. Correct? If this is the case, how could
the RP really tell what the AA thought the root of its PKI is?

In other words, the RP would have to find the root CA certificate that was
used by the AA to make its decision that the Holder's DN was actually
within the AA's PKI. Unfortunately that is on the other side of the
stockade fence. The RP may have the "can't get there from here" problem
with respect to finding the exact root CA cert that the AA used to make
its decision about the Holder being in its own PKI.

The AC has to point to the Holder PKC, as Tom's suggestion point out, so
the RP emphatically knows who has been authorized by the AC.

It seems that one of the key factors here that is causing the problems is
that is NOT desirable to restrict the AC to an entity certificate (or
really its public key). This seems to be the crux of the problem. If the
AC were restricted to the public key, then the problem goes away.

I am tending to agree with Bob Juenema that affixing privileges to names
in this arena is pretty dangerous. Especially for critical applications.
At least there is that option of basing the AC on the public key of the
holder. Although unfortunately, the profile says that it doesn't have to
be supported.

So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
recursively consistent naming constraints, a reality? If not then the AC
cannot name the Holder via DN unless it knows who the RPs will be and
knows that the RPs know who the Holders will eventually. That would be a
highly controlled, closed, and protected environment.

I understand how it's suppose to work. Mathematically, there should be a
least upper bound for all AA, RP, and Holders based on public key
signatures through the proper cross-certifications amongst all parties.
Names are completely factored out of that reasoning, only public keys
matter.

In practice, I don't see ACs with just DNs working all the time because of
naming conflicts, and I don't see a way to make that work unless all
parties are guarranteed to work in environmental constraints, perhaps
by legal means instead of technical ones.

I'll regretfully back off, as I cannot really see how to make it work
verifiably in general.

The solution in an wide open environment must be to always bind the AC to
the public key. Alternatively, the only reason I can see to bind the AC to
the holders PKC is to ensure proper advisory information is used, such as
in auditing with the subject Alt names, and other possibly other policy
constraints. Is that correct?

Cheers,
-Polar



On Wed, 18 Oct 2000 [e-mail] wrote:

>      Since ObjectDigestInfo is already in the standard, those new
syntaxes
> I suggested earlier today are redundant, and I hope that I will be
forgiven
> for them.  IMO the correct thing to do in the profile is to recommend
that
> all uses of baseCertificateID SHOULD also use the objectDigestInfo field
> with digestedObjectType publicKeyCert.  In those cases where entityName
is
> used with underlying PKC authentication but it is the AA's intent that
only
> one PKC be permitted, the objectDigestInfo field with digestedObjectType
> publicKeyCert SHOULD also be used.
>      Do we need a new extension to permit the listing of multiple PKC's
(by
> cert digest) for the same entityName when it is the AA's intent to allow
> the use of such for a single AC and all the intended PKC's already exist?
>
>           Tom Gindin
>
>
> Russ Housley <[e-mail]> on 10/18/2000 02:23:10 PM
>
> To:   Polar Humenn <[e-mail]>
> cc:   [e-mail], [e-mail], [e-mail], [e-mail]
> Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt
>
>
>
> An attribute or extension is the only acceptable approach to me, unless
we
> coordinate with X.509 agrees to make the same change to the base syntax.
>
> Russ
>
>
> At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> >On Wed, 18 Oct 2000, Russ Housley wrote:
> >
> > > Polar:
> > >
> > > You are proposing syntax that is no longer compatible with X.509.  I
am
> > > very unhappy with such a deviation.
> >
> >Hmmm. I only went on that taking into account Tom and Denises
suggestion.
> >Do you feel that an attribute extension would be warranted instead?
> >
> >Cheers,
> >-Polar
> >
> > >
> > > Russ
> > >
> > >
> > >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > > >
> > > > >> [SNIP]
> > > > >    ESSCertID ::=  SEQUENCE {
> > > > >         certHash                 Hash,
> > > > >         issuerSerial             IssuerSerial OPTIONAL
> > > > >    }
> > > > >
> > > > > and, in that case, having IssuerSerial present.
> > > > >
> > > > > Then we would need some additional text in the explanations to
say
> > that the
> > > > > hash of the certificate should also be tested.
> > > > >
> > > > > In this way, at the time of verification, there is no ambiguity
> > about the
> > > > > link between the AC and the certificate, even if the CA has the
> same
> > > > name as
> > > > > another CA certified from a different root key.
> > > >
> > > >Dennis,
> > > >
> > > >I still think that this solution doesn't quite solve the problem,
but
> is a
> > > >good start.  In fact Tom Gindin's suggestion just came in and
includes
> > > >yours. So I'll sort of work off of that.
> > > >
> > > >The fact is that the entityName option still contains a DN and the
RP
> MUST
> > > >be prepared to accept it. However, on what conditions should the RP
> accept
> > > >the Holder as a DN? (Especially if this verification is offloaded to
> some
> > > >remote verification engine).
> > > >
> > > >Perhaps there is a way to word the USE of a DN entityName?
> > > >
> > > >When using an AC that contains the Holder specification as a DN
> entityName
> > > >option, the DN MUST verifiable and uniquely name an entity within
the
> PKI
> > > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
> MUST
> > > >ONLY create AttributeCertificates with the Holder as a DN entityName
> in
> > > >this fashion. This constraint is subject to the entire PKI for which
> the
> > > >AA belongs belongs to behave in its creation of unique DN.
Therefore,
> > > >verification is subject to the trust the RP places in the AA and its
> PKI
> > > >together to conform to this behavior.
> > > >
> > > >[Note: this approach still does not solve the problem that Denis
> brings up
> > > >below as comment 43. A subordinate CA may be compromised within the
> PKI of
> > > >the AA and create impostor certificates, grabbing privileges.]
> > > >
> > > >Therefore, it would still probably be better to use the
Issuer/Serial
> and
> > > >a hash of the Issuer's certificate, even if in the same PKI.
> > > >
> > > >Of course, when an application authenticates to an RP using PKCs
this
> ties
> > > >the authorization to a particular certificate. Apparently that was
not
> > > >desirable due to the effect of key rollover and new certificates
being
> > > >issued to the same subject entity.
> > > >
> > > >However, I think that if as Carlise pointed out, that if the DN is
> only
> > > >used in the case of a single trusted Root, then everything will be
> fine.
> > > >
> > > >So, as Russ asked me to propose text, here it goes:
> > > >
> > > >Using Tom's suggestion (I took the liberty to use the
ObjectDigestInfo
> > > >that is already defined in the document for the certificate Hash).
> > > >
> > > >Section 4.1:
> > > >
> > > >    Holder ::= SEQUENCE {
> > > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > > >                 -- the issuer and serial number of
> > > >                 -- the holder's Public Key Certificate
> > > >         entityName          [1] GeneralNames OPTIONAL,
> > > >                 -- the name of the claimant or role
> > > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > > >                 -- if present, version must be v2
> > > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > > >    }
> > > >
> > > >    IssuerSerialCertID ::=  SEQUENCE {
> > > >         isserCertDigest          ObjectDigestInfo,
> > > >         issuerSerial             IssuerSerial
> > > >    }
> > > >
> > > >In section 4.2.2 Holder add:
> > > >
> > > >When using an entityName that contains a DN, the DN MUST verifiably
> and
> > > >uniquely name an entity within the PKI of the AC issuer. The PKC
named
> by
> > > >the DN MUST verify back to the root CA of the AC issuer. The AC
issuer
> > > >MUST ONLY create AttributeCertificates with the Holder as a DN
> entityName
> > > >in this fashion. This constraint is subject to the entire PKI for
> which
> > > >the AC issuer belongs to behave in its creation of unique DNs.
> Therefore,
> > > >verification is also subject to the trust the RP places in the AC
> issuer's
> > > >PKI to conform to this behavior.
> > > >
> > > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
> 1,
> > > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > > >
> > > >To be valid an AC MUST satisfy all of the following:
> > > >
> > > >1. The AC signature MUST be cryptographically correct, and the AC
> > > >    issuer's entire PKC certification path MUST be verified in
> > > >    accordance with [PKIXPROF].
> > > >
> > > >2. When the AC holder is named by a DN using the entityName option,
> > > >    the holder's PK certificate MUST be uniquely found under the
same
> root
> > > >    CA as the AC issuer. The entire certification path of that PKC
> MUST be
> > > >    verified in accordance with [PKIXPROF].
> > > >
> > > >3. When the AC holder is named by a baseCertificateId, the issuer's
PK
> > > >    certificate MUST be uniquely found under the same root CA as
> > > >    the AC issuer. The entire certificate path of that PKC MUST
> > > >    be verified in accordance with [PKIXPROF].
> > > >
> > > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > > >    named holder issuer's PKC must be found, and that PKC MUST
> correctly
> > > >    digest to the digest value contained in the
> verifiedBaseCertificateID.
> > > >    The entire certificate path starting with the holder's PKC and
the
> PKC
> > > >    of the issuer the holder's PKC MUST be verified in accordance
> > > >    with [PKIXPROF].
> > > >
> > > >.....
> > > >
> > > >Note: there is *still* a problem with AC targeting and proxying
using
> > > >just DNs.
> > > >
> > > >Cheers,
> > > >-Polar
> > > >
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]      2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com
> > >
> >
> >-------------------------------------------------------------------
> >Polar Humenn                  Adiron, LLC
> >mailto:[e-mail]      2-212 CST
> >Phone: [phone]           Syracuse, NY 13244-4100
> >Fax:   [phone]           http://www.adiron.com
>
>
>
>

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com









Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04944 for <[e-mail]>; Wed, 18 Oct 2000 19:09:10 -0700 (PDT)
Received: by balinese.baltimore.ie; id DAA05076; Thu, 19 Oct 2000 03:14:21 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma005055; Thu, 19 Oct 00 03:14:19 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id DAA25330; Thu, 19 Oct 2000 03:13:58 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 03:17:34 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: "Covey, Carlin" <[e-mail]>, Denis Pinkas <[e-mail]>, Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Regardless of any other text, if you want to change X.509(2000)
then you should contact ISO. PKIX compliant ACs have to be
X.509 compliant. 

Stephen.

>    Holder ::= SEQUENCE {
>         baseCertificateID   [0] IssuerSerial OPTIONAL,
>                 -- the issuer and serial number of
>                 -- the holder's Public Key Certificate
>         entityName          [1] GeneralNames OPTIONAL,
>                 -- the name of the claimant or role
>         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
>                 -- if present, version must be v2
>         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
>    }


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04632 for <[e-mail]>; Wed, 18 Oct 2000 19:05:11 -0700 (PDT)
Received: by balinese.baltimore.ie; id DAA04954; Thu, 19 Oct 2000 03:10:21 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma004940; Thu, 19 Oct 00 03:10:09 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id DAA25268; Thu, 19 Oct 2000 03:09:38 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 03:13:12 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Denis Pinkas <[e-mail]>, Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I completely agree.

Stephen.

"Phillip H. Griffin" wrote:
> It is a really bad idea to break compatibility
> with an international standard you are attempting
> to profile. Suggesting such a course of action is
> ridiculous.
> 
> No matter how benign they may appear to be, any ASN.1
> changes made to the AC profile in order to attempt to
> force changes into X.509 would not be wise. This would
> likely lead to two different notations for ACs.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04379 for <[e-mail]>; Wed, 18 Oct 2000 19:02:09 -0700 (PDT)
Received: by balinese.baltimore.ie; id DAA04897; Thu, 19 Oct 2000 03:07:20 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma004893; Thu, 19 Oct 00 03:07:17 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id DAA25217; Thu, 19 Oct 2000 03:07:13 +0100
Message-ID: <[e-mail]>
Date: Thu, 19 Oct 2000 03:10:42 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Lista IETF <[e-mail]>
Subject: Re: Attribute Certificates II
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Pedro,

>         -> In section 4.2.3 it's said that all AC Issuers must be
> identified by non-empty DNs. It's also said that "it means that the AC
> Issuer does not have to know which PKC the verifier will use for it (the
> AC Issuer). Using the baseCertificateID field to reference the AC Issuer
> would mean that the AC verifier would have to trust the PKC that the AC
> Issuer chosed (for itself) at the AC creation time.".
> 
>            If that is so, then how does the relying party know what AC
> Issuer PKC it should use to verify the signature on the AC ?

This is entirely analagous to verifying the signature on a PKC, even
down to the ability to include an AKID in the AC. Just the same, no
different.

>         -> If the holder is identified using the "entityName" field can
> you assure that only the authentic holder can gain access to some
> resource and not another party (with an equal DN) ?
>           As far as I know, presenting the AC isn't enough... You also
> have to present a proof of possesion (usually the signature of a
> challenge) of something that only that identity knows (like the private
> key corresponding to the cert's public key)...
>            Am I wrong ?
>            Or, when you use this field, who presents the AC gets the
> access and that's it ?

No, that isn't it. Protocols using this profile would have to specify how 
theft of ACs is prevented. The security considerations section describes
some of the issues and the proposed additional text adds some more.

Incidentally, what you call proof-of-possession above I would call
authentication.

> 
>         -> Regarding the previous point, if you use the
> "objectDigestInfo" of a public key or cert, you could make that proof of
> possesion right ?

Indirectly. If the authentication is based on the relevant public key or
PKC.

> 
>         -> Are supposing that it's the job of a lower software
> layer/protocol to verify/ensure that the AC is being presented by the
> righteous owner ?
>           If so, do you have any protocol in mind ?

I don't understand the question. In any case, since this is just
a profile, such protocol issues are out of scope.

Stephen.

 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04005 for <[e-mail]>; Wed, 18 Oct 2000 18:52:46 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id VAA04573; Wed, 18 Oct 2000 21:50:24 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 21:50:23 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: [e-mail]
cc: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Tom,

I like your suggestion of tying the AC to a particular certificate, or a
effectively its public key.

The requirements I stated in my proposed text for using only DNs to 
identify the Holder or its issuer are flawed.

They required the AA to decide the root CA certificate was used to
identify the Holder along with itself , i.e. a single PKI as Carlisle
suggested.  Unfortunately, I think that is not such a good idea since
cross-certifications can be all over the place. Therefore, that
requirement for using only DNs to identify Holders isn't even good enough.

The AA may not have any idea of who the RPs are or will be. (I think this
was mentioned before). Specifically, I can imagine, that whoever the AA
thinks is its root CA may not be what the RP thinks the AA's root CA is
because of cross-certification. Correct? If this is the case, how could
the RP really tell what the AA thought the root of its PKI is?

In other words, the RP would have to find the root CA certificate that was
used by the AA to make its decision that the Holder's DN was actually
within the AA's PKI. Unfortunately that is on the other side of the
stockade fence. The RP may have the "can't get there from here" problem
with respect to finding the exact root CA cert that the AA used to make
its decision about the Holder being in its own PKI.

The AC has to point to the Holder PKC, as Tom's suggestion point out, so
the RP emphatically knows who has been authorized by the AC.

It seems that one of the key factors here that is causing the problems is
that is NOT desirable to restrict the AC to an entity certificate (or
really its public key). This seems to be the crux of the problem. If the
AC were restricted to the public key, then the problem goes away.

I am tending to agree with Bob Juenema that affixing privileges to names
in this arena is pretty dangerous. Especially for critical applications.
At least there is that option of basing the AC on the public key of the
holder. Although unfortunately, the profile says that it doesn't have to
be supported.

So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
recursively consistent naming constraints, a reality? If not then the AC
cannot name the Holder via DN unless it knows who the RPs will be and
knows that the RPs know who the Holders will eventually. That would be a
highly controlled, closed, and protected environment.

I understand how it's suppose to work. Mathematically, there should be a
least upper bound for all AA, RP, and Holders based on public key
signatures through the proper cross-certifications amongst all parties.
Names are completely factored out of that reasoning, only public keys
matter.

In practice, I don't see ACs with just DNs working all the time because of
naming conflicts, and I don't see a way to make that work unless all
parties are guarranteed to work in environmental constraints, perhaps
by legal means instead of technical ones. 

I'll regretfully back off, as I cannot really see how to make it work
verifiably in general.

The solution in an wide open environment must be to always bind the AC to
the public key. Alternatively, the only reason I can see to bind the AC to
the holders PKC is to ensure proper advisory information is used, such as
in auditing with the subject Alt names, and other possibly other policy
constraints. Is that correct?

Cheers,
-Polar



On Wed, 18 Oct 2000 [e-mail] wrote:

>      Since ObjectDigestInfo is already in the standard, those new syntaxes
> I suggested earlier today are redundant, and I hope that I will be forgiven
> for them.  IMO the correct thing to do in the profile is to recommend that
> all uses of baseCertificateID SHOULD also use the objectDigestInfo field
> with digestedObjectType publicKeyCert.  In those cases where entityName is
> used with underlying PKC authentication but it is the AA's intent that only
> one PKC be permitted, the objectDigestInfo field with digestedObjectType
> publicKeyCert SHOULD also be used.
>      Do we need a new extension to permit the listing of multiple PKC's (by
> cert digest) for the same entityName when it is the AA's intent to allow
> the use of such for a single AC and all the intended PKC's already exist?
> 
>           Tom Gindin
> 
> 
> Russ Housley <[e-mail]> on 10/18/2000 02:23:10 PM
> 
> To:   Polar Humenn <[e-mail]>
> cc:   [e-mail], [e-mail], [e-mail], [e-mail]
> Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> 
> 
> An attribute or extension is the only acceptable approach to me, unless we
> coordinate with X.509 agrees to make the same change to the base syntax.
> 
> Russ
> 
> 
> At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> >On Wed, 18 Oct 2000, Russ Housley wrote:
> >
> > > Polar:
> > >
> > > You are proposing syntax that is no longer compatible with X.509.  I am
> > > very unhappy with such a deviation.
> >
> >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> >Do you feel that an attribute extension would be warranted instead?
> >
> >Cheers,
> >-Polar
> >
> > >
> > > Russ
> > >
> > >
> > >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > > >
> > > > >> [SNIP]
> > > > >    ESSCertID ::=  SEQUENCE {
> > > > >         certHash                 Hash,
> > > > >         issuerSerial             IssuerSerial OPTIONAL
> > > > >    }
> > > > >
> > > > > and, in that case, having IssuerSerial present.
> > > > >
> > > > > Then we would need some additional text in the explanations to say
> > that the
> > > > > hash of the certificate should also be tested.
> > > > >
> > > > > In this way, at the time of verification, there is no ambiguity
> > about the
> > > > > link between the AC and the certificate, even if the CA has the
> same
> > > > name as
> > > > > another CA certified from a different root key.
> > > >
> > > >Dennis,
> > > >
> > > >I still think that this solution doesn't quite solve the problem, but
> is a
> > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > >yours. So I'll sort of work off of that.
> > > >
> > > >The fact is that the entityName option still contains a DN and the RP
> MUST
> > > >be prepared to accept it. However, on what conditions should the RP
> accept
> > > >the Holder as a DN? (Especially if this verification is offloaded to
> some
> > > >remote verification engine).
> > > >
> > > >Perhaps there is a way to word the USE of a DN entityName?
> > > >
> > > >When using an AC that contains the Holder specification as a DN
> entityName
> > > >option, the DN MUST verifiable and uniquely name an entity within the
> PKI
> > > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
> MUST
> > > >ONLY create AttributeCertificates with the Holder as a DN entityName
> in
> > > >this fashion. This constraint is subject to the entire PKI for which
> the
> > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > >verification is subject to the trust the RP places in the AA and its
> PKI
> > > >together to conform to this behavior.
> > > >
> > > >[Note: this approach still does not solve the problem that Denis
> brings up
> > > >below as comment 43. A subordinate CA may be compromised within the
> PKI of
> > > >the AA and create impostor certificates, grabbing privileges.]
> > > >
> > > >Therefore, it would still probably be better to use the Issuer/Serial
> and
> > > >a hash of the Issuer's certificate, even if in the same PKI.
> > > >
> > > >Of course, when an application authenticates to an RP using PKCs this
> ties
> > > >the authorization to a particular certificate. Apparently that was not
> > > >desirable due to the effect of key rollover and new certificates being
> > > >issued to the same subject entity.
> > > >
> > > >However, I think that if as Carlise pointed out, that if the DN is
> only
> > > >used in the case of a single trusted Root, then everything will be
> fine.
> > > >
> > > >So, as Russ asked me to propose text, here it goes:
> > > >
> > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > >that is already defined in the document for the certificate Hash).
> > > >
> > > >Section 4.1:
> > > >
> > > >    Holder ::= SEQUENCE {
> > > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > > >                 -- the issuer and serial number of
> > > >                 -- the holder's Public Key Certificate
> > > >         entityName          [1] GeneralNames OPTIONAL,
> > > >                 -- the name of the claimant or role
> > > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > > >                 -- if present, version must be v2
> > > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > > >    }
> > > >
> > > >    IssuerSerialCertID ::=  SEQUENCE {
> > > >         isserCertDigest          ObjectDigestInfo,
> > > >         issuerSerial             IssuerSerial
> > > >    }
> > > >
> > > >In section 4.2.2 Holder add:
> > > >
> > > >When using an entityName that contains a DN, the DN MUST verifiably
> and
> > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> by
> > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > >MUST ONLY create AttributeCertificates with the Holder as a DN
> entityName
> > > >in this fashion. This constraint is subject to the entire PKI for
> which
> > > >the AC issuer belongs to behave in its creation of unique DNs.
> Therefore,
> > > >verification is also subject to the trust the RP places in the AC
> issuer's
> > > >PKI to conform to this behavior.
> > > >
> > > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
> 1,
> > > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > > >
> > > >To be valid an AC MUST satisfy all of the following:
> > > >
> > > >1. The AC signature MUST be cryptographically correct, and the AC
> > > >    issuer's entire PKC certification path MUST be verified in
> > > >    accordance with [PKIXPROF].
> > > >
> > > >2. When the AC holder is named by a DN using the entityName option,
> > > >    the holder's PK certificate MUST be uniquely found under the same
> root
> > > >    CA as the AC issuer. The entire certification path of that PKC
> MUST be
> > > >    verified in accordance with [PKIXPROF].
> > > >
> > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > >    certificate MUST be uniquely found under the same root CA as
> > > >    the AC issuer. The entire certificate path of that PKC MUST
> > > >    be verified in accordance with [PKIXPROF].
> > > >
> > > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > > >    named holder issuer's PKC must be found, and that PKC MUST
> correctly
> > > >    digest to the digest value contained in the
> verifiedBaseCertificateID.
> > > >    The entire certificate path starting with the holder's PKC and the
> PKC
> > > >    of the issuer the holder's PKC MUST be verified in accordance
> > > >    with [PKIXPROF].
> > > >
> > > >.....
> > > >
> > > >Note: there is *still* a problem with AC targeting and proxying using
> > > >just DNs.
> > > >
> > > >Cheers,
> > > >-Polar
> > > >
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]      2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com
> > >
> >
> >-------------------------------------------------------------------
> >Polar Humenn                  Adiron, LLC
> >mailto:[e-mail]      2-212 CST
> >Phone: [phone]           Syracuse, NY 13244-4100
> >Fax:   [phone]           http://www.adiron.com
> 
> 
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com






Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29688 for <[e-mail]>; Wed, 18 Oct 2000 15:25:18 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA157316; Wed, 18 Oct 2000 18:29:51 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with SMTP id SAA62422; Wed, 18 Oct 2000 18:29:44 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525697C.007B8F29 ; Wed, 18 Oct 2000 18:29:35 -0400
X-Lotus-FromDomain: IBMUS
To: Russ Housley <[e-mail]>
cc: Polar Humenn <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 18:29:28 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Since ObjectDigestInfo is already in the standard, those new syntaxes
I suggested earlier today are redundant, and I hope that I will be forgiven
for them.  IMO the correct thing to do in the profile is to recommend that
all uses of baseCertificateID SHOULD also use the objectDigestInfo field
with digestedObjectType publicKeyCert.  In those cases where entityName is
used with underlying PKC authentication but it is the AA's intent that only
one PKC be permitted, the objectDigestInfo field with digestedObjectType
publicKeyCert SHOULD also be used.
     Do we need a new extension to permit the listing of multiple PKC's (by
cert digest) for the same entityName when it is the AA's intent to allow
the use of such for a single AC and all the intended PKC's already exist?

          Tom Gindin


Russ Housley <[e-mail]> on 10/18/2000 02:23:10 PM

To:   Polar Humenn <[e-mail]>
cc:   [e-mail], [e-mail], [e-mail], [e-mail]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt



An attribute or extension is the only acceptable approach to me, unless we
coordinate with X.509 agrees to make the same change to the base syntax.

Russ


At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
>On Wed, 18 Oct 2000, Russ Housley wrote:
>
> > Polar:
> >
> > You are proposing syntax that is no longer compatible with X.509.  I am
> > very unhappy with such a deviation.
>
>Hmmm. I only went on that taking into account Tom and Denises suggestion.
>Do you feel that an attribute extension would be warranted instead?
>
>Cheers,
>-Polar
>
> >
> > Russ
> >
> >
> >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > >
> > > >> [SNIP]
> > > >    ESSCertID ::=  SEQUENCE {
> > > >         certHash                 Hash,
> > > >         issuerSerial             IssuerSerial OPTIONAL
> > > >    }
> > > >
> > > > and, in that case, having IssuerSerial present.
> > > >
> > > > Then we would need some additional text in the explanations to say
> that the
> > > > hash of the certificate should also be tested.
> > > >
> > > > In this way, at the time of verification, there is no ambiguity
> about the
> > > > link between the AC and the certificate, even if the CA has the
same
> > > name as
> > > > another CA certified from a different root key.
> > >
> > >Dennis,
> > >
> > >I still think that this solution doesn't quite solve the problem, but
is a
> > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > >yours. So I'll sort of work off of that.
> > >
> > >The fact is that the entityName option still contains a DN and the RP
MUST
> > >be prepared to accept it. However, on what conditions should the RP
accept
> > >the Holder as a DN? (Especially if this verification is offloaded to
some
> > >remote verification engine).
> > >
> > >Perhaps there is a way to word the USE of a DN entityName?
> > >
> > >When using an AC that contains the Holder specification as a DN
entityName
> > >option, the DN MUST verifiable and uniquely name an entity within the
PKI
> > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
MUST
> > >ONLY create AttributeCertificates with the Holder as a DN entityName
in
> > >this fashion. This constraint is subject to the entire PKI for which
the
> > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > >verification is subject to the trust the RP places in the AA and its
PKI
> > >together to conform to this behavior.
> > >
> > >[Note: this approach still does not solve the problem that Denis
brings up
> > >below as comment 43. A subordinate CA may be compromised within the
PKI of
> > >the AA and create impostor certificates, grabbing privileges.]
> > >
> > >Therefore, it would still probably be better to use the Issuer/Serial
and
> > >a hash of the Issuer's certificate, even if in the same PKI.
> > >
> > >Of course, when an application authenticates to an RP using PKCs this
ties
> > >the authorization to a particular certificate. Apparently that was not
> > >desirable due to the effect of key rollover and new certificates being
> > >issued to the same subject entity.
> > >
> > >However, I think that if as Carlise pointed out, that if the DN is
only
> > >used in the case of a single trusted Root, then everything will be
fine.
> > >
> > >So, as Russ asked me to propose text, here it goes:
> > >
> > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > >that is already defined in the document for the certificate Hash).
> > >
> > >Section 4.1:
> > >
> > >    Holder ::= SEQUENCE {
> > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > >                 -- the issuer and serial number of
> > >                 -- the holder's Public Key Certificate
> > >         entityName          [1] GeneralNames OPTIONAL,
> > >                 -- the name of the claimant or role
> > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > >                 -- if present, version must be v2
> > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > >    }
> > >
> > >    IssuerSerialCertID ::=  SEQUENCE {
> > >         isserCertDigest          ObjectDigestInfo,
> > >         issuerSerial             IssuerSerial
> > >    }
> > >
> > >In section 4.2.2 Holder add:
> > >
> > >When using an entityName that contains a DN, the DN MUST verifiably
and
> > >uniquely name an entity within the PKI of the AC issuer. The PKC named
by
> > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > >MUST ONLY create AttributeCertificates with the Holder as a DN
entityName
> > >in this fashion. This constraint is subject to the entire PKI for
which
> > >the AC issuer belongs to behave in its creation of unique DNs.
Therefore,
> > >verification is also subject to the trust the RP places in the AC
issuer's
> > >PKI to conform to this behavior.
> > >
> > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
1,
> > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > >
> > >To be valid an AC MUST satisfy all of the following:
> > >
> > >1. The AC signature MUST be cryptographically correct, and the AC
> > >    issuer's entire PKC certification path MUST be verified in
> > >    accordance with [PKIXPROF].
> > >
> > >2. When the AC holder is named by a DN using the entityName option,
> > >    the holder's PK certificate MUST be uniquely found under the same
root
> > >    CA as the AC issuer. The entire certification path of that PKC
MUST be
> > >    verified in accordance with [PKIXPROF].
> > >
> > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > >    certificate MUST be uniquely found under the same root CA as
> > >    the AC issuer. The entire certificate path of that PKC MUST
> > >    be verified in accordance with [PKIXPROF].
> > >
> > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > >    named holder issuer's PKC must be found, and that PKC MUST
correctly
> > >    digest to the digest value contained in the
verifiedBaseCertificateID.
> > >    The entire certificate path starting with the holder's PKC and the
PKC
> > >    of the issuer the holder's PKC MUST be verified in accordance
> > >    with [PKIXPROF].
> > >
> > >.....
> > >
> > >Note: there is *still* a problem with AC targeting and proxying using
> > >just DNs.
> > >
> > >Cheers,
> > >-Polar
> > >
> > >
> > >-------------------------------------------------------------------
> > >Polar Humenn                  Adiron, LLC
> > >mailto:[e-mail]      2-212 CST
> > >Phone: [phone]           Syracuse, NY 13244-4100
> > >Fax:   [phone]           http://www.adiron.com
> >
>
>-------------------------------------------------------------------
>Polar Humenn                  Adiron, LLC
>mailto:[e-mail]      2-212 CST
>Phone: [phone]           Syracuse, NY 13244-4100
>Fax:   [phone]           http://www.adiron.com






Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29347 for <[e-mail]>; Wed, 18 Oct 2000 15:18:21 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id SAA22789; Wed, 18 Oct 2000 18:02:54 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 18 Oct 2000 18:15:32 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: p/+/jnaSzfmnbGDqGtuN8g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

It's happened before, when organizations with isolated IP networks
decided to connect to the Internet.  It was a royal pain to get a block
of official IP addresses and renumber all your machines, but it was
necessary, so people did it.  (This was before NAT and masquerading,
of course.)

At some point, organizations with isolated PKIs might decide to get an
"official" DN subtree and issue certificates within it.  After an
organization makes a decision to operate in a coordinated way with
other organizations, implementation of name constraints in cross certs
and replacement of user certificates is not particularly daunting.
Less daunting than IP renumbering, at any rate.

"Compliance" is not the problem.  The problem is understanding that an
Inter-PKI cannot really work if users pick their own DNs any more than
the Internet could work if users picked their own IP addresses.

Dave




> From: Polar Humenn <[e-mail]>
> 
> But this condition of operation for the AA still hinges on the fact that
> the DN space MUST be unique after cross certifying PKI's.
> 
> Can you really see that happening?
> 
> I cannot see that happening in the real world. Especially with many
> players, and especally when you need to do things quickly. Forcing one
> organization or both to comply with the other, is a lot of work, and
> figuring out name constraints for both could be a daunting effort, not
> mentioning getting it correct.
> 
> Cheers,
> -Polar



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27104 for <[e-mail]>; Wed, 18 Oct 2000 13:46:42 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <VBLVWW6W>; Wed, 18 Oct 2000 13:48:10 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: "'Polar Humenn'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
Date: Wed, 18 Oct 2000 13:48:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Polar,

Evidently the assumption in the "snippet" below is that when the holder of
an AC is identified by a DN, some PKC with the same DN will be used to
authenticate the holder.  Is this actually required?  Couldn't the AC, even
if it identified the holder by a DN, specify some other authentication
criterion, such as a biometric?  The holder of the AC may in fact have zero,
one or more PKC's that may also be used for authentication.

- Carlin Covey
  Cylink Corp.

> -----Original Message-----
> From: Polar Humenn [mailto:[e-mail]]
> Sent: Wednesday, October 18, 2000 1:19 PM
> To: Russ Housley
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
> 
> 
> 
<snip> 
> 
> In section 4.2.2 Holder add:
> 
> When using an entityName that contains a DN, the DN MUST verifiably and
> uniquely name an entity within the PKI of the AC issuer. 
> The PKC named by the DN MUST verify back to the root CA of the AC issuer.
> The AC issuer MUST ONLY create AttributeCertificates with the Holder as a 
> DN entityName in this fashion. This constraint is subject to the entire
PKI 
> for which the AC issuer belongs to behave in its creation of unique 
> DNs. Therefore, verification is also subject to the trust the RP places in

> the AC issuer's PKI to conform to this behavior.
> 
<snip>


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26136 for <[e-mail]>; Wed, 18 Oct 2000 13:18:23 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id QAA04159; Wed, 18 Oct 2000 16:19:05 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 16:19:04 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Russ Housley <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi, 

Okay, on Russ's suggestion that only an attribute extension will be
acceptable. 

I think this approach does the following:

1. Addresses Carlisle's points about when using DNs that "everything"
   belongs to one PKI, i.e. under a single trusted root. So using DNs for  
   the Holder, or the Holder's issuer in IssuerSerial are okay.

2. Addresses my points solving name collisions by either impostor or
   coincidence.

3. If everything was previous working in accordance with Carlisle's
   assumptions of a single PKI, it doesn't break anything.

4. Doesn't change X.509.

5. There is no need to put a security consideration in the document 
   refering to DN name collisions. 

6. The sentence appearing in Section 4.2.2 Holder,

	"See the security consideration section which mentions some
        name collision problems that may arise when using the entityName
        option."

   can probably be eliminated. (Since there isn't a section currently
   in the security consideration section mentioning name collision
   problems.)


Here is the entire proposed text:

Section 4.1 Remains:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
   }


In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

When using the baseCertificateID, if the DN contained in
holder.baseCertificateID.issuer construct does not verifiably and uniquely
name an entity within the PKI of the AC issuer, the
VerifiedBaseCertificateID critical extension, as defined in Section 4.3.?,
MUST be present. The AC issuer MUST only create AttributeCertificates with
the Holder as a baseCertificateID in this fashion.


Add the following subsection to Section 4.3 Extensions:

4.3.? Verifying Base Certificate ID

When the holder is named by the baseCertificateID, if the DN contained in
the holder.baseCertificateID.issuer construct does not verifiably and
uniquely name an entity within the PKI of the AC Issuer, a verifiable link
to that issuer's PKC is required by Section 4.2.2. This extension provides
that link by using a digest of the holder issuer's PK certificate.

The digest contained in this extension MUST be a digest of the PKC of the
entity named by the DN in the holder.baseCertificateID.issuer field.

  name           id-pe-ac-verfiedBaseCertificateID
  OID            { id-pe ??? }
  syntax         ObjectDigestInfo
  criticality    MUST be TRUE


In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

To be valid an AC MUST satisfy all of the following:

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateID, one of the
   following cases MUST hold: 

   (a) If the VerifiedBaseCertificateID critical extension is not present,
       a PK certificate MUST be found for which the DN contained in
       the holder.baseCertificateID.issuer construct is unique under the
       same root CA as the AC issuer. The entire certificate path of that
       PKC MUST be verified in accordance with [PKIXPROF].
   (b) If the VerifiedBaseCertificateID critical extension is present,
       a PK certificate MUST be found for the DN contained in
       the holder.baseCertificateID.issuer construct, and that PKC MUST
       correctly digest to the digest value contained in the
       extension. The entire certificate path beginning with the holder's
       PKC and the PKC of the holder's issuer MUST be verified
       in accordance with [PKIXPROF].


Note: there is still a problem targets and proxies just using DNs.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24104 for <[e-mail]>; Wed, 18 Oct 2000 11:54:35 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA17670; Wed, 18 Oct 2000 11:59:14 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 18 Oct 2000 12:11:49 -0700
To: Peter Williams <[e-mail]>, IETF-PXIX <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: TSP. Version 10
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:00 AM 10/18/00 -0700, Peter Williams wrote:
>Tony,
>
>Or,
>
>The operator of a time stamping service *asserts* (or may *represent*, or
>may *warrant*) that...
>
>
>---------
>
>
>Designating something as either providing evidence or supporting
>proof claims is not something that an Internet Standard can do,
>legitimately, of one takes, as legally authoritative, Michael Baum's
>scorn of X.400's (1988) International Standard's ratified specifications
>of  "proof" and "non-repudiation" security services.

Peter,

Thank you for the admonishment.

   "A time stamping service supports assertions of proof that ..."

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22924 for <[e-mail]>; Wed, 18 Oct 2000 11:18:55 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA07602; Wed, 18 Oct 2000 11:23:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 18 Oct 2000 14:23:10 -0400
To: Polar Humenn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

An attribute or extension is the only acceptable approach to me, unless we 
coordinate with X.509 agrees to make the same change to the base syntax.

Russ


At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
>On Wed, 18 Oct 2000, Russ Housley wrote:
>
> > Polar:
> >
> > You are proposing syntax that is no longer compatible with X.509.  I am
> > very unhappy with such a deviation.
>
>Hmmm. I only went on that taking into account Tom and Denises suggestion.
>Do you feel that an attribute extension would be warranted instead?
>
>Cheers,
>-Polar
>
> >
> > Russ
> >
> >
> >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > >
> > > >> [SNIP]
> > > >    ESSCertID ::=  SEQUENCE {
> > > >         certHash                 Hash,
> > > >         issuerSerial             IssuerSerial OPTIONAL
> > > >    }
> > > >
> > > > and, in that case, having IssuerSerial present.
> > > >
> > > > Then we would need some additional text in the explanations to say 
> that the
> > > > hash of the certificate should also be tested.
> > > >
> > > > In this way, at the time of verification, there is no ambiguity 
> about the
> > > > link between the AC and the certificate, even if the CA has the same
> > > name as
> > > > another CA certified from a different root key.
> > >
> > >Dennis,
> > >
> > >I still think that this solution doesn't quite solve the problem, but is a
> > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > >yours. So I'll sort of work off of that.
> > >
> > >The fact is that the entityName option still contains a DN and the RP MUST
> > >be prepared to accept it. However, on what conditions should the RP accept
> > >the Holder as a DN? (Especially if this verification is offloaded to some
> > >remote verification engine).
> > >
> > >Perhaps there is a way to word the USE of a DN entityName?
> > >
> > >When using an AC that contains the Holder specification as a DN entityName
> > >option, the DN MUST verifiable and uniquely name an entity within the PKI
> > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
> > >ONLY create AttributeCertificates with the Holder as a DN entityName in
> > >this fashion. This constraint is subject to the entire PKI for which the
> > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > >verification is subject to the trust the RP places in the AA and its PKI
> > >together to conform to this behavior.
> > >
> > >[Note: this approach still does not solve the problem that Denis brings up
> > >below as comment 43. A subordinate CA may be compromised within the PKI of
> > >the AA and create impostor certificates, grabbing privileges.]
> > >
> > >Therefore, it would still probably be better to use the Issuer/Serial and
> > >a hash of the Issuer's certificate, even if in the same PKI.
> > >
> > >Of course, when an application authenticates to an RP using PKCs this ties
> > >the authorization to a particular certificate. Apparently that was not
> > >desirable due to the effect of key rollover and new certificates being
> > >issued to the same subject entity.
> > >
> > >However, I think that if as Carlise pointed out, that if the DN is only
> > >used in the case of a single trusted Root, then everything will be fine.
> > >
> > >So, as Russ asked me to propose text, here it goes:
> > >
> > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > >that is already defined in the document for the certificate Hash).
> > >
> > >Section 4.1:
> > >
> > >    Holder ::= SEQUENCE {
> > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > >                 -- the issuer and serial number of
> > >                 -- the holder's Public Key Certificate
> > >         entityName          [1] GeneralNames OPTIONAL,
> > >                 -- the name of the claimant or role
> > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > >                 -- if present, version must be v2
> > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > >    }
> > >
> > >    IssuerSerialCertID ::=  SEQUENCE {
> > >         isserCertDigest          ObjectDigestInfo,
> > >         issuerSerial             IssuerSerial
> > >    }
> > >
> > >In section 4.2.2 Holder add:
> > >
> > >When using an entityName that contains a DN, the DN MUST verifiably and
> > >uniquely name an entity within the PKI of the AC issuer. The PKC named by
> > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > >MUST ONLY create AttributeCertificates with the Holder as a DN entityName
> > >in this fashion. This constraint is subject to the entire PKI for which
> > >the AC issuer belongs to behave in its creation of unique DNs. Therefore,
> > >verification is also subject to the trust the RP places in the AC issuer's
> > >PKI to conform to this behavior.
> > >
> > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
> > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > >
> > >To be valid an AC MUST satisfy all of the following:
> > >
> > >1. The AC signature MUST be cryptographically correct, and the AC
> > >    issuer's entire PKC certification path MUST be verified in
> > >    accordance with [PKIXPROF].
> > >
> > >2. When the AC holder is named by a DN using the entityName option,
> > >    the holder's PK certificate MUST be uniquely found under the same root
> > >    CA as the AC issuer. The entire certification path of that PKC MUST be
> > >    verified in accordance with [PKIXPROF].
> > >
> > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > >    certificate MUST be uniquely found under the same root CA as
> > >    the AC issuer. The entire certificate path of that PKC MUST
> > >    be verified in accordance with [PKIXPROF].
> > >
> > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > >    named holder issuer's PKC must be found, and that PKC MUST correctly
> > >    digest to the digest value contained in the verifiedBaseCertificateID.
> > >    The entire certificate path starting with the holder's PKC and the PKC
> > >    of the issuer the holder's PKC MUST be verified in accordance
> > >    with [PKIXPROF].
> > >
> > >.....
> > >
> > >Note: there is *still* a problem with AC targeting and proxying using
> > >just DNs.
> > >
> > >Cheers,
> > >-Polar
> > >
> > >
> > >-------------------------------------------------------------------
> > >Polar Humenn                  Adiron, LLC
> > >mailto:[e-mail]      2-212 CST
> > >Phone: [phone]           Syracuse, NY 13244-4100
> > >Fax:   [phone]           http://www.adiron.com
> >
>
>-------------------------------------------------------------------
>Polar Humenn                  Adiron, LLC
>mailto:[e-mail]      2-212 CST
>Phone: [phone]           Syracuse, NY 13244-4100
>Fax:   [phone]           http://www.adiron.com



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22467 for <[e-mail]>; Wed, 18 Oct 2000 11:09:08 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id OAA03951; Wed, 18 Oct 2000 14:09:59 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 14:09:59 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Russ Housley <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Oct 2000, Russ Housley wrote:

> Polar:
> 
> You are proposing syntax that is no longer compatible with X.509.  I am 
> very unhappy with such a deviation.

Hmmm. I only went on that taking into account Tom and Denises suggestion.
Do you feel that an attribute extension would be warranted instead?

Cheers,
-Polar

> 
> Russ
> 
> 
>    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> >
> > >> [SNIP]
> > >    ESSCertID ::=  SEQUENCE {
> > >         certHash                 Hash,
> > >         issuerSerial             IssuerSerial OPTIONAL
> > >    }
> > >
> > > and, in that case, having IssuerSerial present.
> > >
> > > Then we would need some additional text in the explanations to say that the
> > > hash of the certificate should also be tested.
> > >
> > > In this way, at the time of verification, there is no ambiguity about the
> > > link between the AC and the certificate, even if the CA has the same 
> > name as
> > > another CA certified from a different root key.
> >
> >Dennis,
> >
> >I still think that this solution doesn't quite solve the problem, but is a
> >good start.  In fact Tom Gindin's suggestion just came in and includes
> >yours. So I'll sort of work off of that.
> >
> >The fact is that the entityName option still contains a DN and the RP MUST
> >be prepared to accept it. However, on what conditions should the RP accept
> >the Holder as a DN? (Especially if this verification is offloaded to some
> >remote verification engine).
> >
> >Perhaps there is a way to word the USE of a DN entityName?
> >
> >When using an AC that contains the Holder specification as a DN entityName
> >option, the DN MUST verifiable and uniquely name an entity within the PKI
> >of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
> >ONLY create AttributeCertificates with the Holder as a DN entityName in
> >this fashion. This constraint is subject to the entire PKI for which the
> >AA belongs belongs to behave in its creation of unique DN. Therefore,
> >verification is subject to the trust the RP places in the AA and its PKI
> >together to conform to this behavior.
> >
> >[Note: this approach still does not solve the problem that Denis brings up
> >below as comment 43. A subordinate CA may be compromised within the PKI of
> >the AA and create impostor certificates, grabbing privileges.]
> >
> >Therefore, it would still probably be better to use the Issuer/Serial and
> >a hash of the Issuer's certificate, even if in the same PKI.
> >
> >Of course, when an application authenticates to an RP using PKCs this ties
> >the authorization to a particular certificate. Apparently that was not
> >desirable due to the effect of key rollover and new certificates being
> >issued to the same subject entity.
> >
> >However, I think that if as Carlise pointed out, that if the DN is only
> >used in the case of a single trusted Root, then everything will be fine.
> >
> >So, as Russ asked me to propose text, here it goes:
> >
> >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> >that is already defined in the document for the certificate Hash).
> >
> >Section 4.1:
> >
> >    Holder ::= SEQUENCE {
> >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> >                 -- the issuer and serial number of
> >                 -- the holder's Public Key Certificate
> >         entityName          [1] GeneralNames OPTIONAL,
> >                 -- the name of the claimant or role
> >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> >                 -- if present, version must be v2
> >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> >    }
> >
> >    IssuerSerialCertID ::=  SEQUENCE {
> >         isserCertDigest          ObjectDigestInfo,
> >         issuerSerial             IssuerSerial
> >    }
> >
> >In section 4.2.2 Holder add:
> >
> >When using an entityName that contains a DN, the DN MUST verifiably and
> >uniquely name an entity within the PKI of the AC issuer. The PKC named by
> >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> >MUST ONLY create AttributeCertificates with the Holder as a DN entityName
> >in this fashion. This constraint is subject to the entire PKI for which
> >the AC issuer belongs to behave in its creation of unique DNs. Therefore,
> >verification is also subject to the trust the RP places in the AC issuer's
> >PKI to conform to this behavior.
> >
> >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
> >inserting 2, 3, and 4 below, and renumbering accordingly).
> >
> >To be valid an AC MUST satisfy all of the following:
> >
> >1. The AC signature MUST be cryptographically correct, and the AC
> >    issuer's entire PKC certification path MUST be verified in
> >    accordance with [PKIXPROF].
> >
> >2. When the AC holder is named by a DN using the entityName option,
> >    the holder's PK certificate MUST be uniquely found under the same root
> >    CA as the AC issuer. The entire certification path of that PKC MUST be
> >    verified in accordance with [PKIXPROF].
> >
> >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> >    certificate MUST be uniquely found under the same root CA as
> >    the AC issuer. The entire certificate path of that PKC MUST
> >    be verified in accordance with [PKIXPROF].
> >
> >4. When the AC holder is named by a verifiedBaseCertificateID, the
> >    named holder issuer's PKC must be found, and that PKC MUST correctly
> >    digest to the digest value contained in the verifiedBaseCertificateID.
> >    The entire certificate path starting with the holder's PKC and the PKC
> >    of the issuer the holder's PKC MUST be verified in accordance
> >    with [PKIXPROF].
> >
> >.....
> >
> >Note: there is *still* a problem with AC targeting and proxying using
> >just DNs.
> >
> >Cheers,
> >-Polar
> >
> >
> >-------------------------------------------------------------------
> >Polar Humenn                  Adiron, LLC
> >mailto:[e-mail]       2-212 CST
> >Phone: [phone]           Syracuse, NY 13244-4100
> >Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22058 for <[e-mail]>; Wed, 18 Oct 2000 11:01:32 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 18 Oct 2000 11:06:39 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 18 Oct 2000 11:06:39 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VBCCGHQN>; Wed, 18 Oct 2000 11:04:09 -0700
Content-return: allowed
Date: Wed, 18 Oct 2000 11:00:50 -0700
From: Peter Williams <[e-mail]>
Subject: RE: TSP. Version 10
To: "'Tony Bartoletti'" <[e-mail]>, IETF-PXIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"
Deferred-delivery: Wed, 18 Oct 2000 11:04:00 -0700

Tony,

Or,

The operator of a time stamping service *asserts* (or may *represent*, or  
may *warrant*) that...


---------


Designating something as either providing evidence or supporting 
proof claims is not something that an Internet Standard can do,
legitimately, of one takes, as legally authoritative, Michael Baum's 
scorn of X.400's (1988) International Standard's ratified specifications 
of  "proof" and "non-repudiation" security services.

A real actor may assert, with varying degrees of accountability, that
a fact is, or may be, true. It takes someone skilled in and accountable
to scientific method or legal method to take these assertions and claim 
them either as evidence or as proof of another claim.

We should not deviate from the "assertion-centric" design already made in 
the name & certificate registration arena of PKIX. A DN is just a 
collection of assertions about the registration of real-world objects
by the naming authorities. It is not evidence or proof of anything. 
Similarly, certifying a key in a certificate provides per se no evidence,
nor 
does it per se support a proof of any claim. Both name registration, and 
key certification do hold the authority accountable for their management
procedures, however, assuming one can authenticate the 
authority's messages. Time stamping should be no different.

We should remain cognizant of the fact that different Internet communities
have different presumptive arrangements concerning legal evidence and 
legal proof. Unless I am mistaken, there is no citable claim of legal
analysis 
behind PKIX,  and no claim that we are forming or complying with any 
legal standards. Citing compliance to PKIX will provide a legal forum
no more certainty that citing to X.400 1988.

Peter.

-----Original Message-----
From: Tony Bartoletti [mailto:[e-mail]]
Sent: Wednesday, October 18, 2000 10:38 AM
To: Hal Lockhart; Denis Pinkas; IETF-PXIX
Subject: RE: TSP. Version 10


Or ...

   A time stamping service supports proof that ...

Or ...

   A time stamping service provides evidence that ...

___tony___

At 08:43 PM 10/17/00 -0400, Hal Lockhart wrote:

> > FYI, the abstract and the introduction are now as follows:
> >
> > Abstract
> >
> > A time stamping service allows to prove that a datum existed before
> > a particular time.
>
>I thought you would have fixed the fact that there seemes to be a word
>missing after "allows". What that word should be, ("one", "a party", "a
>user", "someone", "a subscriber")I do not know.
>
>Hal

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21611 for <[e-mail]>; Wed, 18 Oct 2000 10:52:30 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id NAA03884; Wed, 18 Oct 2000 13:53:10 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 13:53:09 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "Covey, Carlin" <[e-mail]>
cc: Denis Pinkas <[e-mail]>, Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Oct 2000, Covey, Carlin wrote:

> The wording of 2. below seems a bit misleading.  My understanding is that
> the security issue is a consequence of the fact that the entityName option
> deliberately permits mapping to more than one of the holder's PKC's (hence
> potentially to another user's PKC).  Perhaps instead of "... the holder's PK
> certificate MUST be uniquely found under the same root CA..." the wording
> should be "... a PK certificate MUST be found whose DN is unique under the
> same root CA..."

Hi Carlin,

I agree with your observation, but with the stipulation that we are
talking about the AC's Holder. With that in mind, the new 2:

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

Do you agree?

So, to keep the proposal all together, below is the same as before with
the new 2. and one minor editorial change in 4. I forgot an "of". :(

Cheers,
-Polar


Section 4.1:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
        verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
   }

   IssuerSerialCertID ::=  SEQUENCE {
        isserCertDigest          ObjectDigestInfo,
        issuerSerial             IssuerSerial
   }

In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

To be valid an AC MUST satisfy all of the following:

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateID, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer of the holder's PKC MUST be verified in accordance
   with [PKIXPROF].


Note: there is still a problem targets and proxies just using DNs.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21229 for <[e-mail]>; Wed, 18 Oct 2000 10:46:29 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA07007; Wed, 18 Oct 2000 10:50:38 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 18 Oct 2000 13:48:52 -0400
To: Polar Humenn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Polar:

You are proposing syntax that is no longer compatible with X.509.  I am 
very unhappy with such a deviation.

Russ


   At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
>On Wed, 18 Oct 2000, Denis Pinkas wrote:
>
> >> [SNIP]
> >    ESSCertID ::=  SEQUENCE {
> >         certHash                 Hash,
> >         issuerSerial             IssuerSerial OPTIONAL
> >    }
> >
> > and, in that case, having IssuerSerial present.
> >
> > Then we would need some additional text in the explanations to say that the
> > hash of the certificate should also be tested.
> >
> > In this way, at the time of verification, there is no ambiguity about the
> > link between the AC and the certificate, even if the CA has the same 
> name as
> > another CA certified from a different root key.
>
>Dennis,
>
>I still think that this solution doesn't quite solve the problem, but is a
>good start.  In fact Tom Gindin's suggestion just came in and includes
>yours. So I'll sort of work off of that.
>
>The fact is that the entityName option still contains a DN and the RP MUST
>be prepared to accept it. However, on what conditions should the RP accept
>the Holder as a DN? (Especially if this verification is offloaded to some
>remote verification engine).
>
>Perhaps there is a way to word the USE of a DN entityName?
>
>When using an AC that contains the Holder specification as a DN entityName
>option, the DN MUST verifiable and uniquely name an entity within the PKI
>of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
>ONLY create AttributeCertificates with the Holder as a DN entityName in
>this fashion. This constraint is subject to the entire PKI for which the
>AA belongs belongs to behave in its creation of unique DN. Therefore,
>verification is subject to the trust the RP places in the AA and its PKI
>together to conform to this behavior.
>
>[Note: this approach still does not solve the problem that Denis brings up
>below as comment 43. A subordinate CA may be compromised within the PKI of
>the AA and create impostor certificates, grabbing privileges.]
>
>Therefore, it would still probably be better to use the Issuer/Serial and
>a hash of the Issuer's certificate, even if in the same PKI.
>
>Of course, when an application authenticates to an RP using PKCs this ties
>the authorization to a particular certificate. Apparently that was not
>desirable due to the effect of key rollover and new certificates being
>issued to the same subject entity.
>
>However, I think that if as Carlise pointed out, that if the DN is only
>used in the case of a single trusted Root, then everything will be fine.
>
>So, as Russ asked me to propose text, here it goes:
>
>Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
>that is already defined in the document for the certificate Hash).
>
>Section 4.1:
>
>    Holder ::= SEQUENCE {
>         baseCertificateID   [0] IssuerSerial OPTIONAL,
>                 -- the issuer and serial number of
>                 -- the holder's Public Key Certificate
>         entityName          [1] GeneralNames OPTIONAL,
>                 -- the name of the claimant or role
>         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
>                 -- if present, version must be v2
>         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
>    }
>
>    IssuerSerialCertID ::=  SEQUENCE {
>         isserCertDigest          ObjectDigestInfo,
>         issuerSerial             IssuerSerial
>    }
>
>In section 4.2.2 Holder add:
>
>When using an entityName that contains a DN, the DN MUST verifiably and
>uniquely name an entity within the PKI of the AC issuer. The PKC named by
>the DN MUST verify back to the root CA of the AC issuer. The AC issuer
>MUST ONLY create AttributeCertificates with the Holder as a DN entityName
>in this fashion. This constraint is subject to the entire PKI for which
>the AC issuer belongs to behave in its creation of unique DNs. Therefore,
>verification is also subject to the trust the RP places in the AC issuer's
>PKI to conform to this behavior.
>
>In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
>inserting 2, 3, and 4 below, and renumbering accordingly).
>
>To be valid an AC MUST satisfy all of the following:
>
>1. The AC signature MUST be cryptographically correct, and the AC
>    issuer's entire PKC certification path MUST be verified in
>    accordance with [PKIXPROF].
>
>2. When the AC holder is named by a DN using the entityName option,
>    the holder's PK certificate MUST be uniquely found under the same root
>    CA as the AC issuer. The entire certification path of that PKC MUST be
>    verified in accordance with [PKIXPROF].
>
>3. When the AC holder is named by a baseCertificateId, the issuer's PK
>    certificate MUST be uniquely found under the same root CA as
>    the AC issuer. The entire certificate path of that PKC MUST
>    be verified in accordance with [PKIXPROF].
>
>4. When the AC holder is named by a verifiedBaseCertificateID, the
>    named holder issuer's PKC must be found, and that PKC MUST correctly
>    digest to the digest value contained in the verifiedBaseCertificateID.
>    The entire certificate path starting with the holder's PKC and the PKC
>    of the issuer the holder's PKC MUST be verified in accordance
>    with [PKIXPROF].
>
>.....
>
>Note: there is *still* a problem with AC targeting and proxying using
>just DNs.
>
>Cheers,
>-Polar
>
>
>-------------------------------------------------------------------
>Polar Humenn                  Adiron, LLC
>mailto:[e-mail]       2-212 CST
>Phone: [phone]           Syracuse, NY 13244-4100
>Fax:   [phone]           http://www.adiron.com



Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20479 for <[e-mail]>; Wed, 18 Oct 2000 10:25:13 -0700 (PDT)
Received: from asn-1.com (user-2ivf7le.dialup.mindspring.com [165.247.158.174]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA02057; Wed, 18 Oct 2000 13:29:29 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 13:32:42 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting  
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote (in part):
> 

snip 

> 
> The only problem is that this makes an ASN.1 definition different from the
> ISO X.509 definition. If we plan to adopt that change, then we should raise
> a defect report to ISO, which is, I think, a real defect: a comment for such
> a change was raised by AFNOR (comment numbered 43) and is marked in the
> disposition of comments "accepted in principal". I had not checked the text
> changes (I am always trusting Sharon), but apparently there has been no
> change done. :-(
> 

It is a really bad idea to break compatibility 
with an international standard you are attempting
to profile. Suggesting such a course of action is
ridiculous.

No matter how benign they may appear to be, any ASN.1
changes made to the AC profile in order to attempt to
force changes into X.509 would not be wise. This would
likely lead to two different notations for ACs.


Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20263 for <[e-mail]>; Wed, 18 Oct 2000 10:21:38 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA12835; Wed, 18 Oct 2000 10:25:33 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Wed, 18 Oct 2000 10:38:10 -0700
To: Hal Lockhart <[e-mail]>, Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: TSP. Version 10
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Or ...

   A time stamping service supports proof that ...

Or ...

   A time stamping service provides evidence that ...

___tony___

At 08:43 PM 10/17/00 -0400, Hal Lockhart wrote:

> > FYI, the abstract and the introduction are now as follows:
> >
> > Abstract
> >
> > A time stamping service allows to prove that a datum existed before
> > a particular time.
>
>I thought you would have fixed the fact that there seemes to be a word
>missing after "allows". What that word should be, ("one", "a party", "a
>user", "someone", "a subscriber")I do not know.
>
>Hal

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19574 for <[e-mail]>; Wed, 18 Oct 2000 09:55:01 -0700 (PDT)
Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id <VBLVWV5Y>; Wed, 18 Oct 2000 09:56:13 -0700
Message-ID: <[e-mail]>
From: "Covey, Carlin" <[e-mail]>
To: "'Polar Humenn'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Wed, 18 Oct 2000 09:56:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The wording of 2. below seems a bit misleading.  My understanding is that
the security issue is a consequence of the fact that the entityName option
deliberately permits mapping to more than one of the holder's PKC's (hence
potentially to another user's PKC).  Perhaps instead of "... the holder's PK
certificate MUST be uniquely found under the same root CA..." the wording
should be "... a PK certificate MUST be found whose DN is unique under the
same root CA..."

- Carlin Covey
  Cylink Corp.


> To be valid an AC MUST satisfy all of the following:
>
>  <snip>
>
>2. When the AC holder is named by a DN using the entityName option,
>   the holder's PK certificate MUST be uniquely found under the same root
>   CA as the AC issuer. The entire certification path of that PKC MUST be
>   verified in accordance with [PKIXPROF].



-----Original Message-----
From: Polar Humenn [mailto:[e-mail]]
Sent: Wednesday, October 18, 2000 9:39 AM
To: Denis Pinkas
Cc: Al Arsenault; Sharon Boeyen; Russ Housley; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt


On Wed, 18 Oct 2000, Denis Pinkas wrote:

>> [SNIP]
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
> 
> and, in that case, having IssuerSerial present.
>
> Then we would need some additional text in the explanations to say that
the
> hash of the certificate should also be tested.
> 
> In this way, at the time of verification, there is no ambiguity about the
> link between the AC and the certificate, even if the CA has the same name
as
> another CA certified from a different root key.

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

Perhaps there is a way to word the USE of a DN entityName? 

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

So, as Russ asked me to propose text, here it goes:

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
        verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
   }

   IssuerSerialCertID ::=  SEQUENCE {
        isserCertDigest          ObjectDigestInfo,
        issuerSerial             IssuerSerial
   }

In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

To be valid an AC MUST satisfy all of the following:

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar


-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com





Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19022 for <[e-mail]>; Wed, 18 Oct 2000 09:37:59 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id MAA03759; Wed, 18 Oct 2000 12:38:50 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 12:38:49 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Denis Pinkas <[e-mail]>
cc: Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Oct 2000, Denis Pinkas wrote:

>> [SNIP]
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
> 
> and, in that case, having IssuerSerial present.
>
> Then we would need some additional text in the explanations to say that the
> hash of the certificate should also be tested.
> 
> In this way, at the time of verification, there is no ambiguity about the
> link between the AC and the certificate, even if the CA has the same name as
> another CA certified from a different root key.

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

Perhaps there is a way to word the USE of a DN entityName? 

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

So, as Russ asked me to propose text, here it goes:

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
        verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
   }

   IssuerSerialCertID ::=  SEQUENCE {
        isserCertDigest          ObjectDigestInfo,
        issuerSerial             IssuerSerial
   }

In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

To be valid an AC MUST satisfy all of the following:

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar


-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com






Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17708 for <[e-mail]>; Wed, 18 Oct 2000 08:38:44 -0700 (PDT)
Received: (qmail 30306 invoked from network); 18 Oct 2000 15:30:48 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 18 Oct 2000 15:30:48 -0000
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 16:45:06 +0200
From: Pedro Miguel Pereira Borges <[e-mail]>
Reply-To: [e-mail]
Organization: Sociedade =?iso-8859-1?Q?Interbanc=E1ria?= de  =?iso-8859-1?Q?Servi=E7os?=, S.A.
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Lista IETF <[e-mail]>
Subject: Attribute Certificates II
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms903D23EB05C54940DE1300E2"

This is a cryptographically signed message in MIME format.

--------------ms903D23EB05C54940DE1300E2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


   Hi all :)

   I'm interested in Attribute Certificates and I tried to keep up with
the latest thread but since it was 37 mails long, at some point I was
lost...
   So sorry if this is a re-run :)
   Even so, after reading the latest version, I have some questions that
I hope you can make clearer for me :) :

        -> In section 4.2.3 it's said that all AC Issuers must be
identified by non-empty DNs. It's also said that "it means that the AC
Issuer does not have to know which PKC the verifier will use for it (the
AC Issuer). Using the baseCertificateID field to reference the AC Issuer
would mean that the AC verifier would have to trust the PKC that the AC
Issuer chosed (for itself) at the AC creation time.".
         =

           If that is so, then how does the relying party know what AC
Issuer PKC it should use to verify the signature on the AC ?

        -> If the holder is identified using the "entityName" field can
you assure that only the authentic holder can gain access to some
resource and not another party (with an equal DN) ?
          As far as I know, presenting the AC isn't enough... You also
have to present a proof of possesion (usually the signature of a
challenge) of something that only that identity knows (like the private
key corresponding to the cert's public key)...
           Am I wrong ?
           Or, when you use this field, who presents the AC gets the
access and that's it ?

        -> Regarding the previous point, if you use the
"objectDigestInfo" of a public key or cert, you could make that proof of
possesion right ?

        -> Are supposing that it's the job of a lower software
layer/protocol to verify/ensure that the AC is being presented by the
righteous owner ?
          If so, do you have any protocol in mind ?

   Thanks in advance,

        Pedro Borges   =


-----------------------------------------------------------------------
Pedro Miguel Pereira Borges                            <[e-mail]>
SIBS - Sociedade Interbanc=E1ria de Servi=E7os, S.A.  <http://www.sibs.pt=
/>
Rua Soeiro Pereira Gomes, Lote 1 - 1649-031 Lisboa, Portugal
Tel: + 351 21 791 88 00                         Fax: + 351 21 794 24 40
Certificate Fingerprint 20:A2:77:C5:15:5E:D7:A2:DF:D5:27:53:4A:99:94:37
-----------------------------------------------------------------------
This message was signed with a certificate issued by MULTICERT SIBS.
To validate the signature you must obtain the 'MULTICERT Pilot'
Certification Authority certificate, at http://www.sibs.multicert.com/
-----------------------------------------------------------------------
--------------ms903D23EB05C54940DE1300E2
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

MIIE1wYJKoZIhvcNAQcCoIIEyDCCBMQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A4swggOHMIIC8KADAgECAgQ3Tt9MMA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTAwMDMyNDEwNTIxOFoXDTAxMDMyNDExMjIx
OFowXjELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDjAMBgNVBAsTBURTSVNUMRUwEwYDVQQDEwxQZWRybyBCb3JnZXMwXDANBgkqhkiG
9w0BAQEFAANLADBIAkEA7fynacoDOKjRXpTOgsKNxdL9snCgaJ2qCWf1nF3rtq0vGQOuF/wl
Ao4Z1Zka1NJY9gVHEQNU7LddIgrIhEYnvQIDAQABo4IByjCCAcYwCwYDVR0PBAQDAgWgMCsG
A1UdEAQkMCKADzIwMDAwMzI0MTEyMjE4WoEPMjAwMDEyMDQyMzIyMThaMBEGCWCGSAGG+EIB
AQQEAwIFoDCBqQYJYIZIAYb4QgENBIGbFoGYQ2VydGlmaWNhZG8gUElMT1RPIE1VTFRJY2Vy
dC4gRXN0ZXMgY2VydGlmaWNhZG9zIHNhbyBlbWl0aWRvcyBhbyBhYnJpZ28gZG8gQ1BTIHF1
ZSBzZSBlbmNvbnRyYSBubyBzZWd1aW50ZSBVUkwgLSBodHRwczovL3d3dy5zaWJzLm11bHRp
Y2VydC5jb20vY3BzLmh0bWwwGQYDVR0RBBIwEIEOYm9yZ2VzQHNpYnMucHQwSgYDVR0fBEMw
QTA/oD2gO6Q5MDcxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MQ0w
CwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFLiWIG3WTfGiSQxdd4FPSyQIoi/lMB0GA1UdDgQW
BBSSbtjJjMglJqMVuQciltJ+9xiKkjAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY0
LjADAgOoMA0GCSqGSIb3DQEBBQUAA4GBAKGLb6p69LOewvfAGwzHhIOCiKLfFOBw5ZPOrQ8q
IVuUSliTpoEDjec4hIFgaVQE7lAqEZqh4FDu09FSylZkBSQrkH8LEvCk7H6Kj1HRXMb31/eI
jXjpUqOadjwLiACPFpYX5KisB3gw/oZBY15IossuXPuMUz4UWTN9OzqHynllMYIBFDCCARAC
AQEwMDAoMQswCQYDVQQGEwJQVDEZMBcGA1UEChMQUElMT1RPIE1VTFRJY2VydAIEN07fTDAJ
BgUrDgMCGgUAoH0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDAxMDE4MTQ0NTA2WjAeBgkqhkiG9w0BCQ8xETAPMA0GCCqGSIb3DQMCAgEoMCMGCSqGSIb3
DQEJBDEWBBTWoLQDymdR0PfiS40k5bVsfVU87jANBgkqhkiG9w0BAQEFAARA7GDbw2OsXIBT
xk4vY+wHsrS3PpnXgwA8zDNvnB7AUzA6Yf0ghYBpUKuk0Bby++EJRH/vgR+oWQ+m1oiPqsv/
oQ==
--------------ms903D23EB05C54940DE1300E2--



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14707 for <[e-mail]>; Wed, 18 Oct 2000 08:24:06 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA231636; Wed, 18 Oct 2000 11:28:46 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.94) with SMTP id LAA54722; Wed, 18 Oct 2000 11:28:30 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525697C.0054FE9C ; Wed, 18 Oct 2000 11:28:22 -0400
X-Lotus-FromDomain: IBMUS
To: Denis Pinkas <[e-mail]>
cc: Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 11:28:22 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Rather than making IETF's format completely incompatible with X.509,
there are two other possibilities which come to mind:

     First, adding the changed baseCertificateID as another option in
holder, as follows:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate
                 entityName          [1] GeneralNames OPTIONAL,
                          -- the name of the claimant or role
                 objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                          -- if present, version must be v2
     verifiedBaseCertificateID     FullESSCertID OPTIONAL
           }

   Full ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial
   }

     Second, adding the needed field as an extra field (the order of the
extra field is arbitrary, and some might prefer it immediately after
baseCertificateID):
           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate
                 entityName          [1] GeneralNames OPTIONAL,
                          -- the name of the claimant or role
                 objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                          -- if present, version must be v2
     baseCertHash   Hash OPTIONAL -- only present if baseCertificateID is
also
           }

     Third, defining an extension to contain the base certificate hash.

     Any of these changes would leave all legal X.509:2000 AC's still
legal, which is presumably desirable.  The first two options involve a
defect report against X.509.  I have avoided tags as they are not needed
here - and hardly ever are when all the existing members have them.

          Tom Gindin


Denis Pinkas <[e-mail]> on 10/18/2000 10:35:31 AM

To:   Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>
cc:   Russ Housley <[e-mail]>, [e-mail],
      [e-mail], [e-mail], [e-mail]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt



> Russ Housley wrote:
> >
> > I would like to redirect this thread.  We should be discussing the
changes
> > to the document.
> >
>
> AWA: An excellent suggestion!

I guess that everybody strongly agrees. :-)

> > What changes are needed to the base document that make it clear that
> > certification paths must be validated before the authorization
information
> > contained in an attribute certificate can be safely used?
> >
>
> AWA:  Section 5., Attribute Certificate Validation:
>
>         Add a new 1., and renumber other items appropriately:
>
>         To be valid an AC MUST satisfy all of the following:
>
>         1.   The AC holder's PK certificate must be found, and the entire
> certification path of that PKC MUST be verified in accordance with
> [PKIXPROF].
>
>         2. The AC signature must be cryptographically correct, and the AC
>         issuer's entire PKC certification path MUST be verified in
>         accordance with [PKIXPROF].
>         ...
> > What changes need to be made to the Security Considerations section to
> > avoid many of the problems discussed in this thread.  Carlisle Adams
made
> > the constructive comment that name constraints can be used to eliminate
> > many of these concerns.
> >
>
> AWA: I'm not wedded to the exact wording, but I'll propose:
>
>         There is a potential security issue when an attribute certificate
is
> issued to a holder and the holder's PKC chains back to a root CA that is
> independent from the root CA to which the AC issuer's PKC chains.
> "Independent" means that neither root CA is subordinate to the other,
> and they are not cross-certified.  The security issue is that two
> different PKCs, one under each of the two roots, can have the same
> issuer name and serial number, and this information will be in the AC
> holder field.  In this case, it may not be possible to identify to which
> PKC the AC is supposed to belong, and thus attributes may be associated
> with the wrong holder.

There is a way to (partially) "fix" this security hole. We currently have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate  ...

if we use ESSCertID (defined in RFC 2634 - CMS) instead of IssuerSerial
then
we have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] ESSCertID OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate ...

with

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

and, in that case, having IssuerSerial present.

Then we would need some additional text in the explanations to say that the
hash of the certificate should also be tested.

In this way, at the time of verification, there is no ambiguity about the
link between the AC and the certificate, even if the CA has the same name
as
another CA certified from a different root key.

The only problem is that this makes an ASN.1 definition different from the
ISO X.509 definition. If we plan to adopt that change, then we should raise
a defect report to ISO, which is, I think, a real defect: a comment for
such
a change was raised by AFNOR (comment numbered 43) and is marked in the
disposition of comments "accepted in principal". I had not checked the text
changes (I am always trusting Sharon), but apparently there has been no
change done. :-(

==========================================================================

Copy of the original comment 43 from AFNOR.

43. Page 30. Section 13.7. Attribute certificate syntax. There is a
security
weakness in the linkage of the attribute certificate with a public key
certificate, even when the baseCertificateId is used.

The current proposal provides no protection if the key of the CA is
compromised.

In such a case an attribute certificate could point to "CA from Delta
company, number 1234567" which is the certificate from Mr Dupont, but if
the
CA key is compromised then the attacker could forge a certificate with the
same serial number that would contain the name Mr Durand. The way to
counter
that threat is to include the hash of the public key certificate as well.
The ASN1 should be changed to a sequence of both the serial number and the
hash of the certificate and the corresponding explanations should be
adjusted accordingly.

IssuerSerial within the ASN1 syntax of Owner should be changed into:

CertificateUniqueIdentifier

with:

CertificateUniqueIdentifier ::= SEQUENCE {
     certSerialNumber    CertificateSerialNumber,
     certDigestInfo ObjectDigestInfo
}

==========================================================================

>
>         The primary solution to this issue is for RPs to only accept
AC/PKC
> combinations that chain back to a common root CA, or to CAs that (1) are
> cross-certified; and (2) enforce name constraints to ensure that there
> are not two issuers with the same names.

If there is a single trusted root CA, then the problem vanishes, :-) bit we
cannot mandate this.

For (1), we cannot either mandate cross-certificates and a single root.

For (2), name constraints are not that easy to handle. I would prefer the
use of the certificate hash, as indicated above to solve the issue and
others as indicated in the AFNOR comment 43. This is also simpler.

Denis

>
> > Can we focus on the text?
> >
> >    -- Russ
>
> Okay, take your shots at it.
>
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.





Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11328 for <[e-mail]>; Wed, 18 Oct 2000 07:31:21 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA32864; Wed, 18 Oct 2000 16:41:47 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA20106; Wed, 18 Oct 2000 16:35:28 +0200
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 16:35:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, Sharon Boeyen <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Russ Housley wrote:
> >
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 
> AWA: An excellent suggestion!

I guess that everybody strongly agrees. :-)

> > What changes are needed to the base document that make it clear that
> > certification paths must be validated before the authorization information
> > contained in an attribute certificate can be safely used?
> >
> 
> AWA:  Section 5., Attribute Certificate Validation:
> 
>         Add a new 1., and renumber other items appropriately:
> 
>         To be valid an AC MUST satisfy all of the following:
> 
>         1.   The AC holder's PK certificate must be found, and the entire
> certification path of that PKC MUST be verified in accordance with
> [PKIXPROF].
> 
>         2. The AC signature must be cryptographically correct, and the AC
>         issuer's entire PKC certification path MUST be verified in
>         accordance with [PKIXPROF].
>         ...
> > What changes need to be made to the Security Considerations section to
> > avoid many of the problems discussed in this thread.  Carlisle Adams made
> > the constructive comment that name constraints can be used to eliminate
> > many of these concerns.
> >
> 
> AWA: I'm not wedded to the exact wording, but I'll propose:
> 
>         There is a potential security issue when an attribute certificate is
> issued to a holder and the holder's PKC chains back to a root CA that is
> independent from the root CA to which the AC issuer's PKC chains.
> "Independent" means that neither root CA is subordinate to the other,
> and they are not cross-certified.  The security issue is that two
> different PKCs, one under each of the two roots, can have the same
> issuer name and serial number, and this information will be in the AC
> holder field.  In this case, it may not be possible to identify to which
> PKC the AC is supposed to belong, and thus attributes may be associated
> with the wrong holder.

There is a way to (partially) "fix" this security hole. We currently have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate  ...

if we use ESSCertID (defined in RFC 2634 - CMS) instead of IssuerSerial then
we have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] ESSCertID OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate ...

with 

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

and, in that case, having IssuerSerial present.

Then we would need some additional text in the explanations to say that the
hash of the certificate should also be tested.

In this way, at the time of verification, there is no ambiguity about the
link between the AC and the certificate, even if the CA has the same name as
another CA certified from a different root key.

The only problem is that this makes an ASN.1 definition different from the
ISO X.509 definition. If we plan to adopt that change, then we should raise
a defect report to ISO, which is, I think, a real defect: a comment for such
a change was raised by AFNOR (comment numbered 43) and is marked in the
disposition of comments "accepted in principal". I had not checked the text
changes (I am always trusting Sharon), but apparently there has been no
change done. :-(

==========================================================================

Copy of the original comment 43 from AFNOR.

43. Page 30. Section 13.7. Attribute certificate syntax. There is a security
weakness in the linkage of the attribute certificate with a public key
certificate, even when the baseCertificateId is used. 

The current proposal provides no protection if the key of the CA is
compromised. 

In such a case an attribute certificate could point to "CA from Delta
company, number 1234567" which is the certificate from Mr Dupont, but if the
CA key is compromised then the attacker could forge a certificate with the
same serial number that would contain the name Mr Durand. The way to counter
that threat is to include the hash of the public key certificate as well.
The ASN1 should be changed to a sequence of both the serial number and the
hash of the certificate and the corresponding explanations should be
adjusted accordingly.

IssuerSerial within the ASN1 syntax of Owner should be changed into: 

CertificateUniqueIdentifier

with:

CertificateUniqueIdentifier ::= SEQUENCE {
	certSerialNumber	CertificateSerialNumber,
	certDigestInfo	ObjectDigestInfo
}

==========================================================================

> 
>         The primary solution to this issue is for RPs to only accept AC/PKC
> combinations that chain back to a common root CA, or to CAs that (1) are
> cross-certified; and (2) enforce name constraints to ensure that there
> are not two issuers with the same names.

If there is a single trusted root CA, then the problem vanishes, :-) bit we
cannot mandate this. 

For (1), we cannot either mandate cross-certificates and a single root.

For (2), name constraints are not that easy to handle. I would prefer the
use of the certificate hash, as indicated above to solve the issue and
others as indicated in the AFNOR comment 43. This is also simpler.

Denis

> 
> > Can we focus on the text?
> >
> >    -- Russ
> 
> Okay, take your shots at it.
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10453 for <[e-mail]>; Wed, 18 Oct 2000 07:06:39 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA03496; Wed, 18 Oct 2000 10:07:26 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 18 Oct 2000 10:07:26 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Stephen Farrell <[e-mail]>
cc: Al Arsenault <[e-mail]>, Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: AC text changes
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 18 Oct 2000, Stephen Farrell wrote:

> 
> Hi Al,
> 
> Al Arsenault wrote:
> > 
> > Russ Housley wrote:
> > >
> > > I would like to redirect this thread.  We should be discussing the changes
> > > to the document.
> > >
> > 
> > AWA: An excellent suggestion!
> 
> Seconded. (Thirded?)
> 
> > 
> > > What changes are needed to the base document that make it clear that
> > > certification paths must be validated before the authorization information
> > > contained in an attribute certificate can be safely used?
> > >
> > 
> > AWA:  Section 5., Attribute Certificate Validation:
> > 
> >         Add a new 1., and renumber other items appropriately:
> > 
> >         To be valid an AC MUST satisfy all of the following:
> 
> 
> I'm nearly ok with this. Minor caveat is that I'd still like that
> the AC profile doesn't mandate PKCs for holder->RP authentication,
> so I'd tweak it to:
>  
> "1.   Where the holder uses a PKC to authenticate to the AC verifier, then 
> the AC holder's PKC MUST be found, and the entire certification path of 
> that PKC MUST be verified in accordance with [PKIXPROF]. As noted in 
> the security considerations section, if some other authentication scheme
> is used, AC verifiers need to be very careful mapping the identities
> (authenticated identity, holder field) involved."
> 
> Similarly, I'd tweak the security considerations section text:
> 
> "         There is a potential security issue when an attribute certificate is
>  issued to a holder and the holder's PKC chains back to a root CA that is
>  independent from the root CA to which the AC issuer's PKC chains.
>  "Independent" means that neither root CA is subordinate to the other,
>  and they are not cross-certified.  The security issue is that two
>  PKCs, (one under each of the two roots), belonging to two different holders, might 
>  have the same subject field or even issuer name and serial number, and this 
>  information will be in the AC holder field.  In this case, it may not be possible 
>  to identify which PKC authenticates the AC holder, and thus attributes may 
>  be associated with the wrong holder.
> 
>          One solution to this issue is for AC verifiers to only accept AC/PKC
>  combinations where both the holder's and AC's PKCs chain back to a common root CA, 
>  or to CAs that (1) are cross-certified; and (2) enforce name constraints to ensure 
>  that there are not two issuers with the same names. Failing this, AC verifiers
>  have to establish (using other means) that the potential collisions cannot
>  actually occur, for example, the CPSs of the CAs involved may make it clear that
>  no such name collisions can occur.


I don't know if Stephen saw my previous comment before he wrote this.
So, I'll just reiterate that stating that two issuers that have the same
names are not enough, especially when you must accept an entityName with a
DN in it. I'll propose a rewording of (1) and (2) togther:

Modified:

>          One solution to this issue is for AC verifiers to only accept AC/PKC
>  combinations where both the holder's and AC's PKCs chain back to a common root CA, 

or to CAs that are cross-certified such that name constraints are enforced
to ensure that there MUST NOT be two end entities with the same names.
Failing this, AC verifiers

>  have to establish (using other means) that the potential collisions cannot
>  actually occur, for example, the CPSs of the CAs involved may make it clear that
>  no such name collisions can occur.

I don't really like this last part, but I don't really understand the Law
that applies to CPSs and how it can enforce problems, especially
automatically. All it does do is prevent a ligitimate user from using its
privileges, because the AC verifier couldn't really be sure if there was
another legitmate or illegitimate user with the same name.

I am sad that the technology cannot be introduced to ensure that this
problem doesn't exist and all we can get out of it is a warning label on
the side of the box.

Cheers,
-Polar

> > Okay, take your shots at it.
> 
> Minor tweaks only:-)
> 
> BTW: There was also the issue raised by Tom Gindin (and supported by
> James Manger) about allowing entityName = subject *or* any subjectAltName
> (it currently only allows entityName = subject for this case). I asked folks 
> to comment, but only James supported it and no one objected. Failing 
> further comments, I'll include this change too.
> 
> Stephen.
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09190 for <[e-mail]>; Wed, 18 Oct 2000 06:24:01 -0700 (PDT)
Received: by balinese.baltimore.ie; id OAA10799; Wed, 18 Oct 2000 14:29:08 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma010671; Wed, 18 Oct 00 14:28:16 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA05607; Wed, 18 Oct 2000 14:28:08 +0100
Message-ID: <[e-mail]>
Date: Wed, 18 Oct 2000 14:31:44 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: AC text changes
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Al,

Al Arsenault wrote:
> 
> Russ Housley wrote:
> >
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 
> AWA: An excellent suggestion!

Seconded. (Thirded?)

> 
> > What changes are needed to the base document that make it clear that
> > certification paths must be validated before the authorization information
> > contained in an attribute certificate can be safely used?
> >
> 
> AWA:  Section 5., Attribute Certificate Validation:
> 
>         Add a new 1., and renumber other items appropriately:
> 
>         To be valid an AC MUST satisfy all of the following:


I'm nearly ok with this. Minor caveat is that I'd still like that
the AC profile doesn't mandate PKCs for holder->RP authentication,
so I'd tweak it to:
 
"1.   Where the holder uses a PKC to authenticate to the AC verifier, then 
the AC holder's PKC MUST be found, and the entire certification path of 
that PKC MUST be verified in accordance with [PKIXPROF]. As noted in 
the security considerations section, if some other authentication scheme
is used, AC verifiers need to be very careful mapping the identities
(authenticated identity, holder field) involved."

Similarly, I'd tweak the security considerations section text:

"         There is a potential security issue when an attribute certificate is
 issued to a holder and the holder's PKC chains back to a root CA that is
 independent from the root CA to which the AC issuer's PKC chains.
 "Independent" means that neither root CA is subordinate to the other,
 and they are not cross-certified.  The security issue is that two
 PKCs, (one under each of the two roots), belonging to two different holders, might 
 have the same subject field or even issuer name and serial number, and this 
 information will be in the AC holder field.  In this case, it may not be possible 
 to identify which PKC authenticates the AC holder, and thus attributes may 
 be associated with the wrong holder.

         One solution to this issue is for AC verifiers to only accept AC/PKC
 combinations where both the holder's and AC's PKCs chain back to a common root CA, 
 or to CAs that (1) are cross-certified; and (2) enforce name constraints to ensure 
 that there are not two issuers with the same names. Failing this, AC verifiers
 have to establish (using other means) that the potential collisions cannot
 actually occur, for example, the CPSs of the CAs involved may make it clear that
 no such name collisions can occur.

> Okay, take your shots at it.

Minor tweaks only:-)

BTW: There was also the issue raised by Tom Gindin (and supported by
James Manger) about allowing entityName = subject *or* any subjectAltName
(it currently only allows entityName = subject for this case). I asked folks 
to comment, but only James supported it and no one objected. Failing 
further comments, I'll include this change too.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA18973 for <[e-mail]>; Tue, 17 Oct 2000 19:57:24 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id WAA02771; Tue, 17 Oct 2000 22:57:49 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 17 Oct 2000 22:57:49 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 17 Oct 2000, Al Arsenault wrote:

> 
> 
> Russ Housley wrote:
> > 
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 
> AWA: An excellent suggestion!
>  
> > What changes are needed to the base document that make it clear that
> > certification paths must be validated before the authorization information
> > contained in an attribute certificate can be safely used?
> >
> 
> AWA:  Section 5., Attribute Certificate Validation:
> 
> 	Add a new 1., and renumber other items appropriately:
> 
> 	To be valid an AC MUST satisfy all of the following:
> 
>    	1.   The AC holder's PK certificate must be found, and the entire
> certification path of that PKC MUST be verified in accordance with
> [PKIXPROF].

Hmmm. I didn't realize that wasn't there, or I thought it was at least
implied by (2).

> 
> 	2. The AC signature must be cryptographically correct, and the AC
>         issuer's entire PKC certification path MUST be verified in
>         accordance with [PKIXPROF]. 
> 	...
> > What changes need to be made to the Security Considerations section to
> > avoid many of the problems discussed in this thread.  Carlisle Adams made
> > the constructive comment that name constraints can be used to eliminate
> > many of these concerns.
> >
> 
> AWA: I'm not wedded to the exact wording, but I'll propose:
> 
> 	There is a potential security issue when an attribute certificate is
                 ^^^^^^^^^^^
  There is a security issue

> issued to a holder and the holder's PKC chains back to a root CA that is
> independent from the root CA to which the AC issuer's PKC chains. 
> "Independent" means that neither root CA is subordinate to the other,
> and they are not cross-certified.  The security issue is that two
> different PKCs, one under each of the two roots, can have the same
> issuer name and serial number, and this information will be in the AC
> holder field.  In this case, it may not be possible to identify to which
> PKC the AC is supposed to belong, and thus attributes may be associated
> with the wrong holder.
> 
> 	The primary solution to this issue is for RPs to only accept AC/PKC
> combinations that chain back to a common root CA, or to CAs that (1) are
> cross-certified; and (2) enforce name constraints to ensure that there
> are not two issuers with the same names.

Oh well, I can't see what techincal merit can be brought forth in the
"Security Concerns" section, especially with no possible means of solving
the problem other than declaring you to have eminate domain over all
parties, AAs,RPs,PKC RootCAs, involved. I wouldn't really need a public
standard in that case.

In addition, the (2) is not good enough. You have to ensure that there are
no two issuers with the same names when using the Issuer-Serial
baseCertificateId option, or no two end entities with the same names.  Of
course, a Relying Party may not know what he's going to get handed to it,
Issuer-Serial or entityName, since he MUST accept both. Correct?
Therefore, all DNs MUST be unique. Of course, that does nothing for
established PKIs that *already* have name collisions, or the possiblity
for creating them.

Anyway, who does the enforcing? The RP or does the cross certification of
CAs have to figure out what name constraints don't issue collisions a
priori? That means they either have to permit all the trees that don't
have collisions, or either deny all the trees that do have collisions.
This is not simple. Especially if you want identities in those collision
spaces to actually do something.


Cheers,
-Polar

> > Can we focus on the text?
> > 
> >    -- Russ
> 
> 
> Okay, take your shots at it.
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17951 for <[e-mail]>; Tue, 17 Oct 2000 19:23:52 -0700 (PDT)
Received: from 216-164-129-214.s468.tnt1.lnhva.md.dialup.rcn.com ([216.164.129.214] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13liyP-0000Dv-00 ; Tue, 17 Oct 2000 22:28:57 -0400
Message-ID: <000801c038ab$af0e7fe0$d681a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Tue, 17 Oct 2000 22:32:35 -0400
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 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

I agree.  This sounds like good clarifying text.

Regards,
Rich

-----Original Message-----
From: Al Arsenault <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: Tuesday, October 17, 2000 10:06 PM
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt


>
>
>Russ Housley wrote:
>>
>> I would like to redirect this thread.  We should be discussing the
changes
>> to the document.
>>
>
>AWA: An excellent suggestion!
>
>> What changes are needed to the base document that make it clear that
>> certification paths must be validated before the authorization
information
>> contained in an attribute certificate can be safely used?
>>
>
>AWA:  Section 5., Attribute Certificate Validation:
>
> Add a new 1., and renumber other items appropriately:
>
> To be valid an AC MUST satisfy all of the following:
>
>   1.   The AC holder's PK certificate must be found, and the entire
>certification path of that PKC MUST be verified in accordance with
>[PKIXPROF].
>
> 2. The AC signature must be cryptographically correct, and the AC
>        issuer's entire PKC certification path MUST be verified in
>        accordance with [PKIXPROF].
> ...
>> What changes need to be made to the Security Considerations section to
>> avoid many of the problems discussed in this thread.  Carlisle Adams made
>> the constructive comment that name constraints can be used to eliminate
>> many of these concerns.
>>
>
>AWA: I'm not wedded to the exact wording, but I'll propose:
>
> There is a potential security issue when an attribute certificate is
>issued to a holder and the holder's PKC chains back to a root CA that is
>independent from the root CA to which the AC issuer's PKC chains.
>"Independent" means that neither root CA is subordinate to the other,
>and they are not cross-certified.  The security issue is that two
>different PKCs, one under each of the two roots, can have the same
>issuer name and serial number, and this information will be in the AC
>holder field.  In this case, it may not be possible to identify to which
>PKC the AC is supposed to belong, and thus attributes may be associated
>with the wrong holder.
>
> The primary solution to this issue is for RPs to only accept AC/PKC
>combinations that chain back to a common root CA, or to CAs that (1) are
>cross-certified; and (2) enforce name constraints to ensure that there
>are not two issuers with the same names.
>
>
>> Can we focus on the text?
>>
>>    -- Russ
>
>
>Okay, take your shots at it.
>
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17067 for <[e-mail]>; Tue, 17 Oct 2000 18:55:37 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Tue, 17 Oct 2000 18:57:17 -0700
Message-ID: <[e-mail]>
Date: Tue, 17 Oct 2000 21:57:22 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ Housley wrote:
> 
> I would like to redirect this thread.  We should be discussing the changes
> to the document.
>

AWA: An excellent suggestion!
 
> What changes are needed to the base document that make it clear that
> certification paths must be validated before the authorization information
> contained in an attribute certificate can be safely used?
>

AWA:  Section 5., Attribute Certificate Validation:

	Add a new 1., and renumber other items appropriately:

	To be valid an AC MUST satisfy all of the following:

   	1.   The AC holder's PK certificate must be found, and the entire
certification path of that PKC MUST be verified in accordance with
[PKIXPROF].

	2. The AC signature must be cryptographically correct, and the AC
        issuer's entire PKC certification path MUST be verified in
        accordance with [PKIXPROF]. 
	...
> What changes need to be made to the Security Considerations section to
> avoid many of the problems discussed in this thread.  Carlisle Adams made
> the constructive comment that name constraints can be used to eliminate
> many of these concerns.
>

AWA: I'm not wedded to the exact wording, but I'll propose:

	There is a potential security issue when an attribute certificate is
issued to a holder and the holder's PKC chains back to a root CA that is
independent from the root CA to which the AC issuer's PKC chains. 
"Independent" means that neither root CA is subordinate to the other,
and they are not cross-certified.  The security issue is that two
different PKCs, one under each of the two roots, can have the same
issuer name and serial number, and this information will be in the AC
holder field.  In this case, it may not be possible to identify to which
PKC the AC is supposed to belong, and thus attributes may be associated
with the wrong holder.

	The primary solution to this issue is for RPs to only accept AC/PKC
combinations that chain back to a common root CA, or to CAs that (1) are
cross-certified; and (2) enforce name constraints to ensure that there
are not two issuers with the same names.


> Can we focus on the text?
> 
>    -- Russ


Okay, take your shots at it.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14775 for <[e-mail]>; Tue, 17 Oct 2000 17:47:39 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id UAA05543; Tue, 17 Oct 2000 20:52:41 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <SSF7V0SN>; Tue, 17 Oct 2000 20:45:03 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: TSP. Version 10
Date: Tue, 17 Oct 2000 20:43:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> FYI, the abstract and the introduction are now as follows:
> 
> Abstract
> 
> A time stamping service allows to prove that a datum existed before 
> a particular time.

I thought you would have fixed the fact that there seemes to be a word
missing after "allows". What that word should be, ("one", "a party", "a
user", "someone", "a subscriber")I do not know.

Hal


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06652 for <[e-mail]>; Tue, 17 Oct 2000 12:42:22 -0700 (PDT)
Received: from RHOUSLEY-PC.spyrus.com ([209.172.119.210]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA23204; Tue, 17 Oct 2000 12:46:46 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 17 Oct 2000 15:46:52 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I would like to redirect this thread.  We should be discussing the changes 
to the document.

What changes are needed to the base document that make it clear that 
certification paths must be validated before the authorization information 
contained in an attribute certificate can be safely used?

What changes need to be made to the Security Considerations section to 
avoid many of the problems discussed in this thread.  Carlisle Adams made 
the constructive comment that name constraints can be used to eliminate 
many of these concerns.

Can we focus on the text?

   -- Russ



Received: from web218.mail.yahoo.com (web218.mail.yahoo.com [128.11.68.118]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03210 for <[e-mail]>; Tue, 17 Oct 2000 10:00:47 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [38.156.60.132] by web218.mail.yahoo.com; Tue, 17 Oct 2000 10:05:51 PDT
Date: Tue, 17 Oct 2000 10:05:51 -0700 (PDT)
From: julie whitfield <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Please unsubscribe from mailing list

=====
Red leader---OUT!!!

J

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24802 for <[e-mail]>; Tue, 17 Oct 2000 07:38:18 -0700 (PDT)
Received: from bpsi.net (port407.bpsi.net [209.54.245.207]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9HEhDp14555; Tue, 17 Oct 2000 09:43:13 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Tue, 17 Oct 2000 09:40:51 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Stephen,
<p>Comments inline.
<p>Best Regards,
<p>--dg
<p>Stephen Farrell wrote:
<blockquote TYPE=CITE>Hi Dale,
<p>> What I mean is a value that maps, cryptographically, to only one certificate.
<p>Ok there are lots of examples of pointing to one certificate all right,
however,
<br>I don't know of any that point to one certificate *path*, which is
what I thought
<br>you meant.
<p>> I think the potential attack described earlier is that a bad guy would
intentionally assume the
<br>> name of a legitimate CA for the express purpose of gaining use of
permissions, etc. provided by
<br>> someone else's AC.&nbsp; So we can't say this is unlikely to occur.
<p>Yes, but that attack applies in all PKI cases - it amounts to
<br>grabbing the root configuration information of the RP, as
<br>discussed in Al's earlier message. If we need new bits on the
<br>wire to protect against this, then that'd affect all PKIX
<br>specifications and probably S/MIME, TLS and IPSec too. Do we
<br>really need to go there? I don't believe so. (And I certainly
<br>don't want to either:-) I can't see any reason why the AC
<br>profile is any different from any of those, in the face of
<br>"stomping on root CA configuration" attacks.
<p>And so I don't see any need to add such new attributes to an AC.</blockquote>
I believe the potential attack consisted of replacing the entire PKC chain.&nbsp;
This could done if the Holder's PKC was identified only by issuer and serial
number within the AC and the attacker was somehow able to get a different
key (and the holder's DN and serial number) certified by any other accepted
CA.
<p>A significant difference in the AC case is that the Holder's public
key is outside of the AC so there needs to be a solid link from the AC
to the holder's PKC.
<p>If referencing the holder's PKC only (rather than a specific PKC chain)
is architecturally more elegant, then I agree that's a better solution.
<br>&nbsp;
<blockquote TYPE=CITE>Stephen.
<p>--
<br>____________________________________________________________
<br>Stephen Farrell
<br>Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) [phone]
<br>61 Fitzwilliam Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: [phone]
<br>Dublin 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<a href="mailto:[e-mail]">mailto:[e-mail]</a>
<br>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<a href="http://www.baltimore.com">http://www.baltimore.com</a></blockquote>
</html>



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22212 for <[e-mail]>; Tue, 17 Oct 2000 06:01:27 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id JAA01543; Tue, 17 Oct 2000 09:01:59 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 17 Oct 2000 09:01:59 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: [e-mail], Carlisle Adams <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 16 Oct 2000, Al Arsenault wrote:

> > [SNIPPED] 
> 
> AWA: Well, those who know me know that I've been called "paranoid" and a
> lot of other things in my 17+ years in this security business, now. 
> (Actually, I can think of at least 4 regular contributors to this list
> who have called me "paranoid" at one point or another. :-) I'm generally
> seen as one unwilling to accept even the tiniest of security holes. 
> However, in this case, I think that it comes down to a tradeoff:
> 
> 	- if the RP trusts two independent Root CAs, then there is a chance
> that the two Roots can have sub-CAs that cause naming collisions.  This
> applies to ACs or PKCs.
> 
> 	- if you don't want to accept that risk, then as Carlisle has
> suggested, you simply operate in an environment in which you don't do
> this.  You make everything be "one PKI", chaining back to the "one true
> Root" that you choose to/have to trust.
> 
> 	- on the other hand, the benefits of accepting two independent Roots
> are that you can work in two different environments, simultaneously,
> without worrying about the relationship of the Roots themselves.  If I
> want to use a DVNT cert issued under a DST root, and a VeriSign cert
> under a VeriSign root, and an Entrust cert issued under an XYZ root, I
> really don't want to care about the relationships among the top levels. 
> If I choose to take the risk, it's my choice.
> 
> So: benefits of "two PKIs" vs. risks of naming collisions. Sounds like a
> trade-off to me. One I think that we ought to allow.


So, Al, Let me guess.
You are still driving your Ford Explorer with the Bridgestone tires on it.
:)

-Polar

> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21566 for <[e-mail]>; Tue, 17 Oct 2000 05:44:22 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 17 Oct 2000 05:49:25 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Tue, 17 Oct 2000 05:49:25 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VBCCGDMA>; Tue, 17 Oct 2000 05:46:59 -0700
Content-return: allowed
Date: Tue, 17 Oct 2000 05:46:58 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: question about certificate path length
To: "'Hiroyuki Sakakibara'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-2022-jp"

Hiroyuki,

I believe that your understanding is correct.

Note that draft-ietf-pkix-new-part1-02.txt's definition of the basic
constraints extension (section 4.2.1.10) clears up ambiguities found in RFC
2459's definition. For example, draft-ietf-pkix-new-part1-02.txt states:

This extension MAY appear as a critical or non-critical extension in end
entity certificates.

where RFC 2459 says:

This extension SHOULD NOT appear in end entity certificates.

Frank


In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,
> 

When validating

section 3

   end entity:  user of PKI certificates and/or end user system that
                is the subject of a certificate;



4.2.1.10  
   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.




   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.





> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[e-mail]]
> Sent: Tuesday, October 17, 2000 2:55 AM
> To: [e-mail]
> Subject: question about certificate path length
> 
> 
> Hi.
> 
> I have a question about difference between "certificate path 
> length" and
> "pathLenConstraint field in the basicConstraint extension".
> 
> >Internet X.509 Public Key Infrastructure
> >Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> >July 14, 2000
> 
> >4.2.1.10  Basic Constraints
> >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> >   In this case, it gives the maximum number of CA certificates that
> >may follow this certificate in a certification path."
> 
> SNIP
> 
> >6.1 Basic Path Validation
> 
> >To meet this goal, the path validation process verifies, among other
> >things, that a prospective certification path (a sequence of n certi-
> >ficates) satisfies the following conditions:
> >      (i) for all x in {1, ..., n-1}, the subject of certificate x is
> >      the issuer of certificate x+1;
> >      (ii) certificate 1 is issued by the trust anchor;
> >      (iii) certificate n is the end entity certificate; and
> >      (iv) for all x in {1, ..., n}, the certificate was valid at the
> >      time in question.
> SNIP
> >(inputs)
> >(a) a prospective certification path of length n;
> 
> >State variable initialization
> >(l) max_path_length:  this integer is initialized to n, and is
> >      reset by the path length constraint field within the basic con-
> >      straints extension of a CA certificate.
> 
> Referencing "Internet X.509 Public Key Infrastructure
> Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> July 14, 2000"
>  I will describe my understanding.
> 
> For example,
> 
> CAa : trust anchor
> CAb : subordinate CA of CAa
> CAc : subordinate CA of CAb
> CAd : subordinate CA of CAc
> EE   : subordinate user of CAd
> 
> Cert_a : CAa's self-signed certificate
> Cert_b : CAb's certificate issued by CAa
> Cert_c : CAb's certificate issued by CAb
> Cert_d : CAb's certificate issued by CAc
> Cert_user : user's certificate issued by CAd
> 
> In this case, certificate path is
> 
> Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user
> 
> therefore, the length of the certificate path is "5".
> 
> On the other hand, if CAa restricts the number of subordinates
> CAs, 3, actually to CAd in this case, the pathLenConstraint value
> in Cert_a is 3.
> 
> because
> 
> >4.2.1.10  Basic Constraints
> >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> >   In this case, it gives the maximum number of CA certificates that
> >may follow this certificate in a certification path."
> 
> So, in general, the length of the certificate path means 
> that, the number of
> chained
> certificates, from the trust anchor CA's certificate to EE( 
> user or CA)
> certificate,
> as shown above
> ( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).
> 
> In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,
> therefore the length of the certificate path is 2.
> 
> Consequently, if someone handles the Cert_a as the trust anchor CA's
> certificate,
> he sees that the maximam path length is 5, because pathLenConstraint
> in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then 
> gets the length as
> 5.
> 
> Am I misunderstanding ?
> 
> ---------------------------------------
> Hiroyuki Sakakibara
> MITSUBISHI ELECTRIC CORPORATION
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> PHONE: [phone]
> FAX:   [phone]
> E-mail : [e-mail]
> 


Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19050 for <[e-mail]>; Tue, 17 Oct 2000 04:29:23 -0700 (PDT)
Received: by florida.melco.co.jp (florida) id UAA00990; Tue, 17 Oct 2000 20:33:57 +0900 (JST)
Received: by mailgw.melco.co.jp (mailgw) id UAA18701; Tue, 17 Oct 2000 20:34:24 +0900 (JST)
Received: by mr01.melco.co.jp (mr01) id UAA27345; Tue, 17 Oct 2000 20:34:23 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id UAA03250; Tue, 17 Oct 2000 20:34:22 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id UAA01896; Tue, 17 Oct 2000 20:34:22 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id UAA16313; Tue, 17 Oct 2000 20:34:55 +0900 (JST)
Message-ID: <004201c0382e$6b0fe9f0$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: Re: question about certificate path length
Date: Tue, 17 Oct 2000 20:35:57 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi

There was misdescription in the posted mail.

[WRONG]
> Cert_a : CAa's self-signed certificate
> Cert_b : CAb's certificate issued by CAa
> Cert_c : CAb's certificate issued by CAb
> Cert_d : CAb's certificate issued by CAc
> Cert_user : user's certificate issued by CAd

[CORRECT]
Cert_a : CAa's self-signed certificate
Cert_b : CAb's certificate issued by CAa
Cert_c : CAc's certificate issued by CAb
Cert_d : CAd's certificate issued by CAc
Cert_user : user's certificate issued by CAd

I'm sorry.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]




Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10255 for <[e-mail]>; Mon, 16 Oct 2000 23:49:01 -0700 (PDT)
Received: by florida.melco.co.jp (florida) id PAA01220; Tue, 17 Oct 2000 15:53:30 +0900 (JST)
Received: by mailgw.melco.co.jp (mailgw) id PAA05601; Tue, 17 Oct 2000 15:53:53 +0900 (JST)
Received: by mr02.melco.co.jp (mr02) id PAA23656; Tue, 17 Oct 2000 15:53:50 +0900 (JST)
Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id PAA12268; Tue, 17 Oct 2000 15:53:47 +0900 (JST)
Received: from iss.isl.melco.co.jp by islgw.isl.melco.co.jp (8.8.8/3.6W) id PAA13591; Tue, 17 Oct 2000 15:53:46 +0900 (JST)
Received: from belize by iss.isl.melco.co.jp (8.8.8/3.6W) id PAA11624; Tue, 17 Oct 2000 15:54:19 +0900 (JST)
Message-ID: <006101c03807$382fb0f0$[e-mail]>
From: "Hiroyuki Sakakibara" <[e-mail]>
To: <[e-mail]>
Subject: question about certificate path length
Date: Tue, 17 Oct 2000 15:55:21 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hi.

I have a question about difference between "certificate path length" and
"pathLenConstraint field in the basicConstraint extension".

>Internet X.509 Public Key Infrastructure
>Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
>July 14, 2000

>4.2.1.10  Basic Constraints
>"The pathLenConstraint field is meaningful only if cA is set to TRUE.
>   In this case, it gives the maximum number of CA certificates that
>may follow this certificate in a certification path."

SNIP

>6.1 Basic Path Validation

>To meet this goal, the path validation process verifies, among other
>things, that a prospective certification path (a sequence of n certi-
>ficates) satisfies the following conditions:
>      (i) for all x in {1, ..., n-1}, the subject of certificate x is
>      the issuer of certificate x+1;
>      (ii) certificate 1 is issued by the trust anchor;
>      (iii) certificate n is the end entity certificate; and
>      (iv) for all x in {1, ..., n}, the certificate was valid at the
>      time in question.
SNIP
>(inputs)
>(a) a prospective certification path of length n;

>State variable initialization
>(l) max_path_length:  this integer is initialized to n, and is
>      reset by the path length constraint field within the basic con-
>      straints extension of a CA certificate.

Referencing "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
July 14, 2000"
 I will describe my understanding.

For example,

CAa : trust anchor
CAb : subordinate CA of CAa
CAc : subordinate CA of CAb
CAd : subordinate CA of CAc
EE   : subordinate user of CAd

Cert_a : CAa's self-signed certificate
Cert_b : CAb's certificate issued by CAa
Cert_c : CAb's certificate issued by CAb
Cert_d : CAb's certificate issued by CAc
Cert_user : user's certificate issued by CAd

In this case, certificate path is

Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user

therefore, the length of the certificate path is "5".

On the other hand, if CAa restricts the number of subordinates
CAs, 3, actually to CAd in this case, the pathLenConstraint value
in Cert_a is 3.

because

>4.2.1.10  Basic Constraints
>"The pathLenConstraint field is meaningful only if cA is set to TRUE.
>   In this case, it gives the maximum number of CA certificates that
>may follow this certificate in a certification path."

So, in general, the length of the certificate path means that, the number of
chained
certificates, from the trust anchor CA's certificate to EE( user or CA)
certificate,
as shown above
( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).

In the case of validating Cert_b as  EE certificate, the certificate path is
Cert_a -> Cert_b,
therefore the length of the certificate path is 2.

Consequently, if someone handles the Cert_a as the trust anchor CA's
certificate,
he sees that the maximam path length is 5, because pathLenConstraint
in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then gets the length as
5.

Am I misunderstanding ?

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: [phone]
FAX:   [phone]
E-mail : [e-mail]



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04591 for <[e-mail]>; Mon, 16 Oct 2000 19:40:42 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA03191; Tue, 17 Oct 2000 12:52:25 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <VAHVC0HA>; Tue, 17 Oct 2000 13:43:41 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Frank Balluffi <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Tue, 17 Oct 2000 13:43:41 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Frank,

The path discovery algorithm is [meant to be] deterministic. Theoretically,
two different DPD boxes, regardless if they execute the same or different
path building algorithms, should come up with the same path for the same
certificate, provided that the input conditions are identical. The order of
components in the path may vary, though, but it doesn't change a lot.

Therefore it should be reasonable to expect that a path generated/obtained
by the DPV will be identical to a path generated by any compliant
path-discovery engine.

Michael

> -----Original Message-----
> From: Frank Balluffi [mailto:[e-mail]]
> Sent: Tuesday, 17 October 2000 12:10
> To: 'Michael Zolotarev'; Frank Balluffi; Michael Myers;
> [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael Zolotarev said:
> 
> > To find out why 'No', a client can use DPD to get the path, 
> > and then ask DPV
> > for each component in the path.
> 
> I agree that a client should be able to request the path used 
> during DPV,
> but I do not see any guarantee that a DPD response will 
> contain the path
> used to generate a previous DPV response. Is my understanding correct?
> 
> Frank
> 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA03885 for <[e-mail]>; Mon, 16 Oct 2000 19:14:35 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 16 Oct 2000 19:19:36 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 16 Oct 2000 19:19:36 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VBCCGCMC>; Mon, 16 Oct 2000 19:17:12 -0700
Content-return: allowed
Date: Mon, 16 Oct 2000 19:17:11 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[e-mail]>, Michael Myers <[e-mail]>, Frank Balluffi <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Michael Zolotarev said:

> Frank - I'm still standing on attention to hear why do you 
> think a client
> may want to know 'why Yes'. No jokes. That'd be one of the 
> major requirement
> for audit performed on DPV, if there is for example a legal reason, or
> something...

If a server were to apply a policy not requested by a client, returning this
information to the client might be valuable. Obviously, this assumes that
the protocol allows such behavior.

Frank


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA03441 for <[e-mail]>; Mon, 16 Oct 2000 19:07:24 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 16 Oct 2000 19:12:20 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 16 Oct 2000 19:12:20 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <VBCCGCLS>; Mon, 16 Oct 2000 19:09:56 -0700
Content-return: allowed
Date: Mon, 16 Oct 2000 19:09:55 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[e-mail]>, Frank Balluffi <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Michael Zolotarev said:

> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.

I agree that a client should be able to request the path used during DPV,
but I do not see any guarantee that a DPD response will contain the path
used to generate a previous DPV response. Is my understanding correct?

Frank


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25951 for <[e-mail]>; Mon, 16 Oct 2000 14:09:39 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA00566; Mon, 16 Oct 2000 17:10:25 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 16 Oct 2000 17:10:24 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Stephen Farrell <[e-mail]>
cc: Dale Gustafson <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi, 

comments below.

On Mon, 16 Oct 2000, Stephen Farrell wrote:

> 
> Hi Dale,
> 
> > What I mean is a value that maps, cryptographically, to only one certificate.  
> 
> Ok there are lots of examples of pointing to one certificate all right, however,
> I don't know of any that point to one certificate *path*, which is what I thought
> you meant.
> 
> > I think the potential attack described earlier is that a bad guy would intentionally assume the
> > name of a legitimate CA for the express purpose of gaining use of permissions, etc. provided by
> > someone else's AC.  So we can't say this is unlikely to occur.
> 
> Yes, but that attack applies in all PKI cases - it amounts to 
> grabbing the root configuration information of the RP, as 
> discussed in Al's earlier message. If we need new bits on the
> wire to protect against this, then that'd affect all PKIX
> specifications and probably S/MIME, TLS and IPSec too. Do we 
> really need to go there? I don't believe so. (And I certainly 
> don't want to either:-) I can't see any reason why the AC 
> profile is any different from any of those, in the face of 
> "stomping on root CA configuration" attacks.

I will not deny that if you grab root configuration information of any RP
that you have a problem in the PKI space. However, this attack doesn't
require you to grab the root configuration. It merely relies on a name
collision whether it is malicious or coincidental.

With AC's you have an indirection problem because you are "naming" a
holder with a DN. You are not doing ANY verification on anything common
between the RP and the AA with respect to the holder.

In TLS you are not naming anything. You present the certificate chain. The
chain has all the evidence you need to do verification of the subject of
the certificate chain. It verifies the authentication signature.

In applications of S/MIME, you are looking to verify a signature of the
subject. You can send the subject's certificate chain if you wish, which
reduces the problem to TLS above. In the advent that you don't send the
certificates, you can name the subject's certificate, but you still have
something, a signature that needs to be verified. So, if you don't get the
correct certificate verification of that signature CANNOT happen.

If in AC's you only name the Holder using its DN you have the following
problem. If you have the possibility of having [CA1,Holder] and
[CA2,Holder] (i.e. a name collision between the CA1 and CA2 spaces) where
[x,y] means x certifies y, in your believable world, there is nothing the
RP can do with just the AC to verify that the AC is certifying CA1's
Holder as opposed to CA2's Holder.

I don't have to grab anybody's root configuration information.

Cheers,
-Polar

> And so I don't see any need to add such new attributes to an
> AC.
> 
> Stephen.
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25733 for <[e-mail]>; Mon, 16 Oct 2000 14:08:13 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Mon, 16 Oct 2000 14:13:13 -0700
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 17:14:31 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: [e-mail], Carlisle Adams <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments in-line, prefaced by my initials, again.

Polar Humenn wrote:
> 
> On Mon, 16 Oct 2000, Al Arsenault wrote:
> 
> <snip>
> I thought it was the case as well, that the AC can really bridge three
> PKIs. That means the holder, the AA, and the RP all can have their own
> different PKIs with the possibility of cross-certification of all three. I
> don't even see a need for cross certification in the model. My browser
> "trusts" 137 root certificates without cross-certification, and nobody
> seems to care all that much.

AWA:  Actually, I think that that's a *really band thing*.  Antime I get
a new browser installed, one of the first things I do is go delete all
the default CA certs, and then add 'em back one at a time as I need to. 
Among other things, it lets you see which certs are really being used.

> 
> > In my opinion, the "security hole" pointed out by Polar can in fact
> > occur, either maliciously or by "accident". (e.g., if the holder's PKC
> > chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> > then there can be a cert under root_CA_2 with the same DN,
> > subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> > both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> > tell which holder PKC to use. And it gets even more interesting if the
> > RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> > right cert is the one under root_CA_2, and thus everything validates; or
> > does the RP think that the right holder PKC is the one under root_CA_1,
> > and thus reject the AC?)
> >
> > However, I do not believe that the right thing to do is either mandate
> > the objectDigest form in the AC, or kill the AC draft.  And I don't
> > think it's to insert the requirement that the holder's PKC and the AA's
> > PKC chain back to the same root. Rather, I think that the best approach
> > is to acknowledge that this risk exists, and live with it. Put in an
> > explanation (in Security Considerations, in some other section - in the
> > Roadmap, too, in all likelihood - that says that if you trust two
> > independent Root CAs, then this is a risk you run.
> 
> This brush off seems to be a hard call for a group that worried so much
> about the security and trust relationships of PKI to begin with.
> 
> Well, at the very least, I'm glad that some people in the group actually
> see the problem. Whether it amounts to anything significant, I can only
> hope.
> 
> I cannot recommend the use of such products and services, except in
> tightly controlled environments, which rules out e-commerce on the
> internet, or even business-to-business on the internet, or anything on the
> internet. Call me paranoid, but I am a security person, not an issurance
> salesman. Unfortunately, I'd probably make a lot more money if I were the
> latter. :)
> 

AWA: Well, those who know me know that I've been called "paranoid" and a
lot of other things in my 17+ years in this security business, now. 
(Actually, I can think of at least 4 regular contributors to this list
who have called me "paranoid" at one point or another. :-) I'm generally
seen as one unwilling to accept even the tiniest of security holes. 
However, in this case, I think that it comes down to a tradeoff:

	- if the RP trusts two independent Root CAs, then there is a chance
that the two Roots can have sub-CAs that cause naming collisions.  This
applies to ACs or PKCs.

	- if you don't want to accept that risk, then as Carlisle has
suggested, you simply operate in an environment in which you don't do
this.  You make everything be "one PKI", chaining back to the "one true
Root" that you choose to/have to trust.

	- on the other hand, the benefits of accepting two independent Roots
are that you can work in two different environments, simultaneously,
without worrying about the relationship of the Roots themselves.  If I
want to use a DVNT cert issued under a DST root, and a VeriSign cert
under a VeriSign root, and an Entrust cert issued under an XYZ root, I
really don't want to care about the relationships among the top levels. 
If I choose to take the risk, it's my choice.

So: benefits of "two PKIs" vs. risks of naming collisions. Sounds like a
trade-off to me. One I think that we ought to allow.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24582 for <[e-mail]>; Mon, 16 Oct 2000 13:21:22 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id QAA00493; Mon, 16 Oct 2000 16:22:08 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 16 Oct 2000 16:22:08 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I do not agree with Carlisle that the AC must verify to the same root CAs
and cross-certifications of root CAs. Nor do I think that
cross-certification eliminates name clashes in the DN space. Nor do I
think that cross-certification is actually required for it to work.

I think all naming schemes follow the basic structure of a name and an
ubiquitous identifiable scope.

Likewise, the AC Holder should have the same thing. If you end up naming
the Holder with a DN you must have a scope in which that name is defined.

Naming the Holder's Root CA (DN) and a hash of its certificate, and maybe
a path length, would probably close the door on this security hole. This
approach names the Holder and its PKI, i.e. name and scope. The scope for
the Holder can be implemented as a standard optional critical attribute.
It isn't a hint, it needs to be verified.

That way AAs and RPs have a way to make sure this door on this security
hole doesn't open. Without it you are forced to accept a risk in using
this technology.

I still have to remind the group that the same exact problems exist with
naming of Proxies and Targets of the AC. Maybe new attributes should be
invented that replace the current ProxyInfo and TargetInfo that names the
proxy or target and the scope of each.

Cheers,
-Polar


-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23524 for <[e-mail]>; Mon, 16 Oct 2000 12:43:53 -0700 (PDT)
Received: by balinese.baltimore.ie; id UAA15042; Mon, 16 Oct 2000 20:48:48 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma015016; Mon, 16 Oct 00 20:47:51 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.ie.baltimore.com (8.9.3/8.9.3) with ESMTP id UAA02705; Mon, 16 Oct 2000 20:47:51 +0100
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 20:51:32 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dale Gustafson <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Dale,

> What I mean is a value that maps, cryptographically, to only one certificate.  

Ok there are lots of examples of pointing to one certificate all right, however,
I don't know of any that point to one certificate *path*, which is what I thought
you meant.

> I think the potential attack described earlier is that a bad guy would intentionally assume the
> name of a legitimate CA for the express purpose of gaining use of permissions, etc. provided by
> someone else's AC.  So we can't say this is unlikely to occur.

Yes, but that attack applies in all PKI cases - it amounts to 
grabbing the root configuration information of the RP, as 
discussed in Al's earlier message. If we need new bits on the
wire to protect against this, then that'd affect all PKIX
specifications and probably S/MIME, TLS and IPSec too. Do we 
really need to go there? I don't believe so. (And I certainly 
don't want to either:-) I can't see any reason why the AC 
profile is any different from any of those, in the face of 
"stomping on root CA configuration" attacks.

And so I don't see any need to add such new attributes to an
AC.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21611 for <[e-mail]>; Mon, 16 Oct 2000 11:45:44 -0700 (PDT)
Received: from bpsi.net (port442.bpsi.net [209.54.245.242]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9GIoYp13409; Mon, 16 Oct 2000 13:50:34 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 13:48:11 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Stephen,
<p>Comments inline.
<p>Best Regards,
<p>Dale Gustafson
<br>&nbsp;
<p>Stephen Farrell wrote:
<blockquote TYPE=CITE>Dale,
<p>> I think Polar is saying that an AC should be able to (optionally)
contain a
<br>> pointer to "one and only one" PKC chain.&nbsp; This seems like a
reasonable
<br>> requirement given that this same concept has already been defined
in several
<br>> forms for a single PKC within RFC-2459, RFC-2560, et. al.
<p>I'm not sure what you mean here, AFAIK neither RFC contains such a
<br>structure or requirement.</blockquote>
What I mean is a value that maps, cryptographically, to only one certificate.&nbsp;
For example if you create a pointer structure that includes a hash of the
target certificate then you can be pointing to only one certificate (since
two different certificates cannot produce the same hash value).
<p>So a pointer to a single certificate might be something like:
<p><tt>&nbsp;&nbsp; CertPTR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issuerName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Name, -- Issuer's DN</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; serialNumber&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CertificateSerialNumber,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hashAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AlgorithmIdentifier,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certHash&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OCTET STRING -- hash of certificate including issuer's signature }</tt>
<p>PKIX RFCs and drafts have used several variations of this technique
to create a pointer to a specific certificate.&nbsp; For example, RFC-2560,
page 7, defines "CertID" which includes a hash of the issuer name and a
hash of the issuer's public key value.
<br>&nbsp;
<blockquote TYPE=CITE>> PKI providers could still follow their preferred
architectural approach
<br>> (cross-certify .vs. trust-points).&nbsp; The "PKC chain pointer"
structure would
<br>> probably be useful in other specifications.
<br>>
<br>> Such a structure might contain a pointer to the first and last certificates
in
<br>> the chain {issuer DN, serial number, cert hash} and a hash of the
entire,
<br>> ordered PKC chain.&nbsp; This chain pointer would map to only one
PKC chain.&nbsp; There
<br>> may be other representations that are more elegant yet equally effective.
<p>In general, I don't believe this would be useful, e.g. imagine an
<br>originator (say an AA or an originating mail UA) including such
<br>an attribute in a signed data structure (an AC or s/mime message).
<br>Now the originator has no way to know what path(s) will be ok for the
<br>relying party, so this attribute can at best be a hint unless you
<br>effectively force the originator to "know" about the relying party's
<br>PKI settings.</blockquote>
The described pointer is a shorthand representation of the full PKC chain,
all or part of which is currently included in a typical signed S/MIME message.&nbsp;
This should be equally useful.
<blockquote TYPE=CITE>So, either:
<p>- its a hint (why bother if it can be ignored?), or,
<br>- the originator has to know the RP's settings (and we've just made
<br>&nbsp; general interop *much* harder if not impossible)
<p>I also think folks are getting carried away here - when has any
<br>real CA service been vulnerable to the types of (particularly
<br>CA!) name collisions that are being claimed here? If it were, how
<br>much confidence should you have in anything else it claims to
<br>offer? I think this is just another case where the certificate
<br>syntax itself cannot fully represent the underlying (PKI or
<br>PMI) policy settings.</blockquote>
I think the potential attack described earlier is that a bad guy would
intentionally assume the name of a legitimate CA for the express purpose
of gaining use of permissions, etc. provided by someone else's AC.&nbsp;
So we can't say this is unlikely to occur.
<blockquote TYPE=CITE>Regards,
<br>Stephen.
<p>--
<br>____________________________________________________________
<br>Stephen Farrell
<br>Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) [phone]
<br>61 Fitzwilliam Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: [phone]
<br>Dublin 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="mailto:[e-mail]">mailto:[e-mail]</a>
<br>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="http://www.baltimore.com">http://www.baltimore.com</a></blockquote>
</html>



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20657 for <[e-mail]>; Mon, 16 Oct 2000 11:12:38 -0700 (PDT)
Received: by balinese.baltimore.ie; id TAA10004; Mon, 16 Oct 2000 19:17:36 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma009917; Mon, 16 Oct 00 19:17:03 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.ie.baltimore.com (8.9.3/8.9.3) with ESMTP id TAA23411; Mon, 16 Oct 2000 19:17:03 +0100
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 19:20:43 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail]
Subject: One or many PKIs (was: Re: Comments on draft-ietf-pkix-ac509prof-05.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

The text again:-)

     "The signature on every certificate in the path must be verified. Procedures 
      related to validating signatures and public-key certificates are not repeated 
      in this clause. The privilege verifier must verify the identity of every entity 
      in the path, using the procedures of clause 10. Note that checking the signature 
      on an attribute certificate necessarily involves checking the referenced public-key 
      certificate for its validity. Where privileges are assigned using attribute 
      certificates, path processing engines will need to consider elements of both the 
      PMI and the PKI in the course of determining the ultimate validity of a 
      privilege asserter's attribute certificate." 

> Now, does the text above mean that we take EACH of those entities above and use the procedures of
> clause 10 to verify them, which may lead to multiple PKIs?  Or does it mean that the whole
> collection of entities in the list above all pertain to a single path (with respect to the
> authorization decision), and so are all evaluated *collectively* according to clause 10, which
> leads to a single PKI?

That's the question all right. I read it as the former on the basis that it
doesn't say "collectively" or anything like it. If it did, you'd be right,
but it doesn't.

> [snip]...having a single PKI for all the entities involved in this authorization path
> can eliminate the security hole, whereas having multiple PKIs absolutely cannot eliminate this
> hole.  

Again, I disagree - I don't see how the existence of a cross certificate (compared
to the RP having two trustpoints) eliminates anything (not that there was anything 
to be eliminated in the first place:-). The cross-certificate *might* provide the RP 
with some better recourse in the event of a problem arising, but that's not a 
run-time issue, which is what we're discussing.

> What exactly is the argument in favour of supporting multiple PKIs for this purpose?  What problem
> does it solve?  What benefit does it bring?

It decreases the dependence between the PKI(s) and the PMI, which I
think is useful in practice, e.g. the "single" PKI model would mean that
certain RPs could not validate ACs without first getting the RP's
"local" PKI to issue cross certificates for the AA's and holder's PKI(s).
The issuance of such certificates is neither simple (procedurally), nor 
required, if the RP can safely configure in the relevant trustpoints.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19491 for <[e-mail]>; Mon, 16 Oct 2000 10:46:48 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <46BW942G>; Mon, 16 Oct 2000 13:52:52 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 13:51:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03799.AEDB5E70"

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_01C03799.AEDB5E70
Content-Type: text/plain

Hi Stephen,

> ----------
> From: 	Stephen Farrell[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, October 16, 2000 1:03 PM
> To: 	[e-mail]
> Subject: 	Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Looks like we disagree on this. This is the X.509 quote (I hope:-):
> 
>      "The signature on every certificate in the path must be verified.
> Procedures 
>      related to validating signatures and public-key certificates are not
> repeated 
>      in this clause. The privilege verifier must verify the identity of
> every entity 
>      in the path, using the procedures of clause 10. Note that checking
> the signature 
>      on an attribute certificate necessarily involves checking the
> referenced public-key 
>      certificate for its validity. Where privileges are assigned using
> attribute 
>      certificates, path processing engines will need to consider elements
> of both the 
>      PMI and the PKI in the course of determining the ultimate validity of
> a
>      privilege asserter's attribute certificate."
> 
> To me, that's prettly clearly saying: "check all PKC's involved" and
> nothing 
> about relationships between the different roots involved.
 
What it says is "verify the identity of every entity in the path, using the
procedures of clause 10."  The identities involved in the path are
represented by the holder's PKC (and all the CAs, if any, up to the root),
the AA's PKC (and those of all the AAs, if any, up to the SOA), and perhaps
the AA that signed the role certificate, if there is one (and all PKCs of
those AAs, if any, up to the SOA).

Now, does the text above mean that we take EACH of those entities above and
use the procedures of clause 10 to verify them, which may lead to multiple
PKIs?  Or does it mean that the whole collection of entities in the list
above all pertain to a single path (with respect to the authorization
decision), and so are all evaluated *collectively* according to clause 10,
which leads to a single PKI?

I suppose that, on its own, the text could be read either way.  However, all
the other places in the PMI text which talk only about "THE PKI" suggest to
me that only a single PKI is assumed.  Add to this the fact that having a
single PKI for all the entities involved in this authorization path can
eliminate the security hole, whereas having multiple PKIs absolutely cannot
eliminate this hole.  Add further the idea that it seems unreasonable for an
AA to issue certificates when it has no way of knowing whether any RPs will
be able to verify certificates in the particular set of multiple PKIs the AA
has chosen.  All of this, taken together, says to me that if the X.509 text
assumed anything at all on this issue, it assumed a single PKI.

Sure, the ACprof I-D can take no stance here, or can explicitly state that
multiple PKIs is the underlying model.  But why open up a potential security
hole when we don't need to (and then have to patch it using the sort of
extension that Polar suggested)?  The single-PKI (for all entities involved
in a given authorization path) model is not fundamentally any more limiting
than the multi-PKI model, but it is more secure, and it seems (to me) to be
more reasonable in terms of what an AA can expect RPs to know.  And (as I
keep saying) given that entities in two PKIs can't authenticate anyway
unless these PKIs are tied into one, I don't see what the objection is.

What exactly is the argument in favour of supporting multiple PKIs for this
purpose?  What problem does it solve?  What benefit does it bring?

Carlisle.


------_=_NextPart_001_01C03799.AEDB5E70
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.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Stephen,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 1:03 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Looks like we disagree on this. This =
is the X.509 quote (I hope:-):</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &quot;The =
signature on every certificate in the path must be verified. Procedures =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; related to =
validating signatures and public-key certificates are not repeated =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; in this =
clause. The privilege verifier must verify the identity of every entity =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; in the path, =
using the procedures of clause 10. Note that checking the signature =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; on an =
attribute certificate necessarily involves checking the referenced =
public-key </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; certificate =
for its validity. Where privileges are assigned using attribute </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; =
certificates, path processing engines will need to consider elements of =
both the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; PMI and the =
PKI in the course of determining the ultimate validity of a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; privilege =
asserter's attribute certificate.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">To me, that's prettly clearly saying: =
&quot;check all PKC's involved&quot; and nothing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about relationships between the =
different roots involved.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What it =
says is &quot;verify the identity of every entity in the path, using =
the procedures of clause 10.&quot;&nbsp; The identities involved in the =
path are represented by the holder's PKC (and all the CAs, if any, up =
to the root), the AA's PKC (and those of all the AAs, if any, up to the =
SOA), and perhaps the AA that signed the role certificate, if there is =
one (and all PKCs of those AAs, if any, up to the SOA).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now, does =
the text above mean that we take EACH of those entities above and use =
the procedures of clause 10 to verify them, which may lead to multiple =
PKIs?&nbsp; Or does it mean that the whole collection of entities in =
the list above all pertain to a single path (with respect to the =
authorization decision), and so are all evaluated *collectively* =
according to clause 10, which leads to a single PKI?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I suppose =
that, on its own, the text could be read either way.&nbsp; However, all =
the other places in the PMI text which talk only about &quot;THE =
PKI&quot; suggest to me that only a single PKI is assumed.&nbsp; Add to =
this the fact that having a single PKI for all the entities involved in =
this authorization path can eliminate the security hole, whereas having =
multiple PKIs absolutely cannot eliminate this hole.&nbsp; Add further =
the idea that it seems unreasonable for an AA to issue certificates =
when it has no way of knowing whether any RPs will be able to verify =
certificates in the particular set of multiple PKIs the AA has =
chosen.&nbsp; All of this, taken together, says to me that if the X.509 =
text assumed anything at all on this issue, it assumed a single =
PKI.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Sure, the =
ACprof I-D can take no stance here, or can explicitly state that =
multiple PKIs is the underlying model.&nbsp; But why open up a =
potential security hole when we don't need to (and then have to patch =
it using the sort of extension that Polar suggested)?&nbsp; The =
single-PKI (for all entities involved in a given authorization path) =
model is not fundamentally any more limiting than the multi-PKI model, =
but it is more secure, and it seems (to me) to be more reasonable in =
terms of what an AA can expect RPs to know.&nbsp; And (as I keep =
saying) given that entities in two PKIs can't authenticate anyway =
unless these PKIs are tied into one, I don't see what the objection =
is.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What =
exactly is the argument in favour of supporting multiple PKIs for this =
purpose?&nbsp; What problem does it solve?&nbsp; What benefit does it =
bring?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03799.AEDB5E70--


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18342 for <[e-mail]>; Mon, 16 Oct 2000 10:10:47 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <40P5Z84N>; Mon, 16 Oct 2000 13:15:14 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Polar Humenn'" <[e-mail]>
Cc: Al Arsenault <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 13:15:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03794.A5384630"

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_01C03794.A5384630
Content-Type: text/plain

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[e-mail]]
> Sent: 	Monday, October 16, 2000 12:25 PM
> To: 	Carlisle Adams
> Cc: 	Al Arsenault; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; Stephen McConnell; Kent
> Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Hi Carlisle,
> 
> On Mon, 16 Oct 2000, Carlisle Adams wrote:
> 
> > > Well, at the very least, I'm glad that some people in the group
> actually
> > > see the problem. Whether it amounts to anything significant, I can
> only
> > > hope.
> >  
> > Yes, I think people see the problem.  Furthermore, I've outlined the
> > conditions under which it is not a problem.  These conditions (a single
> PKI,
> > formed through responsible cross-certification) are not overly
> restrictive
> > and make perfect sense for interoperation between domains that care
> about
> > security, especially since they need to do this anyway in order to
> > authenticate each other.
> 
> But this condition of operation for the AA still hinges on the fact that
> the DN space MUST be unique after cross certifying PKI's.
 
Not quite.  It hinges on the fact that whatever name space will be used,
MUST be unique.  Name constraints do not have to be applied to DNs; they can
be applied to e-mail domains, or Kerberos realms, or whatever is used within
the subject AND subjectAltNames fields (and, in fact, can be applied to
multiple name spaces simultaneously, if this is deemed to be appropriate).
The idea is similar to PEM's name subordination, but is much more general
and flexible.

> Can you really see that happening?
 
Yes.

> I cannot see that happening in the real world. Especially with many
> players, and especally when you need to do things quickly. Forcing one
> organization or both to comply with the other, is a lot of work, and
> figuring out name constraints for both could be a daunting effort, not
> mentioning getting it correct.
 
As one example, company A has the e-mail domain A.com and company B has the
domain B.com.  When they cross-certify, the cross-cert that A issues says
that entities in B's space must be in the B.com domain, and the cross-cert
that B issues says that entities in A's space must be in the A.com domain.
This seems quite straightforward and intuitive.  AND, as I keep saying, they
need to do this anyway in order to authenticate (this is not some special
situation that needs to be artificially put in place just so that
authorization can work).

Other example name constraints could equally well have been chosen.  I don't
see the difficulty.

Carlisle.


------_=_NextPart_001_01C03794.A5384630
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.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 12:25 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al Arsenault; =
[e-mail]; [e-mail]; [e-mail]; =
[e-mail]; [e-mail]; Stephen McConnell; Kent Salmond; Ken =
Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Mon, 16 Oct 2000, Carlisle Adams =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Well, at the very least, I'm =
glad that some people in the group actually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; see the problem. Whether it =
amounts to anything significant, I can only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; hope.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Yes, I think people see the =
problem.&nbsp; Furthermore, I've outlined the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; conditions under which it is not =
a problem.&nbsp; These conditions (a single PKI,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; formed through responsible =
cross-certification) are not overly restrictive</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and make perfect sense for =
interoperation between domains that care about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; security, especially since they =
need to do this anyway in order to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; authenticate each other.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But this condition of operation for =
the AA still hinges on the fact that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the DN space MUST be unique after =
cross certifying PKI's.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Not =
quite.&nbsp; It hinges on the fact that whatever name space will be =
used, MUST be unique.&nbsp; Name constraints do not have to be applied =
to DNs; they can be applied to e-mail domains, or Kerberos realms, or =
whatever is used within the subject AND subjectAltNames fields (and, in =
fact, can be applied to multiple name spaces simultaneously, if this is =
deemed to be appropriate).&nbsp; The idea is similar to PEM's name =
subordination, but is much more general and flexible.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Can you really see that =
happening?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Yes.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I cannot see that happening in the =
real world. Especially with many</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">players, and especally when you need =
to do things quickly. Forcing one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">organization or both to comply with =
the other, is a lot of work, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">figuring out name constraints for =
both could be a daunting effort, not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mentioning getting it correct.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As one =
example, company A has the e-mail domain A.com and company B has the =
domain B.com.&nbsp; When they cross-certify, the cross-cert that A =
issues says that entities in B's space must be in the B.com domain, and =
the cross-cert that B issues says that entities in A's space must be in =
the A.com domain.&nbsp; This seems quite straightforward and =
intuitive.&nbsp; AND, as I keep saying, they need to do this anyway in =
order to authenticate (this is not some special situation that needs to =
be artificially put in place just so that authorization can =
work).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Other =
example name constraints could equally well have been chosen.&nbsp; I =
don't see the difficulty.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03794.A5384630--


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18003 for <[e-mail]>; Mon, 16 Oct 2000 10:04:35 -0700 (PDT)
Received: by balinese.baltimore.ie; id SAA03603; Mon, 16 Oct 2000 18:09:33 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma003593; Mon, 16 Oct 00 18:09:31 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.ie.baltimore.com (8.9.3/8.9.3) with ESMTP id SAA17770 for <[e-mail]>; Mon, 16 Oct 2000 18:09:31 +0100
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 18:13:12 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dale,

> I think Polar is saying that an AC should be able to (optionally) contain a
> pointer to "one and only one" PKC chain.  This seems like a reasonable
> requirement given that this same concept has already been defined in several
> forms for a single PKC within RFC-2459, RFC-2560, et. al.

I'm not sure what you mean here, AFAIK neither RFC contains such a 
structure or requirement.
 
> PKI providers could still follow their preferred architectural approach
> (cross-certify .vs. trust-points).  The "PKC chain pointer" structure would
> probably be useful in other specifications.
> 
> Such a structure might contain a pointer to the first and last certificates in
> the chain {issuer DN, serial number, cert hash} and a hash of the entire,
> ordered PKC chain.  This chain pointer would map to only one PKC chain.  There
> may be other representations that are more elegant yet equally effective.

In general, I don't believe this would be useful, e.g. imagine an 
originator (say an AA or an originating mail UA) including such 
an attribute in a signed data structure (an AC or s/mime message). 
Now the originator has no way to know what path(s) will be ok for the 
relying party, so this attribute can at best be a hint unless you 
effectively force the originator to "know" about the relying party's 
PKI settings. 

So, either:

- its a hint (why bother if it can be ignored?), or,
- the originator has to know the RP's settings (and we've just made
  general interop *much* harder if not impossible)

I also think folks are getting carried away here - when has any
real CA service been vulnerable to the types of (particularly
CA!) name collisions that are being claimed here? If it were, how 
much confidence should you have in anything else it claims to 
offer? I think this is just another case where the certificate
syntax itself cannot fully represent the underlying (PKI or
PMI) policy settings.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17654 for <[e-mail]>; Mon, 16 Oct 2000 09:57:12 -0700 (PDT)
Received: from asn-1.com (user-2ivf1qn.dialup.mindspring.com [165.247.135.87]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA11329 for <[e-mail]>; Mon, 16 Oct 2000 13:02:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 13:05:03 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft
References: <00f001c03779$e20bf9a0$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Michael Ströder wrote:
> 
> Anders Rundgren wrote:
> >
> > Are you the slightest familiar with XML parsers and schemas?
> 
> There's no doubt that it would be interesting to use XML for the
> presentation layer because of automatic validation against DTD
> retrieved by URL etc.

Yes, XML has great potential for data display. 
But if the data transfer has been performed using
an efficient binary method, such as provided by
any of the ASN.1 encoding rules, there is no need
or benefit for performing further validation of 
the data using either XML DTDs or any of their 
many (relax, etc.) XML schema. 

Simply decoding ASN.1 encoded data validates the 
gross structure of the information, and assures that
the data conforms to the schema specified by the 
ASN.1 notation - decoding guarantees that the data
values are valid members of the distinct set of 
values indicated by the their tag type. 

> But there would be still a need to define the semantics of the
> attributes (name space in XML) to make different applications from
> different vendors interoperable. Or did I get you totally wrong?
> 
> > There is AFAIK not any standardized way to verify that an ASN.1
> > document corresponds to its definition.

This is exactly the opposite of true. Each ASN.1 value is
a member of an ASN.1 type. An ASN.1 type is a class of
distinct values. Given the tag for the type, the validity
of every value can be easily determined. 

In ASN.1 the schema is built into and underlies the actual
notation. There is just one schema in ASN.1, but there are
many encoding rules (soon to include one for XML). One schema
seems to be more than enough for most folks.

> I leave this question open to the ASN.1 compiler experts.
> 
> Ciao, Michael.

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17419 for <[e-mail]>; Mon, 16 Oct 2000 09:55:35 -0700 (PDT)
Received: by balinese.baltimore.ie; id SAA02119; Mon, 16 Oct 2000 18:00:33 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma002075; Mon, 16 Oct 00 18:00:08 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.ie.baltimore.com (8.9.3/8.9.3) with ESMTP id SAA17579 for <[e-mail]>; Mon, 16 Oct 2000 18:00:08 +0100
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 18:03:49 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

Where in X.509(2000) is there an assertion that a "single" PKI is good, bad
or indifferent w.r.t. AC validity? I certainly don't recall one. (Maybe Hoyt 
or Sharon can clarify this?)

> The text that I quoted in my previous message is from X.509 (2000), not from the AC I-D. I have
> not checked, but I strongly suspect that the I-D says nothing about this, which is probably why
> you cannot find it.  

You won't find it since its not there, nor (IMO) should it be.

> I think that the X.509 text implies this pretty clearly, but I don't think
> this is stated explicitly.

Looks like we disagree on this. This is the X.509 quote (I hope:-):

     "The signature on every certificate in the path must be verified. Procedures 
     related to validating signatures and public-key certificates are not repeated 
     in this clause. The privilege verifier must verify the identity of every entity 
     in the path, using the procedures of clause 10. Note that checking the signature 
     on an attribute certificate necessarily involves checking the referenced public-key 
     certificate for its validity. Where privileges are assigned using attribute 
     certificates, path processing engines will need to consider elements of both the 
     PMI and the PKI in the course of determining the ultimate validity of a
     privilege asserter's attribute certificate."

To me, that's prettly clearly saying: "check all PKC's involved" and nothing 
about relationships between the different roots involved.

Regards,
Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17076 for <[e-mail]>; Mon, 16 Oct 2000 09:48:02 -0700 (PDT)
Received: from mega (t5o69p34.telia.com [213.64.110.34]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id SAA13128; Mon, 16 Oct 2000 18:52:58 +0200 (CEST)
Message-ID: <003701c03791$5c6607b0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "=?iso-8859-1?Q?Michael_Str=F6der?=" <[e-mail]>, <[e-mail]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 18:51:39 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA17080

<snip>

>But there would be still a need to define the semantics of the
>attributes (name space in XML) to make different applications from
>different vendors interoperable. Or did I get you totally wrong?


Well you *could* do that but I think it is the wrong way to go.
An AC XML attribute schema is the application IMO.  You would typically
find that the health-care sector would define their own schemas (with their own
syntax and semantics only limted by XML itself).  And so would every other sector
or single application do.  I.e. IETF should not have to
bother about semantics for attributes. In the same way as Microsoft does not
care how many BizTalk purchase order schemas are created and how they are to
be interpreted.  It is up to every community.

Anders



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16273 for <[e-mail]>; Mon, 16 Oct 2000 09:25:19 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id MAA05590; Mon, 16 Oct 2000 12:25:57 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 16 Oct 2000 12:25:56 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: Al Arsenault <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Carlisle,

On Mon, 16 Oct 2000, Carlisle Adams wrote:

> > Well, at the very least, I'm glad that some people in the group actually
> > see the problem. Whether it amounts to anything significant, I can only
> > hope.
>  
> Yes, I think people see the problem.  Furthermore, I've outlined the
> conditions under which it is not a problem.  These conditions (a single PKI,
> formed through responsible cross-certification) are not overly restrictive
> and make perfect sense for interoperation between domains that care about
> security, especially since they need to do this anyway in order to
> authenticate each other.

But this condition of operation for the AA still hinges on the fact that
the DN space MUST be unique after cross certifying PKI's.

Can you really see that happening?

I cannot see that happening in the real world. Especially with many
players, and especally when you need to do things quickly. Forcing one
organization or both to comply with the other, is a lot of work, and
figuring out name constraints for both could be a daunting effort, not
mentioning getting it correct.

Cheers,
-Polar



> 
> Carlisle.
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA16063 for <[e-mail]>; Mon, 16 Oct 2000 09:23:13 -0700 (PDT)
Received: (qmail 3325584 invoked from network); 16 Oct 2000 16:28:07 -0000
Received: from e004.dhcp212-17.cybercable.fr (HELO home) ([212.198.17.4]) (envelope-sender <[e-mail]>) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for <[e-mail]>; 16 Oct 2000 16:28:07 -0000
From: "Stephen McConnell" <[e-mail]>
To: "Dale Gustafson" <[e-mail]>, "Carlisle Adams" <[e-mail]>
Cc: <[e-mail]>, "'Al Arsenault'" <[e-mail]>, "'Polar Humenn'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Kent Salmond" <[e-mail]>, "Ken Mccoy" <[e-mail]>, "Thumrongsak Kosiyatrakul" <[e-mail]>, "Susan Older" <[e-mail]>, "Shiu-Kai Chin" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 18:26:18 +0200
Message-ID: <003e01c0378d$cfe32460$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Importance: Normal
In-Reply-To: <[e-mail]>

Seems to me that Dale's comment seems to properly address the issue here.

Cheers, Steve.


> -----Original Message-----
> From: Dale Gustafson [mailto:[e-mail]]
> Sent: Monday, 16 October, 2000 17:41
> To: Carlisle Adams
> Cc: [e-mail]; 'Al Arsenault'; 'Polar Humenn';
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul;
> Susan Older; Shiu-Kai Chin
> Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
>
>
> Hi Carlisle,
>
> I think Polar is saying that an AC should be able to (optionally)
> contain a pointer to "one and only one" PKC chain.  This seems
> like a reasonable requirement given that this same concept has
> already been defined in several forms for a single PKC within
> RFC-2459, RFC-2560, et. al.
>
> PKI providers could still follow their preferred architectural
> approach (cross-certify .vs. trust-points).  The "PKC chain
> pointer" structure would probably be useful in other
> specifications.
>
> Such a structure might contain a pointer to the first and last
> certificates in the chain {issuer DN, serial number, cert hash}
> and a hash of the entire, ordered PKC chain.  This chain pointer
> would map to only one PKC chain.  There may be other
> representations that are more elegant yet equally effective.
>
> Best Regards,
>
> Dale Gustafson
>
>
>
>
> Carlisle Adams wrote:
>
> >
> >
> > Hi Al, Stephen,
> >
> >      ----------
> >      From:   Al Arsenault[SMTP:[e-mail]]
> >      Sent:   Monday, October 16, 2000 9:37 AM
> >      To:     [e-mail]
> >      Cc:     Carlisle Adams; 'Polar Humenn'; [e-mail];
> >      [e-mail]; [e-mail]; [e-mail]; Stephen
> McConnell; Kent
> >      Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older;
> Shiu-Kai Chin
> >
> >      Subject:        Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> >
> >      Stephen Farrell wrote:
> >      >
> >      > Carlisle,
> >      >
> >      > You're overstating the requirements for an AC to be
> valid. There is
> >      > no need for the AA and holder to belong to the "same"
> PKI - the only
> >      > requirement, in general, is that the RP be able to
> valiate the AA's PKC
> >
> >      > and the holder's PKC and that the AC contents be
> consistent with those
> >      > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
> >      significance
> >      > we'll never know:-) and also what the PKIX AC profile
> says. If there is
> >
> >      > text somewhere clearly to the contrary please point it out.
> >      >
> >      ><rest snipped>
> >
> >      I agree with Stephen - I can find nothing in the AC I-D
> that says that
> >      the AA's PKC and the holder's PKC have to trace back to
> the same Root
> >      CA.  And it was my understanding that that was decided to not be a
> >      requirement.
> >      As always, I'm willing to be shown where I screwed up, and this is
> >      actually required - I've been publicly shown to be wrong
> so many times
> >      that it doesn't bother me at all.  :-)
> >
> >
> > The text that I quoted in my previous message is from X.509
> (2000), not from
> > the AC I-D.  I have not checked, but I strongly suspect that
> the I-D says
> > nothing about this, which is probably why you cannot find it.
> I think that
> > the X.509 text implies this pretty clearly, but I don't think
> this is stated
> > explicitly.
> >
> >      In my opinion, the "security hole" pointed out by Polar can in fact
> >      occur, either maliciously or by "accident". (e.g., if the
> holder's PKC
> >      chains back to root_CA_1, and the AA's PKC chains back to
> root_CA_2,
> >      then there can be a cert under root_CA_2 with the same DN,
> >      subjectAltName, serial number, ... as the holder's PKC. If
> the RP trusts
> >      both root_CA_1 and root_CA_2, then it may be the case that
> the RP can't
> >      tell which holder PKC to use. And it gets even more
> interesting if the
> >      RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> >      right cert is the one under root_CA_2, and thus everything
> validates; or
> >      does the RP think that the right holder PKC is the one
> under root_CA_1,
> >      and thus reject the AC?)
> >
> >
> > Yes, I agree that the "security hole" can occur if multiple
> PKIs are involved,
> > which is why I believe that the underlying assumption in X.509
> (2000) is that
> > there is one PKI and that it is managed in such a way as to
> avoid identity
> > collisions through proper use of name constraints.  This eliminates the
> > security hole (which, ultimately should be the goal of a security
> > infrastructure).
> >
> > Even aside from security, however, I think that allowing for
> multiple PKIs
> > here is unreasonable in practice.  As Stephen said, what is
> required is that
> > the RP can validate the AA's PKC and the holder's PKC and that
> the AC contents
> > are consistent with those two PKCs.  But in general the AA
> (particularly the
> > SOA) does not know who the relying parties will be, especially
> if delegation
> > is involved so that there are intermediate AAs (this is
> identical to a root CA
> > not knowing who its relying parties are in general when there
> are subordinate
> > CAs in between).  So why would it make sense for the SOA to create
> > certificates that only RPs with trust anchors in these two PKIs
> can validate?
> > It has no way of knowing if such RPs even exist (they
> *probably* do, but the
> > SOA doesn't know who they are, or where they are, or what their
> > needs/assumptions will be with respect to authorization)!  I
> just can't see
> > much value in this level of generalization.  I'm not saying
> that this can't be
> > done, or that we should necessarily do anything to prohibit it,
> but I don't
> > see the value of it and I wonder if it actually would be used.
> >
> > So, I suggest that security and simplicity both lean toward the
> single PKI
> > model.
> >
> >      However, I do not believe that the right thing to do is
> either mandate
> >      the objectDigest form in the AC, or kill the AC draft.  And I don't
> >      think it's to insert the requirement that the holder's PKC
> and the AA's
> >      PKC chain back to the same root. Rather, I think that the
> best approach
> >      is to acknowledge that this risk exists, and live with it.
> Put in an
> >      explanation (in Security Considerations, in some other
> section - in the
> >      Roadmap, too, in all likelihood - that says that if you trust two
> >      independent Root CAs, then this is a risk you run.
> >
> >
> > Fair enough.  That way, those that are serious about security
> can "do the
> > right thing" and those for whom security is less important can
> "hope that bad
> > things don't happen"...  :-)
> >
> >      That's my .02 worth.  And if I'm wrong and missed the part
> in the I-D
> >      that says the two certs do have to chain back to the same
> root, then I
> >      retract the last two paragraphs.
> >
> >
> > As mentioned above, I doubt that you missed anything in the
> I-D.  But look at
> > .509 again with fresh eyes and let me know if I'm just imagining this
> > underlying assumption in the text.
> >
> > Carlisle.
>



Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14493 for <[e-mail]>; Mon, 16 Oct 2000 08:39:07 -0700 (PDT)
Received: from bpsi.net (port436.bpsi.net [209.54.245.236]) by ra.bpsi.net (8.11.0/8.11.0) with ESMTP id e9GFh1p05921; Mon, 16 Oct 2000 10:43:01 -0500 (CDT)
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 10:40:38 -0500
From: Dale Gustafson <[e-mail]>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD NSCPCD47  (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: [e-mail], "'Al Arsenault'" <[e-mail]>, "'Polar Humenn'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Carlisle,

I think Polar is saying that an AC should be able to (optionally) contain a
pointer to "one and only one" PKC chain.  This seems like a reasonable
requirement given that this same concept has already been defined in several
forms for a single PKC within RFC-2459, RFC-2560, et. al.

PKI providers could still follow their preferred architectural approach
(cross-certify .vs. trust-points).  The "PKC chain pointer" structure would
probably be useful in other specifications.

Such a structure might contain a pointer to the first and last certificates in
the chain {issuer DN, serial number, cert hash} and a hash of the entire,
ordered PKC chain.  This chain pointer would map to only one PKC chain.  There
may be other representations that are more elegant yet equally effective.

Best Regards,

Dale Gustafson




Carlisle Adams wrote:

>
>
> Hi Al, Stephen,
>
>      ----------
>      From:   Al Arsenault[SMTP:[e-mail]]
>      Sent:   Monday, October 16, 2000 9:37 AM
>      To:     [e-mail]
>      Cc:     Carlisle Adams; 'Polar Humenn'; [e-mail];
>      [e-mail]; [e-mail]; [e-mail]; Stephen McConnell; Kent
>      Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
>
>      Subject:        Re: Comments on draft-ietf-pkix-ac509prof-05.txt
>
>      Stephen Farrell wrote:
>      >
>      > Carlisle,
>      >
>      > You're overstating the requirements for an AC to be valid. There is
>      > no need for the AA and holder to belong to the "same" PKI - the only
>      > requirement, in general, is that the RP be able to valiate the AA's PKC
>
>      > and the holder's PKC and that the AC contents be consistent with those
>      > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
>      significance
>      > we'll never know:-) and also what the PKIX AC profile says. If there is
>
>      > text somewhere clearly to the contrary please point it out.
>      >
>      ><rest snipped>
>
>      I agree with Stephen - I can find nothing in the AC I-D that says that
>      the AA's PKC and the holder's PKC have to trace back to the same Root
>      CA.  And it was my understanding that that was decided to not be a
>      requirement.
>      As always, I'm willing to be shown where I screwed up, and this is
>      actually required - I've been publicly shown to be wrong so many times
>      that it doesn't bother me at all.  :-)
>
>
> The text that I quoted in my previous message is from X.509 (2000), not from
> the AC I-D.  I have not checked, but I strongly suspect that the I-D says
> nothing about this, which is probably why you cannot find it.  I think that
> the X.509 text implies this pretty clearly, but I don't think this is stated
> explicitly.
>
>      In my opinion, the "security hole" pointed out by Polar can in fact
>      occur, either maliciously or by "accident". (e.g., if the holder's PKC
>      chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
>      then there can be a cert under root_CA_2 with the same DN,
>      subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
>      both root_CA_1 and root_CA_2, then it may be the case that the RP can't
>      tell which holder PKC to use. And it gets even more interesting if the
>      RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
>      right cert is the one under root_CA_2, and thus everything validates; or
>      does the RP think that the right holder PKC is the one under root_CA_1,
>      and thus reject the AC?)
>
>
> Yes, I agree that the "security hole" can occur if multiple PKIs are involved,
> which is why I believe that the underlying assumption in X.509 (2000) is that
> there is one PKI and that it is managed in such a way as to avoid identity
> collisions through proper use of name constraints.  This eliminates the
> security hole (which, ultimately should be the goal of a security
> infrastructure).
>
> Even aside from security, however, I think that allowing for multiple PKIs
> here is unreasonable in practice.  As Stephen said, what is required is that
> the RP can validate the AA's PKC and the holder's PKC and that the AC contents
> are consistent with those two PKCs.  But in general the AA (particularly the
> SOA) does not know who the relying parties will be, especially if delegation
> is involved so that there are intermediate AAs (this is identical to a root CA
> not knowing who its relying parties are in general when there are subordinate
> CAs in between).  So why would it make sense for the SOA to create
> certificates that only RPs with trust anchors in these two PKIs can validate?
> It has no way of knowing if such RPs even exist (they *probably* do, but the
> SOA doesn't know who they are, or where they are, or what their
> needs/assumptions will be with respect to authorization)!  I just can't see
> much value in this level of generalization.  I'm not saying that this can't be
> done, or that we should necessarily do anything to prohibit it, but I don't
> see the value of it and I wonder if it actually would be used.
>
> So, I suggest that security and simplicity both lean toward the single PKI
> model.
>
>      However, I do not believe that the right thing to do is either mandate
>      the objectDigest form in the AC, or kill the AC draft.  And I don't
>      think it's to insert the requirement that the holder's PKC and the AA's
>      PKC chain back to the same root. Rather, I think that the best approach
>      is to acknowledge that this risk exists, and live with it. Put in an
>      explanation (in Security Considerations, in some other section - in the
>      Roadmap, too, in all likelihood - that says that if you trust two
>      independent Root CAs, then this is a risk you run.
>
>
> Fair enough.  That way, those that are serious about security can "do the
> right thing" and those for whom security is less important can "hope that bad
> things don't happen"...  :-)
>
>      That's my .02 worth.  And if I'm wrong and missed the part in the I-D
>      that says the two certs do have to chain back to the same root, then I
>      retract the last two paragraphs.
>
>
> As mentioned above, I doubt that you missed anything in the I-D.  But look at
> .509 again with fresh eyes and let me know if I'm just imagining this
> underlying assumption in the text.
>
> Carlisle.



Received: from frcmr1001.ac.com (frcmr1001.ac.com [195.27.74.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13883 for <[e-mail]>; Mon, 16 Oct 2000 08:35:34 -0700 (PDT)
From: [e-mail]
Received: from emehm1103.ac.com (emehm1103.ac.com [10.135.64.207]) by frcmr1001.ac.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9GFdxp01793 for <[e-mail]>; Mon, 16 Oct 2000 17:40:02 +0200 (MET DST)
Subject: UNSUBSCRIBE
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 16:38:12 +0100
X-MIMETrack: Serialize by Router on EMEHM1103(Release 5.0.4 |June 8, 2000) at 16.10.2000 17:38:23
MIME-Version: 1.0


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10184 for <[e-mail]>; Mon, 16 Oct 2000 08:16:54 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <46BW9TYD>; Mon, 16 Oct 2000 11:22:58 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Al Arsenault <[e-mail]>, "'Polar Humenn'" <[e-mail]>
Cc: [e-mail], Carlisle Adams <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 11:21:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03784.BDDCF880"

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_01C03784.BDDCF880
Content-Type: text/plain

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[e-mail]]
> Sent: 	Monday, October 16, 2000 10:48 AM
> To: 	Al Arsenault
> Cc: 	[e-mail]; Carlisle Adams; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; Stephen McConnell; Kent
> Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> I thought it was the case as well, that the AC can really bridge three
> PKIs. That means the holder, the AA, and the RP all can have their own
> different PKIs with the possibility of cross-certification of all three. 
 
As I mentioned before, as soon as you allow (proper) cross-certification of
all three, you no longer have three, but one.  This is what makes the model
work.

> I don't even see a need for cross certification in the model. My browser
> "trusts" 137 root certificates without cross-certification, and nobody
> seems to care all that much.
 
A number of people have been saying for a long time now that the Web model
(with dozens of "trust anchors" in your software that you've never even
heard about) is NOT a good model for security.  I wouldn't quite say that
"nobody seems to care all that much".  If you look at the organizations
operating PKIs today that care a lot about security (governments and
financial institutions, in particular, but others as well), most of them do
not rely solely upon the browser software for security in their
authentication decisions.

> Well, at the very least, I'm glad that some people in the group actually
> see the problem. Whether it amounts to anything significant, I can only
> hope.
 
Yes, I think people see the problem.  Furthermore, I've outlined the
conditions under which it is not a problem.  These conditions (a single PKI,
formed through responsible cross-certification) are not overly restrictive
and make perfect sense for interoperation between domains that care about
security, especially since they need to do this anyway in order to
authenticate each other.

Carlisle.


------_=_NextPart_001_01C03784.BDDCF880
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.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 10:48 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; Carlisle Adams; [e-mail]; =
[e-mail]; [e-mail]; [e-mail]; Stephen McConnell; Kent =
Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai =
Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I thought it was the case as well, =
that the AC can really bridge three</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKIs. That means the holder, the AA, =
and the RP all can have their own</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">different PKIs with the possibility =
of cross-certification of all three. </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As I =
mentioned before, as soon as you allow (proper) cross-certification of =
all three, you no longer have three, but one.&nbsp; This is what makes =
the model work.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">don't even see a need for cross certification in the =
model. My browser</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;trusts&quot; 137 root =
certificates without cross-certification, and nobody</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">seems to care all that much.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">A number =
of people have been saying for a long time now that the Web model (with =
dozens of &quot;trust anchors&quot; in your software that you've never =
even heard about) is NOT a good model for security.&nbsp; I wouldn't =
quite say that &quot;nobody seems to care all that much&quot;.&nbsp; If =
you look at the organizations operating PKIs today that care a lot =
about security (governments and financial institutions, in particular, =
but others as well), most of them do not rely solely upon the browser =
software for security in their authentication decisions.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Well, at the very least, I'm glad that =
some people in the group actually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">see the problem. Whether it amounts =
to anything significant, I can only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">hope.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, I =
think people see the problem.&nbsp; Furthermore, I've outlined the =
conditions under which it is not a problem.&nbsp; These conditions (a =
single PKI, formed through responsible cross-certification) are not =
overly restrictive and make perfect sense for interoperation between =
domains that care about security, especially since they need to do this =
anyway in order to authenticate each other.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03784.BDDCF880--


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09178 for <[e-mail]>; Mon, 16 Oct 2000 08:01:44 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <40P5Z6ZY>; Mon, 16 Oct 2000 11:06:11 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], [e-mail], "'Bob Jueneman'" <[e-mail]>
Cc: [e-mail], [e-mail], "<Ed Reed" <[e-mail]>
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Mon, 16 Oct 2000 11:06:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03782.9E2ADFE0"

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_01C03782.9E2ADFE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Bob,

Just a couple of quick responses to specific points below...

> ----------
> From: 	Bob Jueneman[SMTP:[e-mail]]
> Sent: 	Friday, October 13, 2000 6:56 PM
> To: 	[e-mail]; [e-mail]
> Cc: 	[e-mail]; [e-mail]; <Ed Reed
> Subject: 	Objections to advancing the attribute certificate
> authentication draft
> 
> Secondly, I tend to disagree with the assertion that the PKC issuer is not
> usually authoritative for the authorization information.  This assumes a
> separation of function of identity confirmation vs. authorization which I
> simply haven't seen demonstrated in practice, except arguably in some
> European systems where the State is issuing high-grade identity
> certificates to their citizens.
> 
> Within the US, at least, I would claim that 99.9% all of the identity
> certificates that  have been issued were either created by or vouched for
> by an organizational RA, or were issued by the organization itself. And
> inevitably it is that organization that is authoritative for the
> authorization information.  
 
Yes, the identity certificates were issued by the organization, and it is
the organization that is authoritative for the authorization information.
No argument.  BUT, is it the same department within the organization?  Is it
exactly the same people within the organization that administer both
identity and privilege?  Not that I've seen (or heard about).  Whoever it
was in Novell that assigned you an employee ID number is almost certainly
not the same person that decides whether or not you can sign a cheque for
$10,000. to buy some office equipment or some new software for your machine.

Maybe we just work in different circles, but this separation of function
(identity versus authorization) is about the ONLY thing I've ever seen in
actual practice.

> Finally, I also disagree with the third assumption, i.e., that
> authorization needs to be bound to an identity.  It often is, of course,
> but it need not be, and there are plenty of examples such as extranet
> access control where identity may be relevant to audit, but not to access
> control.  
 
Yes, often identity is relevant to audit but not to access control.
However, audit is extremely important to many organizations (at least for
some types of transactions), so being able to bind these things together,
especially in a persistent way, can be valuable.

> In addition, in some cases it is highly desirable that authorization NOT
> be tied to identity, or at least that the identity be anonymous. An
> example might be a teen-aged girl that wants to log in to get the results
> of her pregnancy test, but without revealing her name.  In that case a
> standard X.509 certificate could be used that contained a security label
> attribute and nothing more than a serial number, with no DN.
 
Sure, a PKC with no DN that includes a security label attribute, or a PKC
with no DN and a corresponding AC that contains a security label attribute.
Either will work and both have their advantages and disadvantages.
Depending on the adv. and disadv. you pick one or the other for some
particular application.

> Because attribute certificates are presently tied to a distinguished NAME
> that is presumably contained in an identity certificate, but not
> necessarily to any particular public/private key or certificate, path
> validation up the chain to two different CAs would seem to be a nightmare,
> and revocation  even worse.
 
ACs MAY be tied to a DN, but are preferably tied to the certificate itself
via issuer/serial.

> In an offline note to me, Ed Reed recently made another cogent
> observation.  Whereas incorporating a security/clearance/rights label in
> an identity certificate binds that label inextricably to the public key
> (and to the identity, if that matters), the same is not true of an
> attribute certificate.  
> 
> In particular, if the function of the security label is to DENY the
> delegation of some particular capability or default to an entity, then all
> that entity has to do is to conveniently "lose" the attribute certificate
> and he is back in business.  This may not be obvious, but without negative
> delegation I really have no way to definitive way to control what CAs I
> trust to control what functions, except by the very ponderous mechanisms
> of closed user groups and policy OID constraints. Yuch.
 
If you want to set up your security architecture in such a way that everyone
gets to do something unless there's a certificate saying "don't let me do
this thing", and you rely upon the entity to volunteer this certificate
whenever they feel like doing this thing, then I can't help but feel that
this is a flawed architecture...  :-)

No, if you want to operate in this manner (i.e., with "negative"
privileges), then the relying party must be responsible for acquiring this
information independent of the requesting entity.  There are multiple ways
to do this securely.  This doesn't argue against ACs.

> In summary, I am afraid I have to object to advancing the proposed draft
> at this time.
 
X.509 (2000) is, of course, already a standard.  I don't see what purpose
objecting to advancing a profile of this standard will serve.  If there are
specific technical flaws, that's one thing.  But objecting on the grounds
that you think the business case for ACs is suspect doesn't make sense.
That would be like trying to hold up RFC 2459 because you don't think
public-key certificates will work.  Trying to hold up a profile because you
really object to the base standard seems to be of little value.

Carlisle.


------_=_NextPart_001_01C03782.9E2ADFE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Objections to advancing the attribute certificate =
authentication draft</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Bob,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Just a =
couple of quick responses to specific points below...</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Bob =
Jueneman[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 13, 2000 6:56 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]; &lt;Ed Reed</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Objections to advancing the attribute certificate authentication =
draft</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Secondly, I tend to disagree with the =
assertion that the PKC issuer is not usually authoritative for the =
authorization information.&nbsp; This assumes a separation of function =
of identity confirmation vs. authorization which I simply haven't seen =
demonstrated in practice, except arguably in some European systems =
where the State is issuing high-grade identity certificates to their =
citizens.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Within the US, at least, I would claim =
that 99.9% all of the identity certificates that&nbsp; have been issued =
were either created by or vouched for by an organizational RA, or were =
issued by the organization itself. And inevitably it is that =
organization that is authoritative for the authorization =
information.&nbsp; </FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, the =
identity certificates were issued by the organization, and it is the =
organization that is authoritative for the authorization =
information.&nbsp; No argument.&nbsp; BUT, is it the same department =
within the organization?&nbsp; Is it exactly the same people within the =
organization that administer both identity and privilege?&nbsp; Not =
that I've seen (or heard about).&nbsp; Whoever it was in Novell that =
assigned you an employee ID number is almost certainly not the same =
person that decides whether or not you can sign a cheque for $10,000. =
to buy some office equipment or some new software for your =
machine.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Maybe we =
just work in different circles, but this separation of function =
(identity versus authorization) is about the ONLY thing I've ever seen =
in actual practice.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Finally, I also disagree with the =
third assumption, i.e., that authorization needs to be bound to an =
identity.&nbsp; It often is, of course, but it need not be, and there =
are plenty of examples such as extranet access control where identity =
may be relevant to audit, but not to access control.&nbsp; </FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, =
often identity is relevant to audit but not to access control.&nbsp; =
However, audit is extremely important to many organizations (at least =
for some types of transactions), so being able to bind these things =
together, especially in a persistent way, can be valuable.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In addition, in some cases it is =
highly desirable that authorization NOT be tied to identity, or at =
least that the identity be anonymous. An example might be a teen-aged =
girl that wants to log in to get the results of her pregnancy test, but =
without revealing her name.&nbsp; In that case a standard X.509 =
certificate could be used that contained a security label attribute and =
nothing more than a serial number, with no DN.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Sure, a =
PKC with no DN that includes a security label attribute, or a PKC with =
no DN and a corresponding AC that contains a security label =
attribute.&nbsp; Either will work and both have their advantages and =
disadvantages.&nbsp; Depending on the adv. and disadv. you pick one or =
the other for some particular application.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Because attribute certificates are =
presently tied to a distinguished NAME that is presumably contained in =
an identity certificate, but not necessarily to any particular =
public/private key or certificate, path validation up the chain to two =
different CAs would seem to be a nightmare, and revocation&nbsp; even =
worse.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">ACs MAY =
be tied to a DN, but are preferably tied to the certificate itself via =
issuer/serial.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In an offline note to me, Ed Reed =
recently made another cogent observation.&nbsp; Whereas incorporating a =
security/clearance/rights label in an identity certificate binds that =
label inextricably to the public key (and to the identity, if that =
matters), the same is not true of an attribute certificate.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In particular, if the function of the =
security label is to DENY the delegation of some particular capability =
or default to an entity, then all that entity has to do is to =
conveniently &quot;lose&quot; the attribute certificate and he is back =
in business.&nbsp; This may not be obvious, but without negative =
delegation I really have no way to definitive way to control what CAs I =
trust to control what functions, except by the very ponderous =
mechanisms of closed user groups and policy OID constraints. =
Yuch.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If you =
want to set up your security architecture in such a way that everyone =
gets to do something unless there's a certificate saying &quot;don't =
let me do this thing&quot;, and you rely upon the entity to volunteer =
this certificate whenever they feel like doing this thing, then I can't =
help but feel that this is a flawed architecture...&nbsp; =
:-)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">No, if you =
want to operate in this manner (i.e., with &quot;negative&quot; =
privileges), then the relying party must be responsible for acquiring =
this information independent of the requesting entity.&nbsp; There are =
multiple ways to do this securely.&nbsp; This doesn't argue against =
ACs.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In summary, I am afraid I have to =
object to advancing the proposed draft at this time.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">X.509 =
(2000) is, of course, already a standard.&nbsp; I don't see what =
purpose objecting to advancing a profile of this standard will =
serve.&nbsp; If there are specific technical flaws, that's one =
thing.&nbsp; But objecting on the grounds that you think the business =
case for ACs is suspect doesn't make sense.&nbsp; That would be like =
trying to hold up RFC 2459 because you don't think public-key =
certificates will work.&nbsp; Trying to hold up a profile because you =
really object to the base standard seems to be of little =
value.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03782.9E2ADFE0--


Received: from junker.ms.inka.de (clxviii.yapay.inka.de [212.227.15.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08758 for <[e-mail]>; Mon, 16 Oct 2000 07:52:48 -0700 (PDT)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id A440868430 for <[e-mail]>; Mon, 16 Oct 2000 16:57:06 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 16:57:06 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft
References: <00f001c03779$e20bf9a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
> 
> Are you the slightest familiar with XML parsers and schemas?

There's no doubt that it would be interesting to use XML for the
presentation layer because of automatic validation against DTD
retrieved by URL etc. 

But there would be still a need to define the semantics of the
attributes (name space in XML) to make different applications from
different vendors interoperable. Or did I get you totally wrong?

> There is AFAIK not any standardized way to verify that an ASN.1
> document corresponds to its definition.

I leave this question open to the ASN.1 compiler experts.

Ciao, Michael.


Received: from gricmail.gric.com (gricmail.gric.com [207.20.139.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08464 for <[e-mail]>; Mon, 16 Oct 2000 07:49:14 -0700 (PDT)
Received: from fifo (St-Germain-3-91.abo.wanadoo.fr [164.138.49.91]) by gricmail.gric.com (8.9.3/8.8.5) with SMTP id HAA13268; Mon, 16 Oct 2000 07:53:48 -0700 (PDT)
Message-ID: <009c01c03782$663995e0$0200000a@fifo>
From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Bob Jueneman" <[e-mail]>, <[e-mail]>, "Polar Humenn" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <002a01c03747$0cc3d420$[e-mail]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 17:04:22 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Anders,

Since January I was trying to solve a business problem then I came to a
conclusion to the need of a new concept. Investigated it and found something
closse to AC. In fact I can use AC as a building block. Checking IDs and
signing e-mails are a nice to have: that's why PKIs haven't yet been really
deployed.What you can build with AC will become a must have and I expect it
to drive PKI implementations.

Stephen, Polar

I think that Polar addressed a number of valid points but we are looping in
circles to get them fixed: I am not sure I make a list of all of them to
address them one by one. I creates a climate of uncertainty that raises
doubts in Bob's mind.
Can you help better structure the resolution of those issues.

>From my perspective, I see two main objections:

1) How holder is identified ?
Certificate, DN, ...

2) Can you trust DN way to assign attributes ?

3) How trust can be built in PKI ?
a) From a business standpoint
b) From a technical standpoint

Clearly points number 3a and 3b are a very interesting general PKI problem
but should not impact AC.

FFO

> Tim,
>
> >Bob - One of the main reasons for favouring a collection of attribute
certificates over
> >a collection of public-key certificates for asserting privilege is that
one of the main
> >costs associated with public-key certificates is that related to the
management of the
> >corresponding private key.  The private key has to be secured for
confidentiality
>
> You are right but I felt that the core of Bob's criticism of ACs is not
based on security
> issues but rather on the business case (applications if you prefer) for
ACs.
>
> I wholeheartedly agree with Bob that the use of ACs between organizations
is highly dubious
> but if ACs become an RFC or not is something I care less about.  I.e. a
standard that
> no one uses is IMO "harmless".
>
> ACs are though redundant as:
> - ACs have no support in the commercial world including browsers.  Never
will.
> - ACs are in the "wrong" format: ASN.1.  XML is what's counts in
e-business
> - ACs are like PKCs originally thought of replacing paper credentials in
an off-line world. In
> an on-line world authority can be delivered directly from the source which
make issuing,
> distribution, validity, and revocation essentially "no-issues".
>
> Internally there are other solutions such as Kerberos, Externally ACs
complicate things
> more than they solve.
>
> An AC RFC cannot change these basic facts!
>
> BTW, are ACs also anticipated to be used in conjunction with digital
signatures?
> Anyone written a paper on that?
>
> Anders Rundgren
> Senior Internet e-commerce Architect
> X-OBI AB
>



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08232 for <[e-mail]>; Mon, 16 Oct 2000 07:47:28 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA05240; Mon, 16 Oct 2000 10:48:08 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Mon, 16 Oct 2000 10:48:07 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: [e-mail], Carlisle Adams <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 16 Oct 2000, Al Arsenault wrote:

> Stephen Farrell wrote:
> > 
> > Carlisle,
> > 
> > You're overstating the requirements for an AC to be valid. There is
> > no need for the AA and holder to belong to the "same" PKI - the only
> > requirement, in general, is that the RP be able to valiate the AA's PKC
> > and the holder's PKC and that the AC contents be consistent with those
> > two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance
> > we'll never know:-) and also what the PKIX AC profile says. If there is
> > text somewhere clearly to the contrary please point it out.
> > 
> ><rest snipped>
> 
> I agree with Stephen - I can find nothing in the AC I-D that says that
> the AA's PKC and the holder's PKC have to trace back to the same Root
> CA.  And it was my understanding that that was decided to not be a
> requirement.
> As always, I'm willing to be shown where I screwed up, and this is
> actually required - I've been publicly shown to be wrong so many times
> that it doesn't bother me at all.  :-)

I thought it was the case as well, that the AC can really bridge three
PKIs. That means the holder, the AA, and the RP all can have their own
different PKIs with the possibility of cross-certification of all three. I
don't even see a need for cross certification in the model. My browser
"trusts" 137 root certificates without cross-certification, and nobody
seems to care all that much.

> In my opinion, the "security hole" pointed out by Polar can in fact
> occur, either maliciously or by "accident". (e.g., if the holder's PKC
> chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> then there can be a cert under root_CA_2 with the same DN,
> subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> tell which holder PKC to use. And it gets even more interesting if the
> RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> right cert is the one under root_CA_2, and thus everything validates; or
> does the RP think that the right holder PKC is the one under root_CA_1,
> and thus reject the AC?)
> 
> However, I do not believe that the right thing to do is either mandate
> the objectDigest form in the AC, or kill the AC draft.  And I don't
> think it's to insert the requirement that the holder's PKC and the AA's
> PKC chain back to the same root. Rather, I think that the best approach
> is to acknowledge that this risk exists, and live with it. Put in an
> explanation (in Security Considerations, in some other section - in the
> Roadmap, too, in all likelihood - that says that if you trust two
> independent Root CAs, then this is a risk you run.  

This brush off seems to be a hard call for a group that worried so much
about the security and trust relationships of PKI to begin with. 

Well, at the very least, I'm glad that some people in the group actually
see the problem. Whether it amounts to anything significant, I can only
hope.

I cannot recommend the use of such products and services, except in
tightly controlled environments, which rules out e-commerce on the
internet, or even business-to-business on the internet, or anything on the
internet. Call me paranoid, but I am a security person, not an issurance
salesman. Unfortunately, I'd probably make a lot more money if I were the
latter. :)

Cheers,
-Polar

> That's my .02 worth.  And if I'm wrong and missed the part in the I-D
> that says the two certs do have to chain back to the same root, then I
> retract the last two paragraphs.
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07233 for <[e-mail]>; Mon, 16 Oct 2000 07:13:11 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <40P5Z6A3>; Mon, 16 Oct 2000 10:17:37 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'Al Arsenault'" <[e-mail]>
Cc: "'Polar Humenn'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 10:17:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0377B.D54EA4E0"

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_01C0377B.D54EA4E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Al, Stephen,

> ----------
> From: 	Al Arsenault[SMTP:[e-mail]]
> Sent: 	Monday, October 16, 2000 9:37 AM
> To: 	[e-mail]
> Cc: 	Carlisle Adams; 'Polar Humenn'; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Stephen McConnell; Kent Salmond; Ken Mccoy;
> Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Stephen Farrell wrote:
> > 
> > Carlisle,
> > 
> > You're overstating the requirements for an AC to be valid. There is
> > no need for the AA and holder to belong to the "same" PKI - the only
> > requirement, in general, is that the RP be able to valiate the AA's PKC
> > and the holder's PKC and that the AC contents be consistent with those
> > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
> significance
> > we'll never know:-) and also what the PKIX AC profile says. If there is
> > text somewhere clearly to the contrary please point it out.
> > 
> ><rest snipped>
> 
> I agree with Stephen - I can find nothing in the AC I-D that says that
> the AA's PKC and the holder's PKC have to trace back to the same Root
> CA.  And it was my understanding that that was decided to not be a
> requirement.
> As always, I'm willing to be shown where I screwed up, and this is
> actually required - I've been publicly shown to be wrong so many times
> that it doesn't bother me at all.  :-)
 
The text that I quoted in my previous message is from X.509 (2000), not from
the AC I-D.  I have not checked, but I strongly suspect that the I-D says
nothing about this, which is probably why you cannot find it.  I think that
the X.509 text implies this pretty clearly, but I don't think this is stated
explicitly.

> In my opinion, the "security hole" pointed out by Polar can in fact
> occur, either maliciously or by "accident". (e.g., if the holder's PKC
> chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> then there can be a cert under root_CA_2 with the same DN,
> subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> tell which holder PKC to use. And it gets even more interesting if the
> RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> right cert is the one under root_CA_2, and thus everything validates; or
> does the RP think that the right holder PKC is the one under root_CA_1,
> and thus reject the AC?)
 
Yes, I agree that the "security hole" can occur if multiple PKIs are
involved, which is why I believe that the underlying assumption in X.509
(2000) is that there is one PKI and that it is managed in such a way as to
avoid identity collisions through proper use of name constraints.  This
eliminates the security hole (which, ultimately should be the goal of a
security infrastructure).

Even aside from security, however, I think that allowing for multiple PKIs
here is unreasonable in practice.  As Stephen said, what is required is that
the RP can validate the AA's PKC and the holder's PKC and that the AC
contents are consistent with those two PKCs.  But in general the AA
(particularly the SOA) does not know who the relying parties will be,
especially if delegation is involved so that there are intermediate AAs
(this is identical to a root CA not knowing who its relying parties are in
general when there are subordinate CAs in between).  So why would it make
sense for the SOA to create certificates that only RPs with trust anchors in
these two PKIs can validate?  It has no way of knowing if such RPs even
exist (they *probably* do, but the SOA doesn't know who they are, or where
they are, or what their needs/assumptions will be with respect to
authorization)!  I just can't see much value in this level of
generalization.  I'm not saying that this can't be done, or that we should
necessarily do anything to prohibit it, but I don't see the value of it and
I wonder if it actually would be used.

So, I suggest that security and simplicity both lean toward the single PKI
model.

> However, I do not believe that the right thing to do is either mandate
> the objectDigest form in the AC, or kill the AC draft.  And I don't
> think it's to insert the requirement that the holder's PKC and the AA's
> PKC chain back to the same root. Rather, I think that the best approach
> is to acknowledge that this risk exists, and live with it. Put in an
> explanation (in Security Considerations, in some other section - in the
> Roadmap, too, in all likelihood - that says that if you trust two
> independent Root CAs, then this is a risk you run.  
 
Fair enough.  That way, those that are serious about security can "do the
right thing" and those for whom security is less important can "hope that
bad things don't happen"...  :-)

> That's my .02 worth.  And if I'm wrong and missed the part in the I-D
> that says the two certs do have to chain back to the same root, then I
> retract the last two paragraphs.
 
As mentioned above, I doubt that you missed anything in the I-D.  But look
at .509 again with fresh eyes and let me know if I'm just imagining this
underlying assumption in the text.

Carlisle.


------_=_NextPart_001_01C0377B.D54EA4E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi Al, =
Stephen,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 9:37 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams; 'Polar Humenn'; [e-mail]; [e-mail]; =
[e-mail]; [e-mail]; Stephen McConnell; Kent Salmond; Ken =
Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Stephen Farrell wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Carlisle,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; You're overstating the =
requirements for an AC to be valid. There is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; no need for the AA and holder to =
belong to the &quot;same&quot; PKI - the only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; requirement, in general, is that =
the RP be able to valiate the AA's PKC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and the holder's PKC and that =
the AC contents be consistent with those</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; two PKCs. That's what =
X.509(2000) says (ignoring &quot;hints&quot; whose significance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; we'll never know:-) and also =
what the PKIX AC profile says. If there is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; text somewhere clearly to the =
contrary please point it out.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&lt;rest snipped&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with Stephen - I can find =
nothing in the AC I-D that says that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the AA's PKC and the holder's PKC =
have to trace back to the same Root</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CA.&nbsp; And it was my understanding =
that that was decided to not be a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requirement.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As always, I'm willing to be shown =
where I screwed up, and this is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">actually required - I've been =
publicly shown to be wrong so many times</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that it doesn't bother me at =
all.&nbsp; :-)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The text =
that I quoted in my previous message is from X.509 (2000), not from the =
AC I-D.&nbsp; I have not checked, but I strongly suspect that the I-D =
says nothing about this, which is probably why you cannot find =
it.&nbsp; I think that the X.509 text implies this pretty clearly, but =
I don't think this is stated explicitly.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In my opinion, the &quot;security =
hole&quot; pointed out by Polar can in fact</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">occur, either maliciously or by =
&quot;accident&quot;. (e.g., if the holder's PKC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">chains back to root_CA_1, and the =
AA's PKC chains back to root_CA_2,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">then there can be a cert under =
root_CA_2 with the same DN,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">subjectAltName, serial number, ... as =
the holder's PKC. If the RP trusts</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">both root_CA_1 and root_CA_2, then it =
may be the case that the RP can't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">tell which holder PKC to use. And it =
gets even more interesting if the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RP trusts root_CA_2 but not root_CA_1 =
- does the RP assume that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">right cert is the one under =
root_CA_2, and thus everything validates; or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does the RP think that the right =
holder PKC is the one under root_CA_1,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and thus reject the AC?)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, I =
agree that the &quot;security hole&quot; can occur if multiple PKIs are =
involved, which is why I believe that the underlying assumption in =
X.509 (2000) is that there is one PKI and that it is managed in such a =
way as to avoid identity collisions through proper use of name =
constraints.&nbsp; This eliminates the security hole (which, ultimately =
should be the goal of a security infrastructure).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Even aside =
from security, however, I think that allowing for multiple PKIs here is =
unreasonable in practice.&nbsp; As Stephen said, what is required is =
that the RP can validate the AA's PKC and the holder's PKC and that the =
AC contents are consistent with those two PKCs.&nbsp; But in general =
the AA (particularly the SOA) does not know who the relying parties =
will be, especially if delegation is involved so that there are =
intermediate AAs (this is identical to a root CA not knowing who its =
relying parties are in general when there are subordinate CAs in =
between).&nbsp; So why would it make sense for the SOA to create =
certificates that only RPs with trust anchors in these two PKIs can =
validate?&nbsp; It has no way of knowing if such RPs even exist (they =
*probably* do, but the SOA doesn't know who they are, or where they =
are, or what their needs/assumptions will be with respect to =
authorization)!&nbsp; I just can't see much value in this level of =
generalization.&nbsp; I'm not saying that this can't be done, or that =
we should necessarily do anything to prohibit it, but I don't see the =
value of it and I wonder if it actually would be used.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">So, I =
suggest that security and simplicity both lean toward the single PKI =
model.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">However, I do not believe that the =
right thing to do is either mandate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the objectDigest form in the AC, or =
kill the AC draft.&nbsp; And I don't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">think it's to insert the requirement =
that the holder's PKC and the AA's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKC chain back to the same root. =
Rather, I think that the best approach</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is to acknowledge that this risk =
exists, and live with it. Put in an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">explanation (in Security =
Considerations, in some other section - in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Roadmap, too, in all likelihood - =
that says that if you trust two</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">independent Root CAs, then this is a =
risk you run.&nbsp; </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Fair =
enough.&nbsp; That way, those that are serious about security can =
&quot;do the right thing&quot; and those for whom security is less =
important can &quot;hope that bad things don't happen&quot;...&nbsp; =
:-)</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">That's my .02 worth.&nbsp; And if I'm =
wrong and missed the part in the I-D</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that says the two certs do have to =
chain back to the same root, then I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">retract the last two =
paragraphs.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As =
mentioned above, I doubt that you missed anything in the I-D.&nbsp; But =
look at .509 again with fresh eyes and let me know if I'm just =
imagining this underlying assumption in the text.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0377B.D54EA4E0--


Received: from mail.fst.it (mail.fst.it [208.164.5.254]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06696 for <[e-mail]>; Mon, 16 Oct 2000 07:01:42 -0700 (PDT)
Received: from piccione ([213.255.36.10]) by mail.fst.it  with Microsoft SMTPSVC(5.5.1875.185.18); Mon, 16 Oct 2000 16:07:40 +0200
From: "Sergio Tabanelli" <[e-mail]>
To: <[e-mail]>
Subject: RE: Objections to advancing the attribute certificateauthentication draft
Date: Mon, 16 Oct 2000 16:18:27 +0200
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal

Hi all

I know that my knowledges on PKI dosen't stand comparison with those owned
by people participant to this open forum, so please forgive me if the
following comments will seems to you semplicistics and conceited.
I think that one of the problems of the actual use of PKCs is that all of
the Public Administrations, Finantial Institutes and private companies that
use this technology are self issuing their certificates, the risk I am
seeing is that everyone will have dozens of Smart cards or crypto devices in
his pocket or purse, everyone containing a key binded with a PKC issued
under its specific policy and with its specific extensions and keyusage. I
know that the universal CA solution is not a good answer, but I think that
milions of CAs everyone crosscertifing each other is not the right solution
too. IMHO a possible solution is few country based CAs that focus their
activity on certification of individual identities with different levels of
recognitions. Identity certs without any usage reference (keyusage,
extkeyusage, extensions and policy multiplications, ...) and standard
application protocols can help to reduce CA proliferation, semplify policies
and clarify responsabilities assignment. What I am saying is that we don't
need PKC with lots of attributes and extensions but different application
protocols and objects (AC is one example) for different purbose, everyone
based on an identity object, the PKC. Maybe this can be considered banal and
semplicistic but for analogy if "x" is the PKC, and we need y as y=f(x) i
think is better to work on f rather then on x. In conclusion IMHO things
like ACs or new signature protocol like signature policies, signature
request and so on can do the job and help people using this technology,
things like keyusage, non repudiation bit, big PKCs with all in, not.

P.S.
I think that two parties with two distinct rules, authorization issuer and
authorization verifier, can agree to use PKCS7 or CMS with signed attributes
to reach same results as with ACs, I consider ACs as a standard and more
suited way (flawed or not) to do this useful thing.

Sergio Tabanelli



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06559 for <[e-mail]>; Mon, 16 Oct 2000 07:00:07 -0700 (PDT)
Received: from mega (t6o69p24.telia.com [213.64.110.144]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id QAA13127; Mon, 16 Oct 2000 16:04:55 +0200 (CEST)
Message-ID: <00f001c03779$e20bf9a0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "=?iso-8859-1?Q?Michael_Str=F6der?=" <[e-mail]>, <[e-mail]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 16:03:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06560

Michael,

>> Using XML, an AC draft specification would not have to
>> define a single attribute or attribute syntax!
>
>Well, you would have to define a commonly used XML name space to let
>different applications from different vendors work together. Same
>thing as the ASN.1 type definitions used now.


Are you the slightest familiar with XML parsers and schemas?  There
is AFAIK not any standardized way to verify that an ASN.1 document
corresponds to its definition.
And if there is such a feature it is certainly not a part of the standard itself. 
And it is definitely not a part of current operating systems!
Unlike XML which has DOM and SAX APIs.  Regarding the name-space it is
fairly simple using BizTalk as an example.  You publish the XML schema on
a web-site and the name is essentially the URL.  No magic whatsoever.
AC XML schemas (like most XML schemas) would be specialized for different
purposes and geographic regions and must be agreed upon before used. 

Anders



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05549 for <[e-mail]>; Mon, 16 Oct 2000 06:30:58 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Mon, 16 Oct 2000 06:35:56 -0700
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 09:37:12 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Carlisle Adams <[e-mail]>, "'Polar Humenn'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Farrell wrote:
> 
> Carlisle,
> 
> You're overstating the requirements for an AC to be valid. There is
> no need for the AA and holder to belong to the "same" PKI - the only
> requirement, in general, is that the RP be able to valiate the AA's PKC
> and the holder's PKC and that the AC contents be consistent with those
> two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance
> we'll never know:-) and also what the PKIX AC profile says. If there is
> text somewhere clearly to the contrary please point it out.
> 
><rest snipped>

I agree with Stephen - I can find nothing in the AC I-D that says that
the AA's PKC and the holder's PKC have to trace back to the same Root
CA.  And it was my understanding that that was decided to not be a
requirement.
As always, I'm willing to be shown where I screwed up, and this is
actually required - I've been publicly shown to be wrong so many times
that it doesn't bother me at all.  :-)

In my opinion, the "security hole" pointed out by Polar can in fact
occur, either maliciously or by "accident". (e.g., if the holder's PKC
chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
then there can be a cert under root_CA_2 with the same DN,
subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
both root_CA_1 and root_CA_2, then it may be the case that the RP can't
tell which holder PKC to use. And it gets even more interesting if the
RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
right cert is the one under root_CA_2, and thus everything validates; or
does the RP think that the right holder PKC is the one under root_CA_1,
and thus reject the AC?)

However, I do not believe that the right thing to do is either mandate
the objectDigest form in the AC, or kill the AC draft.  And I don't
think it's to insert the requirement that the holder's PKC and the AA's
PKC chain back to the same root. Rather, I think that the best approach
is to acknowledge that this risk exists, and live with it. Put in an
explanation (in Security Considerations, in some other section - in the
Roadmap, too, in all likelihood - that says that if you trust two
independent Root CAs, then this is a risk you run.  

That's my .02 worth.  And if I'm wrong and missed the part in the I-D
that says the two certs do have to chain back to the same root, then I
retract the last two paragraphs.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from junker.ms.inka.de (clxviii.yapay.inka.de [212.227.15.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05547 for <[e-mail]>; Mon, 16 Oct 2000 06:30:56 -0700 (PDT)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 5FE8368430 for <[e-mail]>; Mon, 16 Oct 2000 15:24:38 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 15:24:38 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft
References: <00c801c03770$1826ba70$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
> 
> Using XML, an AC draft specification would not have to
> define a single attribute or attribute syntax!

Well, you would have to define a commonly used XML name space to let
different applications from different vendors work together. Same
thing as the ASN.1 type definitions used now.

Ciao, Michael.


Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04964 for <[e-mail]>; Mon, 16 Oct 2000 06:17:02 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Mon, 16 Oct 2000 06:22:00 -0700
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 09:23:15 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: Michael Myers <[e-mail]>, "'Frank Balluffi'" <[e-mail]>, [e-mail]
Subject: Re: Delegated Path Validation draft.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments in-line, prefaced by my initials.

Michael Zolotarev wrote:
> 
> On the same tune:
> 
> I expect that receiving 'No' answer will be rather an exception than a
> common case of using DVP. 

AWA: I tend to agree with this part. At least I *hope* that it will be
the case.

>If you keep receiving 'No's, it most likely
> indicates that either your trust/policy settings are wrong, or you are under
> attack. Significance of it is that each 'No' case will require human
> intervention, at least at the initial stage of system's operations. With the
> amount of data required to perform adequate 'why No' analysis being larger
> than a single response message can reasonably communicate.
>

AWA: This part I disagree with. Suppose that I'm trying to access some
popular website from my wireless device, so I choose to use DPV.  Say
for the sake of argument that the site I'm accessing is my brokerage
account on "AlTrade".  Now, I get the result that "AlTrade's certificate
does not validate."  While it's true that during initial system testing
(and maybe during the initial operational stages) I'm going to have my
designers/testers go trace back to the problem, I do not believe that
steady-state operation will need or even want human intervention.  One
of the biggest drawbacks to this whole PKI thing in the eyes of many
people is the cost in terms of people needed to make it work.  If you're
going to staff a help-desk to respond to human phone calls saying "I was
trying to buy stock in XYZ; I got a message that the certificate didn't
validate, and no I have no clue what else was involved", you'd better be
ready to shell out some money for people.

Much more efficient would be "AlTrade's certificate does not validate
because the information is not available at this time; please try later
or call 123-456 for help" or "AlTrade's certificate appears to have
expired, please call 987-5432 to update it" or ...  That way, if you do
have to get the human help desk involved, at least you have a clue what
happened.

 
> However, once the system went through the initial tuning up stage, and the
> client has acquaired reasonable trust into quality of decisions by  the DPV
> server, receiving 'No' answer should be just 'flagged' by the client, but
> not investigated.
>

AWA: "Not investigated" is only acceptable if what you really want is
for all of your users to answer "yes" to the question "AlTrade's
certificate did not validate, would you like to continue anyway?" It's
not often that they're just going to give up - and I'm not really sure
that that's what you want your customers to do, anyway.

 
> In short, communicating 'Why No' data to the client is rather a 'roll-out
> stage trace/debug' feature, then normal operation mode feature. Therefore
> making it a part of the core(!) protocol is not very justified, to me.
>

AWA: For the reasons stated above, I disagree.
 
> However, every DPV vendor may of course decide on a special way of ensuring
> that the clients have access to the DPV decision making context. As a
> minimum, I'd expect a server to make its verification procedure logic
> publically known and auditable.
> 
> Frank - I'm still standing on attention to hear why do you think a client
> may want to know 'why Yes'. No jokes. That'd be one of the major requirement
> for audit performed on DPV, if there is for example a legal reason, or
> something...
> 

AWA: I can't think of any reasons to mandate that justification always
be passed with a "yes" answer, but I know of some circumstances where it
would be better to provide "yes, and here's the cert path I validated"
than just "yes". So I'd see "why YES" as more optional than mandatory.

> Michael


			Al Arsenault
			Chief Security Architect
			Diversinet Corp.


Received: from junker.ms.inka.de (clxviii.yapay.inka.de [212.227.15.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04400 for <[e-mail]>; Mon, 16 Oct 2000 06:11:03 -0700 (PDT)
Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 6078068430 for <[e-mail]>; Mon, 16 Oct 2000 13:55:46 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 16 Oct 2000 13:55:44 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Organization: stroeder.com
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: PKIX-List <[e-mail]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft
References: <00a901c03762$c8b0b340$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders Rundgren wrote:
> 
> I.e. instead of
> the misery we have today trying to find out where e-mail addresses in PKCs are
> stored, you either a priori know a certain attribute schema or you just reject it.

Disclaimer: Anders, maybe I totally misunderstood you.

So what's the difference in using ASN.1 or XML? I mean that's what
standards are all about. Defining non-proprietary a-priori knowledge
for applications.

The misery today with RFC822 email adresses is that they were not
present in those old X.500 (especially X.521) days.

Ciao, Michael.


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03448 for <[e-mail]>; Mon, 16 Oct 2000 05:49:55 -0700 (PDT)
Received: from mega (t2o69p14.telia.com [62.20.144.134]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id OAA22042; Mon, 16 Oct 2000 14:54:50 +0200 (CEST)
Message-ID: <00c801c03770$1826ba70$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 14:53:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA03449

David,

> <chuckle>
> 
>I've heard some good arguments for using XML in various contexts, but
>"rigor of schema definition" has never been one of them!


Rigor or rigor.  The thing with XML schemas is that they have a "unique" name that the actual
documents must also contain.  Which a parser can use to automatically verify that
received documents follows the schema definition.  Or a sender can verify that it is sending
a proper document.  There is AFAIK no corresponding feature in X509 certificates
or EDI.  And for clearances and authorizations you'd better understand the message
or reject it.

Using XML, an AC draft specification would not have to define a single attribute or attribute syntax!
Just the container document and its signature part.  The attribute schema may be more or less strict
but that is up to the each AC application implementer to define.

That is indeed something to "chuckle" about compared to having in advance know
("guess" I would say),  how roles, clearances etc. could or should be cast in a digital format!

Anders



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02036 for <[e-mail]>; Mon, 16 Oct 2000 05:11:50 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id HAA28851 for <[e-mail]>; Mon, 16 Oct 2000 07:57:16 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 16 Oct 2000 08:10:02 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: CUKe8un2tP7gQ1M1loDGBA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Anders Rundgren" <[e-mail]>
> 
> Hi,
> Not that I believe that ACs have any value but an XML solution would be simlar
> to BizTalk.  I.e. a generic header format holding an arbitrary XML 
shema-defined
> document holding the actual attributes.  In that way you achieve the 
flexibility to let every
> type of digital relationship define a unique (and from other definitions 
clearly
> separable) set of attributes and corresponding interpretation.  I.e. instead 
of
> the misery we have today trying to find out where e-mail addresses in PKCs are
> stored, you either a priori know a certain attribute schema or you just reject 
it. 
> An AC XML draft could though suggest suitable formats for encrypted items etc.
> 
> Anders



 <chuckle>
 
I've heard some good arguments for using XML in various contexts, but
"rigor of schema definition" has never been one of them!



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29894 for <[e-mail]>; Mon, 16 Oct 2000 04:14:37 -0700 (PDT)
Received: from mega (t5o69p71.telia.com [213.64.110.71]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id NAA09246 for <[e-mail]>; Mon, 16 Oct 2000 13:19:33 +0200 (CEST)
Message-ID: <00a901c03762$c8b0b340$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 13:18:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA29895

Hi,
Not that I believe that ACs have any value but an XML solution would be simlar
to BizTalk.  I.e. a generic header format holding an arbitrary XML shema-defined
document holding the actual attributes.  In that way you achieve the flexibility to let every
type of digital relationship define a unique (and from other definitions clearly
separable) set of attributes and corresponding interpretation.  I.e. instead of
the misery we have today trying to find out where e-mail addresses in PKCs are
stored, you either a priori know a certain attribute schema or you just reject it. 
An AC XML draft could though suggest suitable formats for encrypted items etc.

Anders



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA22997 for <[e-mail]>; Mon, 16 Oct 2000 02:17:45 -0700 (PDT)
Received: from mega (t2o69p112.telia.com [62.20.144.232]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA11571; Mon, 16 Oct 2000 11:22:34 +0200 (CEST)
Message-ID: <006d01c03752$7106c950$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Michael Zolotarev" <[e-mail]>, "Bob Jueneman" <[e-mail]>, <[e-mail]>, "Tim Moses" <[e-mail]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 11:21:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA22998

Michael,

>> - ACs are in the "wrong" format: ASN.1.  XML is what's counts 
>> in e-business
>
>Rather, XML is what's *hot* in e-business. I'm not saying 'No' to XML. But I
>do not accept it as an argument. The encoding format doesn't affect the
>concept. There is a lot of things that can be blamed for being non-XML,
>however widely accepted for more than historical reasons.


That the concept is not affected by format is true.  Market acceptance is another thing.
That PKCs are in ASN.1 is less of a problem as they are essentially only used as a
an mechanism to bind a named entity to a public key.  ACs are more subject to "interpretation".
And more, it is a *new* thing which may call for a *new* format.   Note: I personally do not suggest
changing anything in the AC specification as it is pretty useless anyway.

<snip>

>> Externally ACs complicate things
>> more than they solve.
>I'd like to hear more *meaty* arguments for it :)


I believe that Bob's initial message had plenty of "beef"!

Anders




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19835 for <[e-mail]>; Mon, 16 Oct 2000 01:22:59 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id SAA00468; Mon, 16 Oct 2000 18:35:02 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <VAHVC9ZB>; Mon, 16 Oct 2000 19:26:15 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Anders Rundgren <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail], Tim Moses <[e-mail]>
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Mon, 16 Oct 2000 19:26:14 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Anders,

> ACs are though redundant as:
> - ACs have no support in the commercial world

It is easy to claim that something that has just been formally defined has
no support in commercial world. 

> including browsers.  Never will. 

Probably. However we can see how it CAN be used, and some certain advantages
of it. So the time may change current (yet still very much questionable)
attitude.

> - ACs are in the "wrong" format: ASN.1.  XML is what's counts 
> in e-business

Rather, XML is what's *hot* in e-business. I'm not saying 'No' to XML. But I
do not accept it as an argument. The encoding format doesn't affect the
concept. There is a lot of things that can be blamed for being non-XML,
however widely accepted for more than historical reasons.


> - ACs are like PKCs originally thought of replacing paper 
> credentials in an off-line world. In
> an on-line world authority can be delivered directly from the 
> source which make issuing,
> distribution, validity, and revocation essentially "no-issues".

This is a 'pull' model, which is one of defined by the draft.

> 
> Internally there are other solutions such as Kerberos, 
The same argument applies to using PKC in general.


> Externally ACs complicate things
> more than they solve.
I'd like to hear more *meaty* arguments for it :)

Regards
Michael


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18423 for <[e-mail]>; Mon, 16 Oct 2000 00:56:08 -0700 (PDT)
Received: from mega (t4o69p109.telia.com [62.20.145.229]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id KAA09652; Mon, 16 Oct 2000 10:01:01 +0200 (CEST)
Message-ID: <002a01c03747$0cc3d420$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, "Tim Moses" <[e-mail]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 09:59:44 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA18424

Tim,

>Bob - One of the main reasons for favouring a collection of attribute certificates over
>a collection of public-key certificates for asserting privilege is that one of the main 
>costs associated with public-key certificates is that related to the management of the
>corresponding private key.  The private key has to be secured for confidentiality 

You are right but I felt that the core of Bob's criticism of ACs is not based on security
issues but rather on the business case (applications if you prefer) for ACs.

I wholeheartedly agree with Bob that the use of ACs between organizations is highly dubious
but if ACs become an RFC or not is something I care less about.  I.e. a standard that
no one uses is IMO "harmless".

ACs are though redundant as:
- ACs have no support in the commercial world including browsers.  Never will.
- ACs are in the "wrong" format: ASN.1.  XML is what's counts in e-business
- ACs are like PKCs originally thought of replacing paper credentials in an off-line world. In
an on-line world authority can be delivered directly from the source which make issuing,
distribution, validity, and revocation essentially "no-issues".

Internally there are other solutions such as Kerberos, Externally ACs complicate things
more than they solve.

An AC RFC cannot change these basic facts!

BTW, are ACs also anticipated to be used in conjunction with digital signatures?
Anyone written a paper on that?

Anders Rundgren
Senior Internet e-commerce Architect
X-OBI AB



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09316 for <[e-mail]>; Sun, 15 Oct 2000 18:24:03 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <46BW9SXT>; Sun, 15 Oct 2000 21:30:05 -0400
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: [e-mail]
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Sun, 15 Oct 2000 21:21:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0370F.599FDCE0"

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_01C0370F.599FDCE0
Content-Type: text/plain;
	charset="iso-8859-1"

Bob - One of the main reasons for favouring a collection of attribute
certificates over a collection of public-key certificates for asserting
privilege is that one of the main costs associated with public-key
certificates is that related to the management of the corresponding private
key.  The private key has to be secured for confidentiality and it has to be
activated, rolled-over and revoked.  

-----Original Message-----
From: Bob Jueneman [mailto:[e-mail]]
Sent: Friday, October 13, 2000 6:57 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; <Ed Reed
Subject: Objections to advancing the attribute certificate
authentication draft


>
>PKCs bind a public key to an identity.
>
>ACs bind attributes to an identity.
>
>Authentication, which includes validating the PKC certification path and 
>having the remote party perform some operation that involves the private 
>key associated with the identity.  Without authentication of the identity, 
>who cares what attributes are associated with it?
>
>Russ

The more I read and think about the issues Polar has brought up the more I
am convinced that the very notion of attribute certificates is potentially
flawed, and the business case highly suspect.  They may have had some
validity back in the X.509 v1 time frame, before more general extensions
were allowed, but I am far from convinced that they are necessary, and may
not even be workable.

Let me begin with a few paragraphs from the draft RFC:

   First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. Second,
   the PKC issuer is not usually authoritative for the authorization
   information. This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC. Yet, authorization information also needs
   to be bound to an identity. An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

Although it is certainly true that clearances or rights may not have the
same lifetime as an identity per se, in general those clearances or rights
are quite likely to last LONGER than any reasonable public key/certificate
validity period. An exception might be a short-lived right or capability,
similar to that granted by a Kerberos ticket, but in that case the right is
generally not tied directly to an identity per se, but is better conveyed by
demonstrating that the user possesses a private key that is tied to that
right via the public key.  In any case, certificates are cheap -- they're
just a bag of bits -- and such rights could more easily be conveyed by a
standard X.509 cert that does contain a public key.  

Secondly, I tend to disagree with the assertion that the PKC issuer is not
usually authoritative for the authorization information.  This assumes a
separation of function of identity confirmation vs. authorization which I
simply haven't seen demonstrated in practice, except arguably in some
European systems where the State is issuing high-grade identity certificates
to their citizens.

Within the US, at least, I would claim that 99.9% all of the identity
certificates that  have been issued were either created by or vouched for by
an organizational RA, or were issued by the organization itself. And
inevitably it is that organization that is authoritative for the
authorization information.  The exception to this might be e-mail address
certificates (the equivalent of the VeriSign class 1 certificates) which are
low due-diligence and arguably not identity certificates at all.  It seems
unlikely that such certs would ever be used to authenticate an attribute
cert.

Finally, I also disagree with the third assumption, i.e., that authorization
needs to be bound to an identity.  It often is, of course, but it need not
be, and there are plenty of examples such as extranet access control where
identity may be relevant to audit, but not to access control.  Knowing the
identity in advance might be a management impossibility -- it is just too
hard fro one organization to keep up with everything going on in another
organization, even if they wanted to.  All that is necessary is to know
whether the entity which controls a given private key has the authority to
perform certain functions.

In addition, in some cases it is highly desirable that authorization NOT be
tied to identity, or at least that the identity be anonymous. An example
might be a teen-aged girl that wants to log in to get the results of her
pregnancy test, but without revealing her name.  In that case a standard
X.509 certificate could be used that contained a security label attribute
and nothing more than a serial number, with no DN.

Because attribute certificates are presently tied to a distinguished NAME
that is presumably contained in an identity certificate, but not necessarily
to any particular public/private key or certificate, path validation up the
chain to two different CAs would seem to be a nightmare, and revocation
even worse.

Finally, even the authors of the attribute certificate draft didn't know how
to control a chain of authorization certificates, and in particular how to
control delegation of rights, and so they only allow a one-deep attribute
certificate chain.  They also don't seem to know how to control the
interpretation of the semantics of a particular security label.  So they
throw up their hands and invoke a deus ex machina type of solution, saying
that the relying parties have to "trust the attribute authority root."  This
is no solution at all.

In an offline note to me, Ed Reed recently made another cogent observation.
Whereas incorporating a security/clearance/rights label in an identity
certificate binds that label inextricably to the public key (and to the
identity, if that matters), the same is not true of an attribute
certificate.  

In particular, if the function of the security label is to DENY the
delegation of some particular capability or default to an entity, then all
that entity has to do is to conveniently "lose" the attribute certificate
and he is back in business.  This may not be obvious, but without negative
delegation I really have no way to definitive way to control what CAs I
trust to control what functions, except by the very ponderous mechanisms of
closed user groups and policy OID constraints. Yuch.

The current situation, with dozens or perhaps hundreds of "trusted" roots in
the various relying party software is a mess that is about to become a
disaster, because enterprises have no convenient way of controlling what
roots are really to be trusted, and for what.  I am increasingly convinced
that adding attribute certificates to this already fragile structure will
cause the entire house of cards to collapse.

We have already seen in the E-sign legislation that a number of opponents
(well-intentioned or not so well intentioned) have pushed for an won the
right to use "technology-neutral" alternatives to PKI.  If we continue to
add more and more complexity with less and less justification, as I believe
we are doing over and over again, I predict that we will see a
counter-revolution, and "press one to confirm nonrepudiation" will become
the norm.

In summary, I am afraid I have to object to advancing the proposed draft at
this time.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

------_=_NextPart_001_01C0370F.599FDCE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Objections to advancing the attribute certificate =
authentication draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob - One of the main reasons for favouring a =
collection of attribute certificates over a collection of public-key =
certificates for asserting privilege is that one of the main costs =
associated with public-key certificates is that related to the =
management of the corresponding private key.&nbsp; The private key has =
to be secured for confidentiality and it has to be activated, =
rolled-over and revoked.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Jueneman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 13, 2000 6:57 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; [e-mail]; =
&lt;Ed Reed</FONT>
<BR><FONT SIZE=3D2>Subject: Objections to advancing the attribute =
certificate</FONT>
<BR><FONT SIZE=3D2>authentication draft</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;PKCs bind a public key to an identity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;ACs bind attributes to an identity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Authentication, which includes validating the =
PKC certification path and </FONT>
<BR><FONT SIZE=3D2>&gt;having the remote party perform some operation =
that involves the private </FONT>
<BR><FONT SIZE=3D2>&gt;key associated with the identity.&nbsp; Without =
authentication of the identity, </FONT>
<BR><FONT SIZE=3D2>&gt;who cares what attributes are associated with =
it?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
</P>

<P><FONT SIZE=3D2>The more I read and think about the issues Polar has =
brought up the more I am convinced that the very notion of attribute =
certificates is potentially flawed, and the business case highly =
suspect.&nbsp; They may have had some validity back in the X.509 v1 =
time frame, before more general extensions were allowed, but I am far =
from convinced that they are necessary, and may not even be =
workable.</FONT></P>

<P><FONT SIZE=3D2>Let me begin with a few paragraphs from the draft =
RFC:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; First, authorization information often =
does not have the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; same lifetime as the binding of the =
identity and the public key.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; When authorization information is =
placed in a PKC extension, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; general result is the shortening of the =
PKC useful lifetime. Second,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the PKC issuer is not usually =
authoritative for the authorization</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information. This results in additional =
steps for the PKC issuer to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; obtain authorization information from =
the authoritative source.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; For these reasons, it is often better to =
separate authorization</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information from the PKC. Yet, =
authorization information also needs</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; to be bound to an identity. An AC =
provides this binding; it is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; simply a digitally signed (or =
certified) identity and set of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; attributes.</FONT>
</P>

<P><FONT SIZE=3D2>Although it is certainly true that clearances or =
rights may not have the same lifetime as an identity per se, in general =
those clearances or rights are quite likely to last LONGER than any =
reasonable public key/certificate validity period. An exception might =
be a short-lived right or capability, similar to that granted by a =
Kerberos ticket, but in that case the right is generally not tied direct=
ly to an identity per se, but is better conveyed by demonstrating that =
the user possesses a private key that is tied to that right via the =
public key.&nbsp; In any case, certificates are cheap -- they're just a =
bag of bits -- and such rights could more easily be conveyed by a =
standard X.509 cert that does contain a public key.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Secondly, I tend to disagree with the assertion that =
the PKC issuer is not usually authoritative for the authorization =
information.&nbsp; This assumes a separation of function of identity =
confirmation vs. authorization which I simply haven't seen demonstrated =
in practice, except arguably in some European systems where the State =
is issuing high-grade identity certificates to their =
citizens.</FONT></P>

<P><FONT SIZE=3D2>Within the US, at least, I would claim that 99.9% all =
of the identity certificates that&nbsp; have been issued were either =
created by or vouched for by an organizational RA, or were issued by =
the organization itself. And inevitably it is that organization that is =
authoritative for the authorization information.&nbsp; The exception to =
this might be e-mail address certificates (the equivalent of the =
VeriSign class 1 certificates) which are low due-diligence and arguably =
not identity certificates at all.&nbsp; It seems unlikely that such =
certs would ever be used to authenticate an attribute cert.</FONT></P>

<P><FONT SIZE=3D2>Finally, I also disagree with the third assumption, =
i.e., that authorization needs to be bound to an identity.&nbsp; It =
often is, of course, but it need not be, and there are plenty of =
examples such as extranet access control where identity may be relevant =
to audit, but not to access control.&nbsp; Knowing the identity in =
advance might be a management impossibility -- it is just too hard fro =
one organization to keep up with everything going on in another =
organization, even if they wanted to.&nbsp; All that is necessary is to =
know whether the entity which controls a given private key has the =
authority to perform certain functions.</FONT></P>

<P><FONT SIZE=3D2>In addition, in some cases it is highly desirable =
that authorization NOT be tied to identity, or at least that the =
identity be anonymous. An example might be a teen-aged girl that wants =
to log in to get the results of her pregnancy test, but without =
revealing her name.&nbsp; In that case a standard X.509 certificate =
could be used that contained a security label attribute and nothing =
more than a serial number, with no DN.</FONT></P>

<P><FONT SIZE=3D2>Because attribute certificates are presently tied to =
a distinguished NAME that is presumably contained in an identity =
certificate, but not necessarily to any particular public/private key =
or certificate, path validation up the chain to two different CAs would =
seem to be a nightmare, and revocation&nbsp; even worse.</FONT></P>

<P><FONT SIZE=3D2>Finally, even the authors of the attribute =
certificate draft didn't know how to control a chain of authorization =
certificates, and in particular how to control delegation of rights, =
and so they only allow a one-deep attribute certificate chain.&nbsp; =
They also don't seem to know how to control the interpretation of the =
semantics of a particular security label.&nbsp; So they throw up their =
hands and invoke a deus ex machina type of solution, saying that the =
relying parties have to &quot;trust the attribute authority =
root.&quot;&nbsp; This is no solution at all.</FONT></P>

<P><FONT SIZE=3D2>In an offline note to me, Ed Reed recently made =
another cogent observation.&nbsp; Whereas incorporating a =
security/clearance/rights label in an identity certificate binds that =
label inextricably to the public key (and to the identity, if that =
matters), the same is not true of an attribute certificate.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>In particular, if the function of the security label =
is to DENY the delegation of some particular capability or default to =
an entity, then all that entity has to do is to conveniently =
&quot;lose&quot; the attribute certificate and he is back in =
business.&nbsp; This may not be obvious, but without negative =
delegation I really have no way to definitive way to control what CAs I =
trust to control what functions, except by the very ponderous =
mechanisms of closed user groups and policy OID constraints. =
Yuch.</FONT></P>

<P><FONT SIZE=3D2>The current situation, with dozens or perhaps =
hundreds of &quot;trusted&quot; roots in the various relying party =
software is a mess that is about to become a disaster, because =
enterprises have no convenient way of controlling what roots are really =
to be trusted, and for what.&nbsp; I am increasingly convinced that =
adding attribute certificates to this already fragile structure will =
cause the entire house of cards to collapse.</FONT></P>

<P><FONT SIZE=3D2>We have already seen in the E-sign legislation that a =
number of opponents (well-intentioned or not so well intentioned) have =
pushed for an won the right to use &quot;technology-neutral&quot; =
alternatives to PKI.&nbsp; If we continue to add more and more =
complexity with less and less justification, as I believe we are doing =
over and over again, I predict that we will see a counter-revolution, =
and &quot;press one to confirm nonrepudiation&quot; will become the =
norm.</FONT></P>

<P><FONT SIZE=3D2>In summary, I am afraid I have to object to advancing =
the proposed draft at this time.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>Robert R. Jueneman</FONT>
<BR><FONT SIZE=3D2>Security Architect</FONT>
<BR><FONT SIZE=3D2>Novell, Inc. -- the leading provider of Net services =
software.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0370F.599FDCE0--


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07836 for <[e-mail]>; Sun, 15 Oct 2000 16:21:18 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA03659; Mon, 16 Oct 2000 09:32:48 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LK9A>; Mon, 16 Oct 2000 10:24:17 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Michael Myers <[e-mail]>, Michael Zolotarev <[e-mail]>, "'Frank Balluffi'" <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Mon, 16 Oct 2000 10:24:09 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

On the same tune: 

I expect that receiving 'No' answer will be rather an exception than a
common case of using DVP. If you keep receiving 'No's, it most likely
indicates that either your trust/policy settings are wrong, or you are under
attack. Significance of it is that each 'No' case will require human
intervention, at least at the initial stage of system's operations. With the
amount of data required to perform adequate 'why No' analysis being larger
than a single response message can reasonably communicate.

However, once the system went through the initial tuning up stage, and the
client has acquaired reasonable trust into quality of decisions by  the DPV
server, receiving 'No' answer should be just 'flagged' by the client, but
not investigated.

In short, communicating 'Why No' data to the client is rather a 'roll-out
stage trace/debug' feature, then normal operation mode feature. Therefore
making it a part of the core(!) protocol is not very justified, to me.

However, every DPV vendor may of course decide on a special way of ensuring
that the clients have access to the DPV decision making context. As a
minimum, I'd expect a server to make its verification procedure logic
publically known and auditable.

Frank - I'm still standing on attention to hear why do you think a client
may want to know 'why Yes'. No jokes. That'd be one of the major requirement
for audit performed on DPV, if there is for example a legal reason, or
something...

Michael

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Saturday, 14 October 2000 7:50
> To: Michael Zolotarev; 'Frank Balluffi'; Michael Myers;
> [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> 
> I generally agree.  I'm doing all I can to advocate for a 
> principle that
> "simpler is better until compelling proven otherwise." 
> However, it was a
> criticism of 2560 that there exists more easily predictable 
> error status
> values than 2560 currently recognizes.  I propose that we 
> take a look at
> that, building on Frank's suggestions and perhaps those of 
> others, but that
> we do not create a sub-protocol for error cause discovery.
> 
> Mike
> 
> > -----Original Message-----
> > From: Michael Zolotarev [mailto:[e-mail]]
> > Sent: Friday, October 13, 2000 8:19 AM
> > To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> > [e-mail]
> > Subject: RE: Delegated Path Validation draft.
> > 
> > 
> > Frank,
> > 
> > please, do not go this way. Keep it simple. 
> > Realistically speaking, a client only needs a simple 'yes' or 
> > 'now'. The
> > whole purpose of defining a TTP for path validation was to 
> > simplify things.
> > 
> > If a client is not satisfied by the 'yes' or 'now', there are 
> > other options
> > (other then been shot, of course). Mind you I fail undestand 
> > why a client
> > would ever ask 'why yes?' - would like to hear from you on this one,
> > frankly. 
> > 
> > To find out why 'No', a client can use DPD to get the path, 
> > and then ask DPV
> > for each component in the path.
> > 
> > Otherwise we'll end up with a hugely blown-up service, which 
> > wasn't the
> > purpose of the exercise.
> > 
> > M
> 


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01352 for <[e-mail]>; Sun, 15 Oct 2000 09:51:20 -0700 (PDT)
Received: by balinese.baltimore.ie; id RAA12178; Sun, 15 Oct 2000 17:56:13 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma012175; Sun, 15 Oct 00 17:55:37 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA15108; Sun, 15 Oct 2000 17:51:47 +0100
Message-ID: <[e-mail]>
Date: Sun, 15 Oct 2000 17:52:17 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], "<Ed Reed" <[e-mail]>
Subject: Re: Objections to advancing the attribute certificateauthentication  draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

I don't think your objection should be entertained for the following
reasons:

Profiling of ACs is in the PKIX charter. This document has been discussed
on the PKIX list for more than 18 months now. You have not objected to
it before, though you have discussed it before on the list. Your mail
contains no specific technical issues with the document but rather just
some indication of your "feelings" towards it (phrases like: "I tend to 
disagree...",  "It seems unlikely that..." etc.)

The only point where you directly quote the draft is the discussion
on the "lifetime" of attributes in PKCs and ACs. This was discussed
at length on the PKIX list a long time back (not sure if you were
part of that or not?), but in any case it did get WG discussion.
The consensus was against the position you express in your mail.

And lastly:

> Finally, even the authors of the attribute certificate draft didn't know 
> how to control a chain of authorization certificates, and in particular 
> how to control delegation of rights, and so they only allow a one-deep 
> attribute certificate chain.  

I quote this directly since I'd love to know how you know what I know 
and what I don't know. In fact, the main reason for omitting AC chains 
is relative simplicity. I do have some doubts that the X.509(2000) model 
for delegation can be made to work well, but that is quite different 
from not knowing "how to control a chain". 

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00802 for <[e-mail]>; Sun, 15 Oct 2000 09:29:19 -0700 (PDT)
Received: by balinese.baltimore.ie; id RAA11971; Sun, 15 Oct 2000 17:34:13 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma011967; Sun, 15 Oct 00 17:33:48 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA14883; Sun, 15 Oct 2000 17:30:46 +0100
Message-ID: <[e-mail]>
Date: Sun, 15 Oct 2000 17:31:15 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'Polar Humenn'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

You're overstating the requirements for an AC to be valid. There is 
no need for the AA and holder to belong to the "same" PKI - the only 
requirement, in general, is that the RP be able to valiate the AA's PKC 
and the holder's PKC and that the AC contents be consistent with those 
two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance 
we'll never know:-) and also what the PKIX AC profile says. If there is
text somewhere clearly to the contrary please point it out.

Of course, if anyone chooses to implement their RP s/w in the way you've
described then that's just fine, but irrelevant for AC profile.

Stephen.

> Carlisle Adams wrote:
> 
> Hi Polar,
> 
>      ----------
>      From:   Polar Humenn[SMTP:[e-mail]]
>      Sent:   Friday, October 13, 2000 1:14 PM
>      To:     Carlisle Adams
>      Cc:     Stephen Farrell; [e-mail]; [e-mail]; [e-mail]; [e-mail];
>      Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai
>      Chin
> 
>      Subject:        RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
>      Carlisle,
> 
>      Thank you for your very learned and well formed response.
> 
>      You do draw an important conclusion that the AA and the Holder must belong
>      to the same "well-behaved" PKI in order for this scheme to work correctly.
>      (I wonder how many PKI's are actually really well-behaved? :).
> 
> 
> Good question.  On the other hand, why would anyone expect to get security from a system that was
> not "well-behaved"?  If security is important to you, the onus is on you to choose (buy,
> implement, deploy, whatever) your PKI carefully...
> 
>      In any case, I do not see anywhere in the ac509 profile that specifies
>      that AA must belong to the same PKI (under the same rootCA?) as the
>      Holder's it authorizes? Can you point me to some text stating this
>      requirement, or some text that somehow implies this requirement?
> 
> 
> Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly through the profile
> document, so I can't comment on that one at the moment, but this implication is definitely there
> in X.509 (2000).  As one example, all through the sections on attribute certificates it talks
> about "the" PKI, so it seems that the AC-based PMI is to be tied to only a single PKI.  Slightly
> more explicitly, however, Clause 16.1 ("Basic processing procedure"), begins as follows:
> 
>      "The signature on every certificate in the path must be verified. Procedures related to
>      validating signatures and public-key certificates are not repeated in this clause. The
>      privilege verifier must verify the identity of every entity in the path, using the procedures
>      of clause 10. Note that checking the signature on an attribute certificate necessarily
>      involves checking the referenced public-key certificate for its validity. Where privileges
>      are assigned using attribute certificates, path processing engines will need to consider
>      elements of both the PMI and the PKI in the course of determining the ultimate validity of a
>      privilege asserter's attribute certificate."
> 
> ACs and PKCs are talked about "in the same breath" with respect to validity checking and identity
> verification.  The referenced Clause 10 ("Certification path processing procedure") lists the
> inputs to the procedure in Section 10.1.  One of the inputs is "a trusted public key value or key
> identifier (if the key is stored internally to the certification path processing module), for use
> in verifying the first certificate in the certification path".  This strongly implies to me that
> there is a single trusted root key that forms the starting point for all the path processing
> (which includes the AC path as well as the PKC path).
> 
>      I also see this requirement to be a crippling constraint.
> 
>      The requirement for the AA and the Holder's it certificate to belong to the
>      same PKI means that I will be able to authorize certain subject entities
>      from HisCarCompany to have access to resources in MyCarCompany, unless I
>      do one of the following:
> 
>      1. Create a new identity at MyCarCompany for subject entity X in
>         HisCarCompany.
>           This is undesirable for many reasons. For example,
>           if Person X from HisCarCompany gets fired. Also, it to generate
>           new keys, new certificates, new names, new password, new
>           token card, etc. Now, causes a single-sign-on scenario.
> 
>      2. Create an entirely new PKI for the interested parties and an AA.
>           Out of the question for most. It's Way too much work with new keys,
>           new names, new passwords, new tokens cards, etc.
> 
> 
> This is not a crippling constraint because neither of the above undesirable actions need to be
> taken.  If these two companies want to work together, they need to issue cross-certificates
> between their root CAs anyway so that authentication can take place.  Cross-certification ties
> these previously-independent PKIs together, so that there is only a single PKI.  Appropriate name
> constraints in the cross-certificates ensure that identity clashes will be ruled out of the
> picture, and authorization based upon attribute certificates can proceed securely.
> 
>      It would be nice if PKI and AA combined could solve the single-sign-on
>      problem.
> 
> 
> If the companies follow what is outlined above, single sign-on is preserved.
> 
>      Of course, this problem would go away, if there is only one RootCA for all
>      organzations, and therefore on PKI. For example, HisCarCompany, and
>      MyCarCompany must get our CA certificates signed by the Verisign RootCA.
>      And we and everybody that Verisign signs, must be well behaved, and the DN
>      space is consequently unique.
> 
> 
> I'm sure you can imagine that Entrust and Baltimore and many other PKI providers would not be
> content with the scenario you paint...  :-)
> 
> But seriously, people recognized a long time ago that a single root for the whole world will not
> work.  This is why cross-certification was invented -- so that independently-deployed PKIs can be
> joined to form a single, workable PKI.  This is why the term "PKI networking" is sometimes used
> instead of "cross-certification" (it seems slightly more descriptive).
> 
>      Is this approach realistic and practical?
> 
> 
> What I described above, I believe, has the qualities of both realism and practicality.
> Cross-certification is what allows you to grow your PKI to include other environments, but in a
> very controlled and reasoned manner.  Attribute certificates take the power of this secure, yet
> flexible, authentication technology and overlays the power of secure, yet flexible,
> authorization.  It's a very strong combination!
> 
> Carlisle.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA09560 for <[e-mail]>; Fri, 13 Oct 2000 17:06:23 -0700 (PDT)
Received: (qmail 26943 invoked from network); 14 Oct 2000 00:11:00 -0000
Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 14 Oct 2000 00:11:00 -0000
Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 13 Oct 2000 19:10:57 -0500
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 17:10:59 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail], [e-mail]
Subject: Re: Objections to advancing the attribute certificateauthentication  draft
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

IMO, attribute certificates as defined in the draft can be seen as a “patch” type
of solution that may introduce a series of inconsistencies (e.g., revocation
lists for either type of certificate, cross dependencies, etc.) that will only
highlight the broken model of trust being used.

On the other hand, attribute certificates with more attributes will tend to
have a shorter lifetime than attribute certificates with a lesser number of
attributes. The formula I calculated under very general assumptions which
I believe hold for the majority of cases is that the lifetime of the certificate
is inversely proportional to the sum of the inverse of each independent
attribute's lifetime (see PKIX archives, 99).

This means that it is indeed advantageous to divide information in attribute
certificates so that expiration of one short-lived attribute will not invalidate
an entire certificate with otherwise long-lived data. The analogy (due to Tony
Bartoletti at the time) is a box with dynamite sticks where upon the explosion
of one stick the entire box explodes – which sets a limit for the number of dynamite
sticks that one can safely store in one place. Placing too many attributes in one
certificate is generally not a good idea and this may be the only justification I
would find for PKIX to advance the draft, in spite of my first comment above.

Cheers,

Ed Gerck



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA08146 for <[e-mail]>; Fri, 13 Oct 2000 15:52:20 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Oct 2000 16:56:35 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 13 Oct 2000 16:56:33 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "<Ed Reed" <[e-mail]>
Subject: Objections to advancing the attribute certificate authentication draft
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA08147

>
>PKCs bind a public key to an identity.
>
>ACs bind attributes to an identity.
>
>Authentication, which includes validating the PKC certification path and 
>having the remote party perform some operation that involves the private 
>key associated with the identity.  Without authentication of the identity, 
>who cares what attributes are associated with it?
>
>Russ

The more I read and think about the issues Polar has brought up the more I am convinced that the very notion of attribute certificates is potentially flawed, and the business case highly suspect.  They may have had some validity back in the X.509 v1 time frame, before more general extensions were allowed, but I am far from convinced that they are necessary, and may not even be workable.

Let me begin with a few paragraphs from the draft RFC:

   First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. Second,
   the PKC issuer is not usually authoritative for the authorization
   information. This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC. Yet, authorization information also needs
   to be bound to an identity. An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

Although it is certainly true that clearances or rights may not have the same lifetime as an identity per se, in general those clearances or rights are quite likely to last LONGER than any reasonable public key/certificate validity period. An exception might be a short-lived right or capability, similar to that granted by a Kerberos ticket, but in that case the right is generally not tied directly to an identity per se, but is better conveyed by demonstrating that the user possesses a private key that is tied to that right via the public key.  In any case, certificates are cheap -- they're just a bag of bits -- and such rights could more easily be conveyed by a standard X.509 cert that does contain a public key.  

Secondly, I tend to disagree with the assertion that the PKC issuer is not usually authoritative for the authorization information.  This assumes a separation of function of identity confirmation vs. authorization which I simply haven't seen demonstrated in practice, except arguably in some European systems where the State is issuing high-grade identity certificates to their citizens.

Within the US, at least, I would claim that 99.9% all of the identity certificates that  have been issued were either created by or vouched for by an organizational RA, or were issued by the organization itself. And inevitably it is that organization that is authoritative for the authorization information.  The exception to this might be e-mail address certificates (the equivalent of the VeriSign class 1 certificates) which are low due-diligence and arguably not identity certificates at all.  It seems unlikely that such certs would ever be used to authenticate an attribute cert.

Finally, I also disagree with the third assumption, i.e., that authorization needs to be bound to an identity.  It often is, of course, but it need not be, and there are plenty of examples such as extranet access control where identity may be relevant to audit, but not to access control.  Knowing the identity in advance might be a management impossibility -- it is just too hard fro one organization to keep up with everything going on in another organization, even if they wanted to.  All that is necessary is to know whether the entity which controls a given private key has the authority to perform certain functions.

In addition, in some cases it is highly desirable that authorization NOT be tied to identity, or at least that the identity be anonymous. An example might be a teen-aged girl that wants to log in to get the results of her pregnancy test, but without revealing her name.  In that case a standard X.509 certificate could be used that contained a security label attribute and nothing more than a serial number, with no DN.

Because attribute certificates are presently tied to a distinguished NAME that is presumably contained in an identity certificate, but not necessarily to any particular public/private key or certificate, path validation up the chain to two different CAs would seem to be a nightmare, and revocation  even worse.

Finally, even the authors of the attribute certificate draft didn't know how to control a chain of authorization certificates, and in particular how to control delegation of rights, and so they only allow a one-deep attribute certificate chain.  They also don't seem to know how to control the interpretation of the semantics of a particular security label.  So they throw up their hands and invoke a deus ex machina type of solution, saying that the relying parties have to "trust the attribute authority root."  This is no solution at all.

In an offline note to me, Ed Reed recently made another cogent observation.  Whereas incorporating a security/clearance/rights label in an identity certificate binds that label inextricably to the public key (and to the identity, if that matters), the same is not true of an attribute certificate.  

In particular, if the function of the security label is to DENY the delegation of some particular capability or default to an entity, then all that entity has to do is to conveniently "lose" the attribute certificate and he is back in business.  This may not be obvious, but without negative delegation I really have no way to definitive way to control what CAs I trust to control what functions, except by the very ponderous mechanisms of closed user groups and policy OID constraints. Yuch.

The current situation, with dozens or perhaps hundreds of "trusted" roots in the various relying party software is a mess that is about to become a disaster, because enterprises have no convenient way of controlling what roots are really to be trusted, and for what.  I am increasingly convinced that adding attribute certificates to this already fragile structure will cause the entire house of cards to collapse.

We have already seen in the E-sign legislation that a number of opponents (well-intentioned or not so well intentioned) have pushed for an won the right to use "technology-neutral" alternatives to PKI.  If we continue to add more and more complexity with less and less justification, as I believe we are doing over and over again, I predict that we will see a counter-revolution, and "press one to confirm nonrepudiation" will become the norm.

In summary, I am afraid I have to object to advancing the proposed draft at this time.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07392 for <[e-mail]>; Fri, 13 Oct 2000 14:54:18 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA01479; Fri, 13 Oct 2000 17:54:50 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 13 Oct 2000 17:54:49 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Carlise,

On Fri, 13 Oct 2000, Carlisle Adams wrote:

> Good question.  On the other hand, why would anyone expect to get security
> from a system that was not "well-behaved"?  If security is important to you,
> the onus is on you to choose (buy, implement, deploy, whatever) your PKI
> carefully...

I don't want a closed world. I want to interoperate. This leads me to
the next point you bring up, which is about cross certification. Sorry I
snipped all the text to make this note somewhat shorter.

You say that there WILL be name constraints on CAs and they will be placed
on the cross certificates.

So, that means that the CA's when they cross certify each other have to
make sure that their name constraints (if they have any at all) are
consistent with each other.

Without doing all the set theoretic mathematics, this tells me, that if
naming constraints exist, the permitted subtrees MUST be distinct to
comprise a unique DN space for the two of them together. Otherwise, name
collisions may already exist.

I cannot figure out if the permitted subtree specification only describes
one hop from each CA certificate, or for all certificates underneath.

There is no mandate in RFC2459, that the permitted subtrees and excluded
subtrees from that CA relate to the CA's certificate DN in any way. In
fact, its explicitly called out that constraint DOES NOT exist, referring
in contrast to the PEM stringent CA and DN hierarchy.

Page 12:

      (b)  Name constraints may be imposed through explicit inclusion of
      a name constraints extension in a certificate, but are not
      required.

Therefore, while cross certifying a CA, I must chase down all the CA's and
their permitted and excluded subtrees, in general. Also, I must check the
other CA as well to make sure, which is information I don't think I have
access to.

The only place I have seen anything that looks like it will work in this
regard is in the PEM specification RFC1422, where there is a ridged
subordinate subject DN creation scheme for CAs. That is, a CA named "C=US,
O=Adiron" must generate subject DN's with "C=US, O=Adiron" in them, i.e.
"C=US, O=Adiron, OU=Research", etc. (I don't know how unwieldy that can
get at, for example, 5 or six levels of CAs deep). There is supposed to be
an Email based registry, IPRA, to make sure that the PEM root certificates
contain distinct DN's.

That document makes special dispensation for cross-certificates, or
certificates out of the application of PEM. I haven't really thought about
that.

There is a obvious reason these stringent requirements exist for the PEM
application of PKI. It is that you need unique names over this application
space because applications other than X.509 certificates reference DNs for
their purposes, i.e. other than for validation.

And, that is the case with the AA. It references DNs. They really need to
be unique, but it seems that they are not guaranteed to be.

So, why isn't there a ridged structure placed on X.509 RootCA's that the
subject names should be subordinate to the issuer DN's? There is a
definition of superior and subordinate DNs, all roots have distinct DNs,
and then make special dispensation for Cross Certificates?

Also, when RFC2459 states in the Path Validation algorithm with respect to 
the constrained subtrees state variable:

      (b)  constrained subtrees:  A set of root names defining a set of
      subtrees within which all subject names in subsequent certificates
      in the certification path shall fall. The initial value is
      "unbounded".

And processing each CA certificate:

      (j)  If permittedSubtrees is present in the certificate, set the
      constrained subtrees state variable to the intersection of its
      previous value and the value indicated in the extension field.

What does the "intersection" mean? It is not explicitly defined.

Does it mean, just the intersection of the root names named in the
constrained subtrees by explicit equality? Or does it more involved? Say
for each TYPE (DN, DNS, email, etc)  of each name in the constrained
subtress, N, if N is "superior" to at least one P of the same TYPE in the
permitted Subtrees, then replace N with P in constrained subtrees,
otherwise drop N from the constrained subtrees. If this is the case, I
would imagine then also, that an absence of a name with the same type as N
would also constitue dropping N.

If this is the case, then name constraints on the CAs would do it, and
before two companies wanted to cross certify each other their Namespaces
would have to be distinct. However, I don't think that is the case. Is it?

Cheers,
-Polar





Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07014 for <[e-mail]>; Fri, 13 Oct 2000 14:45:57 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA16586; Fri, 13 Oct 2000 14:46:41 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <46FYYJVV>; Fri, 13 Oct 2000 14:50:05 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Michael Zolotarev <[e-mail]>, "'Frank Balluffi'" <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Fri, 13 Oct 2000 14:50:04 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I generally agree.  I'm doing all I can to advocate for a principle that
"simpler is better until compelling proven otherwise." However, it was a
criticism of 2560 that there exists more easily predictable error status
values than 2560 currently recognizes.  I propose that we take a look at
that, building on Frank's suggestions and perhaps those of others, but that
we do not create a sub-protocol for error cause discovery.

Mike

> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: Friday, October 13, 2000 8:19 AM
> To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Frank,
> 
> please, do not go this way. Keep it simple. 
> Realistically speaking, a client only needs a simple 'yes' or 
> 'now'. The
> whole purpose of defining a TTP for path validation was to 
> simplify things.
> 
> If a client is not satisfied by the 'yes' or 'now', there are 
> other options
> (other then been shot, of course). Mind you I fail undestand 
> why a client
> would ever ask 'why yes?' - would like to hear from you on this one,
> frankly. 
> 
> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.
> 
> Otherwise we'll end up with a hugely blown-up service, which 
> wasn't the
> purpose of the exercise.
> 
> M


Received: from catch22.concept5.com (catch22.concept5.com [207.123.142.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05152 for <[e-mail]>; Fri, 13 Oct 2000 13:03:53 -0700 (PDT)
Received: from absolute0.concept5.com (absolute0.concept5.com [207.123.142.20]) by catch22.concept5.com (8.9.1/8.9.0) with ESMTP id QAA08257; Fri, 13 Oct 2000 16:08:00 -0400 (EDT)
Received: from concept5.com (dhcp141201.concept5.com [207.123.141.201]) by absolute0.concept5.com (8.8.8+Sun/8.8.8) with ESMTP id QAA21702; Fri, 13 Oct 2000 16:07:59 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 16:09:14 -0400
From: John Marsh <[e-mail]>
Organization: Concept Five Technologies, Inc.
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: Carlisle Adams <[e-mail]>, Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------5DDD41D0EFE0702ACF2773E0"

This is a multi-part message in MIME format.
--------------5DDD41D0EFE0702ACF2773E0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar -
A modification to your suggestion of "one" -

I'd suggest world that looks more like the financial services world.  In the
financial services world, there's differentiation in what one has to do to get
varying levels of services and varying levels of universal acceptance.

Other than cash (which looks like no authentication unless the transaction gets very
high value), there's a couple levels of authentication & associated authorizations -

There's near universal acceptance of "certificates" from a very small number of
trusted "standard roots" - VISA, Discover, Mastercard, Diners, American Express.
Merchants handle cards from some subset of these (in the US - VISA & MC always, some
greater differentiation with AMEX & Discover, & Diners is much less accepted, but
exists essentially to be used by corporations to keep their employees from spending
money on anything that's not travel related.  In travel, it's fairly well
accepted.). There is some variation in both services to the card holder and
merchants, but as long as one of the "standard" cards is presented it's sufficient
up to the holder's credit limits.    Note that at this level, there are no
cross-certifications - there are individual "authorizations" but against universally
accepted certificates.

In addition, some merchants also offer their own "certificates" to the general
public - cards -  that are good at their place of business for special privileges
but are not intended for use at any other location (though they are some times
accepted for other purposes at other locations - e.g. Safeway stealing customers
from A&P by giving a discount to A&P card presenters).  Users aren't willing to hold
too many of these, but if it's a service that is highly valued to them, they will
allow them to show up in their wallet.

In the above cases, the level of potential damage on both sides for significant
breach is fairly low given the comparatively low dollar financial transactions
occuring.  At the same time, there's a relatively low level of authentication
evidence presented prior to receiving the card & there is typically a large number
of holders of the "certificate" type.

However, for very high valued services or internal users or representations for
purchase authority at other organizations - say for large purchases, purchases
dependent on acceptance, ... other arrangements end up getting created that may have
higher associated transaction costs, different levels of certification required,
stronger revocation list support, etc. It is also at this level that Carlisle's
cross-certifications really occur.

So the likely long term arrangements look like:

1)  No authentication required.
2)  Some small (always prime (-:) number of nearly univerally accepted root CAs
where no cross-certifications occur but where the acceptance risks are low.
3)  <this level may not exist in the long run> merchant's "own" CAs intended for the
general public.
4)  Specialized roots for much higher level of authentication when the transaction
involved is high risk and where cross-certifications may occur.

John

Polar Humenn wrote:

> My apologies,
>
> I missed stating a negative in a paragraph below.  Sorry!
>
> -Polar
>
> On Fri, 13 Oct 2000, Polar Humenn wrote:
>
> >
> > Carlisle,
> >
> > Thank you for your very learned and well formed response.
> >
> > You do draw an important conclusion that the AA and the Holder must belong
> > to the same "well-behaved" PKI in order for this scheme to work correctly.
> > (I wonder how many PKI's are actually really well-behaved? :).
> >
> > In any case, I do not see anywhere in the ac509 profile that specifies
> > that AA must belong to the same PKI (under the same rootCA?) as the
> > Holder's it authorizes? Can you point me to some text stating this
> > requirement, or some text that somehow implies this requirement?
> >
> > I also see this requirement to be a crippling constraint.
> >
> > The requirement for the AA and the Holder's it certificate to belong to the
> > same PKI means that I will be able to authorize certain subject entities
> > from HisCarCompany to have access to resources in MyCarCompany, unless I
> > do one of the following:
> ^^^^^^^^^^^^^^^^^^^^^^^^Scratch that  paragraph!^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The requirement that the AA and the Holders it certifies must belong to
> the same PKI means that I will NOT be able to authorize certain subject
> entities from HisCarCompany to have access to resources in MyCarCompany,
> unless I do one of the following:
>
> > 1. Create a new identity at MyCarCompany for subject entity X in
> >    HisCarCompany.
> >      This is undesirable for many reasons. For example,
> >      if Person X from HisCarCompany gets fired. Also, it to generate
> >      new keys, new certificates, new names, new password, new
> >      token card, etc. Now, causes a single-sign-on scenario.
> >
> > 2. Create an entirely new PKI for the interested parties and an AA.
> >      Out of the question for most. It's Way too much work with new keys,
> >      new names, new passwords, new tokens cards, etc.
> >
> > It would be nice if PKI and AA combined could solve the single-sign-on
> > problem.
> >
> > Of course, this problem would go away, if there is only one RootCA for all
> > organizations, and therefore on PKI. For example, HisCarCompany, and
> > MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> > And we and everybody that Verisign signs, must be well behaved, and the DN
> > space is consequently unique.
> >
> > Is this approach realistic and practical?
> >
> > Cheers,
> > -Polar
> >
> > On Fri, 13 Oct 2000, Carlisle Adams wrote:
> >
> > > Hi Polar,
> > >
> > > I think that as this thread has progressed we've all come to a better
> > > understanding of what you perceive the problem to be.  However, I suspect
> > > you may be missing an important foundational premise which so many of us
> > > take for granted that it may not be stated explicitly in the various
> > > standards documents.
> > >
> > > In PKI, a number of security implications rest upon the underlying trust
> > > model.  If I have a particular root CA (i.e., I received it's public-key
> > > out-of-band in a secure fashion, etc. -- all the usual conditions), then
> > > that root CA defines for me a PKI.  That is, it is the starting (or ending)
> > > point in my certificate path validation processing; any path that does not
> > > validly end up at this root is rejected by my software.  Therefore, this
> > > root CA defines for me a universe of PKI entities.  Such entities are
> > > identified in some way, perhaps by DN in the subject field, or by some other
> > > value(s) in subjectAltNames field, or by a combination of the two fields.
> > >
> > > Now if, for some reason (my deliberate choice, or as a result of the browser
> > > I downloaded, or whatever) I happen to have a second root CA, then this root
> > > CA defines for me a second PKI, another universe of entities.  Is it
> > > possible that a given entity could have an identity in each of these
> > > universes?  Of course.  But my path validation software will trace a path
> > > down to one root or the other, depending on which certificate it began with.
> > > Is it possible that two different entities could have (accidentally or
> > > maliciously) the same identity in each of these universes?  Again, of
> > > course.  But, again, my path validation software will trace a path down to
> > > one root or the other, depending on which certificate it began with.  The
> > > point is that these two universes of PKI entities are always distinguishable
> > > because they trace to one root or the other.  (Extend this to any number of
> > > roots with corresponding universes and this remains true.)
> > >
> > > Now, what about authorization via attribute certificates, which is where
> > > this thread began?  The AC may be bound to a PKI entity only through
> > > identity (DN, or issuer/serial), but this "identity" may appear in several
> > > different PKIs.  Your question is, "how can the AC verifier know which PKI
> > > was intended unless the AC issuer includes in the AC the full path of DNs
> > > (identities) all the way to the root?"  The answer is that this new
> > > extension is not at all necessary because this AC issuer (i.e., this AA)
> > > itself has an identity, and *its* issuer has an identity, all the way up to
> > > the SOA, which also has an identity.  All these identities must belong to
> > > the same universe, from the perspective of the relying party (the verifier),
> > > otherwise the AC is rejected.
> > >
> > > X.509 (2000) is fairly clear about the idea that AAs do not create
> > > identities; they rely upon the PKI to do this function and then simply point
> > > to those identities in the ACs they issue (see, for example, Section 13).
> > > Therefore, the AA must not simply have an awareness of the identities it can
> > > point to; it must itself be able to verify these identities in order to
> > > assign privileges to them.  In other words, the AA and the proposed AC
> > > holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> > > recursively all the way up the chain to the SOA and the first AA in the
> > > path.  Logically, this makes sense as well:  why would it be reasonable for
> > > an AA in one universe to be able to assign privileges to some entity in an
> > > arbitrary, different universe?  No, all entities involved must be part of
> > > the same PKI because the AA is only making use of the identities defined in
> > > the PKI of which it is a part and from which it has its own identity.
> > >
> > > The extension you propose would not hurt, but would not help either.  It
> > > would be a fairly sizable piece of extraneous, unnecessary information
> > > carried in each and every attribute certificate.
> > >
> > > Carlisle.
> > >
> > > P.S., It seems to me that thinking about this one-to-one mapping between
> > > root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> > > be name (identity) clashes between universes of entities, but this doesn't
> > > matter:  any certificate can be resolved to one and only one universe by
> > > following its path of signatures to the root.  Furthermore, it is easy to
> > > ensure that identity clashes will not be a concern within a single PKI:
> > > this is why name constraints were invented.  A root CA that does its job
> > > correctly will put name constraints in the certificates it issues to its
> > > subordinate CAs, and will put name constraints in the cross-certificates it
> > > issues to other CAs.  Any of these CAs can, of course, ignore these
> > > constraints and (again, accidentally or maliciously) create name clashes,
> > > but such certificates will not validate in proper path validation software
> > > and so are of no consequence.  Any environment for which secure
> > > authentication and authorization is important will use a root CA that
> > > imposes proper name constraints in order to eliminate the possibility of
> > > identity clashes within that PKI.  Clashes with entities in another PKI will
> > > not lead to faulty authentication or authorization decisions because all
> > > certificates being validated for a single purported entity must exist within
> > > the same universe.
> > >
> > > P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> > > that we should probably do this.  However, I kept all the copied lists and
> > > people on this response because I don't know how many of you currently
> > > subscribe to PKIX and I felt it was important to address the concern being
> > > raised so widely that name clashing was somehow a serious security problem
> > > for attribute certificates and for PKI more generally.  This is not the
> > > case, as I hope I have shown above.
> > >
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> >
>
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com

--------------5DDD41D0EFE0702ACF2773E0
Content-Type: text/x-vcard; charset=us-ascii;
 name="jmarsh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Marsh
Content-Disposition: attachment;
 filename="jmarsh.vcf"

begin:vcard 
n:Marsh;John
tel;cell:[phone]
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:www.concept5.com
org:Concept Five Technologies, Inc;Financial Services
version:2.1
email;internet:[e-mail]
title:Architect
adr;quoted-printable:;;1595 Spring Hill Rd, Suite 600=0D=0A;Vienna;VA;22182;USA
fn:John Marsh
end:vcard

--------------5DDD41D0EFE0702ACF2773E0--



Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04527 for <[e-mail]>; Fri, 13 Oct 2000 12:36:34 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.dc.adsl.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id PAA16038; Fri, 13 Oct 2000 15:40:26 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 15:37:12 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'Polar Humenn'" <[e-mail]>, Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

This should probably go in the roadmap too.

spt

Carlisle Adams wrote:

>
>
> Hi Polar,
>
>      ----------
>      From:   Polar Humenn[SMTP:[e-mail]]
>      Sent:   Friday, October 13, 2000 1:14 PM
>      To:     Carlisle Adams
>      Cc:     Stephen Farrell; [e-mail]; [e-mail];
>      [e-mail]; [e-mail]; Stephen McConnell; Kent Salmond;
>      Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
>
>      Subject:        RE: Comments on draft-ietf-pkix-ac509prof-05.txt
>
>      Carlisle,
>
>      Thank you for your very learned and well formed response.
>
>      You do draw an important conclusion that the AA and the Holder
>      must belong
>      to the same "well-behaved" PKI in order for this scheme to work
>      correctly.
>      (I wonder how many PKI's are actually really well-behaved? :).
>
>
> Good question.  On the other hand, why would anyone expect to get
> security from a system that was not "well-behaved"?  If security is
> important to you, the onus is on you to choose (buy, implement,
> deploy, whatever) your PKI carefully...
>
>      In any case, I do not see anywhere in the ac509 profile that
>      specifies
>      that AA must belong to the same PKI (under the same rootCA?) as
>      the
>      Holder's it authorizes? Can you point me to some text stating
>      this
>      requirement, or some text that somehow implies this requirement?
>



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04023 for <[e-mail]>; Fri, 13 Oct 2000 12:13:16 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <450KR1CJ>; Fri, 13 Oct 2000 15:17:30 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Polar Humenn'" <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 13 Oct 2000 15:17:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0354A.3AA5A480"

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_01C0354A.3AA5A480
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[e-mail]]
> Sent: 	Friday, October 13, 2000 1:14 PM
> To: 	Carlisle Adams
> Cc: 	Stephen Farrell; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Stephen McConnell; Kent Salmond; Ken Mccoy;
> Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Carlisle,
> 
> Thank you for your very learned and well formed response.
> 
> You do draw an important conclusion that the AA and the Holder must belong
> to the same "well-behaved" PKI in order for this scheme to work correctly.
> (I wonder how many PKI's are actually really well-behaved? :). 
 
Good question.  On the other hand, why would anyone expect to get security
from a system that was not "well-behaved"?  If security is important to you,
the onus is on you to choose (buy, implement, deploy, whatever) your PKI
carefully...

> In any case, I do not see anywhere in the ac509 profile that specifies
> that AA must belong to the same PKI (under the same rootCA?) as the
> Holder's it authorizes? Can you point me to some text stating this
> requirement, or some text that somehow implies this requirement?
 
Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly
through the profile document, so I can't comment on that one at the moment,
but this implication is definitely there in X.509 (2000).  As one example,
all through the sections on attribute certificates it talks about "the" PKI,
so it seems that the AC-based PMI is to be tied to only a single PKI.
Slightly more explicitly, however, Clause 16.1 ("Basic processing
procedure"), begins as follows:

	"The signature on every certificate in the path must be verified.
Procedures related to validating signatures and public-key certificates are
not repeated in this clause. The privilege verifier must verify the identity
of every entity in the path, using the procedures of clause 10. Note that
checking the signature on an attribute certificate necessarily involves
checking the referenced public-key certificate for its validity. Where
privileges are assigned using attribute certificates, path processing
engines will need to consider elements of both the PMI and the PKI in the
course of determining the ultimate validity of a privilege asserter's
attribute certificate."

ACs and PKCs are talked about "in the same breath" with respect to validity
checking and identity verification.  The referenced Clause 10
("Certification path processing procedure") lists the inputs to the
procedure in Section 10.1.  One of the inputs is "a trusted public key value
or key identifier (if the key is stored internally to the certification path
processing module), for use in verifying the first certificate in the
certification path".  This strongly implies to me that there is a single
trusted root key that forms the starting point for all the path processing
(which includes the AC path as well as the PKC path).

> I also see this requirement to be a crippling constraint.
> 
> The requirement for the AA and the Holder's it certificate to belong to
> the
> same PKI means that I will be able to authorize certain subject entities
> from HisCarCompany to have access to resources in MyCarCompany, unless I
> do one of the following:
> 
> 1. Create a new identity at MyCarCompany for subject entity X in 
>    HisCarCompany.
>      This is undesirable for many reasons. For example,
>      if Person X from HisCarCompany gets fired. Also, it to generate
>      new keys, new certificates, new names, new password, new
>      token card, etc. Now, causes a single-sign-on scenario.
>      
> 2. Create an entirely new PKI for the interested parties and an AA. 
>      Out of the question for most. It's Way too much work with new keys,
>      new names, new passwords, new tokens cards, etc.
 
This is not a crippling constraint because neither of the above undesirable
actions need to be taken.  If these two companies want to work together,
they need to issue cross-certificates between their root CAs anyway so that
authentication can take place.  Cross-certification ties these
previously-independent PKIs together, so that there is only a single PKI.
Appropriate name constraints in the cross-certificates ensure that identity
clashes will be ruled out of the picture, and authorization based upon
attribute certificates can proceed securely.

> It would be nice if PKI and AA combined could solve the single-sign-on
> problem.
 
If the companies follow what is outlined above, single sign-on is preserved.

> Of course, this problem would go away, if there is only one RootCA for all
> organzations, and therefore on PKI. For example, HisCarCompany, and
> MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> And we and everybody that Verisign signs, must be well behaved, and the DN
> space is consequently unique.
 
I'm sure you can imagine that Entrust and Baltimore and many other PKI
providers would not be content with the scenario you paint...  :-)

But seriously, people recognized a long time ago that a single root for the
whole world will not work.  This is why cross-certification was invented --
so that independently-deployed PKIs can be joined to form a single, workable
PKI.  This is why the term "PKI networking" is sometimes used instead of
"cross-certification" (it seems slightly more descriptive).

> Is this approach realistic and practical?
 
What I described above, I believe, has the qualities of both realism and
practicality.  Cross-certification is what allows you to grow your PKI to
include other environments, but in a very controlled and reasoned manner.
Attribute certificates take the power of this secure, yet flexible,
authentication technology and overlays the power of secure, yet flexible,
authorization.  It's a very strong combination!

Carlisle.


------_=_NextPart_001_01C0354A.3AA5A480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 13, 2000 1:14 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell; [e-mail]; [e-mail]; [e-mail]; =
[e-mail]; Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak =
Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you for your very learned and =
well formed response.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">You do draw an important conclusion =
that the AA and the Holder must belong</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to the same &quot;well-behaved&quot; =
PKI in order for this scheme to work correctly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(I wonder how many PKI's are actually =
really well-behaved? :). </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Good =
question.&nbsp; On the other hand, why would anyone expect to get =
security from a system that was not &quot;well-behaved&quot;?&nbsp; If =
security is important to you, the onus is on you to choose (buy, =
implement, deploy, whatever) your PKI carefully...</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In any case, I do not see anywhere in =
the ac509 profile that specifies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that AA must belong to the same PKI =
(under the same rootCA?) as the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Holder's it authorizes? Can you point =
me to some text stating this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requirement, or some text that =
somehow implies this requirement?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Ed =
Barkmeyer also asked for this.&nbsp; I haven't had a chance to skim =
quickly through the profile document, so I can't comment on that one at =
the moment, but this implication is definitely there in X.509 =
(2000).&nbsp; As one example, all through the sections on attribute =
certificates it talks about &quot;the&quot; PKI, so it seems that the =
AC-based PMI is to be tied to only a single PKI.&nbsp; Slightly more =
explicitly, however, Clause 16.1 (&quot;Basic processing =
procedure&quot;), begins as follows:</FONT></P>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"TIMES">&quot;The signature =
on every certificate in the path must be verified. Procedures related =
to validating signatures and public-key certificates are not repeated =
in this clause. The privilege verifier must verify the identity of =
every entity in the path, using the procedures of clause 10. Note that =
checking the signature on an attribute certificate necessarily involves =
checking the referenced public-key certificate for its validity. Where =
privileges are assigned using attribute certificates, path processing =
engines will need to consider elements of both the PMI and the PKI in =
the course of determining the ultimate validity of a privilege =
asserter's attribute certificate.&quot;</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">ACs and =
PKCs are talked about &quot;in the same breath&quot; with respect to =
validity checking and identity verification.&nbsp; The referenced =
Clause 10 (&quot;Certification path processing procedure&quot;) lists =
the inputs to the procedure in Section 10.1.&nbsp; One of the inputs is =
&quot;</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"TIMES">a trusted =
public key value or key identifier (if the key is stored internally to =
the certification path processing module), for use in verifying the =
first certificate in the certification path</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">&quot;.&nbsp; This =
strongly implies to me that there is a single trusted root key that =
forms the starting point for all the path processing (which includes =
the AC path as well as the PKC path).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I also see this requirement to be a =
crippling constraint.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The requirement for the AA and the =
Holder's it certificate to belong to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">same PKI means that I will be able to =
authorize certain subject entities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from HisCarCompany to have access to =
resources in MyCarCompany, unless I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">do one of the following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. Create a new identity at =
MyCarCompany for subject entity X in </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; HisCarCompany.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; This is =
undesirable for many reasons. For example,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; if Person X =
from HisCarCompany gets fired. Also, it to generate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; new keys, =
new certificates, new names, new password, new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; token card, =
etc. Now, causes a single-sign-on scenario.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2. Create an entirely new PKI for the =
interested parties and an AA. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Out of the =
question for most. It's Way too much work with new keys,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; new names, =
new passwords, new tokens cards, etc.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">This is =
not a crippling constraint because neither of the above undesirable =
actions need to be taken.&nbsp; If these two companies want to work =
together, they need to issue cross-certificates between their root CAs =
anyway so that authentication can take place.&nbsp; Cross-certification =
ties these previously-independent PKIs together, so that there is only =
a single PKI.&nbsp; Appropriate name constraints in the =
cross-certificates ensure that identity clashes will be ruled out of =
the picture, and authorization based upon attribute certificates can =
proceed securely.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">It would be nice if PKI and AA =
combined could solve the single-sign-on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problem.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If the =
companies follow what is outlined above, single sign-on is =
preserved.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Of course, this problem would go away, =
if there is only one RootCA for all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">organzations, and therefore on PKI. =
For example, HisCarCompany, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MyCarCompany must get our CA =
certificates signed by the Verisign RootCA.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">And we and everybody that Verisign =
signs, must be well behaved, and the DN</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">space is consequently unique.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm sure =
you can imagine that Entrust and Baltimore and many other PKI providers =
would not be content with the scenario you paint...&nbsp; =
:-)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">But =
seriously, people recognized a long time ago that a single root for the =
whole world will not work.&nbsp; This is why cross-certification was =
invented -- so that independently-deployed PKIs can be joined to form a =
single, workable PKI.&nbsp; This is why the term &quot;PKI =
networking&quot; is sometimes used instead of =
&quot;cross-certification&quot; (it seems slightly more =
descriptive).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Is this approach realistic and =
practical?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What I =
described above, I believe, has the qualities of both realism and =
practicality.&nbsp; Cross-certification is what allows you to grow your =
PKI to include other environments, but in a very controlled and =
reasoned manner.&nbsp; Attribute certificates take the power of this =
secure, yet flexible, authentication technology and overlays the power =
of secure, yet flexible, authorization.&nbsp; It's a very strong =
combination!</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0354A.3AA5A480--


Received: from dribble.cme.nist.gov (dribble.cme.nist.gov [129.6.32.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02455 for <[e-mail]>; Fri, 13 Oct 2000 10:58:06 -0700 (PDT)
Received: from nist.gov (polonius.msid.cme.nist.gov [129.6.77.120]) by dribble.cme.nist.gov (8.9.3/8.9.3) with ESMTP id OAA15015; Fri, 13 Oct 2000 14:02:27 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 14:02:46 -0400
From: Ed Barkmeyer <[e-mail]>
Reply-To: [e-mail]
Organization: NIST
X-Sender: "Ed Barkmeyer" <[e-mail]>
X-Mailer: Mozilla 4.51 [en]C-CCK-MCD   (WinNT; I)
X-Accept-Language: en,fr-FR,de-DE,nl,sv
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: Stephen Farrell <[e-mail]>, "'Polar Humenn'" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

Thanks for taking the trouble to copy your tutorial to us unwashed outliers who
happen to be on peripheral exploders (in my case, OMG ec).

One question:  Is the model you describe documented somewhere in the IETF or PKI
space?

(That is to say:  Before I read your tutorial, I never understood the "implicit
CA scoping rules", and while it may be common knowledge in the PKI standards
development community, it may not be common knowledge to the "new kid on the
block" who may be charged with implementing an AA.  And I can tell you from
experience that there are a lot of idiots like me who think they can read a
standard and understand it, whilst stupidly having failed to read an important
background document that defines the playing rules for the context in which that
standard was intended to be used.  In this case, I am exactly the kind of idiot
savant you needed to educate.  The tutorial was great, but what document should
I have read?  Next week's idiot will not have been on this collection of email
exploders.)

Thanks,
-Ed

P.S. Any OMG person will tell you that I am one of those people who took the
elementary school teacher's advice to heart:  "If you have a question, don't be
afraid to ask, because lots of people probably have the same question!"

-- 
Edward J. Barkmeyer                           Email: [e-mail]
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260              Tel: [phone]
Gaithersburg, MD 20899-8260                   FAX: [phone]


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01840 for <[e-mail]>; Fri, 13 Oct 2000 10:21:49 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id NAA01013; Fri, 13 Oct 2000 13:22:19 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 13 Oct 2000 13:22:19 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

My apologies,

I missed stating a negative in a paragraph below.  Sorry!

-Polar

On Fri, 13 Oct 2000, Polar Humenn wrote:

> 
> Carlisle,
> 
> Thank you for your very learned and well formed response.
> 
> You do draw an important conclusion that the AA and the Holder must belong
> to the same "well-behaved" PKI in order for this scheme to work correctly.
> (I wonder how many PKI's are actually really well-behaved? :). 
> 
> In any case, I do not see anywhere in the ac509 profile that specifies
> that AA must belong to the same PKI (under the same rootCA?) as the
> Holder's it authorizes? Can you point me to some text stating this
> requirement, or some text that somehow implies this requirement?
> 
> I also see this requirement to be a crippling constraint.
> 
> The requirement for the AA and the Holder's it certificate to belong to the
> same PKI means that I will be able to authorize certain subject entities
> from HisCarCompany to have access to resources in MyCarCompany, unless I
> do one of the following:
^^^^^^^^^^^^^^^^^^^^^^^^Scratch that  paragraph!^^^^^^^^^^^^^^^^^^^^^^^^^^^

The requirement that the AA and the Holders it certifies must belong to
the same PKI means that I will NOT be able to authorize certain subject
entities from HisCarCompany to have access to resources in MyCarCompany,
unless I do one of the following:

> 1. Create a new identity at MyCarCompany for subject entity X in 
>    HisCarCompany.
>      This is undesirable for many reasons. For example,
>      if Person X from HisCarCompany gets fired. Also, it to generate
>      new keys, new certificates, new names, new password, new
>      token card, etc. Now, causes a single-sign-on scenario.
>      
> 2. Create an entirely new PKI for the interested parties and an AA. 
>      Out of the question for most. It's Way too much work with new keys,
>      new names, new passwords, new tokens cards, etc.
> 
> It would be nice if PKI and AA combined could solve the single-sign-on
> problem.
> 
> Of course, this problem would go away, if there is only one RootCA for all
> organizations, and therefore on PKI. For example, HisCarCompany, and
> MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> And we and everybody that Verisign signs, must be well behaved, and the DN
> space is consequently unique.
> 
> Is this approach realistic and practical?
> 
> Cheers,
> -Polar
>  
> On Fri, 13 Oct 2000, Carlisle Adams wrote:
> 
> > Hi Polar,
> > 
> > I think that as this thread has progressed we've all come to a better
> > understanding of what you perceive the problem to be.  However, I suspect
> > you may be missing an important foundational premise which so many of us
> > take for granted that it may not be stated explicitly in the various
> > standards documents.
> > 
> > In PKI, a number of security implications rest upon the underlying trust
> > model.  If I have a particular root CA (i.e., I received it's public-key
> > out-of-band in a secure fashion, etc. -- all the usual conditions), then
> > that root CA defines for me a PKI.  That is, it is the starting (or ending)
> > point in my certificate path validation processing; any path that does not
> > validly end up at this root is rejected by my software.  Therefore, this
> > root CA defines for me a universe of PKI entities.  Such entities are
> > identified in some way, perhaps by DN in the subject field, or by some other
> > value(s) in subjectAltNames field, or by a combination of the two fields.
> > 
> > Now if, for some reason (my deliberate choice, or as a result of the browser
> > I downloaded, or whatever) I happen to have a second root CA, then this root
> > CA defines for me a second PKI, another universe of entities.  Is it
> > possible that a given entity could have an identity in each of these
> > universes?  Of course.  But my path validation software will trace a path
> > down to one root or the other, depending on which certificate it began with.
> > Is it possible that two different entities could have (accidentally or
> > maliciously) the same identity in each of these universes?  Again, of
> > course.  But, again, my path validation software will trace a path down to
> > one root or the other, depending on which certificate it began with.  The
> > point is that these two universes of PKI entities are always distinguishable
> > because they trace to one root or the other.  (Extend this to any number of
> > roots with corresponding universes and this remains true.)
> > 
> > Now, what about authorization via attribute certificates, which is where
> > this thread began?  The AC may be bound to a PKI entity only through
> > identity (DN, or issuer/serial), but this "identity" may appear in several
> > different PKIs.  Your question is, "how can the AC verifier know which PKI
> > was intended unless the AC issuer includes in the AC the full path of DNs
> > (identities) all the way to the root?"  The answer is that this new
> > extension is not at all necessary because this AC issuer (i.e., this AA)
> > itself has an identity, and *its* issuer has an identity, all the way up to
> > the SOA, which also has an identity.  All these identities must belong to
> > the same universe, from the perspective of the relying party (the verifier),
> > otherwise the AC is rejected.
> > 
> > X.509 (2000) is fairly clear about the idea that AAs do not create
> > identities; they rely upon the PKI to do this function and then simply point
> > to those identities in the ACs they issue (see, for example, Section 13).
> > Therefore, the AA must not simply have an awareness of the identities it can
> > point to; it must itself be able to verify these identities in order to
> > assign privileges to them.  In other words, the AA and the proposed AC
> > holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> > recursively all the way up the chain to the SOA and the first AA in the
> > path.  Logically, this makes sense as well:  why would it be reasonable for
> > an AA in one universe to be able to assign privileges to some entity in an
> > arbitrary, different universe?  No, all entities involved must be part of
> > the same PKI because the AA is only making use of the identities defined in
> > the PKI of which it is a part and from which it has its own identity.
> > 
> > The extension you propose would not hurt, but would not help either.  It
> > would be a fairly sizable piece of extraneous, unnecessary information
> > carried in each and every attribute certificate.
> > 
> > Carlisle.
> > 
> > P.S., It seems to me that thinking about this one-to-one mapping between
> > root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> > be name (identity) clashes between universes of entities, but this doesn't
> > matter:  any certificate can be resolved to one and only one universe by
> > following its path of signatures to the root.  Furthermore, it is easy to
> > ensure that identity clashes will not be a concern within a single PKI:
> > this is why name constraints were invented.  A root CA that does its job
> > correctly will put name constraints in the certificates it issues to its
> > subordinate CAs, and will put name constraints in the cross-certificates it
> > issues to other CAs.  Any of these CAs can, of course, ignore these
> > constraints and (again, accidentally or maliciously) create name clashes,
> > but such certificates will not validate in proper path validation software
> > and so are of no consequence.  Any environment for which secure
> > authentication and authorization is important will use a root CA that
> > imposes proper name constraints in order to eliminate the possibility of
> > identity clashes within that PKI.  Clashes with entities in another PKI will
> > not lead to faulty authentication or authorization decisions because all
> > certificates being validated for a single purported entity must exist within
> > the same universe.
> > 
> > P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> > that we should probably do this.  However, I kept all the copied lists and
> > people on this response because I don't know how many of you currently
> > subscribe to PKIX and I felt it was important to address the concern being
> > raised so widely that name clashing was somehow a serious security problem
> > for attribute certificates and for PKI more generally.  This is not the
> > case, as I hope I have shown above.
> > 
> > 
> 
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST      
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01476 for <[e-mail]>; Fri, 13 Oct 2000 10:13:47 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id NAA00975; Fri, 13 Oct 2000 13:14:12 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 13 Oct 2000 13:14:11 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: Stephen Farrell <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Carlisle,

Thank you for your very learned and well formed response.

You do draw an important conclusion that the AA and the Holder must belong
to the same "well-behaved" PKI in order for this scheme to work correctly.
(I wonder how many PKI's are actually really well-behaved? :). 

In any case, I do not see anywhere in the ac509 profile that specifies
that AA must belong to the same PKI (under the same rootCA?) as the
Holder's it authorizes? Can you point me to some text stating this
requirement, or some text that somehow implies this requirement?

I also see this requirement to be a crippling constraint.

The requirement for the AA and the Holder's it certificate to belong to the
same PKI means that I will be able to authorize certain subject entities
from HisCarCompany to have access to resources in MyCarCompany, unless I
do one of the following:

1. Create a new identity at MyCarCompany for subject entity X in 
   HisCarCompany.
     This is undesirable for many reasons. For example,
     if Person X from HisCarCompany gets fired. Also, it to generate
     new keys, new certificates, new names, new password, new
     token card, etc. Now, causes a single-sign-on scenario.
     
2. Create an entirely new PKI for the interested parties and an AA. 
     Out of the question for most. It's Way too much work with new keys,
     new names, new passwords, new tokens cards, etc.

It would be nice if PKI and AA combined could solve the single-sign-on
problem.

Of course, this problem would go away, if there is only one RootCA for all
organzations, and therefore on PKI. For example, HisCarCompany, and
MyCarCompany must get our CA certificates signed by the Verisign RootCA.
And we and everybody that Verisign signs, must be well behaved, and the DN
space is consequently unique.

Is this approach realistic and practical?

Cheers,
-Polar
 
On Fri, 13 Oct 2000, Carlisle Adams wrote:

> Hi Polar,
> 
> I think that as this thread has progressed we've all come to a better
> understanding of what you perceive the problem to be.  However, I suspect
> you may be missing an important foundational premise which so many of us
> take for granted that it may not be stated explicitly in the various
> standards documents.
> 
> In PKI, a number of security implications rest upon the underlying trust
> model.  If I have a particular root CA (i.e., I received it's public-key
> out-of-band in a secure fashion, etc. -- all the usual conditions), then
> that root CA defines for me a PKI.  That is, it is the starting (or ending)
> point in my certificate path validation processing; any path that does not
> validly end up at this root is rejected by my software.  Therefore, this
> root CA defines for me a universe of PKI entities.  Such entities are
> identified in some way, perhaps by DN in the subject field, or by some other
> value(s) in subjectAltNames field, or by a combination of the two fields.
> 
> Now if, for some reason (my deliberate choice, or as a result of the browser
> I downloaded, or whatever) I happen to have a second root CA, then this root
> CA defines for me a second PKI, another universe of entities.  Is it
> possible that a given entity could have an identity in each of these
> universes?  Of course.  But my path validation software will trace a path
> down to one root or the other, depending on which certificate it began with.
> Is it possible that two different entities could have (accidentally or
> maliciously) the same identity in each of these universes?  Again, of
> course.  But, again, my path validation software will trace a path down to
> one root or the other, depending on which certificate it began with.  The
> point is that these two universes of PKI entities are always distinguishable
> because they trace to one root or the other.  (Extend this to any number of
> roots with corresponding universes and this remains true.)
> 
> Now, what about authorization via attribute certificates, which is where
> this thread began?  The AC may be bound to a PKI entity only through
> identity (DN, or issuer/serial), but this "identity" may appear in several
> different PKIs.  Your question is, "how can the AC verifier know which PKI
> was intended unless the AC issuer includes in the AC the full path of DNs
> (identities) all the way to the root?"  The answer is that this new
> extension is not at all necessary because this AC issuer (i.e., this AA)
> itself has an identity, and *its* issuer has an identity, all the way up to
> the SOA, which also has an identity.  All these identities must belong to
> the same universe, from the perspective of the relying party (the verifier),
> otherwise the AC is rejected.
> 
> X.509 (2000) is fairly clear about the idea that AAs do not create
> identities; they rely upon the PKI to do this function and then simply point
> to those identities in the ACs they issue (see, for example, Section 13).
> Therefore, the AA must not simply have an awareness of the identities it can
> point to; it must itself be able to verify these identities in order to
> assign privileges to them.  In other words, the AA and the proposed AC
> holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> recursively all the way up the chain to the SOA and the first AA in the
> path.  Logically, this makes sense as well:  why would it be reasonable for
> an AA in one universe to be able to assign privileges to some entity in an
> arbitrary, different universe?  No, all entities involved must be part of
> the same PKI because the AA is only making use of the identities defined in
> the PKI of which it is a part and from which it has its own identity.
> 
> The extension you propose would not hurt, but would not help either.  It
> would be a fairly sizable piece of extraneous, unnecessary information
> carried in each and every attribute certificate.
> 
> Carlisle.
> 
> P.S., It seems to me that thinking about this one-to-one mapping between
> root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> be name (identity) clashes between universes of entities, but this doesn't
> matter:  any certificate can be resolved to one and only one universe by
> following its path of signatures to the root.  Furthermore, it is easy to
> ensure that identity clashes will not be a concern within a single PKI:
> this is why name constraints were invented.  A root CA that does its job
> correctly will put name constraints in the certificates it issues to its
> subordinate CAs, and will put name constraints in the cross-certificates it
> issues to other CAs.  Any of these CAs can, of course, ignore these
> constraints and (again, accidentally or maliciously) create name clashes,
> but such certificates will not validate in proper path validation software
> and so are of no consequence.  Any environment for which secure
> authentication and authorization is important will use a root CA that
> imposes proper name constraints in order to eliminate the possibility of
> identity clashes within that PKI.  Clashes with entities in another PKI will
> not lead to faulty authentication or authorization decisions because all
> certificates being validated for a single purported entity must exist within
> the same universe.
> 
> P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> that we should probably do this.  However, I kept all the copied lists and
> people on this response because I don't know how many of you currently
> subscribe to PKIX and I felt it was important to address the concern being
> raised so widely that name clashing was somehow a serious security problem
> for attribute certificates and for PKI more generally.  This is not the
> case, as I hope I have shown above.
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29327 for <[e-mail]>; Fri, 13 Oct 2000 09:40:45 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <T6Z8CJY3>; Fri, 13 Oct 2000 12:44:57 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Stephen Farrell <[e-mail]>, "'Polar Humenn'" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 13 Oct 2000 12:44:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03534.EAEF3290"

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_01C03534.EAEF3290
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Polar,

I think that as this thread has progressed we've all come to a better
understanding of what you perceive the problem to be.  However, I suspect
you may be missing an important foundational premise which so many of us
take for granted that it may not be stated explicitly in the various
standards documents.

In PKI, a number of security implications rest upon the underlying trust
model.  If I have a particular root CA (i.e., I received it's public-key
out-of-band in a secure fashion, etc. -- all the usual conditions), then
that root CA defines for me a PKI.  That is, it is the starting (or ending)
point in my certificate path validation processing; any path that does not
validly end up at this root is rejected by my software.  Therefore, this
root CA defines for me a universe of PKI entities.  Such entities are
identified in some way, perhaps by DN in the subject field, or by some other
value(s) in subjectAltNames field, or by a combination of the two fields.

Now if, for some reason (my deliberate choice, or as a result of the browser
I downloaded, or whatever) I happen to have a second root CA, then this root
CA defines for me a second PKI, another universe of entities.  Is it
possible that a given entity could have an identity in each of these
universes?  Of course.  But my path validation software will trace a path
down to one root or the other, depending on which certificate it began with.
Is it possible that two different entities could have (accidentally or
maliciously) the same identity in each of these universes?  Again, of
course.  But, again, my path validation software will trace a path down to
one root or the other, depending on which certificate it began with.  The
point is that these two universes of PKI entities are always distinguishable
because they trace to one root or the other.  (Extend this to any number of
roots with corresponding universes and this remains true.)

Now, what about authorization via attribute certificates, which is where
this thread began?  The AC may be bound to a PKI entity only through
identity (DN, or issuer/serial), but this "identity" may appear in several
different PKIs.  Your question is, "how can the AC verifier know which PKI
was intended unless the AC issuer includes in the AC the full path of DNs
(identities) all the way to the root?"  The answer is that this new
extension is not at all necessary because this AC issuer (i.e., this AA)
itself has an identity, and *its* issuer has an identity, all the way up to
the SOA, which also has an identity.  All these identities must belong to
the same universe, from the perspective of the relying party (the verifier),
otherwise the AC is rejected.

X.509 (2000) is fairly clear about the idea that AAs do not create
identities; they rely upon the PKI to do this function and then simply point
to those identities in the ACs they issue (see, for example, Section 13).
Therefore, the AA must not simply have an awareness of the identities it can
point to; it must itself be able to verify these identities in order to
assign privileges to them.  In other words, the AA and the proposed AC
holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
recursively all the way up the chain to the SOA and the first AA in the
path.  Logically, this makes sense as well:  why would it be reasonable for
an AA in one universe to be able to assign privileges to some entity in an
arbitrary, different universe?  No, all entities involved must be part of
the same PKI because the AA is only making use of the identities defined in
the PKI of which it is a part and from which it has its own identity.

The extension you propose would not hurt, but would not help either.  It
would be a fairly sizable piece of extraneous, unnecessary information
carried in each and every attribute certificate.

Carlisle.

P.S., It seems to me that thinking about this one-to-one mapping between
root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
be name (identity) clashes between universes of entities, but this doesn't
matter:  any certificate can be resolved to one and only one universe by
following its path of signatures to the root.  Furthermore, it is easy to
ensure that identity clashes will not be a concern within a single PKI:
this is why name constraints were invented.  A root CA that does its job
correctly will put name constraints in the certificates it issues to its
subordinate CAs, and will put name constraints in the cross-certificates it
issues to other CAs.  Any of these CAs can, of course, ignore these
constraints and (again, accidentally or maliciously) create name clashes,
but such certificates will not validate in proper path validation software
and so are of no consequence.  Any environment for which secure
authentication and authorization is important will use a root CA that
imposes proper name constraints in order to eliminate the possibility of
identity clashes within that PKI.  Clashes with entities in another PKI will
not lead to faulty authentication or authorization decisions because all
certificates being validated for a single purported entity must exist within
the same universe.

P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
that we should probably do this.  However, I kept all the copied lists and
people on this response because I don't know how many of you currently
subscribe to PKIX and I felt it was important to address the concern being
raised so widely that name clashing was somehow a serious security problem
for attribute certificates and for PKI more generally.  This is not the
case, as I hope I have shown above.


------_=_NextPart_001_01C03534.EAEF3290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I think =
that as this thread has progressed we've all come to a better =
understanding of what you perceive the problem to be.&nbsp; However, I =
suspect you may be missing an important foundational premise which so =
many of us take for granted that it may not be stated explicitly in the =
various standards documents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In PKI, a =
number of security implications rest upon the underlying trust =
model.&nbsp; If I have a particular root CA (i.e., I received it's =
public-key out-of-band in a secure fashion, etc. -- all the usual =
conditions), then that root CA defines for me a PKI.&nbsp; That is, it =
is the starting (or ending) point in my certificate path validation =
processing; any path that does not validly end up at this root is =
rejected by my software.&nbsp; Therefore, this root CA defines for me a =
universe of PKI entities.&nbsp; Such entities are identified in some =
way, perhaps by DN in the subject field, or by some other value(s) in =
subjectAltNames field, or by a combination of the two =
fields.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now if, =
for some reason (my deliberate choice, or as a result of the browser I =
downloaded, or whatever) I happen to have a second root CA, then this =
root CA defines for me a second PKI, another universe of =
entities.&nbsp; Is it possible that a given entity could have an =
identity in each of these universes?&nbsp; Of course.&nbsp; But my path =
validation software will trace a path down to one root or the other, =
depending on which certificate it began with.&nbsp; Is it possible that =
two different entities could have (accidentally or maliciously) the =
same identity in each of these universes?&nbsp; Again, of course.&nbsp; =
But, again, my path validation software will trace a path down to one =
root or the other, depending on which certificate it began with.&nbsp; =
The point is that these two universes of PKI entities are always =
distinguishable because they trace to one root or the other.&nbsp; =
(Extend this to any number of roots with corresponding universes and =
this remains true.)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now, what =
about authorization via attribute certificates, which is where this =
thread began?&nbsp; The AC may be bound to a PKI entity only through =
identity (DN, or issuer/serial), but this &quot;identity&quot; may =
appear in several different PKIs.&nbsp; Your question is, &quot;how can =
the AC verifier know which PKI was intended unless the AC issuer =
includes in the AC the full path of DNs (identities) all the way to the =
root?&quot;&nbsp; The answer is that this new extension is not at all =
necessary because this AC issuer (i.e., this AA) itself has an =
identity, and *its* issuer has an identity, all the way up to the SOA, =
which also has an identity.&nbsp; All these identities must belong to =
the same universe, from the perspective of the relying party (the =
verifier), otherwise the AC is rejected.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">X.509 =
(2000) is fairly clear about the idea that AAs do not create =
identities; they rely upon the PKI to do this function and then simply =
point to those identities in the ACs they issue (see, for example, =
Section 13).&nbsp; Therefore, the AA must not simply have an awareness =
of the identities it can point to; it must itself be able to verify =
these identities in order to assign privileges to them.&nbsp; In other =
words, the AA and the proposed AC holder MUST BELONG TO THE SAME =
PKI.&nbsp; This relationship must necessarily hold recursively all the =
way up the chain to the SOA and the first AA in the path.&nbsp; =
Logically, this makes sense as well:&nbsp; why would it be reasonable =
for an AA in one universe to be able to assign privileges to some =
entity in an arbitrary, different universe?&nbsp; No, all entities =
involved must be part of the same PKI because the AA is only making use =
of the identities defined in the PKI of which it is a part and from =
which it has its own identity.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
extension you propose would not hurt, but would not help either.&nbsp; =
It would be a fairly sizable piece of extraneous, unnecessary =
information carried in each and every attribute certificate.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">P.S., It =
seems to me that thinking about this one-to-one mapping between root =
CAs and PKIs alleviates all the name clashing concerns.&nbsp; Yes there =
can be name (identity) clashes between universes of entities, but this =
doesn't matter:&nbsp; any certificate can be resolved to one and only =
one universe by following its path of signatures to the root.&nbsp; =
Furthermore, it is easy to ensure that identity clashes will not be a =
concern within a single PKI:&nbsp; this is why name constraints were =
invented.&nbsp; A root CA that does its job correctly will put name =
constraints in the certificates it issues to its subordinate CAs, and =
will put name constraints in the cross-certificates it issues to other =
CAs.&nbsp; Any of these CAs can, of course, ignore these constraints =
and (again, accidentally or maliciously) create name clashes, but such =
certificates will not validate in proper path validation software and =
so are of no consequence.&nbsp; Any environment for which secure =
authentication and authorization is important will use a root CA that =
imposes proper name constraints in order to eliminate the possibility =
of identity clashes within that PKI.&nbsp; Clashes with entities in =
another PKI will not lead to faulty authentication or authorization =
decisions because all certificates being validated for a single =
purported entity must exist within the same universe.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">P.P.S., =
Stephen asked that we trim the Cc: list back to PKIX, and I agree that =
we should probably do this.&nbsp; However, I kept all the copied lists =
and people on this response because I don't know how many of you =
currently subscribe to PKIX and I felt it was important to address the =
concern being raised so widely that name clashing was somehow a serious =
security problem for attribute certificates and for PKI more =
generally.&nbsp; This is not the case, as I hope I have shown =
above.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C03534.EAEF3290--


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20684 for <[e-mail]>; Fri, 13 Oct 2000 07:32:44 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 13 Oct 2000 07:37:27 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 13 Oct 2000 07:37:26 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <4L3GHFVS>; Fri, 13 Oct 2000 07:35:15 -0700
Content-return: allowed
Date: Fri, 13 Oct 2000 07:35:06 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[e-mail]>, Frank Balluffi <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Michael,

I strongly agree with your desire to keep it simple. Unfortunately, I am
learning as I go and do not know all of the answers to how this stuff will
be used. For example, I recently learned that there are many certificates in
the real world that do pass RFC 2459, section 6.1 (e.g., illegal criticality
flags, improper policy identifier values, etc.). I have no idea how the
world will choose to deal with these certificates. Also, what is a client?
An end-user device (e.g., an internet-enabled phone)? A gateway? Perhaps a
gateway will want more detailed information than an end-user device. I don't
know. As long as we can find a simple way to deal with complexity, I am
happy (e.g., by just saying no).

Frank

> -----Original Message-----
> From: Michael Zolotarev [mailto:[e-mail]]
> Sent: Friday, October 13, 2000 11:19 AM
> To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Frank,
> 
> please, do not go this way. Keep it simple. 
> Realistically speaking, a client only needs a simple 'yes' or 
> 'now'. The
> whole purpose of defining a TTP for path validation was to 
> simplify things.
> 
> If a client is not satisfied by the 'yes' or 'now', there are 
> other options
> (other then been shot, of course). Mind you I fail undestand 
> why a client
> would ever ask 'why yes?' - would like to hear from you on this one,
> frankly. 
> 
> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.
> 
> Otherwise we'll end up with a hugely blown-up service, which 
> wasn't the
> purpose of the exercise.
> 
> M
> 
> 
> -----Original Message-----
> From: Frank Balluffi [mailto:[e-mail]]
> Sent: Saturday, October 14, 2000 12:04 AM
> To: 'Michael Zolotarev'; Michael Myers; [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael Zolotarev wrote:
> 
> > However, my original question was what does the server do if 
> > both Policy and
> > Trust components aren't there. I'd assume that the server has 
> > two options:
> > 1. Check revocation status and then apply some 'default' 
> > implicit policy and
> > trust points. This would be an option for a pre-configured (i.e.
> > enterprise-wide) responder.
> > 2. Check revocation status and then discard the request on 
> > the basis that
> > there is no 'implicit' verification context which the server 
> > can apply (at
> > all, or for that particular certificate). In this case the 
> > error code can be
> > either 'invalid', if the cert is revoked, or 'unknown', 
> > indicating that the
> > cert is not revoked, but validation couldn't be executed due 
> > to lack of
> > input conditions.
> 
> Considering that validating a path includes more steps than 
> checking the
> revocation status of each certificate (in the path), and that 
> at least one
> of these steps should not "check out" under normal operations 
> (or at least
> until there are no adversaries), I expect that clients will 
> want to know why
> a path was not valid, and possibly why a path was valid. For example:
> 
> 1. the server did not possess the necessary information to 
> validate each
> certificate
> 2. the server applied some default policy
> 3. a certificate's basic information (e.g., its signature, 
> validity period,
> revocation status or subject name) did not "check out" (i.e., 
> adhere to RFC
> 2459, section 6.1)
> 4. a certificate extension did not "check out"
> 
> RFC 2560 addresses some failure paths (e.g., malformed 
> request, internal
> error). So my answer to your question is that the protocol needs to:
> 
> a. provide a mechanism for the server to return detailed 
> information about
> why the server deemed the path valid or not valid (e.g., it 
> applied some
> default policy, it encountered a "bad" extension, etc.)
> b. define a set of cases and each's expected behavior
> 
> Frank
> 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20154 for <[e-mail]>; Fri, 13 Oct 2000 07:16:25 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id AAA00760; Sat, 14 Oct 2000 00:27:51 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LKTX>; Sat, 14 Oct 2000 01:19:08 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: "'Frank Balluffi'" <[e-mail]>, Michael Zolotarev <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Sat, 14 Oct 2000 01:19:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Frank,

please, do not go this way. Keep it simple. 
Realistically speaking, a client only needs a simple 'yes' or 'now'. The
whole purpose of defining a TTP for path validation was to simplify things.

If a client is not satisfied by the 'yes' or 'now', there are other options
(other then been shot, of course). Mind you I fail undestand why a client
would ever ask 'why yes?' - would like to hear from you on this one,
frankly. 

To find out why 'No', a client can use DPD to get the path, and then ask DPV
for each component in the path.

Otherwise we'll end up with a hugely blown-up service, which wasn't the
purpose of the exercise.

M


-----Original Message-----
From: Frank Balluffi [mailto:[e-mail]]
Sent: Saturday, October 14, 2000 12:04 AM
To: 'Michael Zolotarev'; Michael Myers; [e-mail]
Subject: RE: Delegated Path Validation draft.


Michael Zolotarev wrote:

> However, my original question was what does the server do if 
> both Policy and
> Trust components aren't there. I'd assume that the server has 
> two options:
> 1. Check revocation status and then apply some 'default' 
> implicit policy and
> trust points. This would be an option for a pre-configured (i.e.
> enterprise-wide) responder.
> 2. Check revocation status and then discard the request on 
> the basis that
> there is no 'implicit' verification context which the server 
> can apply (at
> all, or for that particular certificate). In this case the 
> error code can be
> either 'invalid', if the cert is revoked, or 'unknown', 
> indicating that the
> cert is not revoked, but validation couldn't be executed due 
> to lack of
> input conditions.

Considering that validating a path includes more steps than checking the
revocation status of each certificate (in the path), and that at least one
of these steps should not "check out" under normal operations (or at least
until there are no adversaries), I expect that clients will want to know why
a path was not valid, and possibly why a path was valid. For example:

1. the server did not possess the necessary information to validate each
certificate
2. the server applied some default policy
3. a certificate's basic information (e.g., its signature, validity period,
revocation status or subject name) did not "check out" (i.e., adhere to RFC
2459, section 6.1)
4. a certificate extension did not "check out"

RFC 2560 addresses some failure paths (e.g., malformed request, internal
error). So my answer to your question is that the protocol needs to:

a. provide a mechanism for the server to return detailed information about
why the server deemed the path valid or not valid (e.g., it applied some
default policy, it encountered a "bad" extension, etc.)
b. define a set of cases and each's expected behavior

Frank


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19596 for <[e-mail]>; Fri, 13 Oct 2000 07:01:58 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 13 Oct 2000 07:06:36 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 13 Oct 2000 07:06:36 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <4L3GHFS0>; Fri, 13 Oct 2000 07:04:24 -0700
Content-return: allowed
Date: Fri, 13 Oct 2000 07:04:16 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Michael Zolotarev wrote:

> However, my original question was what does the server do if 
> both Policy and
> Trust components aren't there. I'd assume that the server has 
> two options:
> 1. Check revocation status and then apply some 'default' 
> implicit policy and
> trust points. This would be an option for a pre-configured (i.e.
> enterprise-wide) responder.
> 2. Check revocation status and then discard the request on 
> the basis that
> there is no 'implicit' verification context which the server 
> can apply (at
> all, or for that particular certificate). In this case the 
> error code can be
> either 'invalid', if the cert is revoked, or 'unknown', 
> indicating that the
> cert is not revoked, but validation couldn't be executed due 
> to lack of
> input conditions.

Considering that validating a path includes more steps than checking the
revocation status of each certificate (in the path), and that at least one
of these steps should not "check out" under normal operations (or at least
until there are no adversaries), I expect that clients will want to know why
a path was not valid, and possibly why a path was valid. For example:

1. the server did not possess the necessary information to validate each
certificate
2. the server applied some default policy
3. a certificate's basic information (e.g., its signature, validity period,
revocation status or subject name) did not "check out" (i.e., adhere to RFC
2459, section 6.1)
4. a certificate extension did not "check out"

RFC 2560 addresses some failure paths (e.g., malformed request, internal
error). So my answer to your question is that the protocol needs to:

a. provide a mechanism for the server to return detailed information about
why the server deemed the path valid or not valid (e.g., it applied some
default policy, it encountered a "bad" extension, etc.)
b. define a set of cases and each's expected behavior

Frank


Received: from ns.koscom.co.kr (ns.koscom.co.kr [128.134.148.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16927 for <[e-mail]>; Fri, 13 Oct 2000 05:13:12 -0700 (PDT)
Received: from LocalHost ([128.134.151.26]) by ns.koscom.co.kr (8.9.1/8.9.1) with SMTP id VAA00876 for <[e-mail]>; Fri, 13 Oct 2000 21:14:14 +0900 (KST)
Message-ID: <002f01c0350f$9c4a9910$1a978680@LocalHost>
Reply-To: =?UTF-8?B?6rmA7ISx642V?= <[e-mail]>
From: =?UTF-8?B?6rmA7ISx642V?= <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: id-smime-ct-TSTInfo
Date: Fri, 13 Oct 2000 21:17:48 +0900
Organization: =?UTF-8?B?7KCE7J6Q7J247Kad7IKs7JeF67aA?=
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id FAA16928

I think that  id-smime-ct-TSTInfo in Appendix D of new TSP draft should be replaced by id-ct-TSTInfo .

TSP version 10
2.4.2 Response Format
id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

 Appendix D 
TimeStampToken ::= ContentInfo
     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo 
     -- eContent within SignedData is TSTInfo

-- eContentType for a time stamping token

id-smime-ct-TSTInfo  OBJECT IDENTIFIER ::= { id-smime-ct 4 }
id-smime-ct          OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime             OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13983 for <[e-mail]>; Fri, 13 Oct 2000 03:57:51 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA22952 for <[e-mail]>; Fri, 13 Oct 2000 13:07:54 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA14582 for <[e-mail]>; Fri, 13 Oct 2000 13:02:00 +0200
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 13:02:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: TSP. Version 10
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A new version of the Time Stamping Protocol has been placed on the web
server. A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt

This version addresses the comments received during the IESG last call
period.

Besides the changes made to accommodate the 24 comments raised by Russ
Housley, the abstract and the introduction have been modified, by myself and
Steve Kent, in order to address some of the concerns raised by Todd Glassey.

If there are no major editorial errors, this version should (hopefully) be
the version to be published as an RFC. Should there be a few minor errors
left, please tell me, since they can still be corrected directly by myself
when the RFC editor transforms the document into an RFC (there a 48 hours
time window to do so).

FYI, the abstract and the introduction are now as follows:

Abstract

A time stamping service allows to prove that a datum existed before 
a particular time. This document describes the format of a request 
sent to a Time Stamping Authority (TSA) and of the response that is 
returned. It also establishes several security-relevant requirements 
for TSA operation, with regards to processing requests to generate 
responses. A TSA may be operated as a Trusted Third Party (TTP) 
service, though other operational models may be appropriate, e.g. an 
organization might require a TSA for internal time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

(...)

1.  Introduction

(...)

This standard does not establish overall security requirements for 
TSA operation, just like other PKIX standards do not establish such 
requirements for CA operation. Rather, it is anticipated that a TSA 
will make know to prospective clients the policies it implements to 
ensure accurate time stamp generation, and clients will make use of 
the services of a TSA only if they are satisfied that these policies 
meet their needs.


Denis


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12697 for <[e-mail]>; Fri, 13 Oct 2000 03:29:39 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02174; Fri, 13 Oct 2000 06:34:22 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-10.txt
Date: Fri, 13 Oct 2000 06:34:21 -0400
Sender: [e-mail]

--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 
                          Time Stamp Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-10.txt
	Pages		: 24
	Date		: 12-Oct-00
	
A time stamping service allows to prove that a datum existed before 
a particular time. This document describes the format of a request 
sent to a Time Stamping Authority (TSA) and of the response that is 
returned. It also establishes several security-relevant requirements 
for TSA operation, with regards to processing requests to generate 
responses. A TSA may be operated as a Trusted Third Party (TTP) 
service, though other operational models may be appropriate, e.g. an 
organization might require a TSA for internal time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt

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-time-stamp-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-10.txt

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

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

--OtherAccess--

--NextPart--




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12063 for <[e-mail]>; Fri, 13 Oct 2000 03:17:45 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA17561; Fri, 13 Oct 2000 12:22:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 13 Oct 2000 12:22:27 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA01295; Fri, 13 Oct 2000 12:22:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA00687; Fri, 13 Oct 2000 12:22:26 +0200 (MET DST)
Date: Fri, 13 Oct 2000 12:22:26 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Experimental TSA

> 
> Therefore it's more constructive to see if there's a way to work around these problems, and
> what should be the best way for that, than to simply complain.
> 

I may have been misunderstood, the first part of your statement is the
exact purpose of this discussion of early experiemnts. First, it
helps to identify certain problems, then we can find a way to 
handle this in whatever way. 

As I said, the problem is not in the server: In any case, at least
one message and answer get through. It may be a problem for a client,
if the client first wait for the connection to end before treating
a response, or client must not assume that the connection will
be closed by the server. That's all what I think needs to be 
understood.  






Received: from logatome.francenet.fr (logatome-2.francenet.fr [193.149.96.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09008 for <[e-mail]>; Fri, 13 Oct 2000 02:54:42 -0700 (PDT)
Received: from certplus.com ([193.149.118.138]) by logatome.francenet.fr (8.10.1/8.10.1) with ESMTP id e9D9xOn54202 for <[e-mail]>; Fri, 13 Oct 2000 11:59:24 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 12:00:46 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pkix <[e-mail]>
Subject: Re: Experimental TSA
References: <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>   Section 5 of the [RFC2510] spec specifies sending the DER-encoded
>   CMP message directly over various protocols. However, implementors,
>   during various interoperability workshops, found the protocol
>   lacking in the following respects:
>
>   1.    No clear definition on when the connection is to be closed
>         and by whom.
>   2.    No version number specified to allow for extensions.

You can define new values for the request flag, etc...
But it's not very sure how the server that doesn't understand it, will react (close the
connection, send an error message with flag 6 and leave the connection open, etc...)

>   3.    Error messages cannot be processed by applications.

Answer with flag value "6" is an error message.
The error message can be also in the status.

>   At least we have the SAME situation as in 1. here in this discussion.

About the same. A separate RFC for that would be better of course.

> > The client just has to check if the connexion is still open before sending the second
> > message.
> This is normal error handling.

That's my point.

Most of the "problems" that occurs in that case are things that _could_ also happen if the
protocol did define whether there will be several messages or not.

The only actual difference is that the server has to wait a time-out interval after sending
the answer, so some ressources are used a little more than necessary.
Under normal circumstances , I think this time-out interval could be something around 10 or
20 seconds.
I don't believe this is the performance bottle-neck of the server, if it's properly
configured with a large number of sockets.

I'm not saying the protocol is perfect.

I just think that from the previous discussion it is clear there will be no major chance in
the draft anymore.

Therefore it's more constructive to see if there's a way to work around these problems, and
what should be the best way for that, than to simply complain.



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29533 for <[e-mail]>; Fri, 13 Oct 2000 01:03:39 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA29214; Fri, 13 Oct 2000 10:13:36 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA14488; Fri, 13 Oct 2000 10:07:25 +0200
Message-ID: <[e-mail]>
Date: Fri, 13 Oct 2000 10:07:27 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: The future of DVCS...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

My comments are along the lines.

> Hi Denis,
 
 (...some text deleted...)

>> I agree that more clearly-defined subsets of the DVCS functionality
>> should be handled by these other protocols (TSP, OCSP, etc.) .. 
>> but this also means that this subset is not the right direction for 
>> the long run and thus should be deprecated. For that reason, this 
>> subset should *not* be placed in an experimental RFC.

> Actually, this is a very good reason why this subset *should* be placed in
> an Experimental RFC.  

Sorry, I do not see any argument for supporting your assertion.

> These other protocols, which differ in some details
> with what is in DVCS, go on to become standards, whereas our early
> "experimental" work on this same functionality is archived as something
> that was tried but not standardized.

(text deleted) 
 
> Actually, this again *is* a good argument for saving this material in an
> Experimental RFC.  DVCS represents something that was conceived,
> discussed, and implemented, but all in quite limited circles.  When it
> comes time to discuss this sort of topic more broadly, this early
> "experimental" work can perhaps serve as a reasonable starting point for
> that discussion.

(text deleted)
 
> Within the IETF environment, what alternatives are there for preserving
> this work?  As you well know, the only archival documents in IETF are
> RFCs, so if we all agree that DVCS is not appropriate for the standards
> track at this time, we are left with Experimental, Informational,
> Historic, and Best Current Practice.  The description for Experimental is
> given in RFC 2026 as follows:
> 
>    The "Experimental" designation typically denotes a specification that
>    is part of some research or development effort.  Such a specification
>    is published for the general information of the Internet technical
>    community and as an archival record of the work, subject only to
>    editorial considerations and to verification that there has been
>    adequate coordination with the standards process (see below).  An
>    Experimental specification may be the output of an organized Internet
>    research effort (e.g., a Research Group of the IRTF), an IETF Working
>    Group, or it may be an individual contribution.
> 
> DVCS was certainly the result of some early research work centering on the
> possible uses of a notarization-type server, and did undergo some limited
> development (i.e., implementation) effort.  It may be useful as a source
> of information on this topic to at least the Internet technical community,
> if not the broader Internet community.  It makes sense to have an archival
> record of this work, especially if this topic may arise again in the
> future.  I see pretty-much an exact fit between DVCS and the stated
> purpose of the Experimental RFC category.

Let me provide a copy of the text in the next following section of RFC 2026:

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.  The IESG shall review such a referred document
   within a reasonable period of time, and recommend either that it be
   published as originally submitted or referred to the IETF as a
   contribution to the Internet Standards Process.

   If (a) the IESG recommends that the document be brought within the
   IETF and progressed within the IETF context, but the author declines
   to do so, or (b) the IESG considers that the document proposes
   something that conflicts with, or is actually inimical to, an
   established IETF effort, the document may still be published as an
   Experimental or Informational RFC.  In these cases, however, the IESG
   may insert appropriate "disclaimer" text into the RFC either in or
   immediately following the "Status of this Memo" section in order to
   make the circumstances of its publication clear to readers.

   Documents proposed for Experimental and Informational RFCs by IETF
   Working Groups go through IESG review.  The review is initiated using
   the process described in section 6.1.1.

So the first question is whether this document is proposed for Experimental
and Informational RFCs by some individuals or by the PKIX Working Groups. I
am not supportive of presenting this document as a PKIX WG proposal.

The next point, as far as I understand, is that in any case it will go
through IESG review. Should the document be proposed as an Experimental RFC,
the concerns I have might then be brought to the attention of the IESG.

> Perhaps, however, you are suggested that this document should be preserved
> outside the IETF process.  This can certainly be done, but I must confess
> to having a hard time seeing what value that would serve to the Internet
> community.

All drafts which are submitted do not need to become RFCs (even Experimental
or Informational). There are numerous examples for this. Since it is very
likely that some of the authors of DVCS are going to remain present in the
PKIX working group, parts of this document might be brought up, when
necessary, by one of the authors and alternatively by someone else who saved
the document. Once again, preserving the document does not mandate the
issuance of an Experimental RFC.

> (...substantial and valuable comments deleted for the sake of brevity...)
> 
> Thank you once again for your careful consideration of this document and
> for your thoughtful input.  

:-)

> I skimmed quickly through Peter's responses
> and am in agreement with what I saw there.  But ultimately the question is
> this:  "Is it worth revising this document further, given that it is not
> targeted for the standards track?"  Why don't we simply freeze it as-is
> and call it a day.  I suspect we all have other things we could be working
> on...

I agree we have other things todo. However, pushing the document to
Experimental RFC would *not* save our time. :-)

Denis

> Carlisle.


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA24618 for <[e-mail]>; Thu, 12 Oct 2000 20:59:46 -0700 (PDT)
From: [e-mail]
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 06721163; Fri, 13 Oct 2000 00:04:09 -0400 (EDT)
Received: (from rsalz@localhost) by os390.caveosystems.com (8.9.3/8.9.3) id AAA27129; Fri, 13 Oct 2000 00:08:29 -0400
Date: Fri, 13 Oct 2000 00:08:29 -0400
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Delegated Path Validation draft.
X-Loop-Detect: 1

I'm a bit removed from OCSP details these days.  Can an OCSP repsonder
indicate which extensions in the request it didn't like?

Even if this is not possible, I see no reason to remove the CRITICALITY
feature.  A client can always resend without that bit if it decides
the semantics are optional after all.


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20402 for <[e-mail]>; Thu, 12 Oct 2000 16:51:29 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA25406 for <[e-mail]>; Fri, 13 Oct 2000 10:55:38 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0y08jo; Fri Oct 13 09:55:01 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id KAA21673 for <[e-mail]>; Fri, 13 Oct 2000 10:55:00 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0yT31_; Fri Oct 13 09:54:37 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA20306 for <[e-mail]>; Fri, 13 Oct 2000 10:54:37 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <4ZAMMCQ7>; Fri, 13 Oct 2000 10:54:05 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: pkix <[e-mail]>
Subject: RE: AttributeCertificates: Why is the holder DN preferred?
Date: Fri, 13 Oct 2000 10:53:57 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I support making the change.

The separation of names between the 'subject' and 'subjectAltName' fields is
for historical reasons.  These two fields should not be distinguished for
future processing - i.e. together they provide the certificate holder's
names.


----------
From: Stephen Farrell [mailto:[e-mail]]

. if there were consensus that they were important then I'd be ok 
with changing the draft to allow AC.holder.entityName to be compared against

either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it.

PS: If we made the change, I wouldn't agree to distinguish some types of alt
name
from others (e.g. disallowing ip-address as you suggested), but would treat
all 
equally since that's what the CA put in the PKC.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20192 for <[e-mail]>; Thu, 12 Oct 2000 16:49:05 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA19980; Fri, 13 Oct 2000 10:00:15 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LKDK>; Fri, 13 Oct 2000 10:51:53 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Michael Myers <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Fri, 13 Oct 2000 10:51:47 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Friday, 13 October 2000 6:48
> To: Michael Zolotarev; [e-mail]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael,
> 
> Regarding the criticality flag, in fact I'd rather change 
> 2560's current
> "Support for any specific extension is OPTIONAL. The critical 
> flag SHOULD
> NOT be set for any of them." to SHALL NOT set the criticality flag.  I
> believe this will improve interoperability and reduce 
> confusion with no loss
> of security assurances.  Are there are any criticality flag 
> advocates out
> there who would wish to argue a contrary position?
> 

In my opinion the extentions defined for DPV (and DPD as a matter of fact)
must be marked as critical. The client adds those extensions as an indicator
of the type of service it expects. Leaving those extension non-critical
would be just wrong, equivalent to say "the client wants DPV (not basic
OCSP), but the responder may ingore it". It obviously defeats the purpose.


> I propose to clarify the "omit both fields" requirement to 
> read "If neither
> initialPolicySet nor trustPoints are included in the request, 
> the DPVOptions
> structure SHALL be encoded as an SEQUENCE of zero length 
> (that is, an empty
> sequence)."
> 

Agree.

> And I will give some thought to the instance when a relying 
> party includes
> both initialPolicySet and trustPoints.  In fact, we had 
> talked at length
> about these kind of combinatorics in blocking out the draft, 
> but I wanted
> first to get a sounding from the WG on the overall approach 
> before drilling
> down too deeply.  Minimally, we need an "invalid" response value in
> BasicOCSPResponse to distinguish the case when a certificate 
> isn't revoked
> but fails to validate against OCSP request extension content.
> 

I agree. The client asks the question "Can this cert be validated given that
policy and trust critirea, provided that the cert is NOT 
revoked". Therefore, if any of the conditions fail, the response must be
'invalid'.


However, my original question was what does the server do if both Policy and
Trust components aren't there. I'd assume that the server has two options:
1. Check revocation status and then apply some 'default' implicit policy and
trust points. This would be an option for a pre-configured (i.e.
enterprise-wide) responder.
2. Check revocation status and then discard the request on the basis that
there is no 'implicit' verification context which the server can apply (at
all, or for that particular certificate). In this case the error code can be
either 'invalid', if the cert is revoked, or 'unknown', indicating that the
cert is not revoked, but validation couldn't be executed due to lack of
input conditions.

Michael
> 


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19344 for <[e-mail]>; Thu, 12 Oct 2000 16:09:31 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id TAA32368; Thu, 12 Oct 2000 19:09:47 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 12 Oct 2000 19:09:46 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Stephen Farrell <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Stephen,

Comments below:

On Thu, 12 Oct 2000, Stephen Farrell wrote:

> 
> Polar,
> 
> Since you choose to quote from that off-list mail, let me complete the
> quote somewhat:
> 
> You wrote:
> 
> > > Help me out here. This one I don't understand? How can another path exist?
> > > The PKIXPROF mandates that the Issuer field of a PKC MUST match a subject
> > > field of the certificate containing the public key that verifies it. That
> > > really mandates just one path up to the RootCA for the holder's identity.
> > > How can a different path exist?
> 
> And I responded:
>  
> > CA1 certifies holder.
> > CA2 certifies CA1.
> > AA trusts CA2 as a "root"
> > CA3 also certifies CA1.
> > RP trusts CA3 as a "root"
> > 
> > Both [CA2,CA2],[CA2,CA1],[CA1,holder] and [CA3,CA3],[CA3,CA1],[CA1,holder]
> > are potentially valid paths, where [x,y] means "x certifies y". Based on their 
> > respective configurations the first path is usable by the AA, the second by 
> > the RP.

Yes, and thank you for clearing up my confusion. And from your response, I
should note, that I concluded the problem was worse than I had originally
imagined. :)

> The bottom line seems to be that you have a different concept of "identity" 
> to that which has been understood in PKIX for the last five years. Your 
> concept of "identity" is the entire sequence of DNs from the end-entity 
> PKC subject field, up to a "root" CA, including all CA names in between. 
> PKIX treats the end entity PKC subject field by itself as an identity

Which means that the DN MUST be globally unique? Is the fact that a single
DN is just NOT empahtiacally guaranteed to point to a unique subject
entity just specifically avoided in arguments for the sake of
functionality, which in this case is *security functionality*?

> (and no, I don't want to start another of those interesting discussions
> about whether this is good or bad!).

Right. We should not be concerned about about the integrity of such an
infrastructure. We should just use what is given to us, whether it is good
or bad. ;^)

And I guess, why not? I have a machine (of which I only use when forced
to) on my desk with an operating system made by a popular software company
that just can't get out of its own way and stop crashing, getting
diseases, etc. I have to use it sometimes because everybody else uses the
same thing and sends me stuff only it can understand. Oh well. I should
just accept this. Okay. It's a market. It's a standard. :)

> I can only guess that this is ultimately why you perceive there to be such 
> a problem, where others don't. 

Your "guess" is correct! At least you recognize my problem with the entire
thing.

What I would like is an answer to the verifiability problem all the way up
the identity chain of the Holder. The PKIXPROF tells you how to verify a
PKC chain. Why does it even bother walking up a chain? All PKIX identities
and public keys should be signed by Verisign and be done with it. :^)

But seriously, the AC draft says nothing other than that when using the
baseCertificateID it must match that of the components of the
authenticated entity's certificate. It's just not enough in the cases of
PKC chains greater than 2. Even the an Issuer UID can be forged in the
holder's PKC along with the DN and the serial number, especially if I am
allowed to have two CA's certify the same certificate as you have pointed
out above.

I don't mind if a single certificate subject field points to one and only
one unique subject entity.  But I cannot ignore, skip, or gloss over the
fact that the DN is just NOT unique in the PKIX space.

I do like Tom's suggestion of being able to use the subjectAltName in
places where uniqueness is a factor, ignoring the subject DN. The problem
is being able to force vendors of AAs to use it. In some cases, where
authentication services are provided by widely disparate CA services and
vendors, mandating such things from AA service vendors may be impossible.

> So, can we leave it there and agree to disagree as to what constitutes
> an "identity"? (I'd *much* rather that than to have to parse & respond 
> to all of your "treatise":-)

Okay. Okay. I wrote something you won't read? I'm defenseless against that
approach.

I just have to tell my customers they can't use such standards and
standard products (at least not without proprietary extensions) and they
will have to use something else for widely scaled e-commerce solutions in
the PKI space.

I guess there is a market for a workable, but inadequate, solution now
with really expensive upgrades later on that fix the problems, albeit
after the attacks, or the screw ups.

"How come I can't get my pizza?" 
"I'm sorry Mr. Smith, you already picked it up!"

> Stephen.
> 
> PS: Can we also drop the huge cc list if there are any more mails on 
> this topic? The AC profile is a PKIX draft - whoever is interested can
> discuss it there.

Surely, now that you've seen my point and my problem with it, let's take
it back to PKIX and the OMG lists. The CC list is for the people I know
are interested and aren't on the lists. I took the iesg off the list.
Hopefully, the concerned parties there are subscribed to the pkix list.

Cheers,
-Polar

> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com






Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18521 for <[e-mail]>; Thu, 12 Oct 2000 15:21:35 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA198420; Thu, 12 Oct 2000 18:25:45 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id SAA68644; Thu, 12 Oct 2000 18:25:51 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256976.007B34AD ; Thu, 12 Oct 2000 18:25:44 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: Russ Housley <[e-mail]>, pkix <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 18:25:48 -0400
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA18522

     The reason I think that using SubjectAltName might sometimes be
preferred is related to Polar's concern about the adequacy of identities.
IMHO, both e-mail addresses and permanent identifiers are less likely to
have identity conflicts than DN's, while IP addresses and DNS names are
usually adequate identifiers only for devices.  There is also little reason
to prefer a secondary directoryName or x400Name to a subject DN.  I would
not be sure where to put ediPartyName, registeredID, or URI in such an
ordering - the last two are pretty immune from naming conflicts but they
don't usually indicate individuals.
     Using SubjectAltName fields would allow an AA to specify a user by
e-mail address or by PI and let that user use any of his PKC's with that
AC.  The only potential drawback I see is whether that allows an attacker
to get a PKC with a false value in that field from a legitimate CA, but I
hope that if there are others they will be pointed out.
     If this suggestion comes too late in the cycle, so be it.

          Tom Gindin


Stephen Farrell <[e-mail]> on 10/12/2000 05:33:25 PM

Please respond to [e-mail]

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[e-mail]>, pkix <[e-mail]>, xme
      <[e-mail]>
Subject:  Re: AttributeCertificates: Why is the holder DN preferred?




Tom,

Sorry, I misinterpreted your mail a bit (being mixed up with figuring out
how
many identities could dance on the subject field of a certificate:-).
You're right
in what you said below, but I think its ok anyway on the following basis:

If a PKC is used to authenticate the holder to the relying party, and that
PKC
contains a non-null subject field, and the AA chose to put the entityName
in on
the basis of that PKC, then there's no reason not to just stick with
AC.holder.entityName being compared to PKC.subject.

I guess the (now explicit) assumption in there is that the same PKC (well
at least
the same PKC.subject value) is the basis on which the AA issued the AC and
is also
used for holder to relying party authentication - in which case the subject
field
is available to both, so why not just use it?

I suppose a circumstance where this wouldn't hold would be e.g. where the
holder
uses Keberos to authenticate to the AA, which then produces an AC
containing
the holder's KerberosName in AC.holder.entityName.OTHER-NAME and where the
holder
then uses her PKC to authenticate to the relying party when using the
AC, and where the KerberosName is in PKC.subjectAltName.OTHER-NAME, but
PKC.subject is not empty. I hadn't really considered such "mixed"
authentication
schemes, but if there were consensus that they were important then I'd be
ok
with changing the draft to allow AC.holder.entityName to be compared
against
either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it. If its not
important
enough right now (which is what I think) then we're ok as is (Russ?).

Stephen

PS: If we made the change, I wouldn't agree to distinguish some types of
alt name
from others (e.g. disallowing ip-address as you suggested), but would treat
all
equally since that's what the CA put in the PKC.

[e-mail] wrote:
>
>      I am not misquoting the draft in any important way.  The third
> paragraph (excluding the note) of section 4.2.2 of your current draft
> begins as follows: "If the holder field uses the entityName option and
the
> underlying authentication is based on a PKC, then the entityName MUST be
> the same as the PKC subject field, unless the PKC subject field contains
an
> empty distinguished name. If the PKC subject field contains an empty
> distinguished name, then the entityName field MUST be identical to one of
> the values of the PKC subjectAltName field extension."  This forbids the
> use of a value from subjectAltName, whether e-mail or PI, as an
entityName
> if the subject DN is present.  The preference for baseCertificateID makes
> the issue somewhat less important, but does not eliminate it.
>      As for PI's (whose draft is -01 rather than -00), I cited them as
one
> of two reasonable global identifiers for a user in SubjectAltName.  I
> understand that you would not want to hold up this draft for that one,
but
> I'm looking for re-wording of this statement to allow SubjectAltName
> components including e-mail, but excluding IP address, DNS name, and
> probably some others.  It might be appropriate to state that the use of
> "OTHER-NAME components specifying the identity of the subject as an
> individual" may be supported as well.
>
>           Tom Gindin
>
> Stephen Farrell <[e-mail]> on 10/12/2000 05:30:30 AM
>
> Please respond to [e-mail]
>
> To:   Tom Gindin/Watson/IBM@IBMUS
> cc:   Russ Housley <[e-mail]>, pkix <[e-mail]>
> Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
>
> Tom,
>
> I think you're misquoting the draft. basdCertificateID is the SHOULD for
> holder
> when PKCs are used for authentiation. When entityName is used, the text
> tells
> you how it should compare to the subject and/or subjectAltName from the
> PKC. It
> does not say that the PKC must use any particular form of subject naming.
>
> There is no reference to PI since right now that's a -00 draft with who
> know
> what future (bright, I'm sure:-) and the AC profile is in IETF wide last
> call.
>
> Stephen.
>
> [e-mail] wrote:
> >
> >      Russ:
> >
> >      On one subject which is connected to what Polar brought up, I am
> > inclined to think that he is right.  In the AC509Prof draft, section
> 4.2.2
> > states that for PKC-based authentication the entityName MUST be the
same
> as
> > the PKC subject field unless that field is empty.  Why should it be
> > mandatory to prefer the subject DN to either permanent ID's or e-mail
> > addresses, both of which identify individuals in a globally unique way?
> > Name collisions are more likely in the DN space than in either of the
> other
> > two, except for PI's with a default assignment authority, and PI's of
> that
> > sort should be forbidden as entityName's.  This does not imply that
most
> of
> > the options within GeneralName are appropriate as entityName's, as I
> don't
> > think they are.
> >
> >           Tom Gindin
> >
> > Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM
> >
> > To:   Polar Humenn <[e-mail]>
> > cc:   Al Arsenault <[e-mail]>, Stephen Farrell
> >       <[e-mail]>, Patrik Fältström <[e-mail]>,
> >       [e-mail], [e-mail], Thumrongsak Kosiyatrakul
> >       <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
> >       Older <[e-mail]>
> > Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets
> >       andProxies
> >
> > Polar:
> >
> > > > Okay, I think I finally figured out what Polar is getting at here,
> but
> > > > I'm not sure what the fix is.  Let me try to illustrate with an
> > example.
> > > >
> > > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > > intended; apologies for any offense.  :-)
> > > >
> > > > Suppose that there's a legitimate root CA with DN "C=IE,
O=Baltimore
> > > > Technologies, OU=Public CAs, CN=The CA".
> > > > That CA has a self signed certificate with subject and issuer both
> > equal
> > > > to the DN above.
> > > >
> > > > Now, there is an end-user certificate issued under that CA.  The
> issuer
> > > > field of that certificate will be the DN above; the subject field
is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > > CN=Stephen".
> > > >
> > > > The serial number field will be something like "4434".
> > > >
> > > > Now, an attribute authority has issued our friend Stephen an AC
> > > > consistent with the proposed profile.  The "Holder" field in that
AC
> > can
> > > > be one of three things, according to the proposed profile:
> > > >
> > > >       - it can be the issuer and serial number of the base PKC;
that
> is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > > >
> > > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > > >
> > > >       - it can be an ObjectDigest - for which the I-D does not
> require
> > > > support.
> > >
> > >I think the ObjectDigest is truly the only way to go. However, it
still
> > >has problems. The object that is talked about must be able to be
> recalled
> > >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> > >delivered with the Holder's Public Key Certificate.
> > >
> > >I don't believe that requiring the delivery of the Holders certificate
> is
> > >unreasonable. Can something like this be mandated in this profile? I
> don't
> > >see how. I only see that in specific protocols. Or am I wrong?
> >
> > PKCs bind a public key to an identity.
> >
> > ACs bind attributes to an identity.
> >
> > Authentication, which includes validating the PKC certification path
and
> > having the remote party perform some operation that involves the
private
> > key associated with the identity.  Without authentication of the
> identity,
> > who cares what attributes are associated with it?
> >
> > Russ
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com





Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17399 for <[e-mail]>; Thu, 12 Oct 2000 14:29:49 -0700 (PDT)
Received: by balinese.baltimore.ie; id WAA15137; Thu, 12 Oct 2000 22:34:24 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma015126; Thu, 12 Oct 00 22:33:28 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA26460; Thu, 12 Oct 2000 22:34:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 22:33:25 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>, xme <[e-mail]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id WAA26460
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA17403

Tom,

Sorry, I misinterpreted your mail a bit (being mixed up with figuring out how 
many identities could dance on the subject field of a certificate:-). You're right 
in what you said below, but I think its ok anyway on the following basis:

If a PKC is used to authenticate the holder to the relying party, and that PKC 
contains a non-null subject field, and the AA chose to put the entityName in on 
the basis of that PKC, then there's no reason not to just stick with 
AC.holder.entityName being compared to PKC.subject.

I guess the (now explicit) assumption in there is that the same PKC (well at least
the same PKC.subject value) is the basis on which the AA issued the AC and is also
used for holder to relying party authentication - in which case the subject field 
is available to both, so why not just use it? 

I suppose a circumstance where this wouldn't hold would be e.g. where the holder
uses Keberos to authenticate to the AA, which then produces an AC containing 
the holder's KerberosName in AC.holder.entityName.OTHER-NAME and where the holder
then uses her PKC to authenticate to the relying party when using the
AC, and where the KerberosName is in PKC.subjectAltName.OTHER-NAME, but 
PKC.subject is not empty. I hadn't really considered such "mixed" authentication 
schemes, but if there were consensus that they were important then I'd be ok 
with changing the draft to allow AC.holder.entityName to be compared against 
either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it. If its not important 
enough right now (which is what I think) then we're ok as is (Russ?).

Stephen

PS: If we made the change, I wouldn't agree to distinguish some types of alt name
from others (e.g. disallowing ip-address as you suggested), but would treat all 
equally since that's what the CA put in the PKC.

[e-mail] wrote:
> 
>      I am not misquoting the draft in any important way.  The third
> paragraph (excluding the note) of section 4.2.2 of your current draft
> begins as follows: "If the holder field uses the entityName option and the
> underlying authentication is based on a PKC, then the entityName MUST be
> the same as the PKC subject field, unless the PKC subject field contains an
> empty distinguished name. If the PKC subject field contains an empty
> distinguished name, then the entityName field MUST be identical to one of
> the values of the PKC subjectAltName field extension."  This forbids the
> use of a value from subjectAltName, whether e-mail or PI, as an entityName
> if the subject DN is present.  The preference for baseCertificateID makes
> the issue somewhat less important, but does not eliminate it.
>      As for PI's (whose draft is -01 rather than -00), I cited them as one
> of two reasonable global identifiers for a user in SubjectAltName.  I
> understand that you would not want to hold up this draft for that one, but
> I'm looking for re-wording of this statement to allow SubjectAltName
> components including e-mail, but excluding IP address, DNS name, and
> probably some others.  It might be appropriate to state that the use of
> "OTHER-NAME components specifying the identity of the subject as an
> individual" may be supported as well.
> 
>           Tom Gindin
> 
> Stephen Farrell <[e-mail]> on 10/12/2000 05:30:30 AM
> 
> Please respond to [e-mail]
> 
> To:   Tom Gindin/Watson/IBM@IBMUS
> cc:   Russ Housley <[e-mail]>, pkix <[e-mail]>
> Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
> 
> Tom,
> 
> I think you're misquoting the draft. basdCertificateID is the SHOULD for
> holder
> when PKCs are used for authentiation. When entityName is used, the text
> tells
> you how it should compare to the subject and/or subjectAltName from the
> PKC. It
> does not say that the PKC must use any particular form of subject naming.
> 
> There is no reference to PI since right now that's a -00 draft with who
> know
> what future (bright, I'm sure:-) and the AC profile is in IETF wide last
> call.
> 
> Stephen.
> 
> [e-mail] wrote:
> >
> >      Russ:
> >
> >      On one subject which is connected to what Polar brought up, I am
> > inclined to think that he is right.  In the AC509Prof draft, section
> 4.2.2
> > states that for PKC-based authentication the entityName MUST be the same
> as
> > the PKC subject field unless that field is empty.  Why should it be
> > mandatory to prefer the subject DN to either permanent ID's or e-mail
> > addresses, both of which identify individuals in a globally unique way?
> > Name collisions are more likely in the DN space than in either of the
> other
> > two, except for PI's with a default assignment authority, and PI's of
> that
> > sort should be forbidden as entityName's.  This does not imply that most
> of
> > the options within GeneralName are appropriate as entityName's, as I
> don't
> > think they are.
> >
> >           Tom Gindin
> >
> > Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM
> >
> > To:   Polar Humenn <[e-mail]>
> > cc:   Al Arsenault <[e-mail]>, Stephen Farrell
> >       <[e-mail]>, Patrik Fältström <[e-mail]>,
> >       [e-mail], [e-mail], Thumrongsak Kosiyatrakul
> >       <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
> >       Older <[e-mail]>
> > Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets
> >       andProxies
> >
> > Polar:
> >
> > > > Okay, I think I finally figured out what Polar is getting at here,
> but
> > > > I'm not sure what the fix is.  Let me try to illustrate with an
> > example.
> > > >
> > > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > > intended; apologies for any offense.  :-)
> > > >
> > > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > > Technologies, OU=Public CAs, CN=The CA".
> > > > That CA has a self signed certificate with subject and issuer both
> > equal
> > > > to the DN above.
> > > >
> > > > Now, there is an end-user certificate issued under that CA.  The
> issuer
> > > > field of that certificate will be the DN above; the subject field is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > > CN=Stephen".
> > > >
> > > > The serial number field will be something like "4434".
> > > >
> > > > Now, an attribute authority has issued our friend Stephen an AC
> > > > consistent with the proposed profile.  The "Holder" field in that AC
> > can
> > > > be one of three things, according to the proposed profile:
> > > >
> > > >       - it can be the issuer and serial number of the base PKC; that
> is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > > >
> > > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > > >
> > > >       - it can be an ObjectDigest - for which the I-D does not
> require
> > > > support.
> > >
> > >I think the ObjectDigest is truly the only way to go. However, it still
> > >has problems. The object that is talked about must be able to be
> recalled
> > >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> > >delivered with the Holder's Public Key Certificate.
> > >
> > >I don't believe that requiring the delivery of the Holders certificate
> is
> > >unreasonable. Can something like this be mandated in this profile? I
> don't
> > >see how. I only see that in specific protocols. Or am I wrong?
> >
> > PKCs bind a public key to an identity.
> >
> > ACs bind attributes to an identity.
> >
> > Authentication, which includes validating the PKC certification path and
> > having the remote party perform some operation that involves the private
> > key associated with the identity.  Without authentication of the
> identity,
> > who cares what attributes are associated with it?
> >
> > Russ
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16692 for <[e-mail]>; Thu, 12 Oct 2000 14:08:44 -0700 (PDT)
Received: by balinese.baltimore.ie; id WAA14769; Thu, 12 Oct 2000 22:13:20 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma014746; Thu, 12 Oct 00 22:12:44 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA26133; Thu, 12 Oct 2000 22:13:41 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 22:12:32 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, John Propper <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>, xme <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar,

Since you choose to quote from that off-list mail, let me complete the
quote somewhat:

You wrote:

> > Help me out here. This one I don't understand? How can another path exist?
> > The PKIXPROF mandates that the Issuer field of a PKC MUST match a subject
> > field of the certificate containing the public key that verifies it. That
> > really mandates just one path up to the RootCA for the holder's identity.
> > How can a different path exist?

And I responded:
 
> CA1 certifies holder.
> CA2 certifies CA1.
> AA trusts CA2 as a "root"
> CA3 also certifies CA1.
> RP trusts CA3 as a "root"
> 
> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and [CA3,CA3],[CA3,CA1],[CA1,holder]
> are potentially valid paths, where [x,y] means "x certifies y". Based on their 
> respective configurations the first path is usable by the AA, the second by 
> the RP.

The bottom line seems to be that you have a different concept of "identity" 
to that which has been understood in PKIX for the last five years. Your 
concept of "identity" is the entire sequence of DNs from the end-entity 
PKC subject field, up to a "root" CA, including all CA names in between. 
PKIX treats the end entity PKC subject field by itself as an identity
(and no, I don't want to start another of those interesting discussions
about whether this is good or bad!).

I can only guess that this is ultimately why you percieve there to be such 
a problem, where others don't. 

So, can we leave it there and agree to disagree as to what consitutes
an "identity"? (I'd *much* rather that than to have to parse & respond 
to all of your "treatise":-)

Stephen.

PS: Can we also drop the huge cc list if there are any more mails on 
this topic? The AC profile is a PKIX draft - whoever's interested can
discuss it there.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15757 for <[e-mail]>; Thu, 12 Oct 2000 13:43:42 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA05094; Thu, 12 Oct 2000 13:44:22 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <4GKKZSTM>; Thu, 12 Oct 2000 13:47:46 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Michael Zolotarev <[e-mail]>, [e-mail]
Subject: RE: Delegated Path Validation draft.
Date: Thu, 12 Oct 2000 13:47:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Michael,

Regarding the criticality flag, in fact I'd rather change 2560's current
"Support for any specific extension is OPTIONAL. The critical flag SHOULD
NOT be set for any of them." to SHALL NOT set the criticality flag.  I
believe this will improve interoperability and reduce confusion with no loss
of security assurances.  Are there are any criticality flag advocates out
there who would wish to argue a contrary position?

I propose to clarify the "omit both fields" requirement to read "If neither
initialPolicySet nor trustPoints are included in the request, the DPVOptions
structure SHALL be encoded as an SEQUENCE of zero length (that is, an empty
sequence)."

And I will give some thought to the instance when a relying party includes
both initialPolicySet and trustPoints.  In fact, we had talked at length
about these kind of combinatorics in blocking out the draft, but I wanted
first to get a sounding from the WG on the overall approach before drilling
down too deeply.  Minimally, we need an "invalid" response value in
BasicOCSPResponse to distinguish the case when a certificate isn't revoked
but fails to validate against OCSP request extension content.

Mike


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14473 for <[e-mail]>; Thu, 12 Oct 2000 13:12:03 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA26389; Thu, 12 Oct 2000 16:16:37 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 12 Oct 2000 16:14:57 -0400
To: "pkix" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: FYI: SHA-2, AES
In-Reply-To: <009701c0348f$986509a0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

FYI,

NIST has just posted a white paper that specifies hashing algorithms 
(SHA-256, SHA-384, and SHA-512) that are intended to provide security 
similar to that of the three AES key sizes. Information can be found at 
<http://www.nist.gov/sha/>.

These algorithms "will be proposed in a draft Federal Information 
Processing Standard (FIPS) in 2001. These algorithms are being made 
available for information purposes prior to the publication of the draft 
FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 
bits of security against collision attacks, and SHA-512 is a 512-bit hash 
function that is intended to provide 256 bits of security. A 384-bit hash 
may be obtained by truncating the SHA-512 output."

The web site has the NIST contact points.

One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains 
the object identifiers and ASN.1 type definitions for AES parameters for 
protocols built on ASN.1.  The OIDs for the new hash algorithms will follow 
next week.

Thanks,

Tim Polk


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13917 for <[e-mail]>; Thu, 12 Oct 2000 12:58:26 -0700 (PDT)
Received: from mega (t5o69p66.telia.com [213.64.110.66]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id WAA12786; Thu, 12 Oct 2000 22:02:42 +0200 (CEST)
Message-ID: <009701c0348f$986509a0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
Date: Thu, 12 Oct 2000 23:01:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA13919

Tom,
I think you addressed  a somewhat bigger issue:
The relationship between Subject DN and SubjectAltName.
I.e. where should the poor RP look for identity information?
Unfortunately PIs and the PKIX-recommended place to put e-mail addresses
makes this even mory fuzzy.

/Anders

-----Original Message-----
From: [e-mail] <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: Russ Housley <[e-mail]>; pkix <[e-mail]>
Date: Thursday, October 12, 2000 20:31
Subject: Re: AttributeCertificates: Why is the holder DN preferred?


>     I am not misquoting the draft in any important way.  The third
>paragraph (excluding the note) of section 4.2.2 of your current draft
>begins as follows: "If the holder field uses the entityName option and the
>underlying authentication is based on a PKC, then the entityName MUST be
>the same as the PKC subject field, unless the PKC subject field contains an
>empty distinguished name. If the PKC subject field contains an empty
>distinguished name, then the entityName field MUST be identical to one of
>the values of the PKC subjectAltName field extension."  This forbids the
>use of a value from subjectAltName, whether e-mail or PI, as an entityName
>if the subject DN is present.  The preference for baseCertificateID makes
>the issue somewhat less important, but does not eliminate it.
>     As for PI's (whose draft is -01 rather than -00), I cited them as one
>of two reasonable global identifiers for a user in SubjectAltName.  I
>understand that you would not want to hold up this draft for that one, but
>I'm looking for re-wording of this statement to allow SubjectAltName
>components including e-mail, but excluding IP address, DNS name, and
>probably some others.  It might be appropriate to state that the use of
>"OTHER-NAME components specifying the identity of the subject as an
>individual" may be supported as well.
>
>          Tom Gindin
>
>Stephen Farrell <[e-mail]> on 10/12/2000 05:30:30 AM
>
>Please respond to [e-mail]
>
>To:   Tom Gindin/Watson/IBM@IBMUS
>cc:   Russ Housley <[e-mail]>, pkix <[e-mail]>
>Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
>
>
>
>
>Tom,
>
>I think you're misquoting the draft. basdCertificateID is the SHOULD for
>holder
>when PKCs are used for authentiation. When entityName is used, the text
>tells
>you how it should compare to the subject and/or subjectAltName from the
>PKC. It
>does not say that the PKC must use any particular form of subject naming.
>
>There is no reference to PI since right now that's a -00 draft with who
>know
>what future (bright, I'm sure:-) and the AC profile is in IETF wide last
>call.
>
>Stephen.
>
>[e-mail] wrote:
>>
>>      Russ:
>>
>>      On one subject which is connected to what Polar brought up, I am
>> inclined to think that he is right.  In the AC509Prof draft, section
>4.2.2
>> states that for PKC-based authentication the entityName MUST be the same
>as
>> the PKC subject field unless that field is empty.  Why should it be
>> mandatory to prefer the subject DN to either permanent ID's or e-mail
>> addresses, both of which identify individuals in a globally unique way?
>> Name collisions are more likely in the DN space than in either of the
>other
>> two, except for PI's with a default assignment authority, and PI's of
>that
>> sort should be forbidden as entityName's.  This does not imply that most
>of
>> the options within GeneralName are appropriate as entityName's, as I
>don't
>> think they are.
>>
>>           Tom Gindin
>>
>> Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM
>>
>> To:   Polar Humenn <[e-mail]>
>> cc:   Al Arsenault <[e-mail]>, Stephen Farrell
>>       <[e-mail]>, Patrik Fältström <[e-mail]>,
>>       [e-mail], [e-mail], Thumrongsak Kosiyatrakul
>>       <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
>>       Older <[e-mail]>
>> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
>Targets
>>       andProxies
>>
>> Polar:
>>
>> > > Okay, I think I finally figured out what Polar is getting at here,
>but
>> > > I'm not sure what the fix is.  Let me try to illustrate with an
>> example.
>> > >
>> > > (We'll be picking on Stephen a little bit in this; nothing personal
>> > > intended; apologies for any offense.  :-)
>> > >
>> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
>> > > Technologies, OU=Public CAs, CN=The CA".
>> > > That CA has a self signed certificate with subject and issuer both
>> equal
>> > > to the DN above.
>> > >
>> > > Now, there is an end-user certificate issued under that CA.  The
>issuer
>> > > field of that certificate will be the DN above; the subject field is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
>> > > CN=Stephen".
>> > >
>> > > The serial number field will be something like "4434".
>> > >
>> > > Now, an attribute authority has issued our friend Stephen an AC
>> > > consistent with the proposed profile.  The "Holder" field in that AC
>> can
>> > > be one of three things, according to the proposed profile:
>> > >
>> > >       - it can be the issuer and serial number of the base PKC; that
>is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
>> > >
>> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
>> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
>> > >
>> > >       - it can be an ObjectDigest - for which the I-D does not
>require
>> > > support.
>> >
>> >I think the ObjectDigest is truly the only way to go. However, it still
>> >has problems. The object that is talked about must be able to be
>recalled
>> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>> >delivered with the Holder's Public Key Certificate.
>> >
>> >I don't believe that requiring the delivery of the Holders certificate
>is
>> >unreasonable. Can something like this be mandated in this profile? I
>don't
>> >see how. I only see that in specific protocols. Or am I wrong?
>>
>> PKCs bind a public key to an identity.
>>
>> ACs bind attributes to an identity.
>>
>> Authentication, which includes validating the PKC certification path and
>> having the remote party perform some operation that involves the private
>> key associated with the identity.  Without authentication of the
>identity,
>> who cares what attributes are associated with it?
>>
>> Russ
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com
>
>
>



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12817 for <[e-mail]>; Thu, 12 Oct 2000 12:21:48 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id PAA32040; Thu, 12 Oct 2000 15:21:56 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Thu, 12 Oct 2000 15:21:55 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
cc: Stephen McConnell <[e-mail]>, Kent Salmond <[e-mail]>, Ken Mccoy <[e-mail]>, John Propper <[e-mail]>, Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Comments on draft-ietf-pkix-ac509prof-05.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This message is from Polar Humenn from Adiron, LLC; Syracuse University;
and the Object Management Group(OMG) Security SIG.

Greetings IETF, PKIX WG, OMG Security SIG, and OMG E-Commerce DTF:

I have analyzed the X.509 Attribute Certificate Draft Specification and
have come to the conclusion that a glaring problem exists. The problem
relates to the verification that the Relying Party(RP) carries out on the
Attribute Certificate(AC) issued by an Attribute Authority(AA) for a
particular subject entity. This problem exists in the case when the
subject entity is represented by a chain of Public Key Certificates (PKC),
such as in, but not limited to, SSL or TLS.

I also state a recommendation of the creation and use of the AC's in their
current form, draft-ietf-pkix-ac509prof-05.txt, for systems in which
verification of that AC belongs to particular subject entity is paramount.

The Problem:

Only the least significant part of the AC's Holder's Identity is present
in the AC.

This anomally is a problem, because it allows impostors or coincidental
bystanders to reap the privileges certified in the AC.

Several Certificate Authorities(CA) may create subject entities with any
DN they choose. An ATTACK may be levied against an RP by virtue of knowing
(or sniffing) the fact that an AC was issued in a particular Holder's DN.
The only prevention against such an attack is that the AA and the RP agree
on common trust points (trusted CA) for verification of the PKCs used to
reference the Holder at the AA, and authenticate the Holder at the RP.
Also the Holder's certificate chain length MUST be no greater than 2 and
that the DN spaces underneath each trusted CA the AA and RP agree on MUST
be distinct.

On The Distinctness of DN space:

In the following treatise, DN's are represented by single words, such as
CA1 and DN1. A DN path from most significant to least significant is
represented as DNs separated by colons (:), such as CA1:DN1. 

In the case where CA1 and CA2 are Certificate Authorities and they certify
names in a common DN space, name collisions can exist. [Note: There is no
mandate that either CA1 or CA2 know anything about each others name
spaces]. 

The problem is that if the AA certifies privileges for CA1:DN1, only DN1
goes in the AC. If the RP gets an authentication from CA2:DN1 (which is a
different subject entity). The AC WRONGFULLY applies. The AA did NOT issue
CA2:DN1 the privileges, it issued them to CA1:DN1.

The structure of DN's will NOT solve this problem, since there is no
mandated relationship between an Issuer's DN and a Subject's DN in a
Public Key Certificate. i.e. there is no relationship between the internal
structure of CA1 and the internal structure of DN1. Therefore, no
implication can be made as to the Holder's Issuer's name from the Holder's
DN alone.

This problem is tantamount considering 1234 and 3214 equal numbers. This
problem is also tantamount to ordering and paying for a pizza under credit
card 2132 2323 3343 3433 and letting anybody with a credit card xxxx xxxx
xxxx 3433 pick it up.

This situation DOES NOT lend itself to a GOOD E-commerce model.

It is also said that the following scenario is desirable and should be
supported:

The following scenario is attributed to Stephen Farrell from an email I
received from him:

> CA1 certifies holder.
> CA2 certifies CA1.
> AA trusts CA2 as a "root"
> CA3 also certifies CA1.
> RP trusts CA3 as a "root"

> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and
> [CA3,CA3],[CA3,CA1],[CA1,holder] are potentially valid paths, where
> [x,y] means "x certifies y". Based on their respective configurations
> the first path is usable by the AA, the second by the RP.

In this case, the RP has no idea what the AA certified. Does
CA2:CA1:Holder really the same as CA3:CA1:Holder?

The RP would have to know that some cross certification is possible, i.e.
that actually AA was using CA2:CA1 for referencing Holder. This is
impossible and cannot be verified unless the RP has intimate knowledge of
the AA.


Using the baseCertificateID IssuerSerial form of the Holder in the AC:

Using the baseCertificateID IssuerSerial form of the AC Holder just pushes
the problem up one level because the Issuer is only named by a single DN,
and not a path from its root CA. If it is NOT the case that the Issuer is
a common trust point for the AA and the RP and they agree that the DN
references the same certificate, verification of the AC with respect to
the Holder's certificate serial number cannot even be performed.

If the Holder is defined by a CA that is two levels deep, verification of
the AC with respect to the Holder certificate serial number cannot be
performed. Attacks can now be enumerated by creating certificate chains
with bogus PKCs with serial numbers and the Issuer's DN.


Widely Scaled E-COMMERCE Model:

This model for E-COMMERCE should be able to be supported by an AA and RP.

The RP sells Pizza. 
A user labeled by a PKC chain of RootCA1:CA2:Batman wants to buy a pizza.
He contacts the RP's AA, pays for the pizza, and the AA creates an AC with
attributes telling the RP that a pizza has been purchased.

Note that this can be an pseudo anonymous process. In this process, the AA
authenticates Batman all the way up to the RootCA1. It is not the job of
the AA to care if the RootCA1 is a trusted entity of the AA. The AA for
the purposes of collecting money trusts all Root CA's only for the purpose
of authentication. There is just an agreement between the AA and the RP
that whatever identity certificate chain is presented to the AA, verifies
to a root. The AA and RP don't care who it is or who certified it, just
that the entity paid for a pizza, AND that the same entity that paid for
the pizza walks out with the pizza.

Unfortunately, the standard X.509 AC only contains the Holder as "Batman".

RootCA1:CA2:Batman authenticates to the RP to pick up a pizza. The AC
(either delivered by Batman, or gotten from some directory) verifies in
this case and Batman gets his pizza.

ALSO: 

If RootCA2:CA43:CA33:Batman authenticates to the RP and orders a pizza,
without going to the AA first. The AC verifies and he, THE WRONG BATMAN,
gets a pizza.

This is tantamount to a standard college prank, of which this Attribute
Certificate Model as it stands, cannot prevent.

For this scenario to work without common trusted CA certificates between
the AA and RP, the AC needs to contain the entire DN path from the RootCA
to the Holder, AND it MUST contain a hash of the Holder's RootCA
certificate to prove that the same certificate chain presented to the AA
was presented to the RP.


Recommendation for Verifiability of the X.509 AC:

Aside from HIGHLY CONSTRAINED environments, where agreements between AAs
and RPs go down into intimate details, there is only one Profile that can
breed VERIFIABLE trust that the AA actually certified the subject entity
the RP is dealing with:

Verifiable Profile;
1. The AA MUST use the baseCertificateID IssuerSerial form of the Holder.
2. The AA and RP must agree that ANY Issuer Name in the 
   baseCertificateID field resolves to the SAME certificate 
   in their respective repositories,i.e. Common Trust Points. 
   That is, any verification chain of a Holder's PKC cannot
   be greater than 1 from any trust point common to both the AA and the
   RP.
3. The RP MUST reject any AC for which the AA and RP have not 
   emphatically agreed on to be a common trust point, even if
   the RP can locate the Issuer's certificate via the DN in the
   baseCertificateID field of the AC.

This solution does not scale well. The AA and RP must communicate
agreements on common trust points.

Requirement 1 is unfortunate because that may require a lookup at the RP
and keep and it definitely ties the AC to the subject entity's
certificate. This effect is undesirable especially in the case of key
rollover, where a new PKC with a different serial number is issued.

The reliance on common trust points severely limits the use of the AC in
widely scaled environments.


Recommendation to the OMG, Security SIG, and E-Commerce Groups;

The OMG Security Protocol (CSIv2) has stated that the IETF AC X.509
Profile be used for it's delivery of privilege information. I only can
recommend that the above Recommendation for Verifiability be followed for
CORBA and EJB systems that use X.509AC, or that the OMG Security Group
fashions its own X.509 Profile with new attribute extensions solving the
problem of verification of X.509 AC, or it creates a new privilege
certificate altogether.

Sincerely,
Polar Humenn

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com







Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11819 for <[e-mail]>; Thu, 12 Oct 2000 11:26:43 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA163268; Thu, 12 Oct 2000 14:30:58 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id OAA69364; Thu, 12 Oct 2000 14:31:04 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256976.0065AE61 ; Thu, 12 Oct 2000 14:30:37 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: Russ Housley <[e-mail]>, pkix <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 14:30:46 -0400
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA11820

     I am not misquoting the draft in any important way.  The third
paragraph (excluding the note) of section 4.2.2 of your current draft
begins as follows: "If the holder field uses the entityName option and the
underlying authentication is based on a PKC, then the entityName MUST be
the same as the PKC subject field, unless the PKC subject field contains an
empty distinguished name. If the PKC subject field contains an empty
distinguished name, then the entityName field MUST be identical to one of
the values of the PKC subjectAltName field extension."  This forbids the
use of a value from subjectAltName, whether e-mail or PI, as an entityName
if the subject DN is present.  The preference for baseCertificateID makes
the issue somewhat less important, but does not eliminate it.
     As for PI's (whose draft is -01 rather than -00), I cited them as one
of two reasonable global identifiers for a user in SubjectAltName.  I
understand that you would not want to hold up this draft for that one, but
I'm looking for re-wording of this statement to allow SubjectAltName
components including e-mail, but excluding IP address, DNS name, and
probably some others.  It might be appropriate to state that the use of
"OTHER-NAME components specifying the identity of the subject as an
individual" may be supported as well.

          Tom Gindin

Stephen Farrell <[e-mail]> on 10/12/2000 05:30:30 AM

Please respond to [e-mail]

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject:  Re: AttributeCertificates: Why is the holder DN preferred?




Tom,

I think you're misquoting the draft. basdCertificateID is the SHOULD for
holder
when PKCs are used for authentiation. When entityName is used, the text
tells
you how it should compare to the subject and/or subjectAltName from the
PKC. It
does not say that the PKC must use any particular form of subject naming.

There is no reference to PI since right now that's a -00 draft with who
know
what future (bright, I'm sure:-) and the AC profile is in IETF wide last
call.

Stephen.

[e-mail] wrote:
>
>      Russ:
>
>      On one subject which is connected to what Polar brought up, I am
> inclined to think that he is right.  In the AC509Prof draft, section
4.2.2
> states that for PKC-based authentication the entityName MUST be the same
as
> the PKC subject field unless that field is empty.  Why should it be
> mandatory to prefer the subject DN to either permanent ID's or e-mail
> addresses, both of which identify individuals in a globally unique way?
> Name collisions are more likely in the DN space than in either of the
other
> two, except for PI's with a default assignment authority, and PI's of
that
> sort should be forbidden as entityName's.  This does not imply that most
of
> the options within GeneralName are appropriate as entityName's, as I
don't
> think they are.
>
>           Tom Gindin
>
> Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM
>
> To:   Polar Humenn <[e-mail]>
> cc:   Al Arsenault <[e-mail]>, Stephen Farrell
>       <[e-mail]>, Patrik Fältström <[e-mail]>,
>       [e-mail], [e-mail], Thumrongsak Kosiyatrakul
>       <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
>       Older <[e-mail]>
> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
Targets
>       andProxies
>
> Polar:
>
> > > Okay, I think I finally figured out what Polar is getting at here,
but
> > > I'm not sure what the fix is.  Let me try to illustrate with an
> example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both
> equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The
issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC
> can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that
is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not
require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be
recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate
is
> >unreasonable. Can something like this be mandated in this profile? I
don't
> >see how. I only see that in specific protocols. Or am I wrong?
>
> PKCs bind a public key to an identity.
>
> ACs bind attributes to an identity.
>
> Authentication, which includes validating the PKC certification path and
> having the remote party perform some operation that involves the private
> key associated with the identity.  Without authentication of the
identity,
> who cares what attributes are associated with it?
>
> Russ

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com





Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10526 for <[e-mail]>; Thu, 12 Oct 2000 10:37:00 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id NAB09879; Thu, 12 Oct 2000 13:41:31 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 12 Oct 2000 13:39:44 -0400
To: Carlisle Adams <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: The future of DVCS...
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail].c om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Carlisle & Denis,

Like Steve, I am comfortable with moving this to Experimental.  I think 
DVCS has run its course, but I don't want to lose the ideas that were 
incorporated into the document.  This strategy permits us to document the 
good ideas in DVCS in more permanent fashion than periodically resubmitting 
the Internet-Draft.

In my opinion, duplication of functionality with standards track documents 
is not an issue.  I assume a "successful" experimental protocol *should* be 
the precursor to standards track RFCs that implement those experimental 
concepts in  a solid and interoperable fashion.   I realize this has 
already occurred to some extent, but there is no need to remove this overlap.

Let's move DVCS to experimental and free up the DVCS editors' time to 
contribute to the standards track documents that will follow.

Tim Polk


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10210 for <[e-mail]>; Thu, 12 Oct 2000 10:32:32 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA09903; Thu, 12 Oct 2000 19:37:02 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 12 Oct 2000 19:37:02 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA28247; Thu, 12 Oct 2000 19:37:01 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA00384; Thu, 12 Oct 2000 19:37:01 +0200 (MET DST)
Date: Thu, 12 Oct 2000 19:37:01 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Experimental TSA
Cc: [e-mail]

> 
> Jean-Marc,
> the proposed protocol could be fine but you know
> that the Time Stamp Authority is one for many different clients
> so the protocol is usually decided by the TSA.

> Is very difficult to serve different clients with different protocol ideas.
Indeed. That's why it necessary to discuss possible ambiguities
in protocols. 

> We need more explicit formalization for this kind of extensions.
> 
> And also what about the "denial of service" problems arised from a client which
> doesn't close the connection and let the server waiting indefinitely or in
> the better for a timeout?
This problem is not much different from those that any web server is
faced today. 

You have the same problem when the client opens a connection and doesn't send
data. Does your server has a time out for that? At least it is pretty long >1h,
as far as I can say. :-) 

> Our TSA implementation close the connection after a Token is sent back to
> the client.
It is a simple solution that works. Anyway, it is good to have something
to experiment with. 

Have fun
Peter


Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09642; Thu, 12 Oct 2000 10:20:37 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id <TRNYXPMN>; Thu, 12 Oct 2000 13:26:00 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Subject: v1.8 Certificate Management Library Now Available
Date: Thu, 12 Oct 2000 13:22:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

Getronics Government Solutions (GGS) (formerly Wang Government Services) has
delivered the Version 1.8 Certificate Management Library (CML).  The v1.8
CML is freely available to everyone from the Fortezza Developers CML Page
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html>.  

The v1.8 CML is described in the v1.8 CML Application Programming Interface
(API) document.  It implements the 1997 X.509 certification path processing
rules and SDN.706.  It meets the majority of the IETF PKIX RFC 2459
Certificate/CRL Profile requirements.  It (optionally) provides local cache
management functions and (optionally) obtains data objects using the
Lightweight Directory Access Protocol (LDAP).  It can (optionally) be used
in conjunction with the v1.31 Certificate Path Development Library (CPDL)
developed by CygnaCom Solutions, an Entrust Technologies company, to provide
robust certification path building capabilities such as using cross
certificates. The CML has been used to validate X.509 Certificates and
Certificate Revocation Lists (CRL) signed using the Digital Signature
Algorithm (DSA) and RSA.   Further enhancements, ports and testing of the
CML are still in process.  Further releases of the CML will be provided as
significant capabilities are added. 

The following v1.8 CML files are available:
CMLv18win.zip: MS Windows Dynamically Linked Libraries (DLL) 
CML18so.tar.Z: Sun Solaris Libraries 
CML18li.tar.Z: Linux Libraries
CML18sr.tar.Z: Source, including Windows project files 

The aforementioned files and the v1.8 CML API document (CMv1_8api.doc,
CMv1_8api.pdf), test certs (CML18data.zip) and readme.txt files are stored
on the Fortezza Developers CML Page.

The v1.8 CML includes the following enhancements (compared with the v1.71
CML release):

1) Fixed all bugs reported by customers.

2) Tested for MS Windows, Solaris 2.7 and Linux.  On Linux and MS Windows,
we tested the CML with the following crypto capabilities: internal calls to
the internal SHA-1/DSA code; internal calls to RSAREF library; and using the
Crypto++ Crypto Token Interface Libraries (CTIL) with the Crypto++ v3.2
library.  

3) Tested using common v1.3 R4 Enhanced SNACC ASN.1 C Library, v1.8 CTILs
and LIBCERT libraries shared with the v1.8 S/MIME Freeware Library (SFL) and
v1.4 Access Control Library (ACL).  The common, shared libraries are
available from the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.

4) Enhanced to process all recognized certificate and CRL extensions,
regardless of criticality.

5) Implemented SDN.706 sigOrKMPrivileges and commPrivileges subordination
checks.

6) Corrected processing of v2 subject and issuer unique identifiers.  v1.71
CML incorrectly processed them as if they were key identifiers instead of
distinguished name (DN) qualifiers.

7) Corrected cache/database code so that it stores distribution point CRLs
under a separate entry in the cache/database that is identical to entry from
which the CRL was retrieved.

8) Added name constraints processing for name forms specified in RFC 2459:
rfc822Names, DNS Names and Uniform Resource Identifiers (URI).
directoryName is already supported.  

9) Added support for NULL subject DNs.  (NOTE: Certs with a NULL subject DN
will not be stored in the CML database.)

10) Added support for the RFC 2459 Authority Information Access (AIA)
extension. This includes enhancing the CML to retrieve and check a CRL
identified in an AIA extension by an LDAP address in the URI field.

11) Enhanced CRL retrieval processing.  This includes identification of
Authority Revocation List (ARL) vice CRLs and using the application-provided
distribution points information in the CM_RequestCRLs function.  This
includes enhancing the CML to automatically search the directory for a
current CRL when the current date is later than the nextUpdate field in a
local CRL.  This also includes enhancing the CML to retrieve and check a CRL
identified in a CRLDistributionPoint (CRLDP) extension by an LDAP address in
the URI field.  This also includes the ability to process multiple URI
fields in the CRLDP (especially to handle the case in which the initial URI
field indicates a null server name (LDAP:///...)). 

12) Added support for certificate policy qualifiers as described in RFC
2459.

13) Removal of the C++ SNACC conversion shared library (cmdec_cpp) (the v1.8
CML makes use of the C SNACC ASN.1 Library, but not the C++ SNACC ASN.1
Library).

14) Add CTIL interface shared library (cmctil).

15) Incorporated calls (IFDEFed) to BSAFE v5 library submitted by Secure
Computing Corporation.
  
16) Enhanced CMTool to execute performance testing and memory leak testing.

17) Performed regression testing to ensure that aforementioned enhancements
did not break existing CML functionality.

We welcome all feedback regarding the CML software and documents.  If
bugs are reported, then we will investigate each reported bug and, if
required, will produce a patch or an updated release of the software to
repair the bug.

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  GGS is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.8 CML uses the GGS v1.3 R4 Enhanced SNACC ASN.1 Library to
encode/decode objects.  GGS has successfully tested the v1.8 CML with the
SNACC and CTIL DLLs delivered in conjunction with the v1.8 SFL.  Source code
for the GGS-developed CTILs is available from the Fortezza Developer's
S/MIME Page.  The actual crypto libraries are not provided with the CML or
SFL.  They must be independently obtained from the appropriate source.  

The v1.8 CML can be used in conjunction with the v1.31 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML18sr.tar.Z file includes the CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

The Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml>   
and a CML mail list which is used to: distribute information regarding CML
releases; discuss CML-related issues; and allow CML users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-cml mailing list is at the IMC web site listed above.  

All comments regarding the CML source code and documents are welcome. This
CML release announcement was sent to several mail lists, but please send all
messages regarding the CML to the imc-cml mail list ONLY.  Please do not
send messages regarding the CML to any of the IETF mail lists.  We will
respond to all messages sent to the imc-cml mail list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07838 for <[e-mail]>; Thu, 12 Oct 2000 09:14:27 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <T6Z8BZ0A>; Thu, 12 Oct 2000 12:18:36 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: The future of DVCS...
Date: Thu, 12 Oct 2000 12:18:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03468.0C5257A0"

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_01C03468.0C5257A0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Thursday, October 12, 2000 3:25 AM
> To: 	Carlisle Adams
> Cc: 	'[e-mail]'; '[e-mail]'; [e-mail]
> Subject: 	Re: The future of DVCS...
> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
 
(...some text deleted...)

> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also
> means
> that this subset is not the right direction for the long run and thus
> should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC.  
 
Actually, this is a very good reason why this subset *should* be placed in
an Experimental RFC.  These other protocols, which differ in some details
with what is in DVCS, go on to become standards, whereas our early
"experimental" work on this same functionality is archived as something that
was tried but not standardized.

> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
 
Actually, this again *is* a good argument for saving this material in an
Experimental RFC.  DVCS represents something that was conceived, discussed,
and implemented, but all in quite limited circles.  When it comes time to
discuss this sort of topic more broadly, this early "experimental" work can
perhaps serve as a reasonable starting point for that discussion.

> > Furthermore,
> > we are aware of only a single implementation at this time, so any
> > interoperability testing is out of the question, at least at the moment.
> > But enough work has gone into this protocol that letting it expire as an
> > Internet Draft and disappear completely seems inappropriate, especially
> if
> > (as we suspect) this higher-layer functionality will begin to be
> required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.
 
Within the IETF environment, what alternatives are there for preserving this
work?  As you well know, the only archival documents in IETF are RFCs, so if
we all agree that DVCS is not appropriate for the standards track at this
time, we are left with Experimental, Informational, Historic, and Best
Current Practice.  The description for Experimental is given in RFC 2026 as
follows:

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

DVCS was certainly the result of some early research work centering on the
possible uses of a notarization-type server, and did undergo some limited
development (i.e., implementation) effort.  It may be useful as a source of
information on this topic to at least the Internet technical community, if
not the broader Internet community.  It makes sense to have an archival
record of this work, especially if this topic may arise again in the future.
I see pretty-much an exact fit between DVCS and the stated purpose of the
Experimental RFC category.

Perhaps, however, you are suggested that this document should be preserved
outside the IETF process.  This can certainly be done, but I must confess to
having a hard time seeing what value that would serve to the Internet
community.

> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
 
(...substantial and valuable comments deleted for the sake of brevity...)

Thank you once again for your careful consideration of this document and for
your thoughtful input.  I skimmed quickly through Peter's responses and am
in agreement with what I saw there.  But ultimately the question is this:
"Is it worth revising this document further, given that it is not targeted
for the standards track?"  Why don't we simply freeze it as-is and call it a
day.  I suspect we all have other things we could be working on...

Carlisle.


------_=_NextPart_001_01C03468.0C5257A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: The future of DVCS...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Denis,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis =
Pinkas[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, October 12, 2000 3:25 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">'[e-mail]'; '[e-mail]'; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: The future of DVCS...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you for posting this E-mail. As =
explained hereafter, while I agree</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with many of your arguments, I do not =
share your conclusion.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; In discussing this protocol with =
the other authors and with various</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; members of the community, I =
sense &quot;rough consensus&quot; on two things.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Firstly, it makes sense to allow =
the more clearly-defined subsets of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; DVCS functionality to be handled =
by these other protocols (TSP, OCSP,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; etc.) since they are relatively =
well-understood and implementations are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; already either completed or =
underway.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree that more clearly-defined =
subsets of the DVCS functionality should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be handled by these other protocols =
(TSP, OCSP, etc.) .. but this also means</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that this subset is not the right =
direction for the long run and thus should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be deprecated. For that reason, this =
subset should *not* be placed in an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">experimental RFC.&nbsp; </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
this is a very good reason why this subset *should* be placed in an =
Experimental RFC.&nbsp; These other protocols, which differ in some =
details with what is in DVCS, go on to become standards, whereas our =
early &quot;experimental&quot; work on this same functionality is =
archived as something that was tried but not standardized.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Secondly, most real-world</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; environments are not yet ready =
to incorporate notarization functions for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; other data formats.&nbsp; This =
higher-layer purpose of DVCS is perhaps too</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; early as a concept to engage =
serious review and debate within the wider</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PKIX group right now.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I also agree. However, this is not an =
argument for saving this material in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an experimental RFC either.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
this again *is* a good argument for saving this material in an =
Experimental RFC.&nbsp; DVCS represents something that was conceived, =
discussed, and implemented, but all in quite limited circles.&nbsp; =
When it comes time to discuss this sort of topic more broadly, this =
early &quot;experimental&quot; work can perhaps serve as a reasonable =
starting point for that discussion.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Furthermore,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; we are aware of only a single =
implementation at this time, so any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; interoperability testing is out =
of the question, at least at the moment.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; But enough work has gone into =
this protocol that letting it expire as an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Internet Draft and disappear =
completely seems inappropriate, especially if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (as we suspect) this =
higher-layer functionality will begin to be required</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in PKI environments in the one- =
to three-year time frame.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The specification can certainly be =
saved without being transformed as an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">experimental RFC.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Within =
the IETF environment, what alternatives are there for preserving this =
work?&nbsp; As you well know, the only archival documents in IETF are =
RFCs, so if we all agree that DVCS is not appropriate for the standards =
track at this time, we are left with Experimental, Informational, =
Historic, and Best Current Practice.&nbsp; The description for =
Experimental is given in RFC 2026 as follows:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; The &quot;Experimental&quot; designation typically =
denotes a specification that</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; is part of some research or development =
effort.&nbsp; Such a specification</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; is published for the general information of the =
Internet technical</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; community and as an archival record of the work, =
subject only to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; editorial considerations and to verification that =
there has been</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; adequate coordination with the standards process =
(see below).&nbsp; An</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; Experimental specification may be the output of an =
organized Internet</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; research effort (e.g., a Research Group of the =
IRTF), an IETF Working</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; Group, or it may be an individual =
contribution.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">DVCS was =
certainly the result of some early research work centering on the =
possible uses of a notarization-type server, and did undergo some =
limited development (i.e., implementation) effort.&nbsp; It may be =
useful as a source of information on this topic to at least the =
Internet technical community, if not the broader Internet =
community.&nbsp; It makes sense to have an archival record of this =
work, especially if this topic may arise again in the future.&nbsp; I =
see pretty-much an exact fit between DVCS and the stated purpose of the =
Experimental RFC category.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Perhaps, =
however, you are suggested that this document should be preserved =
outside the IETF process.&nbsp; This can certainly be done, but I must =
confess to having a hard time seeing what value that would serve to the =
Internet community.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hereafter are some more technical =
comments which related to version 06 (I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have not read the recently posted =
version 07)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">(...substantial and valuable comments deleted for the sake of =
brevity...)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thank you =
once again for your careful consideration of this document and for your =
thoughtful input.&nbsp; I skimmed quickly through Peter's responses and =
am in agreement with what I saw there.&nbsp; But ultimately the =
question is this:&nbsp; &quot;Is it worth revising this document =
further, given that it is not targeted for the standards =
track?&quot;&nbsp; Why don't we simply freeze it as-is and call it a =
day.&nbsp; I suspect we all have other things we could be working =
on...</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03468.0C5257A0--


Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05929 for <[e-mail]>; Thu, 12 Oct 2000 08:45:42 -0700 (PDT)
Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id 1931B2FDD; Thu, 12 Oct 2000 17:50:20 +0200 (CEST)
Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id B9407108005; Thu, 12 Oct 2000 17:50:14 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 17:50:13 +0200
From: Bernd Matthes <[e-mail]>
Reply-To: [e-mail]
Organization: Celo Communications GmbH http://www.celocom.de
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: Kevin White <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: UNSUBSCRIBE
References: <01FE208971B3D311B41900508B8B6BCF178873@ZEUS>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0B3C5D5CA60D1F31B1B4026C"

This is a cryptographically signed message in MIME format.

--------------ms0B3C5D5CA60D1F31B1B4026C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Kevin White wrote:
> 
> I have been looking for messages with unsubscribe instructions, but I
> don't see the instructions on any of the many messages per day that I
> receive.  How do I unsubscribe?
> 
> Thanks,
> 
> Kevin

Hi Kevin!

Try the follow:

Look in a mail header from the list and search for 
"List-Unsubscribe: " and then click on this link.

mailto:[e-mail]?body=unsubscribe

Example:

      List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
           List-ID: <ietf-pkix.imc.org>
  List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

Regards

-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	Weissenfelser Strasse 46a   
Nachrichtentechniker            D 06217 Merseburg           
Dipl.-Ing.(FH)                  http://www.celocom.com      
  f. technische Informatik      mailto:[e-mail]   
http://www.worldbug.de          Tel.: [phone]       
mailto:[e-mail]      Fax:  [phone]
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------ms0B3C5D5CA60D1F31B1B4026C
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

MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw
MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG
9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa
ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw
6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB
pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz
aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp
U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT
aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2
YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp
Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi
k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv
A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ
FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg
UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw
WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw
b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl
cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh
bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2
uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7
vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG
5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH
AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV
HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt
qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG
3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN
Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf
MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu
LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG
A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u
YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAxMDEyMTU1MDE0WjAjBgkq
hkiG9w0BCQQxFgQUiHL/n6mkp3d9bhrUsVsTbUlAZ2QwUgYJKoZIhvcNAQkPMUUwQzAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI
hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDV4YY0lqMmLqGBESY5xTGXvmUmH8x0Y8t0C8nJ
GH3wCRUHwPFpJJnMVws02SrHCBwiMNbWju7YjoKh1xlI3mhEzAsyh16WK1Eu2OHHGk79Vtpw
nP0yJazoMgydMCdJh29BAxehw+kubW9rU6f5GfNHK3LfTCj02QUcQkktjxrGGg==
--------------ms0B3C5D5CA60D1F31B1B4026C--



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04043 for <[e-mail]>; Thu, 12 Oct 2000 08:32:48 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 12 Oct 2000 08:37:22 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 12 Oct 2000 08:37:22 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2650.21) id <4XW6SCDR>; Thu, 12 Oct 2000 08:36:30 -0700
Content-return: allowed
Date: Thu, 12 Oct 2000 08:36:29 -0700
From: Boulos Dib <[e-mail]>
Subject: RE: UNSUBSCRIBE
To: "'Kevin White'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/alternative; boundary="Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)"

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.

--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)
Content-type: text/plain; charset="iso-8859-1"

Try the "Mailing lists" (  <http://www.ietf.org/maillist.html>
http://www.ietf.org/maillist.html) link on the ietf main page (
<http://www.ietf.org)> http://www.ietf.org)
 
Boulos.

-----Original Message-----
From: Kevin White [mailto:[e-mail]]
Sent: Thursday, October 12, 2000 10:46 AM
To: '[e-mail]'
Subject: UNSUBSCRIBE


I have been looking for messages with unsubscribe instructions, but I don't
see the instructions on any of the many messages per day that I receive.
How do I unsubscribe?
 
Thanks,
 
Kevin


--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)
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 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=936583615-12102000>Try 
the "Mailing lists"&nbsp;(<A href="http://www.ietf.org/maillist.html"><FONT 
size=2><FONT face=Arial>http://www.ietf.org/maillist.html</FONT></FONT></A>) 
link on the ietf main page (<A href="http://www.ietf.org)"><FONT size=2><FONT 
face=Arial>http://www.ietf.org</FONT></FONT>)</A></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=936583615-12102000>Boulos.</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kevin White 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 12, 2000 10:46 
  AM<BR><B>To:</B> '[e-mail]'<BR><B>Subject:</B> 
  UNSUBSCRIBE<BR><BR></DIV></FONT>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial size=2>I have been 
  looking for messages with unsubscribe instructions, but I don't see the 
  instructions on any of the many messages per day that I receive.&nbsp; How do 
  I unsubscribe?</FONT></SPAN></DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2>Thanks,</FONT></SPAN></DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2>Kevin</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)--


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28765 for <[e-mail]>; Thu, 12 Oct 2000 07:51:54 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA07534; Thu, 12 Oct 2000 16:56:32 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 12 Oct 2000 16:56:32 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA27404; Thu, 12 Oct 2000 16:56:31 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA00330; Thu, 12 Oct 2000 16:56:30 +0200 (MET DST)
Date: Thu, 12 Oct 2000 16:56:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Experimental TSA

> > The TimeStamp protocol  doesn't require to leave the connection open for
> > other possible requests after the first has been processed.

We are not talking about the time stamp protocol, but about transport
protocols that are used to exchange queries and replies. 

> 
> Doesn't require, but doesn't restrain either.
Right.

The question is what happens in clients that have been developped by
the same group that always close a connection. Do these clients just
read the n octects returned and process and then finish, or will they
block, in trying to read data, or?  

> What's more :
>   There is no mandatory transport mechanism for TSA messages in this
>   document.  The mechanisms described below are optional; additional
>   optional mechanisms may be defined in the future.
> 
> > So if you want to send many requests at the time you need to do many connections.
> >
> > We could provide some extension payload to the socket based  protocol
> > to support multiple requests in a single packet (modifying the actual draft, but I
> > do not think this is the right time to do that).
> 
> Nothing restrains the client and the authority to have an agreement to exchange
> several messages in a row in the current proposal.
> The problem is that with the current protocol, the client and the TSA need to agree on
> that out of band.
> 
> This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
> 1.0 to an HTTP 1.1 request and close the connexion.
> 
> The only difference here is that the client has no way to tell explicitly the TSA that
> he wishes to keep the connexion open after the first message.

Note what had been said in 

      draft-ietf-pkix-cmp-transport-protocols-00.txt

1. Motivation

  Section 5 of the [RFC2510] spec specifies sending the DER-encoded
  CMP message directly over various protocols. However, implementors,
  during various interoperability workshops, found the protocol
  lacking in the following respects:

  1.	No clear definition on when the connection is to be closed
	and by whom.
  2.	No version number specified to allow for extensions.
  3.	Error messages cannot be processed by applications.

  Realizing that this could not be achieved in a backward compatible
  way, and acknowledging the changes being made to [RFC2510], the
  decision was made to enhance the protocol now to avoid
  interoperability conflicts later and to pull the transport section
  out in a separate draft. This enhancement tries to keep as much of
  the older protocol as possible, while ensuring that implementations
  using the old protocol will not mistake a new message for a valid
  message in the [RFC2510] format.

At least we have the SAME situation as in 1. here in this discussion. 


> That means a TSA that's able to handle another request on the same connexion, has to
> leave the connexion open after sending the answer and watch if the client decides to
> close it.
It could leave the connexion open for a certain time, just as in a http
keep alive, or actualy one could implement the technique proposed in the
draft mentioned above. 

It was an error anyway not just simply reference 2510. That's history.
 
> The client just has to check if the connexion is still open before sending the second
> message.
This is normal error handling.

> This seems to me to work quite well, even if it's not as elegant as explicitly telling
> whether there will be several messages or not.

This is similar to the question whether for example pipelining would be allowed
in some way or another. Actually a client can also simply open several channels. 


Received: from artemis.e-filer.com (www.e-filer.com [216.250.76.74]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28526 for <[e-mail]>; Thu, 12 Oct 2000 07:49:31 -0700 (PDT)
Received: by D8FA5501.ptr.dia.nextlink.net with Internet Mail Service (5.5.2650.21) id <42RXJNH3>; Thu, 12 Oct 2000 08:54:49 -0600
Message-ID: <01FE208971B3D311B41900508B8B6BCF178873@ZEUS>
From: Kevin White <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: UNSUBSCRIBE
Date: Thu, 12 Oct 2000 08:45:57 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0345C.5E2EACB0"

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_01C0345C.5E2EACB0
Content-Type: text/plain;
	charset="iso-8859-1"

I have been looking for messages with unsubscribe instructions, but I don't
see the instructions on any of the many messages per day that I receive.
How do I unsubscribe?
 
Thanks,
 
Kevin

------_=_NextPart_001_01C0345C.5E2EACB0
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 5.50.4207.2601" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=550425314-12102000><FONT face=Arial size=2>I have been looking 
for messages with unsubscribe instructions, but I don't see the instructions on 
any of the many messages per day that I receive.&nbsp; How do I 
unsubscribe?</FONT></SPAN></DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2>Kevin</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C0345C.5E2EACB0--


Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28100 for <[e-mail]>; Thu, 12 Oct 2000 07:43:48 -0700 (PDT)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id PAA05623; Thu, 12 Oct 2000 15:54:48 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 16:50:53 +0200
From: Raffaello <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Marc Desperrier <[e-mail]>
CC: [e-mail]
Subject: Re: Experimental TSA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE65B2EB52F82D672637224A1"

This is a cryptographically signed message in MIME format.

--------------msE65B2EB52F82D672637224A1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jean-Marc,
the proposed protocol could be fine but you know
that the Time Stamp Authority is one for many different clients
so the protocol is usually decided by the TSA.
Is very difficult to serve different clients with different protocol ideas.

We need more explicit formalization for this kind of extensions.

And also what about the "denial of service" problems arised from a client which
doesn't close the connection and let the server waiting indefinitely or in
the better for a timeout?

Our TSA implementation close the connection after a Token is sent back to
the client.

Raffaello



Jean-Marc Desperrier wrote:

> Raffaello wrote:
>
> > The TimeStamp protocol  doesn't require to leave the connection open for
> > other possible requests after the first has been processed.
>
> Doesn't require, but doesn't restrain either.
>
> What's more :
>   There is no mandatory transport mechanism for TSA messages in this
>   document.  The mechanisms described below are optional; additional
>   optional mechanisms may be defined in the future.
>
> > So if you want to send many requests at the time you need to do many connections.
> >
> > We could provide some extension payload to the socket based  protocol
> > to support multiple requests in a single packet (modifying the actual draft, but I
> > do not think this is the right time to do that).
>
> Nothing restrains the client and the authority to have an agreement to exchange
> several messages in a row in the current proposal.
> The problem is that with the current protocol, the client and the TSA need to agree on
> that out of band.
>
> This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
> 1.0 to an HTTP 1.1 request and close the connexion.
>
> The only difference here is that the client has no way to tell explicitly the TSA that
> he wishes to keep the connexion open after the first message.
>
> That means a TSA that's able to handle another request on the same connexion, has to
> leave the connexion open after sending the answer and watch if the client decides to
> close it.
>
> The client just has to check if the connexion is still open before sending the second
> message.
>
> This seems to me to work quite well, even if it's not as elegant as explicitly telling
> whether there will be several messages or not.

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

MIIGtgYJKoZIhvcNAQcCoIIGpzCCBqMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGYwggRiMIIDSqADAgECAgIBITANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCSVQxDzAN
BgNVBAgTBk1pbGFubzEaMBgGA1UEBxMRQ2luaXNlbGxvIEJhbHNhbW8xEDAOBgNVBAoTB0Mg
YW5kIEExGTAXBgNVBAsTEEMgYW5kIEEgU2VjdXJpdHkxLDAqBgNVBAMTI01hc3RlciBSb290
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGNvbS1hbmQu
Y29tMB4XDTAwMDkyNTExMjIyOFoXDTAxMDMyNDExMjIyOFowgbQxCzAJBgNVBAYTAklUMSAw
HgYDVQQIExcyMDA1NyBDaW5pc2VsbG8gQi4gKE1JKTEbMBkGA1UEBxMSVmlhbGUgRi4gVGVz
dGkgMTI2MQwwCgYDVQQKFgNDJkExFTATBgNVBAsWDEMmQSBTZWN1cml0eTEdMBsGA1UEAxMU
SW5nLiBSYWZmYWVsbG8gR2FsbGkxIjAgBgkqhkiG9w0BCQEWE3IuZ2FsbGlAY29tLWFuZC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/9pk93Tx72DkTfN5KOfPs5IdaOM0Pm
GkRikARsOdKsqjdvLtkLCPiupbqv/VzCXTUSvFaBzP2QBDZPkGqsOiya2+nzdYPrQhe9fsgT
eqqrXF1Wq5XEqFRP8gd00n3J1ngpaK7emftB2i5T6O4rCIU54H+VR9z2xcy18DdOkAB/AgMB
AAGjgf0wgfowLgYJYIZIAYb4QgEEBCEWH2h0dHA6Ly93d3cuY2FuZGEuY29tL2NhLWNybC5w
ZW0wgbQGCWCGSAGG+EIBDQSBphaBo1RoaXMgaXMgYSBzdGFuZGFyZCAgWDUwOSBWLjMgQ2Vy
dGlmaWNhdGUgKFdlYiBhbmQgRS1tYWlsKSAgc2lnbmVkIGJ5IEMmQSB3aXRoIHRoZSAyMDQ4
IGJpdHMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQ2VydGlmaWNhdGUuIFRoaXMgQ2VydGlm
aWNhdGUgaXMgdmFsaWQgMTgwIGRheXMwEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEB
BAUAA4IBAQDg+Rj/NPFsdVmJc3BbQfe9MA7gr6Ad6Dc7zB5WiODixSk5yfwjdTjQPqva6F2+
yOzeCnNVWCOqSynjwGz7DrLgvaRmZg61mlEG4qIt9izToSmG9PtwwIo1Rb++VHukoFLFiUND
tr0uiLWXSCn5dJbKEfvAHTtDHoN5ceYeDAjJKKSM8YGRoGb+ZpN4BOOc84KrkTTB0XNFlsXv
+4zNJ6nc3T+puj/BdrJGxBBjQos/WlGUq1I4yW25NTLay1Fz2WrJvy+ECUFUnAx++Aq0HftO
gYWLn1eZ1HTeC6E9MljjDO5hFbWQTcWXAsOD/Z9SJH9cgLEr94yDQQ/RxyTl+FcqMYICGDCC
AhQCAQEwgb0wgbYxCzAJBgNVBAYTAklUMQ8wDQYDVQQIEwZNaWxhbm8xGjAYBgNVBAcTEUNp
bmlzZWxsbyBCYWxzYW1vMRAwDgYDVQQKEwdDIGFuZCBBMRkwFwYDVQQLExBDIGFuZCBBIFNl
Y3VyaXR5MSwwKgYDVQQDEyNNYXN0ZXIgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEf
MB0GCSqGSIb3DQEJARYQaW5mb0Bjb20tYW5kLmNvbQICASEwCQYFKw4DAhoFAKCBsTAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMTIxNDUwNTNaMCMG
CSqGSIb3DQEJBDEWBBQwq8fWjXVMPKCgfUKmyUPXdCTQfjBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggq
hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgHdbtnk7QAWe2tXrBgTa6pdeNVMNLqyty9vW
ZIRjzrZD16rp2yS9wRgLGJa1GxtkyFMbW+YV2Pw29eSe9j5o6da5ltkUXp4JMqhQKSGAfIyE
hYeNKu3ZN3o8S41tfTcPeP5iDj/hsILCYUmpdEBrD1KijICY9zDZ8sIVyLb0ADk+
--------------msE65B2EB52F82D672637224A1--



Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA28040 for <[e-mail]>; Thu, 12 Oct 2000 07:42:44 -0700 (PDT)
Received: (qmail 25196 invoked from network); 12 Oct 2000 14:35:16 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 12 Oct 2000 14:35:16 -0000
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 15:49:26 +0100
From: Pedro Miguel Pereira Borges <[e-mail]>
Reply-To: [e-mail]
Organization: Sociedade =?iso-8859-1?Q?Interbanc=E1ria?= de  =?iso-8859-1?Q?Servi=E7os?=, S.A.
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Attribute Certificates
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7BBB10FA0D2430FA75F77B56"

This is a cryptographically signed message in MIME format.

--------------ms7BBB10FA0D2430FA75F77B56
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


   Hi all :)

   I'm interested in Attribute Certificates and I tried to keep up with
the latest thread but since it was 37 mails long, at some point I was
lost...
   So sorry if this is a re-run :)
   Even so, after reading the latest version, I have some questions that
I hope you can make clearer for me :) :

	-> In section 4.2.3 it's said that all AC Issuers must be identified by
non-empty DNs. It's also said that "it means that the AC Issuer does not
have to know which PKC the verifier will use for it (the AC Issuer).
Using the baseCertificateID field to reference the AC Issuer would mean
that the AC verifier would have to trust the PKC that the AC Issuer
chosed (for itself) at the AC creation time.".
	 =

	   If that is so, then how does the relying party know what AC Issuer
PKC it should use to verify the signature on the AC ?

	-> If the holder is identified using the "entityName" field can you
assure that only the authentic holder can gain access to some resource
and not another party (with an equal DN) ?
	  As far as I know, presenting the AC isn't enough... You also have to
present a proof of possesion (usually the signature of a challenge) of
something that only that identity knows (like the private key
corresponding to the cert's public key)...
	   Am I wrong ?
	   Or, when you use this field, who presents the AC gets the access and
that's it ?

	-> Regarding the previous point, if you use the "objectDigestInfo" of a
public key or cert, you could make that proof of possesion right ?

	-> Are supposing that it's the job of a lower software layer/protocol
to verify/ensure that the AC is being presented by the righteous owner ?
	  If so, do you have any protocol in mind ?

   Thanks in advance,

	Pedro Borges   =


-----------------------------------------------------------------------
Pedro Miguel Pereira Borges                            <[e-mail]>
SIBS - Sociedade Interbanc=E1ria de Servi=E7os, S.A.  <http://www.sibs.pt=
/>
Rua Soeiro Pereira Gomes, Lote 1 - 1649-031 Lisboa, Portugal
Tel: + 351 21 791 88 00                         Fax: + 351 21 794 24 40
Certificate Fingerprint 20:A2:77:C5:15:5E:D7:A2:DF:D5:27:53:4A:99:94:37
-----------------------------------------------------------------------
This message was signed with a certificate issued by MULTICERT SIBS.
To validate the signature you must obtain the 'MULTICERT Pilot'
Certification Authority certificate, at http://www.sibs.multicert.com/
-----------------------------------------------------------------------
--------------ms7BBB10FA0D2430FA75F77B56
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

MIIE1wYJKoZIhvcNAQcCoIIEyDCCBMQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A4swggOHMIIC8KADAgECAgQ3Tt9MMA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTAwMDMyNDEwNTIxOFoXDTAxMDMyNDExMjIx
OFowXjELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDjAMBgNVBAsTBURTSVNUMRUwEwYDVQQDEwxQZWRybyBCb3JnZXMwXDANBgkqhkiG
9w0BAQEFAANLADBIAkEA7fynacoDOKjRXpTOgsKNxdL9snCgaJ2qCWf1nF3rtq0vGQOuF/wl
Ao4Z1Zka1NJY9gVHEQNU7LddIgrIhEYnvQIDAQABo4IByjCCAcYwCwYDVR0PBAQDAgWgMCsG
A1UdEAQkMCKADzIwMDAwMzI0MTEyMjE4WoEPMjAwMDEyMDQyMzIyMThaMBEGCWCGSAGG+EIB
AQQEAwIFoDCBqQYJYIZIAYb4QgENBIGbFoGYQ2VydGlmaWNhZG8gUElMT1RPIE1VTFRJY2Vy
dC4gRXN0ZXMgY2VydGlmaWNhZG9zIHNhbyBlbWl0aWRvcyBhbyBhYnJpZ28gZG8gQ1BTIHF1
ZSBzZSBlbmNvbnRyYSBubyBzZWd1aW50ZSBVUkwgLSBodHRwczovL3d3dy5zaWJzLm11bHRp
Y2VydC5jb20vY3BzLmh0bWwwGQYDVR0RBBIwEIEOYm9yZ2VzQHNpYnMucHQwSgYDVR0fBEMw
QTA/oD2gO6Q5MDcxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MQ0w
CwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFLiWIG3WTfGiSQxdd4FPSyQIoi/lMB0GA1UdDgQW
BBSSbtjJjMglJqMVuQciltJ+9xiKkjAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY0
LjADAgOoMA0GCSqGSIb3DQEBBQUAA4GBAKGLb6p69LOewvfAGwzHhIOCiKLfFOBw5ZPOrQ8q
IVuUSliTpoEDjec4hIFgaVQE7lAqEZqh4FDu09FSylZkBSQrkH8LEvCk7H6Kj1HRXMb31/eI
jXjpUqOadjwLiACPFpYX5KisB3gw/oZBY15IossuXPuMUz4UWTN9OzqHynllMYIBFDCCARAC
AQEwMDAoMQswCQYDVQQGEwJQVDEZMBcGA1UEChMQUElMT1RPIE1VTFRJY2VydAIEN07fTDAJ
BgUrDgMCGgUAoH0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MDAxMDEyMTQ0OTI2WjAeBgkqhkiG9w0BCQ8xETAPMA0GCCqGSIb3DQMCAgEoMCMGCSqGSIb3
DQEJBDEWBBRZFiAxrRTVDDeBPrZtXsbPSDBRCTANBgkqhkiG9w0BAQEFAARAKBGQNCZ5QAUE
n2ReWDBUQU7lAagLLZL+uZ5JJXkfhjmIM/ScXYwEOud52Im04r8wS9BODptK7T5Z/4jNplv0
dA==
--------------ms7BBB10FA0D2430FA75F77B56--



Received: from logatome.francenet.fr (logatome-2.francenet.fr [193.149.96.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25799 for <[e-mail]>; Thu, 12 Oct 2000 05:59:50 -0700 (PDT)
Received: from certplus.com ([193.149.118.138]) by logatome.francenet.fr (8.10.1/8.10.1) with ESMTP id e9CD4JV25358 for <[e-mail]>; Thu, 12 Oct 2000 15:04:28 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 15:05:41 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Experimental TSA
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Raffaello wrote:

> The TimeStamp protocol  doesn't require to leave the connection open for
> other possible requests after the first has been processed.

Doesn't require, but doesn't restrain either.

What's more :
  There is no mandatory transport mechanism for TSA messages in this
  document.  The mechanisms described below are optional; additional
  optional mechanisms may be defined in the future.

> So if you want to send many requests at the time you need to do many connections.
>
> We could provide some extension payload to the socket based  protocol
> to support multiple requests in a single packet (modifying the actual draft, but I
> do not think this is the right time to do that).

Nothing restrains the client and the authority to have an agreement to exchange
several messages in a row in the current proposal.
The problem is that with the current protocol, the client and the TSA need to agree on
that out of band.

This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
1.0 to an HTTP 1.1 request and close the connexion.

The only difference here is that the client has no way to tell explicitly the TSA that
he wishes to keep the connexion open after the first message.

That means a TSA that's able to handle another request on the same connexion, has to
leave the connexion open after sending the answer and watch if the client decides to
close it.

The client just has to check if the connexion is still open before sending the second
message.

This seems to me to work quite well, even if it's not as elegant as explicitly telling
whether there will be several messages or not.



Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25083 for <[e-mail]>; Thu, 12 Oct 2000 05:22:14 -0700 (PDT)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id NAA03954; Thu, 12 Oct 2000 13:33:11 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 14:29:16 +0200
From: Raffaello <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Experimental TSA
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE945F83946DEE6CBEC8DDBDD"

This is a cryptographically signed message in MIME format.

--------------msE945F83946DEE6CBEC8DDBDD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

The TimeStamp protocol  doesn't require to leave the connection open for
other possible requests after the first has been processed.

So if you want to send many requests at the time you need to do many connections.

We could provide some extension payload to the socket based  protocol
to support multiple requests in a single packet (modifying the actual draft, but I
do not
think this is the right time to do that).

Raffaello


Peter Sylvester wrote:

> > Rigth now the only interface available is the socket based protocol defined in
> > the
> > draft-ietf-pkix-time-stamp-09.
> >
>
> Furthermore both implementions close the connection after sending the response.
> This is unfriendly and pretty inefficien if you want to send many requests,
> I am not sure whether this had been intended by the protocol.
>
> The length field at the beginning indicate to the client and to
> the server how many data are transmitted in an exchange.
>
> it seems that the same problem occured in the CMP interoperability tests,
> and this has already resulted in a draft.

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

MIIGtgYJKoZIhvcNAQcCoIIGpzCCBqMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGYwggRiMIIDSqADAgECAgIBITANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCSVQxDzAN
BgNVBAgTBk1pbGFubzEaMBgGA1UEBxMRQ2luaXNlbGxvIEJhbHNhbW8xEDAOBgNVBAoTB0Mg
YW5kIEExGTAXBgNVBAsTEEMgYW5kIEEgU2VjdXJpdHkxLDAqBgNVBAMTI01hc3RlciBSb290
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGNvbS1hbmQu
Y29tMB4XDTAwMDkyNTExMjIyOFoXDTAxMDMyNDExMjIyOFowgbQxCzAJBgNVBAYTAklUMSAw
HgYDVQQIExcyMDA1NyBDaW5pc2VsbG8gQi4gKE1JKTEbMBkGA1UEBxMSVmlhbGUgRi4gVGVz
dGkgMTI2MQwwCgYDVQQKFgNDJkExFTATBgNVBAsWDEMmQSBTZWN1cml0eTEdMBsGA1UEAxMU
SW5nLiBSYWZmYWVsbG8gR2FsbGkxIjAgBgkqhkiG9w0BCQEWE3IuZ2FsbGlAY29tLWFuZC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/9pk93Tx72DkTfN5KOfPs5IdaOM0Pm
GkRikARsOdKsqjdvLtkLCPiupbqv/VzCXTUSvFaBzP2QBDZPkGqsOiya2+nzdYPrQhe9fsgT
eqqrXF1Wq5XEqFRP8gd00n3J1ngpaK7emftB2i5T6O4rCIU54H+VR9z2xcy18DdOkAB/AgMB
AAGjgf0wgfowLgYJYIZIAYb4QgEEBCEWH2h0dHA6Ly93d3cuY2FuZGEuY29tL2NhLWNybC5w
ZW0wgbQGCWCGSAGG+EIBDQSBphaBo1RoaXMgaXMgYSBzdGFuZGFyZCAgWDUwOSBWLjMgQ2Vy
dGlmaWNhdGUgKFdlYiBhbmQgRS1tYWlsKSAgc2lnbmVkIGJ5IEMmQSB3aXRoIHRoZSAyMDQ4
IGJpdHMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQ2VydGlmaWNhdGUuIFRoaXMgQ2VydGlm
aWNhdGUgaXMgdmFsaWQgMTgwIGRheXMwEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEB
BAUAA4IBAQDg+Rj/NPFsdVmJc3BbQfe9MA7gr6Ad6Dc7zB5WiODixSk5yfwjdTjQPqva6F2+
yOzeCnNVWCOqSynjwGz7DrLgvaRmZg61mlEG4qIt9izToSmG9PtwwIo1Rb++VHukoFLFiUND
tr0uiLWXSCn5dJbKEfvAHTtDHoN5ceYeDAjJKKSM8YGRoGb+ZpN4BOOc84KrkTTB0XNFlsXv
+4zNJ6nc3T+puj/BdrJGxBBjQos/WlGUq1I4yW25NTLay1Fz2WrJvy+ECUFUnAx++Aq0HftO
gYWLn1eZ1HTeC6E9MljjDO5hFbWQTcWXAsOD/Z9SJH9cgLEr94yDQQ/RxyTl+FcqMYICGDCC
AhQCAQEwgb0wgbYxCzAJBgNVBAYTAklUMQ8wDQYDVQQIEwZNaWxhbm8xGjAYBgNVBAcTEUNp
bmlzZWxsbyBCYWxzYW1vMRAwDgYDVQQKEwdDIGFuZCBBMRkwFwYDVQQLExBDIGFuZCBBIFNl
Y3VyaXR5MSwwKgYDVQQDEyNNYXN0ZXIgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEf
MB0GCSqGSIb3DQEJARYQaW5mb0Bjb20tYW5kLmNvbQICASEwCQYFKw4DAhoFAKCBsTAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMTIxMjI5MTZaMCMG
CSqGSIb3DQEJBDEWBBSQjUmSkVfnHCpOQB7bLBX9FJY5XzBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggq
hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgF0pTbdSX5m60LJH527USgJqwXLM4eMaW9Tx
Jf8+OXyR0tMtsmFoXGrxCL63GkGX6TUWcnZ7xRFzzfhnN3xjju8SC7wrS5e2di3XKJGdSlOj
UnyIhC2KaYE4AJoCdG9R0nEWaOHZoB7SarkE/hTYfuXzvl5FkrwJTKWME90Q00IE
--------------msE945F83946DEE6CBEC8DDBDD--



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05736 for <[e-mail]>; Thu, 12 Oct 2000 03:30:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA04704; Thu, 12 Oct 2000 12:34:35 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 12 Oct 2000 12:34:35 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA26558; Thu, 12 Oct 2000 12:34:33 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA00259; Thu, 12 Oct 2000 12:34:32 +0200 (MET DST)
Date: Thu, 12 Oct 2000 12:34:32 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: The future of DVCS...
Cc: [e-mail], [e-mail], [e-mail]

> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
> 
> > Hi,
> > 
> > Over the past year or more, the question has arisen in various contexts as
> > to the status and role of the DVCS draft, especially with respect to TSP,
> > OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
> > the future.
> > 
> > DVCS precedes and, at some level, encompasses all of these other
> > protocols.  However, these protocols -- many of them targeted for the
> > standards track -- have been defined for the twin purposes of simplicity
> > and rapid implementation.  They are small and clearly defined; each one
> > tries to solve essentially one problem.  DVCS, on the other hand, is
> > intended to be general, embracing the sometimes abstract notion of the
> > validation and certification of arbitrary data.  The actual content of the
> > data (the payload) in a sense defines the function of the server (i.e., if
> > the data is a hash of something, then the server is providing a time stamp
> > function; if the data is a certificate, then the server is providing an
> > OCSP or SCVP/DPV function; if the data is a contract or legal document,
> > then the server is providing what (at least in North America) might be
> > called a notarization function; etc.).  It's not quite as loose as that,
> > but that's the basic idea.
> > 
> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also means
> that this subset is not the right direction for the long run and thus should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC. 

I think you are misunderstanding something: We are talking about putting DVCS
as experimental, and we leave it open to take subsets of functionality of
it into other protocols, i.e. to provide some additional building blocks.
 
> 
> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
> 
> > Consequently, the authors of DVCS are recommending to the chairs that this
> > specification be preserved as an Experimental RFC.  It has received some
> > discussion (both public and private) over the years, but probably not
> > sufficient to warrant progression along the standards track.  
> 
> I certainly agree that this specification has not received sufficient
> discussion to warrant progression along the standards track.

Thank you for your contributions in the past. Also for thse in this message.

> 
> > Furthermore,
> > we are aware of only a single implementation at this time, so any
> > interoperability testing is out of the question, at least at the moment.
> > But enough work has gone into this protocol that letting it expire as an
> > Internet Draft and disappear completely seems inappropriate, especially if
> > (as we suspect) this higher-layer functionality will begin to be required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.

Yes, one could write a book. why are you against an RFC? 

> 
> > We would like
> > to see the specification frozen and preserved for now; it can always be
> > re-visited later (and even re-targeted for the standards track) if the
> > need arises.
> > 
> > In light of this recommendation, further revisions to this document seem
> > unnecessary; the authors are satisfied with the text in this -07 version
> > going to "Experimental" status.
> 
> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
There are essentially just a few spelling changes. 
 
> The document covers four different services:
> 
> 1. Certification of possession of data,
> 2. Certification of claim possession of identity,
> 3. Validation of a Digitally signed document,
> 4. Validation of a public key certificate.

Have you really read the text, it says:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).
> 
> Note that, in the following comments, this services are NOT addressed in the
> same order as they are listed above.

> The second service (Certification of claim possession of identity) can
> simply be obtained using directly a Time Stamping server using the TSP
> protocol, by defining the structure of the whole message that must be hashed
> before it is presented to the TSA. So there is no need to define a new
> protocol, but instead to define a data format, which will basically be
> formed by the concatenation of some information that relates to the entity
> claiming the possession of the data (like first name, family name, home
> address, date of birth, place of birth, and any information able to identify
> unambiguously the entity claiming the possession of the data) and the data
> for which the possession is claimed. Note that there is no need to use any
> ASN.1 construct to do this. While it is recognized that this definition
> would be useful, it may be questioned whether this work should be done in
> the PKIX WG or another group.

There is no such thing as 'claim possession of identity'. It's claim
of possession of data.  

Anyway, you are defining something different. 

The difference of the defined service to time stamping is small,
what is provided is a common way to include in the dvc a reference to
the requestor and a reference to the location of the data, and this is visible in the timestamp.

The time stamp essentially becomes a statement like: 

  "We, the DVCS certify that the person identified as requestor is claiming
  to have a document available under the following URL for we he showed
  a hash at date J."

You can obviously achieve this by adding extensions to time stamping.

You are free to define any format describing 'data to be time stamped'
but this is something else IMHO.

> The first service (Certification of possession of data) is defined as being
> similar to the previous one, except that the full message (e.g. Megabytes)
> is transferred instead of a hash. This is not a desirable feature since the
> performance of such a service would be quite low and because the server
> would be able to know the content of the message, which is not desirable for
> several reasons: privacy reasons or when the content is related to IPR.

On the contrary. The server is a notary, archive server, legal depository or
whatever you want to call it. This is a desirable service, there is a trust
relationship between the notary and the client, the transaction is
be protected by ssl or other means.

> 
> The last (fourth) service (Validation of a public key certificate) is
> closely related to remote path processing, a topic that is being addressed
> by two other specifications. There is still the need to have a single
> protocol to cover that functionality since the PKIX WG cannot afford
> multiple protocols for the same purpose.

DVCS is a different protocol than the OCSP++. I refer to a comment from
Michael Myers, who gave a good caracteristics. The protocols are complementary.  

> 
> The third service (Validation of a Digitally Signed Document) is more
> ambitious than the previous service, since every detail of the format of the
> signature itself will have to be known by the server. This goes behind the
> mathematical correctness of all digital signatures, since it is necessary to
> unambiguously know both which certificate has been used to sign the document
> and at which time. 

The client completely delegates the acceptablity of the document to
a server. Actually, it is not even necessary that the document is a signed
document, 

There is the possibility that no validation of a signature occurs
at all, for example if you validate a dvc 30 years ago. The server has at
least two possibilities, verifying signatures, or looking up an archive
of all dvcs issued. This possibility transforms a chain of trust elements
(in time) into a web. A chain can easily break, a web is much more difficult
to break. 
 
> The validation should not be necessarily made against a single root key.
No one says that. The client may have no idea about roots, trust points or whatever,
it is the server that has that knowledge. A client can also
add certs to the signed document which may be taken as hints by the server.  

> When multiple roots are considered, Certificate Policy (CP) constraints and
> naming constraints are fairly important. They should be able to be defined
> by the requester. When revocation status is looked for, there are cases when
> either CRLs or OCSP responses are adequate or only OCSP responses are
> acceptable. The requester should be able to express his wishes.

The point is to have the requestor as a dumb entity, it is the server who
knows what do do in the context of the application expressed
by a policy identifier. The whole trust management occurs at the server side. 

> 
> The document mentions the possibility to verify all signatures attached to
> the document. This level of complexity would mandate a rather complex
> definition of all the parameters to do this. This appear to be a much longer
> term goal.
The protocol only defined a transaction protocol and a certificate format.
The way how the server is implemented is not specified, only the result, the
dvc should contain a complete list of all actions that had been performed.

> Finally there would be two options: either the server testifies that the
> Digitally Signed Document is well signed and simply provides a signed yes/no
> answer, or does more by providing in addition the proof that led to that
> decision.

Both options are provided. A simple yes/no answer may be given for some
application contexts, but in general it is the idea that a dvc contains
not only a decision, but all elements that have been contributed, in
particular if they cannot easily be reproduced. 

> 
> Conclusion
 
> The first two protocols supporting both "Certification of possession of
> data" and "Certification of claim possession of identity" should not be
> defined. A format describing of the document to be time-stamped should be
> defined instead of providing the second service currently called
> "Certification of claim possession of identity".
Possession of data is a useful service. 

I don't accept the 'INSTEAD of providing the'. You can have both since
these are different things. 

> The third protocol supporting "Validation of a Digitally signed document"
> should be restricted to the verification of a single signature. In order to
> simplify the protocol, the parameters to be presented should be restricted
> to the identification of the "Validation policy" to be used (using an OID to
> refer to that policy) and of the signed message. Note that the Validation
> Policy and a certificate policy are two concepts that should not be
> confused. However more information than the information that was presented
> will usually be needed to be returned, in order to get long term validity of
> the signature, in particular a Time Stamp, a certification path and
> certificate status for every element from that certification path. It is
> proposed to wait until the definition of the RPP service ("Remote Path
> Processing") is stabilized before addressing this level of complexity.
All what you ask for is provided. The requestPolicy defines a validation policy.
The DVC itself contains a time stamp, either provided by itself or by
an external service. The certification path, the certification status, and
all other kinds of OCSP repsonses, crls, dvcs are returned.  

> The last protocol supporting "Validation of a public key certificate" should
> be addressed under the current discussion related to "Remote Path
> Processing" (RPP), so that the WG ends up with a single protocol.
PKIX today says that the result of a cert validation is a verifiable
cert chain, the fact that the exact algorithm for path determination, and
the formats of lookups etc is not defined has not stopped X.509 or 2459.
  
> 
> With the arguments raised above, I am *not* supportive to make this
> specification an experimental RFC.
So be it. 

> 
> Denis
Peter


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00119 for <[e-mail]>; Thu, 12 Oct 2000 02:26:38 -0700 (PDT)
Received: by balinese.baltimore.ie; id KAA29197; Thu, 12 Oct 2000 10:31:15 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma029028; Thu, 12 Oct 00 10:30:35 +0100
Received: from baltimore.ie (wks179-0.ie.baltimore.com [10.153.0.179]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA05947; Thu, 12 Oct 2000 10:31:36 +0100
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 10:30:30 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id KAA05947
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA00120

Tom,

I think you're misquoting the draft. basdCertificateID is the SHOULD for holder
when PKCs are used for authentiation. When entityName is used, the text tells
you how it should compare to the subject and/or subjectAltName from the PKC. It
does not say that the PKC must use any particular form of subject naming.

There is no reference to PI since right now that's a -00 draft with who know
what future (bright, I'm sure:-) and the AC profile is in IETF wide last call. 

Stephen.

[e-mail] wrote:
> 
>      Russ:
> 
>      On one subject which is connected to what Polar brought up, I am
> inclined to think that he is right.  In the AC509Prof draft, section 4.2.2
> states that for PKC-based authentication the entityName MUST be the same as
> the PKC subject field unless that field is empty.  Why should it be
> mandatory to prefer the subject DN to either permanent ID's or e-mail
> addresses, both of which identify individuals in a globally unique way?
> Name collisions are more likely in the DN space than in either of the other
> two, except for PI's with a default assignment authority, and PI's of that
> sort should be forbidden as entityName's.  This does not imply that most of
> the options within GeneralName are appropriate as entityName's, as I don't
> think they are.
> 
>           Tom Gindin
> 
> Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM
> 
> To:   Polar Humenn <[e-mail]>
> cc:   Al Arsenault <[e-mail]>, Stephen Farrell
>       <[e-mail]>, Patrik Fältström <[e-mail]>,
>       [e-mail], [e-mail], Thumrongsak Kosiyatrakul
>       <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
>       Older <[e-mail]>
> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
>       andProxies
> 
> Polar:
> 
> > > Okay, I think I finally figured out what Polar is getting at here, but
> > > I'm not sure what the fix is.  Let me try to illustrate with an
> example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both
> equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC
> can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate is
> >unreasonable. Can something like this be mandated in this profile? I don't
> >see how. I only see that in specific protocols. Or am I wrong?
> 
> PKCs bind a public key to an identity.
> 
> ACs bind attributes to an identity.
> 
> Authentication, which includes validating the PKC certification path and
> having the remote party perform some operation that involves the private
> key associated with the identity.  Without authentication of the identity,
> who cares what attributes are associated with it?
> 
> Russ

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29080 for <[e-mail]>; Thu, 12 Oct 2000 01:49:10 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA03629; Thu, 12 Oct 2000 10:53:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 12 Oct 2000 10:53:39 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA26352; Thu, 12 Oct 2000 10:53:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA00228; Thu, 12 Oct 2000 10:53:36 +0200 (MET DST)
Date: Thu, 12 Oct 2000 10:53:36 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: The future of DVCS...
Cc: [e-mail]

> 
> Carlisle,
> 
> I think your characterization of DVCS vs. OCSP and SCVP is very 
> accurate and I would be very comfortable with moving it to the 
> experimental track. I would like to hear an affirmation from Peter 
> Sylvester on this.

This had been discussed among the author's and we all seem
to be in violent agreement.  



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26907 for <[e-mail]>; Thu, 12 Oct 2000 00:50:47 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id SAA18297 for <[e-mail]>; Thu, 12 Oct 2000 18:02:31 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LJZC>; Thu, 12 Oct 2000 18:54:07 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Subject: Delegated Path Validation draft.
Date: Thu, 12 Oct 2000 18:53:58 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

A couple of comments.

Should we require the id-pkix-ocsp-valid-req extension to be marked as
critical?

If neither DVPOptions::initialPolicySet nor DVPOptions::trustPoints is
included in the request, the draft says "SHALL omit both optional fields".
This is not clear. Should we include an empty sequence into extension? or
probably a zero-lenght OCTET STRING value?

What should the server do if the both initialPolicySet and trustPoints are
missing? I think the draft should say something about it.

Michael


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25502 for <[e-mail]>; Thu, 12 Oct 2000 00:21:31 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA19000; Thu, 12 Oct 2000 09:31:26 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA10180; Thu, 12 Oct 2000 09:25:32 +0200
Message-ID: <[e-mail]>
Date: Thu, 12 Oct 2000 09:25:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: The future of DVCS...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Carlisle,

Thank you for posting this E-mail. As explained hereafter, while I agree
with many of your arguments, I do not share your conclusion.

> Hi,
> 
> Over the past year or more, the question has arisen in various contexts as
> to the status and role of the DVCS draft, especially with respect to TSP,
> OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
> the future.
> 
> DVCS precedes and, at some level, encompasses all of these other
> protocols.  However, these protocols -- many of them targeted for the
> standards track -- have been defined for the twin purposes of simplicity
> and rapid implementation.  They are small and clearly defined; each one
> tries to solve essentially one problem.  DVCS, on the other hand, is
> intended to be general, embracing the sometimes abstract notion of the
> validation and certification of arbitrary data.  The actual content of the
> data (the payload) in a sense defines the function of the server (i.e., if
> the data is a hash of something, then the server is providing a time stamp
> function; if the data is a certificate, then the server is providing an
> OCSP or SCVP/DPV function; if the data is a contract or legal document,
> then the server is providing what (at least in North America) might be
> called a notarization function; etc.).  It's not quite as loose as that,
> but that's the basic idea.
> 
> In discussing this protocol with the other authors and with various
> members of the community, I sense "rough consensus" on two things.
> Firstly, it makes sense to allow the more clearly-defined subsets of the
> DVCS functionality to be handled by these other protocols (TSP, OCSP,
> etc.) since they are relatively well-understood and implementations are
> already either completed or underway.  

I agree that more clearly-defined subsets of the DVCS functionality should
be handled by these other protocols (TSP, OCSP, etc.) .. but this also means
that this subset is not the right direction for the long run and thus should
be deprecated. For that reason, this subset should *not* be placed in an
experimental RFC.  

> Secondly, most real-world
> environments are not yet ready to incorporate notarization functions for
> other data formats.  This higher-layer purpose of DVCS is perhaps too
> early as a concept to engage serious review and debate within the wider
> PKIX group right now.

I also agree. However, this is not an argument for saving this material in
an experimental RFC either.

> Consequently, the authors of DVCS are recommending to the chairs that this
> specification be preserved as an Experimental RFC.  It has received some
> discussion (both public and private) over the years, but probably not
> sufficient to warrant progression along the standards track.  

I certainly agree that this specification has not received sufficient
discussion to warrant progression along the standards track.

> Furthermore,
> we are aware of only a single implementation at this time, so any
> interoperability testing is out of the question, at least at the moment.
> But enough work has gone into this protocol that letting it expire as an
> Internet Draft and disappear completely seems inappropriate, especially if
> (as we suspect) this higher-layer functionality will begin to be required
> in PKI environments in the one- to three-year time frame.  

The specification can certainly be saved without being transformed as an
experimental RFC.

> We would like
> to see the specification frozen and preserved for now; it can always be
> re-visited later (and even re-targeted for the standards track) if the
> need arises.
> 
> In light of this recommendation, further revisions to this document seem
> unnecessary; the authors are satisfied with the text in this -07 version
> going to "Experimental" status.

Hereafter are some more technical comments which related to version 06 (I
have not read the recently posted version 07)

The document covers four different services:

1. Certification of possession of data,
2. Certification of claim possession of identity,
3. Validation of a Digitally signed document,
4. Validation of a public key certificate.

Note that, in the following comments, this services are NOT addressed in the
same order as they are listed above.

The second service (Certification of claim possession of identity) can
simply be obtained using directly a Time Stamping server using the TSP
protocol, by defining the structure of the whole message that must be hashed
before it is presented to the TSA. So there is no need to define a new
protocol, but instead to define a data format, which will basically be
formed by the concatenation of some information that relates to the entity
claiming the possession of the data (like first name, family name, home
address, date of birth, place of birth, and any information able to identify
unambiguously the entity claiming the possession of the data) and the data
for which the possession is claimed. Note that there is no need to use any
ASN.1 construct to do this. While it is recognized that this definition
would be useful, it may be questioned whether this work should be done in
the PKIX WG or another group.

The first service (Certification of possession of data) is defined as being
similar to the previous one, except that the full message (e.g. Megabytes)
is transferred instead of a hash. This is not a desirable feature since the
performance of such a service would be quite low and because the server
would be able to know the content of the message, which is not desirable for
several reasons: privacy reasons or when the content is related to IPR.

The last (fourth) service (Validation of a public key certificate) is
closely related to remote path processing, a topic that is being addressed
by two other specifications. There is still the need to have a single
protocol to cover that functionality since the PKIX WG cannot afford
multiple protocols for the same purpose.

The third service (Validation of a Digitally Signed Document) is more
ambitious than the previous service, since every detail of the format of the
signature itself will have to be known by the server. This goes behind the
mathematical correctness of all digital signatures, since it is necessary to
unambiguously know both which certificate has been used to sign the document
and at which time. 

The validation should not be necessarily made against a single root key.
When multiple roots are considered, Certificate Policy (CP) constraints and
naming constraints are fairly important. They should be able to be defined
by the requester. When revocation status is looked for, there are cases when
either CRLs or OCSP responses are adequate or only OCSP responses are
acceptable. The requester should be able to express his wishes.

The document mentions the possibility to verify all signatures attached to
the document. This level of complexity would mandate a rather complex
definition of all the parameters to do this. This appear to be a much longer
term goal.

Finally there would be two options: either the server testifies that the
Digitally Signed Document is well signed and simply provides a signed yes/no
answer, or does more by providing in addition the proof that led to that
decision.

Conclusion

The first two protocols supporting both "Certification of possession of
data" and "Certification of claim possession of identity" should not be
defined. A format describing of the document to be time-stamped should be
defined instead of providing the second service currently called
"Certification of claim possession of identity".

The third protocol supporting "Validation of a Digitally signed document"
should be restricted to the verification of a single signature. In order to
simplify the protocol, the parameters to be presented should be restricted
to the identification of the "Validation policy" to be used (using an OID to
refer to that policy) and of the signed message. Note that the Validation
Policy and a certificate policy are two concepts that should not be
confused. However more information than the information that was presented
will usually be needed to be returned, in order to get long term validity of
the signature, in particular a Time Stamp, a certification path and
certificate status for every element from that certification path. It is
proposed to wait until the definition of the RPP service ("Remote Path
Processing") is stabilized before addressing this level of complexity.

The last protocol supporting "Validation of a public key certificate" should
be addressed under the current discussion related to "Remote Path
Processing" (RPP), so that the WG ends up with a single protocol.

With the arguments raised above, I am *not* supportive to make this
specification an experimental RFC.

Denis

 
> Steve, Tim:  any comments or alternate suggestions?
> 
> Carlisle.
> 
>      ----------
>      From:   [e-mail][SMTP:[e-mail]]
>      Reply To:       [e-mail]
>      Sent:   Friday, October 06, 2000 6:31 AM
>      Cc:     [e-mail]
>      Subject:        I-D ACTION:draft-ietf-pkix-dcs-07.txt
> 
>      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
>      Data
>                                Validation and Certification Server
>      Protocols
>              Author(s)       : C. Adams, P. Sylvester, M. Zolotarev,
>                                R. Zuccherato
>              Filename        : draft-ietf-pkix-dcs-07.txt
>              Pages           : 48
>              Date            : 05-Oct-00
> 
>      This document describes a general Data Validation and Certification
>      Server (DVCS) and the protocols to be used when communicating with
>      it.  The Data Validation and Certification Server is a Trusted Third
>      Party (TTP) that can be used as one component in building reliable
>      non-repudiation services (see [ISONR]).
>      Useful Data Validation and Certification Server responsibilities in a
> 
>      PKI are to assert the validity of signed documents, public key
>      certificates, and the possession or existence of data.


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25060 for <[e-mail]>; Thu, 12 Oct 2000 00:14:06 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA18213 for <[e-mail]>; Thu, 12 Oct 2000 17:25:50 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LJYQ>; Thu, 12 Oct 2000 18:17:26 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Subject: FW: Delegated Path Discovery draft
Date: Thu, 12 Oct 2000 18:17:15 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

A scenario:

Client has 2 certificates (C1 and C2). C1 has a single path, C2 has 2
possible paths.

Step 1. Request. Contains C1 and C2. RetryReference void.
	Response. DPDOCSPResponse contains 2 PathResponses. Each has
retryReference =1.
	OCSPResponse::responseStatus (0).

Step 2. Request. The same 2 certificates. RetryReference=1.
	Response. We know that there is no more path for C1. So that the
OCSPResponse::responseStatus should be noMoreData(7). 
	However, there is another path for C2. 
	So that OCSPResponse::responseStatus should be 0.

Because the OCSPResponse::responseStatus is global, applying to all elements
of the DPDOCSPResponse (i.e. to each of the PathResponse), I don't see how
we can distinguish the status in a situation like one above.

Regards
Michael


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13510 for <[e-mail]>; Wed, 11 Oct 2000 19:56:49 -0700 (PDT)
Received: from [128.33.238.45] (TC045.BBN.COM [128.33.238.45]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id XAA22318; Wed, 11 Oct 2000 23:01:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220807b60aca65f305@[128.33.238.81]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 11 Oct 2000 22:46:52 -0400
To: Carlisle Adams <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The future of DVCS...
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Carlisle,

I think your characterization of DVCS vs. OCSP and SCVP is very 
accurate and I would be very comfortable with moving it to the 
experimental track. I would like to hear an affirmation from Peter 
Sylvester on this.

Steve


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07890 for <[e-mail]>; Wed, 11 Oct 2000 14:43:33 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA26395; Wed, 11 Oct 2000 14:44:10 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <42WJRFLC>; Wed, 11 Oct 2000 14:47:34 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Carlisle Adams <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: The future of DVCS...
Date: Wed, 11 Oct 2000 14:47:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C033CC.DC056560"

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_01C033CC.DC056560
Content-Type: text/plain;
	charset="iso-8859-1"

Chairs:
 
 I offer a second to Carlisle's proposal that the DVCS work effort should be
maintained as proposed.
 
Mike

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Wednesday, October 11, 2000 12:40 PM
To: '[e-mail]'; '[e-mail]'
Cc: [e-mail]
Subject: The future of DVCS...



Hi, 

Over the past year or more, the question has arisen in various contexts as
to the status and role of the DVCS draft, especially with respect to TSP,
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
the future.

DVCS precedes and, at some level, encompasses all of these other protocols.
However, these protocols -- many of them targeted for the standards track --
have been defined for the twin purposes of simplicity and rapid
implementation.  They are small and clearly defined; each one tries to solve
essentially one problem.  DVCS, on the other hand, is intended to be
general, embracing the sometimes abstract notion of the validation and
certification of arbitrary data.  The actual content of the data (the
payload) in a sense defines the function of the server (i.e., if the data is
a hash of something, then the server is providing a time stamp function; if
the data is a certificate, then the server is providing an OCSP or SCVP/DPV
function; if the data is a contract or legal document, then the server is
providing what (at least in North America) might be called a notarization
function; etc.).  It's not quite as loose as that, but that's the basic
idea.

In discussing this protocol with the other authors and with various members
of the community, I sense "rough consensus" on two things.  Firstly, it
makes sense to allow the more clearly-defined subsets of the DVCS
functionality to be handled by these other protocols (TSP, OCSP, etc.) since
they are relatively well-understood and implementations are already either
completed or underway.  Secondly, most real-world environments are not yet
ready to incorporate notarization functions for other data formats.  This
higher-layer purpose of DVCS is perhaps too early as a concept to engage
serious review and debate within the wider PKIX group right now.

Consequently, the authors of DVCS are recommending to the chairs that this
specification be preserved as an Experimental RFC.  It has received some
discussion (both public and private) over the years, but probably not
sufficient to warrant progression along the standards track.  Furthermore,
we are aware of only a single implementation at this time, so any
interoperability testing is out of the question, at least at the moment.
But enough work has gone into this protocol that letting it expire as an
Internet Draft and disappear completely seems inappropriate, especially if
(as we suspect) this higher-layer functionality will begin to be required in
PKI environments in the one- to three-year time frame.  We would like to see
the specification frozen and preserved for now; it can always be re-visited
later (and even re-targeted for the standards track) if the need arises.

In light of this recommendation, further revisions to this document seem
unnecessary; the authors are satisfied with the text in this -07 version
going to "Experimental" status.

Steve, Tim:  any comments or alternate suggestions? 

Carlisle. 


	---------- 
From:   [e-mail][SMTP:[e-mail]] 
Reply To:       [e-mail] 
Sent:   Friday, October 06, 2000 6:31 AM 
Cc:     [e-mail] 
Subject:        I-D ACTION:draft-ietf-pkix-dcs-07.txt 

	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
Data 
                          Validation and Certification Server Protocols 
        Author(s)       : C. Adams, P. Sylvester, M. Zolotarev, 
                          R. Zuccherato 
        Filename        : draft-ietf-pkix-dcs-07.txt 
        Pages           : 48 
        Date            : 05-Oct-00 
        
This document describes a general Data Validation and Certification 
Server (DVCS) and the protocols to be used when communicating with 
it.  The Data Validation and Certification Server is a Trusted Third 
Party (TTP) that can be used as one component in building reliable 
non-repudiation services (see [ISONR]). 
Useful Data Validation and Certification Server responsibilities in a 
PKI are to assert the validity of signed documents, public key 
certificates, and the possession or existence of data. 


------_=_NextPart_001_01C033CC.DC056560
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">
<TITLE>The future of DVCS...</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>Chairs:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>&nbsp;I offer a second to Carlisle's proposal that the 
DVCS work effort should be maintained as proposed.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>Mike</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Carlisle Adams 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, October 11, 
  2000 12:40 PM<BR><B>To:</B> '[e-mail]'; '[e-mail]'<BR><B>Cc:</B> 
  [e-mail]<BR><B>Subject:</B> The future of 
DVCS...<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Hi,</FONT> </P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Over the past year or 
  more, the question has arisen in various contexts as to the status and role of 
  the DVCS draft, especially with respect to TSP, OCSP, SCVP, DPV, DPD, and 
  whatever other variations might be incarnated in the future.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>DVCS precedes and, at 
  some level, encompasses all of these other protocols.&nbsp; However, these 
  protocols -- many of them targeted for the standards track -- have been 
  defined for the twin purposes of simplicity and rapid implementation.&nbsp; 
  They are small and clearly defined; each one tries to solve essentially one 
  problem.&nbsp; DVCS, on the other hand, is intended to be general, embracing 
  the sometimes abstract notion of the validation and certification of arbitrary 
  data.&nbsp; The actual content of the data (the payload) in a sense defines 
  the function of the server (i.e., if the data is a hash of something, then the 
  server is providing a time stamp function; if the data is a certificate, then 
  the server is providing an OCSP or SCVP/DPV function; if the data is a 
  contract or legal document, then the server is providing what (at least in 
  North America) might be called a notarization function; etc.).&nbsp; It's not 
  quite as loose as that, but that's the basic idea.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>In discussing this 
  protocol with the other authors and with various members of the community, I 
  sense "rough consensus" on two things.&nbsp; Firstly, it makes sense to allow 
  the more clearly-defined subsets of the DVCS functionality to be handled by 
  these other protocols (TSP, OCSP, etc.) since they are relatively 
  well-understood and implementations are already either completed or 
  underway.&nbsp; Secondly, most real-world environments are not yet ready to 
  incorporate notarization functions for other data formats.&nbsp; This 
  higher-layer purpose of DVCS is perhaps too early as a concept to engage 
  serious review and debate within the wider PKIX group right now.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Consequently, the authors 
  of DVCS are recommending to the chairs that this specification be preserved as 
  an Experimental RFC.&nbsp; It has received some discussion (both public and 
  private) over the years, but probably not sufficient to warrant progression 
  along the standards track.&nbsp; Furthermore, we are aware of only a single 
  implementation at this time, so any interoperability testing is out of the 
  question, at least at the moment.&nbsp; But enough work has gone into this 
  protocol that letting it expire as an Internet Draft and disappear completely 
  seems inappropriate, especially if (as we suspect) this higher-layer 
  functionality will begin to be required in PKI environments in the one- to 
  three-year time frame.&nbsp; We would like to see the specification frozen and 
  preserved for now; it can always be re-visited later (and even re-targeted for 
  the standards track) if the need arises.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>In light of this 
  recommendation, further revisions to this document seem unnecessary; the 
  authors are satisfied with the text in this -07 version going to 
  "Experimental" status.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Steve, Tim:&nbsp; any 
  comments or alternate suggestions?</FONT> </P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Carlisle.</FONT> </P><BR>
  <UL>
    <P><FONT face="MS Sans Serif" size=2>----------</FONT> <BR><B><FONT 
    face="MS Sans Serif" size=2>From:</FONT></B> &nbsp; <FONT 
    face="MS Sans Serif" 
    size=2>[e-mail][SMTP:[e-mail]]</FONT> 
    <BR><B><FONT face="MS Sans Serif" size=2>Reply To:</FONT></B> 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face="MS Sans Serif" 
    size=2>[e-mail]</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Sent:</FONT></B> &nbsp; <FONT face="MS Sans Serif" size=2>Friday, 
    October 06, 2000 6:31 AM</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Cc:</FONT></B> &nbsp;&nbsp;&nbsp; <FONT face="MS Sans Serif" 
    size=2>[e-mail]</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Subject:</FONT></B> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    face="MS Sans Serif" size=2>I-D ACTION:draft-ietf-pkix-dcs-07.txt</FONT> 
</P>
    <P><FONT face=Arial size=2>A New Internet-Draft is available from the 
    on-line Internet-Drafts directories.</FONT> <BR><FONT face=Arial size=2>This 
    draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
    of the IETF.</FONT> </P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    Internet X.509 Public Key Infrastructure Data </FONT><BR><FONT face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Validation and Certification Server Protocols</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : C. Adams, P. 
    Sylvester, M. Zolotarev, </FONT><BR><FONT face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    R. Zuccherato</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    face=Arial size=2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    draft-ietf-pkix-dcs-07.txt</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    48</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    05-Oct-00</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT 
    face=Arial size=2>This document describes a general Data Validation and 
    Certification</FONT> <BR><FONT face=Arial size=2>Server (DVCS) and the 
    protocols to be used when communicating with</FONT> <BR><FONT face=Arial 
    size=2>it.&nbsp; The Data Validation and Certification Server is a Trusted 
    Third</FONT> <BR><FONT face=Arial size=2>Party (TTP) that can be used as one 
    component in building reliable</FONT> <BR><FONT face=Arial 
    size=2>non-repudiation services (see [ISONR]).</FONT> <BR><FONT face=Arial 
    size=2>Useful Data Validation and Certification Server responsibilities in 
    a</FONT> <BR><FONT face=Arial size=2>PKI are to assert the validity of 
    signed documents, public key</FONT> <BR><FONT face=Arial 
    size=2>certificates, and the possession or existence of data.</FONT> 
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C033CC.DC056560--


Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07635 for <[e-mail]>; Wed, 11 Oct 2000 14:37:18 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA202786; Wed, 11 Oct 2000 17:41:25 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id RAA63132; Wed, 11 Oct 2000 17:41:12 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256975.00771E92 ; Wed, 11 Oct 2000 17:41:06 -0400
X-Lotus-FromDomain: IBMUS
To: Russ Housley <[e-mail]>
cc: Polar Humenn <[e-mail]>, Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 17:41:09 -0400
Subject: AttributeCertificates: Why is the holder DN preferred?
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA07636

     Russ:

     On one subject which is connected to what Polar brought up, I am
inclined to think that he is right.  In the AC509Prof draft, section 4.2.2
states that for PKC-based authentication the entityName MUST be the same as
the PKC subject field unless that field is empty.  Why should it be
mandatory to prefer the subject DN to either permanent ID's or e-mail
addresses, both of which identify individuals in a globally unique way?
Name collisions are more likely in the DN space than in either of the other
two, except for PI's with a default assignment authority, and PI's of that
sort should be forbidden as entityName's.  This does not imply that most of
the options within GeneralName are appropriate as entityName's, as I don't
think they are.

          Tom Gindin


Russ Housley <[e-mail]> on 10/11/2000 01:50:42 PM

To:   Polar Humenn <[e-mail]>
cc:   Al Arsenault <[e-mail]>, Stephen Farrell
      <[e-mail]>, Patrik Fältström <[e-mail]>,
      [e-mail], [e-mail], Thumrongsak Kosiyatrakul
      <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan
      Older <[e-mail]>
Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
      andProxies



Polar:

> > Okay, I think I finally figured out what Polar is getting at here, but
> > I'm not sure what the fix is.  Let me try to illustrate with an
example.
> >
> > (We'll be picking on Stephen a little bit in this; nothing personal
> > intended; apologies for any offense.  :-)
> >
> > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > Technologies, OU=Public CAs, CN=The CA".
> > That CA has a self signed certificate with subject and issuer both
equal
> > to the DN above.
> >
> > Now, there is an end-user certificate issued under that CA.  The issuer
> > field of that certificate will be the DN above; the subject field is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > CN=Stephen".
> >
> > The serial number field will be something like "4434".
> >
> > Now, an attribute authority has issued our friend Stephen an AC
> > consistent with the proposed profile.  The "Holder" field in that AC
can
> > be one of three things, according to the proposed profile:
> >
> >       - it can be the issuer and serial number of the base PKC; that is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> >
> >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> >
> >       - it can be an ObjectDigest - for which the I-D does not require
> > support.
>
>I think the ObjectDigest is truly the only way to go. However, it still
>has problems. The object that is talked about must be able to be recalled
>and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>delivered with the Holder's Public Key Certificate.
>
>I don't believe that requiring the delivery of the Holders certificate is
>unreasonable. Can something like this be mandated in this profile? I don't
>see how. I only see that in specific protocols. Or am I wrong?

PKCs bind a public key to an identity.

ACs bind attributes to an identity.

Authentication, which includes validating the PKC certification path and
having the remote party perform some operation that involves the private
key associated with the identity.  Without authentication of the identity,
who cares what attributes are associated with it?

Russ








Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05221 for <[e-mail]>; Wed, 11 Oct 2000 12:58:43 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id PAA30245; Wed, 11 Oct 2000 15:48:23 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 11 Oct 2000 15:48:22 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Russ Housley <[e-mail]>
cc: Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, =?X-UNKNOWN?Q?Patrik__F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,  Targets andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Russ,

On Wed, 11 Oct 2000, Russ Housley wrote:

> Polar:
> 
> > > Okay, I think I finally figured out what Polar is getting at here, but
> > > I'm not sure what the fix is.  Let me try to illustrate with an example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate is
> >unreasonable. Can something like this be mandated in this profile? I don't
> >see how. I only see that in specific protocols. Or am I wrong?
> 
> PKCs bind a public key to an identity.

It is true that PKC's bind a public key to an identity, but that identity
is fully qualified by its subject DN, it's issuer DN, it's issuer's
issuer's DN, and so on all the way up to a root CA. This full identity is
all tied together all the way up to the root by chaining of signatures.

> ACs bind attributes to an identity.

The AC's bind attributes only to the least significant component of an
identity, not the entire identity. The rest of it, i.e. he most
significant part, is THROWN AWAY.

> Authentication, which includes validating the PKC certification path and 
> having the remote party perform some operation that involves the private 
> key associated with the identity.  Without authentication of the identity, 
> who cares what attributes are associated with it?

True, but in some cases you may infact be removed from the authentication.
Take a case where you have a webserver that uses SSL. The
authentication information of a user is processed on the webserver. Now
the web server may want to access some database server on the
authenticated user's behalf. The web server cannot authenticate as the
user. There are several ways to do this. One way is for the name of the
authenticated entity to be to propagated. So, on the database server, the
name who the webserver is acting on behalf is transmitted to the database
server. The database trusts the webserver in this matter. 

The question is what identifying information is good enough? Add an AC in
there or and AA to pull from, you have to emphatically know what that name
is refering to and if they are the same. A simple DN will not work in the
widely scaled interoperable case.

Cheers,
-Polar

> Russ
> 
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04433 for <[e-mail]>; Wed, 11 Oct 2000 12:36:28 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <T6Z8BP9Z>; Wed, 11 Oct 2000 15:40:33 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: The future of DVCS...
Date: Wed, 11 Oct 2000 15:40:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C033BB.1A17EB50"

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_01C033BB.1A17EB50
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Over the past year or more, the question has arisen in various contexts as
to the status and role of the DVCS draft, especially with respect to TSP,
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
the future.

DVCS precedes and, at some level, encompasses all of these other protocols.
However, these protocols -- many of them targeted for the standards track --
have been defined for the twin purposes of simplicity and rapid
implementation.  They are small and clearly defined; each one tries to solve
essentially one problem.  DVCS, on the other hand, is intended to be
general, embracing the sometimes abstract notion of the validation and
certification of arbitrary data.  The actual content of the data (the
payload) in a sense defines the function of the server (i.e., if the data is
a hash of something, then the server is providing a time stamp function; if
the data is a certificate, then the server is providing an OCSP or SCVP/DPV
function; if the data is a contract or legal document, then the server is
providing what (at least in North America) might be called a notarization
function; etc.).  It's not quite as loose as that, but that's the basic
idea.

In discussing this protocol with the other authors and with various members
of the community, I sense "rough consensus" on two things.  Firstly, it
makes sense to allow the more clearly-defined subsets of the DVCS
functionality to be handled by these other protocols (TSP, OCSP, etc.) since
they are relatively well-understood and implementations are already either
completed or underway.  Secondly, most real-world environments are not yet
ready to incorporate notarization functions for other data formats.  This
higher-layer purpose of DVCS is perhaps too early as a concept to engage
serious review and debate within the wider PKIX group right now.

Consequently, the authors of DVCS are recommending to the chairs that this
specification be preserved as an Experimental RFC.  It has received some
discussion (both public and private) over the years, but probably not
sufficient to warrant progression along the standards track.  Furthermore,
we are aware of only a single implementation at this time, so any
interoperability testing is out of the question, at least at the moment.
But enough work has gone into this protocol that letting it expire as an
Internet Draft and disappear completely seems inappropriate, especially if
(as we suspect) this higher-layer functionality will begin to be required in
PKI environments in the one- to three-year time frame.  We would like to see
the specification frozen and preserved for now; it can always be re-visited
later (and even re-targeted for the standards track) if the need arises.

In light of this recommendation, further revisions to this document seem
unnecessary; the authors are satisfied with the text in this -07 version
going to "Experimental" status.

Steve, Tim:  any comments or alternate suggestions?

Carlisle.


> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Friday, October 06, 2000 6:31 AM
> Cc: 	[e-mail]
> Subject: 	I-D ACTION:draft-ietf-pkix-dcs-07.txt
> 
> 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 Data 
>                           Validation and Certification Server Protocols
> 	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev, 
>                           R. Zuccherato
> 	Filename	: draft-ietf-pkix-dcs-07.txt
> 	Pages		: 48
> 	Date		: 05-Oct-00
> 	
> This document describes a general Data Validation and Certification
> Server (DVCS) and the protocols to be used when communicating with
> it.  The Data Validation and Certification Server is a Trusted Third
> Party (TTP) that can be used as one component in building reliable
> non-repudiation services (see [ISONR]).
> Useful Data Validation and Certification Server responsibilities in a
> PKI are to assert the validity of signed documents, public key
> certificates, and the possession or existence of data.
> 

------_=_NextPart_001_01C033BB.1A17EB50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>The future of DVCS...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Over the =
past year or more, the question has arisen in various contexts as to =
the status and role of the DVCS draft, especially with respect to TSP, =
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated =
in the future.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">DVCS =
precedes and, at some level, encompasses all of these other =
protocols.&nbsp; However, these protocols -- many of them targeted for =
the standards track -- have been defined for the twin purposes of =
simplicity and rapid implementation.&nbsp; They are small and clearly =
defined; each one tries to solve essentially one problem.&nbsp; DVCS, =
on the other hand, is intended to be general, embracing the sometimes =
abstract notion of the validation and certification of arbitrary =
data.&nbsp; The actual content of the data (the payload) in a sense =
defines the function of the server (i.e., if the data is a hash of =
something, then the server is providing a time stamp function; if the =
data is a certificate, then the server is providing an OCSP or SCVP/DPV =
function; if the data is a contract or legal document, then the server =
is providing what (at least in North America) might be called a =
notarization function; etc.).&nbsp; It's not quite as loose as that, =
but that's the basic idea.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In =
discussing this protocol with the other authors and with various =
members of the community, I sense &quot;rough consensus&quot; on two =
things.&nbsp; Firstly, it makes sense to allow the more clearly-defined =
subsets of the DVCS functionality to be handled by these other =
protocols (TSP, OCSP, etc.) since they are relatively well-understood =
and implementations are already either completed or underway.&nbsp; =
Secondly, most real-world environments are not yet ready to incorporate =
notarization functions for other data formats.&nbsp; This higher-layer =
purpose of DVCS is perhaps too early as a concept to engage serious =
review and debate within the wider PKIX group right now.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Consequently, the authors of DVCS are recommending to the chairs =
that this specification be preserved as an Experimental RFC.&nbsp; It =
has received some discussion (both public and private) over the years, =
but probably not sufficient to warrant progression along the standards =
track.&nbsp; Furthermore, we are aware of only a single implementation =
at this time, so any interoperability testing is out of the question, =
at least at the moment.&nbsp; But enough work has gone into this =
protocol that letting it expire as an Internet Draft and disappear =
completely seems inappropriate, especially if (as we suspect) this =
higher-layer functionality will begin to be required in PKI =
environments in the one- to three-year time frame.&nbsp; We would like =
to see the specification frozen and preserved for now; it can always be =
re-visited later (and even re-targeted for the standards track) if the =
need arises.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In light =
of this recommendation, further revisions to this document seem =
unnecessary; the authors are satisfied with the text in this -07 =
version going to &quot;Experimental&quot; status.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Steve, =
Tim:&nbsp; any comments or alternate suggestions?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail][SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 06, 2000 6:31 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">I-D ACTION:draft-ietf-pkix-dcs-07.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A New Internet-Draft is available from =
the on-line Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This draft is a work item of the =
Public-Key Infrastructure (X.509) Working Group of the IETF.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Internet X.509 Public Key =
Infrastructure Data </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Validation and Certification Server =
Protocols</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : C. =
Adams, P. Sylvester, M. Zolotarev, </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; R. Zuccherato</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-ietf-pkix-dcs-07.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 48</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 05-Oct-00</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">This document describes a general =
Data Validation and Certification</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Server (DVCS) and the protocols to be =
used when communicating with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it.&nbsp; The Data Validation and =
Certification Server is a Trusted Third</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Party (TTP) that can be used as one =
component in building reliable</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">non-repudiation services (see =
[ISONR]).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Useful Data Validation and =
Certification Server responsibilities in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKI are to assert the validity of =
signed documents, public key</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificates, and the possession or =
existence of data.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C033BB.1A17EB50--


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04093 for <[e-mail]>; Wed, 11 Oct 2000 12:32:01 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA09497; Wed, 11 Oct 2000 12:31:31 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 11 Oct 2000 13:50:42 -0400
To: Polar Humenn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
Cc: Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, Patrik  Fältström <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
In-Reply-To: <[e-mail] >
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Polar:

> > Okay, I think I finally figured out what Polar is getting at here, but
> > I'm not sure what the fix is.  Let me try to illustrate with an example.
> >
> > (We'll be picking on Stephen a little bit in this; nothing personal
> > intended; apologies for any offense.  :-)
> >
> > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > Technologies, OU=Public CAs, CN=The CA".
> > That CA has a self signed certificate with subject and issuer both equal
> > to the DN above.
> >
> > Now, there is an end-user certificate issued under that CA.  The issuer
> > field of that certificate will be the DN above; the subject field is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > CN=Stephen".
> >
> > The serial number field will be something like "4434".
> >
> > Now, an attribute authority has issued our friend Stephen an AC
> > consistent with the proposed profile.  The "Holder" field in that AC can
> > be one of three things, according to the proposed profile:
> >
> >       - it can be the issuer and serial number of the base PKC; that is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> >
> >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> >
> >       - it can be an ObjectDigest - for which the I-D does not require
> > support.
>
>I think the ObjectDigest is truly the only way to go. However, it still
>has problems. The object that is talked about must be able to be recalled
>and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>delivered with the Holder's Public Key Certificate.
>
>I don't believe that requiring the delivery of the Holders certificate is
>unreasonable. Can something like this be mandated in this profile? I don't
>see how. I only see that in specific protocols. Or am I wrong?

PKCs bind a public key to an identity.

ACs bind attributes to an identity.

Authentication, which includes validating the PKC certification path and 
having the remote party perform some operation that involves the private 
key associated with the identity.  Without authentication of the identity, 
who cares what attributes are associated with it?

Russ





Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03787 for <[e-mail]>; Wed, 11 Oct 2000 12:27:32 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA09493; Wed, 11 Oct 2000 12:31:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 11 Oct 2000 13:44:10 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: TSP: Response to the comments raised by Russ Housley
Cc: [e-mail]
In-Reply-To: <[e-mail]-its .com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
<font size=2>Francois</font>:<br>
<br>
Policy qualifiers can lead to huge interoperability problems.&nbsp; I am
less concerned about URLs that point to CP or CPS documents than other
uses.&nbsp; In RFC 2459, I wanted to prohibit policy qualifiers all
together to avoid the interoperability issues.&nbsp; The limited support
for policy qualifiers is the compromise.<br>
<br>
Russ<br>
<br>
At 10:36 AM 10/10/2000 -0400, [e-mail] wrote:<br>
<br>
<blockquote type=cite cite><font size=2>Russ,</font> <br>
<br>
<font size=2>What don't you like in policy qualifiers?</font> <br>
<br>
<font size=2>I still think it would be useful to have the option to
include a link to the practice statement of the TSA within each time
stamping response. Although I understand that no automated processing is
currently done today with these practice statements, once they are
written in XML, maybe relying parties could then start to do something
with them. However, with no optional pointer to the TSA practice
statement, it will never be possible.<br>
</font><br>
<font size=2>Regards,</font> <br>
<br>
<font size=2>Francois</font> <br>
<br>
<font size=2>&gt;Russ,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; Thank you for your response.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; The only remaining issues are numbered 3 and 10. See my
comments</font> <br>
<font size=2>&gt; embedded below.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&gt; Denis:</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>[snip]</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt; 3. I am not satisfied.&nbsp; I accept that this is
not the place to define</font> <br>
<font size=2>&gt;&gt; TSP policy or practice statements.&nbsp; However, I
do not think that the RFC</font> <br>
<font size=2>&gt;&gt; 2459 syntax is appropriate for use in the TSP
context.&nbsp; Also, you ignored</font> <br>
<font size=2>&gt;&gt; my concern regarding qualifiers.&nbsp; RFC 2459
contains:</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation ::=
SEQUENCE {</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyIdentifier&nbsp;&nbsp; CertPolicyId,</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PolicyQualifierInfo OPTIONAL }</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt; I would prefer a structure that said
&quot;TSAPolicyId&quot; instead of</font> <br>
<font size=2>&gt;&gt; &quot;CertPolicyId.&quot; Using
&quot;CertPolicyId&quot; in this context will, in my</font> <br>
<font size=2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I would like
to omit policy qualifiers</font> <br>
<font size=2>&gt;&gt; altogether.&nbsp; I do not like them in certificate
policies, and I would</font> <br>
<font size=2>&gt;&gt; like to avoid them in TSA policies.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; I had corrected the text but I did not understood your
were also</font> <br>
<font size=2>&gt; requesting an ASN.1 change.</font> <br>
<font size=2>&gt; Sorry about that misunderstanding. I agree with your
request and I have</font> <br>
<font size=2>&gt; done the changes, i.e:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; TSAPolicyId ::= OBJECT IDENTIFIER</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; and in the request:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; while in the response:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;
policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>[snip]</font> </blockquote></html>



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01200 for <[e-mail]>; Wed, 11 Oct 2000 10:26:38 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA26530; Wed, 11 Oct 2000 19:30:46 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 11 Oct 2000 19:30:46 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA22669; Wed, 11 Oct 2000 19:30:45 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA29833; Wed, 11 Oct 2000 19:30:44 +0200 (MET DST)
Date: Wed, 11 Oct 2000 19:30:44 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Experimental TSA
Cc: [e-mail], [e-mail]

> Rigth now the only interface available is the socket based protocol defined in
> the
> draft-ietf-pkix-time-stamp-09.
> 

With some first tests of sending

   0 30   36: SEQUENCE {
   2 02    1:   INTEGER 1
   5 30   31:   SEQUENCE {
   7 30    7:     SEQUENCE {
   9 06    5:       OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            :       }
  16 04   20:     OCTET STRING
            :       0D E8 66 25 D3 87 2E 02 45 4F 57 94 BD EC DC F6
            :       4F AA 95 77
            :     }
            :   }

I got back a rejection with a bitstring
encoded as
 
   30 0c 30 0a 02 01 02 03 05 00 00 00 00 05

or: 

   0 30   12: SEQUENCE {
   2 30   10:   SEQUENCE {
   4 02    1:     INTEGER 2
   7 03    5:     BIT STRING 0 unused bits
            :       00 00 00 05
            :     }
            :   }


BTW: I think the example of the Graz implementations is wrong:


direct TCP-based TSA message:
00:00:00:37:00:30:34:02.....
XXXXXXXXXXX

This doesn't seem to be network byte order. 

shouldn't this be 

37:00:00:00:00


Furthermore both implementions close the connection after sending the response.
This is unfriendly and pretty inefficien if you want to send may requests,
I am not sure whether this had been intended by the protocol. 

The length field at the beginning indicate to the client and to
the server how many data are transmitted in an exchange. 

it seems that the same problem occured in the CMP interoperability tests,
and this has already resulted in a draft. 





Received: from lax-gate1.raytheon.com (lax-gate1.raytheon.com [199.46.200.230]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25577 for <[e-mail]>; Wed, 11 Oct 2000 09:02:57 -0700 (PDT)
Received: from ds02w00.directory.ray.com (ds02w00.rsc.raytheon.com [147.25.146.118]) by lax-gate1.raytheon.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e9BG79x21957; Wed, 11 Oct 2000 09:07:09 -0700 (PDT)
Received: from most (localhost [127.0.0.1]) by ds02w00.directory.ray.com (8.9.3/8.9.3) with SMTP id JAA28587; Wed, 11 Oct 2000 09:04:22 -0700 (PDT)
Received: by most (SMI-8.6/SMI-SVR4) id LAA14580; Wed, 11 Oct 2000 11:04:20 -0500
Received: from notesmail(151.168.145.77) by most via smap (V1.3mjr) id smI014554; Wed Oct 11 11:04:12 2000
Received: by notesmail.ftw.rsc.raytheon.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 05256975.005841EF ; Wed, 11 Oct 2000 11:04:00 -0500
X-Lotus-FromDomain: HDC
From: "Rob B Branch" <[e-mail]>
To: Al Arsenault <[e-mail]>, "'Polar Humenn'" <[e-mail]>, Stephen Farrell <[e-mail]>, Patrik Faltstrom <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 11:04:02 -0500
Subject: PKI Question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello to ALL,

Do the Private Key have to be stored on a separate processor?
Can it be stored on the same processor but in a separate processing space?
Where can I find the rules for PKI?

Thanks in Advance...

RobB...




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25419 for <[e-mail]>; Wed, 11 Oct 2000 09:02:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA25331; Wed, 11 Oct 2000 18:06:06 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 11 Oct 2000 18:06:07 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA22152; Wed, 11 Oct 2000 18:06:05 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA29802; Wed, 11 Oct 2000 18:06:04 +0200 (MET DST)
Date: Wed, 11 Oct 2000 18:06:04 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Experimental TSA
Cc: [e-mail], [e-mail]

good news.

I have forgotten to cross post the following.

An experimental TSA is available using HTTP and HTTPS,
details how to read it are available under

  http://www.edelweb.fr/tsa.html

The TSA was developed using openssl.  

Peter Sylvester


Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23690 for <[e-mail]>; Wed, 11 Oct 2000 08:36:24 -0700 (PDT)
Received: from com-and.com (lello.andxor.it [195.223.2.223]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id QAA94828; Wed, 11 Oct 2000 16:46:15 +0200 (CEST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 17:41:58 +0200
From: Raffaello <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Experimental TSA
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD907512B2EC3FB39F659C2B4"

This is a cryptographically signed message in MIME format.

--------------msD907512B2EC3FB39F659C2B4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
for those of you interested in testing a TSA experimental implementation based
on the draft-ietf-pkix-time-stamp-09,  our TSA service is available at the
following address 195.223.2.6 ,  port 3318.

Rigth now the only interface available is the socket based protocol defined in
the
draft-ietf-pkix-time-stamp-09.

We would pleased to receive any feed-back from you.

We would like to point out that we have build the token with Snacc 1.3 which
hasn't
BIG INTEGER support so the BIG INTEGER fields of our Token are limited to
32 bit integer  (i.e.  nonce, serialnumber etc..)  and no extensions are
supported.

Thanks
Raffaello/Thomas

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

MIIGtgYJKoZIhvcNAQcCoIIGpzCCBqMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGYwggRiMIIDSqADAgECAgIBITANBgkqhkiG9w0BAQQFADCBtjELMAkGA1UEBhMCSVQxDzAN
BgNVBAgTBk1pbGFubzEaMBgGA1UEBxMRQ2luaXNlbGxvIEJhbHNhbW8xEDAOBgNVBAoTB0Mg
YW5kIEExGTAXBgNVBAsTEEMgYW5kIEEgU2VjdXJpdHkxLDAqBgNVBAMTI01hc3RlciBSb290
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGNvbS1hbmQu
Y29tMB4XDTAwMDkyNTExMjIyOFoXDTAxMDMyNDExMjIyOFowgbQxCzAJBgNVBAYTAklUMSAw
HgYDVQQIExcyMDA1NyBDaW5pc2VsbG8gQi4gKE1JKTEbMBkGA1UEBxMSVmlhbGUgRi4gVGVz
dGkgMTI2MQwwCgYDVQQKFgNDJkExFTATBgNVBAsWDEMmQSBTZWN1cml0eTEdMBsGA1UEAxMU
SW5nLiBSYWZmYWVsbG8gR2FsbGkxIjAgBgkqhkiG9w0BCQEWE3IuZ2FsbGlAY29tLWFuZC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/9pk93Tx72DkTfN5KOfPs5IdaOM0Pm
GkRikARsOdKsqjdvLtkLCPiupbqv/VzCXTUSvFaBzP2QBDZPkGqsOiya2+nzdYPrQhe9fsgT
eqqrXF1Wq5XEqFRP8gd00n3J1ngpaK7emftB2i5T6O4rCIU54H+VR9z2xcy18DdOkAB/AgMB
AAGjgf0wgfowLgYJYIZIAYb4QgEEBCEWH2h0dHA6Ly93d3cuY2FuZGEuY29tL2NhLWNybC5w
ZW0wgbQGCWCGSAGG+EIBDQSBphaBo1RoaXMgaXMgYSBzdGFuZGFyZCAgWDUwOSBWLjMgQ2Vy
dGlmaWNhdGUgKFdlYiBhbmQgRS1tYWlsKSAgc2lnbmVkIGJ5IEMmQSB3aXRoIHRoZSAyMDQ4
IGJpdHMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgQ2VydGlmaWNhdGUuIFRoaXMgQ2VydGlm
aWNhdGUgaXMgdmFsaWQgMTgwIGRheXMwEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEB
BAUAA4IBAQDg+Rj/NPFsdVmJc3BbQfe9MA7gr6Ad6Dc7zB5WiODixSk5yfwjdTjQPqva6F2+
yOzeCnNVWCOqSynjwGz7DrLgvaRmZg61mlEG4qIt9izToSmG9PtwwIo1Rb++VHukoFLFiUND
tr0uiLWXSCn5dJbKEfvAHTtDHoN5ceYeDAjJKKSM8YGRoGb+ZpN4BOOc84KrkTTB0XNFlsXv
+4zNJ6nc3T+puj/BdrJGxBBjQos/WlGUq1I4yW25NTLay1Fz2WrJvy+ECUFUnAx++Aq0HftO
gYWLn1eZ1HTeC6E9MljjDO5hFbWQTcWXAsOD/Z9SJH9cgLEr94yDQQ/RxyTl+FcqMYICGDCC
AhQCAQEwgb0wgbYxCzAJBgNVBAYTAklUMQ8wDQYDVQQIEwZNaWxhbm8xGjAYBgNVBAcTEUNp
bmlzZWxsbyBCYWxzYW1vMRAwDgYDVQQKEwdDIGFuZCBBMRkwFwYDVQQLExBDIGFuZCBBIFNl
Y3VyaXR5MSwwKgYDVQQDEyNNYXN0ZXIgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEf
MB0GCSqGSIb3DQEJARYQaW5mb0Bjb20tYW5kLmNvbQICASEwCQYFKw4DAhoFAKCBsTAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMTExNTQxNThaMCMG
CSqGSIb3DQEJBDEWBBStBcpUTZTXx8JIfgW8zldkzqCkADBSBgkqhkiG9w0BCQ8xRTBDMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggq
hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgLNaptcwwHL7+4UpmbY0ZMqYNYWeLsQ7o5wk
ieEVyQx9EohUZTPe7a7Tese+qNHImgqYMiuRwXts6jYBLJ8/ErW57BZXgRTcGckN90x546WZ
7/Ca6wfzrsisKkNNMZaqdF6+KZ4W018LhFS+aWl4jLgSQs2fpyeOAM01yA0qai0B
--------------msD907512B2EC3FB39F659C2B4--



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20678 for <[e-mail]>; Wed, 11 Oct 2000 08:23:38 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA29843; Wed, 11 Oct 2000 11:24:06 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 11 Oct 2000 11:24:05 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Stephen Farrell <[e-mail]>
cc: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Oct 2000, Stephen Farrell wrote:

> 
> FWIW I guess I agree with David (and Russ and Carlisle and James and ...)
> 
> Stephen.
> 
> Polar Humenn wrote:
> > 
> > On Wed, 11 Oct 2000, David P. Kemp wrote:
> > 
> > > This discussion has already played out, in a different context, in the
> > > S/MIME working group.
> > >
> > > The concern is not that there is a logic hole; there is not.
> > 
> > I really beg to differ on this one. 
> [snip]

What about adding a non-critical Attribute Extension that completes the DN
path of the Holder? That way, CONSTRAINED environments that emphatically
know where the DNs are defined need not have to deal with it.

However, widely scaled interoperable environments can deal with it
effectively and with assurance.

--
-- Full Directory Name of a Subject
--
DirectoryNamePath ::= SEQUENCE OF (1..MAX) OF DirectoryName 
	-- First is the subject's DirectoryName.
        -- Intermediates are the issuer of the previous DirectoryName
        -- Last is the RootCA of the Holder

--
-- Specific Type Alias for holderIssuerName attribute
--
HolderIssuerName ::= DirectoryNamePath
	-- Name path of the Holder's Issuer CA.

--
-- This attribute completes the Holder's name path up to its RootCA.
--
Attribute Extension:
      name           id-ce-holderIssuerName
      OID            { id-ce ? }
      syntax         HolderIssuerName
      criticality    MUST be FALSE


I think this or something like would solve the problem for Holders when
DN's are applicable.

I think there are still have problems for ProxyInfo and TargetInfo when
using GeneralNames and IssuerSerial.

Regards,
-Polar


> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15361 for <[e-mail]>; Wed, 11 Oct 2000 07:26:20 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA13486; Wed, 11 Oct 2000 15:30:53 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma013354; Wed, 11 Oct 00 15:30:23 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA18234; Wed, 11 Oct 2000 15:31:27 +0100
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 15:30:24 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

FWIW I guess I agree with David (and Russ and Carlisle and James and ...)

Stephen.

Polar Humenn wrote:
> 
> On Wed, 11 Oct 2000, David P. Kemp wrote:
> 
> > This discussion has already played out, in a different context, in the
> > S/MIME working group.
> >
> > The concern is not that there is a logic hole; there is not.
> 
> I really beg to differ on this one. 
[snip]

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13664 for <[e-mail]>; Wed, 11 Oct 2000 07:07:27 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA29657; Wed, 11 Oct 2000 10:07:55 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 11 Oct 2000 10:07:55 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Oct 2000, David P. Kemp wrote:

> This discussion has already played out, in a different context, in the
> S/MIME working group.
> 
> The concern is not that there is a logic hole; there is not. 

I really beg to differ on this one. We have already figured out that
information was lost if the AC names a holder by only its first DN.
That is a hole in the logic of naming of the holder in general.

> If the relying party does his job and the CAs and AA do theirs, names
> will be coordinated so that they don't collide.  I can't see any
> reasonable record company authorizing "John Smith" to listen to their
> tunes; John will have an account number issued by the record company,
> a PI, something formerly known as a QC unmistakeable identity, or some
> other unique name form agreed to among the parties involved.

You are *suggesting* ways of how you think organizations will operate and
co-operate. The whole purpose of this AA exercise, at least as I see it,
is so that John Smith doesn't have to get his own ID at the record
company, or every company he wishes to do business with. He just uses his
own. 

I'm sure in something like the Military, one might have a common mandated
naming scheme, so this might not be an issue. It's a constrained
environment.

> Mandating a reference to a particular PK certificate is unnecessarily
> heavy-handed; it precludes, for example, rollover (rekeying the
> subscriber's certificate.)  Designing applications that identify users
> by their public keys is one choice, but it cannot be the only one
> permitted by PKIX.

I agree with respect to the key rollover issue. But as I said in my last
message, I think you need to have the objectDigest of the RootCA and not
the holder's certificate. That might not change as much. If it does, you
got a big problem anyway.

However, I think that AA's and users of AC that agree on a common
resolution to naming of RootCAs just might do it. That's not unreasonable
and is currently done with DNS.

> On the other hand, limiting the damage that can occur when parties do
> not do their jobs properly is a legitimate security concern, so PKIX
> should offer ObjectDigest as an option for environments where RPs
> "trust" all 137 roots built into their browsers.

I know, it gets to be ludicrous after a while. :)

> This is the solution adopted by S/MIME - the SigningCertificate
> attribute identifies a PKC as:
> 
>   ESSCertID ::= SEQUENCE {
>      certHash       Hash,
>      issuerSerial   IssuerSerial OPTIONAL }
> 
> but use of that attribute is an option, not a requirement, of RFC 2634.

I think that is what the objectDigest does. However, I think there is
still some problem.

Given that the AC can be used in CONSTRAINED environments of which,
something like a military can agree on a unique naming scheme for DN's,
then the Holder as a single DN should be fine.

However, there can be a DN path critical extension that completes the
Holder's Name. For widely interoperable environments this criticial
extension must be used.

Also, the same problem exists for ProxyInfo and TargetInfo attribute
extensions.

Care to tackle that one?

Cheers,
-Polar

> > 
> > On Tue, 10 Oct 2000, Carlisle Adams wrote:
> > 
> > > Hi Polar,
> > > 
> > > > ----------
> > > > From: 	Polar Humenn[SMTP:[e-mail]]
> > > > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > > > To: 	Al Arsenault
> > > > Cc: 	Stephen Farrell; Patrik  Faltstrom; [e-mail];
> > > > [e-mail]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > > > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > > > Targets  andProxies
> > > > 
> > > (...some text deleted...)
> > > 
> > > > The start of the solution is mandating the use of ObjectDigest, where
> > > > a digest can be verified against the Holder's Public Key or Public Key
> > > > Certificate. The question after that is where does one pull the
> > > > Holder's cert or public key from, should it not be readily available,
> > > > i.e. wasn't delivered with the AttributeCertificate. This would
> > > > constitute having the entire DN path to the Holders public key
> > > > certificate anyway, and using the ObjectDigest for verification of the
> > > > identity.
> > > 
> > > > Could we suggest a critical attribute extension that will contain the
> > > > path to the ObjectDigest?
> > >  
> > > Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> > > optionals (general name, issuer/serial, and object digest).  If the group
> > > decides to do what you're suggesting, no new critical extension would be
> > > necessary; all the profile would have to do is mandate two (or all three) of
> > > the optional fields.
> > 
> > Not good enough. You still need a proper full DN path, (i.e. sequence of
> > DNs) from the root CA of the Holder's certificate. You need it to locate
> > the Holder's certificate to verify it against the ObjectDigest.
> 
> 
> You don't "need" a sequence of DNs carried in a protocol or in an
> attribute certificate to do path development; and it's not obvious why
> it would even help.  If you know the Holder's DN and/or an IssuerSerial
> reference and cannot find the Holder's PKC using that information, how
> would knowing the DNs of CAs above the Issuer aid in finding it?
> 
> Dave
> 
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12650 for <[e-mail]>; Wed, 11 Oct 2000 06:46:51 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id JAA29627; Wed, 11 Oct 2000 09:47:04 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Wed, 11 Oct 2000 09:47:04 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "Manger, James H" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 11 Oct 2000, Manger, James H wrote:

> A relying party verifying an attribute certificate that only includes the
> holder's name must match a name from an AA to a name from a CA.

Then you MUST name the CA and its CA and its CA, and so on.

> Matching names from two sources is dangerous if the two sources can issued
> the same name to different entities.  It is safe, however, if this cannot
> occur.

However, there is no way for you to control that. The only thing you can
control is that you only accept a set of root CA's (with different keys)
that have different names.

> In the general case trusting an arbitrary combination of CAs and AAs (even
> if they all individually do their job correctly) is insecure when verifying
> an AC that only contains the holder name - as Polar described.

True. So, how does one solve this problem? Not by constraining the
environment.

> However, this is NOT a good reason to mandate extra fields.  It is possible
> to securely verify an AC that only contains the holder name as long as the
> relying party's set of trusted CAs and AAs have some commonality in their
> naming schemes.  It is sufficient that the same name cannot be issued to
> different entities by different CAs and AAs in this trusted collection.

And therefore you limit or break interoperability on a wide scale.

> Use globally unambiguous names (e.g. DNS) or restrict your set of trusted
> CAs and AAs for a given scenario.

I don't have control over names that CA's issue, nor do I have control
over AAs that issue privilege certificates. That's like you being the 51st
state and mandating that the Social Security Agency to conform and use
YOUR person naming scheme for the entire nation and the DMV's of all
states to produce drivers licenses using YOUR person naming scheme so the
person can drive YOUR state.

> It must not be mandated that attribute certificates be bound to public key
> certificates - a major benefit of attribute certificates was separating
> these two domains of control.

Okay I can see that, for things such as Kerberos or unix user ids.
However, with DN's you have the special complex identification problem.
With DN's you are meant to be pointing to a public key. Some evidence is
needed to prove that you are not issuing privileges to a forgery or that
you are not accepting privileges meant for somebody else. Having a
complete path from a root CA might do it. However, that always requires a
lookup to make sure that you have the right certificate and corresponding
signatures that it verifies.

Holder: DN,DNCA,...,DNRootCA

Even if the principal which is the Holder delivers the certificate in
whatever protocol he is using to authenticate himself, the Holder's name
still must be looked up via the DN path in the Attribute Certificate and
be verified. An objectDigest might alleviate that. Still if the Holder
didn't deliver his certificate a certificate lookup is still needed.

So there are two cases in the forms of a protocol, say TLS.

1. The authenticated entity delivers its certificate chain.
   The AC must name the holder using a DN path includes the DN path
   constructed from the certificate chain as a prefix.  The DN path
   in the AC must contain the DN all the way up to the RootCA.

   The certificate from the Holder's RootCA named in the AC must be looked
   up and it must be able to verify the authenticated entities chain as
   well. This covers the case where you trust the same RootCA's the AA
   trusts. So no objectDigest is really needed.

   If you and the AA have no agreement on which RootCA's you trust
   there must be an ObjectDigest! And Strangely enough IT MUST BE THE
   ObjectDigest of the RootCA certificate, not the Holder's!

2. The authenticated entity does not deliver is certificate chain.
   Quite possibly its authentication information is gone. The
   authenticated entity's name has been passed on to another server  as
   being previously authenticated, say at the firewall.  However, you 
   only do this in situations where the certificates that were used
   during authentication can be retrieved somehow.
   
   The AC must name the authentication identity and it's objectDigest
   to make sure that the AC is talking about the proper certificate.
   In this case to be absolutely sure, the authenticated entities
   certificate must be looked up, and the objectDigest verified against
   it.

> what we really want to do here is issue privileges to a public key, not
> just the name of one.
>  
> Absolutely not!  The whole idea is that the source of authority for a given
> privilege knows who (by name) they want to assign it to, but does not care
> what public key that person uses.  The cost is that the names used must be
> unambiguous in a large context that just the AA.

Okay. I can see your point. I'm a big fan of Kerberos and other faster
authentication schemes. However, just using naming in the point of AA must
cause a lookup for verification at least to common trust points. It's not
unreasonable.  Although it still bothers me. Peoples pictures and
signatures on are drivers licenses for a reason.

However, the issue still remains of name "collisions" or "coincidences"
of which cannot be verified.

One approach, of which I think James is getting at, is to mandate that all
DN's in the Entire World and Universe be unique. That would mean a
stringent relationship MUST exist between a subjects DN and an Issuers DN
for public key certificates, i.e. DNS. However, I think, since the
inception of RFC2459 and it's predecessors, this was a detail that was not
addressed, or was addressed to be unwarranted.

Therefore one can only conclude that a NAME of a principal in RFC2459 is
the COMPLETE list of DNs from the subject up to the root CA's DN. It cannot
be shorter. Therefore the Holder must be named by a complete list of DN's
up to its RootCA. 

If we use just DN's and no objectDigests, this must mean that there is
at least a common agreement between all AAs and users of ACs that they
trust the same RootCA's, or the naming scheme of RootCA's. That is if a
DN resolves to a RootCA on the AA side, it resolves to the same RootCA on
the user's side.

I think the basic upshot is that the Holder field must name the entire DN
path up to its rootCA. That is indeed the complete name of the defined
X.509 principal.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11749 for <[e-mail]>; Wed, 11 Oct 2000 06:19:46 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA04130 for <[e-mail]>; Wed, 11 Oct 2000 09:05:22 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Wed, 11 Oct 2000 09:17:39 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: /2zu7h74eDjjpcwYLZFNww==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

This discussion has already played out, in a different context, in the
S/MIME working group.

The concern is not that there is a logic hole; there is not.  If the
relying party does his job and the CAs and AA do theirs, names will
be coordinated so that they don't collide.  I can't see any reasonable
record company authorizing "John Smith" to listen to their tunes; John
will have an account number issued by the record company, a PI,
something formerly known as a QC unmistakeable identity, or some other
unique name form agreed to among the parties involved.

Mandating a reference to a particular PK certificate is unnecessarily
heavy-handed; it precludes, for example, rollover (rekeying the
subscriber's certificate.)  Designing applications that identify users
by their public keys is one choice, but it cannot be the only one
permitted by PKIX.

On the other hand, limiting the damage that can occur when parties do
not do their jobs properly is a legitimate security concern, so PKIX
should offer ObjectDigest as an option for environments where RPs
"trust" all 137 roots built into their browsers.

This is the solution adopted by S/MIME - the SigningCertificate
attribute identifies a PKC as:

  ESSCertID ::= SEQUENCE {
     certHash       Hash,
     issuerSerial   IssuerSerial OPTIONAL }

but use of that attribute is an option, not a requirement, of RFC 2634.




> 
> On Tue, 10 Oct 2000, Carlisle Adams wrote:
> 
> > Hi Polar,
> > 
> > > ----------
> > > From: 	Polar Humenn[SMTP:[e-mail]]
> > > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > > To: 	Al Arsenault
> > > Cc: 	Stephen Farrell; Patrik  Faltstrom; [e-mail];
> > > [e-mail]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > > Targets  andProxies
> > > 
> > (...some text deleted...)
> > 
> > > The start of the solution is mandating the use of ObjectDigest, where
> > > a digest can be verified against the Holder's Public Key or Public Key
> > > Certificate. The question after that is where does one pull the
> > > Holder's cert or public key from, should it not be readily available,
> > > i.e. wasn't delivered with the AttributeCertificate. This would
> > > constitute having the entire DN path to the Holders public key
> > > certificate anyway, and using the ObjectDigest for verification of the
> > > identity.
> > 
> > > Could we suggest a critical attribute extension that will contain the
> > > path to the ObjectDigest?
> >  
> > Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> > optionals (general name, issuer/serial, and object digest).  If the group
> > decides to do what you're suggesting, no new critical extension would be
> > necessary; all the profile would have to do is mandate two (or all three) of
> > the optional fields.
> 
> Not good enough. You still need a proper full DN path, (i.e. sequence of
> DNs) from the root CA of the Holder's certificate. You need it to locate
> the Holder's certificate to verify it against the ObjectDigest.


You don't "need" a sequence of DNs carried in a protocol or in an
attribute certificate to do path development; and it's not obvious why
it would even help.  If you know the Holder's DN and/or an IssuerSerial
reference and cannot find the Holder's PKC using that information, how
would knowing the DNs of CAs above the Issuer aid in finding it?

Dave





Received: from osiris (uu212-190-70-2.unknown.uunet.be [212.190.70.2]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA11259 for <[e-mail]>; Wed, 11 Oct 2000 06:11:16 -0700 (PDT)
Received: from osiris (unverified [192.168.1.254]) by mail.globalsign.net (Rockliffe SMTPRA 4.2.0) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 11 Oct 2000 14:15:30 +0100
Received: by PAPYRUS with Internet Mail Service (5.5.2650.21) id <T8ZQG1T8>; Wed, 11 Oct 2000 15:15:11 +0200
Message-ID: <6B70D9716940D41186F200508BADFECF1C6174@PAPYRUS>
From: "Benoit d'Udekem" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: to Unsubscribe
Date: Wed, 11 Oct 2000 15:15:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0005_01C03396.0CAC8E00"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C03396.0CAC8E00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Information on how to unsubscribe is also provided in every single
message posted to the list.

Have a look at the message header. You will find the following line:

List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

Benoit d'Udekem
________________________________________________________________________
ir. Benoit d'Udekem                Email: [e-mail]
Project Manager

GlobalSign SA/NV                   Tel: [phone]
Haachtsesteenweg 1426              Fax: [phone]
B-1130 Brussels                    Web: http://www.globalsign.net
Belgium
________________________________________________________________________
Get your FREE Web Server Certificate NOW at 
http://www.globalsign.net/prod/freeserver.cfm?ID=CorpSign
________________________________________________________________________

------=_NextPart_000_0005_01C03396.0CAC8E00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMyjCCAk8w
ggG4oAMCAQICCwEAAAAAAOFvQLJOMA0GCSqGSIb3DQEBBAUAMF0xCzAJBgNVBAYTAkJFMRkwFwYD
VQQKExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAzIENBMR4wHAYDVQQDExVHbG9i
YWxTaWduIENsYXNzIDMgQ0EwHhcNMDAwOTA2MDk1NTUyWhcNMDEwOTA2MDk1NTUyWjBwMQswCQYD
VQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBTQS9OVjEYMBYGA1UEAxMPQmVub2l0IGQnVWRl
a2VtMSwwKgYJKoZIhvcNAQkBFh1iZW5vaXQuZHVkZWtlbUBnbG9iYWxzaWduLm5ldDBcMA0GCSqG
SIb3DQEBAQUAA0sAMEgCQQCiKwmbY71Lwhw++lmJMURWvATRB/PAOrSmTmevraA10+shIkDmaLiK
f6PdiG/+12jnyio6p+zfYR8mKy2vIOa3AgMBAAGjRjBEMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNV
HQ8BAf8EBAMCBPAwHwYDVR0jBBgwFoAUgcl7A9IXSWNHIvkJInVBhfIu/xIwDQYJKoZIhvcNAQEE
BQADgYECNlFvDW+tl20/Pjai8iCUPF9tIDuFzfud4P4aVz+qnsCUnqhdeWjHpC676M3+LiZnnG8u
TIzRfuxGmtNZz5GAgOtGUyW23wGUn00CPc5dKU4VfTvD+dyXhvW7jJsG8DEuonbwQ3k7TgMwLZIh
iplzmOzluYjGrGyW4WGXw09ancwwggNEMIICLKADAgECAgsCAAAAAADWeLrrATANBgkqhkiG9w0B
AQQFADBtMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEbMBkGA1UECxMS
UHJpbWFyeSBDbGFzcyAzIENBMSYwJAYDVQQDEx1HbG9iYWxTaWduIFByaW1hcnkgQ2xhc3MgMyBD
QTAeFw05OTAxMjgxMjAwMDFaFw0wNDAxMjgxMjAwMDBaMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQK
ExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAzIENBMR4wHAYDVQQDExVHbG9iYWxT
aWduIENsYXNzIDMgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKCmzjV2IlJGb+wsiUBR
f81TPbbIOr5mdKeKuhSVYzuX5GK2ej8BP8R7aK9D+ZErxVeV/+IgR/FH88tY2Yex2ruJLaFYEVrU
AWSL6hFpvLphJL5RUztfeyu32WlaIw6BO+TP3qT1Q4ckyesVbQ4VGDxo+pq92OzJViyLSeDNm3wv
AgMBAAGjeTB3MA4GA1UdDwEB/wQEAwIABjAdBgNVHQ4EFgQUgcl7A9IXSWNHIvkJInVBhfIu/xIw
HwYDVR0jBBgwFoAUzDbMF7RFkS/tzzswSHf7tRSZvuMwEQYJYIZIAYb4QgEBBAQDAgAGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwDQYJKoZIhvcNAQEEBQADggEBAHehI+3h8rxSul5Lw8axneYNrX4zm4dt
SCROp01tm6cQRFi2z2YeoZVzCK3vQbCCI9Kg9jPLT7ad91emsRrYjoXrR841JPfJ6JFKusqJNZrO
32pPH6e6xAyF8Etlv/gcSUU8ajyQ/HgARFM8H7ebYZWXdvfraaoMFhmD8g6g4tFGFrkBX0PZ3MZF
5KCt03ZepcY9wUZhER0v3D0bHrd2vO+slYsUTMMTIh6mNWxXr2OB0OHUfWT7vROLn3HztGiNoCiu
t4+chRRBDuhQjJcQmmhNvkEkkTpzExVqcKud4FxEc2lApoEGOEtGAl3x8PRgxOWQ+4ABhCxzztGQ
YzcCVGowggN7MIICY6ADAgECAhDEu9jAyv9WpRHTVpZhmSIwMA0GCSqGSIb3DQEBBAUAMB0xGzAZ
BgNVBAMTElJvb3QgU0dDIEF1dGhvcml0eTAeFw05OTA4MjAwMDMwMDFaFw0xNDAxMjgwNzAwMDBa
MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290
IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDaDuaZjc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymA
Zavpxy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp1Wrjsok6
Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdGsnUOhugZitVtbNV4FpWi
6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJU26Qzns3dLlwR5EiUWMWea6xrkEmCMgZ
K9FGqkjWZCrXgzT/LCrBbBlDSgeF59N89iFo7+ryUp9/k5DPAgMBAAGjfTB7MA0GA1UdCgQGMAQD
AgeAMCAGA1UdJQQZMBcGCisGAQQBgjcKAwMGCWCGSAGG+EIEATBIBgNVHQEEQTA/gBANJynkBSqX
tHdYNUeTLQa4oR8wHTEbMBkGA1UEAxMSUm9vdCBTR0MgQXV0aG9yaXR5ggognRHRDn97hXSAMA0G
CSqGSIb3DQEBBAUAA4IBAQDSgu5VNiVXQrnLqHCcQo5Gp9eZkdLMotvyoMa/xttF8XqO3ANjSpuU
maYPvUzKbeQxYWoIEE0eR9QRWTMCZWmuE9vxZXlyJXkhxLQlwmz/jH6W32nARSShaUumpgTngd7K
24ijpnyRz4ZHdpfml/caLtcD8Dc73XaVbSZ0UUlE1j6EtwN0bWZnojaLhPPt+aid5KgaCdzSAZJP
Hz1YQbvprAOb6PCWwM1+AdviqT5m4CTm7H9tGFM5ncCJv2B4vssHN3edfY6NFwrXbxfa5Yrh5wjE
E+V6K1xt954gxI1P7QYpB695kvJf+aohFctmOXfTLRkkaIRfqUhGWtsdtEEfMIIDrDCCApSgAwIB
AgILAgAAAAAA1ni41sMwDQYJKoZIhvcNAQEEBQAwVzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEds
b2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9v
dCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBaMG0xCzAJBgNVBAYTAkJFMRkwFwYD
VQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQcmltYXJ5IENsYXNzIDMgQ0ExJjAkBgNV
BAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAzIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAkV5WZdbAwAScv0fEXHt6MQH5WJaZ4xyEL9xWj631WYHVQ2ZdWpOMdcqp5xHBURAU
YMks1HuvxneGq3onrm+VuQvKtkb7fhr0DRRt0slOsq7wVPZcQEw2SHToVIxlZhCnvSu3II0FSa14
fdIkI1Dj8LR5mwE5/6870y3u4UmNjS88akFFL5vjPeES5JF1ns+gPjySgW+KLhjc4PKMjP2H2Qf0
QJTJTk9D32dWb70DUHyZZ6S5PJFsAm6E1vxG98xvGD4X8O8LZBZX5qyG8UiqQ8HJJ3hzREXihX26
/7Ph+xsFpEs7mRIlAVAUaq9d6sgM7uTa7EuLXGgTldzDtTA61wIDAQABo2MwYTAOBgNVHQ8BAf8E
BAMCAAYwHQYDVR0OBBYEFMw2zBe0RZEv7c87MEh3+7UUmb7jMB8GA1UdIwQYMBaAFGB7ZhpFDZfK
iVAvfQTNNKj//P1LMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADggEBAFeyVMy9lRdk
YIm2U5EMRZLDPahsw8yyGPV4QXTYfaMnr3cNWT6UHWn6idMMvRoB9D/o4Hcagiha5mLXt+M2yQ6f
euPC08xZiQzvFovwNnciyqS2t8FCZwFAY8znOGSHWxSWZnstFO69SW3/d9DiTlvTgMJND8q4nYGX
pzRux+OcSOW0qkX19mVMSPISwtKTjMIVJPMrUv/jCK64btYsEs85yxIq56l7X5g9o+HMpmOJXH0x
dfnV1l3y0NQ9355xqA7c5CCXeOZ/U6QNUU+OOwOuow1aTcN55zVYcELJXqFetNkio0RTNaTQz3OA
xc+fVph2+RRMd4eCydx+XTTVNnUxggIJMIICBQIBATBsMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQK
ExBHbG9iYWxTaWduIG52LXNhMRMwEQYDVQQLEwpDbGFzcyAzIENBMR4wHAYDVQQDExVHbG9iYWxT
aWduIENsYXNzIDMgQ0ECCwEAAAAAAOFvQLJOMAkGBSsOAwIaBQCgggE0MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTAxMTEzMTUxMVowIwYJKoZIhvcNAQkEMRYE
FM6prN4nWWnROPAwWHD0bIESA4KBMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHsG
CSsGAQQBgjcQBDFuMGwwXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2Ex
EzARBgNVBAsTCkNsYXNzIDMgQ0ExHjAcBgNVBAMTFUdsb2JhbFNpZ24gQ2xhc3MgMyBDQQILAQAA
AAAA4W9Ask4wDQYJKoZIhvcNAQEBBQAEQEwq/fRW6qez6Y26QlXOyQd15/bZLMOy2wj4CYbXVIet
DwpkMuahg+Pqa2f3eLBtXYAI8ZnvshyeNVEmErjRboYAAAAAAAA=

------=_NextPart_000_0005_01C03396.0CAC8E00--



Received: from laguna.tiscalinet.it (laguna.tiscalinet.it [195.130.224.86]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10861 for <[e-mail]>; Wed, 11 Oct 2000 06:06:24 -0700 (PDT)
Received: from floridia (62.11.138.35) by laguna.tiscalinet.it; 11 Oct 2000 15:09:39 +0200
Message-ID: <003601c03383$f159cb20$0102a8c0@floridia>
From: "Carmelo Floridia" <[e-mail]>
To: <[e-mail]>
Subject: to Unsuscribe
Date: Wed, 11 Oct 2000 15:05:33 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C03394.B3E6D600"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

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

If you ever want to remove yourself from this mailing list,
you can send mail to <[e-mail]> with the following
command in the body of your email message:

    unsubscribe ietf-pkix [e-mail]



------=_NextPart_000_0033_01C03394.B3E6D600
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>If you ever want to remove yourself =
from this=20
mailing list,<BR>you can send mail to &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt; with the=20
following<BR>command in the body of your email=20
message:<BR><BR>&nbsp;&nbsp;&nbsp; unsubscribe ietf-pkix <A=20
href=3D"mailto:[e-mail]">[e-mail]=
ng</A><BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0033_01C03394.B3E6D600--



Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09976 for <[e-mail]>; Wed, 11 Oct 2000 05:53:31 -0700 (PDT)
Received: by ns.celocom.se; id OAA21107; Wed, 11 Oct 2000 14:56:45 +0200 (CEST)
Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma021101; Wed, 11 Oct 00 14:56:41 +0200
Received: from celocom.se ([e-mail] [10.10.10.124]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id OAA11689; Wed, 11 Oct 2000 14:57:59 +0200
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 14:58:28 +0200
From: Richard Levitte <[e-mail]>
Organization: Celo Communications, Ltd.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Frank Balluffi <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: unsubscibe
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------AD2D79ACC7B93080CDF26B92"

This is a multi-part message in MIME format.
--------------AD2D79ACC7B93080CDF26B92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Frank Balluffi wrote:
> 
> Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
> does not appear to contain directions for unsubscribing (or at least I don't
> see them) nor does it contain directions for where to send this message.

It's a pity that the same info is displayed in two places, and differently.
If you look at the archive page (http://www.imc.org/ietf-pkix/), you'll find
"unsubscribe" mentioned.

However, I do find it a bit surprising that it would be difficult to figure
out that the unsubscribe request should be sent to the same address as the
subscribe command that was obviously sent at some point in time.  And to boot,
when one subscribes one usually gets a welcoming message that explains all
this...

-- 
Richard Levitte			!!! New cell phone number !!!
[e-mail]

/* You might enjoy viewing the complete vCard */
--------------AD2D79ACC7B93080CDF26B92
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[e-mail]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------AD2D79ACC7B93080CDF26B92--



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09160 for <[e-mail]>; Wed, 11 Oct 2000 05:39:48 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA22950 for <[e-mail]>; Wed, 11 Oct 2000 14:44:21 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 11 Oct 2000 14:44:21 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA21314 for <[e-mail]>; Wed, 11 Oct 2000 14:44:20 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA29739 for [e-mail]; Wed, 11 Oct 2000 14:44:20 +0200 (MET DST)
Date: Wed, 11 Oct 2000 14:44:20 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: unsubscibe

Each message includes this information.

Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21)
 id <4L3GG8Y1>; Wed, 11 Oct 2000 05:30:18 -0700
Content-return: allowed
Date: Wed, 11 Oct 2000 05:30:16 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: unsubscibe
To: "'[e-mail]'" <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: mailto:[e-mail]?body=unsubscribe

Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
does not appear to contain directions for unsubscribing (or at least I don't
see them) nor does it contain directions for where to send this message.

Frank



Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08763 for <[e-mail]>; Wed, 11 Oct 2000 05:36:48 -0700 (PDT)
Received: from chrisf (perm70-18.ij.net [209.216.70.18] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id IAA02655; Wed, 11 Oct 2000 08:41:11 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Wed, 11 Oct 2000 08:51:20 -0400
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.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

James,

-----Original Message-----
From: Manger, James H [mailto:[e-mail]]
Sent: Tuesday, October 10, 2000 9:32 PM
To: [e-mail]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

.. .snip
In the general case trusting an arbitrary combination of CAs and AAs (even
if they all individually do their job correctly) is insecure when verifying
an AC that only contains the holder name - as Polar described.

However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
....end snip
[Chris Francis - WetStone Technologies] It seems reasonable then to assert
that a relying party's list of trusted SOAs should have unique Distinguished
Names.  This is something that the RP has complete control over and it
avoids the whole problem.  I suspect that many implementations already
impose a similar limitation on the list of trusted roots for PKC validation.
Chris



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08189 for <[e-mail]>; Wed, 11 Oct 2000 05:27:55 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 11 Oct 2000 05:32:23 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 11 Oct 2000 05:32:22 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <4L3GG8Y1>; Wed, 11 Oct 2000 05:30:18 -0700
Content-return: allowed
Date: Wed, 11 Oct 2000 05:30:16 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: unsubscibe
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
does not appear to contain directions for unsubscribing (or at least I don't
see them) nor does it contain directions for where to send this message.

Frank

> -----Original Message-----
> From: J Johnen [mailto:[e-mail]]
> Sent: Tuesday, October 10, 2000 9:22 PM
> To: Polar Humenn
> Cc: Al Arsenault; Stephen Farrell; Patrik =?UNKNOWN?Q?F=E4ltstr=F6m?=;
> [e-mail]; [e-mail]; Thumrongsak 
> Kosiyatrakul; Shiu-Kai
> Chin; Susan Older
> Subject: unsubscibe
> 
> 
> unsubscribe me from this list, please.
> 
> Polar Humenn wrote:
> 
> > On Tue, 10 Oct 2000, Paul Krumviede wrote:
> >
> > > "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
> > found on
> > > this server."
> > >
> > > -paul
> > >
> > > --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
> > <[e-mail]>
> > > wrote:
> > >
> > > > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
> > >
> > >
> >
> > Opps Sorry, The corrected URL is
> >
> >  http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps
> >
> > Cheers,
> > -Polar
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> 
> 
> 


Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA28420 for <[e-mail]>; Wed, 11 Oct 2000 00:48:35 -0700 (PDT)
Received: (qmail 9896 invoked by uid 0); 11 Oct 2000 07:53:06 -0000
Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 11 Oct 2000 07:53:06 -0000
Received: (qmail 18896 invoked from network); 11 Oct 2000 07:52:39 -0000
Received: from unknown (HELO F-Secure.com) (10.71.0.24) by dfintra.f-secure.com with SMTP; 11 Oct 2000 07:52:39 -0000
Message-ID: <[e-mail]>
Date: Wed, 11 Oct 2000 10:54:43 +0300
From: Camillo =?iso-8859-1?Q?S=E4rs?= <[e-mail]>
Organization: F-Secure Corporation
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: sv-FI,sv,en,fi,fr
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,Targets  andProxies
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Bob Jueneman wrote:
> But I have to say that this seems like one case where our colleagues in 
> the (moribund?) SPKI group may have a very valid point.  The connection 
> between the attribute cert and the identity cert should not be based on 
> the name, nor on the issuer/serial, but on the KEY contained in the 
> identity cert, or better yet on a message digest of the entire > referenced certificate.

Actually, there is no need to be that strict.  Correct me if I'm wrong, but
the underlying problem here is name space collisions.  I.e. the CA and AA
name spaces may overlap, leading to problems in interpreting names.  The
SPKI group also recognized the need for name certificates, as a tool for
indirection and grouping, but the SPKI name spaces are always locally
defined and rooted in a public key.  No assumption on global names are
present.

One of the proposed solutions here required the trusted CA and AA name
spaces to be "reasonable".  With the rapid increase in available TTP CA
certificates, I feel this assumption is insecure.  If Attribute Certs are
to be generally applicable, we must base their security on some other
property.

My opinion is that using the Object Digest would unnecessarily bind the
Attribute Cert to the actual issued Identity Cert.  If the digest would
only be over the key, the usefulness of the DN would be removed.  If the
cert would be referenced, the Attribute Cert validity period would be
limited by that of the Identity Cert (as in SPKI).

A useful solution to this problem would tie the Attribute Cert to the
issuing entity that issued the Identity Cert in an unambiguous fashion. 
I.e. the Attribute Cert must identify not only the DN, but a relevant
trusted root CA.  Is this requirement too strict?

Regards,
Camillo
-- 
Camillo Särs <[e-mail]>       http://www.iki.fi/ged/
Researcher, F-Secure Corporation               http://www.F-Secure.com

   F-Secure products: Securing the Mobile, Distributed Enterprise


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20769 for <[e-mail]>; Tue, 10 Oct 2000 18:56:33 -0700 (PDT)
Received: from [128.33.238.81] (TC081.BBN.COM [128.33.238.81]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id WAA22608; Tue, 10 Oct 2000 22:00:51 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220802b609712acdc9@[128.33.238.61]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 10 Oct 2000 21:30:14 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,  Targets andProxies
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

One could choose to mandate an AC binding to the subject's public key 
or the whole cert, rather than to a name, but that causes the 
undesirable effect of mating the AC's validity to the base cert 
validity.  ACs have chosen to not require such a binding, although to 
allow it as an option, preferring instead to allow a more general 
binding, which has attendant security concerns. SPKI chose one of the 
three options ACs offer, which has security benefits, but also 
management problems.

Steve


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20544 for <[e-mail]>; Tue, 10 Oct 2000 18:54:37 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA10594; Wed, 11 Oct 2000 12:05:46 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5L287>; Wed, 11 Oct 2000 12:57:15 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: TSP: Response to the comments raised by Russ Housley
Date: Wed, 11 Oct 2000 12:57:14 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0332E.F5662C40"

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_01C0332E.F5662C40
Content-Type: text/plain;
	charset="iso-8859-1"

Francois,
I tend to agree with Ross, favoring using just a policy OID. 
 
The reasoning is that a diligent client - since only 'diligent' clients
would be ever interested in reading practice statements - would have to read
the statement before(!) making the very first transaction. So the
information should be available prior to obtaining a timestamp.
 
Anticipating your argument - no, there are better ways of finding references
to the TSA practice statement than executing a 'void' transaction to get the
reference from a timestamp. The SubjectInformationAccess extension in the
TSA cert is a possible one, in addition to other less sophisticated ones.
 
regards
Michael

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, 11 October 2000 0:37
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: TSP: Response to the comments raised by Russ Housley



Russ, 

What don't you like in policy qualifiers? 

I still think it would be useful to have the option to include a link to the
practice statement of the TSA within each time stamping response. Although I
understand that no automated processing is currently done today with these
practice statements, once they are written in XML, maybe relying parties
could then start to do something with them. However, with no optional
pointer to the TSA practice statement, it will never be possible.

Regards, 

Francois 

>Russ, 
> 
> Thank you for your response. 
> 
> The only remaining issues are numbered 3 and 10. See my comments 
> embedded below. 
> 
>> Denis: 
>> 
[snip] 
>> 
>> 3. I am not satisfied.  I accept that this is not the place to define 
>> TSP policy or practice statements.  However, I do not think that the RFC 
>> 2459 syntax is appropriate for use in the TSP context.  Also, you ignored

>> my concern regarding qualifiers.  RFC 2459 contains: 
>> 
>>     PolicyInformation ::= SEQUENCE { 
>>          policyIdentifier   CertPolicyId, 
>>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF 
>>                                  PolicyQualifierInfo OPTIONAL } 
>> 
>> I would prefer a structure that said "TSAPolicyId" instead of 
>> "CertPolicyId." Using "CertPolicyId" in this context will, in my 
>> opinion, confuse matters.  Also, I would like to omit policy qualifiers 
>> altogether.  I do not like them in certificate policies, and I would 
>> like to avoid them in TSA policies. 
> 
> I had corrected the text but I did not understood your were also 
> requesting an ASN.1 change. 
> Sorry about that misunderstanding. I agree with your request and I have 
> done the changes, i.e: 
> 
> TSAPolicyId ::= OBJECT IDENTIFIER 
> 
> and in the request: 
> 
> reqPolicy       TSAPolicyId    OPTIONAL, 
> 
> while in the response: 
> 
> policy          TSAPolicyId, 
> 
[snip] 


------_=_NextPart_001_01C0332E.F5662C40
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">
<TITLE>RE: TSP: Response to the comments raised by Russ Housley</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Francois,</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff size=2>I tend 
to agree with Ross, favoring using just a policy OID. </FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff size=2>The 
reasoning is that a diligent client - since only 'diligent' clients would be 
ever interested in reading practice statements - would have to read the 
statement before(!) making the very first transaction. So the information should 
be available prior to obtaining a timestamp.</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Anticipating your argument - no, there are better ways of finding 
references to&nbsp;the TSA practice statement than executing a 'void' 
transaction to get the reference from a timestamp.&nbsp;The 
SubjectInformationAccess extension in the TSA cert is a possible one, in 
addition&nbsp;to other less sophisticated ones.</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>regards</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Michael</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, 11 October 
  2000 0:37<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> [e-mail]; 
  [e-mail]<BR><B>Subject:</B> RE: TSP: Response to the comments 
  raised by Russ Housley<BR><BR></FONT></DIV>
  <P><FONT size=2>Russ,</FONT> </P>
  <P><FONT size=2>What don't you like in policy qualifiers?</FONT> </P>
  <P><FONT size=2>I still think it would be useful to have the option to include 
  a link to the practice statement of the TSA within each time stamping 
  response. Although I understand that no automated processing is currently done 
  today with these practice statements, once they are written in XML, maybe 
  relying parties could then start to do something with them. However, with no 
  optional pointer to the TSA practice statement, it will never be 
  possible.</FONT></P>
  <P><FONT size=2>Regards,</FONT> </P>
  <P><FONT size=2>Francois</FONT> </P>
  <P><FONT size=2>&gt;Russ,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt; Thank you for your response.</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; The only remaining issues are numbered 3 and 10. See my 
  comments</FONT> <BR><FONT size=2>&gt; embedded below.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt;&gt; Denis:</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>[snip]</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>&gt;&gt; 3. I am not satisfied.&nbsp; 
  I accept that this is not the place to define</FONT> <BR><FONT size=2>&gt;&gt; 
  TSP policy or practice statements.&nbsp; However, I do not think that the 
  RFC</FONT> <BR><FONT size=2>&gt;&gt; 2459 syntax is appropriate for use in the 
  TSP context.&nbsp; Also, you ignored</FONT> <BR><FONT size=2>&gt;&gt; my 
  concern regarding qualifiers.&nbsp; RFC 2459 contains:</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  PolicyInformation ::= SEQUENCE {</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  policyIdentifier&nbsp;&nbsp; CertPolicyId,</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  PolicyQualifierInfo OPTIONAL }</FONT> <BR><FONT size=2>&gt;&gt; 
  </FONT><BR><FONT size=2>&gt;&gt; I would prefer a structure that said 
  "TSAPolicyId" instead of</FONT> <BR><FONT size=2>&gt;&gt; "CertPolicyId." 
  Using "CertPolicyId" in this context will, in my</FONT> <BR><FONT 
  size=2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I would like to omit 
  policy qualifiers</FONT> <BR><FONT size=2>&gt;&gt; altogether.&nbsp; I do not 
  like them in certificate policies, and I would</FONT> <BR><FONT 
  size=2>&gt;&gt; like to avoid them in TSA policies.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; I had corrected the text but I did 
  not understood your were also</FONT> <BR><FONT size=2>&gt; requesting an ASN.1 
  change.</FONT> <BR><FONT size=2>&gt; Sorry about that misunderstanding. I 
  agree with your request and I have</FONT> <BR><FONT size=2>&gt; done the 
  changes, i.e:</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt; 
  TSAPolicyId ::= OBJECT IDENTIFIER</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; and in the request:</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; while in the response:</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; 
  policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TSAPolicyId,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>[snip]</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0332E.F5662C40--


Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19948 for <[e-mail]>; Tue, 10 Oct 2000 18:37:56 -0700 (PDT)
From: [e-mail]
Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id <4VMHV9X7>; Tue, 10 Oct 2000 21:42:14 -0400
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: TSP: Response to the comments raised by Russ Housley
Date: Tue, 10 Oct 2000 10:36:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03324.79580628"

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_01C03324.79580628
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

What don't you like in policy qualifiers?

I still think it would be useful to have the option to include a link to the
practice statement of the TSA within each time stamping response. Although I
understand that no automated processing is currently done today with these
practice statements, once they are written in XML, maybe relying parties
could then start to do something with them. However, with no optional
pointer to the TSA practice statement, it will never be possible.

Regards,

Francois

>Russ,
>
> Thank you for your response.
>
> The only remaining issues are numbered 3 and 10. See my comments
> embedded below.
> 
>> Denis:
>> 
[snip]
>> 
>> 3. I am not satisfied.  I accept that this is not the place to define
>> TSP policy or practice statements.  However, I do not think that the RFC
>> 2459 syntax is appropriate for use in the TSP context.  Also, you ignored
>> my concern regarding qualifiers.  RFC 2459 contains:
>> 
>>     PolicyInformation ::= SEQUENCE {
>>          policyIdentifier   CertPolicyId,
>>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>>                                  PolicyQualifierInfo OPTIONAL }
>> 
>> I would prefer a structure that said "TSAPolicyId" instead of
>> "CertPolicyId." Using "CertPolicyId" in this context will, in my
>> opinion, confuse matters.  Also, I would like to omit policy qualifiers
>> altogether.  I do not like them in certificate policies, and I would
>> like to avoid them in TSA policies.
>
> I had corrected the text but I did not understood your were also
> requesting an ASN.1 change.
> Sorry about that misunderstanding. I agree with your request and I have
> done the changes, i.e:
>
> TSAPolicyId ::= OBJECT IDENTIFIER
>
> and in the request:
>
> reqPolicy       TSAPolicyId    OPTIONAL,
>
> while in the response:
>
> policy          TSAPolicyId,
>
[snip]

------_=_NextPart_001_01C03324.79580628
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: TSP: Response to the comments raised by Russ Housley</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>What don't you like in policy qualifiers?</FONT>
</P>

<P><FONT SIZE=3D2>I still think it would be useful to have the option =
to include a link to the practice statement of the TSA within each time =
stamping response. Although I understand that no automated processing =
is currently done today with these practice statements, once they are =
written in XML, maybe relying parties could then start to do something =
with them. However, with no optional pointer to the TSA practice =
statement, it will never be possible.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Francois</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Thank you for your response.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The only remaining issues are numbered 3 and =
10. See my comments</FONT>
<BR><FONT SIZE=3D2>&gt; embedded below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Denis:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>[snip]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 3. I am not satisfied.&nbsp; I accept that =
this is not the place to define</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; TSP policy or practice statements.&nbsp; =
However, I do not think that the RFC</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 2459 syntax is appropriate for use in the =
TSP context.&nbsp; Also, you ignored</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; my concern regarding qualifiers.&nbsp; RFC =
2459 contains:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation =
::=3D SEQUENCE {</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
policyIdentifier&nbsp;&nbsp; CertPolicyId,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PolicyQualifierInfo OPTIONAL }</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I would prefer a structure that said =
&quot;TSAPolicyId&quot; instead of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &quot;CertPolicyId.&quot; Using =
&quot;CertPolicyId&quot; in this context will, in my</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I =
would like to omit policy qualifiers</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; altogether.&nbsp; I do not like them in =
certificate policies, and I would</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; like to avoid them in TSA policies.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I had corrected the text but I did not =
understood your were also</FONT>
<BR><FONT SIZE=3D2>&gt; requesting an ASN.1 change.</FONT>
<BR><FONT SIZE=3D2>&gt; Sorry about that misunderstanding. I agree with =
your request and I have</FONT>
<BR><FONT SIZE=3D2>&gt; done the changes, i.e:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; TSAPolicyId ::=3D OBJECT IDENTIFIER</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; and in the request:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; while in the response:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TSAPolicyId,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>[snip]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03324.79580628--


Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19593 for <[e-mail]>; Tue, 10 Oct 2000 18:29:53 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA16484 for <[e-mail]>; Wed, 11 Oct 2000 12:33:53 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdIEk6__; Wed Oct 11 11:33:24 2000
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id MAA12213 for <[e-mail]>; Wed, 11 Oct 2000 12:33:23 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd_QU4M_; Wed Oct 11 11:33:00 2000
Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA29052 for <[e-mail]>; Wed, 11 Oct 2000 12:33:00 +1100 (EST)
Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id <4RBDZ0KC>; Wed, 11 Oct 2000 12:32:30 +1100
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Wed, 11 Oct 2000 12:32:20 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

A relying party verifying an attribute certificate that only includes the
holder's name must match a name from an AA to a name from a CA.
 
Matching names from two sources is dangerous if the two sources can issued
the same name to different entities.  It is safe, however, if this cannot
occur.
 
In the general case trusting an arbitrary combination of CAs and AAs (even
if they all individually do their job correctly) is insecure when verifying
an AC that only contains the holder name - as Polar described.
 
However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
 
Use globally unambiguous names (e.g. DNS) or restrict your set of trusted
CAs and AAs for a given scenario.
 
 
It must not be mandated that attribute certificates be bound to public key
certificates - a major benefit of attribute certificates was separating
these two domains of control.
 
> what we really want to do here is issue privileges to a public key, not
just the name of one.
 
Absolutely not!  The whole idea is that the source of authority for a given
privilege knows who (by name) they want to assign it to, but does not care
what public key that person uses.  The cost is that the names used must be
unambiguous in a large context that just the AA.

 



Received: from mail.nanospace.com ([e-mail] [209.213.199.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19149 for <[e-mail]>; Tue, 10 Oct 2000 18:19:12 -0700 (PDT)
Received: (qmail 20363 invoked by uid 74); 11 Oct 2000 01:23:43 -0000
Received: from [e-mail] by mail with scan4virus-0.19 (Clean. Processed in 1.995762 secs); 10/10/2000 18:23:41
Received: from ppp-209-213-195-6.nanospace.com (HELO nanospace.com) (209.213.195.6) by mail.nanospace.com with SMTP; 11 Oct 2000 01:23:41 -0000
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 18:22:21 -0700
From: J Johnen <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, "Patrik Fältström" <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: unsubscibe
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe me from this list, please.

Polar Humenn wrote:

> On Tue, 10 Oct 2000, Paul Krumviede wrote:
>
> > "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
> found on
> > this server."
> >
> > -paul
> >
> > --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
> <[e-mail]>
> > wrote:
> >
> > > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
> >
> >
>
> Opps Sorry, The corrected URL is
>
>  http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps
>
> Cheers,
> -Polar
>
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com





Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13850 for <[e-mail]>; Tue, 10 Oct 2000 14:27:36 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id RAA28454; Tue, 10 Oct 2000 17:12:52 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 17:12:51 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, Patrik  Faltstrom <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 10 Oct 2000, Carlisle Adams wrote:

> Hi Polar,
> 
> > ----------
> > From: 	Polar Humenn[SMTP:[e-mail]]
> > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > To: 	Al Arsenault
> > Cc: 	Stephen Farrell; Patrik  Faltstrom; [e-mail];
> > [e-mail]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > Targets  andProxies
> > 
> (...some text deleted...)
> 
> > The start of the solution is mandating the use of ObjectDigest, where
> > a digest can be verified against the Holder's Public Key or Public Key
> > Certificate. The question after that is where does one pull the
> > Holder's cert or public key from, should it not be readily available,
> > i.e. wasn't delivered with the AttributeCertificate. This would
> > constitute having the entire DN path to the Holders public key
> > certificate anyway, and using the ObjectDigest for verification of the
> > identity.
> 
> > Could we suggest a critical attribute extension that will contain the
> > path to the ObjectDigest?
>  
> Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> optionals (general name, issuer/serial, and object digest).  If the group
> decides to do what you're suggesting, no new critical extension would be
> necessary; all the profile would have to do is mandate two (or all three) of
> the optional fields.

Not good enough. You still need a proper full DN path, (i.e. sequence of
DNs) from the root CA of the Holder's certificate. You need it to locate
the Holder's certificate to verify it against the ObjectDigest.


> Having said that, however, I'm still not convinced that there is a
> problem in the specifications.  The relying party has two chains of
> certificates: an AC chain; and a corresponding PKC chain.  BOTH chains
> have to validate properly (i.e., fit within specified name and path
> length constraints, etc., etc., AND terminate at a trusted public
> key).  The trusted public key of the AC Source-of-Authority (which may
> or may not be the same as the root CA, depending upon the model) must
> have been acquired via a secure out-of-band mechanism.  Given that
> both the AC path and the corresponding PKC path are validated by the
> relying party, where is the "logic hole" for the attack you're
> concerned about?

The hole is currently that the AA is allowed to certify that "Henry Ford"
has some privileges without stating the chain of authorities that defined
"Henry Ford"s name (and public key). 

If your system accepts identities from a number of different public key
certificate authorities, Henry Ford can come from two different trusted
CA's. Which Henry Ford really has the privileges? Information has been
thrown away.  In the current scenario, I may have to accept both, because
I wouldn't be able to tell which one the AC was pointing to. If you use
the Issuer Serial form, all you do is just push the problem up one level.

Now, if I had the ObjectDigest I could verify that the privileges belonged
to the Henry Ford to which they were issued. The only thing to do, is be
able to locate the public key certificate in the advent that I don't
already have it. That's why I sort of suggested a DN path critical
extension. Constrained environments wouldn't have to provide it, but
interoperable ones would to make any real sense of it.

As Bob really said, what we really want to do here is issue privileges to
a public key, not just the name of one.

Cheers,
-Polar

> Carlisle.
> 
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11379 for <[e-mail]>; Tue, 10 Oct 2000 13:22:20 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <T6Z8BDQW>; Tue, 10 Oct 2000 16:26:48 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Al Arsenault <[e-mail]>, "'Polar Humenn'" <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, Patrik  Faltstrom <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Tue, 10 Oct 2000 16:26:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C032F8.6A0DEE70"

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_01C032F8.6A0DEE70
Content-Type: text/plain

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[e-mail]]
> Sent: 	Tuesday, October 10, 2000 3:27 PM
> To: 	Al Arsenault
> Cc: 	Stephen Farrell; Patrik  Faltstrom; [e-mail];
> [e-mail]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets  andProxies
> 
(...some text deleted...)

	The start of the solution is mandating the use of ObjectDigest,
where a
	digest can be verified against the Holder's Public Key or Public Key
	Certificate. The question after that is where does one pull the
Holder's
	cert or public key from, should it not be readily available, i.e.
wasn't
	delivered with the AttributeCertificate. This would constitute
having the
	entire DN path to the Holders public key certificate anyway, and
using 
	the ObjectDigest for verification of the identity.

	Could we suggest a critical attribute extension that will contain
the 
	path to the ObjectDigest?
 
Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
optionals (general name, issuer/serial, and object digest).  If the group
decides to do what you're suggesting, no new critical extension would be
necessary; all the profile would have to do is mandate two (or all three) of
the optional fields.

Having said that, however, I'm still not convinced that there is a problem
in the specifications.  The relying party has two chains of certificates:
an AC chain; and a corresponding PKC chain.  BOTH chains have to validate
properly (i.e., fit within specified name and path length constraints, etc.,
etc., AND terminate at a trusted public key).  The trusted public key of the
AC Source-of-Authority (which may or may not be the same as the root CA,
depending upon the model) must have been acquired via a secure out-of-band
mechanism.  Given that both the AC path and the corresponding PKC path are
validated by the relying party, where is the "logic hole" for the attack
you're concerned about?

Carlisle.


------_=_NextPart_001_01C032F8.6A0DEE70
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.2651.67">
<TITLE>RE: Fwd: AttributeCertificates: Path Names to AC Holders, =
Targets  andProxies</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, October 10, 2000 3:27 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell; Patrik&nbsp; Faltstrom; [e-mail]; [e-mail]; =
Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Fwd: AttributeCertificates: Path Names to AC Holders, =
Targets&nbsp; andProxies</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The start =
of the solution is mandating the use of ObjectDigest, where a</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">digest =
can be verified against the Holder's Public Key or Public Key</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Certificate. The question after that is where does one pull the =
Holder's</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">cert or =
public key from, should it not be readily available, i.e. wasn't</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">delivered =
with the AttributeCertificate. This would constitute having the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">entire DN =
path to the Holders public key certificate anyway, and using </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">the =
ObjectDigest for verification of the identity.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Could we =
suggest a critical attribute extension that will contain the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">path to =
the ObjectDigest?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
the syntax in X.509 (2000) is that holder is a SEQUENCE of three =
optionals (general name, issuer/serial, and object digest).&nbsp; If =
the group decides to do what you're suggesting, no new critical =
extension would be necessary; all the profile would have to do is =
mandate two (or all three) of the optional fields.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Having =
said that, however, I'm still not convinced that there is a problem in =
the specifications.&nbsp; The relying party has two chains of =
certificates:&nbsp; an AC chain; and a corresponding PKC chain.&nbsp; =
BOTH chains have to validate properly (i.e., fit within specified name =
and path length constraints, etc., etc., AND terminate at a trusted =
public key).&nbsp; The trusted public key of the AC Source-of-Authority =
(which may or may not be the same as the root CA, depending upon the =
model) must have been acquired via a secure out-of-band =
mechanism.&nbsp; Given that both the AC path and the corresponding PKC =
path are validated by the relying party, where is the &quot;logic =
hole&quot; for the attack you're concerned about?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C032F8.6A0DEE70--


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11045 for <[e-mail]>; Tue, 10 Oct 2000 13:18:29 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id QAA28346; Tue, 10 Oct 2000 16:11:10 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 16:11:09 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Bob Jueneman <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Susan Older <[e-mail]>, Shiu-Kai Chin <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id NAA11047

On Tue, 10 Oct 2000, Bob Jueneman wrote:

> There is nothing like wide-eyed child saying "Mommy, mommy, the
> Emperor doesn't have any clothes on!" to make the grown-ups wake up
> and take notice.  (No offense intended, Polar!)

No offense taken. :)

> But let me clear up a couple of possible misunderstandings.  In one
> message, Polar said that George#2 "steals" the attribute cert of
> George#1. I assume that by that he meant something like Al Arsenault's
> scenario, whereby George#2 gets a deliberately confusing certificate
> from a rogue CA, i.e., he did not simply steal George#1's private key.  
> I assume Polar understands, but I want to be sure.

Correct. I assume no public keys are stolen. The PKI is intact.

> Second, it should be obvious that the chain of trust from the
> root-level Attribute CA is every bit as important as the chain of
> trust involved in the identity CA chain.  If you don't trust the root,
> and every subordinate CA in the chain, with respect to some policy
> then you can hardly expect to trust the end-entity.  Unfortunately,
> adding more and more "trusted roots" to the various browsers and other
> relying party software makes the security weaker, not stronger -- a
> fact that the end users and some important vendors don't seem to have
> grasped yet.

Yep. I assume that there is a chain of Public Key Certificates verifying
the issuance of the attribute certificate, just like any PKCA issues
Public Key Certificates.

> But assuming that the Attribute CA's are credible, then the
> possibility of a collision in the issue name and serial number name
> space seems somewhat improbable, but not at all impossible.  In fact,
> an attacker could conceivably request certificates one at a time until
> a serial number collision did occur. Likewise, the DN name space could
> also collide. Maybe less likely in the case of someone named Jueneman
> or Arsenault, but highly likely in the case of a "Smith".

I agree.

> I'll confess that I have almost completely ignored the attribute
> certificate standards progression, because I am not yet sufficiently
> convinced as to the business case for such certificates to spend much
> time on them.
> 
> But I have to say that this seems like one case where our colleagues
> in the (moribund?) SPKI group may have a very valid point.  The
> connection between the attribute cert and the identity cert should not
> be based on the name, nor on the issuer/serial, but on the KEY
> contained in the identity cert, or better yet on a message digest of
> the entire referenced certificate.

Exactly.

> Assuming that is what the Object Digest represents, and based solely
> on my imperfect level of understanding, it seems to me that the DN
> and/or issuer/serial number relationship might be useful hints in
> trying to tack down the identity cert, but that the match MUST be
> based on an object digest of the entire certificate which is
> incorporated by reference.
>
> Isn't that why digital signatures were invented, so we could validate
> more than just the name of a document, but actually validate the
> content?

Exactly. At this point I think the ObjectDigest form of the Holder should
be mandated. Let there be a critical attribute extension that can be used
to locate the Holder's identity certificate. The question is should it's
existance be mandatory.

You need at least a DN path to a CA that you trust. The problem with
interoperability on a wide scale is that the AA probably needs to specify
the DN path all the way up to the Root CA of the Holder for which
privileges are requested.

Any other suggestions?

Cheers,
-Polar

> Bob
> 
> >>> Al Arsenault <[e-mail]> 10/10/00 09:10AM >>>
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example. 
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA". 
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
> 	- it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
> 	- it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
> 	- it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> > 
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> > 
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> > 
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> > 
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> > 
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> > 
> > In simplistic terms, With PKCs it's like saying:
> > 
> > "This is George Burns."
> > 
> > And with an Attribute Certificate, it's like saying:
> > 
> > "George has Cigars"
> > 
> > If you have a PKC that says
> > 
> > "This is George Bush"
> > 
> > Which George has the cigars?
> > 
> > Cheers,
> > -Polar
> > 
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail] 
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com 
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail] 
> > > Ireland                             http://www.baltimore.com 
> > >
> > 
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10014 for <[e-mail]>; Tue, 10 Oct 2000 12:49:02 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id PAA28311; Tue, 10 Oct 2000 15:48:25 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 15:48:24 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: Stephen Farrell <[e-mail]>, Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 10 Oct 2000, Paul Krumviede wrote:

> "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
found on
> this server."
>
> -paul
>
> --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
<[e-mail]>
> wrote:
>
> > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
>
>

Opps Sorry, The corrected URL is

 http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09100 for <[e-mail]>; Tue, 10 Oct 2000 12:32:30 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id PAA28246; Tue, 10 Oct 2000 15:27:53 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 15:27:52 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Al Arsenault <[e-mail]>
cc: Stephen Farrell <[e-mail]>, Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail], Thumrongsak Kosiyatrakul <[e-mail]>, Shiu-Kai Chin <[e-mail]>, Susan Older <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id MAA09101

Hi Al,

Thanks for seeing the problem. Comments below:

On Tue, 10 Oct 2000, Al Arsenault wrote:

> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example. 
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA". 
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
> 	- it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
> 	- it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
> 	- it can be an ObjectDigest - for which the I-D does not require
> support.

I think the ObjectDigest is truly the only way to go. However, it still
has problems. The object that is talked about must be able to be recalled
and identified. Otherwise the Attribute Certificate MUST ALWAYS be
delivered with the Holder's Public Key Certificate.

I don't believe that requiring the delivery of the Holders certificate is
unreasonable. Can something like this be mandated in this profile? I don't
see how. I only see that in specific protocols. Or am I wrong?

> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  

The "reality" approach is probably not a great way to reason about this
attack. The "reality" of attacks are always exploited in some form sooner
or later. For example, DES is not considered really good any more, as well
as low bit valued public keys. The arguments for them in their time was
the "reality" of the attack. That reason was just the "reality" of
computing power with respect to the time. However, here what we are
talking about is the "reality" of a glaring hole in the logic. It doesn't
take the reality of a lot of computing power to overcome this one.

> First of all, I as the attacker could simply fake an AC issuer's cert
> first, rather than start from the root CA.  Second, so what if I have
> managed to convince somebody that an AC goes with my PKC vice
> Stephen's - has it gained me anything useful?  I'm not sure. 

I try to look at things in a verifiable way. If I have a Henry Ford from
GM and a Henry Ford from Chyrsler and I have an Attribute Certificate
claiming that Henry Ford has some privilegse, I cannot really say to whom
the privileges belong unless I constrain my operating environment such
that I can throw one out, or deem it impossible, i.e. I don't trust
anything from GM.

The constrained environment approach is okay if I'm running a nuclear power
plant. However, it's not good enough I'm running an E-commerce site in
which I want identities defined by thousands of RA/CA's to be issued
privileges to buy stuff or get access to stuff. I just don't have that
control.

We've done some work on the verifiability of trust in the X.509 public
key directory frame work.

See http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps

We would really like to extend this work to attribute certificates as
well, as it facilitates the need for privileges and delegation within the
X.509 framework. However, if we have holes such as this, it will not be
possible.

> Third, this attack starts by exploiting the age-old issue with PKCs
> that you have to get the root CA's public key through some secure, out
> of band means in order to make everything work.

Not quite so. I can provide this attack without knowing or forging any
private keys. I can be a legitimate user with a real public/private
keypair from a CA. All I need is a name "collision" at a lower level.

The mere fact that I can issue privileges to Henry Ford of GM MUST NOT
mean I have also inadvertently issued privileges to Henry Ford of Chrysler
in some other realm.

> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.

I think only strengthening the wording is not really enough. That's like
telling people they SHOULD NOT use Username/Password schemes in the clear.
The mere fact that standards exist such as Telnet, FTP, etc, means we
can't get rid of them, and it's really tough to stop it from happening.

> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a
> loss for a solution.)

The start of the solution is mandating the use of ObjectDigest, where a
digest can be verified against the Holder's Public Key or Public Key
Certificate. The question after that is where does one pull the Holder's
cert or public key from, should it not be readily available, i.e. wasn't
delivered with the AttributeCertificate. This would constitute having the
entire DN path to the Holders public key certificate anyway, and using the
ObjectDigest for verification of the identity.

Could we suggest a critical attribute extension that will contain the path
to the ObjectDigest?

Note, the same problem exists for ProxyInfo and TargetInfo attribute
extensions as well.

Cheers,
-Polar

> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> > 
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> > 
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> > 
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> > 
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> > 
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> > 
> > In simplistic terms, With PKCs it's like saying:
> > 
> > "This is George Burns."
> > 
> > And with an Attribute Certificate, it's like saying:
> > 
> > "George has Cigars"
> > 
> > If you have a PKC that says
> > 
> > "This is George Bush"
> > 
> > Which George has the cigars?
> > 
> > Cheers,
> > -Polar
> > 
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> > >
> > 
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08497 for <[e-mail]>; Tue, 10 Oct 2000 12:19:19 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id MAA19173; Tue, 10 Oct 2000 12:11:18 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 10 Oct 2000 15:10:13 -0400
To: Al Arsenault <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
Cc: Polar Humenn <[e-mail]>, Stephen Farrell <[e-mail]>, "Patrik  Fältström" <[e-mail]>, [e-mail], [e-mail]
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

Al:

I do not understand how the attacker's certificate path validates.  The 
self-signed certificate must be trusted.  That trust comes from procedures 
outside of either the PKC spec or the AC spec.

Maybe we need to make the language stronger about validating the PKC before 
using the AC.

Russ


At 11:10 AM 10/10/2000 -0400, Al Arsenault wrote:
>Okay, I think I finally figured out what Polar is getting at here, but
>I'm not sure what the fix is.  Let me try to illustrate with an example.
>
>(We'll be picking on Stephen a little bit in this; nothing personal
>intended; apologies for any offense.  :-)
>
>Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
>Technologies, OU=Public CAs, CN=The CA".
>That CA has a self signed certificate with subject and issuer both equal
>to the DN above.
>
>Now, there is an end-user certificate issued under that CA.  The issuer
>field of that certificate will be the DN above; the subject field is
>"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
>CN=Stephen".
>
>The serial number field will be something like "4434".
>
>Now, an attribute authority has issued our friend Stephen an AC
>consistent with the proposed profile.  The "Holder" field in that AC can
>be one of three things, according to the proposed profile:
>
>         - it can be the issuer and serial number of the base PKC; that is
>"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
>
>         - it can be the entity name, which by the I-D MUST be "C=IE,
>O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
>
>         - it can be an ObjectDigest - for which the I-D does not require
>support.
>
>Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
>claim Stephen's legitimate AC as his own. So, he can set up his own CA
>and issue a self-signed certificate with the same name as the legitimate
>one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
>CA".  The KEY cannot be the same - we'll assume that the attacker
>doesn't know the root CA's private key, which is usually a reasonable
>assumption - but you can't stop the attacker from copying the names.
>Then, Al can use that certificate to issue a user certificate with the
>same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
>CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
>will be "4434", just like in the legitimate certificate.
>
>Now, the question is, given the value of the "Holder" field in the AC,
>to which PKC does it correspond - Stephen's real one, or Al's forgery?
>Based on the Issuer/serial number option, you can't tell - both
>purported certs have identical issuer and serial number values. Based on
>the entityName option, you also can't tell - even though you've used the
>full DNs, they're identical; it's just the keys (and signature values,
>of course) that are different. Based on a Digest of the PKC or PK, you
>could tell.
>
>Now - how realistic is this attack in practice? I don't know.  First of
>all, I as the attacker could simply fake an AC issuer's cert first,
>rather than start from the root CA.  Second, so what if I have managed
>to convince somebody that an AC goes with my PKC vice Stephen's - has it
>gained me anything useful?  I'm not sure. Third, this attack starts by
>exploiting the age-old issue with PKCs that you have to get the root
>CA's public key through some secure, out of band means in order to make
>everything work.
>
>So I'm not sure what the solution to this is, other than reversing
>ourselves and mandating the ObjectDigest choice.  It's clearly not
>"include the entire DN vice just the CN". At this point, I think that
>the easiest thing to do may be to strengthen the warning in the Security
>Considerations section.  That is, explain this issue and that it may be
>a risk in some environments.  I don't think that we want to make any
>other changes at this point.
>
>(If Stephen and Russ agree on that approach, I can propose a paragraph
>or two for the Security Considerations section. Otherwise, I'm at a loss
>for a solution.)
>
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
>
>
>
>
>Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I 
> think
> > > this is more or less what Carlisle was saying is a previous response 
> to the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets 
> and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both 
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of 
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, 
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate 
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty 
> low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his 
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For 
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a 
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can 
> access the
> > > > >Holden plant through the Internet. It is clearly not enough that I 
> just
> > > > >define the "Holder" as using the Issuer-Serial form of 
> GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we 
> can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a 
> client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry 
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian 
> Botham
> > > > >or not.  (Provided both the privilege service and target both 
> trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to 
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions 
> (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07577 for <[e-mail]>; Tue, 10 Oct 2000 11:55:16 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Tue, 10 Oct 2000 11:59:45 -0700
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 15:01:06 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Christopher S. Francis" <[e-mail]>
CC: Polar Humenn <[e-mail]>, Stephen Farrell  <[e-mail]>, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?="  <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Christopher,

	If the relying party properly checks both the AC and purported PKC all
the way back to their trusted roots, and the RP has gotten the "right"
public key for the trusted root, then yes, this attack will be detected.

	First, I'll point out that the AC issuer's PK Cert may or may not chain
back to the same trusted root as the PK cert's of the holders to which
it issues certs.  (That is, in my example, the AC issuer's cert may
chain back to "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA", or to a different root.) The I-D is silent on this issue - properly
so, in my opinion.  

	But, that means that just checking the signature on the AC, and then
checking the AC Issuer's chain is not guaranteed to detect the attack.
If the AC Issuer's PK Cert chains back to a different root, also trusted
by the RP, then just doing that part of the check won't reveal the
attack. You have to check the purported PK Cert, too.

	Which is why I pointed out that it's not clear to me how meaningful
this attack is in practice.  If the RP does the whole job, the attack
should not work. If the RP does a lousy job, and just checks the AC and
accepts the purported PKC without checking, there's a problem in the
system. (It's the RP's fault, but there's still a problem in the
system.)  And if the RP finds Awful Al's PK Cert, tries to validate it
and fails and thus rejects the entire transaction without trying
Stephen's PK Cert, there may be a "denial of service" attack - about
which we may or may not care.

				Al Arsenault


"Christopher S. Francis" wrote:
> 
> Al,
> 
> I'm new here so forgive me if I'm missing something obvious, but in your
> example, doesn't the relying party have an obligation to verify the
> signature on the AC using a key that it is confident belongs to the Source
> Of Authority (or a key that can be traced back to an approved SOA)?  If the
> relying party in your example validates the AC in this way, the forged AC
> would fail the signature check.
> 
> What am I missing?
> 
> Christopher S. Francis
> WetStone Technologies, Inc.
> 935 Main Street, Suite A-1
> Safety Harbor, FL   34695
> [phone]
> http://www.wetstonetech.com/
> 
> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Tuesday, October 10, 2000 11:10 AM
> To: Polar Humenn
> Cc: Stephen Farrell; Patrik Fältström; [e-mail];
> [e-mail]
> Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
> andProxies
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising
> and
> > > if it is an issue then it also applies to public key certificates (I
> think
> > > this is more or less what Carlisle was saying is a previous response to
> the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
> Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your
> application
> > > > >does not have control over both clients and server, i.e. they both
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA,
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough
> to
> > > > >identify a holder, proxy, or target of the Attribute Certificate
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low
> on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates
> are
> > > > >signed by 5's public key. Here's one of my employees and his
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden
> Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can access
> the
> > > > >Holden plant through the Internet. It is clearly not enough that I
> just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
> such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can
> verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client
> using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number,
> then
> > > > >there wouldn't even be a question of whether the AC applied to Ian
> Botham
> > > > >or not.  (Provided both the privilege service and target both trust
> the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical
> or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates,
> which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06684 for <[e-mail]>; Tue, 10 Oct 2000 11:31:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA18390; Tue, 10 Oct 2000 11:34:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 10 Oct 2000 14:28:26 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
Cc: IETF-PXIX <[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

Denis:

This is fine with me.

Russ

At 01:25 PM 10/10/2000 +0200, Denis Pinkas wrote:
>Russ,
>
> > Denis:
> >
> > I am happy with your response to number 3.  Now, for number 10.  How about
> > something like the following:
> >
> >      For the <list your types here> MIME types, implementations SHOULD
>
>I did not realized first why you were leaving the types empty, :-)
>... until I found the acronym collision between
>application/timestamp-request (TSR) and application/timestamp-response
>(TSR).
>
>Here is a proposal to solve this acronym collision:
>
>For the application/timestamp-query and application/timestamp-reply MIME
>types, implementations SHOULD include the optional "name" and "filename"
>parameters. Including a file name serves helps preserve type information
>when timestamps are saved as files.  When these parameters are included, a
>file name with the appropriate extension SHOULD be selected:
>
>        MIME Type                     File Extension
>
>   application/timestamp-query            .TSQ
>   application/timestamp-reply            .TSR
>
>In addition, the file name SHOULD be limited to eight characters followed by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>Would that text be OK with you ?
>
>Regards,
>
>Denis
>
> >      include the optional "name" and "filename" parameters.  Including a
> >      file name serves helps preserve type information when timestamps are
> >      saved as files.  When these parameters are included, a file name with
> >      the appropriate extension SHOULD be selected:
> >
> >        MIME Type                     File Extension
> >
> >          <your request type>           .<your request extension>
> >
> >          <your response type>          .<your response extension>
> >
> >          ...
> >
> >      In addition, the file name SHOULD be limited to eight characters
> >      followed by a three letter extension. The eight character filename
> >      base can be any distinct name.
> >
> > Russ



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA05841 for <[e-mail]>; Tue, 10 Oct 2000 11:10:06 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 10 Oct 2000 12:13:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 10 Oct 2000 12:13:42 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA05842

There is nothing like wide-eyed child saying "Mommy, mommy, the Emperor doesn't have any clothes on!" to make the grown-ups wake up and take notice.  (No offense intended, Polar!)

But let me clear up a couple of possible misunderstandings.  In one message, Polar said that George#2 "steals" the attribute cert of George#1. I assume that by that he meant something like Al Arsenault's scenario, whereby George#2 gets a deliberately confusing certificate from a rogue CA, i.e., he did not simply steal George#1's private key.  I assume Polar understands, but I want to be sure.

Second, it should be obvious that the chain of trust from the root-level Attribute CA is every bit as important as the chain of trust involved in the identity CA chain.  If you don't trust the root, and every subordinate CA in the chain, with respect to some policy then you can hardly expect to trust the end-entity.  Unfortunately, adding more and more "trusted roots" to the various browsers and other relying party software makes the security weaker, not stronger -- a fact that the end users and some important vendors don't seem to have grasped yet.

But assuming that the Attribute CA's are credible, then the possibility of a collision in the issue name and serial number name space seems somewhat improbable, but not at all impossible.  In fact, an attacker could conceivably request certificates one at a time until a serial number collision did occur. Likewise, the DN name space could also collide. Maybe less likely in the case of someone named Jueneman or Arsenault, but highly likely in the case of a "Smith".

I'll confess that I have almost completely ignored the attribute certificate standards progression, because I am not yet sufficiently convinced as to the business case for such certificates to spend much time on them.

But I have to say that this seems like one case where our colleagues in the (moribund?) SPKI group may have a very valid point.  The connection between the attribute cert and the identity cert should not be based on the name, nor on the issuer/serial, but on the KEY contained in the identity cert, or better yet on a message digest of the entire referenced certificate.  

Assuming that is what the Object Digest represents, and based solely on my imperfect level of understanding, it seems to me that the DN and/or issuer/serial number relationship might be useful hints in trying to tack down the identity cert, but that the match MUST be based on an object digest of the entire certificate which is incorporated by reference.

Isn't that why digital signatures were invented, so we could validate more than just the name of a document, but actually validate the content?

Bob

>>> Al Arsenault <[e-mail]> 10/10/00 09:10AM >>>
Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example. 

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA". 
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

	- it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

	- it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

	- it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.




Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
> 
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
> 
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
> 
> In simplistic terms, With PKCs it's like saying:
> 
> "This is George Burns."
> 
> And with an Attribute Certificate, it's like saying:
> 
> "George has Cigars"
> 
> If you have a PKC that says
> 
> "This is George Bush"
> 
> Which George has the cigars?
> 
> Cheers,
> -Polar
> 
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik Fältström wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik Fältström, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[e-mail]>
> > > >To: [e-mail] 
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your application
> > > >does not have control over both clients and server, i.e. they both don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates are
> > > >signed by 5's public key. Here's one of my employees and his certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > >certificate to Henry Ford from General Motors so that he can access the
> > > >Holden plant through the Internet. It is clearly not enough that I just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number, then
> > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > >or not.  (Provided both the privilege service and target both trust the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates, which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]       2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com 
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 61 Fitzwilliam Lane,                    fax: [phone]
> > Dublin 2.                mailto:[e-mail] 
> > Ireland                             http://www.baltimore.com 
> >
> 
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05214 for <[e-mail]>; Tue, 10 Oct 2000 11:03:35 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id OAA28105; Tue, 10 Oct 2000 14:03:39 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 14:03:39 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: "Christopher S. Francis" <[e-mail]>
cc: Al Arsenault <[e-mail]>, Stephen Farrell <[e-mail]>, =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id LAA05216

Hi Al,

The issue that you point out, is outside the AC. The fact is that you need
a chain of PK certificates to verify the authenticity of the AC is a
Public Key verification issue of a statement. It only implies that the AC
came from an entity that you may or may not trust.

What you imply after that is what we are talking about.

Cheers,
-Polar
 
 On Tue, 10 Oct 2000, Christopher S. Francis wrote:

> Al,
> 
> I'm new here so forgive me if I'm missing something obvious, but in your
> example, doesn't the relying party have an obligation to verify the
> signature on the AC using a key that it is confident belongs to the Source
> Of Authority (or a key that can be traced back to an approved SOA)?  If the
> relying party in your example validates the AC in this way, the forged AC
> would fail the signature check.
> 
> What am I missing?
> 
> Christopher S. Francis
> WetStone Technologies, Inc.
> 935 Main Street, Suite A-1
> Safety Harbor, FL   34695
> [phone]
> http://www.wetstonetech.com/
> 
> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Tuesday, October 10, 2000 11:10 AM
> To: Polar Humenn
> Cc: Stephen Farrell; Patrik Fältström; [e-mail];
> [e-mail]
> Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
> andProxies
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising
> and
> > > if it is an issue then it also applies to public key certificates (I
> think
> > > this is more or less what Carlisle was saying is a previous response to
> the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
> Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your
> application
> > > > >does not have control over both clients and server, i.e. they both
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA,
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough
> to
> > > > >identify a holder, proxy, or target of the Attribute Certificate
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low
> on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates
> are
> > > > >signed by 5's public key. Here's one of my employees and his
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden
> Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can access
> the
> > > > >Holden plant through the Internet. It is clearly not enough that I
> just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
> such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can
> verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client
> using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number,
> then
> > > > >there wouldn't even be a question of whether the AC applied to Ian
> Botham
> > > > >or not.  (Provided both the privilege service and target both trust
> the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical
> or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates,
> which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04216 for <[e-mail]>; Tue, 10 Oct 2000 10:50:55 -0700 (PDT)
Received: by balinese.baltimore.ie; id SAA26400; Tue, 10 Oct 2000 18:55:22 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma026329; Tue, 10 Oct 00 18:55:14 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA19695; Tue, 10 Oct 2000 16:32:26 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 16:31:28 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: Polar Humenn <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id QAA19695
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA04219

Hi Al,

You've highlighted why this is *not* an AC issue. As you've correctly 
pointed out its a root CA information distribution issue and is addressed 
by rfc2459 and son-of-2459. If I can corrupt a relying party's store of 
root CA information, then I can do *lots* more damage than just try 
steal an existing AC.

If new security considerations belong anywhere then its in son-of-2459,
but that already says:

  "The quality of implementations that process certificates may also
   affect the degree of assurance provided.  The path validation algo-
   rithm described in section 6 relies upon the integrity of the trusted
   CA information, and especially the integrity of the public keys asso-
   ciated with the trusted CAs.  By substituting public keys for which
   an attacker has the private key, an attacker could trick the user
   into accepting false certificates."

I could possibly (just to kill the thread:-) buy including an equivalent 
paragraph in the AC profile, since its no harm in itself, but I don't want 
to start turning the security considerations section of the AC profile 
into a PKI tutorial - if we accepted that logic, then shouldn't the same 
paragraph then be present in all specifications that use PKI? Seems silly 
to me since one of the big reasons for PKIX existing in the first place
is to collect such things in one place.

On balance, I'd expect implementers of the AC profile to be familiar enough 
with PKI to know that root CA information has to be protected and would
prefer not to change the draft. ('Course if there's a consensus to do it,
I'll do it.)

Stephen.

Al Arsenault wrote:
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik Fältström wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik Fältström, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[e-mail]>
> > > > >To: [e-mail]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > > >-------------------------------------------------------------------
> > > > >Polar Humenn                  Adiron, LLC
> > > > >mailto:[e-mail]       2-212 CST
> > > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > > >Fax:   [phone]           http://www.adiron.com
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 61 Fitzwilliam Lane,                    fax: [phone]
> > > Dublin 2.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> > >
> >
> > -------------------------------------------------------------------
> > Polar Humenn                  Adiron, LLC
> > mailto:[e-mail]       2-212 CST
> > Phone: [phone]           Syracuse, NY 13244-4100
> > Fax:   [phone]           http://www.adiron.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from ponyexpress4.csc.com (ponyexpress4.csc.com [208.219.64.203]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02749 for <[e-mail]>; Tue, 10 Oct 2000 10:08:05 -0700 (PDT)
From: [e-mail]
Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress4.csc.com with esmtp (Exim 2.12 #1) id 13j1QT-0001mI-00; Tue, 10 Oct 2000 11:34:45 -0400
Subject: Re: Path Names to AC Holders, Targets and Proxies
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <OFC263BBDF.55CEA84C-ON85256974.0053141A@com>
Date: Tue, 10 Oct 2000 11:27:18 -0400
X-MIMETrack: Serialize by Router on VA-FCH31/SRV/CSC(Release 5.0.4a |July 24, 2000) at 10/10/2000 11:35:48 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Stephen,

You wrote:
> You've made a bad choice trusting that AA. Its operational practices
> are bad (actually apalling!).

Actually I think that Polar's point is that the imprecision in
the IETF names specification(s) takes the AA's policies and practices
out of the picture.  The existing specification doesn't allow the
AA to reliably specify an *interoperable*, well-defined and unique
name - even if it wants to!!

It seems (to me, at least) that the ISO already owns the fuzzy,
multi-option specifications space, so IETF specifications should
focus on specializing ISO specs to promote interoperability.

-DMC

--
Dave Chizmadia
Computer Sciences Corp.






Stephen Farrell <[e-mail]> on 10/10/2000 10:38:58 AM

Please respond to [e-mail]

To:   Polar Humenn <[e-mail]>
cc:   Russ Housley <[e-mail]>, [e-mail],
      [e-mail], [e-mail]
Subject:  Re: Path Names to AC Holders, Targets and Proxies



Polar,

Do you mean that you're willing to trust CAs to pick/certify non-colliding
values (names, keys,...), but not willing to so-trust *any* AA?

If that's so, don't use ACs.

> Let's say I want to use the attribute certificate for a proof of
purchase.
> The Attribute Certificate says "George" has listening rights to play
music
> from my site. He is a guy from a poor country that has spent real money
> to get this attribute certificate from third party service of which I
> trust, but of which I have no control. Another George steals the
attribute
> certificate and uses it at my site. Because George and George match, i
let
> him listen to the music. The first George didn't buy rights for "any"
> George to listen to his music.

You've made a bad choice trusting that AA. Its operational practices
are bad (actually apalling!).

Regards,
Stephen.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com







Received: from emerald.lightlink.com ([e-mail] [205.232.34.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01172 for <[e-mail]>; Tue, 10 Oct 2000 09:37:57 -0700 (PDT)
Received: from chrisf (perm70-18.ij.net [209.216.70.18] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id MAA29954; Tue, 10 Oct 2000 12:42:12 -0400
From: "Christopher S. Francis" <[e-mail]>
To: "Al Arsenault" <[e-mail]>, "Polar Humenn" <[e-mail]>
Cc: "Stephen Farrell" <[e-mail]>, =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Tue, 10 Oct 2000 12:52:24 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>

Al,

I'm new here so forgive me if I'm missing something obvious, but in your
example, doesn't the relying party have an obligation to verify the
signature on the AC using a key that it is confident belongs to the Source
Of Authority (or a key that can be traced back to an approved SOA)?  If the
relying party in your example validates the AC in this way, the forged AC
would fail the signature check.

What am I missing?

Christopher S. Francis
WetStone Technologies, Inc.
935 Main Street, Suite A-1
Safety Harbor, FL   34695
[phone]
http://www.wetstonetech.com/

-----Original Message-----
From: Al Arsenault [mailto:[e-mail]]
Sent: Tuesday, October 10, 2000 11:10 AM
To: Polar Humenn
Cc: Stephen Farrell; Patrik Fältström; [e-mail];
[e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example.

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA".
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

        - it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

        - it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

        - it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

                        Al Arsenault
                        Chief Security Architect
                        Diversinet Corp.




Polar Humenn wrote:
>
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
>
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising
and
> > if it is an issue then it also applies to public key certificates (I
think
> > this is more or less what Carlisle was saying is a previous response to
the
> > PKIX list).
>
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
>
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
>
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
>
> In simplistic terms, With PKCs it's like saying:
>
> "This is George Burns."
>
> And with an Attribute Certificate, it's like saying:
>
> "George has Cigars"
>
> If you have a PKC that says
>
> "This is George Bush"
>
> Which George has the cigars?
>
> Cheers,
> -Polar
>
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik Fältström wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik Fältström, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[e-mail]>
> > > >To: [e-mail]
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your
application
> > > >does not have control over both clients and server, i.e. they both
don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of
naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA,
and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough
to
> > > >identify a holder, proxy, or target of the Attribute Certificate
because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low
on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates
are
> > > >signed by 5's public key. Here's one of my employees and his
certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For
example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden
Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a
attribute
> > > >certificate to Henry Ford from General Motors so that he can access
the
> > > >Holden plant through the Internet. It is clearly not enough that I
just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can
verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client
using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry
Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number,
then
> > > >there wouldn't even be a question of whether the AC applied to Ian
Botham
> > > >or not.  (Provided both the privilege service and target both trust
the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to
include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical
or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates,
which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]       2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 61 Fitzwilliam Lane,                    fax: [phone]
> > Dublin 2.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com
> >
>
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com



Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27495 for <[e-mail]>; Tue, 10 Oct 2000 08:53:23 -0700 (PDT)
Received: from plipp [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id ABF712A02A6; Tue, 10 Oct 2000 17:55:35 +0200
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Christian. Vogel" <[e-mail]>
Subject: AW: Experimental TSA by iaik graz
Date: Tue, 10 Oct 2000 17:57:31 +0200
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>

>Some time ago there was an announcement about an experimental time stamping
>service provided by the University of Graz.
>
>Is this service still running?

Currently it is not, we have had some machine-changes, but plan to have it
up again on a more stable machine asap. We will keep you informed

Peter



Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23423 for <[e-mail]>; Tue, 10 Oct 2000 08:26:03 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA25509; Wed, 11 Oct 2000 04:30:00 +1300 (NZDT) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97119180518322>; Wed, 11 Oct 2000 04:30:05 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Experimental TSA by iaik graz
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 11 Oct 2000 04:30:05 (NZDT)
Message-ID: <[e-mail]>

Peter Sylvester <[e-mail]> writes:

>Some time ago there was an announcement about an experimental time stamping
>service provided by the University of Graz.
>
>Is this service still running?

Not that I know of, it was one of the ones I tried, the server seems to have
gone away and mail to the person involved bounced.

Peter.



Received: from mail.rdc1.md.home.com ([e-mail] [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20553 for <[e-mail]>; Tue, 10 Oct 2000 08:04:27 -0700 (PDT)
Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <[e-mail]>; Tue, 10 Oct 2000 08:08:55 -0700
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 11:10:14 -0400
From: Al Arsenault <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.61 [en]C-AtHome0407  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: Stephen Farrell <[e-mail]>, "Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?=" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example. 

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA". 
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

	- it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

	- it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

	- it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.




Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
> 
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
> 
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
> 
> In simplistic terms, With PKCs it's like saying:
> 
> "This is George Burns."
> 
> And with an Attribute Certificate, it's like saying:
> 
> "George has Cigars"
> 
> If you have a PKC that says
> 
> "This is George Bush"
> 
> Which George has the cigars?
> 
> Cheers,
> -Polar
> 
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik Fältström wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik Fältström, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[e-mail]>
> > > >To: [e-mail]
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your application
> > > >does not have control over both clients and server, i.e. they both don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates are
> > > >signed by 5's public key. Here's one of my employees and his certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > >certificate to Henry Ford from General Motors so that he can access the
> > > >Holden plant through the Internet. It is clearly not enough that I just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number, then
> > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > >or not.  (Provided both the privilege service and target both trust the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates, which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[e-mail]       2-212 CST
> > > >Phone: [phone]           Syracuse, NY 13244-4100
> > > >Fax:   [phone]           http://www.adiron.com
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 61 Fitzwilliam Lane,                    fax: [phone]
> > Dublin 2.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com
> >
> 
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[e-mail]       2-212 CST
> Phone: [phone]           Syracuse, NY 13244-4100
> Fax:   [phone]           http://www.adiron.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18945 for <[e-mail]>; Tue, 10 Oct 2000 07:35:05 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA19598; Tue, 10 Oct 2000 15:39:32 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma019507; Tue, 10 Oct 00 15:39:02 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA17940; Tue, 10 Oct 2000 15:39:57 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 15:38:58 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: Russ Housley <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Path Names to AC Holders, Targets and Proxies
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar,

Do you mean that you're willing to trust CAs to pick/certify non-colliding 
values (names, keys,...), but not willing to so-trust *any* AA? 

If that's so, don't use ACs.

> Let's say I want to use the attribute certificate for a proof of purchase.
> The Attribute Certificate says "George" has listening rights to play music
> from my site. He is a guy from a poor country that has spent real money
> to get this attribute certificate from third party service of which I
> trust, but of which I have no control. Another George steals the attribute
> certificate and uses it at my site. Because George and George match, i let
> him listen to the music. The first George didn't buy rights for "any"
> George to listen to his music.

You've made a bad choice trusting that AA. Its operational practices
are bad (actually apalling!). 

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18058 for <[e-mail]>; Tue, 10 Oct 2000 07:22:56 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA16441; Tue, 10 Oct 2000 15:27:22 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma016374; Tue, 10 Oct 00 15:26:58 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA17557; Tue, 10 Oct 2000 15:27:57 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 15:26:59 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Polar Humenn <[e-mail]>
CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Polar,

Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.

Quoting from the end of 4.2.2:

  "Any protocol conforming to this profile SHOULD specify which AC
   holder option is to be used and how this fits with the supported
   authentication schemes defined in that protocol."

Clearly, possession of an AC is not enough to claim the privileges
contained therein, so authentication is required. If your "vulnerability" 
depends on the relying party not being able to distinguish between 
different AC holders at the authentication stage then I think the 
problem lies outside of the use of ACs and hence doesn't affect this 
profile.

The AC profile only talks about the use of PKCs as an authentication
mechanism (since this is PKIX). The profile says that holder SHOULD use
the baseCertificateID choice. This means your problem amounts to the 
case where a relying party (in PKI terms) trusts two *different* CAs with 
the same name who've issued PKCs with the same serial number where one 
party has intentionally grabbed the other's AC and is claiming its 
privilege. Aside from not being convinced, this leads back to my 
original point that you're talking about a putative problem with that
relying party's PKI, not to do with ACs (e.g. how could it get 
revocation status, how could it figure out who'd signed an email, etc.)

If the RP chooses to trust an AA then effectively it is choosing to
trust that AA's holder field. I'm sure that if and when ACs become
as widespread as PKCs, then concepts like CPS will be elaborated. At
that point your concerns get addressed, not in the profile.

> For a contrived example...

Real examples are more convincing.

> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Every time you write something like that you loose me entirely.

[..."George" omitted...]

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17378 for <[e-mail]>; Tue, 10 Oct 2000 07:06:34 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA27753; Tue, 10 Oct 2000 10:06:54 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 10:06:53 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Russ Housley <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Path Names to AC Holders, Targets and Proxies 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 8 Oct 2000, Russ Housley wrote:

> Polar:
> 
> >I have some questions about total interoperability about the PKIX
> >Attribute Certificate when used in environments where your application
> >does not have control over both clients and server, i.e. they both don't
> >subscribe to the same LDAP server.
> >
> >I have some problems regarding the use of GeneralName for the Holder,
> >Proxies and Targets fields of the AttributeCertificate.
> >
> >When using DN's for these names, they only specify one level of naming.
> >That is, they do not specify the Identity Chain, (i.e. path) upto a
> >certain authority. Specifically, they do not name the Holder's CA, and its
> >CA, and so on.
> 
> This is intentional.  In these cases, we want to bind the attribute to any 
> certificate issued to that identity.  

I don't think that particular is a good idea. That destroys the entire
notion of binding an identity to a certificate for the purposes of
identifying any thing and blows RFC 2459 out of the water. If that is an
intention, it is a misuse, and there should be steps taken in the standard
to prevent that type of misuse. Yuck!

> If identity collisions are possible in your environment, then the
> attributes should be bound to an issuer/serial number pair instead of
> a General Name.

I'm not talking about "my" environment. I'm looking at the entire world of
interoperability. If I had my environment, what would I even need a
standard for an AttributeCertificate for? 

If I had my environment, I would state that there would be critical
extensions to these Attribute certificates so that the paths to the holder
would be complete. However, what good does that do, in an interoperable
environment where you are handed an attribute certificate from some
service that doesn't complete the name.

I'm looking at the case of where I want to accept third party attribute
services of which I trust, but I which I have no control.  I want them to
adhere to standards.

Let's say I want to use the attribute certificate for a proof of purchase.
The Attribute Certificate says "George" has listening rights to play music
from my site. He is a guy from a poor country that has spent real money
to get this attribute certificate from third party service of which I
trust, but of which I have no control. Another George steals the attribute
certificate and uses it at my site. Because George and George match, i let
him listen to the music. The first George didn't buy rights for "any"
George to listen to his music.

I'm not talking about likelihood. I'm talking about VERIFIABLE Security.

> RFC 2459 requires that X.500 distinguished names be present for issuer
> names.  And, in real world implementations, they should include
> significantly more information than a simple common name.

RFC 2459 doesn't imply any structure similarity between the subject's DN
and the issuer's DN. Therefore nothing of the sort can be assumed. Having
more elements in the DN doesn't mean a thing mathematically. It's just a
blob of data, no matter how big or how small. My use of a simple common
name was only to make the problem understandable. I don't care if you had
128 RDNs in there. It's the same thing.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16717 for <[e-mail]>; Tue, 10 Oct 2000 06:53:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA11664 for <[e-mail]>; Tue, 10 Oct 2000 15:57:41 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 10 Oct 2000 15:57:41 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA16282 for <[e-mail]>; Tue, 10 Oct 2000 15:57:40 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA29237 for [e-mail]; Tue, 10 Oct 2000 15:57:39 +0200 (MET DST)
Date: Tue, 10 Oct 2000 15:57:39 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Experimental TSA by iaik graz

Some time ago there was an announcement about an experimental
time stamping service provided by the University of Graz.

Is this service still running? 


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15762 for <[e-mail]>; Tue, 10 Oct 2000 06:28:32 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id JAA27689; Tue, 10 Oct 2000 09:28:47 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Tue, 10 Oct 2000 09:28:46 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Stephen Farrell <[e-mail]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id GAA15765

On Sun, 8 Oct 2000, Stephen Farrell wrote:

> 
> Hi,
> 
> As I've said to Polar previously, I don't see what issue he's raising and
> if it is an issue then it also applies to public key certificates (I think 
> this is more or less what Carlisle was saying is a previous response to the
> PKIX list).

As I have said before. I do not have a problem with PK certificates
because they are usually accompanied by *Verifying* certificates. Even if
you only get one public key certificate for a subject say from a client
program, you must *have* the issuer's certificate to verify it. 

For a contrived example, say you may could have two different issuer PKCs
with the same DN. Only one of those certificates will verify the subject's
certificate. That argument recursively completes the naming path to its
root.

With the AttributeCertificate it is different, because you only name the
"Holder", and not the path from its root, which is indeed its entire name.
In the attribute certificate there is no "Holder" certificate that can be
verified. There is no other evidence tying the holder to its issuer
completing its name. Therefore, there is abolutely no definiative way to
complete its entire name. Even if you use the Issuer-Serial form, the name
of the Issuer has the same problem. The only time that works is when the
issuer of the holder's identity is a root CA. The issuer of the holder's
identity might be a CA other than a root CA.

In simplistic terms, With PKCs it's like saying:

"This is George Burns."

And with an Attribute Certificate, it's like saying:

"George has Cigars"

If you have a PKC that says

"This is George Bush"

Which George has the cigars?

Cheers,
-Polar




> Acrtually, maybe this is clearly shown from Polar's suggestion that the
> "fix" is to change the definition of GeneralName (and hence the base
> X.509-2000 and rfc2459 as well as the AC profile).
> 
> Maybe its me - can anyone else see the issue?
> 
> Regards,
> Stephen.
> 
> Patrik Fältström wrote:
> > 
> > This should be discussed on the PKIX mailing list.
> > 
> > Please discuss...
> > 
> >      Patrik Fältström, Area Director Applications Area, IETF
> > 
> > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > >From: Polar Humenn <[e-mail]>
> > >To: [e-mail]
> > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > >
> > >
> > >
> > >Greetings IETF,
> > >
> > >This is Polar Humenn with the Object Management Group (OMG).
> > >
> > >I have some questions about total interoperability about the PKIX
> > >Attribute Certificate when used in environments where your application
> > >does not have control over both clients and server, i.e. they both don't
> > >subscribe to the same LDAP server.
> > >
> > >I have some problems regarding the use of GeneralName for the Holder,
> > >Proxies and Targets fields of the AttributeCertificate.
> > >
> > >When using DN's for these names, they only specify one level of naming.
> > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > >certain authority. Specifically, they do not name the Holder's CA, and its
> > >CA, and so on.
> > >
> > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > >identify a holder, proxy, or target of the Attribute Certificate because
> > >it has the same problem in identifying the issuer.
> > >
> > >Let me illustrate a security hole that this specification has:
> > >
> > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > >the totem pole, because of my organizational structure. My identity
> > >certificate has a path from a real trusted authority, such as:
> > >
> > >1. CN=Baltimore
> > >2. CN=General Motors
> > >3. CN=Manufacturing
> > >4. CN=Engineering, L=Germany
> > >5. CN=Human Resources
> > >
> > >All my employee identities are defined by 5 and their certificates are
> > >signed by 5's public key. Here's one of my employees and his certificate
> > >serial number:
> > >
> > >6. CN=Henry Ford      Serial#=1234
> > >
> > >I obviously listed the chain with 1 as the most significant. For example,
> > >if Henry authenticates via TLS, he delivers a chain of these 6
> > >certificates.
> > >
> > >And now for something completely different, let's switch to Holden Car
> > >Company, Australia.
> > >
> > >The privilege service that Holden subscribes to wants to issue a attribute
> > >certificate to Henry Ford from General Motors so that he can access the
> > >Holden plant through the Internet. It is clearly not enough that I just
> > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > >as:
> > >
> > >CN=Human Resources
> > >Serial#=1234
> > >
> > >I really have to fully define the path of the holder so that we can verify
> > >that the attribute certificate actually applies to the identity I am
> > >presented with.
> > >
> > >For a contrived example, let's say the GM has authenticated a client using
> > >SSL, and the plant has Versign's verification certificate (i.e.
> > >CN=Verisign). The authentication provides me with the following cert
> > >chain, which the GM plant has verified:
> > >
> > >1. CN=Verisign
> > >2. CN=Holden
> > >3. CN=Human Resources
> > >4. CN=Ian Botham, Serial#=1234
> > >
> > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > >
> > >Does it match? Yes, it sure does.
> > >Should this happen? Obviously not.
> > >
> > >I know it's a bit contrived, but it is a security hole.
> > >
> > >Now, if the Holder contained the name path to that serial number, then
> > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > >or not.  (Provided both the privilege service and target both trust the
> > >same named high-level certificates, such as Verisign or Baltimore for
> > >verification).
> > >
> > >The same goes for the naming of the targets and proxies.
> > >
> > >The problem exists for regular DN naming as their may be two CN=Henry
> > >Fords at both GM and Holden.
> > >
> > >What can we do about this problem?
> > >
> > >I would suggest either changing the definition of GeneralName to include
> > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > >non-critical?) that complete the path from the Holder, proxies, or
> > >targets.
> > >
> > >I do not have a problem with the Issuer of the Attribute Certificate,
> > >because that will be followed by some verifying PK certificates, which
> > >consequently defines the issuers name path.
> > >
> > >Any comments?
> > >
> > >Cheers and Thanks,
> > >-Polar
> > >
> > >-------------------------------------------------------------------
> > >Polar Humenn                  Adiron, LLC
> > >mailto:[e-mail]       2-212 CST
> > >Phone: [phone]           Syracuse, NY 13244-4100
> > >Fax:   [phone]           http://www.adiron.com
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 61 Fitzwilliam Lane,                    fax: [phone]
> Dublin 2.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11817 for <[e-mail]>; Tue, 10 Oct 2000 04:21:54 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA158676; Tue, 10 Oct 2000 13:31:36 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA06608; Tue, 10 Oct 2000 13:25:47 +0200
Message-ID: <[e-mail]>
Date: Tue, 10 Oct 2000 13:25:48 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

> Denis:
> 
> I am happy with your response to number 3.  Now, for number 10.  How about
> something like the following:
> 
>      For the <list your types here> MIME types, implementations SHOULD

I did not realized first why you were leaving the types empty, :-)
... until I found the acronym collision between
application/timestamp-request (TSR) and application/timestamp-response
(TSR).

Here is a proposal to solve this acronym collision:

For the application/timestamp-query and application/timestamp-reply MIME
types, implementations SHOULD include the optional "name" and "filename"
parameters. Including a file name serves helps preserve type information
when timestamps are saved as files.  When these parameters are included, a
file name with the appropriate extension SHOULD be selected:

       MIME Type                     File Extension

  application/timestamp-query            .TSQ
  application/timestamp-reply            .TSR

In addition, the file name SHOULD be limited to eight characters followed by
a three letter extension. The eight character filename base can be any
distinct name.

Would that text be OK with you ?

Regards,

Denis

>      include the optional "name" and "filename" parameters.  Including a
>      file name serves helps preserve type information when timestamps are
>      saved as files.  When these parameters are included, a file name with
>      the appropriate extension SHOULD be selected:
> 
>        MIME Type                     File Extension
> 
>          <your request type>           .<your request extension>
> 
>          <your response type>          .<your response extension>
> 
>          ...
> 
>      In addition, the file name SHOULD be limited to eight characters
>      followed by a three letter extension. The eight character filename
>      base can be any distinct name.
> 
> Russ


Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03578 for <[e-mail]>; Mon, 9 Oct 2000 23:53:12 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2650.21) id <4RBM51PP>; Tue, 10 Oct 2000 08:57:09 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>, "'Peter Sylvester'" <[e-mail]>
Subject: R: R: TSP: Response to the comments raised by Russ Housley
Date: Tue, 10 Oct 2000 08:57:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA03579

The response is actually *not* just a CMS message, as Sylvester rightly
pointed out. I just made a trivial mistake in my previous comment. So the
issue of  file extensions is worth discussing (not for long, though). The
issue about MIME type instead is not, because application/timestamp has been
already defined. Perhaps we can think of adding subtypes and arguments to
the MIME content-type (eg to distinguish requests from responses), but
that's probably not so critical an issue. What I strongly believe is that
the draft should now brought on to RFC status asap. Too much time has
passed, and the community needs a stable standard (especially in Europe,
where digital signatures are supposed to be strengthened and prolonged in
time with timestamps); maybe we do not have the most perfect standard of all
time, but perfection is unreachable and unnecessary; let's work with this
one and see what happens.

Adriano

SIA S.p.A.
Milano, IT/EU
https://ca.sia.it

-----Messaggio originale-----
Da: Russ Housley [mailto:[e-mail]]
Inviato: lunedì 9 ottobre 2000 23.07
A: Santoni Adriano
Cc: Denis Pinkas; IETF-PXIX
Oggetto: Re: R: TSP: Response to the comments raised by Russ Housley


If the response is just a CMS SignedData message, then do not assign a new 
MIME type.  Use the ones already defined in RFC 2633.

Russ


At 09:16 AM 10/09/2000 +0200, Santoni Adriano wrote:
>Is it really useful to tell apart requests vs. responses? From the TSP
>server viewpoint, an incoming message is supposed to be a request and it
>will be processed based on that obvious assumption. So the single
>content-type "application/timestamp" should suffice, IMO. As to file
>extensions, I think it's pretty irrilevant; however, as the response is a
>CMS SignedData message, I presume ".P7M" would be a proper file extension
>for it. As to the request...I do not know; why not ".TSR" ?
>
>Adriano Santoni
>
>SIA S.p.A.
>Milano, IT
>https://ca.sia.it <https://ca.sia.it>
>
>
>-----Messaggio originale-----
>Da: Russ Housley [mailto:[e-mail]]
>Inviato: venerdì 6 ottobre 2000 20.11
>A: Denis Pinkas
>Cc: IETF-PXIX
>Oggetto: Re: TSP: Response to the comments raised by Russ Housley
>
>
>Denis:
>
>I am happy with your response to number 3.  Now, for number 10.  How about
>something like the following:
>
>
>For the <list your types here> MIME types, implementations SHOULD include
>the optional "name" and "filename" parameters.  Including a file name
serves
>helps preserve type information when timestamps are saved as files.  When
>these parameters are included, a file name with the appropriate extension
>SHOULD be selected:
>
>
>
>   MIME Type                     File Extension
>
>
>
>     <your request type>           .<your request extension>
>
>
>
>     <your response type>          .<your response extension>
>
>
>
>     ...
>
>
>
>In addition, the file name SHOULD be limited to eight characters followed
by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>
>
>Russ
>
>
>At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:
>
>
>Russ,
>
>Thank you for your response.
>
>The only remaining issues are numbered 3 and 10. See my comments embedded
>below.
>
> > Denis:
> >
> > Thank you for addressing my concerns.  I address each of your proposed
> > resolutions below.
> >
> > TECHNICAL
> >
> > 1 and 2. Your proposed resolution resolves my concern.
> >
> > 3. I am not satisfied.  I accept that this is not the place to define
TSP
> > policy or practice statements.  However, I do not think that the RFC
2459
> > syntax is appropriate for use in the TSP context.  Also, you ignored my
> > concern regarding qualifiers.  RFC 2459 contains:
> >
> >     PolicyInformation ::= SEQUENCE {
> >          policyIdentifier   CertPolicyId,
> >          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
> >                                  PolicyQualifierInfo OPTIONAL }
> >
> > I would prefer a structure that said "TSAPolicyId" instead of
> > "CertPolicyId." Using "CertPolicyId" in this context will, in my
opinion,
> > confuse matters.  Also, I would like to omit policy qualifiers
> > altogether.  I do not like them in certificate policies, and I would
like
> > to avoid them in TSA policies.
>
>I had corrected the text but I did not understood your were also requesting
>an ASN.1 change.
>Sorry about that misunderstanding. I agree with your request and I have
done
>the changes, i.e:
>
>  TSAPolicyId ::= OBJECT IDENTIFIER
>
>and in the request:
>
>  reqPolicy       TSAPolicyId    OPTIONAL,
>
>while in the response:
>
>  policy          TSAPolicyId,
>
> > 4 through 9. Your proposed resolution resolves my concern.
> >
> > 10. This comment is related to comment number 9, but it has absolutely
> > nothing to do with flow.  It has to do with the specification of file
> > naming conventions.  I would like to see a section that is parallel to
RFC
> > 2633, Section 3.2.1.  Further, I think that that file naming conventions
> > should be labeled SHOULD, not MUST.
>
>I understand the last sentence of your request, but I'm not sure what you
>are requesting for the remaining of it-- all the text in Section 3.2.1 of
>2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
>would like to see something similar to the paragraph regarding base name
>(i.e., 8 characters, can be any distinct name, ..) although many systems
>today are no more limited to 8 characters. :-) If you want some specific
>addition, would you be able to propose it ?
>
>Regards,
>
>Denis
>
> > 11. Fair enough; CMP should include a state machine too.  I believe that
> > many interoperability issues can be avoided by specifying the state
> > machine.  I am not going to hold things up over this issue.
> >
> > 12 and 13. Your proposed resolution resolves my concern.
> >
> > EDITORIAL
> >
> > 14 and 15. Your proposed resolution resolves my concern.
> >
> > 16. Okay.  As I said, this is an editorial comment, so I can live with
the
> > current text.
> >
> > 17 through 24. Your proposed resolution resolves my concern.
> >
> > Russ


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20712 for <[e-mail]>; Mon, 9 Oct 2000 14:14:48 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA04991; Mon, 9 Oct 2000 14:17:29 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 09 Oct 2000 17:06:46 -0400
To: Santoni Adriano <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: R: TSP: Response to the comments raised by Russ Housley
Cc: Denis Pinkas <[e-mail]>, IETF-PXIX <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

If the response is just a CMS SignedData message, then do not assign a new 
MIME type.  Use the ones already defined in RFC 2633.

Russ


At 09:16 AM 10/09/2000 +0200, Santoni Adriano wrote:
>Is it really useful to tell apart requests vs. responses? From the TSP
>server viewpoint, an incoming message is supposed to be a request and it
>will be processed based on that obvious assumption. So the single
>content-type "application/timestamp" should suffice, IMO. As to file
>extensions, I think it's pretty irrilevant; however, as the response is a
>CMS SignedData message, I presume ".P7M" would be a proper file extension
>for it. As to the request...I do not know; why not ".TSR" ?
>
>Adriano Santoni
>
>SIA S.p.A.
>Milano, IT
>https://ca.sia.it <https://ca.sia.it>
>
>
>-----Messaggio originale-----
>Da: Russ Housley [mailto:[e-mail]]
>Inviato: venerdì 6 ottobre 2000 20.11
>A: Denis Pinkas
>Cc: IETF-PXIX
>Oggetto: Re: TSP: Response to the comments raised by Russ Housley
>
>
>Denis:
>
>I am happy with your response to number 3.  Now, for number 10.  How about
>something like the following:
>
>
>For the <list your types here> MIME types, implementations SHOULD include
>the optional "name" and "filename" parameters.  Including a file name serves
>helps preserve type information when timestamps are saved as files.  When
>these parameters are included, a file name with the appropriate extension
>SHOULD be selected:
>
>
>
>   MIME Type                     File Extension
>
>
>
>     <your request type>           .<your request extension>
>
>
>
>     <your response type>          .<your response extension>
>
>
>
>     ...
>
>
>
>In addition, the file name SHOULD be limited to eight characters followed by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>
>
>Russ
>
>
>At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:
>
>
>Russ,
>
>Thank you for your response.
>
>The only remaining issues are numbered 3 and 10. See my comments embedded
>below.
>
> > Denis:
> >
> > Thank you for addressing my concerns.  I address each of your proposed
> > resolutions below.
> >
> > TECHNICAL
> >
> > 1 and 2. Your proposed resolution resolves my concern.
> >
> > 3. I am not satisfied.  I accept that this is not the place to define TSP
> > policy or practice statements.  However, I do not think that the RFC 2459
> > syntax is appropriate for use in the TSP context.  Also, you ignored my
> > concern regarding qualifiers.  RFC 2459 contains:
> >
> >     PolicyInformation ::= SEQUENCE {
> >          policyIdentifier   CertPolicyId,
> >          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
> >                                  PolicyQualifierInfo OPTIONAL }
> >
> > I would prefer a structure that said "TSAPolicyId" instead of
> > "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> > confuse matters.  Also, I would like to omit policy qualifiers
> > altogether.  I do not like them in certificate policies, and I would like
> > to avoid them in TSA policies.
>
>I had corrected the text but I did not understood your were also requesting
>an ASN.1 change.
>Sorry about that misunderstanding. I agree with your request and I have done
>the changes, i.e:
>
>  TSAPolicyId ::= OBJECT IDENTIFIER
>
>and in the request:
>
>  reqPolicy       TSAPolicyId    OPTIONAL,
>
>while in the response:
>
>  policy          TSAPolicyId,
>
> > 4 through 9. Your proposed resolution resolves my concern.
> >
> > 10. This comment is related to comment number 9, but it has absolutely
> > nothing to do with flow.  It has to do with the specification of file
> > naming conventions.  I would like to see a section that is parallel to RFC
> > 2633, Section 3.2.1.  Further, I think that that file naming conventions
> > should be labeled SHOULD, not MUST.
>
>I understand the last sentence of your request, but I'm not sure what you
>are requesting for the remaining of it-- all the text in Section 3.2.1 of
>2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
>would like to see something similar to the paragraph regarding base name
>(i.e., 8 characters, can be any distinct name, ..) although many systems
>today are no more limited to 8 characters. :-) If you want some specific
>addition, would you be able to propose it ?
>
>Regards,
>
>Denis
>
> > 11. Fair enough; CMP should include a state machine too.  I believe that
> > many interoperability issues can be avoided by specifying the state
> > machine.  I am not going to hold things up over this issue.
> >
> > 12 and 13. Your proposed resolution resolves my concern.
> >
> > EDITORIAL
> >
> > 14 and 15. Your proposed resolution resolves my concern.
> >
> > 16. Okay.  As I said, this is an editorial comment, so I can live with the
> > current text.
> >
> > 17 through 24. Your proposed resolution resolves my concern.
> >
> > Russ



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08345 for <[e-mail]>; Mon, 9 Oct 2000 06:15:24 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA00471; Mon, 9 Oct 2000 15:19:36 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 9 Oct 2000 15:19:36 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA11589; Mon, 9 Oct 2000 15:19:34 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA28737; Mon, 9 Oct 2000 15:19:33 +0200 (MET DST)
Date: Mon, 9 Oct 2000 15:19:33 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: R: R: TSP: Response to the comments raised by Russ Housley
Cc: [e-mail]

> 
> You are right; I made a mistake. The response is not just a CMS msg, so =
> the
> "P7M" extensions would not do.
> 
> How about "TSR" for the request and "TST" for the response?
> 

TST seems to indicate a 'time stamp token'. Since the response is
not a time stamp token, this would be even more misleading.


 

 


Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07831 for <[e-mail]>; Mon, 9 Oct 2000 05:58:55 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2650.21) id <4RBM5CD9>; Mon, 9 Oct 2000 15:02:47 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: R: R: TSP: Response to the comments raised by Russ Housley
Date: Mon, 9 Oct 2000 15:02:40 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA07832

You are right; I made a mistake. The response is not just a CMS msg, so the
"P7M" extensions would not do.

How about "TSR" for the request and "TST" for the response?

A

-----Messaggio originale-----
Da: Peter Sylvester [mailto:[e-mail]]
Inviato: lunedì 9 ottobre 2000 10.47
A: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Oggetto: Re: R: TSP: Response to the comments raised by Russ Housley


> 
> Is it really useful to tell apart requests vs. responses? From the TSP
> server viewpoint, an incoming message is supposed to be a request and it
> will be processed based on that obvious assumption. So the single
> content-type "application/timestamp" should suffice, IMO. As to file
> extensions, I think it's pretty irrilevant; however, as the response is a
> CMS SignedData message, I presume ".P7M" would be a proper file extension
> for it. As to the request...I do not know; why not ".TSR" ?

The response is NOT a CMS signeddata. The time stamp token, which
is embedded in the response is a CMS signeddata. 

 


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07309 for <[e-mail]>; Mon, 9 Oct 2000 05:39:01 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id FAA25757; Mon, 9 Oct 2000 05:42:17 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 08 Oct 2000 13:24:22 -0400
To: Polar Humenn <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Path Names to AC Holders, Targets and Proxies 
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail] >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Polar:

>I have some questions about total interoperability about the PKIX
>Attribute Certificate when used in environments where your application
>does not have control over both clients and server, i.e. they both don't
>subscribe to the same LDAP server.
>
>I have some problems regarding the use of GeneralName for the Holder,
>Proxies and Targets fields of the AttributeCertificate.
>
>When using DN's for these names, they only specify one level of naming.
>That is, they do not specify the Identity Chain, (i.e. path) upto a
>certain authority. Specifically, they do not name the Holder's CA, and its
>CA, and so on.

This is intentional.  In these cases, we want to bind the attribute to any 
certificate issued to that identity.  If identity collisions are possible 
in your environment, then the attributes should be bound to an 
issuer/serial number pair instead of a General Name.  RFC 2459 requires 
that X.500 distinguished names be present for issuer names.  And, in real 
world implementations, they should include significantly more information 
than a simple common name.

>Even using the Issuer-Serial type of GeneralName is not good enough to
>identify a holder, proxy, or target of the Attribute Certificate because
>it has the same problem in identifying the issuer.

I disagree.  The names that you ave chosen only include common name.  In 
real life, distinguished names, Internet domain names, and RFC 822 names 
all include much more information.

>[much text deleted]
>
>1. CN=Baltimore
>2. CN=General Motors
>3. CN=Manufacturing
>4. CN=Engineering, L=Germany
>5. CN=Human Resources
>6. CN=Henry Ford      Serial#=1234

A more likely distinguished name for the issuer of certificate number 6 is:
         c=US, o=GM, ou=Mfgr, ou= German Engr, cn=HR
A collision with this name is much less likely.

>[much text deleted]
>
>1. CN=Verisign
>2. CN=Holden
>3. CN=Human Resources
>4. CN=Ian Botham, Serial#=1234

Again, a much more likely name for the issuer of certificate 4 is:
         c=AU, o=Holden, ou=HR

Russ



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00269 for <[e-mail]>; Mon, 9 Oct 2000 01:43:51 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA28269; Mon, 9 Oct 2000 10:47:15 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 9 Oct 2000 10:47:15 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA10540; Mon, 9 Oct 2000 10:46:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA28622; Mon, 9 Oct 2000 10:46:37 +0200 (MET DST)
Date: Mon, 9 Oct 2000 10:46:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: R: TSP: Response to the comments raised by Russ Housley
Cc: [e-mail]

> 
> Is it really useful to tell apart requests vs. responses? From the TSP
> server viewpoint, an incoming message is supposed to be a request and it
> will be processed based on that obvious assumption. So the single
> content-type "application/timestamp" should suffice, IMO. As to file
> extensions, I think it's pretty irrilevant; however, as the response is a
> CMS SignedData message, I presume ".P7M" would be a proper file extension
> for it. As to the request...I do not know; why not ".TSR" ?

The response is NOT a CMS signeddata. The time stamp token, which
is embedded in the response is a CMS signeddata. 

 


Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28127 for <[e-mail]>; Mon, 9 Oct 2000 00:25:49 -0700 (PDT)
Received: from kiku.itsise (kiku.itsise [192.168.2.2]) by atsgw.cyber.ee (8.8.3/8.7.3) with ESMTP id JAA13556 for <[e-mail]>; Mon, 9 Oct 2000 09:30:10 +0200
Received: from cyber.ee (dino.itsise [192.168.2.137]) by kiku.itsise (8.9.1a/8.9.1) with ESMTP id JAA03886 for <[e-mail]>; Mon, 9 Oct 2000 09:29:57 +0200
Message-ID: <[e-mail]>
Date: Mon, 09 Oct 2000 09:30:11 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: PKIX list <[e-mail]>
Subject: Transport protocol for OCSP ver. 2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello.

Which TCP-based transport protocol is used for OCSP version 2?  The
draft doesn't contain any information about that.  Will it be the old
one that is specified in older OCSP RFC or will it be like in
draft-ietf-pkix-cmp-transport-protocols-02.txt?

-- 
Margus Freudenthal                            [e-mail]
Cybernetica                                   http://www.cyber.ee/


Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA27638 for <[e-mail]>; Mon, 9 Oct 2000 00:12:19 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2650.21) id <4RBMZ0P2>; Mon, 9 Oct 2000 09:16:10 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: R: TSP: Response to the comments raised by Russ Housley
Date: Mon, 9 Oct 2000 09:16:09 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA27639

Is it really useful to tell apart requests vs. responses? From the TSP
server viewpoint, an incoming message is supposed to be a request and it
will be processed based on that obvious assumption. So the single
content-type "application/timestamp" should suffice, IMO. As to file
extensions, I think it's pretty irrilevant; however, as the response is a
CMS SignedData message, I presume ".P7M" would be a proper file extension
for it. As to the request...I do not know; why not ".TSR" ?
 
Adriano Santoni
 
SIA S.p.A.
Milano, IT
https://ca.sia.it <https://ca.sia.it>  
 

-----Messaggio originale-----
Da: Russ Housley [mailto:[e-mail]]
Inviato: venerdì 6 ottobre 2000 20.11
A: Denis Pinkas
Cc: IETF-PXIX
Oggetto: Re: TSP: Response to the comments raised by Russ Housley


Denis:

I am happy with your response to number 3.  Now, for number 10.  How about
something like the following:


For the <list your types here> MIME types, implementations SHOULD include
the optional "name" and "filename" parameters.  Including a file name serves
helps preserve type information when timestamps are saved as files.  When
these parameters are included, a file name with the appropriate extension
SHOULD be selected:



  MIME Type                     File Extension



    <your request type>           .<your request extension> 

   

    <your response type>          .<your response extension>



    ... 

    

In addition, the file name SHOULD be limited to eight characters followed by
a three letter extension. The eight character filename base can be any
distinct name.



Russ


At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:


Russ,

Thank you for your response.

The only remaining issues are numbered 3 and 10. See my comments embedded
below.
 
> Denis:
> 
> Thank you for addressing my concerns.  I address each of your proposed
> resolutions below.
> 
> TECHNICAL
> 
> 1 and 2. Your proposed resolution resolves my concern.
> 
> 3. I am not satisfied.  I accept that this is not the place to define TSP
> policy or practice statements.  However, I do not think that the RFC 2459
> syntax is appropriate for use in the TSP context.  Also, you ignored my
> concern regarding qualifiers.  RFC 2459 contains:
> 
>     PolicyInformation ::= SEQUENCE {
>          policyIdentifier   CertPolicyId,
>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                  PolicyQualifierInfo OPTIONAL }
> 
> I would prefer a structure that said "TSAPolicyId" instead of
> "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> confuse matters.  Also, I would like to omit policy qualifiers
> altogether.  I do not like them in certificate policies, and I would like
> to avoid them in TSA policies.

I had corrected the text but I did not understood your were also requesting
an ASN.1 change.
Sorry about that misunderstanding. I agree with your request and I have done
the changes, i.e:

 TSAPolicyId ::= OBJECT IDENTIFIER

and in the request:

 reqPolicy       TSAPolicyId    OPTIONAL,

while in the response:

 policy          TSAPolicyId,

> 4 through 9. Your proposed resolution resolves my concern.
> 
> 10. This comment is related to comment number 9, but it has absolutely
> nothing to do with flow.  It has to do with the specification of file
> naming conventions.  I would like to see a section that is parallel to RFC
> 2633, Section 3.2.1.  Further, I think that that file naming conventions
> should be labeled SHOULD, not MUST.

I understand the last sentence of your request, but I'm not sure what you
are requesting for the remaining of it-- all the text in Section 3.2.1 of
2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
would like to see something similar to the paragraph regarding base name
(i.e., 8 characters, can be any distinct name, ..) although many systems
today are no more limited to 8 characters. :-) If you want some specific
addition, would you be able to propose it ?

Regards,

Denis
 
> 11. Fair enough; CMP should include a state machine too.  I believe that
> many interoperability issues can be avoided by specifying the state
> machine.  I am not going to hold things up over this issue.
> 
> 12 and 13. Your proposed resolution resolves my concern.
> 
> EDITORIAL
> 
> 14 and 15. Your proposed resolution resolves my concern.
> 
> 16. Okay.  As I said, this is an editorial comment, so I can live with the
> current text.
> 
> 17 through 24. Your proposed resolution resolves my concern.
> 
> Russ



Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09698 for <[e-mail]>; Sun, 8 Oct 2000 14:40:17 -0700 (PDT)
Received: by balinese.baltimore.ie; id WAA03808; Sun, 8 Oct 2000 22:44:36 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma003806; Sun, 8 Oct 00 22:43:59 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id WAA02784; Sun, 8 Oct 2000 22:42:15 +0100
Message-ID: <[e-mail]>
Date: Sun, 08 Oct 2000 22:39:45 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>
CC: [e-mail], Polar Humenn <[e-mail]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
References: <p05001910b6062a0fb7d0@[204.152.187.185]>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id WAA02784
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA09699

Hi,

As I've said to Polar previously, I don't see what issue he's raising and
if it is an issue then it also applies to public key certificates (I think 
this is more or less what Carlisle was saying is a previous response to the
PKIX list).

Acrtually, maybe this is clearly shown from Polar's suggestion that the
"fix" is to change the definition of GeneralName (and hence the base
X.509-2000 and rfc2459 as well as the AC profile).

Maybe its me - can anyone else see the issue?

Regards,
Stephen.

Patrik Fältström wrote:
> 
> This should be discussed on the PKIX mailing list.
> 
> Please discuss...
> 
>      Patrik Fältström, Area Director Applications Area, IETF
> 
> >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> >From: Polar Humenn <[e-mail]>
> >To: [e-mail]
> >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> >
> >
> >
> >Greetings IETF,
> >
> >This is Polar Humenn with the Object Management Group (OMG).
> >
> >I have some questions about total interoperability about the PKIX
> >Attribute Certificate when used in environments where your application
> >does not have control over both clients and server, i.e. they both don't
> >subscribe to the same LDAP server.
> >
> >I have some problems regarding the use of GeneralName for the Holder,
> >Proxies and Targets fields of the AttributeCertificate.
> >
> >When using DN's for these names, they only specify one level of naming.
> >That is, they do not specify the Identity Chain, (i.e. path) upto a
> >certain authority. Specifically, they do not name the Holder's CA, and its
> >CA, and so on.
> >
> >Even using the Issuer-Serial type of GeneralName is not good enough to
> >identify a holder, proxy, or target of the Attribute Certificate because
> >it has the same problem in identifying the issuer.
> >
> >Let me illustrate a security hole that this specification has:
> >
> >Let's say I am a CA that defines employee identities. I'm pretty low on
> >the totem pole, because of my organizational structure. My identity
> >certificate has a path from a real trusted authority, such as:
> >
> >1. CN=Baltimore
> >2. CN=General Motors
> >3. CN=Manufacturing
> >4. CN=Engineering, L=Germany
> >5. CN=Human Resources
> >
> >All my employee identities are defined by 5 and their certificates are
> >signed by 5's public key. Here's one of my employees and his certificate
> >serial number:
> >
> >6. CN=Henry Ford      Serial#=1234
> >
> >I obviously listed the chain with 1 as the most significant. For example,
> >if Henry authenticates via TLS, he delivers a chain of these 6
> >certificates.
> >
> >And now for something completely different, let's switch to Holden Car
> >Company, Australia.
> >
> >The privilege service that Holden subscribes to wants to issue a attribute
> >certificate to Henry Ford from General Motors so that he can access the
> >Holden plant through the Internet. It is clearly not enough that I just
> >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> >as:
> >
> >CN=Human Resources
> >Serial#=1234
> >
> >I really have to fully define the path of the holder so that we can verify
> >that the attribute certificate actually applies to the identity I am
> >presented with.
> >
> >For a contrived example, let's say the GM has authenticated a client using
> >SSL, and the plant has Versign's verification certificate (i.e.
> >CN=Verisign). The authentication provides me with the following cert
> >chain, which the GM plant has verified:
> >
> >1. CN=Verisign
> >2. CN=Holden
> >3. CN=Human Resources
> >4. CN=Ian Botham, Serial#=1234
> >
> >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> >
> >Does it match? Yes, it sure does.
> >Should this happen? Obviously not.
> >
> >I know it's a bit contrived, but it is a security hole.
> >
> >Now, if the Holder contained the name path to that serial number, then
> >there wouldn't even be a question of whether the AC applied to Ian Botham
> >or not.  (Provided both the privilege service and target both trust the
> >same named high-level certificates, such as Verisign or Baltimore for
> >verification).
> >
> >The same goes for the naming of the targets and proxies.
> >
> >The problem exists for regular DN naming as their may be two CN=Henry
> >Fords at both GM and Holden.
> >
> >What can we do about this problem?
> >
> >I would suggest either changing the definition of GeneralName to include
> >DN paths. Alternatively, I may suggest attribute extensions (critical or
> >non-critical?) that complete the path from the Holder, proxies, or
> >targets.
> >
> >I do not have a problem with the Issuer of the Attribute Certificate,
> >because that will be followed by some verifying PK certificates, which
> >consequently defines the issuers name path.
> >
> >Any comments?
> >
> >Cheers and Thanks,
> >-Polar
> >
> >-------------------------------------------------------------------
> >Polar Humenn                  Adiron, LLC
> >mailto:[e-mail]       2-212 CST
> >Phone: [phone]           Syracuse, NY 13244-4100
> >Fax:   [phone]           http://www.adiron.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27725 for <[e-mail]>; Sun, 8 Oct 2000 06:55:26 -0700 (PDT)
Received: from [204.152.187.185] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA24411; Sun, 8 Oct 2000 06:59:10 -0700 (PDT)
Mime-Version: 1.0
X-Sender: pfaltstr@127.0.0.1
Message-Id: <p05001910b6062a0fb7d0@[204.152.187.185]>
Date: Sun, 8 Oct 2000 15:42:13 +0200
To: [e-mail]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[e-mail]>
Subject: Fwd: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
Cc: Polar Humenn <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit

This should be discussed on the PKIX mailing list.

Please discuss...

     Patrik Fältström, Area Director Applications Area, IETF

>Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
>From: Polar Humenn <[e-mail]>
>To: [e-mail]
>Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
>
>
>
>Greetings IETF,
>
>This is Polar Humenn with the Object Management Group (OMG).
>
>I have some questions about total interoperability about the PKIX
>Attribute Certificate when used in environments where your application
>does not have control over both clients and server, i.e. they both don't
>subscribe to the same LDAP server.
>
>I have some problems regarding the use of GeneralName for the Holder,
>Proxies and Targets fields of the AttributeCertificate.
>
>When using DN's for these names, they only specify one level of naming.
>That is, they do not specify the Identity Chain, (i.e. path) upto a
>certain authority. Specifically, they do not name the Holder's CA, and its
>CA, and so on.
>
>Even using the Issuer-Serial type of GeneralName is not good enough to
>identify a holder, proxy, or target of the Attribute Certificate because
>it has the same problem in identifying the issuer.
>
>Let me illustrate a security hole that this specification has:
>
>Let's say I am a CA that defines employee identities. I'm pretty low on
>the totem pole, because of my organizational structure. My identity
>certificate has a path from a real trusted authority, such as:
>
>1. CN=Baltimore
>2. CN=General Motors
>3. CN=Manufacturing
>4. CN=Engineering, L=Germany
>5. CN=Human Resources
>
>All my employee identities are defined by 5 and their certificates are
>signed by 5's public key. Here's one of my employees and his certificate
>serial number:
>
>6. CN=Henry Ford      Serial#=1234
>
>I obviously listed the chain with 1 as the most significant. For example,
>if Henry authenticates via TLS, he delivers a chain of these 6
>certificates.
>
>And now for something completely different, let's switch to Holden Car
>Company, Australia.
>
>The privilege service that Holden subscribes to wants to issue a attribute
>certificate to Henry Ford from General Motors so that he can access the
>Holden plant through the Internet. It is clearly not enough that I just
>define the "Holder" as using the Issuer-Serial form of GeneralName, such
>as:
>
>CN=Human Resources
>Serial#=1234
>
>I really have to fully define the path of the holder so that we can verify
>that the attribute certificate actually applies to the identity I am
>presented with.
>
>For a contrived example, let's say the GM has authenticated a client using
>SSL, and the plant has Versign's verification certificate (i.e.
>CN=Verisign). The authentication provides me with the following cert
>chain, which the GM plant has verified:
>
>1. CN=Verisign
>2. CN=Holden
>3. CN=Human Resources
>4. CN=Ian Botham, Serial#=1234
>
>Then he delivers to the plant the Attribute Certificate for Henry Ford.
>
>Does it match? Yes, it sure does.
>Should this happen? Obviously not.
>
>I know it's a bit contrived, but it is a security hole.
>
>Now, if the Holder contained the name path to that serial number, then
>there wouldn't even be a question of whether the AC applied to Ian Botham
>or not.  (Provided both the privilege service and target both trust the
>same named high-level certificates, such as Verisign or Baltimore for
>verification).
>
>The same goes for the naming of the targets and proxies.
>
>The problem exists for regular DN naming as their may be two CN=Henry
>Fords at both GM and Holden.
>
>What can we do about this problem?
>
>I would suggest either changing the definition of GeneralName to include
>DN paths. Alternatively, I may suggest attribute extensions (critical or
>non-critical?) that complete the path from the Holder, proxies, or
>targets.
>
>I do not have a problem with the Issuer of the Attribute Certificate,
>because that will be followed by some verifying PK certificates, which
>consequently defines the issuers name path.
>
>Any comments?
>
>Cheers and Thanks,
>-Polar
>
>-------------------------------------------------------------------
>Polar Humenn                  Adiron, LLC
>mailto:[e-mail]       2-212 CST     
>Phone: [phone]           Syracuse, NY 13244-4100
>Fax:   [phone]           http://www.adiron.com



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13296 for <[e-mail]>; Fri, 6 Oct 2000 11:09:20 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA03761; Fri, 6 Oct 2000 11:12:22 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 06 Oct 2000 14:11:18 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
Cc: IETF-PXIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"

<html>
Denis:<br>
<br>
I am happy with your response to number 3.&nbsp; Now, for number
10.&nbsp; How about something like the following:<br>

<dl>
<dd>For the &lt;list your types here&gt; MIME types, implementations
SHOULD include the optional &quot;name&quot; and &quot;filename&quot;
parameters.&nbsp; Including a file name serves helps preserve type
information when timestamps are saved as files.&nbsp; When these
parameters are included, a file name with the appropriate extension
SHOULD be selected:<br>
<br>

<dd>&nbsp; MIME
Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
File Extension<br>
<br>

<dd>&nbsp;&nbsp;&nbsp; &lt;your request
type&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.&lt;your request extension&gt;
<dd>&nbsp;&nbsp; 
<dd>&nbsp;&nbsp;&nbsp; &lt;your response
type&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .&lt;your
response extension&gt;<br>
<br>

<dd>&nbsp;&nbsp;&nbsp; ...
<dd>&nbsp;&nbsp;&nbsp; 
<dd>In addition, the file name SHOULD be limited to eight characters
followed by a three letter extension. The eight character filename base
can be any distinct name.<br>
<br>

</dl>Russ<br>
<br>
<br>
At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:<br>
<blockquote type=cite cite>Russ,<br>
<br>
Thank you for your response.<br>
<br>
The only remaining issues are numbered 3 and 10. See my comments
embedded<br>
below.<br>
&nbsp;<br>
&gt; Denis:<br>
&gt; <br>
&gt; Thank you for addressing my concerns.&nbsp; I address each of your
proposed<br>
&gt; resolutions below.<br>
&gt; <br>
&gt; TECHNICAL<br>
&gt; <br>
&gt; 1 and 2. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 3. I am not satisfied.&nbsp; I accept that this is not the place to
define TSP<br>
&gt; policy or practice statements.&nbsp; However, I do not think that
the RFC 2459<br>
&gt; syntax is appropriate for use in the TSP context.&nbsp; Also, you
ignored my<br>
&gt; concern regarding qualifiers.&nbsp; RFC 2459 contains:<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation ::= SEQUENCE {<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyIdentifier&nbsp;&nbsp; CertPolicyId,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PolicyQualifierInfo OPTIONAL }<br>
&gt; <br>
&gt; I would prefer a structure that said &quot;TSAPolicyId&quot; instead
of<br>
&gt; &quot;CertPolicyId.&quot; Using &quot;CertPolicyId&quot; in this
context will, in my opinion,<br>
&gt; confuse matters.&nbsp; Also, I would like to omit policy
qualifiers<br>
&gt; altogether.&nbsp; I do not like them in certificate policies, and I
would like<br>
&gt; to avoid them in TSA policies.<br>
<br>
I had corrected the text but I did not understood your were also
requesting<br>
an ASN.1 change.<br>
Sorry about that misunderstanding. I agree with your request and I have
done<br>
the changes, i.e:<br>
<br>
&nbsp;TSAPolicyId ::= OBJECT IDENTIFIER<br>
<br>
and in the request:<br>
<br>
&nbsp;reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,<br>
<br>
while in the response:<br>
<br>
&nbsp;policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId,<br>
<br>
&gt; 4 through 9. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 10. This comment is related to comment number 9, but it has
absolutely<br>
&gt; nothing to do with flow.&nbsp; It has to do with the specification
of file<br>
&gt; naming conventions.&nbsp; I would like to see a section that is
parallel to RFC<br>
&gt; 2633, Section 3.2.1.&nbsp; Further, I think that that file naming
conventions<br>
&gt; should be labeled SHOULD, not MUST.<br>
<br>
I understand the last sentence of your request, but I'm not sure what
you<br>
are requesting for the remaining of it-- all the text in Section 3.2.1
of<br>
2633 with respect to MIME and S/MIME is not relevant, I think.&nbsp;
Perhaps you<br>
would like to see something similar to the paragraph regarding base
name<br>
(i.e., 8 characters, can be any distinct name, ..) although many
systems<br>
today are no more limited to 8 characters. :-) If you want some
specific<br>
addition, would you be able to propose it ?<br>
<br>
Regards,<br>
<br>
Denis<br>
&nbsp;<br>
&gt; 11. Fair enough; CMP should include a state machine too.&nbsp; I
believe that<br>
&gt; many interoperability issues can be avoided by specifying the
state<br>
&gt; machine.&nbsp; I am not going to hold things up over this
issue.<br>
&gt; <br>
&gt; 12 and 13. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; EDITORIAL<br>
&gt; <br>
&gt; 14 and 15. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 16. Okay.&nbsp; As I said, this is an editorial comment, so I can
live with the<br>
&gt; current text.<br>
&gt; <br>
&gt; 17 through 24. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; Russ</blockquote></html>



Received: from hotmail.com (oe11.law8.hotmail.com [216.33.240.115]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13174 for <[e-mail]>; Fri, 6 Oct 2000 11:02:57 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Oct 2000 11:06:37 -0700
X-Originating-IP: [12.34.72.98]
From: "Brian Tervo" <[e-mail]>
To: "D.S. Macauley C9951632" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Public Key Infrastructures
Date: Fri, 6 Oct 2000 14:07:11 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;	boundary="----=_NextPart_000_001B_01C02F9E.B8D85F20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 06 Oct 2000 18:06:37.0336 (UTC) FILETIME=[2B517980:01C02FC0]

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C02F9E.B8D85F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have an attached pdf with some basic concepts.

Brian
----- Original Message -----
From: D.S. Macauley C9951632 <[e-mail]>
To: <[e-mail]>
Sent: Friday, October 06, 2000 11:45 AM
Subject: Public Key Infrastructures


> Dear Sir/Madam,
> I am a student at the University of Huddersfield and I was wondering if it
> would be possible if you had any information on what PKI is and were it
> originated from and any other basic background information. Your help
would
> be most appreciated.
>
> D.Macauley
>

------=_NextPart_000_001B_01C02F9E.B8D85F20
Content-Type: application/pdf;
	name="PKI for Exec's.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="PKI for Exec's.pdf"

JVBERi0xLjENJeLjz9MNCjEgMCBvYmoNPDwNL1R5cGUgL1hPYmplY3QNL1N1YnR5cGUgL0ltYWdl
DS9OYW1lIC9JbTENL1dpZHRoIDQzNw0vSGVpZ2h0IDQ4NA0vQml0c1BlckNvbXBvbmVudCA4DS9D
b2xvclNwYWNlIC9EZXZpY2VSR0INL0xlbmd0aCA0MzE3OQ0vRmlsdGVyIC9EQ1REZWNvZGUNPj4N
c3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAgGBgYGBggGBggMCAcIDA4KCAgKDhANDQ4N
DRARDA4NDQ4MEQ8SExQTEg8YGBoaGBgjIiIiIycnJycnJycnJycBCQgICQoJCwkJCw4LDQsOEQ4O
Dg4REw0NDg0NExgRDw8PDxEYFhcUFBQXFhoaGBgaGiEhICEhJycnJycnJycnJ//AABEIAeQBtQMB
IgACEQEDEQH/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAA
AAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIj
wVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPz
xNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJ
mam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGR
MqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8Mo
KdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY
6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/3QAEABz/2gAMAwEAAhEDEQA/AO/5WXlE0xVv
KxJpVGJm5Xxw0VRObA31pPHN9aTxxoqic2BvrSeOb60njjRVE5sDfWk8c31pPHGiqJzYG+tJ45vr
SeONFUTmwN9aTxzfWk8caKonNgb60njm+tJ440VRObA31pPHN9ZTxxoqic2BvrK+OX9YXxxoqiM2
B/rC+OX66+ONFURlYj66+OX6y40VVsrEvVGb1VxoqrZWJequX6oxoqq5sT9QeObmMaVfl4nzGUZQ
MaKqmbEDOo75X1hfHGiqIy8DfWF8c31hfHGiqIy8D+uvjl+uvjjRVWy8Q9dc3rr440VVs2Ieuvjl
fWF8cC0iM2B/rC+Ob6ynjimiiM2B/rKeOV9ZTxxWkTmwN9ZTxzfWU8cUUic2BvrSeOb60njitInL
wL9ZTxxwnU98VpXy8Yrg47FXZsvNir//0O/HA1xLwBOCD0wr1F+KNhiLKpVf6wsJILUwkl8zIp+3
hD5mvmQtQ9MgN1q8oYjlmdi04kLazJ6sfNKfz5X+KU/nzjx1iT+bK/TEn82XflQjjexf4qT+fL/x
Un8+cc/TEn82b9MS/wAxx/KheN7F/ilP583+Kk/nzjv6Yl/mzfpiX+bH8qF43sX+Kk/nzf4pT+fO
O/piX+Y5f6Yk/mx/KheN7F/ilP583+KU/nzjv6Yk/mzfpiX+bD+UCON7F/ilP583+KU/nzj36Yl/
mzfpiT+bH8oO5eN7EPNKfz/jjh5nT+f8c46NYk/mxRdYf+Y4RpAvG9hHmZP5sePMifz5yNNVkNPi
O+CF1OTu3vkhowjxHqw8xp/Nj18xIf2s5QNUf+br75a61IDs3Trj+TCPEeupryn9rBC60p/azlVt
rDVHImnbDJNTdVry+kf24fyQXxHov6ZX+bK/TS/zZAF1NnrRqjbf54z9JOmzNTwrg/JBfEeirrCn
9rFV1VT3znsOqGtKk96DByamo2qa+G/bAdGE+IzkakD3xQaip75Cl1It9nqRUV/jgmO7mP2q5E6Q
J42WHUB44Hl1QL3wga6ah67CtR+rC66u3Fanb3xGkCeNkUutKv7WIfp1f5shs887Gu/vTEojO7Ab
4fygRxs4GuD+bN+nVH7WQ9llQbk1wFPczRneoG25w/lAvGz4a8v82PGuL/NnOVvn8Sflj/0hIOh9
qYfyYXjeiHXF/mxja8o/aznj6jMBs23jgabVzGPibfwynJp4xFtkLJejN5hQftYmfMifzZy6TV5C
d2oOwxF9XkG/LbNTmyRBqJt2OLSki5Cnqp8yp/Njf8TJ/NnJm1p/5sTGtOTTllUchZywRD10+Zk/
mxv+J0/nzkp1mToDvjTq8n8345aDs1HCLetnzOn8344w+aE/n/HOVHVJSj/FSg236nAh1iSv2sHE
ssFPX/8AFKfz5f8AilP5/wAc49+mJP5jl/peT+bAZsRiexp5nQn7X44YWuvpIR8WcSj1eWo+LJFo
2pPJItTgGTdJw7PbrK7EqjfDJTUZE9CnLouSqI1UZaC4shRVM2bNhYv/0e+t0wn1U/u2w4bphNqv
922ShzQXknmtjyfObXjHmc6P5r+0+c2vPtnNxp/pDTLmhSxyuZyjlZkMW+Ry+R8cb0zfLFK/kcrk
crK64ULuRy+RxtO+XuP864q3yOWGON65h/n2woXcjm5HG9Mum2FW+Z6HFIXblTvXtviRAptlxbt4
eHbpg6r0TOE/GFJ4kjodjgtdwG249idqjASDioJcVIDDfl12p0wUiEqx2FW4ECjDbfl1BywMSFk0
tNt/bviccjV61G+43zScFPEMGY/tnr7gCtMtU5cRH0bYnYUFaVJNMPvVMbQs5Cjr3p4nDdBL9l2A
UDoxoaGm5wHaIqQkJGyswKl2XYEgH7VfbDFw0OzUJpXkpJRVcEfGG26jJbMd1xZEBAkLFegBJA+R
xJZJOQ4gGorzFSK1pTfAd6ZQPhPxLQlht3rSgr49MTSUsAWYmoJIcUHSnw8W9saVkMMXxEyOrdFK
MT02O1BTBMbxgVclYxTixFFDFiBsCdsIY5mjVZTIsisQoWoCkmhCnkf4YrDcwzu0arEjBgyi3AZi
NiF5uRtyFemQIZi6ZVACJOMJrxG4XYHx8cV5XMchKqrg7E8qGta9DXfC+wfk6pLLIhAAQVDGnRSQ
CRil9eRCIURqqwkQclAJQ9BTfIkb0kJkLqTcGMsyk7OQDTpuPCuB3lMkfxqSG2+EjjvuNzhK+pKY
0SMMzhhyVag8R8R5NxNd8Ck3c7KrUCihYkMT4rQIPD5YiC2nsQXm0p6Keq0qe1N8FQWwkdfbf4ut
D8sB6dK9uqNIrED4QJKgEdDy+nDuylt7kL6ZrJx3Ea8QG60+IDIy2s/arntFMYPTaoG3UYWX2ncl
NF6ioZe1dz1yQl4YQRGFLA7gCrGvXfAkkBuJAzMyhlKyBiKH+XYdq5CJ79gpYmbJfUEQ3rUUNTuO
nTEri0liUkDioNe1PfYb5KUsfSZWtxvQ8gDQAqN/tfPC+/tm2AIFasB0NG3+1QgZZxWaWmFXV6Q7
RQLzZerKCOPhXbCW4uGikrOxEjd329tq5teubrTrt1WlJQVYnfcdCpHhXIvLcSyfbct8zXNVruKc
jDiMYjoOvxc7TZY448QgJSPU/oCez6hHDI0UjUdCQw67jtjHnLx80b5UyPz3DzOHf7QAUnx4jiD9
wxSG+eKMxGpU/Z9q5rPCiPNyhrJHaWwPcmQmYnrtliU060rtXANvMsgKCtRvUkCoxcFiPnkDCkxy
Xy3RQkbjQfMkY0uxPWlMZGruKL9mtOR3wSkCoSZDUmo2NPww0WwerkPf3NRzuwUKodx9Ioeu2JtG
6liykEdV6U+WDUkiTaJQADsdq0+eUTzbi32zQCtDhERvezKQJA3vp5fNBL3rv4fP3xrOFNCaU3J+
eD5I0BDUFD9FMDPGhaqMGCjw2H05VKwd2fBtQIJdC5JBAJ98lGhE+ovzyMwsCaDtt49Mk2h7SqPf
ABu1Srh73sHl0/u0yZQ/ZGQ3y5/drkyh+yMyI8nAyc1fNlZsk1v/0u+t0wm1X+7bDlumE2q/3bZK
HNBeRea/tPnN7z7ZzpPmv7T5za8+2c3Gn+kNMuaCO+bLOWqVPXMmmC32zU7/ANmKpDzcrXetKf24
IFhI4DREMpPEfQK4REqZBBe/682DGsJ1Xmy0SvHl2JwP6TCu23StMaK2FlM3Xf8Asy/nt88rfFXU
y6HNT6cvCArQGXTffMPwy/8APxwoayuhoOhO/cY8L/mMaaA4kKETFKqBiRXtUdfDFprhnURqaKuw
2AP3DbAYZen6xT9WLCVSadBToN8IpTa+MOW+H9WSDT7QuAgFSxEacAGZjvISen7K4RQ0DfDvToAd
/lShw6szCUlDxD1QA0e9GQAj5LXb55L3MaTyCFI6EsrKGUylCG4EgKSwANNvlvg+TTJGcRS8nCji
oYHcb9xSp2FcT8vs0kZXpsqNUAp8Pwha9fE5JYrKRo2RQ7HcfuQeoPi2AmuZpWF3NoCvNizftgFS
AT3pyYtgNoeKCMwk8yVXitaAU3Y8fHOhfof04pJrgdFLkA1fcEFdyFwl1iyt+foxqEXiAsjKaivx
HlxrttT78ImDsN67kV3sVSVIgDClS4YMSDVTWhag4Vrv0wx00pyDrGCTUepMWFV2/wAs98CqiW6F
oHMbCtWjUkABhH1YV+LBdk8axuzyFpTRaL9sK3cA+2NMiSmsZeRCZFKgVACfZBPT4q4XXCwRk7AO
PiqoJbwI7jGTXpjBYE+odxyFRy3A+zXenjgS8v1EQdiY4lX4mkpQfdjy5mgj4LZpWEy81Vj9kcux
5VG4GLQtJcFYlHGNyGZEoK8OoHwfPCS11K1uJQqkvvXknUsdunhkq06FRPHIQXCUJABY+A9sbBFj
f3JFjyQtvaXDsixsBxfiXXluGr340G3jhrp91LZXQQkcUBqFFT16/AoGGdzo8rwvNQwiVQgqQdiT
vxArXANppEyksCxU78xRCKirfE3X5ZG4kGz5fgrun1tfTTkq6yJvQo32Ry8PbB0UXII9aMTSqbGi
DpUnxwj4x2qgJLy5AChT4txuatUbDHprcq+n6zD0nJKmhp8FRvx8crlA/wAPVkPNNFkiV2M/QUIV
qsaNXlWnzwr1gmeL01BCLVSp6Hj9keOGduv1kK6klNqMDxB5DtXwwPqenehC/wAS8jUAb1PAfDud
siCBIA82R5PG/OCus8XIKOK/sihqdzy98iklVNc6D5g0WW4ieQt8Qqfiau56DbIDPE0bFWFGU0IP
YjMLXQPEZdCNj7m3EfSB3IdtztjTXHqBXKYEbjNaQebYtRirBh1GGcF8pljSV/Tt2+GRlFSo8adT
hWDQ1GZACd8gYgkE70zhklEERNWyMXWnq6RLcEr+06pQAV9z1xCW/gV6IDJXfcU36b1GEwBpUdsc
Xdmoxqe234ZInbYD3s/Fn1KaNqyx7RQUI+Ghap+RBUYkdYmJDKipuKsOuADUk8x8Y616n54z4fCg
PfI2g5Z/zke+oyyFeI6GiE0+7fbLS+mUcwwAG3Hb9WAFUE06+HbH1AO9KKNh4jwJGQMYnoyGbJz4
inEFwJTsdvAbZKtDb94uQKByjgrtXJloUpeSNq7Gm2IgAy8YkbvbfLZrGuTSH7IyD+WTWNMnEH2R
kw48jZVs2bNhYv8A/9PvrdMJtV/u2w5bphNqv922ShzCC8j81fafOcXY+M50jzV9p85zdD94c3On
+kNE0KigmpGOCNv1Arv0yxX7OCIkUL3r4j39sywGsq9pp8s45hCwoaitPYH7zkjs7IRIkM9I2AoG
C0FaVIYUr4dMB2FzGswQKQlCOBagBoabjrhrbwrdzBYk4nYH9ptxQt265K65I4b5qVtBb3dvKkML
VWTlyIqoAoBQ9q0xlxpELBRHEA4UrIq1apqKGtNqZMNL0R7eERsPgLkNUno1SDQZd0FtnYyptx+1
UR/aP7Q6/I4iYuubAjfbZ5ZrOmC2aqMC4+2Aak9qjCenbvnRNc06IVmhWsdAXFKcSxpkIv7T6tOy
jZSfhFa09jjKP8Q6phK9ig6ZXbHEdxm75FsaAx3H/PpjlFfo3phjY2kc0n7z4VA3LAEVH0jJAWxJ
QaWskuyjY7VPSuGK6HcSR8gnJeo8Pv2yS2VvwYSKg23FAGIND49MkdvZXF+DIHVVWqlWpX+YfD75
IgDmwMi8wn0ae3UmRSDQEAGpofl8sL+PFiKdM67c6C1xGYZS3EU+IgJ0GzVNf1ZDta8q3tn+/Yc4
kY1KgsNzsx+eRPD0plCRPNjdsvOQcqBa7lulPoyVaTapJNxjUUkQ8SU5AdRX4h2wtsdKZpAWqiAV
JTrXwAp44fQW6NGQVQ8QKGRmqy7ArQUrjXxZ38GT6dZJDGIoZV9MnipABJ359ajv4ZJoLG3mCGYM
xNXUMzAFuleK9cItIjkFqqRojJGWZNwi05F2IFDWuG+nX/1yUGoVWAkSOIVAPcO1fi8RTbKMplRI
NVzIRGgjhpdsyFXX1x3BYqgAHw0Ff8zkevoJeTRtCAjAp+7A4g1+zWhJ2J8MOkm5wmGReLTVj5oQ
ZN+khVTt/DFZdNtHPqMo5E82DDY12bZfHK4TMJHjJN8urIi+TA57KZkk9VY09GhVeZNKtsSVoNid
t8KTWLm8hq2y1Y8vegNMnGr2UkQ9K35MJfhSKpWNSPi5Enetc5pqqXrXyWPNbdrkFVk3I5rUKoJF
RypttmTHIOEzRRJA7kDrmsxQ1ihclmNQoPTkOvTrkcc3d4FWeRmRAQF34im/bDC50uKwf1rqZLqS
QMpAZl4OCOJao3FMKrvUQzFYQOIrxHYfLMLNlu5ZjwjpC+fvbIRr6d/NFzTW1ssQgFDEfhlB3fvu
M655JkW5s4bqpZZl4swI+BmLEg/2ZxWx0+81OQBASlQC56CpzsflLSY9Iso41l5cmUuXaoDGo+Ed
K4dNOcxL08OOtveidChdlnT/AL2kVugUqK1UEVK7ftDI/fwNbqXmfkGqGV2JLV9lXYe+SWyl9WFX
3O9f3jA0UHfp49cINXVVSR/rFIxXnFC6qPh3O7MvH3JyzEfUY8q/HNieSVpduy/vR6leJB5gBePQ
Ab5VldLNcABEKjk4VK7Buo371HXA090TIiBUC7SVX4y3AgkKTy67VJxsTXIeSRFkZSzciVBH7wbV
9lPhmSarlSAyhb6piqy8QDyBPKhoSn6sE3BW9gBbYqd+ZFKivP4fbG+W4WEEct6A5mA4qVovJd/h
J3/yd8Nb60tJ5AWAiYgjmgqfi22OYk8kY5OGuXUfqZB5/rkcXJljpIrqaqlBQH7BLZyzzNa+lciY
Jx9UfvBWvxjqagAb9c7nqflqFolMUrgNVW9U8ySv2aU6ZA/MWgStA8LW5CuwdGU0rttsR/HJzjHN
iIid+lrGRjKy8lIIOUSTkmufL6JC4UN64PRtgF8cL20wWiCa4TkCaAV2r9GazJos8Bysc9i5EJRk
QOKr70nCsfsgnxy+BA32Phgl0I6dB4bDEHUBulF8MxDEg7thjTSgAVx1RXwzFRxrUfLvhrpWnC5H
1mVaxrsFrSp/pkZSEYknkzxY5ZJiERuUCtvcTg+hC0gGxdRUb9umMNvOn2omHjUHJfGUQBHPpKB8
C04ig7Y95VpQlWA2q3xDMX8yf5uzsf5NiQLy79dtmFem9eNCT4AHKdHQ/EpX55JL6+tYajjyY7gI
SoyP3Fw87AsAOOwp4ZfjkZCzEhwtRhhiPCJiZ8g1ETy3yW+XWpKnzyJRdRkt8vD96nzybjvcPK5/
dJk6g+yMgvlcfukydQfZGFBVs2bNih//1O+t0wn1X+7bDhumE+q/3bZKHNBeR+avtPnPLlfj+nOi
+aftPnPbgfGT+GbrTfSHHmpRW5lYIOvh03wV6boSK8jXtQ+25yrSgnUtToanDiK1jlAJ+FVqQRQV
49NmzMFMEDaL+9KTURV3IbbcduOTHQ5Qn1iWOLhxUtyHwijUpseuRVoo45EkiC0DBmWQ0aprXc0r
SmGFveSGSLdiqk8xGOQCNRR8XT54CL5qXomkzpJbFYm9SYqQ21KkD4fiP4YMl01L6IllX4grNGwD
AADiwqBkVsbuVJPhnVA3EMgHMhl3JG3UjbwwVPrspPpRKRIxZAjsKAg1ANSK1r2+WVyhLiuJq2O1
b9ETqVhBNBPRFiCI0Su/xMdwR177ZzTXbF1MivQyIaAjatOo47dBk6+vXyQxG6ljKy3EvJEX0ypF
QwFa77fLI55kezey9SJDG8ZK71qWJUfa/aFOhyyF1R3BY16tmDEU6438cUbrQYw+IxLYFWBa1I/V
XD+wtVMdTWoIFNq7U7KK4SWzqopQEnrU02GHVndSLxZG4yDag+IcSO3T9eTjyDCXM9Ga2FkChaVf
s7gvRF+IbddzvhtbP9UBggJZ23UbcTQVI5Gh37ZE7XUbkNs5ZDVl2BK/tb16D6cNItTiLC4uEWRi
d2clqtT+XcU7HEgnzYsw5q4EqRLyO5b7Va7Ef2YC1WyF9EqEk16p8qEbdwfbA82ryOI0lDUb4hRe
ChWI4rsT08cExX6iNRaITLQhyzUAofFanfwzHEZCiBv7/wBLLqxh/K9zbSkXcuyL6yqCxWvSlQv8
a4KtrVLOOMTuyopFGUKD8A5gCpJph/H6d3IDOiSQyUbhTkKNQjlzP8O2Vq1varC8s0hVwOHBCT9k
+CKd6ZMToiJ5nuTvJfp4tUT60eYepVIurnjt0biK03/swXDqFosI5QK6MSFp8QCliPi7dRvkThnl
N0PTk/dMVapoFCsoVgu/QhT9+W4mjT1PWkRWBQhPiFPioxorAbN4ZGWIS3JPT4eSQTyZZJdwW8dF
KQIBVPson+xC/FTAzaxAXKwz0j+25WpHA13JboK5zu+uZYyZgT6ScpACTQfPm38MjV951lA9K3qa
ArsAq0P3nITGHEOLJKr7/wBTIcRNAPWZNbgmuHtrmTjKC0akr1K/FVWJoQQcjnmC2tNREwiKtQ7y
KRyDAfaUDuDnL5/M+pTOzlwQ3RW+ID5VxS182X9uVHFQB141BpWvjlMdbpvpsgVXLZn4U0JqkWoC
+e3nZpJHNQf5q9wMGweWJhbPPckh+JKIu1D2LE/qyYadq+lamBMWQXNNmcfvEb/JPShwzlhichGX
nD4sfhoB2oa4w0eKUjOUjkB+nf8AFqZyoCqYDo8s2nyCO6p6e4Q1rxPdcm1pr68eQ5EIRxQE8a/w
qMier2yJI4JCQcylep+A05e32T9GBbPVg16QCq26lFVG2Pw8VrUb9FyEdbjxS8AAzjE1fd5N35WR
AnP0mQuI7wRdvY9E1KR2WGjPHty4A1oTuxDDfp1+jDe+s45o/rDkRiNTXluSxpx2A6exyO+VnZbN
JkKKx/bkNT8RLDYHt0yTzXc9zEqxVRQeTOBxAofiHxdcyp3xiUeXUuMOt7sKu41VmKKYz/eF3IJ4
dK8AFPY/LNpsavK3w8g6NFI6qFJrVEcddmr0+/DDU7O7VwoaMV48W+NmFagdNvvxDT5XkdSnwl6U
aUM1eA6Hj2ocuBsbKe9mWkOzxRO5+FuIjSQb9PiFNunXph3OA/GNqkVINCAKHptgOzCJbp8fKoDE
rRQSw3wfFNFxHECoHUb1p0+LpmrzSudgcmYCitsFoOoIG423XqKnAl9Y2M+0gUhN0JHP7XfDJroM
CrKAo3BNG69dhhbcTWjMY423QlWUHhXj0JHzyOMzMr3HuZAWXnvnC3iW2d7SpWAFZhtQ8e4HtWuc
d1G5nchHOw+yvTr3+eekr63iurOeAqtXRg5puGZaVBIpnF/NPlm5tY0l4K3UNKrVBP8AL7U3pmXk
4smEwiaI+1IqMrLA6uaEmtOxOPaZHFGWnvXKkjdXKkUIND9GCtOsrG4Z2v7sW0aCuylmb2FM03qF
im8E9EGvpg9zhtaEpHxVqGlQKVrX/bwLeRQWwRLc8kkQSB+5B7H5EdMfaXFaDuOp+nbKsxPDVAUX
I0vCMm5+oUmkcjMrKCaLsQTt49MTKXm3B14ncnZafPHRsP5uRNe2IS3EvRTWvamYos8q+LtZ8Aj6
iQa/hKXygK7FyHcnYjpT5YiyjFJuQkLMAK7EYmwcCp+z7HM2JHhjvLppj1EVybhFWGTTy5AxdGOw
8ciunpE83xjbag+ZyZ6GwMqKOg2yBKIxsW9h8srSNMm8H2RkL8t/3aZNIfsjCGEhur5srNhYv//V
763TCfVf7tvlhw3TCfVf7tvlkoc0F5L5p+0+c+uKcz49s6D5p+0+c9uP7w5u9N9IcefNfaIryBC1
Kg/FgyRGVQ5kBT7K0FSKdPpwujkZWqDQff8Ahi0lzLJGI+RUA7BTSvjtmVbGle2hEswR0Lud13qf
lTBqMbSQq8VAKgxuQoAHxL7/AI4XW0yxUqfjBFNgp32+1XbbDSR2uYo4Qhk4yGj9W2VX37j7WFd1
e31uZphwi5g1IDLSnwhTuD0AHtkx0VX1Oekg+qRuGjXiqsxWhIo56HfCXRtMgZ/3hCmQg8FVWPxH
alaU+jJzp2mRxsBGg2rRmalGXbcL1yGSQETe2zHrsFC50+FIYopP7yE0RjRuQ6HkFAHQb5B/M+nm
0EgeXlT7KBTTbpXqBsRt7Z0y+06Wf4lDcgtWP2BU7NuDhRc+WV1OCQXHqLzVkJC9Cp2NWO/zyvHl
hVykPMIIN7B4ZKtHYdd9/wDMYwg5MNf8m6hp8b3Co0kcYJ5U6r40FffIgfhND1GXijyNhQbXQngx
FaA9+uD4ZkQgCpIoSfnTxphbTsfori0UpSlDSm/Kg+j3yQNKRbJbOdZAeTiqgDqQaLuAOg3OSC2M
RWNTy4updF+Kvq/Y39MdOpFTkHgckgd6Gr9cmeiQxXECtcuSFNAikhqNsCSCD3wnkxqimtlZSzSm
4iT1VGwKKoFR3Pqs71HT4gMVuo3iCPNVHf8A3WGaoYddl4g098OLdrO3jCKpYRrxEQ4qBxO+/f5V
zSxR3kbn0JJXLKaD7I5CnxHb6aHKeM3vy72fD1tLoS9AsbsW/u+TBVFPam464d2VpO/ptKGHP4nC
mvxe5PTGWmkJZSAg0cipCb1Pzb+GHH1qCFVSWRIXoWUMTy8OnzYZTly9IDitsiLQI0u0jm5rHGAp
LLwWpAJ71/zrgS+0RLsqEclxsBK5psR9lEIH7PfDRrqGUji4b1DxCHYCla0NK4WtHqwVpracng3I
xcVFBy6V7/CPDIRlPmZUfNPCOjzLztNBpti0caqJJW4xKFNAN+VC25pnLSWO+TX8x7tX1VLZAAUQ
PIopQF+g2HWmQlVLsFXqTQZr9fl48tXYjt+tsxRqPvW1y64KudMubW3jupOJilYorKwPxL1Bx+kW
qXl9HBIaIQzH/YqW/hmHYonubxjkZiFUSQBfmoQXEkDrJGxVlNQRnTNL1qObTUuCoY0CyMPtCh/z
rkE1PTorYj0SDWhGTLyVowMtvaaqyW9m7Nc3JmNFKx0IjXf9raubDs7LK5DcwIv4tWpxmEuGfMFJ
9UlVbVYp15MRyr13NfD78i6lo35DY9vpzofmzRl0p3l02RL2wesnpAjlED9kEGvJfAjtkGa1uLtZ
blEokVK0Gwr2zFninHLMcJ3kZD3c3Iy5oThjIkLjEDlXJ7B+X1p+kNPWaOoKJxeKlPi8att8QFcn
kmlyMvxOojp8a1qTtvutM51+VetXr2dxZsCzWoX05KEgp04nx451RIZ7kbk0JGw+AfFua982ZzT4
YSsCNDnz83A4fUfewjUbScxhQGaKtHCsONF3778vDC6GFNOlUvC0JJBUKwoafaHxMfHbbJ/d2z8f
TRVU03ND+wf5siurRgEO7LGFbkshbmaU+jr3zJxZeMIIpG2F67wcweQUHjz+KvP7J6/dhvZyCKOh
MvIUKqaquw7jILZM7l0TdCwoEdULVr6daIu1QCN8llvcrCvGScy8gPj4r9oAcvi2wZYWPeou1WXW
2gd43Wql6RyBWRKECoZm3+4YDllSMLeTkAKaE0LNwAqCfpxl7q8e1vAxkIJLNxDgeHw1wpubr1wI
6GqkKylgi/SDWuCOMdBw22RJCcXOugI0qx+qGUlWVvg6rvx3NeJyOazLbXcEtqVYOxYRBVVQO4ep
98c7vbGqKBEasUoKipoCD88LruMyGlGFAUHxF6d/hHTbJRiAk7hiOoaTpNrCzXPISyA0flyIYUr0
275DpKA075N9cgorKwqKB+wpvv716ZCbuF4ZSCDx/ZPjmDr4cMYyjEUeZDLGeYLRBIqRQ+/hiqqY
WDchuO3zxFa08Kb748yKQAQBTantmpLlwI59eiMW4Y/DSngcUI2rTYmpwPbtC4ClunjtvgtrbZAH
2Na13/4jlRoGuTmQ45R4gRL4oS5WsdetD0/twKCCP8+uGLQE0DOqg9yKfwwHJFFGxXnzNei9Pb4v
7MtxTABHNx9RjlYkRXRfZECZQe+335MtBqJVB7HIVAaOKdj1yaaE5aVWPUkYJNUORe0eWv7tMmsP
2RkJ8tf3a5NofsjJBqnzVs2XmwsX/9bvrdMJ9U/u2w4bphPqn922ShzQXk3mn7TZzy5BMh+edE80
fafOfzgczXN1p/pDTLmoIp6A/PenTFONafeCd+vvjljqBy2HUDr1xURqTVRWvWm2ZbCkMqn1AFDO
BQbdPfxp88mWmxRXZMzRFXWg+2OJrSv2lJ6ClMjsSBASBux234mnzw80to2BDEemlSVAJJpX4S3v
TFEmeaZoMMghubbkP2w9BRj2+I77dMPYI5GiPFCrgb8V2J7/ABe+BPLt/E9jFGQOKoGiXlz5L0+/
DrT5EllfY8Aabsd/9jmDmyTBlY2jyUBC2rLIZIiKMCQQasaEVFK4taTfvzHMq8RuHJJO25FKYMZV
imVkoS+xWoXpgObT3BaWJghJLUA7n375Txwld+kSG3vWiF2sWltqFnKkiKwowjLdKOpFaZ501ewN
jcNDJUOO3UVB3Fc9AQ331WIW0qOynkrMByAYD1OPLptWmcJ8xc21CZmG8jF/cBjyG305m6OMoicT
yFGLCRsgj4pGQKZQ2O2OI3+f0ZgpNB3zKVUiLOwUMa0+nJHpU1wkgTmI0NFHM074SW8LqzUBoTx8
cNrOwuWfmhIoKdQKg9dqdMKvRtHe29NYY1qwAeqgNyO3JiWC7+IGSGyvFmYxxw0WOgWXry8OAFch
elRwQFBdMZ3U8OLk/Co+zvuKZJG8w2VjahzGRUclQ/DyIIrTiCemY2aBl9IMrZxTDUp0EaOaVh3U
vt8VCp/DIZe+aLO2nYNNLcCrtIjN8AU7cQAVHfbK1TWbzXp003SFV5bksFRAx2qGXkz9Nq1yU+Wv
y40/TJY77WCL2/pyKEfukbr8K9z7nISnj0+MeJ9RBqPVdydmCLqks1zLPplndNGwH7y2R+fKqmhI
5V6V+1htb+adTWdY7q1dbhyBFDLE6uyEU2B3YmnhnXVZhRY0EaAjqKbe2FmsQ20F7Y6vcKzm2Zkj
VQAqmUcfUY9egpmNHXccuE4xuDW9m62HxZ8NAkH3vmLz7b3Fvrr/AFiOWN3RW/foY2IP+Se3bI5Z
sqXKF+m4+kimegvzv0SK+0zT9dWPkLSQxTuvX05RVSfZWH45yKKOxtrGS1+rpJ6zq5uH+2AOnA9u
uarNkuRlIUZE7OfpcE51KBj6KO/koLpUV1CxkajkVioe/flt4YpxGmL6/olYvshwoPxfyk9q4IZx
CDwGwHKg6YCub8EMjfYNKp1B28DlEZk7HcO0yQxwuYIjOufNVsEl1/VoILeMsikNLX7IRTyYt4DO
o+WoNHlv5b67K0CBbep3QcjVn5EijkUB75zvyhdx2K3ylByuAkMMjV/ds5Yc+I60UnOhQtZ6NYtb
X8C3McDehM67EWdx8SSFDUtxkO2bzRwEcG1+vu8nQaicp5CZHdgXmSNU1SdIZjJEGJG4IBNdl47U
oNskGhWCw6QsbxEtdD1ZNwdj9n/haZG7iUajqkscKCOKaSiovgtVH08c6/oNjaCNDIgb0o0oOBbY
CjdPA9MzNo3M700HfZMfKlmlrCq26rDF8JYKnCoHWvv88kLXHoy/GFERDKC255A1Fd+46YzmLaOo
ISooA4qKkjsKbZH77VZoZHT1QYpVJhaCImnDfkeRof1ZhcJzTMqocmwCmQy3MTko+52IWtBt12yM
+ZI7WK0aWPgpiasibrUSVTt3qRkYkv76SY3IvAF509N0NSS2zdffxxS+12aSKa0eVJw1OZev+6zR
ugYfazIx6cwIMT7xySa5FQiv0tkeWSjAyA8nND8C8W7b0od8MRqVu0RPDi6lhzFAW5U8fiORtiry
ANF8IJIRHG/MVo3ID8MY8x9f7PMmo415EBaGooeuZFXzRwhOWkMkzLEoNACCtVPw715YMhjVozGW
ZC1GbcyEVO45FT9OEtjOY5PiSYo4IZ5AxAqOqgdPbJBZs9PhkJUHgBTgTt8JatO+J5I60rT28a2z
CgPWrMw7Dl0ORu6bgDxALUDHahBr44c3AmkkMS8GZgealTU8q14n50wvuEThT9n4h9qvfw+eQHNn
05Mcv7aSXmGDBC5LEEOvTtt0yI6hAXi9GYt+7r6dBsp8PpyepDLcmiAoDSpUBaH3r1/jhdf6Lbxr
I4lMkjGvp8fp69MMoicTA7g82J23eZluLUcbjrXGM4J6YbatprQyEoteP2qGv07YTkEZoc+GWKZj
L4HvDeJ2FynvXbbbBcV40JBrUDb33wGoY/ZBy+BBofxyggHm2RnKO8bHmmD3yOB6ikkUNQfDAssh
lIag+gU+/E2jKUJ69xjol5niK/ICuAADcM5ZJz9Mj+PNE2ykENTrkv0A/vUyLRigFBsOm+SfQGHq
p88PNHLZ7X5Z/u0ybwfZGQfyyf3aZOIPsjCGqStmzZsKH//X763TCfVP7tsOG6YUap/dtkoc0F5N
5o+02c9uq8znQ/NH2mznl2aOc3Wn+kNUubduGfqfGm9MVoFNAfi7dyD88AcyNu2/vjWkdhsTQdad
KnMmwxANpsJolA5N8W5JJqBXwGD7FkkFEJolHatDShH7PeuR+GqkM3XvSu1O+2GlnPx5oWUEksKh
iTyG9KeFO2EFSLZrplzqEkZjkk4FApWhCkJxO5bau5ycaTNeSegW+Go+OiVJoOvLkfozmljMzpzI
VlXYAUYnfblxq2/vkr0zVL23jBhkRSmxG0irSnLgi/tEeJ+jIZY8USAAT5sKINl6C9tG8iz+p8RA
UDr1zS2QAEjsSy8ioJ226bAdMBabfG7VODqYwKMoHAb7in3UwxkkZU5kfAB9ldvxOamQnCQiTuNv
2MrBBY35kuozpyyoy/AxZeVYwDTiRUFf15xnWp7YsxiWlWbidjVVJAO3j886n5zmW5tESKWnoMGI
BozBjQUahb4fbOPamG5lXUrQ8WLmrkip3B375t9JHhxDauexapUT3pdwJ9/brgu0t/3gLLUDYgbk
fRtmsLX6zOsYO25O/HoK9/HJdZaLbOF9Mo4fkYxQFiQBX4m2/aG2ZDG6Sa1ijoZACzD+7RBx3G5L
U9jhxaJNJISqBeJB5EgLuKcSRU96Yu9oLWb02UO1BVRuaEb9OmPlD28IWNPTBX4xsp+H7Pw7EZE9
zYBtaJMSAIjsTxJqYlJFFHcv8sKxPd6jdi1sUM9wSQgDGRqGgpRKKF6Y21+tate+hFKQGP72QKSF
pVeKqQBWmdY0Xy5Y6HAkdnB6ssgpLPIOJp13PWuU58wwgWLkeX6d0XxWB8Uu8ueRYrG3hur793qa
9WRqL1/yadsm0ToqBQxZgAa9/pwA1vfzSUeZVi2+FBvUdjXFJ/q1tEXuGr4FmO+/t75qM05ZZDjn
xEnYR6X0Zx9O4FeZaklaW5WKKQKi/C9N2rv1NfHBAsFlDxXJ9eCRQGR99xgO31WyDhWIjd+zUWpX
+GGiXEbEKPCte1MryeJCgImO3P8ATbKHCeZv8ckp1zR0vvL9/pUp5QywuqEgbbHj/wACd88oyzTJ
zsytHiYqSPFTnrrVozd2k1nBP6Fy0ZeKQb8SvQla7jxzyNfQtFe3AkIaVZHDspNCwY1I9srOI5I8
XW7/AG/FycWU4yRE7EUaREdz6qiOSiv2qaVGJW1t9a1GG3PHkXPNZCFQ03C1JHXpgUgmgY1p0xSJ
jE6yxErIp5BgdwfEY4tMY5BKVEA7huzazxMfBW/e9j8r+UdGe/vY9QsDZsLeKa2i5h1kB5h5EZSw
Pb5ZHNbvIYzbwzx+jKlu0BmUmshiYxtFL4hqDFdG83JDb2989xSe3RkaCVmbiw+I8P8AJmApTscL
PM2sW+rISE9Odp/rACiiASIodVrv9pa5ucYrcUYkbDlXuHm647nfmgNJgjN5JdJ8EMNXQSbnc0A+
HrnSdM1aWC0ESuysdwVKCpPb4j0qc59pEDJwVQzNIQWVK5L4ELrCJo4lKFefMtTY1G6GnbLqAjwk
fBkI3uyeXW4bgO0jJWFUagPxbinfavfGyxxykskqfGODGUF+IfsqqaAH7sDW1xbGGX0oKUANXoUJ
UEEnueJGBbm+MfKFIXBuEoTCCAGI4AKW2HvTICNbAUAy26JVeoqxhJBWRqoEjChWWMneor2wmll4
PSIVcAfvKkHkR0XoPbDD0ma4LLByBA5ElhJzG5r2HviYtZEkAVAyivqtKCECk78fhB6/TlnJeaBZ
ZW3nk4gsdmO9RVQPoPtjJZXBZg3xdeO1AKj7QIr7ZKf0QrKsZQMyJRiuwqooaVpQ7YAvNLgkkJiD
QnlX9pieQpSoNKeGES+K0hbONrhwqfE7MFZ1JUqrfDWpPE5LIY5EQkdPTAbmS5NO498J9MtYoKST
Fv3Z+wwHBiDs3Hck5KbScOJCV5cjziVCFVgw49wMhKR96OFAsiu5ueXEpUKWAFQ4ADCu+Fd7YiQg
quzoVbjVDyHxdenbDsWRUl5WWlSDtyYAbgYheHkvoxfack7lSoJoD8NK9DkL32bLCVabDKat6RCE
hubbkKSRX5DH6pJYQQ8VZXMYK+mlK0p9NMEvazKFgBP1Zvt8Tx2/28BvZQw1JVfh+0CO/hyO3Tww
3vsvCDuUmudHOo2v1kQKYmBbYBWpsPtGm+RbVNBazt3SKBXPIEfZb33IyeXuqWgQ2luzMRUMimqd
f2sieo3Qd/q0Kc7l/hjhh23Nd2p169MM4xMSZgDbr0ahzqO+7C7RZIpZIDFyLVBQDfbuKY2VaMDE
tWVuQc0PT2Pvk/sPK0FpA2oa78Nw1WWGtKUJpVl8fAYUTaXarcMtpHyiXYeowDGvTbwzl82THHNK
MDxb7ebvMGmy5MURLYfdbDJJXaV5ZUDSOSWYim567dMVt7kRAgIAa9aYb6naIHPOH03ArtsCPbrX
CkiIDZRyBP0jCJiQ5OPkwywz+oHuKrHcBqVjUUrv88kugH96lPHIqgao9tslXl8H1U+eTDVIk83t
nlj+7TJ1B9kZBfLH92mTqD7IyTSVbNmzYof/0O+t0wo1T+7bDdumFGqf3bZKHMKXlHmgfE/05z26
QlznRPMwqz5BpIyzkAVO+bnT/SGshLRbk96Dx7dsXh0/n8RaoG+w6eFWw1gsHK/vO4+EH4hv/Zhv
ZWNnKvoLFzAcKWNK8uqqqnfeuZLFjjwRxpwRHatRUmo8DSg2wVaWEzp60SfAg5SNyAA+EEHcj+Od
DsvLltKwkevGgqEbgQflTr3wWmi2KkxRIg4hlA4noQQPi265HjG4pWH6LDC9uE5DnHUuOITpRx8X
Vuvhg034ShgDMoNZHjI5AN0TuMNNR0i2somuY4wZW+yH+ILQ0air164Dl09Atujt60Mv7xYmoErs
f7te9T3yyJB3/Hm1E0bpNdB1NZIPqrs6SOStFJYgKaU/dVFd/HBr61JcTpZX8JVIqCP1CRzbpy9N
an5bYVWVudLt5JY2IL0VI+IT7J34olWNPGuMe7MnqzR28rfV6ug5CMtv3AHQj6cHhxMjKvj3Hyay
VXULuK5W5geQvEGqU5fV2jYGiEItWNad6ZD9T04yiZ1rFyIcIw47haklnPLucllpMLiOQsFhleqt
GAC/w1JpL9OA76wDNWN96BzsWqWUgr8I8ctgANvx+PcxJ7mLWOmmPn9pmUA1VEZTUVAaSQjjSnvk
lso47dfVSpk6vIzGSganOqCg3p4YGjsSiuJgo9SQcTvUED/ffTfxrgm5DRQ/FXqDVqgHx+I+2ToF
hZQ819BEWaEAFCSzmq8gTt8APUfPCwS3GqXwEf2S6h5CAinfxU9/ngx7MSAwxr8LEl3K7KFAYDeu
5yYafo1rDaIttCkAipJPI68m5kbgN4DIylGFEsuKxsi/Ltpa6aipEpZyA3OIc9iN2c7U6+OS0TtI
vI0jkXrU8hSnXbInBfmNXt7CN5qrR5z8NQTU7+Hvguxubj0ClzxgAUvI3Lainrt3NM12owynIzO3
v+qvd+hMJ1sySK69WAyHZAftN8NV7mn8MDX9hHfmMMzAKOJ4UAr1ryOMXUdHKlPWUkn9itanqQ3z
wVNRq3FkqzOoCUJ3A6nrmEBKEwQJQO9Eih9rd9Q5g/eo22jw2wJCR02KsByceNScMook+EP8XHox
8DkfvNV1WANLbWZYAirSNwHGh5fCOW1cj1z5n1n109OUKRsyKlBU0IryP45dHS6jPuZx95N/dbHx
IR6FmPmCEm3NwpdWjUgGNita0+Hala0pnC/zK8r2ml30V9p5EaXtGNsAahqVZh9PXOuLcanqVvND
6hjkkCqQwLBQPtexrnL/ADfaalFqSvdEyRQ0jVZGBZQwLoCoO22W4NPt4U5C49B3Fl4lniA5vNzC
/dCPvyuFd6Hb2yXJG88ioiVY9AO9N/boBhzZaC1FkNvGwB7Dkev2vvy86SI6shIkW86VWXof8zh7
p0TXs8U0yD04VpVQRz4mtCfpybReUobqRVFrGnQtzWh7/CoXDh9Cgs4yIICEUKq/CaCp3ZWyUMcY
HnaDZ6JJaKbZ1MkPBSOBqASOW9B86jFkWABJBK6JGVrwUBaRkhhQfzct64J4SzztHAhSNVCl1T7T
V/mBpXcdjgO7sXtJHaVgWDMfTKcSf2Qa17Hw65caO3XuWOx3Te0nt5VUoftHgwpRqMOSnuO+WbET
tGjn4BUKJAKClTVeIPWuAbJ5QRHWgJ4s0oKirLWtF8fGuW189tqCrG4IryPpIeS8T8Q38e+QIPRs
FI82KRRP6MYIQqvw/Co5ihZvYV32OLPaLaKogoZPhL8Q/IV25oqjjXr26d8bDfwURogq1+GaOVCG
q/2mBVftb4LuTLfQNLAfh40PqMwBKqT0oDscgbvuDPZQuJl9VyZKxpQHmST8NQ3TwwDNOj8xFIOJ
NXYmgAI+HalceicDK3xeqPjHomg5OACBzxFixd7Yx8mAb7fxniu60403wgIUObvK6ArIIx+7JNeU
n2yoJouZdX9FxGUUyIzMk0z8wAV3VeAPvtgTVJqRo6yMpUE8V5cQxFG+H2GR9ppmDMjBUUr8CkoC
T9lgvfJgd7EnuZmPNFtPUQh0nK8WDFVTmGUUO9T1wTHKk04u0P7t6EGhFAfs0kIOc+S4EMpLcWc/
3m5rWvf38cNU14wg7iikstaEcanbiCK9PDImI6Ky3VNWgt42AkBcVFX+JjQ/sgU+jIZeaxJODI7u
E3apfjsTTopwNea21w6hEDP0McdVqT+zSm3uFxS3htoHW5vGRpVHOOAKCqmtNyv2j75jajVYdLHi
md+kepb8Gmyag8MBfeegQ9hHcapMUXmtuAQSoAY715bmg37np75KtP0qy0yH1AgWXjVQPjao+zya
gPfp2wDb6miV4kx7/DRQ1Kinv+GIXuuSuIzCfgh+Is3ViKj9Wc1q+08mplRuMb+kF3en7MGId56y
KW6hc3c8oW6dgvLYM1d/EDGwwlv2hzIHxP2PalA3TGXFys+oCSb7J4KVA7DwoffBF0rWkSuHRRuQ
sjU+z/KN65ig1IGEeL3uWZUDGZEe6kNNpdnKv755Gbuw3BB6/LfI3f6T6EpFueSsdgewO+5w1k1g
KhA3rt8Hw0Bwuu7ySTgynYr8Q9xt1y/HPNKVmIjEdHFzQ05jRsyJu+qjDa2kK1lZprmu0Y2T6W64
f6Eh9ZdgN+2R1Lob/BQ7U2GSLQpCZVPie+ZMb6uDkEAPS9m8sj92mTiD7IyEeWv7tMm8H2RlgcKX
NWzZs2Fi/wD/0e+t0wo1P+7bDdumFOp/3ZyUOYV5Z5lHxNkJk2c1J+jJx5kHxNkKaMvLTtXc/PNz
p/pDWW0eqkJyLGteJ4mh2G/zyUeXrSVrsTzmg4hQAKkMm+7nYYU28EUIUgHk3Rahjtv06DJZpEqR
RsJxwDbhSwP2qdQPDMg8kWyaIgRK8g37V+P7W3bEWt+Fy8zuQafAjHYFRvRF61wJFfGSVqEBI1J4
AhK0O3XKl1J4IXuTHVWI4FQeQrs1Sf4ZVwSvbqxtEc/UMsfHjxFQx+EDkfE+GOS3trWP1H4L6YKg
xqF2G4NT0rkfSRzdSS3LgP8AFTct+76qAPs7+NcMoZopEX1BxVFAoTzpxG9V+jLOA9+3WmEiPi1f
lmh5wxDnT4jTmaHrxrt2wnEEwWQkkvLUcSOdaj+Bw7hniuJTEo5x1ZQ3xJHvuK9jSnbBEOkySMql
uSigZqcAAtTShC9f1ZMZBAVLb3tJjbD1gmtJjziKMrAMzBvTb7LEkfdXF5b0W7+tGgcksXlJZFqQ
Qsa19myYzaQzyisvCMqVZFXlXmKE8m26YSa3bx2SoI4kZkFC7AOwArTdunTJQzRmQBuSpCS3V0Fr
EQUB3NKMaj7RMh/rhbD9ZnuAkJ5SkkKD8ZAfpUdMTvL9ZHdpACxaiOdx8Wy8lO1B8s6DY+WINGsU
md/XkmX/AEmWMhaq1acPEZZkyxxACXOWwHm1UTySXToFso3UkTTcqySMRxLAVqoXw/sxb65JNOyO
D9XUk+kdkofiCnjQ/ZFaVw5HlVpLMyafOCxoUVhxpQ779cjtxc/4buGN1aB5ZdndJS9T4dwO+Qhk
x5DLgPFIdOR+1SJDc7DvZLLq+k2cQW758WPEpGvBAw+Km3tjpr3RJ7AzVSAzAOquw51PxD4anfvk
PvfMejanC1nNE4kZaiaQ/YahoQFK7g4Cs9atLSNoNUsRNDIh4sBxJJ71O/3ZD8ttfrEgbq+fu6J4
vd8kTLI7ywx2swniZCoUHiQQa0VSfcbHB1h5w1PQGBv1ea0lobeNgQ4P2m3pXpvkHk1G3WV3tA0K
NtwoGA3B779sCan5k1SeJbbkghDFlZQQ1SKHcn9odctzCJgROIkPNYDfY09/0vzZoGvRhYLhPWoQ
YX2f7j1wDe28rTs2nEQO7gusig1p1Zds8/6bezCaonMLlhRgaAf61O2dI0vzXqMKpHfRl4x1ZKg9
Nvirv1HzzDx6QRueE8x9Mtw2zl0l8wz6xk1R2IVULR19RCChAOy03ORXXbK91VLzToIm9ZyXBVQS
JlcMH5Ddhx2+nFLPzHei85wSVLAI4YVLU33PbD8+YktopJL0OrcVZXKkVJoKVTbGWPLikSIRlYFV
sbRGQPUvJLB5raQNMOM0TUljcEMpGxUjpkmttRkVUY7JxCnnuAS3KgphJ5mvrY661xEJPqc6rGZG
G/qIKVbbrTicqz1GOOONxGfhZXFO4BoCQenTMv6og02xID0i3vYfSVonBp147Gmw7798ueNZW2NS
lVoD8W/xDl2yO6ZqKSMwmiHomjBZAakOKkUFe4yTpfJNEOKlQUNa/CKjw2r8sxZwMTYHPq2CQKQX
NtwT1FDEtXeVqdD4r40wmvpY0AYVZh8KrUjYneld/vyQ3Z9dFCtWLkSQgIIp48h88i1/IRULHUqK
EvUnkQePTbpl8GuSG/ScaJGkSK8yNyUlviBAK+wrin6RldHndQj7Cr0AANValD3yNanJPbk8Qy9D
3+nqK9vHAuoyNpbMt3ewm5jVJPq8RaXkJBXjy3WoHXf5YJ5McPrIF96REnkzaO7nbgqyMPTFOKEA
cafDQEdq4OXUfS4sJal+JCCvIECjla/xyE2upCa3jlBIQ0Kct3opPfB8c7swKFuBqK9qvSm3XJbS
AI5H7U8jTJG1SQOrBSwVmBaYhgQVNBQe/bEL+69KEPEzetuHIJQBj8TbdTscZYW8bopVgJEAOxIK
8eu1KYIltZJpVdnV2c1WJiQ4Ujav05EgXVMhI82N3FwBU8kLsPthCh3PQHffCiSRypVjuQQeRqdt
/oyV3egOzEsOCkhV+LlxCjrQ/wAMjt5ZPFz9NSwU/aUUFa4gpKXiVasK7A15AA1rtv3xyJJcyGOA
DwMgBAAJ+Z/DKs7YXM8scrBY434sAK8v9kuSaMabbWbvHG1QtEVjQCp6EDxp2OaftDtcYZHBhF5B
zJ+mP6y7LR9nHLGObLYgeQjzl8egS63jtdMTmyiW5dT8D78CfHj39hgaW4kduZbrs29PfE2arFlU
Dc7L8O304lyJJU7+AO/6s56eSeXIcmQ8R7y73HjhigIQFBEeoQK8qMRUGlN6+OWhqhUmgrSh3Hvg
czKg3rUkEitfwylkAIqd+hHQ+OVmMjZpsE42BfJZPIA7NvVfD36YEvtUu76OOKbjxi2UgUP3/Rjr
2cD4qUqdz4Ae+2F5YOOXTt/mMysMTGO45uBqZRlPY8u5utCa/RjZDSi0981WNCDsevbpjJTQ/wCf
fLI82iZ9JPcsU1O+SbQP71fnkZXdumSny8tZU+eWhxJbvaPLP92mTeH7IyE+Wh+7XJtD9kZYHFnz
Vs2bNhYv/9LvrYVal/dnDVsK9R+wclDmry/zIvxNkLcMJDSvcbfLJz5iWrNkNlYKxFB0NPnm60/0
hrKJsuRNDIFHXlGQB4EVPtkgt0hETSSyIUYPUg0Yinw0PbIihYMGU0PQSPvXbt3zT6jN6ZhR+SED
lvWtNz+vMqrazd7s2tdUsbUsqAy3B5KOXxUI41r0AFMVnvVnDSSGkdDwiY1WjCuwAqcgiXjEjlP6
EXggod/Gm5w4sLywhUssjOw2UgEH4QdxypTbrjwDn1YkpwqG9KxqwhihU/Ei0JC9PhPffAhN4ea2
ac0JKgJUH49iOXyrge4v5JkSEKFSXc8/3jGtGFCARTbNHd3Fns3OM8a1YGQAL+0FUrX6clX9jFk+
nMLCENdcQy8QsSR83+EUoT8Xjvkls7tbqNbji0Rah9NzyIFafZHTINHf/V2SWQGaQ09FJT6QBIPL
lGte/wA8PtOv5Z4pC8gUKGDGNfSUgbg0Ylt69cozYuIX17/0f2sQaTx3r8CboG4k1oPh6Cm+FusW
8T2sxd+i1psqgjereOKR3lusEhaQA8dhXeq1J+I+2QTXtfc27qh4qS0ZXkW5CtOVe9abHBgwyMtv
Twnn3olIV70V5Qt9HutXuLTUIlmS6j42/IgDnuWC13BPY5LdO8sTW1wjesCkGyW7MWIQmpU/hnIV
juYpF1BHZJ1IZHB+yVNR92S228/NPEiaiQt6h/d3ERMPJadWI7r4ZbmjlMz4cuETFEHfl1Hvaxw9
RdbvUZ7hoYnaS2Y8Q2yEFgh2BFCNznH9aujqzShXkEltzb05QB0Y/tKd6DbfBOn+avNkd5JLFMl9
Cwq8MgpsNqqw3ByOaveXM97PNLC9jLMzNxUlgVcUIB2qpx02A4TK6JIBBB+yispCVbpbJJuUkqki
sajrT/ZYIj1J4I/QkQTIT1O5B+ffC9uak8xzHZl26exwPJPTbqO1RvmQMgA3QI2iHdS1BsGJIrt1
wHPISxQ067/RjDKTQE7dBjY43nmEUW7MaV8K98qyZL2j1bYxrcrrdJJZ0WEVevQb0+eGWk64Ybxr
O4DcJG4VG5G/bYnDqwsYtLsJbgrzYKSzNsDQbb+FciOgxNNrdsBUkOHNP8n4sx8uTJinijE1xHfu
ZxEZxkTyHJ7Lotql9ALq1H71V5KQ1AHFNvDcfjh/dm+vrH0A3qgsOaAE1TcgFgD3Wmc+tNRuNA1M
X9sw9Ln++h7cW+0Qvvkh1XzTp0lo2oWdy9uboMSqtxMcsYDEcaqDzG2XZYyMwaBHMEjke5piOgY7
rlo1xANNMPplWLAsSCZyftDoBstN8jpi1ix/3ohdoV3V28FJFCB4Uw7tvNNvNPG1xFS35Kbog8nb
ccn5E9f44Y+aLqzWySSxl5xEhfVWRqhW+JC4P7RUb+/zyZFEcxfPuZC+XOmL2V/fIrXKktbgUmKE
EhS3U98O/wDENuOE8LeqwoSzGjdgysKNkZtru2tpFlniEibUCmh2Ne1Bv74V3ksJmeS25IhJKIaE
AE1pQbfdiZkcxbMCy9OtfMMs8JieMKSvEO/wghiT+yOXfLkltJR8Mys5oQqbD4Rx/aGcvivJo6N1
3qKEin0YaW9+1y4WFXaRVHJAtTt16ZEGJ5bMqPVOdVgiWdpEkD0oVNSeo9xkd1bSjODqMZCNGVT0
yoCsUVW3p3NfDDEyTHinxVYEUoKDp170GBZLS9IMMUgkhYq3xNTcDft75iarNprGLLIXz93xcjFp
s84HJjiSBsjVYSMZUNEYcvh6fEOgr+GDouBo9RyNFK1oQRt1yMJNdWlx9SuKSrKFMdGrwFe1NsP7
TdkqW6qKrspNCDXfLsGaOSNx6bMMmOUDwy5sptJ/gWMgkkkIWNR4EbA9sPrZGD0i2Xckx0H29+hA
NcI7BIFVHQVJ6InWmwp37nDSRzAiPByrGABG5fcg8npwU9Ou+Ge5oIiiru2WVhzYCR9qL1NPtb4T
6ro8QiLsSCTUFzXY7bBe++Gy6jDLGkjv+5BPxGqrv0I5b0wh1bW44YRDF+9dwV5x7dDy8MjESSaY
bes2jzJKjB4yWiu1ApX3Fe4rjJteJhmtVCTQl+cExT4hTaoB6GmLXkouhO1wu3JnYdTVqfR2GRpm
jS4lhhYvEGPpsaD4Sdtt+2aPtXTQGcZhEXIb/B2nZ+oPB4UpbXYHd7k69QOBKDRWHEgmtMoyenG0
zEKFFeVeIp098K7e5NuaE/AftAdfoxLVtR9aIxRqFSvjUnMGGKJ2pzsupMIGV+quXmhrjVJXD0op
6Ajr1rscDJqV0i8Vc9eVTvv71wGWrlZkcMe4OnOSZPFxG/ertcyvvI7N8z+GPiuCQFbqteJrvvgc
U+dcy4nfmonIG7TNZasrD3oDvtlswYKf+CwCHdQBy2I6bimLgsRVtq7gUysxpvGUkEIiPcinT7sl
fl/aRfnkTj+1+vJVoB/eL88VvZ7V5a/u0yaw/ZGQjyyf3aZN4PsjLA40+avmys2Fi//T76emFeo/
YOGjdMK9R+wclDmFLzbzCAWbIZKgMh5dO1D45MvMX2mpkMc1c8h0r06nN3ph6Q1SKm0Hwl0PwgEB
gadthvicsNoE9dHCMB8SfFyqymqqTti5nKRMrFQlQaNvuNyKjxGMe6f0isYVmJHKQjiPiH2VTvmT
TG9t0rUsGIKkgbiu+3jXByXESt+7VqkbryDAChHceBwFOGZjIwIqKEV4qO+y4pbBmNR0WhH05IMC
msN3NIOHIxxgEUjYJsRspZsG24gVyWUdAA6qe/7JdyQKnvgGC0N24ikosYFS7GnwqKk18cPbSC2M
AHMyyu23xcht4jtTxw8kE7ImCOJ5S0MZMiEmR0/fJQ+DsNz/AKuHkNtHOh4yESkElpCCSVO1VGwo
owovWkk9KC3URsCyOWk4LU/Y5KvxHqaYBa4mjkZC9U4ofgqtSPh+Hx6YBEnka+1hIjqnGpLbpC0N
xOJpH+IKpEfEn4gTSp28fDOdarMsl+YEIKQbHj05CtPi77ZILu5NZBD0bku+xoVDb098jMyj/SJT
RmaVqtStaGnTJUYxAu73LUTzTG1vjaguU9TpyBHKvzwountmc8kaM1qR1A+QzNM3HkpIPcdMQlup
W2cA023UfryM5CmERuh/r1zA1ba5liK/ZKsQRXr0wLe6rqd0B697JMF6BnOLsyP9pN/BffEZbWKQ
bKyn23zCzQyS3jL7SHJgQOYQg1S8i2L8h/lb/jjv0n6lPUWniV/piL2TgkBgR77frwNJE8R3zD8f
U4+ZlQ7924QxnkBfkyK3026uQrgBEbu23vh/p2lpbFSrFn7sB2NB13yLaJrclo629y5Nux2Y7lDS
nftkrWVxR0dWRvssrVBHtTbrm30mXFlhxR+ocweYLi5ROJ4Ty6UmGtcY9GnhiA5MPTG9Tu4H/G2R
vy3bJD5gvS1ONmkgFTT9oRD59cOHWe5KKQXQSI0g6bBgf4YD0hRb+bdVtWIBlMwjFAQ3xiQcf9jv
lWqj+/wk8uJnjP7uQTWRmkXiVrUcSKV2+eFM1ldiOSOCNZElFQuxZadNyDhwf3Ujp+0Ca12Na+Hb
GPN6ZJ5bHeh+HbuBmadxXQsRH5sPe0voeSvGSFNCBvTMb24VPRYfCRQqygkfJiK9slA3AoxYAkDg
OQqd+pwPeRxSsCYh2YnvUVBP05UMdChI/FlfeAxhpF40XY431F6kYeNpMUh5cWXs1RQb+GB5NGX/
AHWTuC1DuKfdkJQn5FmCEp5gt7HFkd4eM0bcXXcOOo+/Fzo8wf0wwr4g7VOCLbR1lql6xVaECh47
jcEnfIGMwNhv0ZbFZba56qt67Bpi5Z3YULdWrtjJdUMjMNnT9kOBQVwwPlXT2QfV7mYSEj4igZaH
r0ocKNU0SXTI2mE4mUEUIBBNe4zTZdHm4pZJwJ6k3bsseuIxxxj+HbYUsWR7m6tAkSl1NP3I4ueO
/JvGlMlVpAyygqqrxqS79SWG/wB2EvljS0u4pL92IaN/TUkmm4qa09jkxms/Qs1c1+JuJApQgoVB
o3vmw0MODHZ/iNhws8+KVhGWBjkPpqFZ1JQs1eIQDkaBT1wUyzQzoRKRyYFuDGorsftHwwpsdUgi
RRAF9VFo2xDHxO/euLy3T3kayOoWh5ASfEQOn7OZZG/4+5qB2ZLcGPhGsbKaVUk1LAAeNevjnOfN
tx9WveKAvI4UGlCfiHRaHvTJFcXtyvKNH5rGvEBBT94OppWtBXIXFOmoeZDIxFIgTQGhJA41+LvX
MXV5PBwSkDuRQrm24o8eSMfMJnp2kh7ZzdivqqOcUbFVVQoHQ0+LxOR7VdMj0684QyB4SAyb8iOx
WvfjSmSO/vJIoJIoBQxiiu9CaD4j2odqZEpnahZak9fnnLxyZZyMpTJjyETvs72eHFCMajvHcy6k
qTMxO+wB7+GA7kEjrU+PtiUk0vIt1J2PhifIkjm335kwiR1cDLljOxRvvKn3y9xsRv3ritS7FYhX
jvUeH040JK3xcSe9fxyduPXdu2SrCgTc0oa4xQag9N8WIYJRuK7ljvv2oKYmftkqTQnqeuKUTJE6
NR6eo1GpWpod65fxK3xVqTviUZRDzrVh0+ePMjOxY1J8cFM7rnzPQImMnkTko0A0lX55E4ia5KtA
P71cFMidntnlk/u0ycQfZGQbyx/dpk5g+yMkGiXNWzZs2FD/AP/U76emFeo/3Zw0PTCzUPsHJw5h
Bea+YR8TZDZUBY0IFa7sf1Ab9cmfmEfE2QyU/vDTbbrm7030homVVNOjZDNIWkI6KKKK99vpxjW8
cEjxxgFj8PMU5Aj+UsaD7sU4NHwIAJQt9oncGuPEMktSx4FqEF+++/2fHMqmviScxIHq43ryZSQW
PcnsMUgC8quCoYmlRU9NumGMtlIyCRgRU0Cg/AQePEePXsRgXkiSfC1WoFAjHEclHXfJALKaItqF
1+IlGHH4fluCMOYLISyKkaNsx6NwHxePI74D0y3RzvIquBUih5HlTvklsY3idC/dW41oxNMEjSFQ
aRHMhWaiPurFK1qi/wAx9sRfToQHj5hgh41JJHxAg7ddjh4gJh/eI9f2QSBStfsjrhTcRLFOvpH1
QwbkoPHixB3+jIQkSSLYyCQX9gEti0YLEDfov2B1p1yEoWEc8Mmzq5r7/TnQ7+ZYYZ0TstY+fxEn
oadqd85jf3Rj1SXl0YA7kHtkskxGIJ5E182HCTYHvX+ooah+jKeNSxP8a4F9UE8xvXHien3HfK+I
FHCXOiDdRv3xOrb/AO1ioIbtvt1yinTxGRI7mQPeoOFfYkj8cRezifcPsfbBLgDY/hiDqGr8TD5D
KpwieceJnEnoaQM1iyVKsGHj0wTpeqSadIYpiTA2xHXifEfxxkq8QaSOfmKjAMu561+jMGR8GYni
BiQe+x7m8eoVLd6hp13amP63GysrANyDcqGtDtgDVtLNzdLr2lyqbiBlM0LEAv6f7SfQKUyD6fqU
tkTHWsEhHNPcdCPfJXY30cyrxanT4lAau/flmzxZMesxgH0zib8wfJolGWI2NwU8vDykLR1AYFxs
aUqPpxBYVZ6126cftHc+/wA8VEkcahgnI7g7/sjrtmAGzMCVYGhYcByHTMuq2QDYV4oYlALrV9ye
RpQg+A9selujgSSU4VFBSgofE4xmDqoBI4d13Hj1Jy0mj4hWALAcSO5PTpgXcqscIBPpgKxB6Vb3
H2sCywrGwaZgprSrVqCdumC5ZrbiJFB3oeLVFfmd8ATF71yyhljFeCoCQR7E75EsgENPEpJUMQy1
DClOp/pgqNYCEC9VoTxq32Qa1LYk0CKwkBAJ3PEknb2OKB1UEEV2AHLbqB4YCyRKi3jjaWRlpTZW
Pxbjwwt1WaHUNPktQDHSjKz9KIKk7eGXcXDxx/ZIHFug222G+QvWb+WSX0QDGsYofFqj9WY2pyxx
4iZb3sAzgCSyHylqsGmRXSOwYTPRI6gCqjjyq3jy/DBmpa9btEZriZJG34Qqa8Qv2a+JyAW4t3dI
5yU5N8Uldgp9qYNvrJNPnjilIaORQ6OpqOLdOma6GvMIiEYAGjRtuGEkGV7XumsuvMqwy+qrVJco
NyCevQ++HcPm3TOKiVjGoBFI+/hyG/68gJjQycVYMOtRgkabM9CF4KQGLEjYV65EdoZYAmRib5X+
xn4HGahHl3J7DqaX9/JJFKyGvNSW4sxJ+Lrt9+AJ7FWle6a79OYksvJKbr7qTjooIbZOMJ5Merdz
8sCSRt6ihzXmaUHj1zCyarJmmeKRA7v1Ob+WjixjiiJS7waAvvI5oiLU7if9zM1WXYEdCK74Fu7k
Ix49a/dlMFAoor+ofwxCeAhS5YZDw43dfBjLNk4DG78/JCh6mpx8aGRqfiTQY+0sLm9YrAtQv2mO
wFffBzaQYR/pDsD0CqhNf9kSBhscrDjxxzIsRJHuQjR20NavzJH7HY42af1ERVqtBv36bYLayj+E
UIoDXcfwAxiW6xsxJ5V238MHEO9sOGfKqQIUs1FNTj1QkeGDlgSJ2FNiKoT4YnJGKlkIIruewwGS
RhIFnmOYUih4hu3345F24hSduuYrI3TcAdRjkZgCK0GwIrTCCpHkqwg9Tt7dclGgAeqlPHIvGQSK
A5KNA/vUw0xJ2p7X5Y/u0ycwfZGQbyx/dpk5g+yMk0lWzZs2KH//1e+t0ws1D7DYZnphbqH2Dk4c
wgvOfMC1Zshc6ESdh8+uTXXqcmr75EJnVHqPEGo3O2b3S/SHGmd24pBEOLVptXcAE174JaVCKUAJ
B2jqd/8AWPbCuZhPIEjY8gSB9NP1YoltKJGD1YqNlaoBJ77U5fLMtqREs/xBoz0AUb13ArUhtsKb
mX03NAzSAhSXB6tt0NK7/LDhoXkQPJx/ZCBnVFo1ahTX7X6sI7pQWK0FVbd1qVqBua03x6pCKstQ
uVcHnSvavFCFBpk20W7gMbNLMqOhqzLQCjDf7XyznUDCJWKGkhpWgOwPXbpg63vLhpKCQDYgc67U
37dMBjYSXpF5rdtbR/6LKkrSKycAasSDswHhkcn1m9lMlAsfJyQQDzXl35N3GFFxezOio8xXl0FA
K1NSTx3zL6/pkN8QAKFk3DeFa+NcEccY9N0XaIlvZkLJNK7IS9VrVd15L9qvU98gmpwG8ubmWP8A
vVoVp7AbZK53KxH0vjkI+IJUf5O/0dcis87R3crn4X5fEpNaUoOuQ1EIygIy5E/gsRYNxSD6zJGe
vxDtig1BiKNsfbGakoFw0irxVzWnvgKuaKWXLimYiR2NOWIxkAaTeK8djUN0wQL1z+zU/dhCHZeh
oMetxKNgxy6GtkBUr+DE4QegTz6wxp8P+Zx3JjvSg774UR3MykcyaHxwQt2p6v8Awy+GqhLmSPfs
wOIjkEawY77YEnQn39sxu0B3P3b4xr1NwMGTLikCDJYxkOiCdaHpi1pdy2siyIdgdx45muAwoVBx
FqdlpXMESOOQnjluPg31Yoh6BpeopcoJFYMriklQAQ3h364OkaSRgStVB8Q+xzn2kahPY3kbxN8L
MFdT0Kk9Dk9Fz66iLpUU2+Gp7b/Tm+0up/MQ4qox2LiThwSrmC6aU1CKKuRx3IAG/YDKhDEFyx3N
ePQ9KbnribOvJQtdiGrTlShp3y0biKBa9qE+Jr0y0lmBsrxKVZFJJA68fiO+9aYYtcRFVMaruAT+
yKLT9kYWo6lq913X9jcbVri6sx40XiQfDl198iSy4VZYhJUsarUACnEfFvucSkjjjBeo3BJIHKnH
YdcfCGLAE0LitQ3I1UkD4flijxBj9nc0ryHAUO5xtBFJRdXNrHJFAw/eTAhCfhCkjv23OwGF11bz
XsMlq5KK4IHJFNClKUr0O/bDi+0OK/mjlevKJqim4IWlF27YGurV4Qzu3JyQx4mpBPcrlBjOfHHJ
RiTt7mYMaBvf9LB9S0t9PKhpA9ftU2ocL69j9+SbXrd7mM3Y+1H9pSKHjQDbCy102K4tHunkKole
XEVof2a79zmm1WIYspiBQ2pvxiUxtuefyQ7WxRRJC3LYbfRviRuJtlJIANQN8yM8RI8e2KNG9wQi
KWfrsP6Zj2Q2bH6QQe4L45Cx5Kd/Y774PXTyXT69crbxn42SQnnxPiADSowNBIulSi4ipNOg2LLV
FPtv1GALi5luZWmmbk7GpOJN7/b1ZEiIqVk3y/h+LK5ItCWBXS4j5UoqB3rt3oRscLpYdHkl5eq5
6cwCSD9JAwgrj1cjoSD7ZGqHMn3pObiO8Y+5mVrqNjAIrSGOgZgoAX4d/HuT74tqMqGEhQKGrfD/
AG5FtLuIoL2GS5YrGjciw3IIG22GupajZyswhlJUAcaj5k5TLHvYBNubi1dwqRjEDYDkhpGqdgW8
SPfFI4BLVxXiv2idsM7AQzQqIW+ALyJoKlulcLdVvE5fVbegC/aZagsfDIR4pSMQCOHme5skYRiJ
yIlxch+1DTNzmFJQCAaUrRaGlPuGB2QszIxHKnI06/jTGiUCi8RyHSvY/wCZy45Fjp8VWbqT2OXU
QNhy5OKTGR3NXzXElVK0I6Df5YxVX4iRv0DV2rjuhAPxKDVhvuDvjkKluK0/yqjw+WEDuQdzR9y6
P7QO3bbJR5fH71Nu+R2KME1Y/D92SXQQPVUDoDkrYSjXN7P5Z/u0ycwfZGQjyz/dpk3g+yMkHHlz
Vs2bNixf/9bvp6YWah9g4ZthXqP2GycOYQeTznzAfibIXMGZyD07duuTHzAaM2RFnAc0FT0HffN7
pfpDi5DutjkS2pxQ/Fty8D88SkuJZGPpgCPwUk/a69cWPN+J4jbcn7h0xqqQSpIJINee3bbpmZTV
aHYEBtwANgAewxhDux9QtWi0qD3+KlPpxSRDQoTWu/QgU67dMWWgQKhBP7bActnXiF3PfD5qSgpV
FagcSRWg71Bp1xiBqKKnfcqvanjy74vIOQZiqxFmoQKsxAGAy/xgdhU1J3FcIXekfB8bEcCQSQOF
GNPf2wc5bipcb1DEFqnYewphTb3HFQFHxKDQnYV+gVOKLPPK4buAegNKEb/qxrqt9ETNOryJESVF
ahiQRUg9uORC7WtzKDUHka4fTBieR+0CQGFa1HTI9NIqyPIBy3NFO1fuyjUUIi/ikc9kvvFNCjdR
0wtYFcHXTy3DhqU8AMCyqQxBpt1Izn8+8zIXV7EuVDYAFS3wy0Kza/1O3i/ZDAv06A174XZJfLMR
WOScbNyCqxG3j1yeixeLnhE8hufguWXDAkczt82UXMdmTwe0hloABzQE0H+qMAy6Tpcu/wBSWPc7
qxp7d8EIW58ia1qWpsKEZk57qgq1AKAe43BzoZYcR544n3hwwSORI+LGtQ8sXUJaaBo/Q34nlToK
0PLvhC8UiMVI6bZMdbu5JoxCCQqfG3f4jkWepr8WabW6fHjnUARe532cnFORHqQtGHUY4UAJJqe2
WYixry+jEmFDStcwCCOjcjdNt2ubpFXZVILHwGTESFCSBTl8X83Tpke0JCiO4Bq5AqPDJHCpepA2
qASNtuvXN72fj4MAl1nuf0OPkNz8hsqW6SODKxqp2p9nauKkCKrE7GhH+x98UQEbECpFOzV3ypOP
EBaGtDQ0oPE0zJKhSaQht+gPc8tuuDreclOVOTdRvx3HTbCkk14gg1BFAAvX3xWKf0hUyUYH9ohv
s/PAyPJM0nkDGu1OLcQOIoa/tYLS4QpVjuRwofi3yPS6pDEBIGMjdCw+ICvY+GIprNvOvFphGykb
H4enShXKzkxjYzjt5rwSO9H5MnuZVVOLNxWQcSeXpmgp0pQ4TXN5bzz3PFm4x05fAUBDHYqW6jbC
ee8umUPJLHFE3QysCaN3ooY4gdURT9VlnWVXognUtRR78h03zGlrcHF6Z8gb2O9dAW38vkAuQA5c
yL36om+dFtZrhF5oBxZK1qaheo9zkQV2ielSoP2gP44dandSRqphB+ouaKAfhcr9rdflXCSaZZD8
KcfHetd812q1AzGMhtQ5efVmIcBIu99iqTlVcU+Yr4HDG3voYbUJHQMftt0qT2wlrXrvj1VmU0+z
4ZiSAlzF9W3HllAkw2JFIqR42VjyAB7A774BObKwksJStsZqbFqjY0p3ys2Bi3XL5E9TjeuXilNb
SR4FMkchHJQDvx2PXEG5M5PSu3IHrjYLoJA0DryU9G227+GLevZ1NVY17+HsPoyIBs+bkgxMYiwK
71giY04g18e5zODtGy8SK9f64IV4CaqpIYEBmJ238Bjo19Q0Ub77dRX2OSrvWVcomye5BtQsAKj3
O+2Wi0PInrhw+hzGL1AhZv5YwSf1UwCliSSy7KDvU4BR5FiQQRtv0Ww8nYAdB45L/L6fvE+eEEVu
dqCi+J/gMlWgxKrrxH04suT13y0KRpk1h+yMhvlwUjXJnD9kZIOPLmq5svNixf/X762Feo/YbDRs
K9R+w2ThzCDyea+YftN9ORKgLE9d6+HTJZ5h+02Q2SUo9VND1HfN9pfpDiZEcKBkWnapHT7XvlTL
LGG9IA0P7ALdOoNe2BoppSQSdt67169MFlm9KpC1ABrWm48RvmZTQUGCvJgzNWgNI1DbGpPcduuI
8TFI3Hu4IBpypSq7DBTBGKspDUPRtlH3HfC65JSQIwApQAihHwjfc+AOFIN7Lp5G6IxU16MCT0od
8BSI5341A9t+lcWU1YAIC37Jr1qNgemLGFjvLQsf2RvQjCE3SGhQ8gAy7dCta+9MtVYyircQagkn
f2wV6YqQF8CKig3+WJLGwlPIbV+EjcdO1cKL3XzsDEwFSORIAHQ03OwyJGNmNRtVjkrdA4fh0AUk
fRU/qwgiRdq7bmntQ5jaiHFwhlE1ZQ0sKW8BlG57e+EMjFmJPfrhzqE/KT0juq7bDviMWnggyzVC
9eA6n55qNTA5MnBiG0ef6S345cMblzKVUOTPQoSumQ8d+RZ2psRvx/UMiUnxybClTQDJzpcTJZQR
8aAAmp6EN0y3sqH76cu6NfNGoPpHvtE8D6lDQA/zV7fLFnLRoaVUNTieXeu/hjv3gFVUVAK7GlCN
zgHUGMaTyHoN0ehHXp13zckgCz03cbmgbiNJbedkpVmYgAmvGu36sjktsWqVH+fcYbCeSgAYgDuc
QuVZT6sJqGHJh13965rNTCOQCRHLm3YyYkjvSShVqfPEwpZwPE0xaWT1XqF4juR3xSxjWS8jU7KD
U9+masQ4skYR3BlTlXQs9zJNOt1gSJOmwLEjv0p+OHEbFf3Y2DGhBNQa96CuAI0dqSLUL8+2LoXV
thVxvVRQ1Huc6IREYiI5AU4w3Rijl0I/mA5cQD7DNJGA1AaigAI6/F03xISk/EQetAT8WxLbjNIW
KgO5FFBBrt4Db5YGYCxeHKpIrTqd+namR/Xrk28r20QThKORfjRga1Kj7sNxRnqrGo67cdu++FWs
28FxaveVIli4rStagnb6cxdbEywy4dq3bIbH3pFRqAh/uxhB8fniYcjFIw8z8EFSan6Buc0ZNt3k
r2ts1zII13JrTw2Fcdd2pgbgelPDwNMTkdrVhGKq69exqRiTXDOfiJ38d8jvfPbuZ3ARqjxd66CC
a4kFvGSQfip2FB1wc2kIv2mBp9rg1dx9GVYahb2sEkb2wkkdh+9rQhKUZRt38cZcTvM7FTSEklFq
KhT2YilSMQCT5Mo8AjuOKR+QS2RQjsqmoBoDiyTIsXHj+8Gw+WJSRlGIp16Y+3RWarGgX8ceTWLu
hsjLXTkkjF1dSenDzCsAKvQitQOh+/AEqcHZRWgO1djTDBZAzgE8RvQ7d8B3Ctzqe+RB72c4x4QY
/E+ah1xyqCRy2B2zAd8pqjvXJNa4rGO5OOEIYVBO/tiaqzGigknoBgttNvoovXaMqvcdx8x1wGcR
XFQvkyhCUr4YmVCzQ5BpLWqV50NaUPyri0enueMgoUJ2LGg+80GAKsDuTXDG0KxxEMeTMfseHz98
aJO3yZQ4SQCK87R0OnSSgemtF2BPz+/BUccUL+gkfE1p8Q+Kv+Vv+Ay7aSYRolA21AoG9D06YKdr
LTeE+oy1uUAMdtDQsSf2mcH4SPfIknkfhTlHFCNSuuRNoqNbmT047e5MbCq71VBUVoKA9adMQkhY
MjyFDXfjGOO4qORFKd8J7jzFctKXtqxxNv6fuCdzTc/Tlwa3dTyBZI42rtWlDT6MHDKuldzE5cXF
QHxCauFDj4eRFKntU4faKx9Ra+IyLrOxPtXp2Hhkh0N6yr9GIvqsgK83sfl0/u1yZQ/ZGQvy4f3a
5M4fsjJhxJc1bNmzYWL/AP/Q762FWpfYbDVsKtS/u2ycOYQeTzLzIaM2QK8ehbx+7Jz5lb42zn94
xLEjx+fTN7pT6Q40xuom5lps5rSlfYe+KrcykbmopTb398BEmtf1e+LIZKD26A7VAGZkWqSNjlIU
cdqV367io6Y4OZJAr/ErV5Mff2wOlQake9GqvXF0JJrxpSoA7b9BXJtZXKEIINeS9iKUAFBg/wDd
8BRiwAG9KbfTgRQeQEYOwqabg7b/AInBAi6dBStBU19hTCi20UcjTqaj4dzT6cZ6Hxlj2oaHY1xQ
SDZKknaoPw/Zy1qQTWg3OwJFD337YqsZFKnlsCRUsPh28aZEpJeKkUoakAD55LpSqISzgKI2eQqO
RAVSe9Budsha1eQue5NPpzF1JI4QOZbIDYkrre1q/ry9Qagfxx9/J6cZ49T3xWp4Ubbb9WFV5OZn
4L0zDymOLERHnL5ksoAynZ5BBKpaRfmMntn6UdpCpfeg5hQeQ+n5jIVBEPrEa9W5DJtbIyxqz7Rk
CoZSKkNUjah+7JdlwMY5JHqQGWc2YhGmjEOgBZgWHU7MR2HfCrXpBtEARvQ79QN+n04ZlqBpQlEX
kwKjoppTfY0p0yM39x61yzE/ZoBmdmkBDfrs0xG6iiljUbCmJ3M0MCFS/wAR2p3xskrqCqnCedy8
hJPTNZqdR4caiNz3t+OHEbPJp5Kk06V6YYaLbmSR5W2CigJ2qT2wsLk/2ZLtMtljsYo2XdqFyem9
W/VlGgh4mfiPKAv9TblNRrv2RsM0SooLfEBxod6Y1rj9/wAv2SevXbGrv8K/aG/wkdvxx0cBLCgp
uAfapzdFpjXVXWXggjXdTTp8PU++KMnrLVm2FCopU1AwOymoDEKF8fiO23bHB5OkbfCKCgoOor3y
LPZRMZjBBJG9KE1Br7YEmWJoLhZV5LxJIG3TYfdXBZMhIHIE0JoaA7e+FeuXPp27ItPUchWINdhQ
7Zj55cOOZPcebYN6Hf3McaErXKid4ZFkXYqa4uEmdQSp+IVBPtiBVuRFM58kdG/hPOl1xNLdSmWV
uTGgrQDYCg6ewxEqR8sEIvwjbp1OW0Q4g9q74rRO6HRqYI5fB/DGMnEU/DE60PjhBpdwq8g6cXYA
jYGnbEPskgHp3GZmr7DG0rgJQqiUinjls/qgDpTemJhSTQDfHjiop3wdUgmmiKUI74Is7Ga9mEcY
+bMaADxJxSysJbti2yxJu7NsBhr68cKm3txxSu7bcm/piT0HNvw4OOpTNR+0+5PbCx0mwt/rEBLf
Fwe5daUYDeh7fRiU2o2KwGIBpCoPxjpU9Kk9sJvrD+msJb4FJYIegJyl3QlhuTt2+eY0sPMzJlu7
OGThjw4wIbdAhbtbW45+nD6c9RuDtt24nxxO2jWBPUkLEipKgdKe/vj7hDE/qVFSdqfLpizLHcRc
j8NRU9eo2plnFwgDpycWOISnOW3HHetqKnda9cSqY7dRApAWqgBiFHHqoGFZZnqxJLV3rjpE9Nyp
2I65aip6Einh4ZaOWzhSMpE8RsrVUkgU69B88NLW19GhIq/cjoK9sTsbcyOpYAgEUPh74YbCBlDr
yD13NCRTbITnWw5uRgwCuM/BaDRxTJLoRPqJXIsrUbjWtPDJNoR/epkhyZTiBdPZ/LZ/drk1h+yM
hPlr+7TJtD9kZJwp81fNlZsWL//R763TCnU/7tsNm6YUap/dtk4c0F5Z5mb4mzn90/xEZPPNB+J8
59cn95m80v0hx5qaKSajffcdMGpHxArudvx674HQDcbEbV79sEmRSABXboo2+mmZwaJLlHxU4kit
AQa9Qe2PbYEAbmjEe/hiJkDEnpRhv9kGgx4cUJrXelD2r9HhkgwLavJVeJIUdQNh8XTfFlkZqbEE
KKGg7U7k/qxqhC32vEbCtabYrEtaKacif2j2O+wySCVdQVKnkKmpbfnu2aORA/Eio40+LrtTqMW9
P4CKHfbei9OnTE3HFCVHRKig29yT3wUi9qQOpTMtncKw+AooSg7s2wr9GR1Rw3O1cNNWlRCiL1Y8
iAa7AD+NcKmPNqdzmJmNz9wbIjakNc3DN+7Tw2pgUcIhybd/DBV3xhj5DqTSpwrZmcgeOanUTIyG
95dO4ORjAMdtgmmlJ614sjgMo7fw6jJikkbJxQDY1C1owWh9j4V3yK6OvFWcU698PbeQ+txBoaBQ
Cdtvc1NKDNroocOCJ6y9RachuR8tkRf3H7oqzNTj8QbcbeBGROWVi3JjuxJrh3qkwIdjSsjUpUnf
v9rI7eTfEQCOS7ZVrsojQuqZYha1pyWIJ6+GAJtnONZyTWuNJJ3OaXJlM+fe5UY0q26GWaOMftMB
k0VSi+lWiqKVXbtQdvDIhp1DeQ1NPi65LJfiWjNWu/tSmbLswAY5y6k18mvLzCHjntwrvJOUkDcT
HwqaGvQ8hjknmmVmFwVU7gAbV7d9sLLehlLfM0rxG3uSMFugVfUAHAnYOCoFD/rNmJk1mbjI45VZ
bxjjQPCFQXM8Kn05S7kqeOxG43p92IPrU9VIRSW+0aeBO3fFYoY3dGmWiEFWc+JqoA+IV/DA8kFu
rMse1QAj1K9KMeQ3/XkBrc42EyftZHFE7kNyavcSChB7VrxHtge6EUkPqyXKeooJEXFt6dq0pibp
HGzDkrAGlVHX6SMQkYOtBUb/AEZDJq80xwyO3VnHFCIJHNUhvFMYRkBoag4yZf3h9L7B3HsDj4Ld
WBYUAHXfx9sSndQxVGB26ivb55i2L2bSCIDiO3RSB6g9dv6ZfPagHXEwy06b+OVXuaUrk72arXbn
7Rp4n5Yk3EAjv2OOJPt9GUanfFBUs3hTLFMroajtiwTJLCXiCpG4rUkAdOnjgrTdBNxMXnkAgj3f
huxP8qj9ZwNHcyTxUcio6H398OtPvob2NreKMRSRxUKMwHJyfiKig8OmVnj4S5kI4DKFg1z3POui
LvvqkNubNEMSI3KHj8QJpQ136+OFPFWQGu428MG6yJI/TFe7qPhptWvXtWuFSt1HQeHXJYsZoS4v
Ny8mWPEYCOw2bY1Ox27nFwyiq+IpXrXA8lDSgoOh+eNBI27ZPMBICujXCXCSOduni3LNsdvCnSnb
EomeEk9Ub4T4Yu+61rv1ONKArU9PDKAdqKJQ9fFDYjf+1QvIoyEZD8RqSNzt2wMhK7j6cEupqf5R
38MC86GlPY5ZHl3uJloT4q4bRcNwqJ6dT41xb1gfiJ8ML9mpShIG+KQRsH+JeSnfY9B45Kh1THNO
gBy5I+OZNgBU/dkp0FiZVr4jIpAYUoT8UnYD7NPc5K9CkDSr0Ar0GNjozMiRuXs/lr+7TJvD9kZC
PLP92mTeD7IwuLLmrZsvNixf/9LvrdMKNU/u2w3bphRqn922ThzQXk/mj7T/AE5z65+2c6H5oHxP
nProfGc3mlHpDjzUBIfl09seJCKNyPcfRidB2y0XkRsczQ0lWV23qTTx69cUU0PLffoe22YBRy4/
FxNK9Ou3XH8DUEDoOp6e+TDArhLJ0SgHUn3I364tFK1ak1/s+zviAQ+mGr1O1d6/RlV4mhP+Y9sk
xTaKeqV5fEK7/arSlcTlmQBSe5AO/QdR8IrgJZuKEFunE0IoanrXEJ5zwLVJIHh1I2H6sBOygBLr
+Uy3DOenbA/rJHudzTZRlTvVttvbAh3Y17dc1eXLUjXUt8Y2N1O7MkzVPRR0wKm1TTphgQAh5dxg
RUVnVF7nNflgfEBBsy/S3RO1dyeaVGyW6njuan+OGkIKfFUKxNSRXrgW1jUKqk9Bv1G+D41ApGBV
akn7uudBjhw44x7gA4kjZJ72OeYJyJktl2CDkT3qfHCJ2qTv88G6vIGv7gr9nmVB3347bVwurnNa
rKcmWcu8mvc52ONRA8nHLCljQCp8MrBVhfTafMZoQpJUqyuKgg5TGiQJGh1PNmbrbdFadp92JkuG
iKxrvVtvbpkgcila0KihCnc1+eBLS+ivoQBRJq0kTfcfzL/HBiM3FiOiq3h0H8M3umx44Yv3cuIH
e2iRJO4o8krgh9QtXt8W9eg64YcQEiE0bfEPh2oD2B68vs+GBNOikkbih4sQafEFqKbglio3wzhW
crCohSj8gjMhk5UqKH4uJ37nNFM3IiurmgbBDNJAAjFQGIpG5IBqD2UVqPEkb4Xzy0iKeoC34UO5
oF2wbfWwSKMmWLkftIhUMOu3FRXrXbc4VmNUcpUq4JBDDp8xSuQ6sgdqpTdJCvgpoevX6MS4hTSt
T12GCVYkUIIoBUnvuem2JEKWJPQ9h0wEshFajU6nY9R/tY2RVJqNyemOIAFAflikIgaQCaUQgg0c
gkVp7ZHzZEWKNKEdm0u4NAPwxKeF7dqMBvuMHLNVaR9B3NN6e2NvyHijqSzHce3iMbkJC+RUwxmB
MbuO6Wg79t+2Pp2HTGRgc6HFu+WNAUinE9NjibKQcFpEZCEA+nt88GRQWyqppzboe++RlLhbIYTP
kQB3lLrd+J4t065pSUl5LVe4IwfPGruHAVB2G2B5Ii6UP2h0ycfVG0TxmNxu6OxXC/nkUxzyu4Yh
qk1NRtXfHKx5caV8MABSTtsRguCUAjn8LjauEHdEZHqiuQ4n5bD3xgqemWzrSo2YdT2OPQdOIoDt
U4JkgbByYGyLLTV6fQK44qOFNlp4ZYBJO2w38emOZCFII3HjmN3BvAG552EI3wksKE+HeuApAQxL
dTv4Yax20kxJ6DxOw2wBfNGZQsfRRxJ9++WRkLobuHniaEjt3BQPQYpHyJoDiQr0GCYgo9z+GWFo
gLKtEpLALuB36ZLtAH71KCgyM260+JiFWtST3yS6HIDMgUbV65ENpoB7X5Z/u0ycQfZGQbywaxpk
5g+yMm0HmrZs2bFD/9PvrdMKdT/u2w2bphTqf922ThzQeTynzP8AafOf3P2z886D5n+0+c9u2+Ji
PH6c3ul+kONPmhzt/nTFVYfAaU28aV38cQDVJJ6dgd8dy6DqAdh4ZmBqIRsaqaK2ynuRXpvivGjV
pRVp1PiD1HyOBopWKBRue1D0r3rghZApDO3EUNWWhNRWtCclbEhuT4ZDFSh6kU/yQRtgaRxyPsaV
H9uLzycm9QHsGHOh5VouwA67d8CMVVieo38N6YQUUuMtKjxPXrge4YlAOVDjmZDv1O3+dcCzMOVW
NAKnffIZZVApAQchCk4mCDlXUqmrKenbAn1hqE980uTNGMyDu5EYkhWuJgvwjc4/TEMk/Jtworhc
7cjyr1w30hP3TyE9TT7hkNIfF1UL5Cz8mUxwwPmnkCn5EmtfbB0SqJAtep4knqPowtSYr8IOw6E9
x1wXbT1YOaMR+zT+Ob87ggOIQWEXJJmdW7Mf14jxPhk6u7K0dBJHbRrKXUc9yQarQ+FMkdjp0M07
vfWiPGQoo9IqUpGFAJTv3Gc1qtNLBPhlIG9/g52OfGLAeQ8TlkZ2a88sWz3BFlbRspDSMjoJOK/E
AOUYNem2MfyRpdIpJLVSzKziNVIYqCOg6EivhmKSPP5NoiS8dVmU1UkHxGGNrqt7ar+zIjVBV9+1
Pn3zpEOgeX0PrGwV4OnJwKtSn2fiC7n/AD60BapY6HZsDFpHpuQSoYNRmNSopUEdOoyWPOYfTMx7
2RwkjoWKWqMlTJSNgu3JQ3b3/ocN44XD8UCHh2cEIyGvI7DmQO9WrTtgWO8mjDCMJGHJLBV5EeIJ
fB9rw4+nKXX4vscRUtX4SQVP419srlLfnbbGJPRBXMaRKI43BIbm8JZfTBLVCqpX9fw4E4tLK0k4
jiNOThgvhxpxA2+7DNoy9Glj4r1RZqfEagdFBpSvZN8KWjJlrL0WvwchxDU22WgFKdsjE3dsjAiv
NaUVgADxWnc+PypgGaMqaM1fAitcMQwHbmyUKcQUNF2FKDAE0cjAGSvKgO9Kb/KuEjdb270MW33O
UxJAqTUHr2pllDX4enfEyKfaPTvhYEnq6N2+Jl6dO2K/bUAtXenvviIClqAge9DgqLkF3PXsD4eO
FYgrDBwoxFDibCgrXv2wTIN+VT4/fgc9SD/XCSkxbV6Lx6V60FScU9UhFG1Qa12xNVp2x6xlm4gb
nw64eEVumPFyHuRUlJIge/UEbD3GB/sjkFNT2pWuGtrbrHGocfFWo74tI9vEpcAM1fsqdh9BzHjn
4SYRiZb7Ox/JmcRknMQ23vmkcFlKzGSVeCk99upxa8ezhhAh/v2FHFNvxwVM5kLFSFIFRhHcV5nk
ak9TkxciCTVdA4mbgwxMcY4uLbiPP4dyLtZI5VZX/vRTiB0Yd8M7eFXBBNE3p3pkfjcowYdRhvZ3
nMAcPiFAeNKkE98OXiI2LRgmBIcW6Yy8EcLGoc+C/DXb9rE/qnqRtJdOVNKhVHvTrXKlnjt/inJF
QGBPxFqdB8sKrzVri5amwjXZF60A2yiEJmq2He5eTPjAPHuf5o/Sq398QTbxKVUABiTuadMKjua5
VampxyjfpmTGIiKDgZMkskrPwHcETb2jyj1G+GIbF/H5eOPLRx1Vfo8Tick7sachxAoABQU9hifU
Vrh962ByRCyszfEa5KfL5/er88iMY+IZLfL396nzxpBJe4eV/wC6TJ1B9kZBfK/90mTqD7IwsCr5
s2bFX//U763TCjVP7tsN26YUap/dtk4c0F5R5oPxPnPLtqMc6F5oPxPnOrs0cnN3pj6Q0SG6hy8K
/Rm5fDvSv44lyFd8xK78fp38cywWukVDIQAK9DXf5dsEq4IHqAVB2PhtgCN+JHHtStMXjkowIFNt
q+J2GTBYkK7O5pyLdBRhtWvSvjiTBj8J/Vj0I7D4fE77jMy0JoPAipr13FckGJQshata0G+ALyQr
8IO2GUgBG3U1FRhPqJMbmu9RmJrpcOElni3lSAeRqMp74jXbMWJOVnPSlZtywHZINLQJbxlu5LZH
x136ZILSeH0lVGHwrTY719xmf2Xw+LKRIFRofFqz3wgDvRjGtWoQKbDbFIWKtVNqd8Dc6+/h2xSO
QqDU9djm74g49bJvDKsxi9TYeooJAoKk7E9c6BpCQ/VJRBJQMhAKkc+IYKPtA9q18M5tZNHJcwrQ
srSqChY7jw233zoOmwCWMJL/AKU3EKrIVDBwRSP1Jfh4ge2aPtc3kj/VcvSgUR5omKxa7aaQX5hR
VaGsKhiArbq4j9MAEnoRh2Xs7mMwwQfW1KESzzUVgEp4U/m61+/C3RtFtpriVLp19dv3jRpN6nGj
bkKvavevbphzPDBpKsy8mZaBV5l6l2U1IUA7E9O+aiRO1OWAOTGp7q+tbmG0tFEAf043CRhwSxBL
LWh+zTqD0yNea3b65NHLIzKh+CMuAhIAWhiVRv8AThxqWoRjUyzOz0kDMjH0gAnT7XA/IFtu+RrV
Llrq7aQoRPUgSB6EjqKsPh2r2wxFgE/qZ8rrmk89jJHwURMoahpLVAA32WYmi0+eGFnAUViVhtyh
5LIHpUKv7JXma+9O2CPq8MsQhb0xIx5CshKgcSOKgigPzxeGBYLfk0gdAd0BCBGp+xR9+vUrktuU
mUQeYQDIYoKgRymgQepFJtzIapooWvhvhUYWVlZXCNxYqBRKU8Ps8fuyQXc0ZDRqikNU8WStTUbk
q3JmPfthPI4AJROLMn7wA0G3UcCNvDIiufeyl3Wl0sQTmpl2PEgAHcmu9DT9WINCF+IOzDepVTSu
3w/FTfxphkJXXmk7NGgHEsn7NdqNsD7dcQSPlGxCNQkVIIIBB9lbrTDbGvuQ66U8hqytGnUeopDG
g8MDT6aqMTvwFTTowA3HscOmaWW3QoWAFeR5UWtOlCOu2ApYVAkDuhffvvsPbIkkCz9jcMcZUAB7
ykrQqpATlXuf86YuiKqGp36rWvTHiNmII3XuK7fTlmE7BRUduNfntXCJbWx8OjsFJmp22Pv4YHoX
ai98UnUipoRv1/Xi+nSRw8nehZiFAPuf7MJkasC/JjGAlkEJHhHUlVt7MMA8hrvSlemGEcUMVeCi
oHXAbzfvREBxAagI28cExKGDKu5APxdTvlOQyPM7dzs9OMcdoRBI2JPO0Pc3DcvhFOwp1+eBfVev
KgJpuDvUZcxcn4+nQYlUf0yyIFbOJlyGUjZK+SXkKUK79cLpwSxNKDDBUMhCj7R2+WKNHEW4g7Dc
nqNuuT4gDTjyxGYu63SgAkdN8pJHjbkjFSO42w6FvHuVB6eFMLrm3AclNhhjIS2DTl08sYBJUJZ5
JTyYknufHE8x2NDmpkmhsGmwG/icVRGJC9PntjFU16b4IPj9/wBGLIDv6KbJx775goA3Ir4DFOJN
N+vfMUpSn3nbFabjpyGSzy+P3qfPIrHQdevhkp8vmsqfPCr2/wAr/wB0mTqD7IyC+V/7pPoydQfZ
GLAq+bNmxV//1e+t0wo1T+7bDdumE+qf3bZOHNBeTeaftPnOrs/Ea+OdF80/afOc3f2zm6030hpl
zQh6V/VjKY/tvv4VzcfiHLeu1B/ZmUwXxjse3tgjYig/XX8MRj2PEClajrTrjjVTU7Up0qOmTBoM
SLKqnX5CnEbCuZix+I7+5xIybVr8u+PBLAb7b9x2yQLEgrWJrU9O2FmpRqWAPWlQcNOPxb0+YxC5
gW4IBYoV6MN9sp1WOWTDKERZ7lxmpWxsihzUOHDaPX4vWr81/tzqn5b+RNC17QpZdVt0f0p2X1qF
WICqfthhtv0zRT0eaAJnHhHmf1OUMkTy3eKUy0Lo3JTQjoc9U2/5ZeRkUwnSo5CNiz+oTWtdmLYn
cflv5QEhiXSIgjFnDhSaEbUryr36dMpEZA7Hcbjoyu3zVDqLDaVa+LDrguKeN90avj453h/ys8p8
VhltF5DYyLyQmh5k0DeG2Iy/lt5XtRxjtInrXr6tQOho6uNx75mYNdlFCZ4h580HGOgp49pDc9Ut
gDQhxTlSn3mgzqUVjBLHCk8rmKQshjJUcXU7FYiVrt7HFP8AC3lfT1gI0xvrQlVIZkmdPjrX4xLy
+Hx64d/U7j99KYjFEz8jTlE7MHY8S8St8JB6g9KZja3N4khKujZijRSaK1ms3FxZcViK1BiZYGZk
5L8QJXo1NqU3wNf25upEuL2T625qslFr6dCCoBb4voG/cZKb+xtVtE9NuESqQkjsX3I+CSrMKnka
5Gbsxpd843SWVhxllkQ1P2/gPIgVIAp8HWle2a8k8h06uXGIO6SXCQySSG2DRFCaGAMXKqDQuZF5
ChND/HChrVWmXkrON6sHBY9T8XHkTsK/ZyUXqLLLFPJDI6zUaJH5IACQCCqkgj4q/ZGFrxyG4JUL
LG9CzemoMZJKhVAUvX/PpkhL0/j70iPq6Dv/ALEtcW8sck7H95FyaVnZiVYDbccBvTx3wte7iic/
vGRFNWKIKAn+XkAe3jh3dhHjUSAMCxo4YcmKHjTga8qd9z8sJ7tJ/UikBrGp4qZBxFGHUKWanhtg
BBO/VtAoVHos+ucuVGcxMoDBzRKqO+xYjfahHXApCMgajU+EsDXq253Hjhn6LEoGPIFaCXaQfDsa
l6fr2xs8UUL8E5UAP2NyeQ22BYfjkDM36W/HisXI9EhdEBZnBKUoGpyAI6bnHwywryKj4noKKaE9
SafDSmCHgjkqERpH6IV5bUPXiqEt4bEY0RySr6McUgqymoZ+KgndlFOo98ss11aJUDsB8AijB6ka
rXmZFLcHVVoPsjkaHuPH7sRljdok5RH4vsRKSEHHr9mrE8Ri0E0FuixBppGJB4xyBUWnxAr8Lhj0
wPcTW8ZPwSyuRy9Viw3pu3am/bEg8qTAg3+tLQoV3CgLxJBG4P3NvjJmNACAT0qfbFnjLFmoeNah
WoKD6BiBViAAK0608fpwgbc20k1VVaEkVXB67D2p9GBnFDyHY/qwQ5A2PQ/ScQIL0IG1aD5jDFxM
lX5q5lEirKm5GzV8cVimdQwrRX8DTEorOMq/2i1Knj2OLRWMtB6rADp4nBLhGx297diGaRBESb7j
t8VJmJNK/PKrTuNvHBRt0FQ1afs9B+P9mLcIFUR8VJA69fvJwCVdGfhTMjZqu9DwSBeTGlabV6fR
9+KQRhtx1OBTMkMzK61WnwfTgqO9hBCswANKV7j6MGQSrYc04smO+GUgOEkV5q7KoBHfufE4X3cR
KkofmSfDBzTLQcN6/QMKLy4BeiNyFN6eOSwg8zsjWZIcNCj7kEw398w6bdc1anFIwCaHvtl4Dql0
KE1bwptgmOMfaYfKmJxghSB1PTFlQ7EnAQd26A5bWqqqkdBt0PhiMkZqSenjiwBArWn9MRZGO+++
1cgAbO7bOqA4VNNmFMlPl6vqp88jUcY5VJJPyyVeX0/ept3ydtBiXtflf+6TJ3B9kZBfLA/dpk6g
+yMLWVbNmzYof//W763TCfVP7tsOG6YT6r/dtkoc1LyXzT9p851dk8znRPNJ+J851dfbObrTfSGm
SgN/7M2wI47EY0U2BO2XUVI7e/TfMsNa+tKmgpX6cxNadev0YmGpuDQ12p7ZXM/T49OuG0UvALGv
TepxUAnbany8MQVzQ+2LCSo/DY5KJDGQKpStamvemXwG3vlKwDV6960pjw3h2HffJsWiAAa7HOq/
l5qdnbafZWtW9RppWIFX+I8ePCMDr7n785QTt16Z1PyHHK+k2bh1twpkZGKIPUIYbVIFSeNPbrmJ
rSOAAs8Y3epGa0uY2deXI9mDqRTr8O2+/bHRzQCUxIzOR9ssxYLv+12GE9hPqp5LCg9MFTQIea1+
EcuTuDUb7YMk/Sa3CtNKhSJWdYY2KFt1oXBDGnXNKYgbX39XK57o3jbTh7hGBBFOag8vhPfCz0oI
7hhVAzcnSrselD0ooHyGDIo3DrM0aonFm9NOgJJ3JqK1HtlTwxry9K2pLIQrNwDFxSvxsTWh6VJy
BIHK2QBY1eRyRQyUiiDTKY40MdVLswYEv16eIwNHIty1yfrby3PEMYEd2Cqo+yRzKAEnqN8kF/Ag
hVTH6IUUQCTjTiQF6EVyKCae2klSZDNbmjSlpCgHIH4aM7bV8TmNOd2d3IhAbIbVNauJkS3ls4Tv
x/e8U3qByX4n3B7A9sA6vcyWVnGHt4FRkVTIUd2qCWA5Kj1De58d8Uls/rEnO39EVPpuUBHFqr8D
sjDYfP8AVga8u1ubmUMAEQCN5iTsyftoJHFK1p3yniBNAfobxA13/oQ8DiQ2xEki0EaxLDHWTgvx
ArHy2Ffh6YG1BRczORET8Kh2kf42oStCI42r22qfDFp7YM8XBmKunNgx9JWZ9zykVlqOKjAiSzR+
rG85EUIJVqcgygEMyM3EAdtjX542en4+TLh/nKd3bziJeUQASpVlj5IqybgKpcEKK19/bCkrISXR
fWVWCGUVdqilAGX7O++Gdw7GOsrM7JUrzdXr6lOJHQmlN+tMLHcRpUCNDy6EkluPXlxCg1HiMd/n
0bY11PJWuYJIowfToTy9QOoDrVfsgchy+yaUwK8pSNeFFQpQ0IJO1fspyoKn+zFoXPogyp6kifBw
I6chXqH+HwBC038cEOkBttpYqRgKEjUlWA+AsoIIJq3UN0PhhMOhY+MbobDzSi4mkkMcac3kUceC
yuSOnZlUjr4YGkimI9J1WIBjykJLDf8AZNW+zX2w1urRoY2MYRY1+IyStTZzRfTrIQNhXcYRsnMB
XJcA/CrUUcQPE7/SBh6Mdjd/2qhuZkiEKSNGFHwrHVQTT4iVUjrSm+BnuJGLO60f/IFKhgPEDNz2
HH4QSAlf69DgeUFSeQoegJ3HbfbEFly3HRr1adPtHYk1J/HEpp+/j4k4nOzIxB+Knfse9cbBC905
FaAbk0yfmeTDjkfRHcnotAeZuCbkmlBhlb6Tx/v3IdgSvDc7bnBFtbx2iUYqHp3+1XE725euzUK0
ahIrvtsMrM5Slw49h3uVHT4sWPxc/ql/N6D9rlSO3HEsGbsSKkjEJ7pF36V7DauAJ7kqCCak1BHf
AMk7yEFidthk44t+KRsuPl11DgxREQOSOe8qSQwHhTriLXg33JPiTgKuVlwocgHClmnLmUTJOJTV
tgBsBiJbwxoObG2syJ3K8szDdunbGdT75WXgQ3isTUYfhiWL2yhpQD8/uw8t0xFkDvRQWh22Bx4U
kVH6sUILUIFPhBAHttXG0BPT38clMnkNnKjEANcSvXt1NK5VTU4qUHQHt3yhGgH2qt/KMrMhW/3M
+A/gtRjfbJPoH96mRoUU06e2STQWHqr88iDbCYAe1+Wf7pMnMH2RkF8sH92mTqD7IyYcSXNWzZs2
FD//1++t0wn1X+7b5YcN0wm1X+7b5ZKHNS8k81fafOc3Z+M9s6L5r+0+c4uz8Zzcac+kNUkOT8W3
frmqB9PbG1BzCnSn+YzKthS6o+n3zEkj2yh4fjmCVYAdzTG1psbY8GlOnjWmT7Svym1TU7C11BdR
to1uo/VSNuRah6fZBwYfyV8wbcb2133qeYoKf6uV/mcUSQZgELw35vOlceNO2+PBr32pU50C2/J3
V55TFJqVqjDf4Q7bEV/lFD7HBR/JTUo0Bl1eESF+KgRuVIPTfahwnWYYmjL7GPh3u80agXbp/TO2
/lzZiby1ZXSp++XmInBDcvjOxUkdMin/ACpvXGZkXU7QAVWj+ohr16cT2zpPkTy/feXtDhsZpopy
krvygbkjq3SjH5e2Yur1MJx9B5d7OECE4tra5tnZnoqycFVQ1AP5qlmqSe2Bmuo7S/kihl9R2iDA
Flcj4yG5MdwB88M5mHpBJwkjkBvTcgbg1X5b5H9aViHlmEYHp+oqGjK7h+SIikLz+nMKHqPq67Np
RVjdPNdRE3AmEZKNR6g05UPw8gTQ71OXdayDIgiSWYoJGpGONaVAqrjw74tpklugMRaKoUO0cYVS
rMSzKVj26f5Rwyje3ng9QqODCnB6Gh+xxPEke2VzABqmQYzqevLPb+jbRH6wxBeKQBQAP8vdDv1o
dsIYXaWO252DejLKqO6ssiVJPZK7Cv0UyV6kNJtmRZFQPIxWgdFJB+BvhdlqKnphGkUlhCwSQROG
U8JCI+QjYg0Jp9qvicxMwA2jv+N3LxUR3KV/HO2niaxtILYvXj6wKFasBXiOO+23vkP1O6lN4sDT
p6ysQY1UIWJZ/tkcqEA0+WTueZrqJWkl5pHXlDAPUB48ZKFlrupX6fDI1qMKwGRRF6qSpJIVYACp
eorybcnwG+UxFCz8P7W+MunVAh7yOzmll9RXgpwPJZFYxmjbSLuO+3bCUtO7JKsaTD7TMlOJapeh
VVJ/ycOLzUyttFB8a+kIgsisqAL0YPQtt232wvuRLw9WsvAs6yBUJHAmgLv8S0qN6H8MFHnVWy2H
M80HczXEsaBa+mqkkOEdRw3PE1DAV9q/QMLJBMkqoZgqFeXCEr8akn7TCtK1p8sGahdFeLj/AEe4
iJMnFFoyADivw8R9GFSMZP8AdnCN6NUj4mJXj8PI8fx27b5YOXT9qCa2JJ67fqVg8RorNIfTSvAk
UDj4RUbbU6V6YKiJSD1hI6koFjVePBWJ+Iitd9jv1+jAqQcYuKyfE/FFZCjKdmqD8SmvGvY4x441
RVQlQxLKzd9lI+FarU8utclz2LAEXYH496+6aV0EsbO/BuDTEJy4gfCoAqKeJofowqklkEZPJt2I
DbqSRTn277YvcO3CREryQAEMaGh/E9cRSAv6Z9RY05H++IC8lO9AOVfuxItltE8lJwoqxBj3GzNU
fL23OBJvgkbnUOCD8Jqu3zwXPFVmDFWKmv7vjxNPi61YU8KYDeRi5rvyOyip8Ovicro2z4okd3yQ
VwvxE1JruDWv68dau9s3IDcjav68VkQkbgspNanbEalWRgvIV4kCu9e2WxkORFtIBjLjBojcFfHc
ukpflUncnE5yHc8T8NNutenvlSpwl3FKkHfrQ5TUpT55lY4xl6q6Nc5SowJ5G0JLFT4q798RpsTg
ietPbAwBO3hleQASIGzjnm1QnpmocelARUZdNzTIopTA8cxG+ObY5n2PzxRS3NvmHvl7bUxV2Kxf
bB6YmBtWv0Y9NiD8xkhzUJiOgLdB0+nNuDVTt74kGqiitK9TjgfFgB/n2wEnnJzARVDuBu1RaGpY
/IZmlEQPHr4nA0kxU0BwO0pJO/XI1fNhLNw7R596IExZ6nJR5fesqfPIfGdxks8vH96nzxaDMnm9
08rH90mTuD7IyB+Vf7pPlk8g+yMkxKvmzZsUP//Q763TCbVf7tsOW6YTar/dt8slDmryLzX9p/pz
nF39s50jzX9p85vd/bObfB9IayhP89ssbCn0ZWXv1OZCF5+ED+OKRU9RD0FRUnE1Ip7YpHQyqe9R
SnzyVop9ReUrYQeXNMLLzk+rp8ZWjBWPMLvvReWHbOVHEUFahanr8sJfLF0raRbW8agvEio/EggC
nwn7vlhk7XnxkxCgHwHlyJI78NgPvzSZQTlnxV9RO57yzjyHudDEpZ3eskjOCyyMCE8AoGwpl3Eb
tz9SjQkA8AoJ26jfahxCFLl5IxNBEQPjEjsTIG9l40+44Jmu44XVDVpWAqiAsQN9zToPc4DxcW25
rpuu1JNPdegoR7SQBgpmYVAUyV5cWoQzDYCn34nDqF8vOK3jItlfhG6EP1UUHJ+uGhvEltGJFGdS
CTRaVPCtJCO+IXNzFBDbxlzGyhVNw0Yp3p2HUr0GXA3sYb3Rsk8vJQPNCyQzo81zcgGURqnNZGRi
R/L9riGp2OAFkuHllIaZ14MgmuTQRCgrTaL7J71yRI1uZWlDKAQTIwLciBtsQfH2wDq0MAiiV2U/
vI+KO3HYkcuSmlSem2+QEjYFMxSDksoGsZUlbi8o5fWIwJBICQfs15Ny69/nhdJCqcoZbpoiq+ob
kyMHaMM3JVhTgUFenUDFry4FvCs9lDbKGNWj6VJNXj+DmxHXpxGJF2klL29vbFwACCi/DyAYurTA
lyKippSmMr535so389kO1yjWUJsZ5Y7UrWN47f1mMgZqurxqx2Piq/jhbd3kgYm5m4GhLEKrs3EC
pRJQKsfkThlqMh+pCF7gRutFcKSsJYmvI8Ctf89sjEttBDcskUouYhQrJzKMU2O7U3AHSmYWUWSa
7+jm4Y87RKSWpuvVVrisa/EWkWFQ0m55emEbiRu30YNvliuIlEUUkscoWYFRHx+Bi1C0hGx6/F1H
TfCyKS4jvHMskQiKszJy5VYjYtyLM3brTDm3vFhR5akiUFhwYBFozfG3Knh4+2VyjQB+LIjexf48
2Ok6vb8Lr6or2/FokaAMauTRWBdlep6HYfLAd/eXFuLZQYLRONQhZDITxCDmsvqCp8KfThheLHqU
xW6eVQBEkm6qofgA7ct1PI+2BZdNta8IkJkRjGpkIlDUbsF5LXqvbAKvpy/G7LhIq+qRXVvPMWkj
lhpsDJTkHVlpvUFR86D3wtcmNvTZ1DgMOcQ5MaCv7IJHiPxpkpnt44YVLWwPAc4Z4ywCN2LKxVU6
dFBpkdnu3Z29ZhJKy/aiADAKorVk4n57/rwkADlbEA8rAtTQxwMQFCsyCJuRJKs605dTx/m6V3pm
mujFbhYoikkageqwBNBxUFG+ID33wK9zIo5LIzOp+AMV25faUVbkaBsZJKblXNDQdCCOoA326YLN
hMYiibv4fpWmGaehKMyqNgtRuTWtTXr8sSj9QSgI6w/CaKqh3IJO0lAor49/bGyrEQHldYtzX7bm
hHTpxpX6ctJoPS4qqvyYBqgCg2C0fiWUePjkxHZhM+r3OlM/Aq3GhrWVn3PHrSlaD2p2GAJCWdiW
qTsOJNNvDlU4Ib1CSYoVIl+AIBWjk7BQSfDAkrsacgQKEfGfuyJibSJd53WuCF3O4qCpJr9AGByW
pQA06/dl1LgAVP6uuCFtpmXkFC7bD2yRgQAdvimAMjsCduiy8JZo2px5xr0FK0qD+rAbNT7sXupG
KxxEfFGncb7sT4nxwG5oOQ2PjmTjkYw2cbKfU1JRh8u3zxFUFd8eCCKeHTLAGRO+5auZaIWu2Xt2
zNTb5Y0uR0NDiVWP/blP0B+/LYjtlrvGwJ6HYZBHetA233yxWhoK03/hmFAPl70yi1a++Ktk9vxy
q5gtR1pTp/TNRR3xXdUEpC8e/fNzJO5NPbGsyk1VeOwFB0ym61HfpiknzumzUnxOMrl75sWK+Prk
t8u/3qfPInF9oZLfLw/ep88Ve5eVv7pPlk8t/sjIH5W/ukyeQfZGFCvmzZsVf//R763TCfVBWNsO
T0wsv05IclHmryHzTGSz5zi7iIcmmdh8w6c8pbipPyyAXui3RY8IXPyU5tMEgAGssPZSDjQDh9N5
f1M7JZzMfARsT4eGB18ta9ISE025alT/AHT9B9GZIkO9CVL03+jBVnvcxDpVgPHqaVphhH5U8xyL
yj0u5KilWETgb79xghPKvmK1eK4n0u5WIPu3pn9k79vbDxR5WFp7x5fWZLGKUAyJLxZVMnpVXiu6
hfcV3PemSVo2lt2DkxMwNGQ7r8iKZENA0+/bTLPm/wBUKRrUKV9R6ca/aFFrkqdbgxKVkYGP4uCc
SXG9F5sOnyzWakDj2kLv8eSw5IGeyZWQpeTestQPTozEkVoeatx698Fq0qyMx4mALwJ+1KWHU1XA
eoQXdwkha5+qRREOwRaVHc+q29aV6Y26aW3laSM7sFIDEKpG67sVY0HOpoMjRkACQTR6fHmy+xtL
uFbgNcOkYQExhyObGnjsBQAV74EvtZS9gC2xAJADIwEhLV6Kv2W23+1hXHFf3U4LrDNNRBHd8gVJ
b42+Fgvypx8MNLMTtLPHLbCJRymCyciocUXhz40pSpFDlphEHiO5A2C2eQU7e41CK5VTykkpuoom
wB/nDDY0Ht74jqWoJJZhOT+uJOcg5gsNviRSUYDr1UYndywCcxzQtzevKWMuvIf3hVHU1IIXI/Pq
cVxcJOwlX4R6bvII1ABB48eK/fUnBwgkEBmETBdxRD/RivqMpVUjHrsqFypMn93H419tsXuEltuM
lKrM5FLeUKrsafARHypx6eOazeycF7kwwyuVNAhdpxy6CgcsopuV+nKku7FY7n6vbq1GZAkTMVD0
CpWJRyHjkJ8jYuvxzZgEGwhXs7xLgzSpMOVGJrRIgjMFVvtUrXapNfY4UOnozM6wQTXSyOnJWMqj
4hUssmyn54I1DV7iO2X1CoSYtDInqMSDGat+7U89mrsd/bAlqYryF5kZWdeMkf1oskdWO44rXfwP
XMOZuW+w+bmY41Gwb/Hci4niLbMhkYlmUqrLGUpwIVCoptSg+ZxO51JJYhbSSCIoCrIFJYEtyI5e
JDYheQySwRSwLIXK1CJzCAJvybdR9JOEjW95bP6k8AaUEs78+QApy3CE0NNjvlZIqm2Is+5MVaJi
iRRErHs5klfkSSAtR1PxDwxdZlWWRfTikdByKc/SLEEt8HMtTtscKGurxCpFAqbIKMDSMUqZH+Gv
9c0UkkrDmpLIOJNaku1ACAxG9e+QiTJlMV6hsjL6e6MK+ikcSkGQxxcZUau4PhttTCOW3MzGTkfW
VeXp1Lhnah5jiTTb8Rkntr6ztwYXEZA3p6hLBE+zVjQHruFO2R7Ub/15WCp66g05UIX4v5ilNxUA
ZKYoCtyWENye4BKriPhIxYMkjij1BWq0rzA3O+1PbAckKRoBFJI5UnggHw1pVqjrXfwwxnaZP3ZI
DRt6CPyHRTvSgcU5bdThfIyozl5aNy4kBK8hX7XwEd6Fd98pN8V1s2gxEfNa/IRwqFUNuSzjfgwA
FWei0/ViE8/qtGZSGC/CvIMeI6hQV6gfLB0UdsFLPGG5ng0khckjbdCpoGP+tgSZuJ528hUJ8UZA
DAH+Ud8t5D397QSZWh5WPHhCyuWAY9gOQpQqfDxwFMzzyNReJACnjXegG55VPauaYihXdqmqsCen
h9+Nhu0iRkdaknqf15fjojYWdmoUZ+s8I33RUHGKMMQARWrd69MfM3NQqEqGBCg9CfDbC2W6Z6BS
eANQp3wQjCRAymny7NhOH1cRO/P9TkQzgg448gK7kGULSupr8QPwjsQMCN8R2GxwxuJFMgYgBqhj
8679PHADfC7IexIx6lwsoo1dtcSu2UvvjidjjQfffDKujAc3Hp74k5P3YqR8PLEWNchaJBaT75at
x7VqKZQFc1D0wMXbdsuuZW4n2PUYqiVIIXlXovjikC1lTQgE8T1GWI2boO1cEQQSu3JI+TAiidjU
0pQ4vKDbUW5qzg7wL8KilNjTBbYMexJughjbMI6jdhuwr0p1HviAUsMVeZ3k9U0APVRsKHHCMhqU
phRIA/SPJTWInN6Rri5HHp0yj41w0jhaiSjDJX5fX96nzyLI3xZKvLx/ep88aRs9v8r/AN0mTuD7
IyC+V/7pPoydQfZGLEq+bNmxQ//S78cDTpyBwTibjbCFLHrmyDPXHxWCDcqNsNHjBYY9I1775cZb
MFK2t0jA4gD5YIa6RZo4AAS4JG4H2fAd8cFVaE7cR9o9hjRKrOyUFR3PftTpkBuSSCU/YulnjhoW
JZj0Ubmn6tq7nEblkuYuENyEYniODCpb+X9rFVKCOjOK0K86AdNvwxN7hkekUfNV2IUUpX6Kfjhi
N9huO/l9q9N0PZ6fJCWkmSIyciVZeXRiG35Voa4Pd/SRnIJVRsqip+gDAQ1QBjHJC8bgVo9ACdvs
nvgmKSaWINIvpsT9gHp88M+Mnin9/wBygAcknkmkMPrXBlCRXHIIAWLA9NkDmlDlz6kIJf3+8LIw
QN8DMSK8UBRfiJG+4phtPJCkJEzBE+z1oPlXamFF3e2nBoCWKyBuLk8TUH7KcePj88ugeP8Ag+SD
sLU0uRdfVmt5BHM4q7NCHUU/1ahd/E7jvjp7aZ4R6c7TuGaorxLPyr+xx4gfPEhFpMXJ7FDPOR/O
3HYitaELtx6DAsljfl/UgaSC3UvIPTWNaktX/dvJ1Pwjt75Zt0PD/WAH7UDmlc0UESPCJXju1NVj
JPEvU0Px9DtTlXCWC7EEssE9yPUWo9KJBckAEnkszvty/wAxkiOk3Es01xevAwLGRSycgFNSrngt
Hp1FcLH02SS8eebjLZN+7+srCtTVa/ChHKlV60O+9MMpDvvvbYiyhbORIWilEZZQQbiVAicOThxy
mdu3VuA7ZaXRinmj06eKRGAaVFJb4RtzdmWRWYsOtAd8cpt0gmilhe7KsXt+IX4ACD8FOPCPlUN0
JNdqYNmvp57WR5JorEOwVXVQ0rcgxWRfSY9F6Vp41ymZ2Ow/Hk2DnyY1d29vb1RvTjuGqIkQHo2/
xNIP3ZHYF6eGOgulhNJ7eSVYwVe5T4+6qQVKR9OnLf6cNktLV7Np2lWdY1JWaVTLMhNS32URq/Ea
0NffCSaCzUTM6uHhKrC0caxkIKqQzA1K/Pf6cx5CJO/NyIE8hy7lzPqEqhSFITkImqhcxyD+7/YT
bj2H0Y8yWwjQ2zhq0Yq5UkNvzH7wsK9BXw+jEpYb6aRXMnNIgrooEfJHrxFXdAfv6Y2AcKxW0IE1
1IKvy+CtQ1Vjc0YU5ftUrmPMc/wHIhXu3r9aFvIoqoWjLMS392RIayDjUBeJpXvT9dcQdPS+KR0g
jRq1ZY2JAI3ADNuDv09sM09QLN6T86fCyxNQURmj5HnVV233Jp1rXoDkhuJqxcjbqzfCwEb1G3Lk
qhRRjQjIj0nZkd9jsh5OMrRyRo8hLlldujMTxIAU8ePftgQWyRpVG5ykdQoalAtfg+Lpv88Ez2oP
pglmlUVKOFHGn8qbeO3bGSJLFIyO69KqmwNae3y3wSnVbM8eK7BklVz6Ql9WNxx2VmcFagDqwjPQ
4ElWTgbuLjCkRHF4o/Tr2+Gu9ScM5GRHVxsak8aD0+lafDSpPuBhdcM0pMsyL8Sha8NiB+1x7fRg
PIUphRooeJ1jIJLEggqKK9CSCFZi3T6MQu7iOeUtzZi1Sz+mtSdzUCuw+nGXDkqrB+u+4BI+fbAD
FK06da13+nLAbAvctEo8NqlwQZHUEkiu7AKdqHfjy8MLJ2Ik8e5p74OLKV7eNR16YjIiOx6mvUnb
GEjA21zgJR5oZSDsenTHxzSRcuG4O2+KLA6wNdAr6QcRAVHLlTlsPkMRoSSKUzKviG/Vx/prhO99
Fq1b7XXuMq75cxMafvKmg8RjZKjcH6MfJxe0VhvIjkMf8kgU/VkZHp3MD3Iap79MsV69soDrvl0A
GQQuZgVAHbEsUBPAj6cbxqQOnucCnemhuKU8Piyiu+ahAPidstQWIGK+TaxljtjmQxoASfkDghFA
FQKAd8bIFKsWpXx/hgts8Oo31QwYggqaH2x1XkNWJZvE/wBuVwqTx6DHUqoZmqSCAO4I7H6MNtdN
e1DU9vDFkfkoJPxUofoyjIqkmMUBAK77g0od9sTQ0OAJulZmxFpKnHSGtKYlT78laCVSM/EMlvl0
/vV+eRCP7QyWeXf71PngYvdfKx/dJk7g+yMgflb+6TJ5b/ZGFCvmzZsVf//T79jGx+NIwhUM2zDE
2aTmqpTuTXpsRizrU74mRUjj8NO9MtBDBuQ+oCtfgOzFT0y1MYLOo3FATQkkD546m25rjWHcY+SW
+TMpCgVI+yfE+OJPzFCSOKGvEbAnYip9sdHUVr47AY/cdPux5FVJZXZwpXjX+8IHftvtixlUAEmn
bfxxN2K1oN+2INybDQPkq+VkloWAZR8QDUI5Dofn4YW3cYuGIMq1UioI+I0qfi409qYIdGINAo79
K4nwUjg0YK1/h7ZbD07gqo20ixO0auxZTSgUlSBVuIZq9tsUub2kUnpFTKQeKP0oetRXMITxKqgR
T4eI2riE0TKPhVaj2/tyR4SbKAFSG9lWIC4KkgdUBC/jhNNemcNwhMfw8QQaUPatOux74tMk7NWp
FBsB4nqanActs7inE7Vpv44KiLPe2RCUzvdxfuzK8ilqIATxU1qCPh/z6Zo4Wa2/fIHrUlpONWJH
Gg+HvTtgtrBgCFqO1e+MFo4G4LN/MwB/DIS5N0SLUY4SEU8lLOQGAXZhttT4VqKeGFtzHwld5VUt
1HwLLypsC1RSp+eHRs2YAb8R0XsB4AYi9g5PgOvEfqzGldluiR3pWSxi4yB1jYV8OVO9KFKjbFJp
ZJY4VjAJqG4vUsCpJFSKbbdsGtYykAbmmw77H3OLJYMSCwIotBToPoGVkNnEEjdXlBhZ/wB2WCqF
oKKAdwqjbBkVjb+oJGAlkCcKnalOlK4POnEpQIAw2r09ziptnQVpuB4eAyFdyePzYpqEbvGkcqBG
FVT4eZIAqQfp9sIZ6+oSQQa7d/o3rkzu7SZ+VSaUpQCnXCWbTHr9n+GQlAlvx5YhjspNKMKEUPhQ
jC24LGtSW22qf8+2SaXSpSSQpwFJo8vXjgECylmjzYzKD2G3hXAjoT1GSl9FmJ+ycSOhS/y5bGDj
zyAljBUj+zG0c1VfhDbNT9WSY6HKOimuNOhzfynLRENEpscMB4ADsa74nKGIp9ByT/oOWn2TiT6F
L/LkvewlIVttfNibq3Twy4wQrpTZxQ/Qa/wySnQJf5TlDQJf5DkbaWL8GyvTbwyU/oCX+U5v0BL/
ACnArFxG248euWImHbJSNAl/lOX+gJf5DikMU9E4okBArTc9MlC+X5P5Div6Bk/kxLOMRzYsUbiF
AoBiTI1GG9DQ0yWnQJf5cadAk3+DIhlLdiRjcVpsCO2N9NyKb9a5Lf0BLSnE5X6Al/kOSaixP0W8
MsQv4ZK/8Py/yHL/AEBL/LhRTFjE1KYz0mHQdclh0CX+U4w6BL/KcVLF0jPLJX5ejPqp88anl+Xl
9g5I9E0aSKVaqaVwMXqHlZSIkydwfZGRLy/bGONdsl8IoowoVc2bNir/AP/U7/lEZeViqwrXK4Yp
TNTDaqfDKKYrTNTDaqPDL4YrTNTHiVQMdcaYsE0yqY8RWkIYB4ZX1ceGDOObjh4ytIP6uPDGPag9
sH8c3HHjKpS1kD2xh09T2w44DNwHhjxlUkOmqe2M/Ri+GHvAeGb0xg4im0i/Ri+GV+i18MPvTGb0
x4ZFlxlIf0Wvhjhpi+GHnpjwzemMFL4hST9Gr4Y1tMU9sPeAzemPDGl8QsZk0dW/ZwM+hIf2clxi
HhleivhjSfFLDG8vIf2cTPltD+zk29FfDN6C+GNL4pYMfLUf8n4ZX+GY/wCTJz6C+Gb0F8MKDMsF
PliP+TK/wvH/ACZO/QXwzfV18MNo4iwT/C8f8mNPlaP+TJ79XXwzfV18MbRZYB/hWL+TN/hWP+TJ
/wDV08M31dPDAhgH+FYv5M3+FYv5Mn/1dPDN9XTwxTbAP8Kx/wAmX/hWP+TJ99XTwzfV18MVtgQ8
rR/yZf8AheP+TJ59XXwzegvhiniLA/8AC8f8mV/haP8Akye/V18M31dfDGl4iwH/AArH/Jm/wrH/
ACZPvq6+Gb6uvhii2A/4Vj/ky/8ACsf8mT36uvhm+rr4YrbAf8LR/wAmV/hWL+TJ/wDV18M31dPD
FbYCvlaMH7GD7Xy9HGR8OS/6unhliFR2xQgbKyEIAAwzUUGUFAx+KuzZWbFX/9Xv+bPAGbFX3/mz
wBmxV9/5s8AZsVff+bPAGbFX3/mzwBmxV9/5s8AZsVff+bPAGbFX3/mzwBmxV9/5s8AZsVff+bPA
GbFX3/mzwBmxV9/5s8AZsVff+VtngHNir7+2zbZ4BzYq+/ts22eAc2Kvv7bNtngHNir7+2zbZ4Bz
Yq+/ts22eAc2Kvv7bNtngHNir7+2zbZ4BzYq+/ts22eAc2Kvv7bNtngHNir7+2zbZ4BzYq+/ts22
eAc2Kvv7bNtngHNir7+2y88AZsVff+bPAGbFX3/mzwBmxV//2Q1lbmRzdHJlYW0NZW5kb2JqDTMg
MCBvYmoNPDwNL0xlbmd0aCA4MzM5DS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZw
aQiwIBeRynAjOcxARSwDRiMxcOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRADRkNBcNJpFxk
N42MhkIBoNRqLhgMBoIBaNBwORcORtQzkZZBFYvGY3HRBHyuKhAbqfIqlJRANRxMp2LRuNRiLqWI
KbW6jJKpVqyDRhFxyMqANhANhjYxvdbVTivcYNCIVO4bD4jKxoM5wNqFeLnc6NFIyOBmIBlIaDQ8
yNqSNhrlzHHxeSTbAiIbwaUdXKpZLrZI6nFrBYqJZbPabXE6hsq9cK1c77dhheL1fL9a8DwYHBYP
CSnhodEIlSIyOcxjI3YK+N7OMxhYxkMOteN3Ibbs6rKBVBSoDReRp3AipKRnGrTkRB97RQxonCws
wGCzhqHKLCoj79P0Na5KAs0DjGBoUCGOQ8jgOg3jOOQwjgNA0jGFIqDUmCZvugQWhgpIZBwvAqCJ
BoYLMG4QCpCMJjeNwxjLC45xDEb4qG+j7IovYQP0GciPmGCKKEEAYo6Fy+wPBMjIqGzLxSHCYyME
EGRTGKqRrGAZO4Kg7gaLYUCDGgUyepAchQOsMDkNIwjYEAjDeOQQCEOo5jyFIuioJS5KIs4YMsy8
XQlPo5jSNwyjm6Y8DKMc5DSO1IhcEEfAaIr3szFT0q8GIbxSsYaM88CmKcGjio3JstKSt72Pc+Aj
LxISJM8GrIS4GNeLwGikBskVUqSG6hwRQsFS7BoYv++kIy+mNlTPNMKBSFtSqSFELQwEAhxxHUeU
DQdPPe1iVoE2AapuFwa0QEEWBcm8Zo/dycVMnd6Xsr93hqG7Lhy76dBAPIGtCjSYrwHFDvuECT3y
iqOIvFIbMziOE3eyyBBvVQYhrjV41OHLL4+qeRYkoN65NebPX9iV3o4od+oxf6cXii2bRmOwGuXZ
kuLnBjBugy7DupkmWp3gicqHFIc6iojxyiv6UWYoEySq8ORaHhMB5aEGmhnLeoakFuqRmtaUsjBy
BS/rtnXiu0VuxseyqTs+06ttmt4/v24wZeKKRWi276fvLsbRFO1KdvsUhi8Mq7fuShXrFmxYLxGo
8Vve1xhAfJpv0XA6+n8V5Fw8q85qfGb50G3hdkMsdl0t45hAPVbNzvXc/L/Q8gjPJrLLnBBgnEV6
ZzXV713vHdhKrx8QnevZ1y6Bd1xPW6r3ygeBeoZOxU+teq8nL8zp3md57nn9/2Myen23I3qvv0bJ
zfm/Zq/3eii1TvEeqk9+iM3suscW/ptj3nYnga6Rt4rCS9v0LxAV/LjX9wKSqkiBb5G5G8Ju6l5b
u3twWgSUGBavYMvyLEwJ+zeIDOefa956hG0tQZgBB104N3lPphFAeEjoIZquRmilp8HWYHeha/h9
cP3fxBSQlUGkHHBLcBkDZu0IXtQ+dfE2KB3IiPyYWsWJL6oRxbhlFAy0UIbxTKRFWAkWIXvOguUG
Ga8XxLwgeu5U4NoJxwgrGaOiVTQuIXc7YGRZ4qlDgpEuQDkkUwokfIZuiV4xw9hhHORy8AcQNYDI
ZwjGJKxZkvCVJaVS9OxMc5RwRMV6x9h5KKOUpHaJXMgWiKseUyL1QLKGOMCHQSzlAxcs0uGYHckX
GV7pQZZg4iGWhv71V3pklc/eMkWpkylcYkVxjwG5Irl1CCV8vYmPedowJ/yUZbzQjaDWRUfpGTXn
LJRxkw3qngl1DuaklpYy/Sqdefsz25Ecl09id0yIYzKSqw5xAOJuOCbJLqXkf54UJoXOmgLhFh0R
nfQdJqWTQUJnpQEsR/6NUGkxQtglCaAUOdOqmks1qOObWA6uhrCQZswJ7S+UboHNg0diXVX1DnkG
Lp1PtdRryXquPwX4nRZ2opBNCTNFahiwLwpmbtWTJjsLJM8DlZJ6yrlxN4VwtxtCwr1NuWY/rVqx
qjVo0A4RdS7l5SKWQ5JgC4rNIEEtQoSkuBqkEqUEAdz9pWKGE0EAWwulzDIc4wgU2jnTIixNnTL4
BnrYmvuyy/rKQsbuTthDCl60uYcUBiDMkAMVVNLYy9qGKMeZAypr7JWT2xZGyx8Jl2eMjZmtCzbN
7KLyt2z4OZrV1ktqTFZBzIqzlDI+qmNtGbmk8uUkUo5M6csIP+dZlxfXZF6Y1dAjbwlipRpcSe8R
jFjIlJMA0mhdjQsnJkYu9t714RPunei8qLCBXTvEjG5l8wQM+rg0KB7RSFWRMRe6KN91+FIJojNQ
7x6TSkfE1ujqziaEUNCdi6+EUnPeRnTCOdgm2lBf9homi8LSYQpJhPEdO1qK+S/NrFRPyfW6xdhL
EWFUYAziLjWoODFgrzx3iEoOMZ9pfqJid6mKmcg2Rnh/F+PcSQlpCtRLGKiNMBZrkfGGPkv40azE
PFRSCwX9zBlbGRd8LpfYq14nsjwcM7zXknMRQGb4nBm6UnqBAc3MzvhTK6MHMZ8wugwnpdjHYPux
jzPGhUvg5yCUDJuGqomOw9oPJUvnITYa3STOU7C0UzyppDQmbUnuUbhKq9xPrWZG0fkjVOS3ZZPb
hn5XpaMdazzDpLW+b0HaJ1eY0xmssQa/1VsfE88tMH4JrqfWmnZxrQzIcXIZPViTD2lsrWzIdK4U
zkY4tB3Nu5s2/s5L9X9xm5o/ufSOqokYneFuPRkOtkZV3jt/FKX4a7jIplLTevt0aedkUdoRQND4
aKWWhzG8Na8GBjV7hJ5IHqpJ/FbXuyeCzjPHtfSnF4+NV4htSM0h9woG5Evq4WnM8k6y3p/J+iry
ney/wTffBjM6sdkjHkR1pD751RyZ7rZXJ8WzlauHXA+Oc549RltqT8t6KO8lGm/Qtp8vYDwlJ+Zu
qF2WTxvfXEePR8650HpJlNBc47JyfdjpOLrJSj1vkvL409RfD3En7H+b9N7b0WlPUYn9JM8RjNXb
OiQx5i7LZmGiMJReF3XYB4NhLQ1cf8jRGe19+8S1eo67KkqILRUyQ7eaoEUiiRZbdVSzHmKcR0u1
WiLrHq9c5n5WCtVtN8VQ2taCyVqN1689HuyPM/ryXQ4hxq6nDatgU/Ve6+1/sCjOwhIS02IsVYyx
zRiB2SvdcrAC88BXPuUTHD2ArxXWxcyK7V3i+snKQsAgV+ikXqLz5m8/3/6vC7lfS8LBq+L2a9j/
6+C/DAS/QjS/j8Qma6gpD8K6a4hoJU50rT4ob6qwwECxC9xkJeoGZuykYvBd7QIvAoooCq4pwIUD
Z08DzWQpQgUESFEEpAb1wgsFUDrDzvbCkGEEgmUGZq0FKn0FbDws6KIy8HYokHsE8GsIMG4qK747
EI8GUJUIEDgzKrYuzOozgnEEcJEE0GkKkIT+7XgzELcGMJML4livwgSwDXKwYnkDKpKKq0w7D8BJ
49aKJ5CXa1YoQiwxY77PsAQyYniexAwnaHTg4ixCIxZxikjqovY7CKJN6Gq1am4/x8KqwgS5QjAv
ERSbyZkMSrxkUPCqwvJnMS0BxIrKRKKNMTpN6J8VRkwncRbuZkS8pd0SCgSHRGa8qlMRSh4vcTMB
wtIxb2Jgy5RK8XBwgqkTRv8XwmRZJGa1Yo0WSh6O0MQvcUSgSr0XZAAncXyR8bkEwgUYjWbkYxkc
ZJDSwy7kYsA0S9zICq0OgnEO0chAsTMZ6nIxYmSTcWpmDlRCIKZBqGYy7VwuavwucNjSw7Cwkd50
7kK6qGq57PrhQ4z+LOq8MeAjIobkY8a+qm678MRVMPsj6okWyKJg8d5VTCkTUfMkh+q1Y8Yy67Ui
Ys0QyIgo0jAn4icipEona9EiZGIna5TEAxYn4jkoT+rkJn0oomZzD8qdkQch0jciwnZnwMUlIiok
TSY7EiQnDCi1YyxGcn8oyJ7qp5MnJ2Qmq1adgocn4z0i8PZqQk8q6vTDUiYvSraRAgUiTjKFEQ5Y
YvEn4jQ8JhpujIEjApBFhfgs5j8n0d4nAxhkUQ4oUxwxbwriy1YussUhrUsvJer+Zq4miIkFhWST
cvbBhui3wHMcEwM1ApJ0Jkw7ccanwiroM2LKTAbBgs6Gs26Fi9BVxKJkJsQkLkM0S0x9BJ4i0mcw
a3wywmaMU380bD0LCYYk6BMgZJzi84BaC5g3LkK584Ami/sLD/K+kEy5j1E6Ex84M6Yqczc407he
c70toBsq4xcyCTYm0ikO47RYcK5eDvMsZKLs0Q6r00Epg0Bjy+FAM9Y+8yQ4hzEuZZ56M7JrzJgg
Uhk8T0Z1LgKJE8CRFDlAYy84wy1EJAYgUpc8M2xug7k+CCYuz2EQbNBis1a+47EXwjU1a/sBLik8
wvpmswZd0QbzJshecLcdwxaNpLaZj0cXEBzi1JhYEqsd7zLkJehjEbLaCyxgUagjRaNLZyVHB2Qq
hehZMkcwci5ehggvEpY/hGLKcr0/M8w0BhpYgqlJNMaCZxhjMXzNBm5ppLUSE8Lq82KdkPs2iK1E
LKQgRCMujhKKRZ5JsC5Fiw4l40LJhIKVhJcF8MsHkL0H6m1TBJzia8xkUKMM9UFS7SxIMDhYYndU
9T4tcFNVQoVViREHVTsLsH1WVUNVZJxV7QMI1XMKUNFWgmpyLRiMVWFXcFFXtWpsVLy31ZcKanh1
anx1aixLydBkUhidkcBnZXjoJfDBsjoujXg2g/jmAi4s4vYvC0M2g8EQzgK8CdhIgiYi4n9EslFe
plooYsrcooadgn8kUAQ8Iy9Qzg8yRqCnJCKdgzzicQ1gaFktitChgjaSlgRy7KdcNRhhIns59cAj
dgM4AsrDxVVkdb6yxd1joMQ9pZqesebq7Oqqwy5fA7UnZ9A7xkTDrqx7AmTygr7BsWJsVn7i1hpY
4iZgdoo7FhCHRw0xk4VpqqdmYs0d1qRncoxIthzxi3TsD3loVIpWQ70RKmw6xitsT3lm9mVrInY0
NmJhrLte9RsNM7MhL8KwlStjxLImpAxKLQKzDBo4qRUxNItrYiY7ByIsU3FjIjJXJsCr0b1jzHCY
ZyJqFe9ilxtX5yCjNigjiCbNETlj1Dp1LzKXadguwjh1MyBLdfhhyCbKJGdo8Z5iCr04IvFjKFFv
ojlg5Y40JpipYodo6rqW9vosI2g/6dCAjCF1goxrJpl0AEFo7NFIVyqVt295F3ZsULbi1rYjJpgx
pJto8ox4gpVv1nd5BMh7Fh4n1oJACkl8qm9sidj+pLd8oo9kcyApVolAFphYYtCCYzxRFyMgJU6D
NCpZ0gz6TJkhdSxeIoDlVvopQvFccxKlOCLfBiV/wsBuwn5qK1phOBwpSRRhdIQnyREw93SW60Kt
RJ959/gr6tRFdwYpMT+FZFNz1zUDuD9+YpOGaQ81uHiTd5UDogQnxyCwRqJ2R4Rn2IxsOJJJY2mB
w8hw1HLs0q2EA3M/OJLOtmuLAiqr96pjE0GJoibCRsDbBkd/zSgi16psi9uEzhx1MxKNNCUupwWB
yKJIJlip6zGPC8FZB85iRdy19UY4gqmQQmSPjCSAVhxkeQYqhyM3aW+QRAi316o70x2JuPOHOPk6
2ECltVjRjq5fBgME2Nhqjq+QTlhXJUIidnbXdLBJxUInpkWJmWBLYvb1DreQTHA+ZULKWKMfcQAv
ZqByWFcLDidUZwg0OR2UGQrXk1s6+AzVwnwmVv7VYmZ4WUilpkWFsMeQULA+aD2ZmcFAGULnuMbU
ma6ATzBjUq4n1GDhGSOL80+eBWGPV1C32QUcFX7sCFGfYmaFGQF7OcojtxBsCZk0Euh2VCkgrS1D
GBpXmWWXRkWUmAMqGXLFhGYnzjNTLsFv+Wx05rQvY4iomaoz+br0uCWGFn+YeVFPmEAyg4tUY/Bh
2GDDjlTrpimjaqNt1UZfS31hrUg8ONhbgo1gKqJh0ghYGHtNmmJeGnOphV1piqImmbuphGWm6CVU
Yzwo10OewuupZXlwuQYo+cUy9FGEELCUBJ8t+nk9NUbCByTHJFQgWYheBeWoVn+m0YDUtg7WAmOu
xUJJFtrXelOil6M+pWw+ONhGglNL0T75+G8URaEVdxGwaUBZeOz7YhQoZpAiIuZMRbAMoORbVUgG
oFAOgNIMxD4MIOgMpcxQhU5VLEddhGhF5NIIIFMS4GZOIOgNBPQNIOhQBQRQhFGB8i5behhRYFAK
YNIM4N21wOoppTpT9athan9bIiR8Ay9Sb64l7BCyD7rBZaLFmlK+aUq57uR8JXKCIyq6hnKJFvsI
slA/7sE3GQCzQ/9fOXBV6m47D9th8ghV9wQnj9zihyIil7Oo6Gl39Md2K9y0pyRyLvdFrx40GosJ
Mca71V2WW9FJHA7CVTVHrqs03D2B5Ge8tgXE5V0d1lsCTkTvZiAvZfSj78nGWNkdJYHFK1brpJw7
XFe/aq3HMUxkURViwv2Mu8wniTZltxHHU3Ao0h2y/GvI3CPKeWV1CSgoxqGcULZAPIRB+n+Gl4K9
3HqwWnRAw/w0Dq2U/LVEfNic2WXKuxNR2G8giPOpgo6AgihqL4r1oirijSheDfBGVi5gYn5JejZb
hkyAnRLY9hpKCYbQK03RdHJv/QZgNtpKCryCfPsf6CHS/TyqVgPSR7D2N03RjY6uTQNG6CEyCSnV
nVMt/QT1F1nPXWpvNsgNBja+EnHSlZCzEOVP8nWucOUB/AVpj0says9duxKPR+k9Aip0Isw619nZ
qW/aqWy5gu0+/Z9UiUBWQxnTZYjDyInW5YhrVi2Tdhr0oxnc3Ui3g78l8yCJBmUIhj3euIvd0l+r
qUC0PcBrRlBVOTPgMyVgZg3e67Ff3hGTL0omlf0Ho7nhXd8/SK0+lla8cz1nBiVUhUpjyRDs3bQz
pizh2tPbRmgvJN6JHQBgMddHIvwszHEspLMO3SPmZk5Q/llVqMUzNa/mVkHkqZmr/nhnfbrY/jtg
aMU5xgV29VqUs5xFnpy+dKwmXZ3SJi/cMZ+Ip4+bJ1Oa2ZNqrcpsXR/CHQw8PRznvTdgc2Et6FBB
6DF8outjvaGAGGnp2OZ1PYttonTFhw3vexIM1l1AENz61vPQHPc4fXSzHXCAgmXTQr5bim/RHSvy
NI/tPRXb9uPsnyvuHTt/fyHz3THT9+XTn0fePuHSfVFpnVSAn1fb/WBgf1/xHXOTf2nPnxZCPXhd
3X3v/tXYTwvtPYJd2i65nZJf5AlKHqyW/dp//aShmItUgsrALW/vHbZefo/s3gP7C8fcj0Zefc/U
vdK5n8PZ/fneGTfinei8eMfh/fP9n5HjQi/fy0CCH8f+c5/gv+9f6KPh0IgGggA0EA3GouGgyGQg
NgNGoyGMGGkCG40FwwGo4hUMhwuGY3HMDGQuGw5gULhsPjsfG8PGIzG0ZGoxHIuGMrgcPGQ2l8xm
Yyl0DGEiHAxEB2hkyjgxgUjFw5m0xGwuGo3GYgGw4po5hMxgo1GdVG9BodEMdHrtfm8Vp4xgo0q9
Apo0olcg1vsIuHA3l9lulujA4kI0jswtl1v4zF1UneFGgwqo4xA4nQgmMUGkkEA4igxnIgvgxoM6
hOaxNzGA3g0EEEkpsyyktkQ11cFxw3z1H1AwGW2HMF0Fbxgwog5qI4GuLrAw4WrqNaska0PMpuS1
8zHHG2c03WUhFSGkY3vahNlOYNIRUBoxh40qYgGHuEGwp1Vt3Nh3x7tXohUNoN97/viEA1gaFAhi
CFIqDU9KCt220ABirAbKqryKBqHKqtAh7ets/j/BAKg7wIKcEQUqKPPg96sBkjCvNQHCtMyqLlP2
/sCwPBIGqw78HPg0CONkmKQhgt7JMTE8OwBAEBxtEgGiK9CgrYgT/rU+EBqCmLbDuEAGu+xCEOGi
jTqq/oascpr7tZMaYIskSfzUqjKNOirOq0oUJzm3SXhyoLiIwvk8s6lYXJ82STUCl6mIbOSCwlRK
sJbOTEOcq1IKqssvUI+6rpoqqFu+h8zUfToQO/KIY0SmdF1MmlULTQrb1Y9U9z6t9PhxU89pCq76
KGqUhtXMU40zMFgrVS4GjE8z0BeIzQQCKgzAbEyPwBFSMO+4obKIwCmuXJEUQDAYtwKMo5BSFrG0
IFA6BcFIuioJQGhaoIZpaqoWv2IkCCINIzjKOY6SbJ7/JoGspvdKr3wGiKZo620i3soj+rdUIZo/
iL1Iyt0v4PGKkqItyKBsiLMopSmRJFkrIUJYFMZJlSJMin2N5hkiJJC0FsQlQmPLuled4slSg6BW
LLo4G7bZ/CGNho1DRLhoqIqi3aEhvnIYWwt1CaugeZ2RqeuNHL9gU/req5NNGQ6ckQbNGqOJVLo+
H4/uKy2U84G2ajD92lalw2vuTUOPqzaUjcEHwFAgkDCOY0SawsG3DCE3VLykIKJq6mhtDkaxHHGC
STK2Chmy4QS3LqOsSvIQIQoLBJeG8Is7fKcN6EA5DK81l71Zz376hjEhlar4Oa6iIoLXDZIdIXOQ
+/vRKJAYhCwEAXiOKaBDOOYQCKLGCuVb6y3oirvoxEAG3IIdzXRdQZXYNIzDSMYwjoMoQCsFKPI4
FAyhSDAFAcg5hpDeG5d68UnJQXCws8z1XrhTKq9t7r3zBGodkbYGTWSOHYdkSJ2h6lCO3dy7tvJB
WrvEPe8Yl57CcEJgyUE4RL3EI9cU9R6z2HtPce8vOGCM0PohXIFN9i+WRgoDSGENgIAnB1DaGJ9i
8F5OhgXDWBz2IIw6go6qC58TiEGas7Ml7tYQmyhGEJ3kJnhrhhU3IxDbiEoQOSTF56HnEvTiq9kE
EEodxBX8G5+odXcggCCGwM4b1zxEJFEYOgaA2wHijAp0UdobwQjzFh1MFnWIQIoS4lUYAQRieHGR
3UZoSvChQVY6cK2tnGQwXqOb0YqSThzBN9IKAkhzDmHVcwIAuAoDCHWRchl0FKkSGkOgeQuApkdA
mOi4ZJQPivLSCrqzbE1MCRYgcnpQQilHGeU0apUqlIaRVYCqExE/hm7+WMD5Zx7BQ/lTgM5fP/BQ
GwNIZJjB5BAER+rAJluhnIjwokDIbTQkrNKLUmQbL1K9NmD0YYQShdxN2UsJ5wA5eO0cxxLy2IaM
1K9yc64cUHncFMOoYg1BlDGHSXgKA3gpNgDQFAdw3LmmTP+SBHC0JRZI6OgsVqSRZkxNU78G5O0P
k/RGbkJD0RolPGsiK9THHxXUdudK4oGyyqDLUKFJ6YFYnlPYMYIAlgpYu/2r7/J9BJDcGYFLw3+U
vgBIcGRXQUBtfrASA0UJmFECUgENTCTQEfS2QIJqXKfyUj1BRbpxCPqohgq5ihxiDNZPi24iqL1S
oXKlRwu5vSPmXJCcYgSqG4G2UwnYGZkLLkUrqQky5YqGqoJC1e2CLzWxvW2d42SmDrpuKIWwmZJC
BHfIKDljRbDckTVLb+5FpSplSQsrFPhiTjnxuicY21orK3BQsRVVZrHSmyuEXgpV1DfAzt0lEhFm
0TAzvJbs3Z9CnEcrrZdUJ7DbpmXqdi2hTSL2buOae7CKmSmXIoZq8l0UJNgTtVMtiMi2YCdXdAih
ir3FNNUWw3xe0ug5uHGnCKhFImXRk12jpBqP38JFdhCtmiyhTYKQleqAYGHvr+e+wMMKMOnS4mY9
bsrL0MNsmU4RFUJZDI4SNNjr8ApSIMURQ7ZLHkXKangxGG7vmnNsHkhiZ0zWlt2d8gSZjInfsuSF
i5H8vZANbmK0ZH1DksW3ko4xGFDp9MxZAvDrM3FcyU7IohRs3GSuDQtX5W8jtOb5oi+BtijLKzCb
HQ7OUYZGNpiJnhOjbZzulRxmANT26eJro0xDWSEqHZHHK/5MtUrJmbOpAaZmc6aMspHIxIYM26eM
obL5zTBHxSKW7V5MTQ3nQgV0mqbFGlysvifTuX5NgwsezwzWeMv612rrdTwDVpExIeXqx5eSRHEB
AmUwq9iMQZMQUrXxUNylVgyhHcxlSpXqdbtSnRAtCTEobBlhzFzCZqhdvrQRr0+vLBha6NObUhmt
3GVhC5hNw5MQg0/cxC1pFBxoRzGzitwE0b5ZS1bEyj7hxRuQq+7+HowjhldNjcMRJFbdtHkLTNkw
bylrBMyjdQFRVRkXL7yTr2XNyotQ5gb29ByuS/pJNOJ9MItzvnrbdnk0ecQtZSUWExvdHDAwGPij
2u3Xvor5st0GI4FwAqRrkg2dKJvMiuE9+7h3xBkqMcuQn37wj82yZrhxy3YWo8eX96IYxBNROSOs
hEyOTj1M1YNRRcRdQ1QHAZq31YvoriWBCZNwaZoSDWjIuIM2D5EmhNiZFtwCmZFxaPVkcKdftOZn
PMlts167JF5DwmA0hl83PC4udAp76iDPccjs08ATS9vg2SmfhhsGDKje9QgL1vLfTWSP72RXvngN
vdYEPMcbJLZkae2HS6cezM1TC6o3Ol0GxbTtnqNp2EheMpYMM/jZWN/7ewmKGeE+P2DUL1NfC3Dr
JMv/NXmOFvP2LRiSv4P5P+v6tXgzAVAGgogGg4j0gQA0kuDYCMGkqwGmCLrXJPiCCHqeoRwQCBoO
t1P3grgQA3EPCPHmirDOQTkYIRwYwZrEiErFkuuFuRCJLoi2NGjUCWowl1ClCPwVrGuBCJjmrmD+
wLQMQNQOQPQgjNqPiCQkMnnOFOwlEonTQnCQkLiVGtinCBD+grgVQZD0jIwWwRkWDSCEgWwUGVKJ
w4C8Q5CkiMQ2Q3j3waskQbw7Qaw9QeHwPhE+tnE+jOqCI7poodiDs1QiGRwpkuvrMCDFCaGnGNr1
CsiwCXROtoiDu1C0CCLarLGzF6iDmvO8uMkul1RUmvQCI5FPjunSiBmDiRLmONNYqsC5GiFgCqDL
NLnUlJpXRijUunHUsOmlRQLVxSt9DLiVRQRKGNkfCwnYnSiDEYRfjGisCpmZGiC3mKRRrTGvRyts
Jpl7DZGrkIsmFPk5mLmcR4udxwipLmCqR1iMlpG8lmtkEPlpCkC8saEejrGuqou5nMrVkjHOxFEp
i4qBk0CXoGHyJsAqCyn1JDkzAUA8q3oAA4KYIMgUAqJhoAAiqzIAAhplv8qsp2KtjECvI5D3gqF9
yMHzogAUAQERiwyPmAl0SSn/F8oAJGyigUA5plyAqOSBgGjcrVlwyoFsGLi4iVK4DHCBFwSNEPH0
FyAjAUiIimojAyg2AyAWgmgwg0g3A6S1I/AxA2H7ohAxpAKzAbn+gQAng4H2C2JfA6S1gzyeg8mA
gyg2ylK+GCQMiAgNZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9U
ZXh0IC9JbWFnZUMgXQ0vRm9udCA8PA0vRjIgNSAwIFINL0Y0IDYgMCBSDS9GNiA3IDAgUg0vRjgg
OCAwIFINL0YxMCA5IDAgUg0vRjE0IDEwIDAgUg0vRjE2IDExIDAgUg0+Pg0vWE9iamVjdCA8PA0v
SW0xIDEgMCBSDT4+DS9FeHRHU3RhdGUgPDwNL0dTMSAxMiAwIFINL0dTMiAxMyAwIFINL0dTMyAx
NCAwIFINL0dTNCAxNSAwIFINPj4NPj4NZW5kb2JqDTE4IDAgb2JqDTw8DS9MZW5ndGggMTI4NjQN
L0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0KgAxEBnBpCLAgF5HKYygZzEBFLANGIzFw4EA3
G44FwzGMWNsSikWjEajkWNgNMwNOMSEBpEEgisXjMbjogGo4GguhgtG41GIuGw0EByMswkUzkogj
5XEBuBowi45GQuGA2EA2GM7G9SodFplOqEEGU5GQ3i42G86Gs2G0UGEYEE8GUaHN1rtGmUkmsfMw
qgpUBovI0MgRUlIxn4woVQqGIqlCn1AoVoGouGNwKkfgUEFowqgwGGFMdPqgyGtmKh3BpbFBGOpu
MhhNplNx0MJsEBzMpjOpyNJ0PIgN5iNW7OhpOxlOYpFtjn43FAgF3S6nT63V7HX7XZ7nb73dGgpL
pUJVPuNT0wgKhE1YoKG+OxhMfBO+/NG53dEOgtNZl4IwtgEA4DqMQ2DSMYQP64LaDGOQ8jg443jc
5i5sqHLou/DLuw2oDxPIBoqL81gktqMozt84AQQAMimwkFqiQGMg0jDCI3BA+o6PvGQzt+27cjSM
43Ro3rlOYiYbIrDEOSXDIcQ88sQgazrPhghgqNGz0qpu9TVNYII6xy2jjjHGg0wlG77BBHcetwMY
yjk44uBmGYbTIOkihaGYaBtJUNT9JlAOsGIYSfEERBQIMbDKPDZDgNgyuEM0VBANA8jE30WQbB46
De3I8jnO42hBOQZIEOD4PkPIWtoNEATdFg2jCNI2QoHAchcGk+u6rNCyi1giDrH0FPwOiHDMN45K
U5Q5jDHg3DPFUAjnIA3DTZ8jBoyoZV1P9u0C7KJ17Q4hwdCA3xOMI4Uq3I6jbWMHOYGgbopXNv29
e97UCGLwvHKFDimNI20dSFF0bR6HDfSUBwLA8Ev8pUaDQMtYzGhzmBnW963xjcOBiGtCiKwAopUl
iXAaG1bomiwYqkFwahqGalZPW6yqtlip5fmOUMsnAQZZJF9oEPIGhvJCMKEjqNBwuYQJPnc6ZWHC
fhoGSGadW+oZ8HDK3lpoGhqqYcLfrWuLMk+wIrseb5dmGvZRn2W5yq+Uhnle47aOwGq+8zGBAqA1
oKg6EinmIzociGv7CgWfstqm/BcuqLBbfYXBuhiiJRvjHoFLLFwTr6Qhhu2gcczy6hyuPKcsu6Us
Yqml8f0XOc+Gqc7Es3GX2hnTLtyac9XzHWs/zjLBlmLPKz2fAZftK19z0vIBzyXVcuovhNB4gYqD
x/teVr8kbFpAc9J3fo9R33K+rzMstDx4ZBgtbPff7zT7Swnx8b8vT9T3/1eu+1+Se33Oldo0p9rz
39O9eo6w0j2H3A4LM/J2Df2vq3K26iBDj3Iv8fTAx9jxAZllcfCF3bnwbGeK26N/MGoFP9g8Z98r
WTPJ0hK4ArDlXxtwfJCx88C3gwNSq48GgMHUGeiG8eExUytvOfw7qHkHHgPWiA+VbMQgaRIhsRQr
bMYMu8enC6H77IqA5eIDQHEWGTu/K5F180UH/RTcezB8rYI0A2MqVuHUK3eQ9jBFKMUcV5xxe3BQ
GzRlbR5idHuN0LzQPHKAvtx8J3PQ2LSRmFUiXoxfg7GEz8jo7PxMlJNk5GiMs2ia9B/b6Iovrk7J
GHJngbM9kJBZrciJUQtk3H6VsKAZwRfS/Fz4N4URnltAmTUq3/yOJG49oswHAA3Oe7CNkqYfS6ka
49qURXmt+mDEqS8t4+S5lYaAxZFSrGeJxM5okWo8TTlxMiIE5ZtA4BxOeYLvy4TumPG99k8gaPEK
lPaZ8d2izFifKqN7IyVkCZMDWdDMTTMZbqTY0Jliqupa2ZaWJd4hlTY8WuhxPwZA5LMUsFRTS8Ej
JoRYm5ZC4k9J+9tzBEyY0qKSUulBUCtlTouVgrRXHMN7b6Y0EASzzBKm4GqEdGw7ggJC9sJoIAth
dKgGRwJCCFOFcORFnbKm4M4baR9nbNavtsZ0ylnrz2hNEaMDdpE9CKtMauRujZHWptVbc1iutGWu
tnbC2qvjZnEtpdw3dmLV6ytyq7RNtbcm8hzAbQpkpL5hE6cc8ZJEvSBEfsrROzBG5oEXgkRZ4ytw
cg1dQ0MjBQAclCeMzguxJ7KryIY1VbTGGvWzdW1VmkEGvNojMVa3hOrfV+VxPUEFn7NW5eQYq5Kd
LQECsqWO2t0Llt5qFNxvrgCDVYcIQ0h5EbgXItK5AGkGDPzHInIy9brjQUCdAri09z7TXnZ9emKF
65OJVnslkrM3Hlk5odRBjF5r0GgvUzG/duL3E1go8wnxAry2twO6K/OCprE+u0aWNANUkNgvpga+
+CMLyMkG7GkeAGvlpbBaTAuFMR4WlVfqaxcL3AznUTdl0vcQ4wMTjJ1WNJxxFdjP/FVqGXRVwnfb
H+CYXqDiQ52CMJjPNyyXhXJ0nDEX9Ko22QhP8PXVvrljEuWsU3utRioGzOCzZXxjlmXTQcNlVlEW
1l0eM3ZNzLnF2uc8pw2wFb7PJn5wzQwxKx7WU0s0FkIZW1Ba9B4kxnod4WDnYwThMkiSWPcmX40n
k8HOUXXkWkIWmn2nMyafk4+/LkRM6kazXhLF+ndJZB0oaRUuRHkZqVvmt1GkcgO/yE8J4zs7mzqs
qW3Nus9U62heWNzzyDEYqmgZK4WzM357lYabRRljL7UKnHa122M9aql1CJ1xWY0LzKAW3VG2dzbb
mJunM89ygWh2BnDbcr3uY42oZUtGv9yae2dJwGcRMN5ygo0UoE9N37l4LFKyVDCX0OIrRDJEV6WU
VUGVZydGXtEWcxR0yzL6KUipIzIK9JynU0KOXqlhOCdUvMjTIovLi80r5VTkqNPCranJ5UAr3PG+
kCqMVCpBUKlQzqZU6cxQqo1TqrVdwdWrwtEgDdWzNobOQzxd1u6Vo8e5ptVqa1tz7YOotlEa3Zpi
dW47WrjttvbBXjuFSO4ndSp3Buf2C5lFtx9+unZe61obH2RZJxQBpYyNPagwXVl1m/FxmI22ryGG
vGE6Y9ckGBbuUtDNNwBUrcI70TJP5ljEGK4S9JN5Mkhdm1tUKt6dOb6ZTd7Bl7PxftXLSmVvhr0/
lPOuL8vhLynjm4e/IFdjol2nP3d6reBxDxotMs8556XxdS10IkZCHOcVYKPG2Fa7zpVOUu8+3NWc
e7r3RkxU8aO/CH3/YhZ+mPuQ5gPITp++6EwvyP6P0JFszMuCOoavdpKvrvzPsr5vuMtEtnXGqs/v
dtYL5v5wFP6wBM4tdCdHVvwsCm3wLIiQFv7JxNiPRnXCkvwohuGrhPywRQMQGtzsvKlo0DnOGsJQ
XPznowSJ4IJP8lcMLQVNwqCwQwdPtQMpWCOMuFspRCxiKC0QcQAQdwkHhE9NSIhC7QVCcpCs2wcw
RwqDSJewNnap1CxuAM1wEwXwAwYpWJ/tjGXMiHACxtNDTw0wjQGP1HhAaIrsNi2wyl5CgG2wiwvw
2Q9K3Q+mpP3vKCgrSQvQYQ8jSKHMuPexFNew+RBxHv7nhGYQroUQOnPjTJYLPRHQ1xIMqm3nXGpQ
JDTKYk9Q7RCRTCgIAJsQ0Pwm0NfRXxMwSjSC2oSnTQgxQGYCgCxxcxSxNReMTnTQZw5Haxhxiwpx
CvEKFiWuKqHrkuMqJqQqLOPCOjKuQqOEquSqQKKqRqSm9OWKUikCaqWuZieOaihKZiQucqbm9OeK
diqOfr/ugn1LsuiqiqjqkqliLKmqnuoKpKqE1OqKsvpCIvMvkGWPlGZPUPLSIvMlStIRHPQHmNYv
SHKvTPXCNvYPViMmvPUPYGWvZSSvePcqyyUvaItSWSIPIySvhCOPkyZyHG3yZMNPDuJxqJRt7mVn
LKNCPSgGpGbShxvpYn0mkCenKuTLVLMpIOQlcHHGnC6MLHuiqP9yrnISso7HXihLjC0GfSwHRSxL
ByyDLqPKNyus+y1yiCrtYSSS4RvvmCwPnIKPoSFnDOrxbncSnCepQHpQeJ+MiniLnMHwnuTDLo7u
THTJaxor3IJnXn6QtymzHTBzIxYoHHkHjHuQTnaPRHnTAzHnITNxjoPnuJBqNH6NNHFzSzNTCpGI
ACdH4H3RZnlsWL5zGynzZQwTVIApzrLQDMdEtzezBINTURdzgu8oHzivfo7GfTYzlTZr9zaoQpfI
SM1MqzSTMzqzgIYSBKlwDIbmYTvTfTwTJTxIjOET2o6mcDCTqTITrJrIgojJQQ9o6iKRJTpzvz6T
wjQIxoyt5oTCcsmT5zTz6pxz7sdo5zPtGu5SkT/0FUA0GjTpHMPM6kkE9zYUKTCULJPJIJYTEoTC
0w90Jz00AT1prpYTTCgtXlcSbTkTTUQUWPOpXThpYs6mMntT/UVUK0bplMeIUD0uFz20PUgUbTOU
cRPNSHKzpOFifm60Uzk0V0mJHJspsTbuFiprl0aTf0bpyrkJ0PwJgiKMcUq0azlwejPp5JsUyN7E
9Uk0rUg0mJ/KASWOFjKoQ01UwxISfKGxrKI0ZONifuOqMRvKNuRxwqPuTidOUqTKUOcKbR1uZCtR
3i71KR1Sirsx7qex9Kdi7x+puOjSAOlTxyCOngQOoyEKrS9rvy+nESli0ShS2Siylyjzp1by5SmU
fzkyoiaGkSlw9mrSgAcyvjEyuVjyvjKyzrfwhyy1nGeyxzAVeS3Sm1eVaS6SkqNyevEyfvMnLT5K
RPJPMrkDL1yrkvKGiyhI1CLSNGgRDtE1CyaC6MQHtNFvWvMrTjCCgnivdPqFcHnV/is2Avaoq10v
NV7GXK0tqvR1xK8WFPRy7m+PnLuHBS+Ktvdl6IBDL13zlJ9vuvvwak9UZTSWQTIWRL9tWrfQPGuT
P2PocUnnpWVprP3N02S0ONp2ZIU2QzwnkuEpAwPC0vUzp2UzT2bNEMNQINvwPCSLfWenpWfz1q7M
N09RQMCpe2UWZ2qRYlSw3uDwawVk6IuK3Wu2VTwjnMNk9RVp/iNsNWpWaOHT1iyxfSQxFUvLcW5W
vTUvK27or2x00IRW+W0z1k53AMbRQQ9iaSkWkWazwoaMNsQQVU+LnXC2k3IiuHXMPWxkkKRz5XH2
6RYmqNRIT23C0mmXMXIT1ls3TQ/iNPc13W0XM3W0CpYNQxKi1XHXaXWRYifNRF5r4RQrLSm3RWlR
Nw+HXSSRbKRPvXV3R2/DTtoq4wam0WJWz2fXDRYtNxUpCv3xhH33Z3tXa3uRXHXWcRgicmWTAXjz
wpC3qLT3rRvJa3oXkRpLJmv1BxsVDRt1Ey41GKPOTRtRyuVR0VNuYCbVLuaKYx4Obx5VK1Ox7GW1
QKfx+PmqiOjgQOkgQOlq6SBunJ6yDOpSE1YOrPp12XsV1CP1zykV1VxK63s2p14jLV5i0V6vg171
/V9WGV+yy31yWSX2B4f2ASVF6TSV1Yc2Gym4X4U1yWFvDqhi1MVNFihVVYRVWCXvxGXTPwnCKr1m
WCKo8DmiKsPC7ghPdsBYuwVmipTYxHzmw4zHMY0Yto6LnpKsjYwoIY4YyirY5404uMCQtuz49Yx4
44/Ci46WTY7Nit2vH43jz4+4z5AZGC5xhn75IYyGt5ECC5KYuu3LULC5M5D5Jp+oNMjHTWsHAMqv
NqmvJqeL1lSi0pIYWIr4araisrLNIWyLcNWDLCuPQGqYuRGi0wj4vVdH3vfihZgiKLWyMUeralsr
5QcXYsQCx0T4uiqx8GYjRw5jPwWreqIXGCbtf5cwiZpXJZZHGgQZu5pLzsJDLiqNprqIV51DQvjZ
YKIZ4pIDRgxC/Khv+TorhCOm2CrYWMCsPO7qH5xGp55mqyg11wntBaH1a52PJkLHtmqwhrSRAGxN
fn3uL5xC06PLk6CGXirZ26Rv5HtLiV16MLXHKIr5d6JM26Yt/Z26G54UDt/Ly6E6S3PsXaBaSiNa
T6LAxCWKkCBYPPOnUKmyDZXzbKIO3J6yi4vGxmqtNTbwzHIKNrhietf5pJoM25LCsizZ2tHNICyr
QLXZpL3rkvcuL11wtt8a4J/iGZ2iyUfLbCKrL5bCx6PnbK8NoXG63ici6iha8HIa6RvaXaC63tHD
05vZr7HocaUPJsPoRa91kLhRAQX6sCaZd2i6r66r/52vX60kkIya2HwUca9njaOUObIu3EqiBazl
cRiGq0DslE9yn6P5mv3ZrmeapX1nHbTO37hvI7OHwCsa3mwxXPMl5MJHjHIKJjRgptcIRmfYqYNy
Akst/ZXVxGe7NJD5atYP97NOz4lGqbpCQieyaGsC7a9ozZovf7gZQRXZgvfrnbP5erzxhu7mjPN5
gi6Ze64JD4lQoa3mgSycEL/7PjL6OJSOU8HihG81+La64DFPjJSbxO3HpHUG86j6/nIcHa4CgiGY
WOLDFO75Z3v4lGpbpUTpicEC4bPrT197/IycMNNSrAG6j6ACBQ5b/DQ600TybZalb8Na3iSIBPTu
LHLNlltLQ8nKePvYttQi18nH5aM5LEqrDvJoLaP3U8v8R8ia38jCBCTiUjTO9xLscHK1zRhP/V1q
RUccnX13c4vDLrhRhGqaZwgGY8Lc+7cZbIh8svFxb7+z+Q0c2OSvjMwOHSNIUCarPl9u1dEc2sCI
780tt7snvdGvqLnnbLfcU82txv42A8nvrdKr7ctGXMLP4CN8yXrk59RCKri8fdEH5axiNH4C18Uo
Z5rZLMePgmU9V5LUd73ytrSdhm39XbM8uuTCT8fjLH3btIKEssU7wRhE57OF6LncUi3dV9CwQG0H
La2CptQ8K9Mbb6wUvb43rw9110vMlDIit7OVDi4ZujIk9awH2NfjI27MQohrSeAsUryoQ7a9EMwS
SLymPM2jI8/LnpSb3dBKRLdm6yQuMVDt3bXu5RrjE83CNQ9iLd9oUCuePIzMJcntltYH29BIUIze
Jn0+V9862Mq7BDIqHZo0psLd9ifml93PzLXLga2U0a9dubz9CrnZ+jSFBzB2h6uMcrTMeK7DLP9i
PskNQncGxSPCr8tmbeujJpYJAiOojaLIbi3vVezoboh+1+ve2uEerEj+0Gp+5GpMkiGe0p2+8IIe
9eyIue+nVjRoTidXv+re/CbeqeuMwHHeteq+8e6DRg0GT5m29+uscChKxbUsU+zW4DJ7Y/AmjIgs
7P5mtPGmmfCUvfOvVktobnxnFq4CsiLIbp6vVGsRifCegTpCOmsCzfXvNmWIUC1/aydVkSn+0CKD
EPifhm3flWeYKSP/ivH8qvW/pqy8dfnNvPid0r/mnfldam1/ss7flm4T+YzGh/rmWfzvdf1LW1IV
jfyQ6mWCyCufvuSrCltEtmnfdvH/9AcCACA2A0bDEXDgbDkQDEcjYXDIZDSBQQZi4YxeFw2HxGJj
aKxcYxkbi4ZjIcR2DDUaDeRQ8ZjYQQUXDUcjOWjYaiA7QSDDYaQqGDiLDWbTQXDcYSygwcaTAa0I
cjeQwyRjWniAxg2ni6o1OoyQbxKtjkZTmqC6m06oWWWjUYjKsVq12YcDmSRyB2O2DEcUIaDCxUIc
DegX2SW8QVsZDO6UK3yes1aZjKp4OjjGxRUZT6FjgYWgcWKRx6lZ60XEbZ8YDLC5/GYGDjelYSLY
jU5egbQYDaYVkbDKZzSF7q4b8XDCiZ3XSqYxWa62ScysmYVA3XDaTncQRWERImiCtXaa6WDDGXiA
2+GuDPS58bzbb5uYXzPxLbjb38rT76DUnoPsgy/ug/KZQEzryvO/i0BgwqUho4r+sJA7YuKz78Js
viDMGuDfM++UJw2xLxPZCaVLgozxwm8zegaNCKPW6DXvQgiHLJGLmN4tDFs6hykOKzQYQwwzHtQ4
CSsKoTGJOmSGsqxyTJjDSEs6uySolBSELpKqWSYGKzBy9ycpkhCgTAo6ct8j6MIZMKOzUrzgSCk6
BzHKaGTiGc5p4g87LIrjETpN6MuAHNARe80MT9QsftqryKqsmA8z3MiM0eGqYTpKUyhoh6yTcoal
BzTjWLhQNQIyGqHqvTM+TLVKyz1OsyociCJVMkCM1ovFDzWr6S1jB1QpGxaYJkmlEtGnKdpkn0ys
c5KjKRULBKaxKoKktqrsja6vJG9jYLJL6RrTayuL2r63Q4uVzS0u9bXXcLOr8wFysHJDDxOoTFsa
i0oMjVIasozqRqkzKHs4+jQNEFzSP1K6CNU1j9RkrbBtmuyLwq3Dhrs3cWOMqzc464s4uThMZI9G
GJukBo5uthjOBgEDPhy5OZDWBruM474GsXTimrhL1UpWk4ZWGkoQBaiCDhimA5DKBohZeGF6ZoGi
Q5ozeZhAJYGvLejtZ69lzQxoySBoiT0ojby+oXszkBAiNaTyhbzMvuOxzluqK2wrIp6nqquavmdz
Jhm+xJGsmy29tEZsWuwaBmiS304us9MWj8H7cqqMIHx+Gbcuz8IVz2x8Vzez3e6nEOPuiL74kO1T
zhgZwwi7D8uktVcnu1sdKoSPdshwYtWibFpHvXX7ugfV5l5yF65l63JzsLboY+bNuOlcZpkxizMo
oaiqFgKpy844coVSTbql8sa+LJn0bqvwaJP9TgSIi8koY5uGPyi5I2mkxVSaksxmCuEsN8pwvhJ3
8kWIUcY2RU3wG8SWo9xpbyHGAgQi9C7blUqFSWa4jhb4Pl8JiZ967boMvbKyGI6rz3ns4BqwR+jq
CmtpK1DSBhrCjliLsTRyYMyUkISibEhcQiZxEgSRZap5ohrFg+p4t5diwwCK5FJs0NzURRaCWUiz
bSfRMewRVySEIjFvjI5oyMP1RNujSieHUHovknhnD2Ha4zOQtOs4R2r0HDvWLccOD7SD0yAKmDch
zkoTmgaDIh/pITbl1OGQ4/BIUFGsgZI6SsRTfm5kSgBhjEgYg3kGupZkopSGTlBJiQUDj4GfklKN
VJDCbIdkZK2Wki0vSHYARyQ0rSarqRdGFpsnjLkskLABbEo0eyjJjJQjxwzXONZS5EhZ2E/ymOAV
ZoM2DsSQfuDhDE2FFkxTioWa7BCMG+TiYOdLMExP3RI01WiEjjIMKmjloxCk0kkddPpCSpnawMmI
DBWMZD50FgrP6ghFWgAgfs+efNDjfkdnPPk4AN0d0CNDNejNG0Xp5cmTKUhNqBT/PdOJT9AyFlGP
wu+kh+KWxUpkmM81MzokhWWhopTFVqooaCVtLyIovlTKM2iWp6kM04N/HRjBjKcFEKdU8s1R5+VK
qg02dRIS81Umu8CqBRqDFAmxRolhW20TdKgYhf8x5rpVaMYmh0gZmRJrOSM0Mh5KN9YgQ+a1dSpV
nY7O6UbiTOG3JqfMG5QgYTrIJRmlUo7GQznMQ+Ukk63TETtI6wJcXmkkoqdpnR3jwS/lkesuEhYU
V0kdIo279JG17khLCY0m5Lg5kzbKTkqJP27NzKU1BPZUS9lXbiXBNZFyxlTLmW1sLjyvKHLyVUur
WXAKzMOBVm5mzIIJMqvVmZoIYKQ6l/lf5yVssecGtTDAcTgi/OOtbJKJTvfYkU49hD8TwsqeYpVA
IH0XmvPWq7KaWT0ss6SkM/4FUGpXQnBdC8CzVorRGfE16KKlvThVptH6TUho7hso9IMCYfpIcmk9
BKU4dwI66l0VVWSIp7TRLiGqbpeSrIGncZ6fVTXNS1Z9RKl42LRNaNdRamJQKMeaqsPzz5JqzVYu
OTizX5vrV0i1WZvVhsHWQoVZly1pq/NnKKqbOzFLvWeud3yn13KZd+21fSI3iu3USgxs7DH2Zoee
yRx7HQQsjYs49lDjNGLNZyZ1mpjWdKyy6GDhCJM4Pq5o7VpCtEpp6R9HZESuSBBbKM47xWntR0qT
PS6/SbSFU4YA+bkSDgzwRI58lLdMYdLdqSI7w2BWqlChgppx6NET1hXFFa/SYTJLRRUzEGaZEDb/
o2FAININnJZaJPmlCt2NKA2gtDsV17YIWSuR8izeVBNcZh/jp0vblYffkviGAa7qJiXYHGwtwSbI
SQfejP5LEE3lvQ8qYoAWRdnu9LhzkdnmfGUk1CFtkcD4Vtd/ZmN/rl28ZjfRcQxMvaMdm0uqdhbv
MPDiMJqylcDuQnSbfEeQcIe4wBgMRzBTOVY8QpRP9SEnkKjWmR5nIVxysX2Bj9NwyFMdIjb5rqOl
5KhE3cENZCsdIbt+4REytuScnr2g2xd+X6MwRU5GGKhcH20U/U/WzQ9XU52Tqi+n49d18Tnp8odv
vDwZ0og5wuJMw7Lvexu3yq0gWibzo+Q+RWT6vl1pCdGaWU54TN4vOWmc1dFia9JjCpuzIVIVVKea
qoeYFsyPcMDT7R0keCo/L+LGT616doO4D/RF1iZhjBPyY6pir7KJmA5Kb09nA94HUTMPInt7/Vfa
WtG++J1KA59vd8lPEvTkft9XFcXogr2P00wQ+LR6hq/y6iA0+58ZFnGdnbQZfQ96p9QcFm20SW7l
r/19zxCsU4Ff+hb2crrx4FfL89i/2kgYwsu2S/m3iItAE/ariN9AC/YIMLIS4aOiOPE3m9q1bAiK
5AmnYLQQw+xAm/hAYXMS4/U/YU4/c4w9Ca2JCZw3uZq9aPKWw7jBY+UJWJgvGIY2yIMo0JsvG3e6
vBwR2KyvGM9BuxDB0P6UvBk6MKk0C1XBc33CUOQ1Wlg8FCCQY8GIKIVB2XoMwQsf3CAhQ7aL+YYf
3BW+5CkWKPE+5Cas8AbCfCO8aL67LDbCijmBBCUBmSC8GciJzCUNS6CPqqhCBAaxrDDD1DqfvDmg
XEMIsPm+nDgLio1EXAshmJPCUULA2SqiFDqJ6wY8adrCcINDvEun8JDDlEksXE1CXAtEcOnDZEO5
gJmZqRnEggC4QK5EUL++ciYJZEgKkaC+m+DEe68mc8bGAPeYOiCKhDqM0YQ5MTRDZGXGQU7GUz45
KsYmtF4MRFqMAqTEhFxFfG3EVFodmYlFnEYfHFjFZGMM2iCW84UPTHVGYNGMRGMLc8urwOFGMvbE
ZHuquLCX7Hs7vCxBIOwiPHkLhH8JegYbHDug3IRIIv40/IOgUYE2GlJD2O5HER6KtGCJmTWJeTPI
vGPILIjGnHXJHIZDWUvAu+U9ePTJUuM7ypEMSWG38doJCjqKJBbJsyirwnm+6I9JusYw++7Jk2vK
GQiqvKM6uPciqjqnE5qM+YCzZJy8HKlJ4I3KgMmrORrD8KPKbK5JYQlFYMkMHEYionRJcVTLK8GQ
YKc1w14mmKKIcQfK6ckqTJUPfLgbPLlJXC2fPLdL6+mMI33JfIUcgiJLwj68aceMTLmShMW1cyjL
fAtMZLI6M8afoKdLVMvMEnRLGU4NlF84S7KJVK9NEIOwYMk4q+mOQJyMkStAtNazGlCKBNZI3MtH
NNQjpM3Ny3fLvN5FeKCMSgGlEdMkDNehHONMIVTNWcTOPNA1/FrOFNLNDFfN9JSIqgpJGMo7gK1O
zIebG5eKIT+LMbGxgMSVHF8YIpkMi+NPLPWrPOhPUMnPRNNO2qHPbPs2GnRNKYDPKvDPqIg1u70y
iOcqG2GN4KLO/IURrJvQXPvGcDMII6W/YSqpu7isa6udFAAMO2/LOTEdE4U9wy9AU+pQ0YYKuvHC
q9wJfIOYiKm5sN3GdDI9ay7II3uJw1WfGpU3uMY2yeAkDRKN3RqxCJiMENlQ8z4WLQpSSiEqTQkv
GiEqMhFFkNcQk3TDFF2QtMu5AM9RcgO3cPckVECsspa4ZD2QDI3SwJfCxFAsI5AKTE+dxSSNkIlC
fIo5sKfCwPchG5sJwMhDYPq95AIvGIi3IOOR3SiTW5AaRHSJ7S5FArjHfBw/ApauFTsTicGl3NRC
wSMxZUpEeOAI8qrUfIOOBAnU2PZD2oy9Q1qKTUBEgOxTCKOvbEUTyp7Ki6jEhRW5AN5GdCUMJVnL
zFRD7UsdbWJUgzPDXGMMAqDU9DiTUpbVFB0odREYCaZJCKQcnWuLDIa1S76S9VFFPH8L4PnWuTzI
kNqp6nbV+1S9pU2sXEob5VbE3Wo+3VI3DCAI+KvXhUxTBWkdbBo68c1XCn9SehyK4Jw2+rW8zYQT
BRgLsMojosYilTyIw6q2yh+iqW2vY6CdERILHVq9wbQsEe1RO9kyiYxE46E/XKCT+6CfGKuK3CvY
WLQjbY4JLRgL9Ey2vMe/uYEjqIa/ZYZJSkpGG5tFjJcIcKtW2Q8hrLwgu5AJVJueRYJV6+rYQkVS
xO0jqeDTMLRFPa6Kja+lHKTPXSSL7ao1s9wKejoWHOjTyLYMiRqf85sKbJukpY9RQRPaM8k03JSV
eTs5AuNLSIeN3WM43OGJI+A1qhnJugGjbU3VHNmfQ3cJ6uNJUJNXMJTNSk+KA1qYFbm23VmULbwI
3UOILN2XNaaODGcMkN/XMPqU9NfMVV7AmMkM3c+ZpUBQlPGLIqMTi25PG/WgZXPCrNKMBc/VEeLN
KclXWv1PyJ8qqo+IVNKJreKm2bpNVXBWuI4rbRlWMVEROcq9u1qJ8jo7TWSKfdcVHFPU2YCROOc/
jXgMRd9IpWu77FYtWIkec18a22jISBA2oO6BAZ42vcOMWLW5EkoOZgTdWI6rwPzgcLIPsMEoqeOP
XSWT4LgWIMuY/gtg5DvZMI7hAbiJM3wPtgiJsIhJ6WLgYIlhY1aRZgOJhhinEUwK0R6iJhsyazIu
MIgMEI4MkMIaLhEMAYfiHh/I+KlhxiTiKcSybh1hq8xiEsZgRioYe4yCECoAaBeCMgYBACpQkcqS
gefLUbbLxiUtpjCPS0bBSj2CoKyBQCQDCDmDQBSCoDVDYr8LgeeMEaRKcli745eCpjaa2hjjgDuA
aBQCbjxj0CLi44Zf4cIZqJscPUMyGNyKq7LkwbQNzKEaKQe+okOfHMizi+2kzlKquIi1TFo0AKII
VlY2PlSvvlCZ/IeNkJmqTlkKatzX/lksasVaWYFlO/Bl81iKzkxYesw1jk7XekcKjhXlFk8OHk2L
iRdlk4sx8LA25mzaiW8U9kwKRc+W8KvnFV4SSOTmTlFnGmuNUe2c8+7XLnce0JZniPKiIS86Xnsb
FQtc/n2eM+miErJFAXeIiSknzoKeM+6IQowvmdKPFMununRohbApGfvCqc+Qem6OAMphW+mavouy
GLjo1QEaa68kVoro2wswObw3lDxpOJIpUc+KioSjIpVnWNUmWwJnDoYILpYTyJsUloOT4nygUndo
roGmvqPn4c/qUwMJpqbnlnyRzqjoXnwoSYA3Nnioybgabq1oNnZq9B3qlKjMUvGjbgcMGkzVOkDr
VfcuXGdrekynVhhDCJq0LLPmkocf8NpWDpI6wTXr8uQIisYs3rqbi6EN2t+KHsBsMNyoyfiblpk0
KlgqhmzMilHrNsAgVaiSSd8AadWtHgKPBmdk1l0cdmnmflBsSUJXBlflM1ZmMOHlVs5SVtpl1li2
1l7twoNltlnmrtRnXlvl9mjsTlbmEMmJDmLX42C33mVtfmHuXtUmNuNtNuDnURaZ621m1n1m5tTs
7W3nBg5rFnIOjlDq7n+Ojl3vLnog1qui+oTnfqlqxm2VFqboE5VoBqS4ie7rDoQmvoVnvqKo9ofn
6gOoSwBpU9uOMeJljpBpM0Gpvo03MxAcbmTwgm7pRoNwzpYn3pdNQnHpvo/ojptplvZp0oncXvJw
BpjqCohu3xamJqRwPqfxnvxn8wDFhvpvjx1qtwHnnq/I7rDq6ynrBoXyKmk1tnjrMvEasbxSPrY7
vuWdnrWlxrlyrrhsQIizzryKPsJtlr7r1sAgzsFzHsKOPsOMvrtsfyvsdzTshy/t0kTfnCDsvu5s
zB3vZvDm2PYq4Zaaji4gyqgeeW8LVA0gYva+oIVkLBPkRkZkcAbkgZeN5km8Xks/NqILqNLLVYUb
VoZbGL482wZkwckMKcrCPugPmNC7uRZmKYR1Y/Xhq1YUL1X1HlDQN1sT5rl1pFoIQR1r22Ocn1+M
Hrttd1WId2LsASNXf2Iir011D1+QfmkQ12j07Gdmw1YJpg4ORURO7lP22biN20/mkfusoBl3Gb1k
wS8JZ3ROYyJu33N3aSCbOcvDCI9hh3ocl3sQskV3QZ+9od+KO8F3/kzoDRthqNXFTwHDvlj4VChv
h4b3FFAbhpUI53R4oJz4ELJ24IMJN3byz4mi/hDhL3Q8XyxSP3EOuwxrf5VXVxALLuWaoz5hC573
yNUvQc+Ld4cNVDxqJ4l5N5pxh5/RWfRcMwRgckQPn6N3R6Qdn6UVzy/34docmI1iJoX376qrxVrq
4fCJbbTyR68Tu3x41wOtwTg+3imSSa0TYJnUrgcJL1WX1Urwx7X10OxvI6QSFOz59lFd+M775vYa
G7wnEYZ76c504vZvJ8QXkr9158Z7bqsIjLVMUT8UvumUesIT8IR1d21nD26NX7KdX2h8SSztT2r8
TDvvQbP1P1bta+p1X1R86op2H9lsT1yM71v9uT/119NnX9xXL2B92i1+D2V1UR4NiYf1L2b2T2f1
ANLMd2oIP2t13mvu2Uf8/OYLZ0/+x24gz773l3F0H9X3Z3F3fvZ/D3QjT6n3x3F/X6x6p3F4B6d4
R/l4N4F6h3QZLhx6J4d/2BAIAbAaMhoMRcMxgORAMhhBoQNRBAhkMxyLhpBIXDYOMIhEhmOBcORk
MozBhkOBvC4+LpRJRcMRxJInIBwNpkMBhIRrEDHA5XLYZORnNojPppKaDLxjSIoLhkNRjGZzDZlT
YuNKkLqoIJ7E4rUIVSZwM4XBY3YZxWhjJDzA7NCIUMRzFYZCo9IBuNhsILldITRZmLrze7kNsEOR
xgBpORsM6xhcPiYlixdjceORvLBxUcmMpeNbJcsyOM3is8MdBfJFLKfgKbiKjcs8NBre8CMxlhBz
ORrtJVINxhNJTt9XZXwb4OBrlZjZaEOND0MqMLJBM9Itj0ht1K5buXtLj2u5BMzUJTMOWNub5Bd5
uTIIJPLd5aXqt5mLLy+hodXtaiggZvalrZJYvTuwA9qRIy5YYNagQ5gaIQqAakAaBohQYBBDIYqE
GCsMCuaSBis0RpIKg2ganK1qjDKcubDI1gaFqppwqIqJ6FAhhcKQXBSKg1RSrUPQ0kKCyIkS9xhG
UVNIrAWtmGYZogKgiRSEEbgaFAfx9IAXiNDi+SuMwGsy60NTOmjcBA6Txyig4apTE8rRbM8YxnIS
5Suns7xqxIqDuBothQJAwjmNA0jcM4QDeOAyjkFKQBqFAwjoNI3jcFgQDkMo5jqNlK0SEFEBAMIU
i6KglSsFqDBg/cryrDMsVjQAUDbTg5jCM4yhAMg010OY6S4BoiwmmyDpOvkSNyEAaJYG7EsM0C90
2BsxwkBsvMTG0xsM6iITozKhhBYzcW0swahkhU5TpDYQRiFAm2FZqYsTOj9NIlSK3wGQYsMicrxR
HIg2FDkCrJOgYwCgjEomwwbRGhd0sqHKyTkFAoWFCsLzPDcOsezbK43haQoxdeOTrJchIbPUgpxl
c/0DHNHhbfQUDyOA6DeM45DCOFDjGEAmDKM4U5olgUDKNwyVNVFhwnFTe44rSUyVAKaqwJoQAa3r
2v+kanByrEUBsujq6/dKsIEG6cwssOz7CEAboMGiP4ihyObjue6pGqaau7uSLb2GFu6jtW9YZDyW
MduO2ZE6iWBoveyKc6vHhxyLu64qCM6tzCBNBsD/8tzF0I2m958X0qEJvwisJ71UG4jvq98+z3V7
sjaIdBdOvM9tAQc13uwdcBoxQjCcvTBbYG3nZF7M0xM4JZqN+P0keATnM6ozsqd0xMntBR1ouJBk
FAqUgHIUR7U9Uzu3oaoVVdXytLAUCJX1OWDH9sCNbUxJBJsDdJyIyDtrYqlVgSwnkrtComNMpF2T
ppJImw/hjGyPYXYyhPgMFnssg2DdOKgFBBQDqGIFJMCDgoDYGloAa4TnAaRC+FIeQUgwBQCBpIY2
ZkIPazZnCiFFKMUcpCHqlFLBuB0CkGhNIbw6DLEZUIYQ3NMVShlVZWlXJUZSy5iqe0aOxZgoIMob
AyhjDoHJS8LIcRThQDMFAdgUkEIs0gNkQlFhyBBHCOQNIYw2ZnAQG4KA0hmDzEBUgIA5q+DcpQOq
m4qKqIclErEWoNriSxJVE0ImLx/XnIKPSzXyqUV3C6FAMYYylZs0UnL5VeRlh2TmQLN1QRBUao+G
ERlLxJiWZWG8Qg3SGilI+KyrIsqwZYrNmMY4yxnjS0BpMMo3SfjnGOOwb48ROigooMMiJFSMkc+y
SB7X5qCCYG8Mc0AUSkhgGUMkOIyRmjRL+Z0bIYTSj5NRRoIAuAoDozeFgYQ2BsDyVxS4LZhAgiuq
1KM45+BhURMAN0a4dNFh4pKWU7JEK3iOu6dAZZ0Q0hsFwFNB4rm0cu/N+yvg0h0oBNwM8iw6SNV3
Pubatg5q4V0rx/CwFMtJoM/uYcWKFxaUFRMFtFYfB0owHelYaJDhwk5LwNM9lJ1Ko5G2U8MKQAop
FI8p5LyGmEQDSaA7MX7hnpXS0McQwWmUfKpUM0/6lQnrGChTMiaX0YhNVirchwh1srdPyQdcqPTg
qDQqsqgmBsSjcHUOgaJrNFgIDaQU/Z9MCq7OBPgNVW0IYUDk+slCpsJRtF4tQM0bSaCmHkNqtoz2
SWbZSNU6oU0er5DWG8OZXw9llIaIUtoiqVlzEqJhEZzToDXECkkxKhzGVkldWk2w5yuDKHQEFNqc
UeqBQggwOQa0ntFaeLsW2EsVtVay11UbZQto7R+3ErajVIt6qG38RFJS4iRcRo4IA6hujrOerAa6
DWGu5UKsqsSezIkFFGjMTrrXYVzdpICdynpGras5KaVXwhvDaHAMN6pBBzuHLsHENwyBvBBY9Tiu
w6B3iJZTFAZQ4h1pbE8MdTg34qDkluzUcnLl5L5LDDKWQmq3wjTpX7+kgVfNQRgFpmQb2gTilWDb
mJLo0ytJqcuAIYW0jdRifYc70XVxBP+gNA7dUUN5UmdlIrr5GV1I9YgDQogNDiA0qIaWtMJJY3FZ
5ByYPAcuU6hANyoMhU0GXPDVs/HA0CigK4IA3JWyiZ5wa4y16FQUtTSOk1rpeMI/9gumWEIqJJEu
VaH5d2cT8ihdmhElQbZfgkrR8boJZChGRQuLAwhrV3TVRFjldrCisaczafoEM5IjE8OVEcVXTkRa
wMQbw2BzBcCBYQVAVJZCq0pRywIpK9VDioNu2H97aSyGkOcOKbtJUrS3ZV/QyKOp+kDdCgtwNKkM
EOP9WmcM6Z4z6GhO457Xkfuh8waAy0DqZQEEAYldh1unO3bO29ZPfZjY+NAdQz2QsdinhQIMPS1B
S1yNz62m5zzqQEANZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PA0vUHJvY1NldCBbL1BERiAv
VGV4dCBdDS9Gb250IDw8DS9GMiA1IDAgUg0vRjYgNyAwIFINL0Y4IDggMCBSDS9GMTAgOSAwIFIN
Pj4NL0V4dEdTdGF0ZSA8PA0vR1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0+Pg0+Pg1lbmRvYmoNMjEg
MCBvYmoNPDwNL0xlbmd0aCAxNTQyOQ0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADEQG
cGkIsCAXkcpjKBnMQEUsA0YjMXDgQDcbjgXDMYxY2xKKRaMRqORY2A0zA04xIQGkQSCKxeMxuOiA
ajgaC6GC0bjUYi4bDQQHIyzCRTOSiCPlcQG4GjCLjkZC4YDYQDYYzsb1Kh0WmU4hFQGi8jQyBFSU
jGfjmrVCoWoXWwQDipxYbDecjQcDcQFSP1CCC0YVQYDCGFQx0+qDIbYc7g0tigqGg0w4yG8xnU2m
U3HSWw4zG85CA6GgyiAxHU5nkQGU8GXMnQ0nbTnc0G8QZcyw43G/PGgw7TSGnN6TcGLYG/imEQFw
ZjIZGM5Hk4HQ3ikulQlU8QC2fjOcVYqEQGijXHAynI6c4ZDPjCA6m4yek5nQw/IQbYw546bA0DcN
IxjCNgQPQN44DY04wqIEA5jCPI0jcM4XBAIbpuqN4zjkMI4DQ1jKhA5gxuVBDXBSKg1AaKgVMgFA
5jqMQ1NgOkKCQN47jK2g5BSGocoqFAWJaz0Bjm3EQDYNI1wUpQ3vmOQ3RCOrrDaN4xDTBIdBAPI3
jq3I3jcE7fuC07rBANbejuEDbzS6zsO1FUWMi1MrjIEDROaGYZhsPEQhBATRzK5AQDiOsBjS509D
LOsyjIOTZtONMaL6yiHDpKTRDTAb8yvAgz0fLUuNa3o6jONCWjc0I5DaMIWzc7cVvK2Uvve9gZUb
R72PdEUL0Y2DKjTL8KRPFKoBaqYYhq8C+vIyIrhSHEfBu8wUsEFwYhREMGSQO0IjPU7SNMEAk1Q0
VV1lKApRyN42SlYA3SC0syMoOU6w0Mr9q6O113bWY3jNNTNPvSI82ewYahQF1XO47yNvDZbysm09
x1Tc13BBdN9XZc8GjqMYxjLRVK3CIMNQCOo2UtDcCYxfeNvvRdw3GMjVDpR0B2HOEW5ZjWLZfIMk
SVcEyDu3DS3w4DhDPL7TuRVIyyDEAw48MsEw22UJRDIcC6leWjjCOeFVgyLes85DONaPD0UczmPz
rprRDLCggtzDeKjHEOUPS/eLRA+w127Ao2a5b94vzB9T4pVmwxZarChgs7Esjje+w2Nw5jbSL+zr
l+0DG4EJUVCmItJDYyUjd1NDNrgWusFvVY/II4Q49IUhmG6gBQFoxa/RUGjy+oyja/Iy8XFukaZk
EoNVwFU6EEHBPrcEuQc/A83uOSHTvIrPoG2fADvw8yuYNwyjvZ6c4PIPX6o3aHfYMdWuzV/GMHxz
D8iFGay/AM/OUzYcmPu+eA8JoxnkQIbDgGkMgbDWHnZe4BWZzGiByDYGQO8CmmNfMqhRZxUkfvEW
qtdbJpzMhyfim9sQKCiGdgYn4MKpA0NlDKHRHDZ3ZNqdqDUuLuXdhzd6auAZDnOOFfe/pADd0dBz
XcyJfCCzTlEQQ1KE780WuAXiG10SlClQKgWadDSXD8IgdkhEMzJ4smnhu7QGcOgcw8d4nWIB/Q2k
OPqpxLzmA3H7aeahKTxX8mmNZE4EDqg2JIawHAohrHxBkDsfdj5DkIv9Pif0OQZgyunawf1zxvQ2
IZDSbtrKIUoIDQXHhbzVm4nNBQEFsCKGcgoPu2gMIbUStQSgE40S8UnoVUMqlAAYUgoijBJSSykZ
eJIl8pluijw5AnIckhj7loSSxOQzhWAKAxJcVKZ5WbhT6lEhnINO4JAcgwmCfiAqpwxrsPm+4zp6
YrLhU4gGYwZD9nMkivGaz9DCOPL6/gIgZXZHqM2Z1Oy/wmm+TuFYFIMTCu4DKZSdZuz2A1f7LRKR
6QQhcBSwpYqx1kkWPGA1xphX7otlY85ia5W9qzZ2vxKEiEMlEDnD4OaQUqIMc5TmNDs0dgzLzG6H
0cHfxyiEUSjx3TvsOpHNiS7WIoOCbaaiBqCQxxGf4Zs+4c0KBFDxLNEskA3TrDqfNraEGsPNi+x9
tcQj+Gmn2i1F7alVhySUZ6C5pU7B1NGEGhtD2DhUCbC5elN0zMggS1hLho3PGwDWV1TzwHsJ2DcC
2QxtVIhoeKZEKIdUApKXeg0zjpmsBlBaqtK577Fx8iU+SmqIaamYUyf2wznAxByRva1bzhYOsGBQ
aKCtmwULOBktEFEGAQLOWhB8MVqgxH2kifNAZ6X+n1Ic29Bj5GlGyb21ivKpoXq9um9hhL8mcmRC
quQ9R8Y9QMBSVtH68Fwo6kUZSTJwEhh0Zq1IOhDjVHviLbiI9F4ps5pLP4xCLX/sfPYDDBsRHeUH
KUwIODJ7urejJSxc+DcGpENxBMNZoE7n3eLgek5kT9n2DGko0ckQzhhQi4BqUj1Km4Ok6dASBMMq
qpbKM/Dy2sKRj8oyWYYQzryNOglTxslzU9PVPR2RnauEPq/LRBL2V/vvVbK6a9WG723XuGsFqEYh
TZPinW6OMIWzIbizij61qQsPMiEQNOS1NX7ctfxi0PoSsDTU181ByTlpqzqGiFq3IlBiQScaBLd9
AU8lEnXSBosXoAwKsWpYNDxHkBQHrHtbo5HVPelQ4WNzZY50jaJyzpzhIcQQgHT9qj0JQfJDQ0WI
WOOetg0KuJkVxyU1qhQIaJGBSgePn9RZuH1vOOAvQrqhg6X1Xw4XWaA9oziNHkC3dcLzQp1+enWs
LkoKCjJPB7RsK+MDYK7hIJtkAqmnzXxKBwDLQzPSUTSR9zWIjlpsU0FuA23CwrfrGQcNXoCXO9lK
DhdvpPnCndWaEdgKa4k5WGdXKkrGzgsqptCUnJQOkdQ6yGkOIe3En5z+R1wL4DEaymS3LSLedNnZ
AmfN07XnSiBsllL3Su0ww3TTD8DuQRaGVQhs7pmdSCamAxDpGn1hbXPcygGirhjTT8GyP3dRvgFH
J4efzhHATq82aLKZP8YvMEUsQLaQguIwRcu5OqLA1BsRQGHbyeAyI0DnvhXQGk+duDMHJfC8FABo
Xwj4ZkWBRMUYUoRgwcg0IF5AxgICoBrIKQchIUz3BnIcRAlhLgG+CO/UAEB0Osg4ImUr0YOSSA1K
EDIGLty6A5ef60jQNQYe29k7fupAvBEaBsj30/swXeABB8EioMD3e9BcDQHJAjE/KBwTj4rt/D/A
9cXEvX1/ng2It8rvhVvnF6+l61H3zPefG+h7bwSPia/OBr8T9/zwY/r98UFP36O3d3+8K2/c74Li
8E/+9gBABooeLU9i+MWS/3AQMG9kIs+c+DAOoePaos+cPa9tAeWsLu+8BhAMMTA4LUL49k6y+iL4
/q9cIFBM7cKw+TAEJ7BKBi6yJuKs+mByh0+rAkIm+O7q9u8Eh0BuBhAWIoBoIZCC+OjW+KIoqA+0
h0PAIY9lCa70/3CSOg/XCoPdCSoc+bB6PAotCS8dCY+O9XBwJy+tCm7c9lBhDRCXDUBzAI8EJy9d
BmJzBoKFBwh0LVBYBiJyjXCRByWsLo+KLzBfCvEK+e+jCtEFAjETAbCuBlAxD8+O+tEjES+HDy9a
h097ESIzC3EFD8/JEpDjBTEEMLBnD3BpCsuWMNBKOhBc9sJOPAI1B29PFg8i/C+q7c/nFu7tANFo
KAI5F8Ko+rFY9y/0OgIoLU+TF2J9CkPaWtD9GaI08O+bGi/PGCBoT1GI93DDF2I5BZGjBAKtGC92
95FwIs+mL2IrG3FuLqL3Ga989MOgKm8jG++xFfGXBC9HHYdtHEIo71CRH8Bo9jGi8lHLH8WhGI/n
HVH6+xDfGjCG/dHZF7GUIq7pHk7cTzFvE0PAdvDjGhDvF7Fm+iI3HoMYIq9WJODQ9aKnFRFu8DAI
I/DFIXCw7c6DJKdu9nIMdu7uJM9a8C93FvBPBBBg8CBu/JJSJ7HK8GI2J7KJGEIZBxKRGvBq/88F
KFIM6y8FEDJ2BtKU6y71I9KcKrK2J1CJBhBPB+9RA7Ka9SMbKjBo9tBw6zKTGg6yI6+06yKDHFLF
CW8FKvL9JPGyLYJ1Ks+PDZCTBzMGLvFAh1LBAxKWBxBvE2YbKjADD2+ZMxFNDdLO75Lo9bENKVJ9
Dk8jGlMlJ9FW8EIoIzLwLjCrBxCM+7LbEtDiKpHRL4IzBgKnCHLC+fILEZJe/8OhJlFkAbJbMCJp
Ak9lJwPdJpEEMbMkKnB/JLB1GnIvJhMXOxGiTzECjYBlIMIoBsMNEYjZIiJDEJCTMpGvDvMy/7KU
fRNjMsR7MkJyJ7Me+OBpPtNhFMh0/nKUh1BBMLP/LiOhD2K3BhMgBlFfE5EXCSLxHRChHjD0LiKz
FvP/GnOU7vINP+WVOVAvQw+eJvEZK4PbRFCPLVRHOZE4BxFBL48lRFCJNC/E9nHeWtG5JK/hLSOg
J+WhKaR8BkKrFuJ/InBhSDDZR6+OBuPdBxSDRTSVIK+0/g9VSII3EC/SWVSVSFRo+2KlHEJ/BJBh
Fqn9SUBhSq+U/BStMK9yBrFfTDEDGrTAWs9dTHMPOY9LLI9oBvTmKwKFKzCVKVSLHjUBRPSUBwBr
Km9bBPElStBRRUMbTnGNOUKTSULxSaJQRZAQJJLBGII4IYI/ARPvTdFuMG+gPcJPVFSXIMMGqBA3
CI+fKMOhAgL5VVElHFAhVJBFVhHPVK7kPdAQIo8HGvVaWRAqJDSZV9ILUVWC7dVwKAJ9WO/7VYIr
TVWbURUFNxE1WbBXSs70IFVVQHStAJXCBtHQJ/RTV2JzTPTw+/ArXW8jSsJ8KFXDJtOaJvW3V5Hj
Us9XXDFXUPA9WvKTRvCIotKoIqLlJvXNOPUBBlFuR8L3FM99UbJu9dFAdvAwBmfrRtYPG2+bY0Kp
NM8DSqPafrHdUAqBClZBM3YPY1YyfrUbUA/iuKLjURRULZOYR9EXLrWdGhYhRtOU91GvYhKhUo9j
ZW+tZ5PC9PZA9lL2J09XZKI26DRBRJakL1IdUpR5ZA7rAC6y8k95ZAIzDDMNPJY+8pS69TTKI5GK
otVTAtGYPbNa+g9vA5RjbkLjLTbeYNXiPbXW+7A5LvaZDvDZA4+jaPcJMrAQJ+KrAkqBRxVfTDBz
cHGKIZcWJ1b6TyLjF7V3XRatc0Lwotcu01Y+IpUSItcvHDaZCbZYAbcuI7BLc0LVdEcfNRdWMJct
dq93djHtB/c6KpQSPbHtI5cu7vY/HhWBd1N3eFJVUxeLZIOeKBRdArTDUTaYKnAbcuuLBZeijW/P
AQdvQZHEJzXNKBfA/tfHDLVfYxHcOgLzX67uKBTVfdKfNDfPSZIND/VJfvMpI7anfWIrUNPCI3Ab
V29pQNgGT1VrfjDrf88lXBTPTpHQLzQpddgjP3P5RJU3flfzMTdzFrCrfoI5edgiKlFfDvZtg3Bz
g7CIKthVTPGIWhYNgtFrgRNbezgiLxOZPHGZg27pMlCNA9V3U5KVCbQuJOJTARa/QuPa9zXjVDEo
7pFeI0WQL5VSocLjU7QPanVRddixNdRFctixT9REKzXBiw6Di2odIc8lVbOJEkWtM3jbEHHFD2+H
APixTPjrcxhJZ1ZnP+n9ARj9GvCE/vjwfrjvi3HvAdiwI7NzRxjFAhN/PDjPVpOZLFT5kZAhYTJT
GHjnY1MQT1dFiwuLku+e9NBFlJcnLa7pXplJaXLbT5dRjzZtNqLlXVjjYyfRbdgtWFi1ceBvCrWv
I5b8Iq9NWbCHcdDRTVV3PHShcfIXWa+JmKWhXo+Y+PWjmpjZmuJ9Y/DRYHWaPBbDDdhdmu9ndjPv
cUMNNhe5fJYDnXT5ZVPvUbARexNpcfDjXyKnILbDQFLjnq+fSSjXTpnLn3A9AvJPm3exajoGL1Vf
OphDoG7roLJVe5CFm3iXZVicKFJZgtJ9DjaY/hUbigMHJ49O8lCVi68kKm71bDhAKtivn3oY+FWs
Ky+fmDaY9yuLjxoM/IPA/tkZoNe4I1e3p4I2K5ibEHqNElpdeBcVptD9djJBGNpWKpnvJBcALgLZ
e5JBH5geIqLxaZJBhcLgJ7o0KpFXq+R7aPipRPlS8hAJqS7pWBixY1qG7dEXkFelruBxhhV2/Tl/
hBgXGrG5qS7rdoduK3rOPbe/fi93Y/pFl5Jbq/VFdvUS9tpJWdna/tphi8MHhlcpQTjm75Y/FVrJ
cZa3Chlvi9cZWNoQLvrI8hODoRW7jnsVaZK5Gnrfr3txCVA3jHGGPbLtGnjmKDZU9Sdtk08NcdLX
lGMHnjrFeBVrixRdYzJ3WTt275cc8DjxTDp88DaXq+Ofq4J1ODlTXRhgPbfDSHrVfadsKpXNu7DX
djuRhm8lXXM3bwKkIZivPddu/BjEJzqLbw+hlHD/OJc0jXftEoOfdjIDmFEoMZwdjjrJcJaPHtcn
lTvxd5bzrpPTw5MpunNbkTei+qL5lTmdePbzrJCNYTei9dldCpaPGXDZlTd7ZVCNLTqqMbp9dM7f
qqI5x7GFjZptbXNbjlrLSHbxLBunvRxnMTNDsmWQ7lMk+Fifi9fJHER9etv7bzy1mNjxFVcdpLuJ
ymMZe5Vbuxi8h1U3aYMHonzDDLzG+5lnP/bCO/r9zXfle4J/yZzi/BaOLWLk8lMhIzeYuLvtymMb
bDOpPL0JP1Yzd7unzZvzwTZ3z1O9ss8HzjY1yfPx04OhdvURxP0xDfc0LZrJtVp9XXn/ynaFcpFF
kZMhP3cpEl0m7deDcfqL0enLnlvLwW6yMN19adjxLzGTcfTPunRNwmL3yJsJp9TDQTivE5Is70KB
XjiRU1IlVJoQTy8RddSFgJ0iKB2l3BpL0NejUTpU/uLjWTeYWVbA+XwuI3kD3ZxJpZGNlSR8+hcd
3xlcR8dtZUKmqBlHSDpxeZGtkZR30ZeljFR3xUWht/SDItdlUb31MvbxU/jx33mzc1CPjP33fn49
Wj4uL1wnbp3jVPst1p5TGNyXWN5Lf7bwLx3+/tYyJDTr3jQZl1qdkZIDlXpRWTivH2/JpQnLlm7t
lhCPrRlcLq77PDJe+7xtmNCl6W/9qreX6trD6xbv6tBf6nCG9j6tIzqrTc956trTptgVpOLXRj6n
D57ZHbybbz6qLXvZrLrj6XdnkZz77zpZRTq+Kx6r4HnALg+HBL6WJ9wXSLvz6XLBt/R8/j6W9Vun
OH8Hiz1lrBpOjZeniv2D6BLzg1BoJ1eC01V/2LoD7FLFmZi9L56rLFmj9G7fPDL/lc9TrD9pjjWY
+NRn83rBunNL6L1njFvr99CDkZN16rD3pBIRSX7PQFkz+a/nAxP2MXyJBruDILZrlHBrRtPDDpvD
9HGfpPDQ8P+Q+POJ+1XN+5ErBZ+1UT+JI36rD/p3BF23djChuTo7CPD/9noGBwIAMhiIDaDRoMhm
LhuMBwIIQNhcNhuNxAbINCBcOYFDhnEByMYbBxoLhgN4bCBuLhiMhkIJFKonHJSMhyIDHF5GMhxA
5QLhoNpbLxmNZOM5SNhqM5cMpGNBgNpkLhwNqVN5eNBxNYQOJUOZrLxqMBpHK5RLHVxrPBmOZIMZ
rVqYLrXWrXPhrZ7jOopCLZWahLxiMb3TrlP5tF4SORvWsINq/GByMMYMIyM4HB8TDIcNBjJIpcMz
J84LoFFMxGRvY6ZnRmNKVgKfm86NMNcJyNMZnRrRKXI7nshdRMvcd3g90MRrh5fVJbq58ONfcRvQ
+AM+hvakNqhzoFybhMxzRa4MRhSotQpjCBrUo3FjMKsRGRpyRkNRlpI/BIMM/vktyqS7oqi6uMcv
a6rcqDzp0nzwo4tixIHBSuMs1TrKkxSlvGwytqktylpSrzmwsHDYu+qS1rIqQYOGlIbhjCquKm6K
jxfFKvOUGSUvmtS2Lcx8dPnByfBiv8cuDDC+Iig8cRalkhOug8Wo1IQcutD8Oyox0mPYyaSM1KMT
vowinqDIzrqYygYv5LYcJ0zbKBkG0WIUGrBsozjkzBOU7SOsa4M6qjBq4piKQU2cGqYriDyK1jtM
2ss1oOzrV0e4NHT+mDVKw4IcJCgSVSdRMjzKzqGKVUU6obTCxO3Tc6uiyiNJ5VwZ1ghTJUq+dVIv
O6k0qjs8hlODaVyhClsohlZwJNarLcjKd0qG4aq/ZwcwDUSsrPasbqZB6OxxZEg26lQcNNYSVVat
larwyjW1O3CfJNHDE3E+z8QiBo0P2zsqzE9dEv1MCWOatLSIbBSPMsh2CqQ6KIBsGi94KyMiogjq
T3ssSWrgiEPPq+81Yckkc4XkDUqW9dy4xkGIRw9bp5KlTd5Q4Na5iyTh3/TuF35k7bIi+uYza8yc
Qu+ikpI1uaTVgiE2E6L11riSE5tjiSNVpAb5bRapTbhbEsXK8Za+1E/QG9mp2epa2NTo6EhupiXB
myk97JYTP324KS5iG1y7k+7LJ5ictNchIYTc+tSvs5VaqlrFkJXuTfbhSsqtM1ugXelM2121yR78
piIbgs/MJ20T1u0y/MJ+waR5aq3MJpMSRxf0iR5wze3xRwsAU0hKD42/aEqA5rXJVXHeTjTT7610
nmNFwCp8ZkGlKZp3IvO/i5BhMXfuo1z7s5d/hxXv67NFt7A+nvTGITNs8+0+zBsTAPwODNTN9vG/
YPusPik5cu+FmZTCmvfe0UZd5I1plVP2fcmj/06Ffe0i9VpIzFEhMsZVfxpCsGHPefsiBWWMOfRq
QU1yLSxNkJMS17KUjttIO06Rza3z6kJBqUhuTm04tkKxAyE6HWmk+NjD81LaT+FBKMRFU7SCEEDd
gb5JZ9W6FAQE540jcYpHBcu7RkkWX5OSauVosLNXgu8By31hZlC7xIfctCLINohuNJNGIyjcIfPa
PDEszq0jkvZPuVlwRnVyxIj+r5xJGXCPaKnC8/ptYGlSa0zElcGD7g5axA5GrvHuMScAiWEBhWju
fWlFUjpPoqH1gso41xEIbsEPWDBvcq0lNYgshh2DoiNyoIylOWSJIXwWYVL1RBd0OtmDMQYxrJ04
tRipCY2hJEtJxK4issZ55no5Po30mEfZkOuN5NJeJZ5nrWObNo3Blz5syK1NolhUCrTpP4qebSKz
TTwcQRIhSNzaHrMEdufCdWzT7JI4tOJKTrF/nGSefCOTXzjlPQtpU74LLEoKaSFJtJgUKJScicVE
55EpIZQGcaGztEZfrOmehDqSoknRPyG9KmHpOKswVNULyuRnJqedgqOabT5JcwUpzGECA4LOwUpM
S0CFpOVUZbhRGgEhYZUo+qBCgsMZ3VNoFAWCtwYksuqEgqCVOb6a9jLLasLSc6vZNdWAcVKPm/0m
jCyuGLrIfcx1SFOVakrXIuSHq3xAr4eU0y9jXMLRalamcDljH1JSnVQsyCyzRmI3CFlkDCy0OCYY
2iGoRk+s0xE1EYimkbne5t9UuinTiKOzC1EODaWNUdLqOEPrQIol0m2eqOjysLleVQl1oI4NYajE
6ZCLbfH1PWWmhDm6X3IiUSG0CnbhERJjaUjJmrnOUteRljxuyFLyu2R+MTKXF3WI01giEsLVOOjE
x1sN2zHXoLkvKd7dJlFILlFQiy+ofvSTiQlIhSpnPMJBSpZFSprG6tYUBrtjzaQ2TrgYwtOZkEQi
i0gsTRDaXpOQzGrkpL3MELYsLChrmU22WmT5oOJotMSLY/UoZcq2sLxezN2C/yJY0UtBKfmHT64v
TdFYjWLifMKifZnHT1owMfyTdpzBscfv3bxGbCOUWIQSMTYvFJJnLv0jEWxKrjDExnwkQyJDtIUp
xThkF2LXs1X5c7Em/xVF0NEv5EliDBKDJumcnC5t3mGxVIPQNtxcsETIgclaGpKkiW/cAeley1px
Phcox87NIn+6VXsRO6DzG+INNpIWTjmTlPGTVGJ8KUHjGcZXkW37w1rMxJ+d6bqoHBP9t3NYpuUF
7FJnq657msmvUYIVo3S1Eda3iZvdBz8ekVToKaxFnjeoy6DPsxhZGudEEqQ2vAhc4qwJiLY30oJo
ykLpMrlM0a02COQugbqF6yD8m0N0tONLMp3TI3rtg0lDTdYziyrXcqgNFRjJ/SJfkOJDkC4GidrH
Cd/QckvsXOJR8L57YOA2D5tEezRRdLshsJl7NBRzrtBJBk5Fy1jRXM0VeUm7nWR6l5P494+pW4vm
h2SeUla0W/lC/Ez88S/gyClMFblfwYUOcrokXHKwYfbmKHekV2rNStpRP3mb2TjCHApVsGVtNVSt
w5LsGJV6i23sjhubMPg715pyoaSnWNfnQlZe6SmSL/gxuE62X4zpnTdGqcY/wpp1XNOVKq7YzV0R
G0+DCgJ5qcT+eVdm49/r7OXyhX6nEgoVXbMPizJeYQ7rT0D+PBXcsGiDBbhnkJ1bLSpwyU6Z+qmz
gCUfpe7NUMv5v2CDK0njoe8OuPi2PZ0NT7s8fQX3bI+JJG/5GWSfEhoxAtvmpp8K+oYG4h80QJI+
zqD12YXlGkjR9w7M8jfLGpm6Kgl+G406dd8WGzMP4aM7C65INOmUxdvxHnQTF647j5fDjhdArTj4
rzjK/iMY5CdbcZYjkSPbgCbQjrk4+YnI/L04jrEqYgjr0QtzyDaKbKRov6Ygu7nZfjyogyycDDlK
2an6fiXLlKc8F44KuJOLf6tJlL8UFqUanRjqcqPashizNMFr8qG6zzsJQ6pbtieRSZ78I43afxWK
Kg+ZjqojCQiSMqYgpjERmSasFR26QzFKWCwZ9y1ipwjSqBt58qrAj7fI+aGxhUNqTJpAtZgim7Ya
JkK7KJyKmbACyTEbHMOBcho4thiMMouR6rLb0hpBiLnbbLyCG0KSi0Eh8kR7QyHyGCwrN4sLzR4c
SZvsSoiKQyOBrsN6GCtblJYUUQpMICLUSMTClRfiSypZNLrQxyWZATjabRNQ+ghZLzkLlAkZuCbK
gxYg876g+yfyjYrLlyKCcqkBILg5TLoyM40z6jsbrakygLOgqbuwjw3DtIhQzilSkB9TyRJUaAlS
xDlB35sKio1sa8dyj5Sws7Ojx8cqnztxOkfIxUeQ9ilSaZ6UdA6ChQ8YwTpx9zKsXjmcbq46dgy8
bqb6dhzsiSbJRR5D40PabSG7uZ4ZcSbQ1MLQo7hRrTlSbj80ZQh0kygCn6g0WingiKqAmbjx0RGr
2aiw5skw6cEijcXx0Soqja08naHcnAko1Uoj3ccEAxh5aEKohQo0lZh6T0p4rAnklh/Ep5HMnSVj
psp48kpghStK9JXEmIyKwY9Y8MnUaKqq9KLoiZcirS9K1kuBWryEKwk8uArEtq+cq4o8osFTMAk5
Eiz0lEUowQrUwiOEAcUojpU8wg1MeyNUOUwgnca5uhM8yqmTlAyg6Avcyp78UqM8x6Oq8DlIp80k
Ub7cVSLswjULskJw5swglhPM08vLMB/czikw7YxawAn8zsPc3oxwkMUoqcXzcbezr0zqDpHLcb4c
4qKM3pOrpE5Yvc6RXE5RAElZdU4hWKXM3qds2CaE7Zq8isaMlY1kWkZCjcd7j47rsig0oYzssE+D
Is3hUqSLryxq3ZHJxUeyxqAbj4sU2qxpKc/qgbpwo8OVAS3x1hOk+5484hECNFA4kCHydiLE9ySI
n5RRm1A4gU4gsrMlA6WDn1DgiNEcX5TooMkKxcX8kTshAj50X7djpxZcq5O8cNE4tM6xdqWMCZ6s
X5Ikbg8Y6hHLbLjKY4n5ix6qtqIQmqExaT6E2Q3RJw84kw4K5tLA5EAckwn8sJxcZAnKq4ndJ8Zx
kY1VMotM2p901rBU4jWA7dMsN7OiG4+lOdFh38G1Oai7OgnUxLetC6SrH1MpwrlyP5j1Motc4h5h
UNRRDDrCrIh1QpkjryuFOQ2bCNSLDdSY47uZ6NKhI70jpLwNObYbBibFTq77qb8lTEUzpyByglMs
BDsiBzponQ/qfTpKLBNortWDGU2SBzz7x0/lXo3EeySrgFXqujp1JlNI9YpzCi/j901rNbATlCkE
Zs5p+6KsX4mkq9aB7Ag1Gk6yV5mZiMzqb41JFQkMARa9dbHIqzj8KslaBRb8RyfMpAptSBuAmFet
LKMtfosMq7YFLrzxU9eDINfqokvKBS11fqM9hpIaHw6c8bko/BPNiohk6x2jw5iJw0Xx287FcZw0
nUM1dqP5eShjYos9fooFhCGzDteVdM6x6klEX4tdhCPa7UX57kvKPZuNL87VA48NE0XAicAw/sp1
o5DdfshFoRaUnVWLKdo7rVfoobuYvq7FgUiLMEldRtE1IVlVio6woNnrRVdYp82sQyN1ddpDpxf9
aqK7O1caVNOR5gw1KJwy/w6A59Lo2cyi5JG9K5UpJAqZkY01F9lVw5udlpO6UYnTCyuNmcalyJS1
FlrQnlw4oka5dSb9zaFLrzEa09w8RzshB7ld0qVUXBFdzTCw/Lrym9RyVlFhGKKNzdpaucz5h5yl
2IiK49w93Kp9SccDuZAjHIvQzyMskJvd5IjdE63FSag1TV1iHd5ItNgJWMqNP5L1m8+dwzEZ5Fed
SZdR8tfAu9O7EY69eRQF1MQIr7j4ndNN8Iv8A8bIrIkkWl9hZ9OUPFxI/tXhGMgdfpFd/sfVcY/t
0iua3dfCclSYspJdfEPZTp7bKbj4iUz5EA3lfAqkxKxpv1fB0d6Qrr0jj8d9w7ecA94CVkZpiKB1
24iAhFgNu1SdvDk7jdLCJohySxW4saE1JxxNSZl6yorFaDKFJw+woOJC5tJ1aIl1J0z5qJrwq2KC
N1J0DuJ5lKimK7e2IpC82RqN3og1JxKtORqIr9w4kuKIu2J5izY2Jb0lw64OIVFGNpE+MxJRPJco
ttzVaC0mMcoVO5nWNCjatdJ0rOPc1FSaieOMc1NJz5L94NyCokUeOxiFOQprpuKlZMx5QBXA89Zc
yg2dcUvZvUz8Jw01XuUUdYv9XpF9zU+Z9WKhnuTt/OPSQSGlMo5GVtoEwZSbMOWdLOWotIkNNS2N
MpaQ1+ZGY4/p8uYIjVO6ByWNXpFcxJwD4eahDeVVeOMY/sz58Iy+akwbSmcOb1u9LI5WcWaNFGVO
BNzSP5wlMqttORwyNFeTZo7YjSgeImHMOWHjb5AS/kyo9KM674geH5qg5pKsXOUB72fJ37MiHo5+
h4wuJUdwnmhdC2dJ37w4mlkuYpqgrWfSEWJ5pzKufQxeOLABU+fQx2PSSsDGlrnFXqomjDqkN9Xo
x2m0mWNB/pDelBrdYzYKB+L+dLhI1WhYmjEtNTAujzYuZRUscImlkWYqNTrWHgkCgM2Za+Hj4c3p
KujD9Iy86VbWrqUdeRGK2Jaw0iKugYvegoiZfC/lfsVd8iXYilKInMhFb5SzjJiKieHZuiwtK+SA
k4yKvtdsYbrV/Ar1xMYcmF/AiVsJz+bTjusaV+puCgql+q4c2Q8bsdeR1GEZOsCtKSaOPaoIl1KR
uFOQmbaRiJl95uROYFcZ1FbWFG1+02N6ELFdKQrExKXGEpqOJimNsxf90mFm4ygcx8qcN9dYrO4C
JVlsYbhVw6ym1Sb14iSA5WumI83Cx7jeShTuljMB8uH9CY5JuaTrEoxTRmHaCx6Q8+9rku95AAr+
9og+kWxRPO9u0m+oiSH29s4e/8c+9oqesLxgoI8KaGt51xnwg3BbJWqYhRJw3BCcd+f8qPCycO+p
uD7fBaG+w0YbYPDbQPCZiAkPBbve+o3aMvBeMu+tyIl3BemuHbMe+5RSimhZvpzuHgoGwyOpve+W
TI+mw4onFL9PIqNTIOrFlXIxNwq2Hhw+fMyfBQzOliNWiOhZEmt6OrrvCBt6Luw7YfHaq+w4j/K2
nmwKXb0nHekU/HFJ3WhRScrPLbHwj6IXF0M2t43RSOhYyPIpQBYg3B9xJHPA6bKfLfN5E/GchWjE
FHNNt+oiag5WhZF2hRkF83HZcWfQwQy+hax2HaxUN+fVJfGzbjDWw5Wulg2YmOUAvsG2fQu+v3PE
E3U5TsCuIHJxB7bQrBz5M4ry6+uWMZlK1m/raW844OHeGJLW+USHNahiKuw4kvKl/PFMW0xLMFHW
w65Gu16PKKNW7xvQv/MdI1/AtYs/PCAmu0GfKOT0z7F5eW+WXF9KJQ1+fWauuxOvT5kFz5dW2g3B
wDKt/BNXFNW2B47O/iQRbmChOuOLMGJikDCPV4hVCmFGcLF50F4KYN/AzlOW3mdLEZcV4Np/gmI6
ELxWClWl5Jw6H2Cm8eEfT2J5GPhig2YpB85mPbQOKhHtZREGSLEaZWCk+m36vtO5Qal/njQ0wZRR
yPooo3o5TmNBdV5GCiOfkIwveB4/qaDnrRiPm6aEwYvqW3YiSGlixraQ9w+AsJ92qW9oj+g4BosJ
O622tZQhAXuaDmHaV5KYi3vKTe+qS2+4vvMyUXGZth6uHitvRPjOhRz7nHYNenCYj/dNz2fKV8cn
KJHr8Xu2/nnut9aEQXYPxJ1HgHyKs2tZTvT7F9I2tafXYPFvZZkfSveOjC9OLv2HJxjvOveOhUK3
APeP2Qy3BUQxbmgvUw3Hqn2RiHNpqghtxo/HWhpwsf6EQ/RtCIEH6Aone+Tn7IsTxnRNQYin6GDv
GeeH6n75iH7g9gqH8lyfCB5/5/9NoOlplv7TxXUpxf7VkfgIrv9oGAgA0Fw0GI2EA0HIxFw5HEGG
YwgQ0G40g8JFw4GQzEEPgQ2HEaMYNhEKG4yikci4xisKGw5h0QhY0GsrF0TlUPGouGA4G4gkMjmo
4HEbGE5jNDoA5GAyok5GY4mcIGU6htNFw1GQ5n0iHNTGVQq0eihsrk5HA5k87q8QEFkhA2nQ3nsP
HAuG0Sitwk0zuk1GUqt4uGcMol1kszn8uq41m9qG9PvN2G9DvsewGKuWUtQ1GsUxNwtGNuozmWRt
Evuoxr+RG9oog3hdLreBG1zGGwG4xqOKGo5rUP2A2GGXuA1zWwGo2pmfq/K19XGdMwOcl+wGkYyP
JxvW1Wz3l359fjW0Gd824u1VawNytOgxlbGtLmudEFZHIurM9snxqdnij7PQGKtPiGadBkg0AOGp
kCPQ96srqHLWvgGECr+nsHoWGqewZA6tQwtChwY4D6oZDKQAbETSw+GyDQYiSVQSGKVQYjymQSqq
QwYHLIQAGMJPigQYrxHq/hBIDBRlEkIO7HKYIJGESsmmcjhoGcLxKu8ppgwcoLqhDERRLYaQREry
wWmCMxtEsiyOiChwwGDawnAocIREjYISlSyDNMKpog34YwKGbujbFEZLsGaXvuGkDrbQyBBk3KiL
goqx0MqYYo+oiIozRz4hgnTZIe+9BqYtzfJqwaiUXTKKvuzrG0W7CEVZVa1xPWj8QlUar07XMhLT
V6d1dUNgoG5LvLq5TfhhUlE0chC6hqGaNV4h7pRLKtFMEirRsha1cTWglbUSy7U22gie2inSXVta
NkwNZlXrAhE8Xku1ZwihbNPuyatMTPEWVspTLzwsFB1AGEKW6nVvhjhMd3hZq54e9F23XQeKVAwd
1SijeKpag0mz9O1B0E7qyDRMNQLQpi+tUg1Cv4i62OAgdA09ONQpfk6Zv3nSvvMqYcuNI2dQ1lz5
NzGedIbZipw1E74thHyiKnKsBvO+OnoHozYKEtOrs5Ca6r/oS159MMvNvqzoaZaQbWq+Ux6zZVNW
vJGRbUmqJ7bAUQrUHDh7bOKKPiwzwIehSEuXvbHvMkgcbeq6uqIlmq8OwUrctm6hya4tJIfhLIZ+
uGHyu+7axaou+TV1NI6MnLkpnACz8a+KcoQjUAIZw3WTGomEsf2KB4F0T0b13CB7744ZWR5SsblU
CCI15QbSF4NEal1iz7khWg+IG9p84l3AJzAWzxrCeWUYwr0UblNDVAj2P/nO2ZcDwdBoUp9Lameh
4DJi1qmTCXByRN1AkLeqzp3TH1INsPi6ZQBAlqO3e4UKBzxUtOyILBlOzyjbrVSEQNtiTSBFdIdC
NKzviBOSgy5tI5h4XmuhMoiFKnIFkCM4xQiKdWjQ9L5CNDTyUtlygybmHJgkqwZTq6uCh2FBwnfE
hNTjLjdIBiSrBj5RonE1JPFcgiYIIl2PeoM0CzWcmgSSxlAKZ2qPYjYDItj/3nKAaoTxCZ3GPtUJ
K15Xsdj0Rof+9eFJoEIx5Jqx+AxCY/GPMoQUoLWTcKDkUXZiKTTcPOkqcJ1ZwXjSQBoaV/5nIvl6
JVJgwTlVBlmevH48sIncyMf+lWR5OVmueTCcgosTGcSDiNFEgblX/tEhueg8p8GQSPfsVpPYKlDP
8I3HIq642ZQqigDJoZ11PEZV6xQnJym0vRktAiWKIZuRNi3Klw03DfSwSQ7ckyAYvlGSnPFSMtT8
HvKxD2eaSDPIonjJ8p0rZ9k1XbKswQN0WzxLPOQwTyZ4kMiCU6UKRnnFxnSV9DdF0hQpfPIxHNF5
XwZK7PWekjyOmQoKVWYB0Se0hIURCIL/HgH7mk7Zj733YFYVAROKxCiC0bVAb2L9QE5UhenEt/Z6
FJU8SQoB78x6nTYqKYJDR8JpLApysdAdWZd1LM4jOr0KSWTHqRIFihJHMVZZKocqCC5pJpY+ySU9
AFQFZi+pips0joxWK8pqp0q650JogxttipXi1dru/SxB2qLKgQFCkqYNnx1nPTYNvtTk4wIP6jNA
RCzXWIIbGJTJF27wJMnAQxhcIp2IRkQY/ckCTQpQKpk/Shk8NFmAVicKhyWxBdS+22M0Do1DXG/E
xhXlAGpKrNVApCWKRnKHbEuCjIrMsZQoa6rEWEKpQ3JCIb9SrlnSNJA2t13ivJkgV2EVkJRI+nze
hCj1b4IsgRZCSiObSlLi/XdqtsWylYvEpFBdpVtYDs8tK1rFUKO3tKexWxcrvt2X4Wtw1pYzK2L/
P+1dCW5HBXbdQ9DB2tQfkgwotJ1rvlmWoc8mS/1DTfOczYmSLYrvROfPu8ruTdHPRZg4pxz4XGMK
dB0vpssiQafcVnIBdlRGbLxkklpoovIhiuY9uRdSz2kJyXI8x9yi2ey7KpZp+DV5JMmsZRkuM0OJ
zKRPK2Mr+oBxWQNg7FVp3quUx+5lsAGhmmcVhTDNSvr7JUzIh8+blzTnCgci6yKEFCz8VguFlJvK
pT1QC6rzMbwY0oYKr+N5BaON1Q4t9WCcm+UBLGsRZnh0IM49Wi5cp3GW1QXahxQquzfZrJB09Fsu
6QkhBXW5QoEHFrhqnAUZi7ZnouS5QGlTe63IZI/SphLeWgiDazAW2SGbRIvNjakeNmNE2SQvI18G
H0mb5Ck2BX8OWfNaXOiLm7YupqudF88HTGKvk1vrM2BVFzRnpepZxJ6Lz3vKfcr5N+EnY36fipXC
X6X64ZV/imF8wQu4BVS8uWrGUcm1fpZTOOAFFSngZhfAEZX0bLwgp24uSQA4c7nlJqeTUXONhc1N
utZqN5nHLmBF4jGMNGgKaKlCTcfVv0l5GbJsSB4QhCF1yNCvU4IzQobMtCloWro4289VSWU6co0r
DqZf6OUTGIrO2unESerokjnTlpoD0ScLehxTnI5UG+/pxwu7EssPo7QSRjok65CXBqXh3xnRUoVV
abQzSdZfEiFah+OOUiex3y5+M54yh7ikGPp0UCmMRn5chPX2oO38uZOaKfk4+G9K2M6JClp+WQqs
/2udD4eHISZSaQN45+HSqXyuMou+mTkev1VXfFQE8+WvFT2iXnQIPuR/TK06ksumkwpFuiTjcOsh
tP7Rdk5XFPw5X52VZovTKz4anrRP23jcNolwW9KetF/WRj4FMfXPyiPOviFEqkNu5PRi/iLqzKAM
wMjJuENPstCnJN6E6JNCsFlFVDoiBPvKLEvPMkgmcKQjRv3wMszJ1jUptQSMmKLE8OEIKFWqQjcQ
PIlK4DgpjwSFqJ1pdOHFIF2wYKHvgFIKrisGqKDp4kfKFjQIMQSOUKsPFPzqGNGjiuJpbDutPkWD
fqOJ9NHCJuvouKXtNNwvuCnPINHCeQuleqLJFiHKLqjwwPfusshtHClQsNUm4w0iLiWunLLqQoDO
vi9P5NPtaO3pKQrDCPHDoQvtslqQ1myrpqACjQRurlWtslmuppptZITsWjollGxqQiBKFN6DDI+q
CnrvgMtJtKCjrxLChGpJ7P5RNiFulqCkZRTRYp6rntlwIkcKAECjWuHMtRbi7JonENZFBRajlMOO
oiSuvlFuyKbECjhFqtEjdLVJ4qFC+O+vYtsiPjfu+jGNZIDN/xvEmKAN3pfxxwaJLDKO+iCQTCqR
unvukQQnlx4EDNZMtMjNEiJuxF2RumNlNKQlSPXFqGEuzO2jkuEHUtZN8PgD7kBRkl+t8tCqFSFj
5uvlvKNrgw1k8GqyAirrWlInKKulFmSyQqNKLOGQ8xDiGJ4ONwsNKuiwIuVtHCvqFkvOcizFhiQt
AEUAaKelxxDnHgQNEDYFqQsQNKFPpmqOELnkij9lEkMwJm+PLLWQlJuCWu7NKvJvSF8HkyoDruHR
oMhyoDyw1xeols8p8yzOiK6y0lmuvykSsiqN6QeQCi9QMJ4vCu+QnQWiavTrqytqGRJyvxcoWk7S
9nlwdrTSqHly6CYkFyvwDwqPWNNuskhS/pUw6P0kpyoI6usiJMOPqFdvLjVLbvyo4PLiHvvmElhl
qECiCK4Prm7vLpQqIPrx8zXn6OzianEzaRRu2oZTXFjuoHUwlTaHxzdjkxpTXnsTdjyibzUjISPF
mxsEKpRRdCHTUmFwLC/TlirxyTuDlTvG4qulpKDvWrMtCi7zoLnoOx5iPC5jSPEKNstFRT5MNwOF
9zsoKP9QFsRiTz5Rvvpj+j6FqSixHFpkCjbx1jkHnvLkDxpDgzOTXzWkrPzIxPLjhUADgo8UEj50
NlEPTk6N80LFaPewNRNULFIzOQNGXULEKO7E6OkRFqDPWRoNISoDe0RDmxpLqw80PO6iNyvpNPOT
vxsPFOIPLj4zoPFNxUPNT0aCTTQzXpGUaS3vZDmxsNUzIRex8suugSeyfuHLWJjrkCCKHuHN3lWm
ZSfJLPuC6uwlPU2ilPjOjkW0zk403w0FYHkRfl8M2UzkD06tHkB0zjSOHMwEp1DQsSUy20zu4Jol
Xl20+DryGl9kF1HwbNEl0j4VDIoP7Nu1AnQu+q8EjUzzoCSKKkc05w7IKy51TPnruPDjo1C1Y0XG
rw2jO1bUhLJse1dEMx1iprM08Ruj+1VSeqoxpGhmx0+Cn1lCFv/0zotVXPU1OnLzsj+sh0zjc1gi
gkZ0zmDvDnrnbpQvMVECr05H+JWqXD8FWpm0wxYjKEql8CtU2ONzvHnLVCZF8ToKhjXD919jr0XH
pnSSeijRDPqRAV9uTPqN+VykIzsq7mF1VoWlOyCGLVCiOpD2LuzVyjex1x/1ACI1NV/EN1ylGR/C
UnDWPOORssOVyvhRsKdWTRPyklqH+FnjOxPrQu+lEnk1ynJUXQBpd2dCUx6ngWinJUAPbP32KCU1
UIyWMovUhCFHJHq1yjhWoDfS2intmzoLgpw2u2BUhPrlOvbqrWyRYu7GyulyjCFw7O+Oex1j7qJP
DDUvY23Nv27T520kI0MU4QRjB1oPTk8Kv3BEd3CJLRpPrxOkUUSnN23KFTIN3jV23UkjYHCiN022
J3HDQOyDSPxy7IFV5K7pZSoCGFq02kqvF3MQR02udvDSliT02jH3EqXXNPnopu+DkFG1DmG05GWX
K15iPJmAGmVU+PAXNFICmU2WNXNNKjV2AIDKv15iuvskx21XNRew7DOwk15RoRZXsSWXtG0VOjQJ
f15in07rpXyUV1TLWLW15kfVHNK1W15id2Vu9XZ0FS0XsCJC537zDyevFDf371mXsED3vkA1vnTI
115i/1AObC+Xhmi2kmqjSE6PIVykBYALn3ODOvSooXq2zFGEMmXV5nhjOipi6XyPHVrMnYC3llHX
j19pVWuxkSh2DMzT4lXkk2AMeWvrTVFHZI0XQV21vnZYTnpqQYdFpib3aKm2AiHU8Oi194WXfSfM
YDOqP4AKy2Vnzi8XfHBVCnzrdUzkd1yHznE4SxtV9psV5K9VMCnIy4S4E1OoOXZ4V2FJv2bYSiCY
yQE4AYV2X0t48tQYGCdNpjSFMDwXuuJXUnFmpDrzvxuwGTTZJvhTsxRWTT6z4zzVTMtWLWxD6VVx
T0AQRWrjDTZmynBjOllZTl2VOlpZRF7EQ5JyfUI231MRGzoGDVyOexu04ZW5JkFUhU4EfiJCL5YC
/2fsVR1lpVTSl0XFlRR3sCP5plU5JNkZPKDZbC9NxFqHEY5RY5jNmp/4aF+1Rxe16yeyHXez5Hrp
wiEGbz4oTwK55m40ACjJBZ5sJUhHcw81V26W2jytMEjD4mG0AFKS0aEGHzsrq4P6GxzrWDnDOK70
hXMJZaJUXSi4taGjS0DJLEN6ELN5yk42r26UZ2xRdjOvrwUYbphZ5iMToRT5bPrlv2utzVO3GYg6
S6Wt0UXSHQhaSaVOGFxkc6G113BEzaD3SxsFSPIaEY/20jSMOaEPb6qRtaELGXBFMkF6EE6xpEIG
+6kVl0XC9G+2AZ0z2KDFHSeTWCKH2CVXgiDAYAQAlgG67AlAQa7A1D6j8Fhg7iNw8CKAmgQAtgu6
7AyAGin1ekEOuo+tELgibjGIyCNWAGSFqlpjoVTIOGXbNmH2V0Djf6EPhHbkNRbaMV2zTDemaUXI
W1fbWkrTsqaEWjk1oSErEitjB26JtI5SqxHGOJpkECYE8iNi0C4kLnWUDbjivD6jz6ybGHJULj6w
EOPCyErF+oMJsXwCHHBV2ndyQzqCNiMNcbH6xnGg5gGiAg1lbmRzdHJlYW0NZW5kb2JqDTIyIDAg
b2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0IF0NL0ZvbnQgPDwNL0YyIDUgMCBSDT4+DS9FeHRH
U3RhdGUgPDwNL0dTMiAxMyAwIFINL0dTMyAxNCAwIFINPj4NPj4NZW5kb2JqDTIzIDAgb2JqDTw8
DS9UeXBlIC9YT2JqZWN0DS9TdWJ0eXBlIC9JbWFnZQ0vTmFtZSAvSW0yDS9XaWR0aCAxNzgNL0hl
aWdodCAyMTENL0JpdHNQZXJDb21wb25lbnQgOA0vQ29sb3JTcGFjZSAvRGV2aWNlUkdCDS9MZW5n
dGggMTE1OTMNL0ZpbHRlciAvRENURGVjb2RlDT4+DXN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB
/9sAhAAIBgYGBgYIBgYIDAgHCAwOCggICg4QDQ0ODQ0QEQwODQ0ODBEPEhMUExIPGBgaGhgYIyIi
IiMnJycnJycnJycnAQkICAkKCQsJCQsOCw0LDhEODg4OERMNDQ4NDRMYEQ8PDw8RGBYXFBQUFxYa
GhgYGhohISAhIScnJycnJycnJyf/wAARCADTALIDASIAAhEBAxEB/8QBogAAAAcBAQEBAQAAAAAA
AAAABAUDAgYBAAcICQoLAQACAgMBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAIBAwMCBAIGBwME
AgYCcwECAxEEAAUhEjFBUQYTYSJxgRQykaEHFbFCI8FS0eEzFmLwJHKC8SVDNFOSorJjc8I1RCeT
o7M2F1RkdMPS4ggmgwkKGBmElEVGpLRW01UoGvLj88TU5PRldYWVpbXF1eX1ZnaGlqa2xtbm9jdH
V2d3h5ent8fX5/c4SFhoeIiYqLjI2Oj4KTlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+hEAAgIB
AgMFBQQFBgQIAwNtAQACEQMEIRIxQQVRE2EiBnGBkTKhsfAUwdHhI0IVUmJy8TMkNEOCFpJTJaJj
ssIHc9I14kSDF1STCAkKGBkmNkUaJ2R0VTfyo7PDKCnT4/OElKS0xNTk9GV1hZWltcXV5fVGVmZ2
hpamtsbW5vZHV2d3h5ent8fX5/c4SFhoeIiYqLjI2Oj4OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK
2ur6/90ABAAM/9oADAMBAAIRAxEAPwDnt7YT2RHqA8X6GmBqZ0XzHpCzRC4MRjVhQhhQA77jOfyR
NG7RnYqaHOnMeo5OFGV7HmFLHAZh1wx0+1SaVRIKqOw/DbCBaSaQaW8stQiE+4FcswXMI5MpAHfc
Z0bSNMjBWNY0T1CAJSoNPpP9cNr3ykt5EYqihFUkoOvv7b+OMuEczTATN8nkkUh5KCATXJZpNndT
hYl/YcMR12pQkjbAl15cOn3zwyyLwVtnHcdSAPbJJpFm0bxmPYKQStaVC/zKGHTw449GZr3MssdO
M0XEJypsQSB9NCHHT/JxXUNP9C1NEWFKFSalm6gg9NuniMGWQug6qsRMAHP1FG+9SK9Tt06YKH+k
IqXJKhRvxYipO5r3FKe2Y0skhLpQ7uaQNnml7p1GkNKqrfFRGNAehrU9d++Bbm8+rW3qOypxUDYD
bb337eOTrWtPUwUs2UkjqTXcdPv+dM5BrcaqX/SdyyPE/wANpxoHUH4W5VrQrt065bLMBDi5917f
NRGzS241+a8ZIrVaU2eaXoqr3ovXbvkp8lt+lX4FgssLUZxQ7/s+HWnfOZy3jSsI7YCNKhQen4/1
zpHkDTV0r1LyW5PqzcVKAniRUHoaVOY+HUTyTIieIAby5RHdTOUQAOhZ3qGjWq8GVDIy/aK9Sep3
29u2AGkhVGjh4wstakg1/Cm477ZJHninsA0bUJFW4AEjbr+yO/hkNupfTcx8Qq1PIkbnrSu1N6+H
tl+IkgiV2CwIHRO9NcurPLNzjr8CUJbfbcsf4YtrNhDe2wSJAVO7033Han9mAPL8TTTRrIVaBV5G
PoWNaFaEL4H+uS290y2lCx8WijIG0ZoNj3HxU+7K8kxDIASWQ5PnfzZpMdpMbiAURjxcV6Gn9hyK
1FCCM7x5l8lTXFvKsCmVG2Feo32IAr0pnL9V8qHT3VLg+idy/NgfcEU6bZi6jTHJLxMPCQRuGyE6
FSYkeuPWuwIwTIsQfjFQduP9uIFeLENUHtmsMSD7nIqutuoM2VQ+Htmx37kP/9A8vtQgvYZElhEM
chIVjQjiqodlBJH2qj6M5frcUcOoTRxkMFNAR3Hb8KZ2m+sbURrH6bcG5MrVJYF/tDka985N5n0u
5tLtneB0jIDKzAmo6VqQPDfOmxkGOzgcixwD4hU098kGlTRRMARyBO+4G3t1whIwZbzlSD0odyan
LI7Jlu9Hs9WjMQjCekw2VweVO5odv14fwala+jCqE77+oQeO3WlPp75z7SbxZHVKH1CDQ16nqKU6
ZNdP0uSUNcMDCSKKCu4X/WUr/XI5BHqgA77JjPHZXTgiJXl5VE5UHx+z3419sCXsH6K9NoZFoP8A
dXKhYrvunuRicdrcR3JiWNhUgq/eh3BIUj9RyR2+mRrB+/IkqOh+I1Br77/RlMpjHW9g9O9nGNse
fWLzj64AFVFeTkUIJp2O3emEGpeeJrOrXZESHZAF3Pfq3M+HTJvfW2mcVt7gemBQrxBIFajwZfwz
g/nu7D6w1pGAkdsONBT7R3PSnbplWXPDHiOQQF7CII72UYEkAp5cfmbN65kt42AIoQdx7bEjoPfA
r32i+beMN25tZ0IIc8VLeNK7b998gJOLpBc+l9ZRD6YNOY6VGa8a/IdsgjKJ5xqm8Yh/DdjfZ6Je
+X7GLTzDAgCIA/Tlzbtv8NTv/tYT2WqvZzJaPKRyJXiDTgoIpXpvWuGOj3d/qeiBI42lNuvO4Kir
cI2UB+xIqaff4ZEdTDC7M1VqxqOH68u1OplCWI4ajExvYfYWWLHA45yn6iJVXl3vffLckS2KPNyb
1lDFR9k7dOP39sAa3A5kMzxsFYliarQDvttSm/RcGeRYLG48vWlx6wLyJ8Xpk9RQGlRtuNxTBeq6
MswqjBYi32G35e5XavjuMzY5Imd3z7+Xwcait8sQK9TUgID1bqT347n8MmSGIgMzV47UA2+7Ob2d
ydOnEDbRgkVQHfYEEipGSe1uXktGaElWcV5kEEFvYhh+GV6nCZHiuhyTE9E5u5Y0AVJFFfso1K0/
HxGc18/eW31O3jubcvLMCwenEmlKjbvx6UyQXl845vcFZZIz8AT7NQepqKjC681m4ljJfiQN2jI3
B9yPkemOPEYiud82YqvN4Dc28ltK0UilWHjiospPq4uXnQqQWMSsGkABC1Ydqk5MfMUNoEnnFqGm
lqS2/wANf5Nz0OQYMCxHbwzW6rB4MtjtKyG7HLib5j36U+nNl8U9+niOubMTjPefm3cJ8n//0epl
WdZVnjFUFTyUUp86fPKuNO0zVrNop4lLsp5CgJX5bYZtzlKyCMmNl3I2rX9k4X30TWcct1FWF4hU
oPi5AMPY9d82cZ8RAB4ZXtR68qcQivN866tYfo++mtWIJjZlIG9KGlK4BGxqPvw88yJXUZ5uYYyO
zHia7k7nt3wpggMsgX33PbNvTWCj9Kup7eZZ4yBQ7E7D3OdP0W6hnhQXD832YRjYfDtxWvHfbOeW
enRAD1iKGhC7b79fbJhp0p0uIPAnBdyxICtQD/LpXBMWK6sgOrOj9Xgs2cR+gWCtvTkCoH2vHYZF
ZfM895cS2WmrcXMyj4EtIy3GhNKqOYp4tTEIbjXfNlw9jaEtbL8UxHJAEDDYN9ksR7Z03SNH07Q7
EQ6fALZSB6hFDIxH7Tv1Y5g5ckcA9QE5yOwvl7+rMbnbYBgcV/r8Qig1HRp6zkRI7pQuzbhP2h4m
u2cM812l7b+ZNQtruJ0uvWPKJh8VW+JaDfqDtnrWZZbuGP6unGZG9S3lkAIBHXqGI5AkVzkX5w6f
9Q1ew8xqPT+uJ6MzU3SaH7DA+6mn0Zr9VnM4D0gEEkgc/k5GniJTETLhB2sjZ5XFYC9tI158Y0IZ
U4jkdqMOXUbDxxfiypHolvExnkICCoIPI1rWtMcLwyxF1b94K8vHrWuDvLGk6rqup201jLHHOs3p
wc24nnxY8l2IIFN98w8ETkyCJGwNnyHe7PUHHixcUPqnGrrY948mZ6dFb6Pol/NaXbWkyIkcAQfC
5iLhmanHlUhqb+/XIzoejR6rNeXN5D6jt+6AUBfjbdjRabin44d+YL250/T5NKt3WMBSlxGHrRq8
JB8YB+3E3Eg9Cw77m3kOW30+0/f/AAyGsh6AktSn2ivYDOh4IncxB4dwPsdJZ6HmzbyroVpoekpB
bwcOJLKHZuRZtzy5fR2w2ubiylIhYhHYUUVo3h0NKfdhVf6kLiNobbdSDxozKSRtWg49NuxyGalJ
LDdPPIvORW2Jqh3Ab7NV+18sohgMzxSJj3AdA2AUjNaEFtqfEksgHNalhsVI6bCtfbK/S0DwAI7I
xWgFafDSop3Hh0yNz6hJMeLkyONgFJZaCtBRv6UxJrgmUhuQLUFPhO4FelD0+WZgGwB3oIoMltoT
Oo5L2+HqaVFamnyy9RtoIlUqQXoQw+XsK/y43SWZ0DOKhKqD1NF38B0pTpgi5gakkigkj7G5IIAN
R+1vtkZbFMd2GavatcxsFQDhWncilff/ACRnP9Rtxby+qi8VfqB0B9uudcgshd3DrJQt+xGdwfDt
3oMJ/MHlqKYtAnBXA+FEXt40FTvlWowxzYzHqN4lIJjK/m8t9Rc2H3+Eb3xH2vH9nxzZqvyOf+Z9
obfFHf8AY//S6lo2srdRK00i1U8SQKAuT2odsDeZb2KSyuYY2/elGUSqBX4fiIXkBXwNK5E9OEth
bym5dmik2WhYEmm5pu3h9lscs5cx2vqyAKpZOQoCrAcRyYbkGmb+OkiMniDajYHRwjPo801WGVbs
hwa8iBTv9GHmjaRazIoZiZCPiPUCoJ6jwI8MNdQ0tmccYw/ShBqRyHvTt3xdVa3hZh3PwsanuADu
T91czq226tRkhVto7RWkoFSM1Rm23/Z+H7sGaDpF75hvRFIWTTwQJXXivJfBa7998D2ejzatdCKW
VhEoq1Bu7dkB28euTTT3i0uAW0as8kQC+lEKgU2PPjTfr3ynKTGJEN5Hl5X1ZHJy7mTWGmR6faiy
07haQIfsoKtTxJNPiPyy7y8gtGSBleZ5BUrv0+Q/piVvfQufUmmSElfhR2AJrUFqVBwVLMka+o6/
WIytAUXmK06EDx+WaciQn6wZfYSf63VsBBG232/Yi7S6Eka0haPsVNKj6BnM/wA7o2vNHg9JnItL
gGeELUBSh4y8v2RVuOS2583Q2cojFnJy5cSrUX6VG5wq82ahdXOlXF1b2PqpLC8Dqx5AF2HE8SOo
oOuGGknxiU4cMZggWRzZjMKoGyD3PnEctiCfYjJF5Y8xvojSQlnFu5WQBKGkkbBlO/y+/wCnMmiQ
TlViD8yN6Yax+RpZVHBpBIegKintvWn45kw0cscrAiCyOQzG5JCjq183mPUIp47f0pHrI5TZSrcf
E7fEG798kWnRtbxKLjihcq25NTU0A2Ke3fH2flJNFj5zMzEj424kdjtt4V8cXkW7t41kQNHERUcu
o77DbceGZkQOHbn5MYkgpv6qRQK8cCxv8RFSa1+2Ktt1wmuorm8laVlKoQ2x5UWo/Z+wNun2fpwd
FdtHaM71bgPi5ECtCfdT49sH211aTCN3oo+H4BQFeIruDxrXfxyJJHRsG/VJbPRKo5uFCqacQdjQ
nvuPD+XErnRYklBT4ApApy2bYePT7skN16iS0RQscpDcjSjbGnT/AJpwvlJcsGZgRSpKj4VYbHcC
nbtiJFaCP0uSCJFg48lUU+LqSaAHYHYdOnfBDxxW6M7NzKV2Hbf6fbtkIu9RkST041A4bFVOxUdK
g7GgAFKY2y12ZJP9KmaQLtxY8qA0279KD7sTDqi+5lptXERkEnBJP7yhoRttuOnQYTPf2GnOzx/H
MRRWUioB8S1fbAGp+Y1uYktYHYV+EIoFa/5PXAENpbPIj303Jg1fRU1Uf653qcxdRqsOmjxZpb9I
jmXIw6fNnPDiHvPQfFE/ptP5z9rl/uzp4/L3zYZ/XtO/l70/vD1+7r75s1n+iCH+pfa5n8i5f5x+
T//Tl99G9zGdwhB+JQKniabV69xhZLo8sgWaNqcaIoZa7HpQ9cMdKnaJhLeKzTyk0jRuTAH32AAq
O+SUuioESlSK0G3Xv+OdFLLLHUQLcDhB3tgd0Lu1ZjNxjV15FGpyLE7V2FDU+ApgGysb3Vbh3RXW
OP8AvZF33IrxX/KIOHPnWOD6t6/qqJCSNvlXf8cOdDsEjs7VdNvg+j3FJhHKU5lzT1FVwNt/frlp
z8OIT2Bl3+X6WuUbNJLyltIoraNTAxpsfhYLUgksxU9998M7jVJdLs4mW3huIQwWVyegJpyC1UH/
ADrgnzrqAg0qNDGeEp9IzELIq7dOVa7EZx+W7ntp2jElChKmhqpAP9ccdZ4CUoiO52538UEGJoG9
mfeYtUV3hnW3MEUyrwmidWUgGm6pXANv+YE3lt4xBdpf277vbOTyTp8Kn4uPjkHvLyOYhkUxlftL
Wq1PceGFFy4eTfcjao3w5YRGPwyAR3HfZljHqt75b+atH8xrHLC5s5wAGjrxkB6kD+ZdvDBnJdQs
zBb6grXCvTi4oBQUDAgfTnDNP1Oaxurayu4yTMBw2q6lmou3X6M61oMMTWwul4zwSniWZj8DbECq
mo+nMfwsQh6JEcB5bGj3bsjxCW459WLarpj+XNZeBZfUSQetEwBA4MSGWh/lPvki0bUmUkSEHkaK
SQKH7R7e/jkb8zabcyzcYlLXaNzV+fIcWFfTrXod+p8MI47/AFHT7pUkhWKYGrBmWhptQN08e+X8
PFECRs1z7/NsjOnrd1AJYhJLQcqV3PTqehHevfInqbCJWC0pX4Wb4Rt4VpXYHC2DzqqcELlugkRv
gIK9ak7+PfBFzqOn345mRELCgWta996UHUHvkYQMee48kmV+SSvr3ouI3YRgAKUVa8gN+vw4LtNZ
WRVcSNSpKr0/AcfDCW+hb151tZ+ElwPSSZPhIBYHY/D4dsAaZGsMAVmq/JvXbkTyfl9qpI6imJnL
xODh9JF8X6GQG13v3M5XVZpx6cJam9Aak+H+SK/RieoSTyKAp3A5SkGlR9row7cvDAWkyRxyVBr4
U2P8K/dkttIEkFGAb4dgTWhJ3oNu/tjKh0ZRJLzW89cEl1ZBQCnQbeA/swLaw3N6xit4+Z3qeyiv
eudC1TRI54XdmHw1otAPnt9/bIKbtdGnaCRfUHLmhBYBjypInt3ocwu0NRmxaczwREpWBv8Awg9X
J0mLFkzCGYkAjp1PQKxRdMZ4VXlc9HlahoPBRvTA4lLMTXlXfETdrdM8i13Y1Vt23NR0/pgDUdQW
zCRgAuwqwruB+OcxKGbNMzyEylLqXofFwafFsOGMeg70z9Q/zHr49/HNkV/TV1/k+HTt9+bB+Tn/
ADg0/wAq4v5sn//UM7T6wCqCXgGFHKtRj38V8fHfJF9cu7VS3oiqqakkBTt/Nt1qe2R4kxxwi3/d
rQcnVWPMj7I/Z6UIrX6MB3d3feiqTFiVANCar930HOo4OLnVebgSIHJJNX1CW91Aw3JJWOvqLXap
NeO/8uJHVbzSecFhch7aUVkhJoK9/h7H3GFszUdplPIvJJybud6YEnlkbZlDDcgkb4ZyFe7k1c5I
6TzBAtjJas12vJufpq4khLe6s23zwkOqWjV3aMnsRUfxxrxI/wBpKfTT+GAZ7Ghrz27V3zCzZ9RE
3HhkL5fim6EcZ2Ngo0SmdqRMZPDjucPNE0Z5LhZbpPAqh7b9TkUsL640u4EifEh+2h6MP65NbDUl
uk9W0k5Keq0owPgRl2kzwzfWamP4T9471yxlHl9J6oKeE3HnCEHeOMkqfaFOX/Ehkjh1m70h5Ws6
Nb3H+9EBBYV3KyAb7qd8KZofqOs6ZPcn4bhZoWem3NyxWv8AwYGD3dYqqeqn6dslp4i8wkLJmT+p
Zb8NdAlcXmzULTUPrLUZVckRMKRlW+0AMC6nrhvb17yIcC29P5T3+jDgx/WGLNH6niCBT+OAJNES
Zzxi4gnYqaD+mWmJ7wVFdyQXFxJcytcSsDIxqxAAJ+6mK2128bD1GYwg/EBTl9BODpvL6ivBiKeN
D9AONttD57SOWhOzcNjU+/TKyJiyB9rYKVGnsZIvUZ+SNQr0DDt277YBV4Rew/VSVDkpIvJvioKr
UsAMMm8pQOn+iyzRnwfiwJ+YCU+/EPKumG6vLppWIktCqgVps3JWbqP5c1YxakaiMssj6pXz9O3k
50s+I4RCGMAxFXW/zZTorldyBv49NvDbfavbJNFNLJcRwKDFIP2yNiB1qPgr1PbItJdW1hc7UkRQ
KNWgBAFTT4a718cHnU3oLyVhGEBag6EfLbw8M2khbhg0qeaNUuLG2JLhUY8GYChpU7fF479shOoQ
X1zpxuUiqpq7Ft3Cg8uaggHF9e1uC7urCO4mDWvPnIwrQ07MtO59sS1bUjJEsNvL+53qEPUUoK0p
1Html7T1eSMhgx0Ykeuxt3uw0OCMxLJIkGP00d/7EiWd4WDIaP3GFd7NJNMXkYsx7k4pczyeoVVh
QYH5cvtbknqRtmBAED3s9Rl4/TZ2KltmxbjJ4j7u33Zsnbj0/wD/1ZvHAiW7CJQv7I5CoPQVNRTt
44S3ZQxN6wABUqabV4+/fpiN95nD24S2PpCQFWbdqjx3Wnj3wmuNQnc82lZiNzUkLQkVHw08M6iE
Zcz1PxcCQsMMu7iOO4uLdNgr1QH/ACt8RE4pRt8Q1eP1XuLlWpMr8jT9pdh+GEa3sy7cqjwzCy6v
wshjkG29EdzKOESFg+9kLDnuMTYFe9PbCuLUWA3cg9674IS9Ehp6gP0YjUYp8juV8OQ9y6ckrRlQ
jt4/qwJbX1xp1wJ7Y8T+0h3UjwIwcZFI6nAlzGr/ALQ+nKc8ZbZISox3Fc/m2QI+kjYsttdbj1WI
xShWRqUjcbowOxUjcMOxw2ch2LV5O3xEU27dOvhnMY5JbWUSRtRlNQQfDJ1ouqJqNsQHCSL/AHiH
qKjt4g0zL0mrjmuMgI5Ov9KmE8fBuN4/cnSsFjAU13+L5fj4YIEkRBbmo47gU/z9sJ5WegQGgFR0
3NPb6MeAKACpI2G+/wDntmWSgRtEzO0jn6uKJ0LEdT/Z/rYlETGPiahPWniPu/Xglp+SBaAACgp3
p0/hlSRoV5RrU9idv8+2RtlVJZqurNaQBwWXgKgKKVO1K09z45ErTWL97uX6s8cL3RCshqqtsfCn
f8ck9y87XEsXpmJYwvpyqD8RbqK1HTItr1hb2xWeANylYl6moBNds1usOUxGTHKhC72o3ytuxgD6
hdrL3UdQllkE0q+otYnjoBxoewx8VzrTxC3W4dLdgAxOy07fqwrSMJtcIy8/sN0yyZVZQGLg9AM1
hzZDZ45Ay5ndyIxhtxRsDoCnE9xKiJGArBVEfNgDXt0O34YCHqIhjjNa1+j5Y4m1t4omumaVm3Nv
G1CoHZzQ0J8MVm1jT5VCJYcdqNV+v/AqMpEa5+rzcmeSJN3wUKAu+fuSuK2ubiVo4UMjD7VO3zOD
FtLmFStVRqfNvvphppGpKZo7O0gVFcksKEk0BPv4d8WvBJdXLIgAKihJBoKGmVyyEE2BTLFp8coi
QmSeRAG3utIfq1z/AL87+J6+ObDn9G3P+T08G/pmyPjDvDZ+T/ol/9YqtneRxyJPH3FD05V3Hjil
zNEqkMRR2p7eG4FK9MK4pJArdQOvwgj8dvDFQPUi5Go2PU9TUfLOup11scvQTPPxpQM3wjpT2yPS
qFYkdCdsO5xLNI6JUcia02qK98KbqNIX9MGpX7XzzRa4WeKtgefme5ycO23VQRWdgiirMaD55NV8
uaUsESyLJ64jUyPFJT4iN/tBh1yMaND62pQLTZSXO1fsiuTiNSxoBuR1/wA65d2bpsc4TnkiJb0L
8mOeZEgAa2tIr3y24iMtlMeKbuJmGw8QyimRuRJkYht6bVrtk6v1Yw+gjH4gWf5AVp+OQudCpNVq
K9cj2hgxwIMARfPfZOGZNgm0NUdzh/5cjeNZbjor0VR48TU5H2AJAUUrkw0m3MUEasePGlfmd8r7
Nx3mMzygPtLPKfTXemkZklJZ9lGw/r+GPLmOg/aFN/8AP5Y+McaKgJ8MQmDOw7EnbNwWEUfDMpi5
BasN8FRXEZQc6Cg+E/Pp3yJX+rfo5/QRA8mxC7/ZO/LphY3mK85klAVP7Lfw40zFyazBCRiSbGxo
M/DlLdnd9eQxoVU1bsEHI70327AZFdY9J7S44jkAQCOlGrsfowqOozyK0kUNKCpdmYkHxFOK/hgW
4vri84R8SJ1NAV6EHrUeNcwsuvjKMoxialtvXzbRh4aPFfdQO6hLcvPGBO1WiAVdqbYvFPax29QK
TNsXPb2H0YDnguITznWhY9T443gpi5V+ImgA65rTv8G2M5RJ76rfn/a1OVLkqajEx86YpNbzW/ET
LxLCoU9djTcdsSpgYHn3KiTSRMHjYqw6MpocG2F3ci4DrIeQ3oatUVwBwbFIVmSQNHUMOhGJjtRD
KEiJA77Honv6YuP5h9vn36fy9OmbCrnd/wAvbj9kZshwR8nK8eX9J//XI/QABpsafaONWP8Ad03H
Wrdun+1gsELUH7Xh8vu9svjQU2A2FKjvt0/szsHWWxKVlgWR6UcFuIPjU4W/UvUVrqfYUJC+Pzwd
tNMzMOSciVHY1NcR1Gf4PQXq3YeGanOIyBnP6Yj0x75d7dEkGhzPM+S3y5Hz1EsKVVWoPnt2ByaK
rGlNzSqmn6j9ORPy1Gy3ErKKmlNh943GSoyiKL1HJcIKliO5A7ivyzJ7Pjw6aN9SSxzbzPlSRX1z
Ityyht1ABP8AlHc9cKL6qoXQAq3VTtQnwwVLOHkaZhy5GtMKLy8kmcqxog6KMxtZliImzZJNM8UT
e3Tmss4xJdxK24DVangN8mUaOiF6ih3IyPaBaiRpLk/s0RO+564ffvHQKCWB2/zoMn2fDhwcRH1m
/gNmeQ3Ou5HRu/agoQtf86e2B7h6vx5Gvj2GUodOAJpTudv6ZcsgYCiU2oDXx+7xzKKQx7X4lIS7
UN6gb02Pag3U4SxkyusZIXkaVPTD7WpgiJbKCxlYFk8KDpt88IXQqR8JBO4zRa2hnlXlfvb4A8Nq
0lzJbl7aN/gB4niag02rUdcfZXyW5c+kHd6APUgqN6gU232wOIuQHicZ6ZTfMVsuVg2duXkr3LST
7s/IruB0FPbEbcojcm+0PsjKMm9e46YkSWJP6sZUUcW9oy5f1kEhaprViepJwLlrX9o7Ht44NtLH
1h689UgG1e7U7Lg5BkBLJKgNz+LUbTTry+J+rxllX7TnZR8zgm90rULCnKrrSvJKmlfHDqHVHt7Y
21uBHGCPTA34gA12PUtXc4Eu5rmZQ7SsxXfcnbx75UZZOLoI93e5n5XEMR3Mp94NAfrSL1H/AJ+1
e/XNg7/Rf5O3L/ZeGbJcfkWj8v8A7ZH5v//QKkUhARUk0G561pT9QxC8maK3YnaikGnQ1BC16e2L
R3AZN6daVp8qYUazc8oxGvc/F2qB0zrshqEj5OrjZIBSdiyAhBVvHCySQIxJ+KQ7V8Plg9plRSF3
f9WFLKwkPPduv0nNJq5/SI7/AHD9rlYhztk+gsIIC5ALSGpr18PfB2q3BFv6St1AAIPj869MB2UR
EMUZ7AV332FcA6/eMjxRI29OTH8AKZsck44NMCekQPiWoDjnt1KWT3PA0r36YAkYM5I6HGu5Y1O+
KQWlxc19CMuAQGYdAT0qegzQTnPLKgCd9hzcwREQyTSAsWnI255cmYfTTNDdOyLwUoFNHYMak+IH
3Y60ikhslhf7SA1A3HT2xKyjIAbYjfbbsPen68z9XknixYYwJieHejXIBGKIkZE0ftVDNcbm1L8m
3B5cunbc074Fe+1AVVnoG6D2+gjBbNFChKsVO4DNTwGxpvt88LppHkJEZ+ACtKmlT1zA/NZt6yS+
bkeFHYkBSuZi3psqn1gd3LAinf4eP8cbM5dQ0gCt4jao+WJ0KtuanHTEzUqxr4dsolKUpXI2e8to
AETXy6IfmRv92NZgep69sX+pTcDIN6b070GBQanj+GIlewPJhKMo1Yq+VrH3O2OgVGmVZDxQ9Tjm
Su/hjODlvhBPfbCwqiDV78k9sdMtJ5TLKWeKE7rUCpoWA8aGmDdSmjEqRBFVYxRQu1FNTxp7VyPr
czQMlzASki1UmnY7U3wRLqMl63qSgeoBvxFARWvj75EQuQMiapy8eeMAYxiASbuuncruQCD+zXLd
llShHTtiPIld61pUZak0rhzch5cm2EgbHMHcqPpe3fNivE/h/n2zZXxMOAdxf//RiXrUWgNDX6f8
98K76Vmc12H4YIeReo2PbCu7nXda/Fua502syCOPutwMcd1OgqWxOKlzdKg6VqT7DAjXLMpHjgzR
l5Su3gAB9P8AtZqcUxlzYsYG3FZ+G7eYmMTLyZPb/YoB9ORjzC5fUpQduAVQPbiD/HJBHcEEKenf
6MFfo6zu7uCcwI0ruKlgWDAKaAqaj8M2PaOKWTB6SAIHiN+TVhPDPcc9g8/ocWt7me1fnC5XoSOx
p/MO+db/AMIaL9ViE1vDBcNxq5NQQ1BUrWoy5Py90hYI7lbQzLKFoyMwSrVYnluKAfLOe4+E8QNE
dQ5wgTsQ8+t9Yt5AwmBiYqfiHxDkQfp74M08D0xxD8hWjI3HqKAVp/MfHJHq/lzR9Nt1dNPi5nYE
XDNyI78Fc+PzwktWkaRE9Pp/IlSa+Jo1evfJ59VLNGPGQTHy72zHi4Sa6rL2NHRS6UUmvqkkkgqO
oah+W304WfV3oHIArXoKV36f7WH1zAzh5aE8VJ5V5EGgPxkAfze+FHDjsx5FqgkkfwOUCV22cBFJ
dJyRiGXvvXE1l4EMFDf5LdD9xGL3CGQlqgnwX36eGBHRl2NaewxrvSSeitFck9uTUIp29sDCJg3P
scdEPiA3HgKVwS4PHvTw7ZIAbljRkBfRDKo5UbbxwZDKtFjX4a1G3XAgXkffwwZb2UsjhiCqihqc
ExExuRptwDJxVCNk93coyRqCykADvv28cStbOWYlozSlaMdgaYdMbRRTgGfsD3PvgC/ctGaHj/kg
dsiMhkAADHzP6m3Lp4Y/VKQlX8Mf1qUbGQsisDwND270rg5LVmTmTRRQknCGKRo3Dr1GHUN/E0Be
QgcafBWpw5eIgcLRgyxBPFsOip6cP8/t0PXx+WbEf04v++u9Ovbx+ebKeDJ/NPzDkePi/nj5F//S
gky9SOvhkauZKyEDqMkh3NDkfu7eQSkhD1NaA5u+1QTCBA6m3FwczaDw30hkSNzyHMnp3oB/bg3S
fIfmnW7aO80ywaeCUkLIGQCqmh5cmFPpwzf8qfPdv8baaVK7iksRP0UfNZp8pwZRkMbrpyb5xEo8
NoISAt7Yb6PIWvIljalST1A/ZP8ANt9OB4/JXnZKLNpbsux58ox19+VMOvL/AJU8wW+opc3VmUt0
5q0nNWAPE0B9Nid/EZs8utx5NPk4TRMTsebVHERIHuLNoFvLi4tFRoiDUcpENAxpQbsKt/qn+mGG
pIbS1lF9KJJuH7s8qBQAab7cR8XXAselq4aeCOhjIYTLuzVPwoWanQMRsfbCy8i9d3dgJZ+G8s9G
YgblhyBIFNqFc5yRHJ2MYnmxzWbmGW0treE0C86gVNeTE0q3+fywAlgGuFkCqa/aBNCCDsB8THp9
/TDG5sgZUYrx/aCksSKduXI0+X4YCvkeNK8QGALSSAmhPajAciTQnfJcQHJsjC9zyWXsdv6ZBIZj
v8KKKUNNvs0G/wDn1wokCcqEEiteagDu24+E4NDXE8e3FgwoVUswO/fltgO6t3BFUr3pSu47b5Hj
3pt8ImPEOQQ0cSFlMnxJXiaEgHt2Ar1yrqOoIEaxheXHx28K0xa2qjRgpRXO4jJJ+ilMFzwcAwAI
5CpHEgAjY1L8eXTvXEnYrAC65saEbFuX3d67YlPyUdOvt44YH4Kruu57U/pgKXevIVOSBIpZwHDs
Va3SCGESk8pP2hQEAnpg13cwuetKVA8DhJEzBiiqWDdadiO+CI5HZSor7jwIyM49bbcGoAjwCNWK
27+/zaYgk1zel6qnkfhHUnFFgmapC0I8f4VxSKrLwNKBvi+eS4qGzWIcR9QNG625oQacCCeX9mAJ
I2jJB6eOSRlVU9vHCK9KGT4Sfce+HFMytq1eCGMR4aBQtM2XTNlrhP8A/9OC0J2r8/llhAo3xNHx
5batO2dZYcCi9t/LS8hi0GCyIkVOLOW4kDk8jdG79snZKl19QMwG6koRQfOn4ZzzyLZE+W7S4HIF
0PF0J57M5KClCB/nUZNZIbeFoixei8njlZ+RDDagWoFfi65oNQB4kiOpLlwHpXXYiEPqRTUDmppW
tD0XpWu4yP6lBHHJ63piQK5CFiStAOL1AXwDbZJIrmEW8kvJ40Wu70qxpXq3y8cKtYurEWCsLlZF
LcPtA7/y1StKEZiZDQoBvxizukF7q5s4COPqtPGpDKREQen2HWor2+HCC+uWimgLKXdxyZ2YyDps
GUrQfa8e+HJtBPbmtyJIYQaKC7vtxJ4iMe4wiuJ0W6IdpGiPQOtQgUcVHxE7jxzDJsnbvcyENtih
Jxzij+rnkyVJagoN6ju/xfQMKb9HSQKQOVFXiWUioAFd606Vq2D7tIIJ/TWo4r6RJGwO5rsSpCje
g8fuLrx0Vh6VWWPc8QNjT/IPy7482yIA5oc1ihjYUFNqBlJUVA9/DAlyQvMMlGpsPir1rXw6eOLx
SvEDxYj4uXxECnQU2Yt/L37YvcyxCNndCjEcgEYLt8+bNyOx2+/DwUbSckiDHokbsYnqeKlq8gGW
rbj4VKjb3wNcXAI4sgCipAqd/oY/xxSVUHLieNSeoAHj4t+vAk6kUr1Na1+f4/fhukCO10pvOAKH
tv8A59MCqkt2/CIVJ+4fPE5a+rQgha7jDKG6t4T6UK8QRXlvufpyZEquMbP2LAxySrJPhiDR/nH3
LVsUtgGkkBI+0Kdx/n4YnPeQwii7ClaYDuriRizKu+FzFjUnHwjYOTf7AxyauMLhggIjvO5TBtSI
2B26igwK9yS5dCVLdhgbL3pllDoA4cs2SX1SJRP16448fU6eO5wOSWJJNSepOVljEAMDKUuZJ95b
rmzZsKH/1OeDtT8P7cUFaftdPbOfZs6b5uL8n2V+WH/KHab1+w32uv8AeP8Ah4YY6t6f1i3rx4cp
Of2+Van+X4+NevHt7Z4kzZoz/fT5/wAX3ff3N/8AC+2o+H1VeH1Hj25cuHT/AC/i5fPCfWuHrTcP
QrxNfS5ep9pevPanyzx7mymfXny6t+PmP0PskcvRvPs04bVp6n2I/td6+Nchicf01NX6vy9RuFa+
r1H2qfDw/l5d6e2eac2a4fTL3Dl+Pm5sX0Jdep9Zm51rVa19P1KUNfU9P26U3pSm+FOq9fh+z24/
3fQfZ5/F6fj7cc4jmyY+o8vhybB9J/Tz+D1g8qvTlSm/Tl9odK70+X9MWfl6r09f7Ddac+m1a/50
65yHNlg5Dl+O9r6y5/H9D0ZftGtejceXXqPs07/PAs32T0+032unbIHmyuXNtjyZbJ9o/wCqen8c
Tb7f0dsi2bMnDzDjT6+9k0nQ/LtgE9O/XvhPmy3N9Q9zjSTnw6Y3ucKM2UsSm2WMKM2FCcZsJ82F
D//ZDWVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwNL0xlbmd0aCAyMjMwDS9GaWx0ZXIgL0xa
V0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMoGcxARSwDRiMxcOBANxuOBcMxjFjbEopF
oxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRiLhsNBAcjLMJFM5KII+VxAbgaMIuORkLh
gNhANhjOxvUqHRaZTqhYZ0IKgawaNZ6Lq4MhmN43N5sOBqLqyIBaMhgORcN6tRKNMpJNY+ZhVEqm
OItbLcM7haJyMItd7ze77RcJBSoDReRoZAipKbZaoZYRBoa4MRtU7YM4voRmNqsVI/UIIMKpPosV
DGDS2KCMKRkNo2KDqbjIYTaZTcdDCbBAKS6VCVEr2MrqLdsOBhGBAVCJT6oMrR3TuDRQUzKYzqcj
SdDyICeYjV6ToaTsZTmKSoagbetgskAP8qwZOCjaGKCigYqq7qPuwqkFNi3beiChw6DQMqWjcMw3
jkNowvqN43K6Ow3jYOsQRENAwoc6DpKeuyfhiGgZBy7rvt65Q6DKogyBAN71hANj7PwFgQDmN7kx
8M0fSAOAwjhHYUhm2wZhQFsWumKjChQMUVjLHr9P4qa0BkoSoO8BsHBhNbPN2FA6DkMI3DmMIxxQ
EAyjYMrkuWh0VPuEAxDK5UwzTMYbzLGC6RnGs0TVNaGN08yiDgNk6y/QL3zy+g5RCNIxqUMs5DmF
1Cy1NLbTWGE2vMIo8ORSr8BAMKiBAO8LxEMcePaFox1pHs4VHK79gbU4UTrFCHVpDAwxONEODSPV
MDe+45BBC0MDhZ43DLUzC0eGFIzdDgQDIMoxV5Xw5R7Xw5jRWz2jRQq9BwibWTO781QUGrut3VLx
X4KjyhQMk4ju5tlKJQoW3pe1FRlGkbN5Y9nWhaUew/a8LyMOsoQ7Wg1jKOlSui6aoBan4bxk1k0V
TBWWX88Lx4FiYqw1Dg6OLD88jyFKtoqFEi2xPEvSUpVqDSNwzyxF+UUXiOW5k3OBzlHo5jpaGlQz
DePxRQq3UQizSQEEAZhktwahyoQahmjUCNi2d+xfmgUC5swY3moCrbHvWytenQYX5tm3ODBjwVWG
GYcO8QbvI80QwwN8l2xr6qcDxrhBkuXG6jcK4bpar30FbgzPbCsVDpWY6WDOyHDrCo3zxPQx2G/m
TxjRmJTfTo3U/a84znZA0xC/NibBzUAKhsgaBww4abWHC3BzBbZbnf3Hbru+8v/vj/hoHKf+eqyb
+l6jZwfxO5X/meqDZI9bQ4Nfiv5hiqKCyPcag7/1qFmjehhDOGFpLVwQOvQytcFKCgXA0BQt2BUD
A5QJJ+DIFAbYEm2BqCg/MCoMnPgVBQN8FwXQZDNCKDrTC9PfQAo5VKkH1Myc4eU3ocz0nrPaz0mY
OAUAuBAEl1IaT8slTTClGrTmIKNf2+hxTLgasBhlBqEUDA0wmgrFEFAcIrBsioz2B4KIEQcBRCGL
sYjbQMTxFYMMVoNwYBRFyMsXoSxgjJAsFEEYuqzOeyg20FDmJ6OWpgFMeidLHdWnVkMEYhKnfXE5
ibWCBwCREnUMZ+HYAgDG0wtwOAZvghWvmFq4YXueampM9qnzmtbQ4h5FALGFyZk2QKIzuXOuMcc/
840B0PBuPeu1Ii13YhjRU0pDCFkPtMVOb1pLXJVPDRE0lWwYQ8unYystcpyIAJXkSltpIZ5fMaQw
0lHRRGrkOclN5IIZQzyllUt1YixknByPqGMNKTk+w8UK7cvbK2JLgVYCgJLk2NhwU6G2IDkUlqbT
s7x3wY0kO1aa/mJDEzkhykmS2SqggQBmDqGxuxrw2J6DIkWhCcFPSXmyqhy0oFJQahqew9zsk9o5
T8GFQEjqMMZT0isOi3qUKqVY/8hwZw3hvYwQ4MylwWtYBbUeSaRUnMeSkTmCgLUuw0DJMYwsM6Ww
3Z8XoHMOwQBBlvOk+6ImhtJV0qIOc2wQB2o3NhFyxluJxXQkKl85ano7SNNFHQbZK0MOLQ5U64Fx
HmnCGYMspWlJFarOapjqZiOppHQqS87VvwtagzFcJWJagooYG2idFQxFEDC/JjSnQ6hnXe0MNyHz
1nNaYEUzJYgcA2XuRVRJZQGvMMoCB5hcyekWBi2kuhVi7g1jKDM1hfomtoBuawGhqC921KUSgwoQ
jMmbJqZ4lIMSfgwTMgC7xVChGwJ0UIGgNiNAxBywFuJpLdT8lC2eRgKAoKdY8kardL13I/DZVdYk
+DYA2c4d9Y9Hw3h3nMsF4KdpmS+p5YRuQKEVBwSgG6pxRKy2SXilGy1PU2YTnfPGeacnUhmoHRlh
AaQzB5sFNprScj3orSg61ozlMP4SpXgxOmDkQggC4CitCJgyTbp4m9C4aVrBpXMcuG4XAUpFZCGU
OCs6P5HU2nwOk5KATDeBj3F+IFV4TTvQI+zO7GS3pyffI6clZh1yLZBOIaTnNcY1krAB/JjxXVof
VWVjVLYKOU1ySdcEs2XpTYU3uWpuobwRgqZ0vKsOPSXkUOYcETqyXJihZoZFSrEtki8ghWSKkWtt
AsjLZS5mILsYzUpXSJXqOq41Mpi723VMvdgzQRirXcMNq80mpNWJTKoTi3xc3kPVIEbV9T2AaKF1
CFElRLCXANLw9Ihhii33CL4UAoRki9F81g3+Ta/AabII8A0K4Kiml/JGTQixN6pF2J6T8oOsCJkx
3eUkpe7SoFbKmgsrBWiuF+K/tMGJM0y22eSaWB4NDtmlO23pRLZyN8QX4GMj4LwkhtIYEQN4Ddpb
SJWQLau+SjmB3iTgsZPCfbe3wSEwG8Lq8H3+VJ+xVzr8A1hwfXV2ioa+L0aNAJYzxIxbMCA1BU0Z
G5vfw0sxtjUA2UahJuoKAqSB3PAxzQMzjPyBz14GWhk0kUuMVOiK/5Rm9BmD2PJqG2F0BQGZkMKk
ehGCe3YtmkzeupDaFQEpVgTSBRlezuQOAvhGXK0yMu5y7doYkb0PAIVrh1KGb+ISDnnr8LuWryPW
AVAmBWCGQLbW/gxBQCMq5aG0kWtiZnaRAQ1lbmRzdHJlYW0NZW5kb2JqDTI2IDAgb2JqDTw8DS9Q
cm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUMgXQ0vRm9udCA8PA0vRjIgNSAwIFINL0Y2IDcgMCBS
DS9GMTAgOSAwIFINL0YxOCAyNyAwIFINPj4NL1hPYmplY3QgPDwNL0ltMiAyMyAwIFINPj4NL0V4
dEdTdGF0ZSA8PA0vR1MyIDEzIDAgUg0+Pg0+Pg1lbmRvYmoNMjkgMCBvYmoNPDwNL0xlbmd0aCA0
NTAyDS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMoGcxARSwDRiMx
cOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRiLhsNBAcjLMJF
M5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKga4lUxxFhkMxvG5vNhwNRdWRALRkMByL
hvVqJRplJJrHzMKqfAwaNRtU7oNooNIyIBncrTdcjFYtfcHBSoDReRqtAipKazlrJpdHkxqN5+M5
wIMcLhpWBAVI/AoJUCoY8KVDuDRQNRSVDVnCNDNBKbyNqtYRByasMhkNo3DBqNZzGattMLBBaMKo
MBhoN13hgMsRs96WxQaYcdTmdTCbDYeRAYaUYTodDKchAbzMEA6DkMI3DmOA3jkOgQPeMY0BSLoq
CUwoWp+GIaBkHLZiIBruu+8rZt0FA6DQ/EADQMsAQFAgwjGOg0jcM4QDKN0WxaMqHDCogQDGNg3j
mMrguGKjCBRGQ3jqM40QAN8dDeNo2jqNw0jG/ETwGMkUQGOcVjoF0gAbIUNvI8DxAa9QkDeO4yjs
/YUhqvIchQFgQDvEw3RLE8AyzLY0jfOw6DCNcbQdCEvyGOA2RXE43zW/gyjYMsWDlPspBAM0VjSN
g0xqOcvLaG4ZIs5jnMgGiNBoGChJ87zEuyj7cPG9DfC4GYZBjL1R1EoCrMi6Qc1omwY1W6LZo/Dj
wPDD7fTVGUvQmigarvDEJrnC0MCpDTyPMG9YvUNL/xFEk8xVFk+TtEcbvk/tvxMEA4UkOAW0HCMw
WM8CGNyp6qPMizeTLIg5TajQcTiEAyDSM9NPiFtxS1ck+wVSA6jlTQ83lQrfDMMr8YlQThAbT1QN
KqFRvMvIZhm1yMBcGqq2I3dYX6FFZ1rW9dZE5ubOitq4osxy25ZVsww7e7x30t+Y00lqHDnFt0wM
OY5jSMVH0rA76jdZqc5RacKwvDN8vK7L0hQ/E/jHQL+DpJcRjkNs73aFIYrkGeybjuYUYBB8I2Cn
Qa5O0tr6E8LrWTbLU1jEMpDSOEBjohwxYrj0Ju882/65auv2NuTs6K8s3cQMkZDzF0YREMu3R8OQ
7SlE8vI0HIbByGvAQ1esPXxw1t5iLkiBcM4XTkMY6wT01m9f2PZ8vr3AvVTI3DLOQ10wNm3wNNOA
JuiuCDUMO3dNHURjd542C4FMu71CSftUGmUeYFAnv+McjDlH05WXO1vPrdIzfnGNHhtRk45dTFio
PKWs7VMSyF8HqYYntPp8WIPCYmHQ+iOETouXaogMb0AQB5SMxZei2QYpkPU0x6Z9z6BiRO6EMyAg
6uhSu5Bq4IEoBzDGwAnj2g6hwDqvF9CYAUI8Pcl4n5UmvG4WwVRYL7UQBwP2HNPqnS9MhVycoEAM
gbk5VQZAHJ12WnaVebs3rMlaK2Y8rg0rJAcFTBstCLkXmgnkiW4VozumxpaYqTNgacooQAT6nhQC
NoOv9YsC0yRHChQGczAmEgKA2x/gqG5K6llMEObUwVRwaVGJ3DSo2SUA4fmEgYuwMSOAzhhRcC4E
CZ00qMYCC5OCcn8weYlBFiTFIQGEXqDR2buCqAzdu2M9i7V3psMSXNOIKS7GplgiFEYdJlHmV6Ci
GsN4dh1iEpyZYNQUROfpFGULgnBrJPUHd6c0W/TNRGmuaJQTYRBDKGaaBdgbneBi2RrE9J7Nkhep
qaJqkQoCUxP+fb/IcRYnu8WcLtmiNgW04gMLww0IHU0GmQUl3+HyTQ1dK85l0huDegmFSXogBham
nhJbTAwn0gwGI9yLkbEOoMCBRh9EeIvS6x4IpmyxA4MYWQioMihFlAaqcqbsC/k0Is3IvIMSrF2B
syAroDS2EaKqQxWiporGCMIEIzZnSanHIkT+LZzIRlUKEhY7wNChA3BmTluS/DamGdsmRbJPXEBX
me0qW0Ew8g/lWmhL0BSfnKqi18FAZEly0BAGukAd05p1kGHWkkuoE0NBROuC4dLABJXWidS0G2Fh
vXix6EKHZG2hROHMPLTHTpzRPZqXM4nbogPcGWSbVkRJGS1JIhx/rKm+Dyxp+lfAyh4e7TAMkspo
WmstahZIKIVPygBb8MTq7eIlPxcGgKemHBuggj6CUuLnL+fkgQ9kAj/NVlrDeiqUw2WzPVdRAzz0
ZhzB1MSTSK481NmTQuy90aIumRmlI/C5ZZIzDKGdidpUg3PWPI2CgKStzNTklYpqfQWlEh4wbA6f
XzqEp3UUjReyrkzdlUtNxc6n1CLQZcop1i0AwIs359Rb6uGaOIcY2ZyGbRVKsDQ5JFqonenrHGui
YomUONkv09UpQ5MTieuogYZQ34MDCHANDFQcMmmSXaNcyEWwAo4u3LbUYfKEsItR5cCDv1OjoeWL
K3AUXwJagRAIdYAX3Tk9959uGq0HfYytIij1IgpBsCjDVs16k+nIesMc0VSgoPeGKEwdHhqCLtWw
nR65tVCYGsvQQNz1huhuxpqNOICF1fUhV9ubsI5xmlnQKi7AzhvDeld54dyHTDXAgmcyIila5P21
h9Ga2uwHtpQ2+Ycg8hwbVljLUeWBMEPi9S9b31HOngDb8M2jJGaPtVaMFtqk5OMm8Ckys9wWylR8
leBt31OThzqgMEEKiuqHUTR1TSSdtqRUmGNLCBMHMXbJvJOSdEpJJRcjuF4ZQdWDIqakgS0316vZ
fGJWVQjgMerBUvHpZzSVmxeVc6VQibGqI2bFl1PafnejXUOxpvgoJeM7jw0IDY0MjZtFkirf+Kcr
yQdzAK+G8X7DG5E4fFjYrb4tq5r8YWZcc5sEasPITTqhNNyU5ROlUnWL1T7ltQKfMo5hyiogKAg9
V5xj6K2QCLtzQ8dU6/YowZJaHdGiUAcDItii5J9Tsid6tfZ1G6IXOqce6tyDnPWWb+O67yhvxGjo
ZI5hy+oPMizAoCT2wEFYuds4itypUqqTWE6WH3foneejYKwZeTpZP5E+E4x1LxEvOq9X8byXkhpP
IqpVqrryxFfMcxNL5sJ3nvQY/jTz0ttbCrLQsLFb1Wy7o4aw5P3D7WHJFoiy1v2nUWjL8bGEEMkM
J/k5m42r9OhHTI+n+RTRL/GJT/LlNw9n7ZuR//1I5A5E7bbNJCLZBzBwJ3LOjPZBLP6GBJQ+oMa+
hTIOZJK8SW7CbAC6CBbRSTbf5ALgIpoMoOgO5A4Na/A+oOyVBRAMRTCXDCpODEJebCBey6IJjBai
oNpKiGh1JpaiabDXSkLe6FZGSiwMi4KurAUB6mMBpFyg0G7vxOzDAoiKBiSDYOanLB5fwJJPxdjc
ZtTcpRJOZA4Ni5cE0FCk0FcCxQjm4qCsQtoGY5Y0sNoz4GI5KK4u4vQHKuQwqszmZ2xzihxUrOgK
BicE7pK4wNygxuIvIGjOrQCGTaZqLOxTINphMJxpYOpBg+ohxgwOcAR9JvqRY77RyXxzxxBP7UyD
hHZHrQCxRA4OaPgMJjMVxHUMx55xzC6T5GRNZHiJ0KsIrcMDLWpGxKpHK25K6KA/p0y4pKZ8UH5H
xRSWreMSsF5CQxQ8xr49SvRGS2BOZxsBpGQ95HLX56rKxQ5E5NKTCCDYJBrY7VkT59yCyyJJZ0w+
iPBO6CoojhKC5AiJxFg+pgsQY/ZmY4DsERZTifYEBTKDZAhH7ehqxxhqBAxBBLwyQyY5kOLz6dL4
ypwkho5VxwpxBmaMw4ci8iwjYz4Gw7yYAgUjYt0PMI0UcaxmK457scrbw+rvbApKcJ0KxDb+5rca
qXqJI8AHJaxEAILgZhsJ0WZOzfBRhb0Ibe4+hKYogMybA+bO5ApSBFpF6wcdsmLWBMbR6eYvJgZB
oFpN5IiZUsgFAECZRvie6xR4UBK7RBKYbAaiZiYPS3DPpJZF0cCzaYgN6bw+a2ZMUojR5gBvkRZH
5vhugOBuMlJvAFMtBH517Sjbpt5+TKMrR8BHBLY/a9JKUmx77eMTqIEpTDBLxZ4HA1h2i2hMgFAO
4MIhxd0wQ/cq8u6ikvUMaCgODAw+Q+hERSRI5JIMJZs1c1pacr43xqIM68DTAoiVUYLO4/T16CjK
jdA/cpCBxO02ptR+QNhTi8pshHM70rURsqSTRTDMq90Sa8B6gNQ9xFqDZBS1o/QNsXpjyAsoCxEo
58IMgFoO6CY/RO05s55jivkYsBpdx+5BL7LDw/UIk/Ur0oI30aJcsWTDCYdBSS9Ax8BSEEh4Iohg
xBMqdCUK67pccSsW5K685PJFk/I4Y6AoEa0OwrNCo9QIhg5hJ6hdzpClghxGUREOaZqDaGMegPJJ
0EBibgRGSG8t0yzZ8pUcSYZ1ZBA+E4DVc5VHA9YNpp5qKk8BoMQohQCyMbVBU2swZirsEFwEAJ8Z
Ih0G6FJKtMKS5+QOE4JEy2dFMpNDBOSlx4hEw+ijx6ikCkVOhqiS50J+R0LMpKB0J+kUzeBEwNsn
k/Yuc5YFFHRhBP56ku7vknRcqvk2oMkS7QB1Y+yDZBANJWcN0nRjo4cijrQqEi5CwjQiclanwvUj
rjI3CMckKKUNxm9Wqt4oDGjz9XQnsl0X5zsmJscDhSRKLgRmYGQMkgAOUgRNonMgqQtGyvFLca6I
J1khYOZmZlBg1Tja4+lalAy3FcwEB3hc5ExK7DFJyHAGItrRNKU9Ef1H0E4/SxoMoPJ8sqI+tPbP
K11eiiSiiCkkLDA+1dFHhBRg9A5HJh9VJEY+RGQM5E9VoGxR9Swus/h91TdiUp1j1UJh4ohRhHyS
xdlAx0kwMKkEo+1AxjZHKYdRde9fIFFfcIkdlcBwLRqRsdRt83MvMgJWkgdbbSgFIGEtiHhqZShQ
M4JJYN4MRP6DB766pLVjhgpg5GxLg2Zdi6s00GIGDJZwxe6O4MNjigid6YdeTQFO1MlgFmpSBPpK
9dFsKVSzxt9vZphG9nB0MnI+LPpdjcEDFZqXpsdrltqC5G8nE+bMp79dtbFpVbSd8g0tgNNwhGlI
EwJNYNyVVktTqvqXCcI9QogOIOqTqQVNM28ehiNEaCIohBLDFf0HFqlDKT5P9LxNkNyZDDZGy9Jx
q+SbpSU74N88LQM+q1xtxF06qvxNr+QFEadS9G9cN0qCCkAN14bDoNL7dUZSR1cBlVFr9dJ6lm06
BGzhINDhY+pHLU4/ETrNc5Y9VfleVmI+1x1rx3ljxR9glerU1nYoFnraFmJ78KKbDYDfp6sQZKl4
9qjKh79o4NMvRgCt2A06V95x5FwMllyFdHd019dBCS579iN01st49rtjqMkN2AIFMIF/dhdpEMcG
56RF4lpBK45ALbkq5gwM1lGBkBp+RKA/Sg6goMpTUabEYsU1o7yLr44BpUA6QuiaQoAx4rL2T2Zk
whgvrIQtA2Qxg2Ax7HKrw4gz7rD3jrY0hC6wooSoSItXhVbz5kTlbmZbJCzOgIrQ0DtaRHWApOFK
RJaAC3dn7ESnioGKCWDzSscOmLCqKpYtYnQixCeLyqZU4uRVBbeOSWDHAlCrozbxz3oydG9TCK4G
mOcPOOogWJ4oQsw9QKjCgihOBAVEhcqCE7I/mQyieRBCOJ2O52Zyg6rmZUovQ55UAuYt6ZiLZCYu
QmovqoRYR2eTzFIpWULHTm7trnQsZXI6gn6NxWotqEeVjx8PjopEEQVH5L2YKexuSoAx2KeY7E0O
auAmuZr2eaDGBj6pqK9fAuYwObONAvIhmb5YBlY401gqgx76sl8o1yTvpcuduRUlJUORueYjRvw5
pgUPAq5ubwefaqZYIuR2KpehYGGM2gYzegpm+lonwnRDAHBneOgwwFAJz7AMt8D7eikPQjaoGYYq
hX2YzEsk48gx9YqpGZ4uefiEYqYvAhmmbiYj2lebugz5ucGhLz7ISX+cwgjzj116anWRQI4woJQ0
oNWeIqyyBYIEAJoEALYLoqAMjEmZEOtW+UDIQ7xz46GvAk2uueqLugOqmvRlZDGe2wchGwGo2hmw
gHOvew8lGxuxWY+jcoklubGwtYWy4yOv4KYBoKIBogINZW5kc3RyZWFtDWVuZG9iag0zMCAwIG9i
ag08PA0vUHJvY1NldCBbL1BERiAvVGV4dCBdDS9Gb250IDw8DS9GMiA1IDAgUg0vRjYgNyAwIFIN
L0YxOCAyNyAwIFINL0YyMCAzMSAwIFINL0YyMiAzMiAwIFINPj4NL0V4dEdTdGF0ZSA8PA0vR1My
IDEzIDAgUg0+Pg0+Pg1lbmRvYmoNMzQgMCBvYmoNPDwNL0xlbmd0aCA4MjAzDS9GaWx0ZXIgL0xa
V0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMoGcxARSwDRiMxcOBANxuOBcMxjFjbEopF
oxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRiLhsNBAcjLMJFM5KII+VxAbgaMIuORkLh
gNhANhjOxvUqHRaZTqhYZ0IKga4lUxxFhkMxvG5vNhvORhFhaMhgORcN6tRKNMpJNY+ZhVBSoDRe
RoZAipKbwNqtYRBjasNBhIYsNY4LhoOIYVI/UIILRhVBiNaEVDHT6oMhqNxAVDuDRQazKeRAbDKb
jOdDQLhASTMIDCIDGbzacDqdDKchAdzDDjKduWIDEdTSbDoKSoaqeIBbPxiNBkOdeRNUMNZFthst
4YTpxDedTYZOpRDCaxARCKU5abhAN43DKEA5jK4o3DIFiWuy7YGiowbRvQ1rXtiLYUDu+L5hAOj7
wEN7pOYOkLuo642DTAAQDyMowjkhw6DfDQ5BSGKfhkFA8hSLoqCVBrBhQMI2DZDQ0QE4o2jENI3P
dEw3IcN7gxCN4Wto2wZv0KYQu07jDqsxSUqg768vCGbyga0SqBg9DXtTCAZM3CbZCDAckDO3AQSm
pQ6jm94xQEOY0RWMoyN9LLDMQEEuok0aehgGqyTJM00BgxU1tWGqrPWFAkv8OY8jaNoyjoFtCO/R
Qa0Y7zwPE8gqPNSE0M61IUDkNIxyk2oQNyMY5DyOA6SXBLhjnOc6zuNs8wW7kHTLCE0Um2U+QHP6
iPpPkQjK3NcDCMY0QG3IyOmMMD0JZVXTS1DZKIMYyjTD74SNJElQA3wuBQKdrhAIw0jOOqiBAqYu
BTcbB3LZ0KioNA0odPI6x+NjbYS/sDOkNw0ty98kOEOA4RLUUcx3ZQUDHeMmObId+jK3AxjoOUAV
opQwuuluFQJQWBWXM9zNTg0ZK2vIUDeFIYBRd1jYpkTlOaNLeOE28VjPAQ3DrIzlxxHUeAbCsnBA
OAyjfjYywSPL41xpWTKba76WCMo4RW92warj+B2ZSU1awFECV1UE7VuMw3uZFVt27A+qBmnMahbd
N1w/uGr3LS9KQjN8KyLI8k19AEE78FK6pmG8bbHY09IHdk+ui5cf8Zcm51g87WNc9cK65r06t5Po
w0/bu8vfKYUpmHAUQS3k85eNeO6t1WcYKFE5wU4Q3Dy3nmOq9+1d1QePULLjXy9VEwhpMdWdaGnX
woFGDwFTTlDlAOLxaN8XyOM4Qb65m8KJ3bajn6+rMOxPtndTAeE8aZE2KWckplTaBX7q2NsrpXiL
gzhyDCHANCN2eg5eAkJqDUnjNxWedNrSUyHIBUCoFDSLwyPwTykgMocyHMJZsuV1iFQ3L0Dcd9gD
myfAugwC+HRUwYgoKmCAKaL3am/Dc+p9jzj6NKIcDFNDqW5PJbqhUNqJElggTycshyFz5H0KIHE6
y/QagsUijA68HXGurbqChEqJ4RLAY0ywPAaQ2tuYcodNBSosIAZsz84Id2EOBi8hlP50oTnUQEch
i5/gwwxbm8p+zegyHuDCGI56An6LZcDFtGINS8QYf2jstcPCGGQlKVxGajQbylBmY415nyqE+PUr
EKCsw7LaNsqMn4MycFWTMDgGBGEyIVCuCk8ZFXltLXs7oEAS1bhBQOCBxhPzxEcO8aOYUxHwgoCg
HUMSJQxzPVuEUN0DlepLUIZJRxUJ2A0MaRYxxowZlcM8zdSMMwUBPQC5s1heAZyAn9KAjYKHa0Do
ACgLgM5XosOyXWglAUihwQAxYOdCKCtANGDQFAZqMUBZQgWNSX1UwDfCq6XzdU2A5Ua7CgzLGjO5
X40pG5dXvzKhhTYGzPg4ApoYTpWVPi0PLqFQUO1RQao+qKDZkNS0bIyKyZoFALnNgxByTmgL55/A
0p255lYYQyNKnUTlz0allLMNO5AGQNnwPlkfQkNgKaEzUihQVT5vA3n0a0HCXEumZNbgqsJkSQaq
k5qSiWK9Zopz5pUpV8jdkNuXSYgkOYdXAnPkU9IMrCJphjDYG9mkUp8LNiqCiFLfn9T+BsRpz0t1
2V+DLGJt1Fy62rZ8i61ReHPIGoXK9b8SQ0o/sVaNnLdqaO9Lw79BJuA6K+N0f8N0eUCMpOUfR2TX
wQB2YqHc4VomCWlbYHJXwYz5IrRguEOa2rJG+CLdSmCtGGwWlC8C0QKK+WvDGw86CepLolT9CY3j
LA6hnW4rlXYcFRIMZBZJQhbZWkWMhOwGxbSJkMNaVOYZnTP0qTfQoGYMgYzrKAY9R07CelANdhcq
krZY3EdZAWx4KFc15eYcNT8LgwtPP+cy3oNk6hzaAgwupQAcqngCqpMlBk/nvDci+ipxFwldrAgq
qiDKSPefAeZnYMWeueaAmaIKuJz4HeoCDHqdVP3okSHNXTt5woCke9jK8AlV5abuytFQbatkad+k
6rdurTSWz3MrIFWy2wYPbQ9NufJl200XMpvy+l4VxpsW136BrhoVOVEkhzIg3ZNT2gI+yggQBSha
i5Wdz6DvYZBJVDciYnY70kklIL9A21/DXk0O8jqL4KsXaRc9poFQPSWb4IQb2l4G2IidcIZJIJnT
bY1CJinyrfnRZIrsYg0r9OG7wnFQFgAgrCGdpTqNWa/lftJNpp3y43vS09YE08o4GBTozZYbp/TC
mUj8M+kTeBtqpue4izoCqXNi+ZIaGkRB0V5C0/5wdlTpRPXcNFederJR7Fs+iLpKm2UAgNTtd1Zz
jXo353L92bIVSmwCJhwlOKeVByPMzPzmHInCy7lYKeAtWCKYUsUqyyGaNcVAJZ3QlKODUockJzY9
AgCaCALYXSoBkAbPAoBFlVAuBqDIjwDS7EarWCDrPWyTANCmYR7Kh3/zswjiPsU8exGsLzPYj6rp
4bqTdS4KfIeY84VvvQ75OaOb3cY/3tRi4AE/BumJR8kd1QGUx3vmDK2XclfrApvXOcxbXnVlZ7ud
MksQkwzS6DTFhG6WIrfjT8+TG5wTxjF0bfObMmntbMmxTX8JCJoLX3A42zm9mf4KaG0DorPovTEU
p8SljPCjRNJbKdozw1cSlqsUrYilh22WAMQbGjBkDdMf0AXIzfB3WNmweWMQoPkJGZmjNzApLnVu
wbbQHvSL/RTffPKTj35v4NDW5JC+qI4KoFwKZeZepe5fJfZfoGLljZqv71YMRG73q77YIMyEqCRI
LHJXJioh0B6I6TANwNZ5hIr15q6KwOpijhiRKvjZBArJhAAFqzw55YTHqEzVwMLnZHbK7xZ77JJK
zzb27ZgNjIDXDXTXhQjObJCbqcIN4MY/DiLbD05dTcSSyv8KMEx5CxjYKExjEJsJ5Jo4IoJEYOgO
ZBKFa544ZSwFpI5ZCNaKhc5CsIBO5eh2rbhfoiy8KmkMkDyi7gRCxlANhgDeI+g5I64NIPR5j7jc
QNIM0C4oiJJBR08EwjonQHBCQykSxCSk785WKyUMJpiiY3APBaMRq5wM5BIMoPCzyFY6UJLz8JZV
pZgtaNoJ4KROayicBPRpUQ0NKacVRthA55jP0ChZibEOLJRARO8B5wBbkMcNrRz8AoCQEKpDY3w4
BISGDgSGS0rIEFIMjTo4xja+C6p4LJahY1hGQu6gohyaqXo8ZRoqETg0gGr6puxPhkSLaraphpRx
g78d6lkWCkzOxhKqjSqHjhA90dAGqqCIBu7QajiQQ9zQ0hCO42jRyriZbQaDDQsg8jhApfgMsHTx
LLEH4/YEBP8DzcSCQO6TEJ8dAGLWJO43A3Q3ji8kj0Cbrj7HoPCEw9wmwq0aDmcZ7WIO5sprZFam
hgDKr2BgwNBPJYEcI445KLggZvQMw559QFK2ygMcx0q8i4ZWUPZrUIElJdxARJBFwECMTU5X5myA
o9R8sKbOBAYOprgOUrB0Sicqg5g4qL4+DfCnaji4bGDDpdS16cI2xfaFsDx6hIDh6DRdxypkcm5k
BrQhktSI5SxpaigO46ZeiVqMw1oFiUAGgFiP4yoG4FgqU1TIoqBbYN5WiFspY344I4cvcrT3pkJD
DjZXZpiK5ICLMxaFzh0u53JABBEt5SsuI9hIY/xpQ+Ev5lbj0x6iiFwNLN4gYOsxjh0AL3swqlwG
QFjrhMZFJFZ/QEAILMpI84JE84ZAgh04xvBGQqZw6+s5BBM6CQqvS6I2xDY2hf0SxFBFRFg309S7
s3Tyk9o/0984o6ZvE/B5s/aP5ACPM/5AQu0lA+JFhLDzxMEHrLJuwJ8OzkDybmTegGrrRGziSRwN
jfpWbf8Pxq0JUgZuyyqy4hwKQIc0zUoIaMoEAIQ/YKhGQzJGpBIIYIIKdIYrKnapMVIOgMckZZRC
qQ5ASXJWa/sZRW8mg3YNBFrJY4RIAN67hPKqCoEsJ5iz43Q6aESRI2htY4RIbKZrT9cppkLMhF49
xDcJ8qqzB2o2xPhALHreqgo94MxljPTgRCp0xGIGdFKDAFsvJ9RdyRiLg31JcS6qSjRoZJBvKTKD
S+pvCmcFcsg/cM5AhFklAMKRDfpAKE7lJWUFJijVThL/tGD/5IRGItqjhe5XzG5pI3i0UuCA7AJe
6sMRw5Ziw/Mk9NpelFCqSB9YANFYSxyA7J7bzxSDL21aMoxpZ6tCMZjfFXYFEwk5cwzMlaRph6IO
RQTlhg5iBiCwY3E3oNJr85RCLgxu0IBehKo/cByacsyI69J3AMqjwjSjkC5lTly0RCo4b7gHENk6
DbwiiplAy7MpJcI99OhWa7EIEbR44wbTRC6BgEFfo/lZzMYFNFKpNbko9a42reonKpk09RTYTa9d
NgRAtcCaZ2o/w3KuSgtcpCM5hyddFbpbiI7Hqhw4QM5mCGrnQ15GQHAiipNkZ3jgU8Dg9kyv6I62
I6yXMmljQ4L6UPjh5Qjno7qbStjoIzgoQsrqo9CHgqwkYmgiw0ovERYuozInAroBotgqYoIoStYq
alghgwIwYIQwow4mpRD9oGFtxR1xwoQ8SjYoT8AnI0o9Qj4gQ0Lxxc5NgnqA585rZljN7W9o9Eqk
Z7oxzCbJLkRWlkkKKLKGEYpnDF41YraA5YJYdLQ2x0JPdMyIIMq7xCBGbgl3FfJu5aSExaszxbEZ
qP5AhwY5jZpQlFIuyhhR0ecLZnRWRApxQ6ZtjbdlSUUf164ypMbId1h148zhBiBPxQA+hYpFRJkV
5MF9bxsOCtQuLDrRMyK8JXzhyEjjbIL2AFFKpXC/jm6/5tIroNgMMLJHsT5hAOF0hExEBF8ErZ97
g2RoschOcpgBttAKIlQlglzqojQzBf1RwjY1lkoGhGirg7wuwn40woQvgzaejEAmw1rrQwABoK4F
QpovtugpIm5ww7wnon8MYvgiYmOIuH4r47orbDAqwrArQrgvmKQ0atjobIg8gyDooqDo4qDpLwUR
a7gkMMbp7qLqYgog4hIKZMYM4hwiAiSm90IjuJFzYvQio12PT5hNr8Y0xQ7b4xI02HwoWQAhg1I0
qww8JQ7CY1Y8mR2RJQ4GgnIqRLmRAn2RSUonuRgiWTmSArKXp8ZQ4meF1JgzVx+VDsBRorIuTD44
giWVJRoHC5NqeVwnRRrrbrRNwPLr2Jw1oy4qY0zsrEFqgjOVAigHItI27rwuIiuWEaWZ2ZGaUS5Q
+X2GQk7s6egmqekeJRzop1wzQGwxIzeP1wzr2HqrjCynYHMMYk48Yn+eOd9uQoWeYHOeuc+SNwhN
wk4jgttR2RWc6HmgFvzLgt2RWdIHDFmbo1QnDCAnSlI0eazoIyo8jorb+e2VD6OeIpQBujmfuGAv
Nvgk+XAjeZekojNwTuTLjsTxVvmYIGWl+P4G1R+k7r2lhMb7mnOfOnbxWnpUwiuVuiAqAgWMNv2d
I02dFXYrgj5wrQ+ShwrrQhhwovAu+TwvAm4i2rAqiq5Q4uz8a1eWmbxM9t2g+pKUzEjooLc+oudA
Lr4EDqTcWpeJY8RQ77jrTrpwuvAxMdbCer2kooOwF68MYO1vyVonWZaKGw+oFv+xgtSUpGYqwk6q
wnIHAgWmoimyuaGzAiogQrIignuy2WokJwusW0iA2iFxJQtux/9FJ7+pJRynec4oQGduOrDuIiuX
DFoyAsQqws0eRNbDpelA9rqaZrURbARA4OaHJBltGLgtjoIGwHOMGcZrGurqg8OrmGW0YnWVtzbq
w0wq2678Yrmy7uQ9IyNvG9Is964t+ZIvOWegMTIzAtWJz8Ahm+w0e/GS96+nQjtR+ZeZyHkRYj4u
1zGsPA2fe03BW9GRQHONWaA8YxuSnCYivB+8+62sSIGaDD5Glxmmr8eaGs5NGtKq+teTW7Khg8GQ
m8BN2qIzOR2sVyu3HGmQmeIvOuPF2QYoSlgoGVo1Ls+122SbAyG2zaJNokOmGmrSwu7FpCrUwOhf
g/yj0SqgKjT8ZWUyKfuJyjgPA9+5r44FERZFxDcQRgJ7G6QoG6mLm66dpOwkGTNxhS2FooWRAtYo
Q74vAGgt4vhLwipNz72iqHmZ5CCevOaghCQ0qnYufPJw21PPozXQAovQQpOcPOQswteJaA3R3PAm
3SXPiq3Soi3QI8+Vui2GDoPFlt+3NFO2+bSnbD/SOinUnP3SwlGiPQmimiei/RI8gs3RmP4zIrYq
3PXSfUvP/U/S4BvYiPQtpUwy/UZVHXPZvXfaFqYnTC3avSnZlvvQWLu6vOIyAswifOtuzD4mnbvW
/a3U3cPOnA4i2Q2Z/ZPXHeHVGb+idR3TbrwzOnBLndervUXd3b/XQlPTooHT4ueafdvPfd/cHVHh
XgIEFTOz3e/iPhHVPFPVmizsPV5RgoDaLCuvnang3Zfje6eL2627Ft/dHeaPTPjreFe+j+CgAhnV
GnzaHmXh3mr8Hm+FveO4BR24fOQgToogTpO/3mi7gkCaxf1x7IhMdzeXyVuzfqW62oYtCUHqNmXC
a7OUVwmkHCHrWbS1nsCqy1nruYNzLuenoxwvMH2y/GntPuIuOnozPF2SKrsH2xIiaa3Dr7nvvvPq
HsvsGYIMVtKdooHOYgTo/sSUwtXrPsHqtwj75Q/Awzlu2X01nzLPgHI13v4zBSvz4mPtyVvCX0A1
3tvzrrnr3qeaHxXIwzXJG2vkehgqYymdCgBVbDfogsxCoJsxiR4jSpgM5zbQF4ZoVICz4MdqSgoN
bwoIyKDw4lJMCYeGSAI1g08WQ0huhc5V3OKlxegiwIZaVQipK9UqoLYMX6CgJ6CFoLpxnlfcnl3O
erItb5R8O4g7pTALggApFJUNQNF5GHAgGIgKhmBowEEQiQgNYNFoyGIuGIzHI2hQuGAyGwyhhEiw
wkAwGELKhjh8plcMO4NLYoKhoMogIhFKYgJYpjYuGgoMtAGdCFB5FJdKhKgxGGMQlkOFsZG4wGkJ
qsaGQ1ksnlI5kktsEqsUymgoLgoGseMRpOhzEArEEJOBhOQpqo0Fw2FFwPIgt9xLkCplOg8JqYNj
NdGgzEEXvsYscmFsolUxsmYlUsmc1KApGQ5FwyogpGAoORtoA4FwzFB1OhhOhpN5uEAmpdNxmlHA
5HORjIxrtfmpCNhvMet14oNZpNxn3dOrYyjHByQ0Gw1rxUk2g0Wk01F1Or5mw2W02243WH3uj4Vc
7vfFHI5Xn53Q6XurYzGoZsgyQahyGD5rS0LRtK07ytYGLXPQ2batu3LppeGoYBmjytuJAwUCGN42
ruMcJDcgaCqCG4chqGi6pAjEWO8h6GJc8EEtg8iNNVBrXKG9MSQqrYcQKrzJLEHDKrKGEUxmtL7O
XB0FOe6MKpRI7/vjDivogsi1BQJgyjMOjCxM96OK0o7rOAr7LpgliXBQIo8LuNw5vXMkoQGjaFIy
jgZpYkz6tuMj9TIg6ooUhiqMbFUsJFJCarXOIxjYOs6js0S+Ru1AUBAJ4pTG9zE0QhreyyFqjpUG
s/ya5Mnwe/Mpv4lAbho4oWhujQZpDLUmRq0lNJQGMdOZHsIztWQXBqG9lBAvgYwdA02MzNwGhQKY
6jEObajo2T1wogkLBkG9Gw7D8QjDEc7XAGK+WUjsWpFI6v0CN1ByncFDKlRKLUW7lGhtGD6UiPFJ
0qNNLhkvihvJTlPVA3lRMWvgcyWiYbJAG6SV00gYhsjziYviiEioNq0icoqgtgO8qI0rCtJRAgc1
XLc3y/MMyTYjdGTZmNV2sNIyKLcFcYSGDgoyHAbQzNbOM1GgUZOozm5XZCuw1mGjZ8KQ0jONA6TI
lDrT1nms15Lgp6BoSCiKKiX49FiJBdFTIIgiocL4ygQBkkNkhghOS7u0rib1DDXoXwOkshvajo7w
4ar67fCcYGyFpdpKhBshPF7lyi61xZ/NcLP3PI1B3CBlvqE8tz/Tb2q0Crri7tdCjMhrrx+PK91y
QX9yy+cTwna39wO892q6veJwe99RC/VAaNAG8u7aSBjWm5dNwGL+mhQbqPC7g8CGuk+4o4aQGut2
/H6vfhyyHfWT9Qb1xACSDZ6PUT77n5hn+v7te+17jj1aEJfsikFxV0WPVgEVkEEBTSQIe4xyAD9g
cFHQyx+AwMYJvRgsx4hSQjSrLga9ElDkUHNhhFA5uQMjFQgMhAYHCV4TlCVUCCGANCFwzfk86GEM
gcEZaUZCFUMTIIOIyDmGJdSUA0Jig51BGyPQghMkdXJHnLKzBwuOJxGgaPgg6x+KkUAQB5g4a+Dy
Dk0QbgNBCNBpY1QPKxB9i4N2AQjio/lB0c46wUfxABaBpXYQUfTDmGMgCvSCfhDksRQokwUIy+Z6
j7SQPVhsaQGANmjoqgPJiSpIJOQaktDyS0nHlwHYyXV1CGCSN7gE5GQrmVxysk2V5yyv1auElaV6
RaundN8fkSSXbsJQEgedMEr0GncA5RYb8F0WZMuoaSuN6R2iFSLVquNyz2gavUeszKAgDQzAqRkE
oiIIA1ERWSZAO4IHot4eU3x5oIHATulW6Jw7v2lOSc445yEvXJuVei7JzM+nGukdBPp0cWXSuheY
34EDq6FvBgO7By7s6JO2le5F3btn3vAo28OelEnjvocFPWhrznoPSm29xib2KAl9pW9V7zRqSPig
w+V874X4vsfdO1+EGH9v9jvH5+Rr3+R2j7EVZcB4GQqjZUuAcI41xxerBKIUZYLwRI1BuCsZowQo
kPCSmEH6wVSNIkashr5OxErS+YhcN5CKzBvKKZsPogIArNXWIsP25RJhBEyQkT2lxSmPGFpcV4Dx
Zg/E+LpdYv2LirGOrEZ6umjqvVOBNlY30TszHpFkfH/17s9Ui0MH3HysjtIO00hrUyJmq6grNYa+
SQmqqiSkBpLyZlacG3EnzgTEoeA23pwZSy/lQSCo8so6PIdxYq5TkZamvlvc+XT+HYXFlPMaasob
g3amQX2ZRdTSTOtfM0G00ntTUg1bBcVwaVTcpbN8OYDQhNtXyqMhzjzHkkYsZOBLlK+wJmVKYljJ
SJr6IqEILAIAXhHCmiwM5cgihYSS05aoTQyhzDmGEM7agGrtJFOUiDj6Y4AiRZk8UNWSIyM2WhSA
KAkm4BwC0MYaC8ApNcDUFC6A6BlLye4iBVTjAoDEfhVp+A1hzYeU6/VR7+kjRYzJ3j1KFJ+ODita
RnUmAoJ2FNMgVJxLSI4tQmoSyikXVmUlCrbCXkrK8sE/06IWX8IoYyc06DuEknXfTBeDQpmQwiCD
CYDU/MXiyQsjr1yvMlQAa6DRkNEsyK9o2o2iGQgxK8HbQgM0eSc0jpgEAMwaN4cigSvpC4yai1IV
58TnKw6Fn6CDVpHdJsdmahjWRrtaAg01rCZRC9ZuR1hocEGnyvRkDFnacmm0ebF0vovZj/zg5Sdh
pQjm0zhwa15tGLq49qHW1DqOrZHspLPODqnThQtnaKhHsm+uH1k4hIniR6j/ChaimqrhVS48V4HU
RgnPuDsIYSwozTC5gQxhyDKoNr64MwFpDGXgMgIES45NiG0MWPkK8Pyy+MsnHd+EzL+XLURbQQNK
Kzl+cXBkt8iJEY8hS4mLguBcmSJjclloaeqRpeYayFgg6B0HoQIGVrgyCz7oBcuKGCB7z8EGHuHm
q151PoIaegh16CC/lS1S6h26AD8EnQgtpkybnQiD2mE6hb8aVfyF5mgz34yXLOFmmmeLSEUN3CS9
K6WSUkOGPeJ4Yw1hwoqoSEX4Rlv7gGDMHaA4IRYkRviEq4kw51GOWa5q9PrkdKBsEpH7N5EtgCRD
hnFRjwZLrW2upiIEuDNgUQGhxzt1YxhR/J1zcMQl8TeDIrLiAizhXtZmw29wn5v4DQr8URkimVJH
nKEkVuWf4PyQ3X0vsEbtJizXQsxEvAhOnNDLsb0njEO/S+qIbjvgivc1qGYlBi4FARmuB14UR8EA
Uw8htDaGUOgcg0gxgQC1g3g5AQA5gyuEv+CKAyg8slkZCtn5PMkYiagyu8i8iqlcAcu/ESAQA0i5
AxAwwDOJkJgwwCj9A2Ccg1wFuNpxCalKuFgQAzQBunwKi9INQNFvAwl6gQGgu9CqwMg8u/j1uaj3
OHiaibicgiDaQSO8QeudwfwgkJgpjZl6uJQAsuCeQGuowOgQA6CcJ5A3ltKHkQA2kJg5v8v9v+v/
utsdg2AzwBi4A0A2wODcQuicgqgXApgXAWAQQcuJwtwXAyOtvUAxDAgzOFsfAwg2Q+MOu8g0sMw+
QdQ6jBQcg1gWw1j9QxP9A6g3DAQuA3gQA4A5A3sekRuKDbsaA2QQRLOHMwu6stk6guEAAbQXjoQY
jVj1DbuavXG2v0iEmYG4M6ispNm9C2i+vMgZE/JmkWQfDXiSPgjHvbNRiFCVJNiPGSpwvrCnmPl9
jiJmxfJyxugcPdG8HNIcG5HxCGMDPziFv0kWCKjMGEjIAqORApwDuFA6QFA8gdCdCeQ+Q2w3wujW
RdkZAzjGJoCEmlDXtcD/RvDIyGRxAQPgn1lkk9GEojx0RrpxN3xwxvipSDu1JiEWHzGWiPMViFyC
uWC0AUAbEyPXgGiAgA1lbmRzdHJlYW0NZW5kb2JqDTM1IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERG
IC9UZXh0IF0NL0ZvbnQgPDwNL0YyIDUgMCBSDS9GNiA3IDAgUg0vRjggOCAwIFINL0YxMCA5IDAg
Ug0vRjE4IDI3IDAgUg0vRjI0IDM2IDAgUg0+Pg0vRXh0R1N0YXRlIDw8DS9HUzIgMTMgMCBSDS9H
UzMgMTQgMCBSDS9HUzQgMTUgMCBSDT4+DT4+DWVuZG9iag0zOCAwIG9iag08PA0vTGVuZ3RoIDE2
NTIxDS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMoGcxARSwDRiMx
cOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRiLhsNBAcjLMJF
M5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKgawaMopXLQN43N5sN5yMIsLRkMByLhvV
qJRplJJrHzMKoKVAaLyNDIEVJTdxtVrCIMZVhkMhteIsNspOhpDCpH6hBBaMKoMBhiTHT6oMhqNx
AVDuDS2KDKbjGcjycDoaTebhYIN2Zd8ZhAdDRwDWZTzDjSbuHxRAcDCaTkKS6VCVTxALZ+Mc2Oda
RAbodGMRrrdPohhqsTr9iaYcbTCZOAcDqYjYaTGbDyIDCduiNgwvsMrejCNwyOaMrqOsBoqME8TS
Ky8zUPSqzXNgFA3uIMo5JahwUrYGwUOO3DnjkNL/DpAYQDKNMNQ43b+BANAwjkMgWwU68GvC9EIQ
k9DVQq9gUDvGjgDoN7juYN8OOWEAxjeNr6RTDg5jeMw6SIogXBBHDsO0vDuBm78dtG9MJNiKgUhi
ra8QwFLxBiFAQDm2cDjDEsMjKMcUwONoyjmOYwjO4A6jm5Yzy6qEvu4GTvCo8EHx6KjThQ+j7PwE
Djv22batu3Ldt7DU5zrDYUioNUGQdHkzUmBoUSfKI3zoh07z9QFBRVDTmU42zcOUOlTVRHTYjvFo
0QQroxjSOA0tmOguBm1U1LsjYUIdSz7jHTLkQ+jQcBRLYntpBLqxzVUytNV1eU8MoyN7FsnQK3w3
P0EAxOA+VOtxdtg1TMjSVY09iWNZCiWVZlnWhaQY2oGdrRLE4wxTbY826itwBAII5y7HVItLM4UD
Y3Yzv4hzd3rUWDWXZo3DpGQw1oMYxz/jdy382Mj2QOETRQ41uTYHIUVC506QNDd4uZe+OXPgDOYE
FGYDmOqiQO4mJXnlDnZVhGW6RpcL3zXuXVFW1A0HLYgjZKqWuFWuaVxr7YjHeV7hBsN2QPYriWRo
r5DlhQa2mjQaWtr+PXS2NsUxTWLaDobga3lmXbnpLgZhG+bWHa2p3a5ur5O/dRb7o8njqNkDxmO1
yQXHTZNpsXOxa3t77nQrgdBvlSOnU+b0rWVZ1nnWeYln2KpnoMti4FAqOdnY3jFzHWaY0mnQuNgy
jbGUNuA93PZdQwzjdQ8Y7LXF7YrzPp4/VrY3W3Hx3hvVjzvneI4nTSlDLAua+lf/qMgbI29QYIFi
hsDYU0N4IGRBuUGhxuqdDahlDoCxuK1jlszWQwoGTqkTBmDyodhSYn8PdcUGNLYVwUg4JIbJwyq1
0pDDTAZOYbw2OqObCQOTz3rvZQAlNeYLguApX6YYqxiSUqKJ+DdMKY0fg0NYhYFAUD6rZBa/huYb
AxumYkboNxyg3B2hpDZUQZQ8BwDejd3kSAXKMUcpBVb1TYhuWcGmLaMErAgg4m9NYLnCH7QAHKAY
bg6htXuHIOaW0umGMQa0lJWSNg5MwWRMbh0JRRimfiNCqDtFTBnJAnZ2zuyTR4eVVqPy3IWNi/h9
ynzmJVhqn9ZCmgWhkPcHREwYg6pqKmnF6K5n/FyR8akGyYpUAolYm8GTx1Kw5QEG12YdWXIzIcli
BJ8A1JLhauiYJ6TVmtNeCgMgcgwh3DEGEMYaw5g6BA8oMMQTnyXDHFU5C8YsRalYxt3jHUeAzlIe
eYRnJvh0DCccpQdQxrHgXA1z0rQ8htT9LZxa3J8vTBio6fx6SezeQvFeLMPYuSHmQXknUllLrais
GGetHjdv8l8x56sponzfOXGCV6yIyRmjky2OkrDgx4Q2xV3kiihRGAaRoGRFjH1GIsDQu4NDylZM
qY0oRnTURFkkaIGZQizSUlKVSiqjkhBGDSGdzgICpggCuwQOdDaHompNPNXkyDRJxU9Fw3qiTsxJ
JGmNqCc1DvXYpQUObLoHozaovaCQdwymzRXOYNC/XWujQ4gVA7BkWQcSclAMRy46huS2EJDKx7IG
CKgq1SqNDcywpQ2uOTnWcupcsxBJZXaVBukyRInINbdFWBqRsGdv5RTatMHMNCyzhwJls/sNq8I5
B3YpIdjIbDiBvDqGdY5xD3L9jURgjNfKHhoDe3lJc6ICBlhk/JGIcz4QykFIRo6VrRquOgHK1Ic1
3sue6GQN6fw3OAZcHe8aKwzLQBmDZZSzl63oDDfFkKNJAyDkLT2+ZuWDoFDpSB3hHSdHlt6XUGqF
TwGxrFWQogICKAgilSWZANreuElU6+PTQa6owe7OVOgZK8Jfu4RZR8v5+oTLqkFVyMJqFKYkcU+G
FKUL1KJD1zqmroBFsdfFSMnZt1fo1KmeaTVRHQOkc9UoLXBgoDMksNs0znUzQ2nSZCjQXA1QwcJD
U2WAOIQwi6GcBEZsuN/YGuJdK5goU9fZZFoVSvpbAno6Z2i2YyV8uGOVPVRZQQ7kY+U76Sn6S6dz
N6QCLxrBjqGvh/T/oBsBZTQueHuojZc/VnsFI015LxXvHpsljXvOYnewwZEspGSRYy2aTUqpX16C
7Kkb2QYpWzn7GB2i710fejC1cCUu1GKCUK0sbqvAyqmpSVzqs0HzmZbfMROtr6yx3cE0paGQQ7p6
/iWlg5bzQi5m0ijhA0x6l2CgN2+o1py38nENnAWocE0WROPgKFESbhZwxLnDOFlZBQdNmzDI1kZO
9tmX8L7qBwIc/Jfp2q58Y3RrQ8ExjnJPXGiSO7M76BpwJgZ4mGFUBFMIWIHEwyyEV25JIsxk8WkX
M3HwGZFrfmVBuTsHJd8CldAaDUGBbAcA5KEY0vBlClEoMEEIwhhia1E1CVTbEkuwgwKFtwqcKiLm
ZBwDFCpHyBEER/RmKGypMYvX1TzGrMHO5EwBkZDWST8ZLqAqiNRjQbRPxDxO8zxED6UDucXEr+qD
2By4806KHA4IbzKHLM6MTfy9X8kMMLoZxRd874KOxzFRBkYkGFLbzHtn8xLkV50zZ8LCMFDBvcJZ
5KbdfjMN06vNhy9SgWDB7mpWqQMgjBh8LbHLBahoFtywyBk1OHSgU59jO85sA0KJKiWEuAaDQjRe
azF1LwDki23C2JmzERTpPTgZ0iLQmLFhFAZdu6yFcFQpovgkYmgiwm4nIrQnwoAoQvbhAo4vwjwB
or47ArYqYqoq5CIngrgvcCIx4x4s0DgEAgQJY7AJUEAEANTnaYZMS5wkIoIEAJoEALYLoqAMggog
4hIKZMQM4hwiD8rZ4HA1j/Yyqfg8oj4G4igrEIDtwto8sIzWY8sIMJaPABsJoHKrKs0JUIYEAHA0
Q1cJ5ai3Q8oPKosLijJNbtI1gk78wFwHKp7pIio1ipiNaYEM0N8KUOIyiIsN0H4EEOIjsJMIS3QE
EMQMQ7EDgoBTIlkEkKYkIGrs8LEQMIsRjs5aiYYoUJoHERqsxaiJRMQO0RcNYxsTQxhj8LaPiSEU
RMBMUMUS8TMKELIk8QkD4ssEYl41S3IHIgUV0SAs5Ng9IhkXUJ5NgmsYEKSZLpjosK8QEJ8TENYr
cVEMEQQs8ZgHMZ0OkPYk8WwtqocPUIERrN5CMaw1kT0bLxMEEbis0bwGsXEZMKMQcQqq8Q4swgUR
UYzDY70Ygj8eo1Ue8SkK0fUdUVETkYpNj+sXMShj6o63sfgu8gUMUf8e8R48sWD8D8QgT8hhgnIr
EEDpcNYgTuDswiqJ0jYu8dcjAoDqcTQyrqIq0MTUItgGjr8KqPjrAk5hi3o0ip8UojAq0moGEm8n
0EEH4vEKwk8UrFiocoUIwoUoo0Uo8kcjqBQiUkD+pMSr8qEk0jUq0dcT0Daq7n0GohAhUHMHYiMo
wtzIIqi7o0TpYoQui3pMQvaI7nZCkubrEWbtooAGsX4qstKpENbqg7I1Qjbp0uQ9EvUuYn0r4HAq
YoML0lUtUv8tswUuAoswsvsuYjExUI7K0tDqMv0tkwMt8wkQsOQ8quYGBMUu8jK4EzsyE0Et0wcu
JCZj6uYjjnYrLjMREZgzAyUvkzznc18yc0ZHggSuabs4zsYsznIoEvcx8z8wE2EyglE2c4qNYHE1
M60xREAiclMy8tc6E4U2U4jnYurjInUCsu4jQGzqM7s3878yU0U8Q8c8ifk+k4s3Qxk9s108E+My
s6k8iSI0Q1Q1kWYHMLkwE1s58+E2M/08dATtVB81MREXDN7tVBM4E/lBk6dBwmjbAjYu0r4qVCsg
051DFBc6SI8+arFDy385IBsmULs/VBU0NDVFJ/6rEUNHFEK3IGz9s30/dE84Y0YhirArirDnNEK3
rD85s70yNGlFE2dIiPgmo0UmE+4sySDN7D9GVE1J9IVG6PipznYGj+tEItkRsflEs99L0+VMCJ06
oGjnVAojURpMVC9Nc6NL5M1KsalMclFAou4GrptO9J1PNNtPbTs7An1FxhkLlO1H9GdQ1BtIbndN
FStRg0rTsSdNVQs8NSdMFGMLlHMRBhgqYn0IFSFLtSVDdSkps2jN8dcWZhgign1ElJs4M/tVg0k7
AzEv0JEr8kzqFTdW9DNKCfcFETMptMlYEn0U1H1TlXFGs2dXlXwG03MeUviplJk91TtXNG01DnYG
89AoEwFWTqKPkTFLlPFT1XVcA0UI1KT+dcxwcZ1QlaNYw0c7AnsvwuAx1UhaiJ1bdIFNlT9dwy00
zWdK4iTi1OM3taFYtPU7Dts6ordAlUjsKp1NNYlINQ9iVMo0UxdCUeSRyp1R9h9jlgtDznNiSplY
DhAGkkVe1iFQ9lVP8N9RjTlmFdVbtaRHlD0XFhFa9hbFsf1VNddb02dn8mE4Eu1i4yozdZ9jdgk6
b8Ilciwl8NT9Aydd79isyJw1I7M67q7+j+y4D/InT/gpb/4p0BgvsAYmwnAsYnkBEFsBYkNtwpIp
cAAqECYqgqwrArUDIr1vcr0EMWgqEE8pq4EFYisFsF8GMGcsEG8sYh4iMrAgUrUj0qQnInA1lzME
EkFHtjUlcaMl1KYiyire8mkqUn8nNd79Ent1soItkpUqMs0pF2kokMcvKocjkdcnonMqkp8kt0Nz
F3wgUTwOcilqwlsWsmEtIxF47rLbgn4GdEFz96iNcxM1slgs9QQit1EmQzcngs959ONz0nV2F8on
9892cocpYs6PbUKIspN3T/Ytl+d4YgUbAGlkEK17F57qN6Mkl5ECFvY0dpU6oqVfwswg0sMHAhty
t+N/D/dnde9PVn48k4Er7/YjTUMx1qVVdb9ms80H9Fz/bZ9EFmVlFdtlVOUkNoVrcOVgVSNdlb9j
1AjnlkQs7/YqkU+FdqeG7ndidcNPsWYycCklGIGEVadcNdN19hQyYiguVk2EOG2Jtd4t1d9OODjb
ktNVFh5MWJlY9d5aNcNIkRDoEtOC1mdgtfVcda2E4zIqtYdbmC9jsFFauGKZIqibuJeK+Ml3kFFZ
eI6o+PtW2O2NtdtXio8FBNeLou7s2OtgeMdVooFV8dWKN6wqkZGP9pBHlKVULN9Ubn4jmTmGlVWQ
GS1S0LmE5aI1OEGROFlb+ULdkLg7mDi36r10eSmVVN2I1dGGKrLbeNmWdKNMaJVMdOWNKfg0dh2K
2T+S1mFhFMli2UuZ+WWIOY9KtKlKeTQyrpeKubOStMCTtKTouBgs7+sNcPeT1nuSzAoxwjedItAj
Vrud1fBHtFbndFuXMkguGYubVDgjlFlEGI9/sUFqOROMWX1V6o8vyo+Hd7KSGRGXuaOfTc1KVAeD
jocNmWOi2d+jAtFhAtGKNMkNb82gOcmh2g08+elmGlGVFo+kNV4js7FKmNKp0NdQdo1nmfOms497
WE9OMNZRulWhs6oiepOo2g7RrdmfE4c28oE0+iUNUXGbGkFY0zEvzqOa18uAmo+T8xFKUn2KLqEN
dcGqE8UuueUumI8BDqeMGaFnsr2t7tMddmWhlpFqr8drD84yT9Qrb9tr7+FsT+Yvb+oyr+4q978I
L/ttcAIpAmsAtuQnon9uoottsAVvOAwsAqMClv8C8Cbp0rox9wwqEElxEFFxbE1xooVx8GRu1yUs
WCMHl7OAV/V6d596w72AA7d7dH97o1QkN8N1V8l7N9ojt1+4980csP198qN+7UF+l3N+G6V/Nz9/
l/13usG27+dz95IlkE4n7qYi1xjnO14l47gxkMtEQrYoTuA1dCt6InIqW3sXudo9InTtsc28k7ii
tM8ZA07t0A23tESYYxG+W8soKqKZMEFHri6ItA0mYhnAYjDWcqsmSSENqptcCisjMdcMQKcd4qAg
UeRNl/vDPEFzRNchVrqioyonEiQiUZkvV8Ml4msmombpKp/Cb+fHXDvFVcl/brQwYwoIxhkEoxQB
uxTnox9M470vQnVz3KSYYxIj5SIzZCXLI9ZC4ILfrhBhwPK7CBhFbZuTbOBvCAhgh0StiCTg4nIG
4FBTB5SDSCAoiCYFL9hNqEIFKTrgDNwGQFHOxmiu3PT8/QZaIGfPxoJLnQPRIyZ8pQZNQihhyCnP
fOXPvP/Rwu/QSDQMyGJBPMJoXQ/PnRXRhOSCSEydwNZNSoyFjDXQR9BBYnN/tMRRYxrxQ7CUrLJV
5uhfDRRN/NDQRfZvPNhogMJPxOfNyWyPUjPOak3VxavUSFZivPZb5Aj5oOw/A4AOwFOLxwjNb2BL
r78psFosUNmiWQ09dOw8jN8zMfPdetMJTpMIDN1QURxEEgAtEponEK/fQ7w0+kois1iPbFke+V4v
MJ/enBwtAqfhUK9JUzPgXhLFkK/WuRvgc6/dre+H+TdHsR3joq3gXe8f1l+H/eXdvjD9vlPiPd41
g04NGdUClPpNclUjUfOV4u1zwuDsVOzNwifngtOZIybZ9Mvm2WBJ2Hno3nlQKiu6MwTpfpsb470b
HqPmvC41XqCXdMRNYtnrXq3rknKXddPqwtjKwjvsnGYyfs+3uw1+wtDN8oL+XuAqdhvubWb9KTkg
Gm2dmwCTlpYjvWsTPknvfty3rxPquHnw3Bk6zs/uI7kpFp79NWnxooXkkI/ms5cmHlntvy0aPtiR
8oIjUn0NHxaNfrqFWPv02JH1HHuKeRvq3F1z0mQ9Ik2Hn2cjdrntfoE2yiv3fqHo0gwn+KXqEjNl
ouon79nx/4mnkhTrAyf5oyTiwxvgOHn6Xl0NnezFter9TblO2TaJXx9AVZfikhX5H71ZbbiucKv7
OP2hF1MK/c3639aNf9rDwisYbApMEfiJNawEAgAyGYyFwwHA4EAyGAxFwxGY5EBjBsCggwHI3EAx
G42go2GIgNgNMwqBowEBqEAwFw3GsQO4giYyHAuGwwGcJGI1Fw1G8YNsxmc1m4yGMcG4yjAyGQ5n
YzGk4G80lsJGcqGw4p9EqI2qcSgUMHAzocaqUQikrrk4o1IqkEjY1nE6nkYr0DtFwog0Fw0mVUsF
inAzvY5G1Uq1YwODwtepdNrMOxUJmU0m04vV8hFKoOVolynsRBpoid2i0YjUcGEeEE/s+ljI3vQw
GlDxsO0w3wUXj9Kpm21+oGVwxm9Ge3pg1GMQkNKnQ5i+v4/JkEx5vPjVR4PTpUEGI0uHXF3Z5dKh
vejI47g4uHjqMP8/p9cx9sQGNhldO7UCnfnwW4p7xoIGgbMK+r+qS8gZqnAoXByHDCu2FynI++rL
hqp7GIJBL6PUmgbuUmMMwVByGsQpTBO6p76o4rL9O/EcLpiwQbOtF76sk+bzxWEA8vlCMNpmGCeP
y7jzPrIEhQA8rvhywQYL68bqtNJiCye6kGOsHKVQ8+LeIaGcJyylYcy42svoShbwoE/K9BsGizTR
BsWIYgUHyDBgZQeojwhnB4YqtGbQKVOc+LjBkhOYvcPMklQZNmwyVu7Rbw0curmzdSVGqGGiVOSs
bm0PTaGyYnE/ogr1Q07M6dBxG06UhN6GI2szSIPM6GIdUzRoq6yNo6j6QjmBocoZAcCJ7BiNNXYV
iQG360IwHKCJahCNVXQkptg29rMXYS9BxXlthBMYXPQ+leo3aFVqW16o2GulhXVcymNSwoc29Xim
OchFsBo40roQiVop3BroX/cVmWNedm2GmlmvBdzQNFcait2sjZpun+JtUoimO8j+BIVirjzVkCFq
gvdAYCgmQsSi742/X2WpY6eYNTiqOUbl6dIUsyi0nnTwosnCGKrD8wu8x+iaEkOjwtM6mI3miOBr
NunrRmi5KGiyV0aEEOL5rTjoNrydU2vGttk0GvzUhSo1ZoGwTO9oYo/Ee27kgt7a9qeq7bvMYRHq
O/BhqOmqzwm/x3YSVaRVS9uLrGgzfsvIJDDmeTPxlm8thTdhhzTC85mKFIJGejO5vXSJo5zp4E5M
U5Ao+aKiG6HIzhjka8vSlw2qOqIQrDw9Y+qCPRbng95dimowg6d0cjTBODj8DWo3Dw9zgN59t6Hr
wmm3rtv33IT96MheJck8NB8nwPOrfC6gsPb1i7OJhqGXbxDbmNYqqOLumSNZbDVjLtWSxlhCzl0L
iWkwRaq5Frn9X6a9cLAV7ragcvVeMCAbLpfQuaAi71xrlYKvRcUFWCr6XFBBf0KGVMDeqvlgjDFi
wjYXAdh6ySJMSJ0xRk7/mMw7Y2ckvbuWSsiJ2yRlbJitMoVzEVmTL3OxPZpFEojODzOWZ20KKrP3
IuYKI0pozjGnRfQi0txcQ3DtQdCA1EbVI0tXiwU1qxRyntrbCTtsbX0gtWbSRKOzeG3uRbi35L7d
WcOEbwRaOrfHDlRkU2ooydZHOFjFI1xKPHDOONmRiOMXk7Sbi7Fpz7KI1s1Y3KNAUpYqJOdW6dUT
h3SusaY6h2DK3ZOWdo9t3DdXdvDBw74q7unhIbeK+mP0vYPPLa8TNCxN3uPShSSsG71XykfeyQV7
b1poPrOC+GZU3HzHofQtycBppfodXq/CZzDCjlwfq/c5L+TQP7h6YBYBJUIlTJMSoGp7iTBrAaR8
lBVjAEvoCWRVinmuP3J+d1lYNDHk6KPPAvhe0nKFomCAO1AaKtUowUojKbmgueJmtEm6PDulMZYR
plYMyEEhbo75qNLE9rULIf419LSEUbpiuRaNOaakZoQ7YztC3FBiJKSmpRKiEUAI+EomFDi9qso/
QyjiAaqM8IKyaqQNKstoqpTyjtPyFUlUBSkhtIKtEGI/SiitXmK0SpASGpBKkNVLKaRCf9SaoUBR
GDFrtRaMmsT8TuMZOajFES1YCqtGiJ2Fl/Y2JZyH71lTvSex7vrGU0IFS+vyq7I2cpcjkgqRSj1B
p43YytolqV/sDYijKPK61LJSuQEFTgQV9sUmKuNRrCJaWHHyJVhUPOeXnWGx5KkstarMz1/pgK11
UR5bu4tja6ANCEFQBsO0HW0I4QMuANTDpvXabAEAVCfz7qUR+gAQgsAgBeEcKZTwzhzBAEULE+HP
smCoRIFpKr9kfCoHcBoKAphlDYGwjLnwUhUDVUkFuAgiYFDmGgMIcgy32DeGbBuDwqEkBQEEIQQw
iYdAbh8BoWwUBJDcGQOocw6ByBThFNgKA0gpU4CjDIXCBgxBSF0KgSsT4gCUG8NAbgQBTDaGkOga
MTJaS+RgFqTS4BUwnioKAbAwhpDcHQMoKTGgzBQHjHAKA6Y/yDQF0tIL/kFyrlcFAQw8hwDQGXGQ
LVQgyzNl/MOY8zgtPQnDOOc8653zznvMBTMxB4zPkDIRSCCm4fvgDN+KQUZZy3l3Pmisx5l0bmnN
rLjCnYvPhMk2A8C4HwTgsGGTwQYR1LhTC2GMNYcwdkPAuIsSYmxRirFmLsYZ3O6TTG2OCG46Dnjw
omaMhYozbgG8+BAUZFyPknJeTcTYRRORYhD0dY6nIlqfaQayPgg3NufdAIA76u1hla/Tn8BX+wBv
DaOBdzX2BBkgMQPdyggy/rfFG4Kk6oBQHKjXB9zhp3OHXc4L9eEk3nfzeVW7+bSa8HbcwPwSboC3
tkyBSy2In2/efcO9QUbk3TyndW7MJbv4kA3Z+9OCb33Nvrfm59/4exBwbjHGOE8L4bw/ewOOfca4
5ia7hhSTK3ovd87LwVWLUQG87KpP8VBFDcGPO6fCdgoznn8zSIwcgoCIGXrWM+uA168HDT+Qgi3a
CiA0ONAQQcKAal+lRj4rFZNmQ0j+gHioCBBhju6vSBE3K49Eoqygrgq3zQEwRCCekzS+QgGryNXk
sWIU/whkPJTTQijYn4V/HkmQ8RUwpHn7gt9P4MMoDfSBuuxdoF4Rk/EZvOGYBrOGu3qd8RC8B5TT
IWTSQi9FSb1Xsuxe++IUyb31vvfngW4tLBBDcCkyANOvZNy4Gff3Wetz87Xl4Mm6smBoBBk0MoIA
4B1DF9jygKA2BpDHbf+CEcdf3zEHnMpEQwskA3g3A2A8gQAxP1gyOzPwuuuvgyvyg7vzv0s6iIg3
g5NaA4QAgyPutmOYHGJCtXlbkBiMN3MVA4NhMag0g7MwDLgUAwsvP7D6v8MvwYP9gUkGlyAUAWAQ
P/vyv/vsDBPtA8vuA3PvAyvwO0PxQGQHQIP1P2QTNiQUQVC9wWQXA1v9P8wZuvP+gxv/gQQAwBwC
wDwEwjwFu2QGvzMmwIsvtHPIIjj0QPiGwQtYsVAxwKQLQMPuv2P3QrP5v6wqwsQZP4v+QbAcAUAX
QNu3t3tJlEiPnNCbq9r1OlgQAlq+PcKBiaKCgQPImqgmgQAtguiTAyO7kpk+GelVjCFlAaKEFClv
jCxUl2vLxVxTqNxUiZm6E+xTRWlGiVlDm0DnkeC+C9CWDbkArGCQiHkTiBqgRUn7xjnhRlLGKNxm
qIHqxiRmRRlAKixWKjvkL1rbu6K+xaCCnIRsxTifxwibCkmtlqgQRzxxmtjgi4RZwYDujMx1FHRg
EOx6qVAai4RfwYR0RYo1qkLsrtkSOlKlOnC4CHi9LGCFKJGovjr3L4L5L6L7L8OXN4tLM7MZtDg6
AQMeAbAZMeEEg6wNiTN2sJsdA6MeG6MTPai2MBPdSErvEIjslNkZD8DkmOncvjuBAUAuCkNWtbva
vbyYyCkVSaLwR2HEE/ECDnIhsBL0uKSMsbA5gyHftslpCbCESUMCygCeyvgZgxA3AxSQEBghAQJp
uhAUAhSgELS3AZseJ+gxLsyXAjSYPcvdyai4L1SZxUiGDnEJkRgcL+L0uSSvGcy7Siy8ukykybGf
EXCOTCSoyMTDyfk8AaMeCjtsi9Evi4SugUQLsTREN5xFF+xGGURHRvCTK+yJPmvnyLL8kBCGKILK
rERtRzEOJfqFRtKvDUEzRyDCxZq/lvyAx2GBH4q1xfAGk3HipnLTxljpzZmgjvzoLGTpk+TnxqrH
Tpn7J4TrH7zpzazjLZRuRIrcRwK/rezcTmT1GrR1zfO/GrR4TuG7K1R7CbzmxdrjHrx+z2iOG6Tj
LryCTGy+y9x2SQlRGtSHjCyIvmSKAQPoSLuYuKyNNDFGMzSPk+SRCxAaySw1sUSVSWMfShy7jTS8
yZ0DSlTTiVpESdSoLzzDL+uBtpSvyhMHyiRIgqPdUCyEUDl+odlFUXmPUYzK0Zyqyriryso8LRyu
0KMBUaikAbywyxyyk+Szy0gcS1y2jgzMjgy4kEyxS60Sy8Udy9SlUVSbTCCOkUzBzCuBuSuCSgDv
TFUdUeSDTHC4KvC9CeJnU3TKOIyqSgE2zNAZTOPQzPuWzQg3zRu4O5O6O7Dil8i+jkqSjPifqXFO
GHQbCLiMVMqtx0odqIHFCHi3HxmBE3D/u701iBkUkPFyVRxjVWGukVFyGTRjR+EGHZVazJjpkEjm
1d1ODPxjVXkZkwVLVPVXlolqVhCMKNvYzzKlL20HvnUIzYu71cjdHHKHLajnCngWjgkIvXCRPkEq
OlVzVpVsCODCHD1RRFVvNX1wibvCPdJ9s3RFEgxGRvEExXx613Vum9VwCdV5vX16ranCCEMADPq9
kEqSn7Vti+WAVv15Vx2DFOI92LzVKAENEGDzSHDy132A2KV6N3zUCHWTF12GCakGD3WP1uLlWRWB
2K2SraiciMFOGnWVTALoE7WXkr2J2ZWSN52TH4lOWE190Elo1Q2QWJV42g2C2aFGGhWpSD2NgbDc
rK2e2I2YWgVxWhKtzUCBS+E919WrC9Fh122mWuWnWvWoWhrak8RFJu10k+Dmmx2XWt2f22WCVyW3
lGFa2/2NO7upks2s1/212BW22+2wLakvinq7Wp2kG3Ex2IWQ2u2+V63GK7XHkIj8WVCZiDnJ21W9
XE3MRE3Glmq7Wq3BimCD0F3R14XS2ZzS3Gqfq7Lu2GAbqmHBWtXLW93ZqtzTEbHGUA3ciwWl2fXY
2R23XgraqIWxpQXcnim+3e2m3ZWvnPzTHa3nWr26HrD1V/XYWY3FXM3s3nDnnGTi3clvHc28XfXr
3mXzJ+E1J+FI3clV2PXq3EXl3F35HnK9HnXvTJWW39XSX+XyqLp+GZp+XU19ljiw3DXxXL3gX/Ca
zUCW2yvC3QH033XrYDt3xHCaC+irFk3c3W4I3k3x3TN54QiuXOE23BVPlWW04U4J3sDKjDrakBq9
V9lWVbXkW83lWn3+4cUW1zkZ3H4eniolYC4hXyYQLatJYotJ4ej+3KYO394h4EYQiWWEiVvBWGHg
pp3w4a3f4b4uD1Yo3t4wqJQ3YsYDYtYoKmXikxWb4eijXeXD44Yn4WLaiw2bn0YYpzlZXK4PY4t5
3OEHYQisYeWNnmiN3X4y34YiZE31FyLzYwmoReY9YnYVqt3OFh2x5GxREtGz5OYVYKG0rlRU1un0
2GJ2VR435O2Zu4u5iP1IohLXu9iEu+0AvAVYDCvCDimcDAPEjwvFvRvHPZPPS0vQPKgQPLndvMjk
CaPOPX5mPJvQiEPRvSy0mBDUgQPVPMqfvCVoRIPcRJzWKlRLWribiXxNCnxORPRQPlyJ1q0JL81J
E71mVkFlVPiiynZ+1PnP4gCnkeVSj7kpEAm9VZK7VaVXisVVVP1WrSVe1cVgJ4U/1fVs1g5+1iCm
VjHb6BVlVKVmrHFg5a1ICYDkLvj6aTCf6WYREpZ+6YkBXREUHFH7DeoGVUaGLtmfJpmE1YVVaY6g
6K1bzmVUSc6NCQz9DZnYaPaf0AJ+6RVdCMaYj3VK6rLHZzZP1u5WLlZXRvTXL5TYPo6kkAj8ZZZU
Yb5QCc1u10k3Qfi2a14bX45VFyZLJf4kqAVUi9iiZC4s4+avKmXuqmFLq9k3Gy63664za75FnIKm
X6RvE3EVpRZT67YiZF46EPY7a+iLqLYUYg62bH4o40ktY17KQbCHk67MbHbNYoxYEtYwbVNFab7R
7M4t4oxkktYqKALxXb5I7cbX7dEtZwCrG9K9rxGiDP7G5J7iiaYvYd10rxEM3t7nYP4+irWc5q3B
LxDBW67A495PHP4W4RiaYSxvLxTOxYbsZD3mirGTJ+Lg7lE7EE7RX37s74Cd4Fid4G7fjUkIvBb3
bB3/ELYAWc71HECxbb78738DX6Cd37cFPKWebXbn3TnGX0Kp5RrxNFa6Ym7SYiXtTUEBbvLCse7x
ZZ4bzTDzQO7PafmiFI8CbyYEi93h8b4MrKIy4ybh8MXaK7XbEI3cb1DICq78ZDcC8bUr3UbqNhil
7W4JbiWo8BXG3Pcimdzi8aZUzUXHXG3I7fmfCZbhcHclWw3ADw2i8ijsbm8Q7c8qW424EhblQYcQ
cL79N6FGEE24Ezc6KVXqc78H75HJW4bj71CFHr8e8y8a2iYQ3h9Dk52H8t4b2Tc5iG8E7fjyGc8V
cRYEWTc+q08Oj9CBcG8k4V2a2MCG4cdDnd8Lcpcf2Dpp9Y8YH7Gd4Oc3cp17Eg18Hc7lE8E09Oc3
9dZXV0dfDscZ9cdYZz9MiZm79J2oaU5biYO8FJi1FJu+ETu/pxCsZgvX5hk9vEJ+5jjC5kvH5sZn
EbZojw5pvN1x9zvKPRPYZuvTiO5wrGPWZyPX5zLaCP50rc514dRMZ4AQZ5RPgQRQ6yZ71r6saXZ+
6YGfSQ6Z6t6axsWtaDLtja6eaF6iagLuiNXW1Y6pCV+Pama0HH02zJakanSc6TCQ6Yicp16aGfas
6TKNlgqBCMqfCEZ3lyRNiYR8V4DkiwDVRzC7aXDcxTmkKLGzmiFLqICo2TnbiOCajhTmCHjKaXFi
HWGL5jpzCdYkR2O+7FDzmOziiJDvEmrglOxxT8viCjkwD+ipkeAp1ovlele3nb+4iIRzZqEvynDm
xizmWV9uepKpo1+lDZU/H4JOTme3bAe1iWEPoAWL5RDcVui02VepvBD6iGb15/Opk2kCU1zCSFIN
5j6M89PgfTFhzBfUjQE+Cg/Wk9/VDeqZ/Ro9xSCG/bfOo+3WfdfRIkib/Yb0D3i0fVICTBC3GU3B
9j6M/lfVfNfgGg/hfQfN4ffPIcvCjBH7U21NZ/PQEB0/fvDinaG9ehNIxMrTjg+jojprPC5SkpDc
lkjilODs+1n7CP/cjCe/7+F3/9AbCACAYjkai4bDUbCAZjcYC4YDSEwMcQ4ZDiFDYci4cjaIjmJj
CKiAxg2FjIXDEYDGBR6KRY2SQbyaUSoZDCGjIaDIQS8ZxiNRwQTWbzmdySfRuEzUYi4bjQaUWSye
U0GU0ynVCYycZjmqUum0+ozOqSYcDWVHmjRmkWMXWWVTyj0CajSTjGEzysjGLXO63eYTK9jCCjcb
36e2q5YKmYWoXGkjAbi4aT2sTKpzXI5PDXnLjCMjMZ0+4RkaDEZ1SMjHGYfJDmdTWMjgcDcQHa0i
4a7KgyimDWdT0bC4ZWbd0sc5OL3SPY+MzGuSOe8occzJabkxrIajcDeVdHsbTYQYayKjcrswOCjX
CY3zbSBjONRvrjgZe4c/AcDOLT34TGVPe3AZJU6AaoywSOrI7oaoK1T3Bwhr9NOnqTIw069Jurby
OAtqHoFB6ToS7z6PG1SPuGi7IhyrkGo0iENO4k7fIEwi2hs2iFpu/MPIauyFBu+DfKfC8QPIMwVA
aGAQDUECGhs0AQDuhUaqeJoQKM4IbRcvSlhrDo2yug0tQ/B7xp6yMBJ1IYZQzMyNBi/8PzW56jIm
G04QwrjWNUiMxsEi7UsZLbcQ66CfT3DyTJrCQbTrOCTMLPMbTdRymIxDVJTRRFK0jLExUSGFF07P
kuUIBo0JhICcR3IkvoXOsnVXHqFsiG7jpWpbsqi4cVvvAMBpghobvUlb4By1UfR5E8AN87rHJW9L
10KxFnvFEKGIdLSWJA/dnIklsXss/9tJCvFwqooadNGn7H3QxrEMeryr3KqSaKqr7Kq0rilKssDO
XqsjiLQ1i1prgC3tvgiHr7fC9Kouk3s2wCqMGxl1YTijDWczDJMpeaxY2zWGM6z7Q3c6rTvDQ7WB
o1ztNk2jbNY3K9t5YTfo44TiQE4zkO85btOdS7pOo0tFva7T1Wbo7woPoTv2o9TaLho8ARVEMsra
+tiLa/SLv7AWt2ZDUCochCVwShUFpO9chwii8KPvVc5Uu4MHyFD9ZaxEcZxNMtJRVGcUxc6EYBjG
UWOnG9rorC28WtVO7x4hKRjnJEmcvJI1galUlvxLIQSqkjh7LfXDLa+VW5Y1rdoKHD5NCjMs5p1r
5Zj1UHqT03XRChDJBo8DPIcHLaYF3qnPcrLS3T0S6PpNPkhi36cI0izVJN5Ta9FBmu+s6vpIKwXS
9ohK0DFy0k/QgwQc0lQlSt2Cma1AXxhB1Lm/l4LVTL1SY+AjJwzxu2NihllLPXek9MC/9BYIGBP8
fk7o+RL3zPocw+tyz7gGm+dij91jpyEpfQWw9UEHXdgghCcJO0JHawZBqXQoj84PQmTsQ6FJ4TPP
EgzDMGEKXuvYJfBpjhEXoE6iAgVIUQ3sxAZsjN670YTAyg2yiCD5AGwTgqk2Cz7UrQnZLDCEsIIW
gui6/lYUJowxjgVAGFkLkZQFNOQghpHjXvBgBAyNcYinxegjFV88YkLOXc0l0/BHiqHwSySqECoH
TmBLoyVLsLmml8BzDuExii7MoYVJNycGTFHTjmeYhKXTgk5kZHiSsoyQqKTCr+URkpUkgRbG+ToN
o5kmIXKGSysGCxiMYSOR5kpIywlvJWQZgSTHHllMWQsqzyKnLMsE9ckiyv1gy6ZYxjzpHjLM+BbJ
dDITaeCWZNKxiDKql8DAj64ilgyihJUyKs1bzlKel1M5A0PEZIQRac89XGmkK5PQ4UhC9GRTebSg
CAkVmzLqbSc5n4WoeoIseH7wQZ0PL0fAGhU6JmfZbRcyRU0u0ObuokgkdqDz2L1SQ8dE560JVwae
jbHHG0vKLSGmSMzPqWpjRWI6tDPU1opRZYRbU31ASwUB/RP5/w7KsiSoZwyLG2laDg0qM5Gq2kEo
NCyPzhEgkqol7lQzSybS7WB6tQ0fxElg4ZFdQz1TzrWgVGZBWWHjnOTKuRep8KMqBXhXhSwYssq+
Q56s5AZzokrHGDhAyly0KeSNlhwbD2FltRUEDLHrztL4YUnTLC1A0PHJKSk55vNmmlOAkxkHgUEr
UQUnEc6COAnOROjNoTIHCBuRagANbLWnhMzWaMmZpkjSNBdy7nUpugi3Ip1xgZDVVkTMovkjmFEQ
ttKCSqDJdSZtHJx1stGHHYlxKiUt1LyTLkOeSVspC2TIuyjWWsvJcXakxLaXsnJIW2vtLi6UsL3V
ZubeiqpI5nXAeBNmak203TYepNp0xDyOzejLTacU8bHXqnQQ6dRwp20AnhYyeU7jhUodcbivk+8R
z9dXQegVCqC4ioRRCheGKRYyxfTuix+aPsHpsVtNOOqMkqx7jmlVJrb4xpTQGlcnKWoeppTEydMy
HUwk4aRJ5qqclcxxT0plP8t1zqJjyphHIhEFI3Us4JTanWuNzEmplVD/lNjFViRUgkZnwYLYNNdZ
66I9rucKsJgwZ1qr9mCt9g62ZgrrhjQtesTEuk5o2clgal2psKUuydiSNWLnJheyBG4xWIIHZU8d
mJXL6YVZyy6KkW3XvFhi0uDCPWoIdcG1l77XlUtinNLttE/MbPrbq29vNXazt/NDA+DTyOVCEFQB
oLwjEoIECAKgZoMknOnBWySJ9BqAIE1iQgVEvwUSSSpzQQgsAgBeEcKZTwzhzBAEULCSCHE2JUFQ
kYWwUBQDYGENIbg6BlBTFCMQKA8B0BSF0KgSnNoUnYCAFpDU/BUCIA3fQQw8hwDQGUOQKQW0ZOEC
jgPAzP8G4QC0+hVQcgo4xxrjnHuQAy5FwLggM+TcJ4WA0+utdBpMbLtTiu+t+b+4BzTkoeAUgw5F
zjhiDNs7lKkTrbbfpoIzji67aiX99BFDcGPjoLSem4BRxnhHCuGAyOCQOwXEYxdA4sCgIgZevce7
CDXsYcOy856cQmCnUyFOjt5JgyJZiE7icsFQO4DQUBTDKGwNhAibApCoGpywLd78V7YTYqfiPFBz
DQGEOQZd4BvDN5LygVEjgoCCEIIYRPTAN9R28JIbgyB1DmHTr9gSDAoDT0kk4KPRBc0GDHpnsPUh
KDeGgNwIAphtDSHQNHrytm4ejZ3t3i/G+PJQDD16SfLfX896D0QIPSev9j6r1nrvJ/G9l7T23uOP
e6Bt7z3wMfgBz+EgL4v5/kfK+Y+c+g9eCK2cCiAaDic2BADSSsNMLaBAMIImBmYaNyLoJ0BaWEsa
Ke9Cc2PxActyjEYaS+CuBADccsVqtSISTtArBMBBA1BFBIfSa6jiKecyAaBoImMYOGSwtyKDAiLa
Ke8sM+J1A0lu0ANOIOzwR6S+uK2a2eCMIi2o2seiLaIsgpCkN0jClSNKI0za8MiwJVBgKec08y3s
2oJG4kJwNO84BQCo42BADmDyDaDaDK9wDSDGfWDKDyJEDe66DK7xAE2dBhCoRakAdEckKCd6RsL3
B6qo4gIGjFCEDKc3A8dcZRC0IIItCUSPCZCtCocvE47+IKr4JwONC43GfVC+58ZKc1DXDaDgDqDE
DZDrDvDyDHD2DHD64Q/Wdi74cvF21WIMIsR+a+8K3GBADOAbDGq83w3oJBBs2o8S329ADoDS/GDc
DKDKDIBADoDeBA8+DsDKBADCBADgDkDSDeDlBY8aDDGnD288DSDgBc9e2gTTCg8qsAJyK44pGQ4l
DJGXDObM8430CCDcDe+g45HGDkDfFgDKDaSg+eDRDdDhDlDoDGBaDXDw/2SPGSJ1GWBQDIDS9vHK
DEDrHY+XJBG1FbGlGo3hGtGxG1G5G84E/W9i308/GzHFHJHNHQ9C37JLHcDhJfG0DkDCDcDnABIy
7fGsSjIuDyDmBcBACNHOBADKDwDCDaDgDYDKBYBADNKkDI7kDDK+DnKRGS3uJG5FDaCqBcCnKeDO
DfG+DkDdDk4BDcDLLoDm7k9CDpIiDaBa/NI1H457H8IpC48S31InHLDtKY3hG2fqDTFiDo9ABSIK
5tDyDEDDLw3hKIDJKRH+PHIC+ADbMuDmDnJWNqDTHEDQDqDbKI48PqPSBRFqDrHK443gDvIfLJH4
83DNMINpDUDYDeDHIvGyDFNoDMDHMw/GDG8+3/JdMbIMDS47JmSO30DvHK9vKc2oDRJODvHODXNt
IfHDHTJ6DTG+DYDzNy3rGVLPKMDC8dBHNWDFIO9IJ3ODHXHNKLK3JHL2+eBADIDe9FL+8VIJL3O6
DkDXIc+gJ29ADPHADdPjNrKfHlCc2m2rHsKYsDDS8xN1LNGYJxN9MM8XIlDnMTKm669yne7vJLAS
3gDNMwDpQk7NCbHpQsN5E7H09UDY+gDeDqDPIg9e8sIaIs8sJPHw7dI3DLQ8WHDVDfDjRJFlLs68
7JPxRZPHPvPNDzRc9vQE303/D1KvJJPvD3K3INIRIVKzIbPoDQDeDvPS81Q65FG49xKJKNP7MXHD
ISDq9pPFDlNIDDQbQEBQDPTzKBNZIu3hP7Ko9xIY8bDzI+DM+EJ6DGDrR1JfQFSRI7LC+cDdJA4D
HRS9HFFrScDkDHNQ8fLwDpGmDcDPQk/XAGj6TePGIad+cuCWuMSSSXAYIsSi2kSqC2C6SSDJBqdi
t0emLLEw4aM+oNWMzaJeCmAbCY2hCfQtF8gpF8N8d8ienWko8NLLSTDPVpNAChFfFjMVDxRM7m8t
RTSnD2BA+K7YIqWHSIO4ORRxXHFhFlKZSrTKDmDeDZJJSpK7HRNTR7QdQhHQ+7EbSKnbH1XA8LGh
PoDhJVVLYk4BOzQnRo2sMGNMNOSTYbMJYe8VXvXLFnXQDlXZJNLG/WBbY2SfSIsDYZQ3PVI5LPTL
D3PPBZTEDdPdDdX9YBXbYFJRHBNVUBOnH3PVQ631QfNFPmDNHHYnHfKIDpUQDcDtX9G/Gy3/TcMF
ZpSVHzGg8a7k9xD3FlVFDlVJHADCDhKxDrZ1KdUvN1HzN4JAabXFXJDrNcVqBRX1SjZO7xSpX6DZ
G/MZFbISDFL9Rk9jW9MGJBSXRDTQ/JadX1I/JCDTP3SpS836DlUBcSSPH4a1I7UHR4Dg3gDFDy3/
bG9rVLVXaFD1D47w9G9LaNc+KfcZdBRDI+DO+fZ5NKDPZ2DpNm48NS/vHDT3FuDlGnUiBtOQ4Dbf
RlWlQq2s+8K9QzSPQ5W+IpXDRDZHDrItDwB0BACDSbMRShRO/jXXb/D3Ri5zHnei4aI0P1FRH1Ux
LPe4DHSBCkPuBwJVZfSNfnH4OJGW31KZNcUY+BRPZRgKBu95LGBa7QIm5XNHGxgUBRD3gLgg5FO7
guBRNY+hcQ5zcVH4sDexbpa+7fIZPvOQ8dPRgcRo/nJ5HXJdTu+hHXTxHBQbGsDlg+4ZhDaRhJBz
Ge7fhjGzG3QbIM46NyI0BRKeCKDDOXZLS9TLYlOja3M/bmqhiCBQDg45YEDbcJHA3/LhLxK5T0DH
RXPpINbhPUItdsVhNBIK426+2DiVX6Sg8/L3D3HBb5gRdhTI43a3PXSVRA8VjhIPcnLy7IDnK3M3
NPFuNrNqDDHjaM30Cm3/kcDLidIhX0+KOCS7flZkJTW5LPZvDzb7kS/JOk8oBbk6Knf7Zi8VK/Sl
dhAS+XHFNLVXKzP9OjbFPwBY9fCkIgMZY9lAJta7i1bvIrfweuRsITldHzmJN27fj3llRXJPPdjq
DXIIDvlrM1Sbh2/ZMPSfDtlNfSDdKeC4+xHACMDSDPNnHAPgC4BTXdefQo3velYVXpQ1aO81a7XB
jZGgCDHHmRZK8/MZO7afeRYu/Xfbnsc2JuLNBneth9dtcc8U9noFXxIrgI/W7QOqRk7CIg8vn3mL
SSBRc1QbPhaYDlkVeLiI43jGDfi3KHJ9YTmc+vMjIvPFNU9o9DiJG5HFR29tkZGnT7UDOBVXIPMb
VFFc4DJRKJXdF0OEgqf+mINwIsBsv8a7W7N1is8UCICKCm9fWrF6IMlCnYPE6lqzjYS/cXLOB3pa
BBnQDFnjmUyVArHvlfmPoze9lLj5RXrFqtGdmHn2JQ8K3zpNLsDJgaTWSA95am8a9LgcNA7FG3Nd
sm7sDDXenwqpSHrxme7fmoDfUHbVO3fvskowBQ/yBlNYDcBa3+BbIMBaDa/iQg/pSC5DM5tu5tty
N45sDZto5C4Ft1tS0GBnkBThHXMjOFnOBQDvjjHADpoPi3pjKy9eVoJDWtrK2OWwt0J9f3rW8PDN
iy/y+JqiKBuyKALMImPUlDu8Ybq3onivoqBQCFMe8fM3fwKWNnZds9ok81drLOCmDrJk8puvE6ST
F8NKLUkoQXBvB3C7W/vG+HsBvPrIKAlId8nniTAe6zpHkDH/kHOralKDbNT1bbqbS9Lw69Dnl9Rl
gcNxSNptRxP3eLHDVTidIvlSAbwNqnu0useohMd+KZq1GLH9wk/1vNF5wRx8q4IYt1yER/vA7YQv
bk7eCpuESGBxI8+Lx5vQISZYR4QyhaVpyJvC8VvJwpyUBBwSJYI5yfzJylevopkHi1pi3gDqDhSA
NiejB/v7f/ZnSS31PlujGu+XINIbkZFrarks/HvrPfho7zh49TDbJPwFbTT30tqdL30o3h0cDYBd
rpVc2coyPwt0N4W2moZYRSwdDO0hWfWjnrHrrHyXwuzGrgslzLrbQ9e08UCGDfNE3+3+DPoxZJX1
kZD/odqsSgSt1JCm1WMiPzWR1VC32ea51dWg2d1nzXx91s1WMHFK7ffHnFr5ZM/iIm5lZRnnfYCN
YzaPXiNpXnerY/cbZC30CoBSywLbgq6SBRZ7cFuhcLTPIZcjHHi5HPtZFvxa5zenYXs/MODfK/Lj
ZN3TDe9vIZzvjHNSDzm/JoBROKDTGzVEDE3/Z14JnJJLfBeVpWDp4V0k87RHIp4nnLusfjwP23wu
OOQCIsKcOCMhvBY9vFDVzRyTx7vSkUQOsuIg1rzj0BI6Do4zbbhXsAJ1uys6uZ52oqyn5/pLq/rC
/Xy7wty+TWOx6wfBzLuJyQ8p21wS0GY4NoMn7N6ZTfh/IBRDJO9tOdG55PdbideBPdXemOIRrv4a
7dnDT9QbkXT3IM+XFdozZLnJ45Oo5Fcx4xJdaCDDJI424BxPl7FnKQ31cpDpcvXbnRLw9p2FL5fJ
XNKbkBmNMa9DYpGpYtnj8TGzdzd3VPnZd/ndoU8p4Zny+uCn5hRL5P8pK5RfP1JIJFKJL8/X4ZZh
s/11aVILTMDt5BbTDdhUDDIX8eDxOXKJc5hBMB6bLPORYl5HMhDzKlHF9vMj9zd9HXndl9aN11ub
ufMx2JXzXP+LXbOQDcBSIAVDUDSoKgaLRgLhhCxkICoYwaKDgcjedjSZDKIDoaDKc4yZjKYTodTl
HRYIDEdToIDScxAbTqYzQKYFBINCIVCxjDogWxQczYbzuZTkKRqORcORQLhAQRAaDyYjlFxAYzke
TgdDeIDmeTmdDKbRSXSoSpsDZ8ZTwdDkYTGdJdG4yYo7KzeZpQb42IDuaDSbIyczTMDYLbHZbPPj
oYTcZTedaAeRAYTsb4uaTcZ41HL4bzlX6Zh7MRSoDRqNhkLhoMBqIBsMxcMhuNhAMxqLhwOBALRm
NhcMRnupLphlvhpRxAMhyN4VwZeDTNBiFpReRtpOyoZgaMdTuRAMO+IO5uN0NRuMRdwRoIOOLhv6
yobe2IDODfBD/tDjvERvNIG0gGiiBqAgDWVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNPDwNL1By
b2NTZXQgWy9QREYgL1RleHQgXQ0vRm9udCA8PA0vRjIgNSAwIFINL0Y2IDcgMCBSDS9GMTAgOSAw
IFINL0YxOCAyNyAwIFINL0YyNCAzNiAwIFINL0YyNyA0MCAwIFINPj4NL0V4dEdTdGF0ZSA8PA0v
R1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0vR1M0IDE1IDAgUg0+Pg0+Pg1lbmRvYmoNNDIgMCBvYmoN
PDwNL0xlbmd0aCA4MjkxDS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeR
ymMoGcxARSwDRiMxcOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLR
uNRiLhsNBAcjLMJFM5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKgawbN5+NKEMhmN43
N5tW6AIBaMhiNZ1FqJRplJJrHzMKoleKCILZbhncBrchqMqtdRjORzcL3gYKVAaLyNDIEVJTbBdX
LDhopXKzUxsNaEN9AMxtVipH6hBBhVJ9FioY6fVBlixAVDuDRQSTcdDKZzkaToeRAQTcZBAKSoag
bObuM4sLdqOBhGN+RAaWxQTjebhaUjKcDqZDSYToafKICuKRntRkKOUaOiXSoSgaFqKBo7jsu27o
bu+3YYJ9A7cwS3rcOCFAiDSM7lDCNgQCnCg3PcOqiDm6TqByoCrNHEbXhAGgYJCiysLwGqqt+j7t
N4rDft0/CHDmNI2jSNgwjlEIGrc1iLRNEkUhnEYYBzFq7hdGDYNlG6nt/CIuBmu0hRPEqyBBLkUh
otwaBkoUXShGLYv+2oYTahkGzY3sGOC8Q0jMEA6DQMs8DkMI3DnHo6OM6EsBkGSiDaMI0vMFL+P8
FqcxgG7Hp+yIZBzBEaTaGDOt08QyDKOVChmEAuBQ9gzjKOY6C4FKWodPM9jmMI2z2MNYT0poyjuN
g80a/oGiowVNU43DdTiuDgOEMcLjGOsf0HUss0OMtE0XUFRSzUlTVRVVWBSFk8T1IVhTWqgYBpTE
4N431lPFWo51nVIQDRW6mjeOgQDEMoyjcEELuNIIYtqGYUDKMgXV+/wiswsQYrusgXTFLwlyqJUv
DUECJpiO+NKgJoQC2LqoDI6sVoqiwateFwbr+s6sYlUmVBtliapOKbLsyIyrM6lMwSPFEVRYmwbI
oqspQdAUrPDCUKQtDFFuM5DlOYNKHDCEFUaeEEdjPDg6Q8FOaBrg2E0dnTON+lKoBan+WhpUgqPB
ZE56Y9FajbfY5XFPY4OSOwwjG5m/BSjQaBQN4xDZaoQDeM2FSrtoXUtdTwPFQoZa6N1FjPUd/qVV
V5T2MTmX6MeBJ/go8jg943DOlo6chcoUDu/O+a5ftsBOh2/DTwDjBANYyjyH4QCRW40c5cjBPEOY
3jYO1VXFqwQcIwnEcVaoXBA4lVjKMLoccEF+hTMYUBb2TBBR0/V9b19Y9BeIw3n2s89uOfc1D3fl
wdZM6Aod679PbwjmL2aw5pDrAj7MGXCG0N62A3Ppf63U8T7HWBvOQGEOAaDmL1VwrJ/Le3TMCKmf
d9sEjxPwXg6JrKFFvAgfqfp5JDg3t7T03t3oKUngxfPCgFEAngvDcKVMG4KHtoaDcGNPb8EgvXDK
GMNIcA0r9Xyhd5zjQxApRfD1s65YUqKT+7eFb809qLX+v6EcOmCAofaweCSyEINMDM8g+C/lTKzV
8ThKAKFwhECKFMFsI42hkVauFWMEYuvqPKr125RIoRSipDBHyGF6vRkahQNDsTprBME3Rpa73Qxk
TwG9ejyIznQDGG8NocEgRqI2waST9lYwSBQ/g57+iHRjXmt1Va4Q7vJDGfpqz/FPqhd8wdfRzFQO
ni1Ht9rnH7whf3IlpjWg6IXa4huBLYo9q2OfFia6i5oSzmpLWaUuZQy7hcqthMm22NuMi3E8CxCf
JUjhJ8FAVIbhlDNDUMq4WsTWmxAhsCQSNH3jKQ5UD6GzzvcmmRyq5k2rpnsuyCgKEsGuDdMgOkpF
9ufl0nuXi+Y0lZJ1Gx1kbpqHihi/dDcuFSzmluHJ3arXqt/PdAOIQOQbRGchQ5t88mmITQrNdqBx
TjnJOWq98aqwwuKasno6CeWBHWcQHUM4aKfl0UrRBBB4qAtOqNNlr02y3Nkn/DCYB+g6ubDiHUMq
vZaOne+cYhwZQ8B0T61k9zWJ+t7axSFcR7n+T3WUfhUBxQ00ZBs9JPx0Awh1kOe9ZldqXNeVDYWi
zSwUWPjFOmkVfXtpCQAzQ14NkDmJI2YlN7lp8q5Dq/hxqdz1VQDHEF0sSUgojcPM8+KzA2BsRBQ2
rlD1LqZTYm0GtFQYGOnxX8FJdSZ09oEhigiHrHTfiUHI99jLKqqbMsBcqxLm3MTlPifSqolhveeQ
6ulOSW1Iamct8pGgcR8jOviG8tFEhqhqCAM1bQyK0ipNiVMqzyyRcc/xYhibzWonxXGJ9ejyhptu
/hZ1So8tktHESfMOkyUnT6ew955ZsK1TzNwHMXLxLDuTc5ddzV2v/gfDRO63qnhsqi8q6TZGo1Ja
pDAN6zzoL7gleRN6OKOggDs1YOqF5GV4VootWzWQ3rOVqcWUb/IfzGDMcxPJ7nYAgcXUVHlOZGFE
b9eqpAZMGXJU4lSsD1UgWUWekBPiflZhjxKG57YRr/5SlW4sFmR84ZJaYHnIeQsiFdfA5+VJxU+5
8lGftYFJmlFQblRJgZsEcL9Dndi0mmDs1duPptTTA0GKeBRLMupqVT5XDrll2Or6rKLDGGw9cbtX
09yhdEx2Pg3V/UTn3Qy57yoNBQUQM6QD2Ouc+HMOET7FgzNdbfMs2K9Z6cDn2dp1HZ6Ab3dWsjX7
sKwlJFaUi1jixgmJACnDgnyojvuuGDzydoPUtiwd7dRGtwIoZi2iSbVOtMoLY64UpF+45yqrWYKf
mrBtBBcBxdkNjqb0QqesWBlQ3d2sDa7+3wGsMOqicizcDag1LgR8u5eGlcoSgXBm7OTNM8bUA1n6
XkwLpKBycxxoUyoy4HnHGKZW6goeOHPfDr7PWCpGiCTZmm0mecjPBuFyNkaIk8u4FAQZS9KqY1jA
4cHFh4XDgkFodwwq+JnvUpR7g0cBP9Q5yiCGDbFwtNjAMSc+2DXyUQMgdYlNXfi+iTcXpayifEn4
5ji3XSy3SCCtoaa31pBiDYGHcpOdD4KeIMRyqY4Yux18/SFwzw1PyG2m1/ysg4Bb592M5VTBSCn1
4JoRDDAgBMCD25NvSTQ9MG/w24MXdZSpsv1Ic6bdOnWHR7d6WuYEs0m68wNV1P/sE7W4K/w2dqDy
Q7e+lX4KzVrG9c4NNPQTs5SEFtI8mIXrhEcN64U7Pjeiv7BP07mrqWOjUoTrj2C+Kz5+ReZ6i6Jh
5lh9Zep1xg6QxcaahYgrK8yi75hVJVaST7bh8BhrJPrvCbhw7zS8a5K5ZBqCrKCPI1Cny6QnKnq9
LYAG4iinqWxbEF5tyzo58F8FjVpca6UFKRyKKKY4ri7gj6o2B/576YJ6pULYh+7Aj0jiaVQ9Sa8E
J5jVqOpxpfyFS0B7YJJO5+D8Jvz4RyAjovI3wtoio7o2CebQ747wLwcJpWr97XRPav5fS/TOi7iK
YObQqdy4rurTY/BfMMJ6KD7KzLCSKDxe5fJfZ8jw8KpgBUKZBC48p95XL7zeYiqnw2qIrSzua4qo
LrBTbgrpCOjfLwg9gMy7xZ5fLSKJR1jACGpITuirzTa5JJT6r/5CJRINxwYMoN7si9bySmapw557
brxHZHpH5IMRxBJTjrQ3jq7rkMLwcPY6InkTLfY6CMzsayRUMKANoNrycKjgbay8wHMXJpiyqOoh
0OqZZ8BVTQourEJw7tREEeRmg+5wTXLCzYAtSV7wCtscZYgu0CcIyapPzeUeRw6YKJ4NbHgGQpCj
AFAIYKQIZVpQoGJrD7zSp6I5MgUNjorGY4TL7vytTMT8aELPJP5QJQbd8eskxfKJjaiSDLSRwMqY
5hA+QFIGQkkQKrUCDODzsiciqgCFqorE60CpjSJHZbClTgSFKjzKsjrxpIBeYNzWZvSLQjTFcYx3
CmaWgO7IYNg6A9jJpUEksZUq0rEbx0hf7LhQDKEb0q5vMbxbh3xqyGqmyzx4Q9LN74zZUsoNLZ51
6to95DDKEksl5xYMxfMl4MMv0UTOTZZaqMEGgm40KIw35XJREysbyz0wJ5xIMoEv5HEsLRqj7bcl
Y5RaLJcmSR8IKTT4hpiX6Uk00sZ8YPCJ8bsOCkUu5HY8qWkaZ0LSp/CMsLxXL8hPczha6zMZjVI1
UyQO8A4vA+5e0xb5x7k46JZPs1RQSZCgxiTu8zs0TgSwx/6zx+C4BZxaE78D88U5hvYO8SJvkIbZ
L/rGTo85MB05Umc2CGCAxeK7CqZes2LzcHZPawReo6ANxfBfRfhf0SDwBrJDz4dAycZXM1JQBq03
7P0WUT6eMUMIkEsiY8sVxsEE8TDFbe0Up156j8b6S4hyUP48CxB77P5Cj0YoSSa2Lbayx+AKc3Qo
kyD6jZTpI/RIQqYxo7BLzVBZD/hpgIINj06pQNANsfoqaHhUwKYJAIJVphMeQn4+4JwFIGBxCygM
tK5ycHawkeVLCzr2JYAupKAtjUq4yiK8koR2I3szCrVPbFdNAyAxBg0nanqCIxxU7YEy4+58UL9F
im7K50KX1AhV8+puJHE65IRIknhLwqBMBMsTY1wEBaY0L9DoTTRY6zkjBLZJBoAqxMpEbYNURQ1U
hpDJD6ro9Bjt87yGwN5joNkSkAZ0VTJllTdVowzn5LNUUBAHJNJKZOFVJLIGNVZFFYwtgnInAiwj
gn9ZlWskE+687rh6hrFaQxtNTzD170BzE5amcOSuBzzikpxR47YHC49GUWlGiwMpKkcYwNhPLIar
L38U0yAxzgpNgxozs89RMTIpVhTFYOthS+4MdiAFCrQuovDFYpSfzYDawoCWsX6GayinLNwupS8z
DYpPTvEcc80dJC9jbD04ReLYAHAig+7MJf1X7aE0COs/YrrUNfpyDkikw1Iq5AIjNUQvAHA7K1Vp
IroBo7BghlowwmYjIqwwAwQIQzDmpjTm6k1pg0droi1koHE6AGk6g3DlggZKtZ6w4HBITkgKIlQl
glwBotgqdegtZLIqlvAtIGJA4upTjnohgvY1xydodsovIpQBoK4FQpovgkYmhlKPQrQnwoAoQvZj
Yo4vwj1xVxoqArYqZGIrArQrgvYr5KosS5Yst05LwgRioqBi4qBjI2oGxTBjokIwpkBkRkggog4h
IKZUgM4hwiFuhGAiroIGIHIn43wiZStqJtpALlVpoIVpwHFbd495JKBA79A0N5Krl6C5Yvd6ZMi+
wtRjV7F5d797xiV6N8N1Y2oHKnhLwsw3on5JgiwyIwlsdo40Kepto61st6VugHBmgHNo1/Dnq5a1
QyYgV/yh98Aot6YGd7Y15UmA4G1/WBV/oyOB2AJFS0wHOCtw+C+BNi+DV/+B4go3d+BLt99+N1QG
jy4oBJoi42pMS5eGOApSmE+ANrBnV+7m5mgrdTgECg9bJJgqggQjtbYzpKdr54NtTVgJqUJwqPYM
66LelQYnhSblIFBgZNpLBh4GByAzRgdrbqgFq0wxOBhF+GBBhuazgLMWRElvxgjayoQFGMSTbkl2
4oRkF4gnMiAoQu47dquAVJIwuQYioqzmY3uQAG+QV4uAdxI3rl147ngia5Yk43o7d4+SORd4mSuS
FJN/WTQ1QnWR5jWTzMglAwUnmQ+SGQmSd6piQyOVOUeTOARmhTmWGRWVcnlvmQWS7B2TVehKGRGV
Qk4y2HovBJghg0cfAgQxw+2WwnT/4j4FAnwhj2DqA6mIJTA0eItUVwBQ2JNwjGToQFGOKd2OYumO
scsQFaWPQzAxxEZgZTF5hKAoQj+ehyZJhjwxBTGRl2mfue47ojZTGfYG47eCRjwjU6GTWgeexjw0
ooWiAxAnGhufOX2iOfzVWg+VeZQzGZg0RL2aFqWQGjBh4jQjGaw4WbNt2eZld2mQV5ByYhmhN5V4
40AyeVZnA2t5Gb5iOoF+VuhopKAHGguimSeR4oC45gepWTRSY0Ly+idUlqWld2hj10GSUiGrBTF+
AmI3WrplmrN84hmqOr2IlWEcsiGAmqgHGi+k+ppTGuAjYi2sWowm+umuOiB1JFeImuI3q3iimpAn
Wtj6xiSimszid4mwer7emX2xAtWgurdVxmA+uCpk8c4w2vOpGquzY3QMRnOb2IecNgg2y5eEGasE
mJt1mJ8UjpWmGourAoQxZmuSeC+sgoVmeaunu2e3WIlmmfWootxFeul0GgO35Se3eD+X2hRiWz2Y
uf2iG2m4O3uZOVpleCRTGgd8unByeIWpkiG32ZYqmkgqGk2tpKGzegZJm1g4Ty+PI6gzWH7qm0mc
FxBORiWv7ngGF/RNTroIQIaP22RLJMeWoiZw24fA2WmQRJWg4hhLIjQjpnhFVwuBNkoiee/Czy65
Y3TaxNg03DlofEGRXBxEZJXCI+vExjQ7GxOxnEuAfBxMeuFUXFeZvFuIJiBLOesW4ifHXD1p0nhy
eSXH5mvDHA/Ge6C1MiHBvFvBWxglOO2U+e/F271p1jkiHKvFArjawnJBWJPEeBK1SiZjXMXGGDJA
4yOn/Elwg1nLfCHG2IOp3KwoXD/N3OnGi1PNPHPI/G2ZhdHPplvIPLw22cvIHG1mmIQifPXRPKnJ
/F43XKXB4yPB3KAj7a2et8vDXOPTOqfCvNmBPC2AfDfUPGGGF4wznM+CVJOzfTnFNUTEL63S3SNp
3WXV0M5AS1PVFegznN3HfUerPI3QfNBEd5JnnX/MfTXJXXXG3ZfSF8vSVuguVsur4yRA+fd8+hkc
40JA+RnbQoXbmAuSdZmu3cOD+XBS4yWjHcXb1unco7HcO4XdPcBL/a+kGVuYtZmr6EogWfeusGGr
+4uioBpnGHuMgqBnos+82Z2konWaOYo7i5eAYjeAHAG+O2RS+n86GROSXTEMgtWXmSXb/jfkWQpS
+v2YPHvdPimhXk2X17A+uUWo/enkuVOWO7Fp3kHTeVXj4t3dWagm+XFaIivV2ZHnXn/V2YXofnfl
/nO8vHGZ/h4wyngql+9croPAGbJfQ5WbjkYzHmQ0Oz2fE6HTBdHsWgugG33sJJvtOj/s3HWQW/2j
Qk/tnsezXgmzAnWRHueh9p3s/tuf+j/p+kXhmIekwjnNmmmleVHrQrPAq5t7Ommeum/v5MfQIrI0
uXGnwnV+FTnzuoN+esD9GpOq3j7lOjvvGVYjiIl+Op+qwjkFiihgeytZX2Wx+sPnX25L+nP1eDYo
OumtZUn1hll+OutJfxJNGveu2xhS63mrP44k3d4twjpUn6PqgvHHmtWwxUhS/7K4+xesQyYjf8Gy
GTX8f7X2nq1V2AvImzOpX5xiXYX1W0O0f4u0u/PquEHeW1dU2IYGIgAgNYNFBIMJzNApKhqBpFKg
NGQuG42EB3EANGY2GYuHI4GggGI3HAuGIxGogNsYjUcj0gGw2iQzEBsBpTlUbjsfGMvmMolUjHAx
nQ2HMcGg5mc3lk6Go3FwwG9JGY1osmodFHNHqUrnMumA3mU0MwqBpCh9fpAwEFqkYyHAgjIxp45i
gxjNPGUnKkpFBZhUMGAul9RFuBGeHmRUIkEPF/hsPGY4pwwHNIu0jGkflORyeVkAzougGVwyQuyQ
xkA0wM7k+RoAynWqkg2k5jjA4oo33Wp1e0uA5wI1rV20I50eg4PDyIuzIg23IF3Cywzpw0yWk3O7
u1fk2k186u437vP0unz/c1ulynT6vXzlz6eYj+2M0Y40cG3g+U+0X48DiuOHKNrAurZNY34aME3D
eNm2r7BqwQaNGoTetaujmKEz8AN+mAaQyy7mPm+0Ow+6jmPcHMIPzCbwu60EEhtBbtok8b7QGjLz
xpCyIro8D2qi/ses+/b6Ps174xC/iOtMGTpw20CihsGDUQpBoQNU4LhQZA7bNUuQaqhLbfNUiIZB
vJwXNFK4YTLM8hyTLs2BdMz2ROqMvOjMMZvEk8sOjLU9xrKDBSnHM+N/I7Px/REmSQ5sisCoiKou
w6quarKOKizYarkGQYqRTAcqimibKnTtPhBUNNIxMCn0lC6iJOmipxhV8E1EqVWhhV6NthWVWVPU
Fb1GBqxoxCToqzVMytQzYaOq2FUsmj9SLKh8IMo0a1LUmFPLhZCtBwmAZhovS+J2GDHIdY6ihw0C
QVbcT+JEkkm3gwN5Wrcl23ek18IpTbAo6yyjpIqapBpccZXiilZ1bgd4IiGocV/fbTX7hik2M6iR
hje1/NNgCMInTLLBriWKKkoLozdkF85GmFRYIquD1nemPZNf+NLIswG2w4y16DbrUKnCCJpOk0yo
+vaCU40YxDSOg53UyD8sEG7wS+zSVRhrCQKhNKkX1qwba8GOwXezaeShr6Ry1WeybMGCcWolUeOG
GG3bqjOup1tGxWLnlrrnbWhTnoiiNM4YYpG3Wlr5p2qbtOaqJBT96v5sqnxkGScV+mzDI1oMsrSg
VWKrQG5qNebV2Vs+6KkG6IutKnVWU6kEsPvyI7yincTTclU3a52R9z4Icy+0ebeMj7cTmw64dlE7
UNKyPo9b5qnes56qJJLXqrfhyYXEt/wLgGtsQz53Oploqnwz5DotH7n0o+yrTVz+uv95eSp/GjFr
7sCpuob87A2wYlrANLQ6MEBbS3v+MEaNASc1yggaYttoJqCBkFIOQkhZj0jKNVSsMnyHmBAwftCR
asJiOQohGpmEplCJJaVgikpKHncw0hUA01RuYaK9gqTSFhwIUwwLEWRMic03H3W8Sk1RTmzqgWmU
kmzPWfuFW44dNZESQvNXHBVpgKF0GOgXBiByVyQkcRYTBNi5iCF+g+pFsoIDCvAegYoggTAWgxcl
D1kLOWQwlOWSaQDLybR+XFIVkSHi5JTZmwZX5qkSSKhuSV97JmUSRhlIle8gYjw8kG5Vl0i0TAwM
oxE6LKYhIeUJJSIUpZTlCZpJGUMrnAwJivAxocaGjQ2aTBSCzkGPAgag1KPpsCJQuLs1qEsyAbzK
b/FSHkzpoPaKRE4GSHWPt5Oi3VCSCZnwFdXEIGSPGWzcbfNOcE1Wws7lw4SXUWkJLtZa4wiTXowu
Rg+utCSZUZOXmHNiKCqGPOemkYFM5UVtkSVwWogaHiqktde6uJwMzAzlnEsqV7EiSwBdWDRciaT8
v7c2RSkDuaRv3Lel2kLfFUvJhvS2kb63oUgo49R7Rb6QUXWi+ZLtACWvmiETs0xHYG05l4U85tNC
ZIeWwpemFP6nv2eHUOqdJHexofHUaiayqIEkok7ZEUCGexlaDGdDxMDfQTV9MEBsGC1QaIIQYhBj
gXhGLeagKh9UVMTniUipxHHrLPOYDeN0YkpAtmKY6OqYJhx7gsYsLYKAmhlDmHMMIKW3AoDOCkFq
7QUBlBSF0KgSq3ssLpHSvVkgUBEDTZ2z5ErQhzDpaO0sIC8k4Y+ilGkgm3TKt4eKaVuY1GWuCs0i
D6CnstgmR1X5eTArPuM0Y1BNC8rYuYdVmtybdXTt7J+kFvydXHkE9pQCojmXbMyXJFN47qUxvNeM
nEqpQXiJBeST7Pa7tnJBBavk8IMS7Bmk0khdr7mYKjGEJcxGohzBAFwFAPAQAyMcgkGpMromZaWY
sFB+THFyJKaOOuGsNkEwY1ILgKXJXEOMUgGTYDKEnorfbF5nXP3cuLhPGENiU3XuXi4GCEDqFJuh
YXIGNsiXKKhkA1+Sbu46yReA5aYCP41LnjKUF8cdZNlXexLWVsY3wTTl/IKaViXhTzlXHav1jRWw
A4Zb1FooEiy2kytwKAmB4adicOYPQnB4wHnwxxRVnlRdnhqyIDbJhQBSaAFAYQyBkDSG6ztpLTR1
PEtGyEeAUYQBiC3PcxQ54pckdQoqYMXOdTTcjUxpsv6qBm0RcUM8q6wNQHlGxHDPKfvYd1fVzddv
xeRlg0CEEJJUgmhIsJ9pwWGJADht2FypH3V3fciJ+ViGgJxsHXubHBM+zfFnOKFyREnoxneytlww
hntFB+OplyZabw4GwMulA6BoweCgJepJ9kPq+ZLWpG9YzNouqicvAjUISMwZ7g+qwQa4pA0Y5uvC
Oa+JrKDiV49u3lNmXXZLnaYkwZPs/aOy6QEbBxkHayEczlTIlxPYXFs2uDWzPFbxeZwPoSuxIxJK
bJ4QCSG5qIaQwhsBAHYFMyAaaPDYHUMupNLQgm/mMpB6mDzYnW9kp7B+pwDBAWCNRJ9cSHmR17sB
xssISJhQXr7+pyIJc6UiZ9hczzlauSewzBpvdlcr2cvM7gogNDiA01AaSLl2fwbokesS3sT7hHSw
xcqRhyDL4TlHX16eMJ8FcEAbq39f2oRQG1j0zmj8oA3znnr9BGWjXo+sZ4zJzrz3Y2mVY0puguYK
/tC3gkDjrKZQoVDbGBTZBYO5BAjWvDr5RK4LgQBBBAGiDoIA04ODCc4N4bQ4b0DwCwEAbw3BlBaY
4tUe5750jxZMO4YQ8gpJ4DYFH3g2hh3uGX+YdA0hj6KCAMwdQ3Axv8PwAQN7v6LbLTAqCyAUPKAy
A6gxrLAQPrg2rLLMN2PvgzQIA3A8iZt6gzt7wBg3wIDHQECCP/A0g4unCXAYLFGovvg5CQC3QVg6
CUQJt1gyvnAqA0N2iGQRgULMQJQZt1QKg7g0g2OjOiv1g8sHPpCEQPwBwcwRCyPfpTCkPhLTk2KO
gqPjwegwwfwJQggygQNJN2LaOjuiunPnApg3vvA0wLgyg7N6woAGwpPcDbLJvwLRAWsrAcgULFw8
ldjTAUNJrPMXw9v6xBw/gcAUQvQKQ8MXnxxAmpw/CnQ9gxvpNKAygyAWRBu7AZgULagWxJgUCExQ
COLQwDAGwRwpPgvhi8PjCCRFwawwrXrLQZQhwijnRLQKgyA5QuP6P8uivxoPwRrJg2P2jhE0gUPn
AkwLv6vovpg4A5A3wGQHMHRmwfQwA7QzLROoweAzA3wXAxA3wPA4Awg5P8LLPvAwg3AyPqRaiDgQ
A5rXvwx2AxP2xhCyLJxrN6gyAyg5AUmsRkQ1wZRoA3w3xqwcwwg3gxg6wJA3QZQlxTwRi1QqgUA3
RxJiAyt6wIA2A6R+xMAXHJPeC3mBCPqHPCFPCYsqgaq1M6HOi5CWo9jQvTPKidlxrhLlDriUuZgG
q7i6r/STjTSRoMiItoQXinOcMJpWEUi3vcyfPeCPvfPiJTDRwqviDYDEwtAgg3AQAyg8QuPtwwA3
wLwlg0NJrOt+gGvAiAgNZW5kc3RyZWFtDWVuZG9iag00MyAwIG9iag08PA0vUHJvY1NldCBbL1BE
RiAvVGV4dCBdDS9Gb250IDw8DS9GMiA1IDAgUg0vRjYgNyAwIFINL0Y4IDggMCBSDS9GMTAgOSAw
IFINL0YyNCAzNiAwIFINPj4NL0V4dEdTdGF0ZSA8PA0vR1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0+
Pg0+Pg1lbmRvYmoNNDQgMCBvYmoNPDwNL1R5cGUgL1hPYmplY3QNL1N1YnR5cGUgL0ltYWdlDS9O
YW1lIC9JbTMNL1dpZHRoIDQ4DS9IZWlnaHQgNDgNL0JpdHNQZXJDb21wb25lbnQgOA0vQ29sb3JT
cGFjZSAvRGV2aWNlUkdCDS9MZW5ndGggMTQyOQ0vRmlsdGVyIC9EQ1REZWNvZGUNPj4Nc3RyZWFt
DQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAgGBgYGBggGBggMCAcIDA4KCAgKDhANDQ4NDRARDA4N
DQ4MEQ8SExQTEg8YGBoaGBgjIiIiIycnJycnJycnJycBCQgICQoJCwkJCw4LDQsOEQ4ODg4REw0N
Dg0NExgRDw8PDxEYFhcUFBQXFhoaGBgaGiEhICEhJycnJycnJycnJ//AABEIADAAMAMBIgACEQED
EQH/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEBAQEBAAAAAAAAAAEAAgME
BQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGBFDKRoQcVsUIjwVLR4TMW
YvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUaktFbTVSga8uPzxNTk9GV1
hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6PgpOUlZaXmJmam5ydnp
+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFBBVETYSIGcYGRMqGx8BTB
0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRonZHRVN/Kjs8MoKdPj84SU
pLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhIWGh4iJiouMjY6Pg5SVlp
eYmZqbnJ2en5KjpKWmp6ipqqusra6vr/3QAEAAP/2gAMAwEAAhEDEQA/ADUR2RYH9Audx2Tbb/Wz
GOx7aC4+hP65IoLK1czRPaTScJGVJI3PEDYipMgNd/DBkUiLo5DTGdDzRXJq3AE/CxO9QNt818c4
N2KqJlzvl0cs465G965MVWK1pt5eetP8nr9+YwQmRivl9+g/j798k+kJDZXZtoZFeC5XkpVuYEyA
clBqeqn8MQWGOwuZdQgj4CGThdBSaNE4Dk8fFSeW2HxgBEkVZIl/RpHh7kA9AR52kBth28vyV2/m
/h4YhJZyHpoElPD4/wCmSd7K1a21SMRoY5CshFAQWKE8vnXHwwxXVzbxajGGIQNahgClVFCFr37+
+IzAkCt5VW+3OufwScdAm9hz2f/QkqecPKkbyMmtSokjl2jWCYCp2O5ir28ccfO/kmIr/uRIUuXc
ehN8Ralf2PYZ59Or3Z7J9x/rnV/y10uCfR/03dIkl3NM8VtUbIqUBPfetfozGOnxjci623JLd4sj
1+xns2veW5fSkiu/SMTiRWWJzuvUfZ7g5Y8waCpuFacss1CR6Um1B6f8vthZf215bQNcQ2sNwUBc
xMvAuBu3B6sAfmDgW21fRZYuVzaGCXiDw4GQbmn2lWnXI+HG74R/aK5MuI1VlM49d8vRwyQrcycZ
Qij9zJsFUoP2fbAep+d/KkUcFpNczRTxKjwyiFgfh25Dl8sD2nqX9xMsVrBa2sIHOQrylYkmiqGV
AvQmprjdR0K2uke1ukDQEEEgAMp6chTv3BxGOAFcO3L9KmUud7v/0eK5PfIPnNNHifRL9HNrNIZb
eeIAtFJQcgValVPHIOfq3bmfnQY+zFb23VK/FIgFfdgMiRYKRze0zebrW5jfS9MeSea5Vk9VlKLG
pU82+LflStKDB9j5f0cxf6VCrMsYk/eE1JIFUO47nIjouks+okABW4j7XTfbcZ0Gw0uT0wFn48jt
QVoTEsin4ielKZSN+TadmG3uqf4U1aVGgJ0+8WMSLDuUkH7ScuoqxBFd9s2s+doNGsvUt43nnuAy
26uAEHQlmpvTp2+nJHr/AJZjv4GICsdnXYgjYMorU9OQzmf5lWcdne6ciRrGrQElUAUE8qdskACQ
xJoF/9kNZW5kc3RyZWFtDWVuZG9iag00NSAwIG9iag08PA0vVHlwZSAvWE9iamVjdA0vU3VidHlw
ZSAvSW1hZ2UNL05hbWUgL0ltNA0vV2lkdGggNDgNL0hlaWdodCA0OA0vQml0c1BlckNvbXBvbmVu
dCA4DS9Db2xvclNwYWNlIC9EZXZpY2VSR0INL0xlbmd0aCAxNDI5DS9GaWx0ZXIgL0RDVERlY29k
ZQ0+Pg1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQACAYGBgYGCAYGCAwIBwgMDgoICAoO
EA0NDg0NEBEMDg0NDgwRDxITFBMSDxgYGhoYGCMiIiIjJycnJycnJycnJwEJCAgJCgkLCQkLDgsN
Cw4RDg4ODhETDQ0ODQ0TGBEPDw8PERgWFxQUFBcWGhoYGBoaISEgISEnJycnJycnJycn/8AAEQgA
MAAwAwEiAAIRAQMRAf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEA
AAAAAAAAAQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGh
BxWxQiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNV
KBry4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5
SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNh
IgZxgZEyobHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU3
8qOzwygp0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiI
mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/dAAQAA//aAAwDAQACEQMRAD8ANRHZ
Fgf0C53HZNtv9bMY7HtoLj6E/rkigsrVzNE9pNJwkZUkjc8QNiKkyA138MGRSIujkNMZ0PNFcmrc
AT8LE71A23zXxzg3YqomXO+XRyzjrkb3rkxVYrWm3l560/yev35jBCZGK+X36D+Pv3yT6QkNldm2
hkV4LleSlW5gTIByUGp6qfwxBYY7C5l1CCPgIZOF0FJo0TgOTx8VJ5bYfGAESRVkiX9GkeHuQD0B
HnaQG2Hby/JXb+b+HhiElnIemgSU8Pj/AKZJ3srVrbVIxGhjkKyEUBBYoTy+dcfDDFdXNvFqMYYh
A1qGAKVUUIWvfv74jMCQK3lVb7c65/BJx0Cb2HPZ/9CSp5w8qRvIya1KiSOXaNYJgKnY7mKvbxxx
87+SYiv+5EhS5dx6E3xFqV/Y9hnn06vdnsn3H+udX/LXS4J9H/Td0iSXc0zxW1RsipQE9961+jMY
6fGNyLrbckt3iyPX7Geza95bl9KSK79IxOJFZYnO69R9nuDljzBoKm4VpyyzUJHpSbUHp/y+2Fl/
bXltA1xDaw3BQFzEy8C4G7cHqwB+YOBbbV9Fli5XNoYJeIPDgZBuafaVadcj4cbvhH9orky4jVWU
zj13y9HDJCtzJxlCKP3MmwVSg/Z9sB6n538qRRwWk1zNFPEqPDKIWB+HbkOXywPaepf3EyxWsFra
wgc5CvKViSaKoZUC9CamuN1HQra6R7W6QNAQQSAAynpyFO/cHEY4AVw7cv0qZS53u//R4rk98g+c
00eJ9Ev0c2s0hlt54gC0UlByBVqVU8cg5+rduZ+dBj7MVvbdUr8UiAV92AyJFgpHN7TN5utbmN9L
0x5J5rlWT1WUosalTzb4t+VK0oMH2Pl/RzF/pUKsyxiT94TUkgVQ7juciOi6Sz6iQAFbiPtdN9tx
nQbDS5PTAWfjyO1BWhMSyKfiJ6UplI35Np2Ybe6p/hTVpUaAnT7xYxIsO5SQftJy6irEEV32zaz5
2g0ay9S3jeee4DLbq4AQdCWam9Onb6ckev8AlmO/gYgKx2ddiCNgyitT05DOZ/mVZx2d7pyJGsat
ASVQBQTyp2yQAJDEmgX/2Q1lbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8DS9MZW5ndGggMjc1
OTMNL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0KgAxEBnBpCLAgF5HKYygZzEBFLANGIzFw
4EA3G44FwzGMWNsSikWjEajkWNgNMwNOMSEBpEEgisXjMbjogGo4GguhgtG41GIuGw0EByMswkUz
kogj5XEBuBowi45GQuGA2EA2GM7G9SodFplOqFhnQgqBriUaoQyGY3jc3m1boAgFoyGI1nUWolGm
UkmsfMwqgpUBovI0MgRUlI5oFWsIgxQ2qw1GEbGkMGoyjVBixUj9QggtyYwGA0HIgKhjp9UGQ1G+
mO4NLYoKZpNxjMogMIgMhpM5pOhhNggOe8NxhOh1OQpGOTGYo25phxjonGMpkEBiPIpLpUJVPuU/
GOV0pUIgNFBoMJzNG0M4gOho25tMpzOZhM+3MJu63vMpuFIqDUBoqMA0CqBgnzTNQ0LVvG17nNqO
Q8jgOj2Pc+CujmOo2QoNz2vk+j7DK/8AwGBsCtE0kEtSGDVtaKjXti3b7jmOgQDu3w0Qs244DkNI
7OoEA1jKPIQDeM0dOE4jlBsFAWu07kBMA2IyuSGrFBwFAWNw3TeN84EkjO4rjuStDnOu2gyIc/gQ
DGN7/LsGsmye7sShQOj+joh0jSRD76vu9w3yQ4cwwrI0Ryi2E7QvPsQy1DIxxy97jS3QcxOQ5SKB
k5050Q2IxvyNw3xqMT4jeOzqhAMzkhsF04jeNsijc+L5z8246DfTkSti/NRPhVaphuFAXBAJMjjL
U43Vi27hw6NjbjE30iyOMjjDDXLAPO9M2PRDrqy1NdGT/GT5zzGw0jYNlD10FDdjMM0qNw/VBOI4
1LzK28b3QptRBBU8ejM7IcThYVrvM2batvNw2SJNY5v6Ml4PQhwwjG2z6UBHV1SkFEeR9IEhYCik
mS1UNlBAMo2YdNj8zZMgXBo50gPe6GCxPA4ZxUFFK3qogXUOIrBLEGK6rJl7WqgJbvCUsgQDUECJ
piO+nqgJoQC2LqoDIBrJI21oZhsxTSI8BoZBhr2wZeHKTAaKbAsGIyrMOxLF6YqDHsi5jKhBr67B
wGDNo/mwaxVBYaM3BwiS637g53Mb5twojrjKOk7jlC2WZ+wWuLXvabhcHK+7Js3Oo10G17aITBbv
urHbpze9BmGq7BkzDTI+FA7x7yj+zBSyiDnn0AbewzTJSqAWp+G7w5w8kVxa11EipC44OQOA35VP
bc24MgW9y3072TnblJyGM5O27vjvA8TTPK2PHVjLY4DCOF4DIN4xjq+Q3Rq6GMDqG4NJyifnNSc+
dToKA4h1ZQkQNLEH9hpYAoJh68D8nWR4pgnQKFTQNRFAZOoYQ6n8gep9CibgXwgPeG9HoejjBpTc
qmFRuGNHmXCwlyxuQ6ByPyfUMcJQ3LDUOYQoTciJGTIwZdpjzTYhIDeHdY6VIBFTU0lo9KnC2A0B
oDE0rsQXETBo8x9ruD8L6DWqEO5ynSpZS2953b4V6JjOUWwHKZjsEtTyygMynH0xdfW81BZbkXnm
fs49UKNUeKmVsehGq4FaIhJaQ5H4bIGvBQCYR4hiDvPIBc8qL77FEhXPgsk3JRAxhpDgGlPC0lKB
lfwy45qs0QH3j0d+PgMjxnlj+i5GDuD8rlVuv1KkEEiG5Rkl5xkb1LtQU0bcLgKIKsFfdIpPkjU/
sSX2qMMrvDgOVgxMsMjBY/uHUSsw20Ej9LwUqqg3wXAUrfQuclqD5ZWSmDTAVKCJZcvQSm/sEAdW
HJqPgGlyx0gUqsTihKX4cw8o0DKrBW4OpZyak5GBRIXAZA0cGFKVhwH8BsZkhd+z+H9B0BOQ6Gse
iKmsIFJo8MtpPLsN4uQEEzY6sSPWh2dklETGTYE8qWlE6X0WowCCjUOZUKnSRCpLpxTgw1S4jMOi
h6eUqlpS2W7zpAS7jqxA6VCEKsNmRK5MyNz3sZg8YCfMgTYzpDlSUED1AxSSDGkFIYKQcRXYJAZA
tPaVvJeXJ5wRh0FGqqyeaoTgwhqvfk5FNcpKOIaOodak7wqp0+pZH08rNkUmnqxLqQVMUaMYTXDm
HYbXvqosmiStFhJxIxtBIuaQd1tBqn8jWrhyTFHNoQqhVSr2amhQOQyziCyrSBUUsusIZadV7qpR
Kv7zbNHjsGiw1j0AULFSQHQO6ganLjRpSY4ykJ3IispVWzB5pST0lTGWJtADjUQvLc6TsSgUWHNN
SB+7+ZUzWkK5KbSG4oFZgydVn1Z6K0XcGE8NzC15phigZBVsaqyKRoDQOFQKWBlEns+ilNln1Uuv
oHN6x+kKsdR+neujAS2JxS0m1DR1j0KnmgCg6QZbIpImK4t3rPIBEbOdgVKDQGyAyVYDMhgMwaFs
J62MGYOCKRIyRkotxJ3UGCMI3F4oDXVmNdW7TIuR4sRdKq7Z5zhrrOJN7jpxpyHHhhcibl60Tg5B
mQ0CBzOQ8vt7LXF0jJSgG5NyfkfPYMc+5UbdltpmXciEb0FoG4pH590EeQWy3SE4XLJVuG8NmQDu
yWaflmPdQI/Wsn0CjNExsdxwVYzDNrkZ/Kov6wphiuIDR7qtJ6tKDoUShQpCSWCtQ5paDFCE3DKV
Aq3hmruEOvA06+relUoEGgzw6Vgm1iCRXLLUN/jMLgM2vrOvcjXGKz5srJfsHfBYbwwsQOsqo5UU
oNBtt+gaJFw7CINPNKOhqollhvOQbZLUp4e5s2CUqDZ8wWKHI6q2Tjeyf5JBtcKzNwLN3TefWpdk
OkbodDnt1svHgYH5DyzNDrl0aqfWSqSp8ATwxdfMlDW1533BpD0qiZoU5sggCMbxS9BkzF2nYCDU
+al6AprxhuA7jjoss5Vq8/agYL4rg1UhSSNTcptTfhHpE+NSXGtJD3Z6x4XT+wZOnGC2r+qkP7sm
Z2ACiBkiovKX5ttoMwQpBE31DSHKPRzFXAzgrhGoU8lRCm3Wv6+4LjU3fVmK7+f3wXaEr3rByTzv
NFF0rO6lgqkU/jlg1poT0tNxSXzaBmwvgJTQbQw9bWxD6nWobnxh6Gl/Naq2XnOYnsZyBt1/JE1f
nRdOtbzYg4nvR5nFrioO9M5Y/vy5S8lKJAmgSqA5Iacf8tNir0nPCRLYFFRsX5IUWhJIOiRMJpbP
QcnSi7LZORhiHNI12s3QdnugTinmNcnmoVQwNqwwjIYgyg8Awg2g4FnEtIIEtg7IOA3gWgzwBryL
VFEvVA3A6gzGKHHHLLZPHmMPVEhDhF7MfJEjjMZmSk2wCHJkKwJwKwLwQNWA5OPAaoBIBmdCBwHg
5sZl8jgrtg5A1n4E1vDAbKCsIg5LQwVQLOBtoE4kqKSsZwHD5K3qPA8sHicmRo7OVnFuyjiPcvgv
6qsJxJnA4JDlTjrQnM2l5JrE1wCgwwpDkvuLVrqLPFPD4AxwevsQ0vbFXH6HLPasMMIrlMZgrgUg
ZgYAUEcN/LYD4j8wVwkK7PbwliHMTDqMZmQK7KeI1Q0qBEgQTH5A3EiOUL+wOv6E6GNuRQakPuTF
zF9P1MIn/wfJpQ1DsmBvWKdt6ChLOEpkqrcq8sgnNOIi2iriKMkiLIuAcCLAWxiC8Ciosi7Ijs9D
FDJCrC/DAHUm3ssJMMBRinWRsCLKVCKosAQMklWnACWCCCoLhrrAcs7jGjJiGCykTAaxwi0s9nYx
uC4DLirC5uWgci3C8jWCNC6nBxwi3RpDvKeAbGcKeKLmmCzHDJNirAbCfC2iLC6jFAYx8GhicqMD
Wi8i/m3DCCaoiGhiqChDGyRDRirx2M+uIicjJHmCPiBDPrgAYLBHnCetSggwrvaLkpHoZPhC5rAS
ZPAwJJqDbrvLYFJmJPLDRSaAUO1Fkj+qukJlUI6j+IZmbEWPvmOEesTjbmQJVKwMHEqiNFNNOAGs
hCxMmmigcySEggGyGgamcDVqDHaAQHaLcq+iNCMSNiiiOxmRvnZSxyDs/SOxqMrtPxripxsySzEx
uCckDy6osiKysDODUssS0ChCzSryaHCrhEHScPajbuUHJDcQwpJFUJfuROSD2scjgM7goiVCWCXS
3CNS4S6pbHPmiAZgcxgzdjvsIIvy9mySIFWzeqLifm/CGClgVCmi9CRiaRuCcCxieSIigiuzmikH
QivjvCtipsxisCtCuC8ztCDCECFGcAziHCITYNFgcgbjIHWMkCaHai1CSMkmcDliSE2CPghAkjBi
mAZAbjBgkHOjBghAoAhgQAcDBghgpiEAiOxDbAjodA8gGgkgiAQB/0M0NB6BohfhYBZBRhVBWhdh
khZhbhkBfh10NUV0NB9h4hlhbhYBaBQBPBTBVBMhKhJBLhPhRhhhrB/UWUNBuBkBNBeBbBOBN0aB
MhKUcBIhEhNhOhV0VUghzBeBShMhVhPBOhMhQBPg+BUhSBLBIhLBFhMhNBSB0UWB+hjBVBNhQhNh
NBUBcBYBUhShOhJhT0oBChHhKhQBah6UVh0hehPhUhLhQhOBMhLBKhShSBRBQBLBMUxhFhKBGBMh
Yh+0Mh4hjhVBQhYBEBSBHBGhJBJBNhXBTBLhOBPhLhEg9hMBGhKhNhxB/h6B2hbBXBRBP1IBJBQh
DBKBOhMBSBThAhSBJBDhHhEBDhLBHhZh+h4BihXhRBMhRhOBLhKhMBKhGBIBSBQBGhBhQhJhDhGh
Cg7BChJhSh1B9hWhWhRhLhGhOBMVv0tBRBNhRBNBJBBBKBEA709hHBEBQhqBvBdhfVrBLhPBNBNh
UBWBWhTVFhPhMBJ18hGBLBRhEg/hAhchnBTBJhMhIhJhRBKBRBTBZBdBWBchJhQBSBMhFBHBMBFB
NhKhCBHhqhvhHhQBQhUVIBSBUhaBOhUBQhNBBhFBMBHWThOhShFA/BHhZBgBihQBOBJA/hMVqBYh
OhZBOhIBIBJBFhSBJhLBQBGBIhGBHBBBEhmBvBBhIhKBGhLBMhMBNhABGBDBIhIhTBDBFhWBJVrB
IBCUaBLhhhhBLBDhJA+WwBNg/W1hQhKBR1rhDhFhQhHBIhHU8g/BEBhBuhKhFBOBFBGhJhJBAhCh
UBGhDBJVXhK1813hQBCBGhbBGBhBshL1jBF1RBGg/BIBThFBGBPhNhLBIBLBGhPBGg/g+BJA8BIh
gBmBUW1A9hFhL3IhQ2PhFhHhVBPBLhF3OhPBCg9BNhBBIhchthHBKhFhEhBBAhJhEBJBMBBBHBJB
MhXhHhU28hSBEhMhBA+hHhlhkBQBIhAhH231QhABEBMVlBAhD3cBRhThH08g6BDg9BfBwhKg8hIU
lg8BPhEBJhMBO3KBEhHBCBNhVhFhIhFBWhEA+BFBWBmhRA9BNBABOA8BGhP24hDBThHA9A7BHhDB
ChWhLg6hChGBChFBlBoWjhKhChK0+1XBGhQBJhEhIImhEhAg9BMBBhDBGhGhIhZBzhKBFA4hGBPB
RBK0xhLVhhVhAhHA/hEWjhCV5hNhGhDhYhkBhhVBTWbBHhFBQYqBIg+2OBChBhN1XXRhRhRBPBXh
aB8hqhchVBS0u0xBPhKYABGBKBAhGhEhEhABABDhOBSBBg8hsh5hzhYBHhOhNhFhOWvhQhEhEBNB
LBOhQBVhKBF3BBFA8W4hsh/BxBZ2OBS0dhTZYBCA/hKhHhRhGhGBJg+BM0kBUBIhkh9B9hYhZ1cW
e0aVVZKY6hDBRBWBDhHBQhBBLhDA8hZB9B/Uhhd1pBQhShLBLBN51BKhEBIBBBXXR3fUoBjhy0gB
xhehVhTBThPBPhSBfhMhP1cZ0ZS5WBNBRhbU5h8UMh8BdBSBPhX6IBVBThXBPhXBQUdU4UzZSBfB
pB80WB0W/hkBiBdBWhWBYBGUwhUWjBXBdBdBfhvh20gB/h/aaB+B1BwhyBxB4B/B9B4h3B6h1BwB
vh4B7h6h76aakB/SzT+zXzXiViBTZNvErnYmntFmvjSiPskDQm9CssimwRnHPyTiJnkkEUKHYify
Zz7mypNmhgQCT6tIuyJgYDHqfa3gaDJyQC6pNpO63m/idNvGn69Ab6+M/6/C1a1avDS63zdCgHa6
uiN6v6pCK6qbH6rl+gGztR1yFiCiDiEgpzzz0iIxBzA65a6CBDJgcirHaCqRkiUEViJm6kDDGS2x
BjFMiT765igKfbUbVTu7WnjLCbYyZ7T7aDlidC3Dl7TS1be7WTrbgAYS0ixSZmj7iifjV7cblbeT
bbmyOEVnB7pS6R3COIpMzbk7dbTnP7mG/7nEVzBbwCLbxJlJO7zAbbd707t717ujQybbpMkbNiOC
cz6Gp7s777V78ii7nzFGi7oDS74nZsjcB7z7l78bfjU7iat7v7ilWHaDW76b7bU8Kb2a8bYbpcMi
zCOC2HaDDbc7670cQcDcK68DV7hAa7Z8TuFi6cO8WcP71cYou7o8FuI7/otCdCs8I8W8J8YcRIu8
MjQ767/61my8dcCcX7fclyLSEcFgb8s8Ti6CdSscPcXce8r7+ctb4babVotcp8Jbtclb9a48zjQi
ccoCKItcV8qcx83x28F8G80HyK78j8ecQ89cSc+cTM/jV64iBcw8k8rc9cZmhSZ8oFWNCG48d8xd
B8EDU8BdI8bdEC2NCdF9L9G7udNR2cmou8jbxDMIuz39Gc29HdTCdb3Gimh8z8uyKisdA9Mc3dZU
AdUCs8uM/xB8mdLc8dM7XR2cFcZc+8TiOcmdRdj9e9kiN7Yovb/sjI+djc2cC9Y9qCOcs68S2dnc
6os9d9ScD9v9IdagadPNvHyGv9z9YdS9v8ga8EEbxIuax95du96bgaqGhLq989KMid+cq9/DUmv9
w9W899ndQc79ueD909/8y68Abdb9hx/midX9++J+E9ls+dx9hyK9o+I889ZS2a8Ct7/67sxHB+Oe
JcfIs+Fy++WDweDeT9qDK9gdms/jKiqR9+cdkbgIv84ou8QbxIv+gehdp+idUGy+G+fTHGBemdve
idaR2HR+ki7b1+Yec+ieK8i9hMkFWGzeX9R95+PDJnDejC6eMMoiqav+vehjU+nyFekiNCqoh+0e
O8fCfeFi1eWDFEDjS+5+m+691x2eAbaGuED+99perAG6nTYiXy3y4zbnQHBzdTeGcHkTfnOC8siE
4TizIzkM/ArzlinGoCji+TocAi5Ceifzqi8/Vi9zn/TzmCoTue4ir8jCeTwivfcxtAQGkioGlioG
nDJnZCGGpCQzqmqmrms7OTy7PiGiH7RbGMneX6rav6s+WjRjDfuIt7GAc6xdn/YgQazSI606qoja
267a8bS8Jf4a47Ay/Gca+yx7AGh/763bCgcCAC4ZDMZiAYjIbC4ZjYciA2A2CDkXDYZDiDQiFQwQ
REXDgZjWLwmFw07A05g0og04g0YiA0iCIDkYi4bwOLjWOjEbiA2zGZjmCwecDidRuZTQcjKDDOZj
Ecw08g0aDAZC4cjCWwcYC4YjWGw8Z0kXDAbRYYjCJDGnQ6Y1WyWau1yZWwZjet0QbQa406W2C7Tm
80KczuwUcajHAjKh0WwzOa0HFYMQSUriA3A0YCDM5sQGsGkIsCAXkcpwUznMQEUsRC/jiKQa0Vy1
1sc3kZW6LHIyg0zZjNWOK7+qTvM566zPXDTYWnZ1bbbgQbreb6tjAa3nqjWC8XWVXXTuz8yG7Tn2
Pc7ve5vzcrqxbuXUZx2NeHZePnCDb+bo+jqbKlK2s7iM61gaI6mrlvq37avw6DpPS34YvYriCM1A
a6qGG7lPotT7QW/IYPO6b1MQ9yuOxCwboSHAbvA2MOQU8sQP3EUIQXAEVwq40WI6s0XObD0Gv49T
bwkGUIxy1gcR4pUNx/GMQwerbFP+gT2RQiQcBwkEmw7J8ZyigUSoRATjBwu8cS5GEGP1Bz+hnGUp
BzK0yuQhs0vJNcZTa9SCJArYZv/CwcO8oEERfPEPyhNwbO2hQaTIiCPI6HMtx9Ls80VPi5z/DMkB
mHEChwHMevFNVEy+/oaObOdIpxO1LVNIMaK2GlHt+GgZUhT6EquoNYURWUwUfPwXBoGtWU+G6rLJ
Q0nUxVD1BqGFGho91BSUq9SQTYE2SE37tJardpV1USrLVZtL1PPdvq9b4Z2Qq9zV9UtuT1b1xRxc
QbXDCyjpkwNfvvdV7omrtv3zfqqplbVD4FYL+hsGlG33eD4qSrOAyBbtZomG9wonVVPTkqwZQ1jM
vXWraGPsGwbV1SmSYBemHY3MCauIic5ZFXgZVfmeNXtjgbhrYia344wc2UoGMZ/lGCBujzfwzl9s
XfdFY5q/qiY/Fl4IkoEW6bZ+Uo6sLfzNo6pBg2mzTvmmgzA7+z1zJCpp/XGr3rRSUpWlqXqlJTtQ
Zr+DLC+IaUKFrEITiSdukhCcK8guSuQqieAaK4VMslj4otFklKYiwa1AgQQBboaZ4jGYY86EHPoU
GKLJ6yrLsyG6xWZfaldOpMZ9o6kKpaJbfCVCo1XYpQ7o2+TlCaEAti6zIyM+0LRtKEDTtS1bGpom
zBKInae+5QvvsYo/byYpi5KhtWFKwi8AXawq3LLq/5rH+q1Jwvi6NaxBen9lzL8Xd/75TCE+BcYc
xJiydvcMeTcyRJSTnqbkXduhmXhp/WMCB5TnXVPOKkXF97rElA2MO5dVROIRqfKsXUEEKUqvpLSR
qGANTgushmQ0McITFoaLCiYhqqiEgwg3CSFpO4hFjiLCyExLYdxJiIluFhCyQQwKJD5JTrDlQ1hv
CyLQIInlxZK+mLLVoYQrdBCaF8IisxMhPDsNEIUCg3as6xZTrCCk9VVHOOpdVilrj2c4wMfomxrJ
wlMpaypCxhcip+RJE4TwwRSnaPyqoglxknI+PEYIeE0PmQsjqtoayOdYQlfZeYYSIlKwUvMYUCm1
kHKZ/8gY6Q+RVKJCJNI+x3QpHAqRAyJwrJ+yWFEwAbQrKqkaF8wCPFBUAsVkKuEClqLNM9WsTpfo
FKnD4qs15loFUZIOZJLZpETIWUuYZyonslnNIN1MjpyzbnQsVZk5ZqTzKnK2X7nUKOsJnPmZZ8Zj
xtneRZXFAphMknUA2OKuCZmKikmchsekjECaJPMnUVaKrVPA+qgFDiaIHn9PSfSuC3OjnxPU/LPa
MNDmXMmSlEpOUmIFTGYJBaaHWmqpyclFUWPpp5TOjaaE3kKY9Muh9F3WMqWnUii1EUeQ6oZCFZRH
pKEzhPHonTZarlIlQ7EsdR3WFuboqp0ANaO1kJ3GGErEil1qjWkpFcPjHILrMgaukCZsV3rnPNIl
cWQTONo72u5H6O2DKVWysMbbERrqq219Vf1VWPq7G+qdIFGIaIwhmicv532aWUtOjRyGWkXWUQiV
B+SupMVyQK0s65uyktbail5Ez52ttFbVlqdrNuIqEVW3ZIViqMtqxIsxGCB09Krau4VyahWkMSQm
51mI6kYBpcS6lmiE2ck5Q2sCgzIVVfDCGuT3iKlcOvGsiR1rNOgRxJZRxF73VrhCRIihib53qI7S
gg8Wb03wS1ce8VMynX7wFAlUF+r72mIVDa/V1VlEfsTfUsax8GYSsBeDBjo4t3fvNgOX0MFKW8wH
VpVy7b+3oq+Ql/mKVkxrcYiy+RCkcRhu2a/F17zEFWZ1ikruK8eWgQNgRXmPbW4cxhJ61mEcHRJU
eeC1uGMbFyKzlHJpccR4bwTiLFFrca2XNjdyLRXGox6zDb7Md14gmxVHG2Ob71VJSZcUvN9eyzwJ
wdmMu05M7tQh9NqGmfcE5jdiQWMJW8/FLc6qONa4s8kEttV/OVHaBWvbU18omitIwvzPJTRdBtO5
0zJobMBaWkkXIkkYvOZtTZQIktKchsVcW8IlHSnGYWDEH1rL2EJmddS6pxncgdrNX5w2EoDVBAn/
6HIFsjFKhc44zIZqDWuubz7TpnrKlmKdsFT1bjPaCLtT6/1Vd2EJTdGGCjoS2rW6LjxDKKqqf5kL
pLVjWY6AtyN7RhLdCPfVBiD7N3oWPePASBmQJxuvAkyZ+mRVrFXgLa8qyHdZvcmm+eKak3ksXhGy
tg7ughw/ixTrj8JKZuZVR8SCZQPiRXdkIeVQuIOfE68SHWQJtufF28l3O1KmBzvAk07Nc6KfGtAp
dbWc0znIHpBF+W6ZldUa1jCq7S5SOQcqqKcO89S2fnrWBOlW86y6rlJCuZH5KfV/mPLEwzYu9Cpu
nWMGwohF3E/M4ZDUW7EfLmzkYin5blIxsuVTvdLx2WTqc7ck+IIuVUj+RH8eJLJh0ofJyDnI2RDX
v/mMJypy75zvJw/Gv48ocDKHjiQYhiIYC4SESQZmVDvlxnJypwqVsQeUxr/a9m4Gy3zp1mC289yU
r3aWsq+z1iUOE/uCuQbif8D40EEtZrJwvu3n1ay/AIJx0il9PdxEyh9iJHqy8fSXbNv1nzPXcoBh
hEi9D7rwo/aQr98CfM/zXB/VFOt6qlF8uk840RAK4qa/+/204dA8e/+O0+JAET6/qZKpLAbASBkT
wKmizAJAoe61A/6yg0QOC+eWU/yK1A004/dBGrs/mMg/gn0oa9WYkMCwKOC9g45Bg1ejU/QZaLg1
q1O/QUoKCwKdu+8+AIGTtCBB4+AUeKywKOuirCQrFBiIs+eJxCSL0WwZ093CJCqyU04lecEmpC2+
enAfyrARTAYm0nPC+Kei3BdDRCg5Qq2PgL0IkWMKUq0wijpDkl04AkUOtDyNqkuqqLmQ4OcqkruJ
0PAwLD+sBAtDyjo4ASVEZEHDowJEgRlEGcWsBEPC0KAw7EDCUaqoWsmmCS2rBE4scqNB+hmq/DvF
SWKwcxCoqUGQ0ly4kmKOQmILUQKIqiQQ+vTFyr0oMPyXeSYlyMPCil+uA7jGKditq+mL1F0ve8Ax
RFofetgv3CK50YMpo+6L0cOaippGHG6WKajGsOtBhG8pxFjFw5uY8tGI7HWQLFrFgle224CMOvGn
KKTCKO8qaVwf2X3HEtzH8mhEQPitynW5NGJIM8fIGNrFnH5HSVcdULUKrHuqFIlIe2a+IMijpGJI
3Cm9uIPIuRNCVI3HpH3I0m+ZJJRIs9USUtoLUkUJszNJetLJiWWzXEg3GrAQi1iSUahB+iyZC+ev
WPnJ4miNiTfCUaULQ04IlKUL1JlADKehHDgngNiLJCKjunrAFKBKjAHAjJ1ERK2lRAFJhKs1BJrB
hKk/YhUrQgAk85e+/LeLUiG/jCwVEL0ukag04cipdLqIFL5CkPlL1MC1AiGd7MAiJLLMRGI4TIA+
fMbLgWHL7MIf0Sq1vL9FIkOrdMGIrCLM5MywrERCmpdLnNJLi/YulB+tPL4zNNXK+OvDWcYxwq2d
vMYJpJCWVNu2ytCn7NtBQtOjVJvNlBKtdFJNbGOKnOFFIyK/4LHN+xu1iu3JDOk2zNpGJOsny2bM
KKe1vNhJuVzGOJOziJo0Glyg2q00RPOj44gJmKxBgle8MJmTfGJPk+8LUwRERPu4sKJCLPbP6LXF
++c3OJzP+RMw6qwTQ5uKA+JPzPrHFQawJPegLQY8y0FFmmm7JQxGfFdNUIyLgdSmVNfRAL0J/K4l
ML0uXKuRUNdRUQnOU/mJ1JLRhOMKnB/RPLKWVRvRMImmVBAnpRw7NCajvCeKbH6LIR5BhSPADRSL
VSY04JFDHPpIZSSIXRDR87chCmTDGVoUG7pS4Lg0QfqVUm66KLUsGku6yS0L1TS7AsXTax454IUc
tTQk84A5VTqzuWq865vQhTsKc7VTgPpIcjXTWUqa+dU34WLTOzZQ3TDTjUDUMtdTFHGwnBa2LUqV
rHwNiWlUq1tKcl1CKPI4gOqMVTiNq9S16dhCVVI0agSrdTtVBPKWPB+VoVs2ZVrUi90zuKYaYhbV
eKpURWBKJVEQQ3DUzV3AZWTTtU3DfR2xlWaVtDsWLWiz6QpFELtVGOc4gaUUpVQjUsUhuzvVSsAM
PGI0RWwrBXPTjWcsVXZUBV5JeW02gq2KfWGUKjDN3KbUI2DWhEQQBV5X/XbVwsvDISzRfKy7pJ/Y
RIowa4gvXI8wQq/KpBhIrRcjC1fEFHtRcwAe84CI/YhHfB+fpEKwKw1SfPM2DY1CUqwkiwKTfSWz
wztYjR6aIz5YZSxK8ruagLhZK5RAyUfZ8fws6VwVpL5YdZCmW0RRodGtSsHYtYmueTDYlacqcMPZ
JYfau4rYdYUnWqxa5PzZ2oqIrGJZcp7ahZsstaM4vbVbRWrZ1G/aDaQ4iI1FhPo/aNgSUWnDqs9T
oRadBGYpAO0R6cDHdFlb0zwt+NlcSovHAbwLPcDGC8dchAFb5cXHCQDNzF4uWYxBDG1HUZNc/VVc
GlI/xdBbwRbN2lEoqTfcBOhUuqofwV8yLHwq2LIV8tPG+q2Z6UrdHFOdHc8r1dIq2NcYBd+ruLQR
7d02Db23TSSKfPxecR6u3JFFFeMNgcZD2wQYxe0wItPW+LPe9FFdxey4vQctCuJfEx4vou8c7Lzc
1cuq1feVewjcE6smVc0WOkum1bzf0t86iIYSY/wt8kCKTdEdg4BHpgRcu6jgPfMQyq+nBMTSSMOw
7f6RaITgs6CK5fzgqSO7KSyVfOpUFhENhN9di7KIRcKInYRfnUpcSaS62gSQRAo4g51RcPphtg4/
bV/h26ZAJAFhk6NToV8hLYQ6iTfiMnpQdHirFAE4LhwYAizPw5pcTijhhcjiYjW5afzAELLGPBbH
/CUc7BkbVjHQ7FzMqLDPsUdLK+rbo6O/jMHULF+XfNxUlF/jVO3jy5uUHRixYQWLU5orc93jrT8X
O92ZcLg5UXPMHjZHFV9MqMRjJVhNFkpHFj+k4gnSUN+kQNo0yPaIagyzweSJgntC8fVgexMgSi6h
KhOIelThyj88mLYsKNunwZDljFiZCqWqjlsnYK6mcnSLY7eTCkGtOhdPUSqkpF0ffljCHJE/U1Pm
g122Jg6K/VXGYzGbpmqI6381SQoq0cZVOIOaVlxlirA/ipHMpnTDmIQwYS0ILl2uWzyIwSygOpAV
AsZPMJBncWLnhnMJydkhDg0huy8RxnSaVViwKYln8woSNJQRALzl3Pe3ta6wdnoIUfJFpGZoUKto
ZKetLo0Nu+PoGmKm7NqYswTl3Cm3THs8foqlCYxb2YNpkiJaGOsKVnSiy1yzuO0OVpkRXePpBopd
kOvdpqLlteKU7TsmPnmwpp8NxqNFEZbgzqUq0m0v5eg/jnS51i8cCzno/qtfMTlqMu9oXVs45TAb
LYBo3qpQfQFGLmfdkTlFazVqW+q8tGFrE5gQM6Sprmy42Io+uY7sE/mI8s0oeuJmhJ+8sq2YiL6k
6ZaMS8dr7O3sTR6UZoJkVoDj9q7jOgTMSkwrdmgu3TPd5IBsak9LWZBsk42I/B+0BnzehAJPzs3q
WOrWsVpqg7Klrcbsu+AwXMuZcOVBmblEGIJte/mKAuO3RqDtCKYuinpug28tsMg1MItnSqxfCMiY
joeCmJQJUJYJcJg7kcQQ0MND6J67kz2INvU67IrfUNqR4J2KijwY6SYS0lCgO7kqsIMQzm/v68Ab
aTMQNmyXiVFv0LuduLZwTMTvgLY7lF3veqxD7vOx7wiMoc2M4M4M8NANENINMNQNUAaXjH1wAVDb
yb0Wg4IO2OEWYO4X9FxwCTMZwaAUyOAT8OEXPxkYVQFxrxWbfxyWmWsOqKLxkYta5yDxuacREwqQ
rVMUCM8ZGWzxTwEawbgMxdnyiOAWtyoVdAJyZyzyIpcPUWmVZvoVELNzHxYT2PNyNOgPGQGaSUmK
DzbyHxaX4Oqg3xkrlYbzxxxz04rzPx3yoSwaiJ1xVyabGSFg7x2OyROM8LPwYPB0DycPTRrzONeO
4LOOQpF0v0byeYN02UgLO8L0t0XzJz0uJzPDx06WmPkSZ1CYH1HzMOFL51gVDLp1oYeRvziRAVYL
O+V1n1Vzd0cUCOrzn0nSSVAMD16aySl0IOFW/1gqrl72hy0SlVORGff1grlDR2zxyIHzjfESQPoI
8Kz3Fxb24QhJF06zuUH2f2NzzzeIRxeQBGZ3hFv3V3p0F3t1uQAJt3gO81z3X3tYQRGpZ3gc737y
x2Pyf3wQn2ElyTMS34P0cKZ4kSP3gKHyvxt1XzeUB0g+b0kJYx2dv4v390xy2IJ3KhP3hN2Tt4x4
j5IK71NYP5V4f3r4z1aQh04QHEGRZ5n5X1F0yQvy6RJ3PAya74/yF3/4z4SQgU706p8Pn5p0ySsQ
Bwb6q7GQ16xy25T6TTZ6q50xR7AVp3aQB2WJYnYaH6/6L1r6ykcRGRt6DI5ov7RQ8SGct6rOpzv7
j18uH4lAp1MtbEd6d0Z7l7D4C496Xsd8B536hyeWrziSNy/7a1qhv715Ir/06qKgf0V8l5YXF2mS
lxf0mfUY91T9H6Ny2ht868f8+6zml7Ab5vIb+Wq/scGXMJAcNUYIKcUZa44ccN2chtEcmVVm/b6c
yc3j8dcahgSBAw4dKdOMOZAdWdadedCcud+dsdwLyd0dMfQd9w5yiIMBAgyBAeKMyeO0dlMg8eae
eeiBAenxAetxGe17bTNvTws9eAaIAMRkMhcNxgMRAMRyMRcNRgNYTA4aNhnCRyNhcOBwNxAeQaMR
mMxcNhuMoSOBrGRpHDZH4kOBmOYSNxpGRhLJdBJhMhiOBhGRvMpaOZ+OBzJp7RaCIKHRaPFoZDoh
LYFBBlG6hDYfEYINByNKzUhAdgacwaUQacY+IDSII/NBcMxxSKILhyNYqbbfNRrRotP7vFRjcBoN
YRCoxIYhHp7KRqNpPKRld6Ze4KMo5g5qMhrU8tJczPrjmMqMbwLpXEKTo5xppFqb/drxpbhg9Vdc
DM5rcrpgNnZCuIDcDRgIOLxxAawaQiwIBeRynFTOcxARSxH9PhszcM5EMBkIkMBwIDkZQaZuJxhc
MKv6vZHOLytNfIVuhd3fVFxB4fH5fO9KfoeyEAtm+LsMcgb7Pw779oI8TyPM9DjvWHCwQC8cDNMj
Aas5BTOvy8EHP7CMABcGKBPUGKbuM5LsBuhrSM0+8PwY/kIP/CYYwtEyQxY+S+xgnjuRou0QwpG8
JRSG0MRNAcWtMHKGhmpEhu9IsGyO/0kp+xEUqxDIbJ+vDVSrEEsQfLUSoHHYZR1HyPhsqIZu2zci
P1G00wmziTJ+GULSeGyCBqsEZQXK88RJPUmBkkk3hiiiGhpKk6ytO8RSREoZwfPqv0cGy+MLD1Ky
NNFEvUxVTz5QDHJXUUzURHFTopU9WzBDcyUpV9LzzU6F1OmlPReztJxnUczxHWKfho+tlU8HCGw/
Qs7VJZEttRWrUNJMEos7Oli11LNTWUG8rMLP75IMidXRrXdxK0itlQxJ4bqjQN10PdtkykhExRXD
KSonXFv3ZcN9M6mUxBnc63pEx9vUNS2C2svr4Infl5r5h9p2PTEJzjK2KUdciGpLe+I1LfVP3gkc
3X/DdyZNamOvUkl+JHZeRWEG+NWNWFrBsHOEJHRt/2evuY45XiftBmlO3/bi56Rn0S3JKyS4u+TR
L7gWIZlpSCpg9SaPhJ4cKijWpXza2zZtneFp7QUhVzgmUbWmL1J9rCPpghqn2lnu1RKHGiIzbWyr
4ym/3BuqzrSta2gaGmjIqgcooWiCYteHKKhbR6MBpOcb0Yx3Nv3ZabJMvQrhU4SPpE8ed2eGaehA
vrNhAFtyIZT8bpAjIQdiuPadV1riqDBzITik3cqe/zguG5DioQJb0iVFg1PVYYQDuEHX94JoQC2L
rijI5bmue6IQOm6rrxk3jYtyvUZL6njcNnGTCsOi64hmxe9mOMgY0+5lCqFwaY4qApNYDmiSma00
5sDVwNNLA9mBCjfEVgSiaCr9jBFwffBY2RFSyFmeio4ED2HvFgfA3tDajD9onMu6kBoMibkqI4m0
hhJSTQ0ReDklEL4coJLJDRZ5AnKQwh1C8kRCyZQ0JSDdtBHk2xLPqYMkTOyTFUcG8JIUV2Sk9c+D
U7cXiTFkjA31MkZCTwtPBEhBJHgxIARYT8yB8gQPWhmeI9ag4gQxBAXqIkeywROIzGI/ceiHyDIe
XaF0Q49GmIRIQuZ44pyFkOSko5kIpSIj5DiPxLY4hCCoA0F4RkVEJBAFQ9BfIXHIQQSeIrlD2I8I
QFQvUJSEHKOYc46BYH1nWPSFQMcwQ7gNBQFMMobA2EJBgDAFIVA1Hpc7KkIkxg5hoDCeU6gbwzTP
miFQFUxgghCCGESbwDZwANC2CgJIbgyB1DmHQOQKXOk1BsCgNIZQ5hcSmDEFIXQqBKnROEFASg3h
oDcCAKYbQ0h0DROcIsoy0FqIQ5AqpqFOkCMS0CP5OSCkHIjRsnhEjHmCdmQUwxHXXEiJIUiGhBUT
mlJe3dFSUWa0yJ1TQ0xBXQGVLqUYpFOyaQYAbT9vyjC40cKoRIq5makAzo5RcryhKn0cOA8WOab5
dvoOkdSYBuDJzMpsvRxa1TiHrJBHM9YMEnHKIXIxQgMKxs2ZPWZAKHUJkHb0Ucu0Va5EjrI3Sux6
y5VqIO2St0VK41zrKx2PdhkEoGK+XauVYrAV0a8ok9as68ntslJgGFi7L2NTyetmFeWFJvf2UYnl
f6b2CsceJeSAW72SReUYwVrrAr4YlWdi6AVQ2SWeRo8dNbR2wtKideB7jvItaCRlsNxrX28cYlyv
FzK2kfmaUC4turMNJs0SC2dm1VHyIOUC3NjLkXhuagFoiT5ZuDu7eq6lg1H3LQCDe5d5nvXpuPfW
xxtrDRQUdaGQt87/11wC2ivKFcCkpJRf66eCrSqqQCwi+BGEK4IwnZlHB96015MohmGqFSkXetJZ
ogd7UTUgxJcN0N0rd4UxVYVHNbMCpRJhie+mNMP3XS4ihDKKnCmZxRevH9nEUu0yGQwuePME4eQk
fe06KQZX7I+QIjJg7LYdvBj/BmVsMHyd82bKGXmpk/vwjxt6OibZGx7lKs7s81stSfTsn2Z8Z5yz
VkBEwNLsonIwUHOGUcv5TJDeOSCjjBkFb9kfAFpX+1qNNYjLKz4oaFzQ4HNWSkuL2yGlGKBh9IY+
0RlXT68j5UvZ3AHUufC45hS4sBDKbSC1kxld/NJqNKFL1qQQG4NtXZx0PWdZedYf61iunHLue9ir
Kz8sxJ6fqUbD0Nrt0Gij9a1ifSnXOKcP3BPVDS8pLtB6A2brrThqNPH3X9tNF5NNSbE2xqjEGWCB
aYqhuncGU3JXjTbqol2osJbO13ixNajlNGXNVq/Z5DcQ7j3xSeL/DuD5+yvc0+SU6YcN3o4Gibjy
3OSSkg1yxpnuubow5xzxqHQn+dG31yjp880ddW63MrwIoPCPG7Y+7uHdM3d66/nTsnhgNeeel49m
wQPK6A8083SZcAgeocV6xxXsJiQ49t7pGXvvhfGCB8tWzoVdfZR6qdIakkyfkRIgxh6q0jUErMkE
OaUmMJDYClzS6Y1Lpza2xnfiM06ifT0ppGW/VC8NUUp1LqRU4PuVijXayuUYqp4+EbjaKFsLc+5q
JAsIZcfkXB+hEfQrefyQmk5CiZGMJQuogSXAalCM+jGv6J/aIygPTshRCCqQUNV7xX3vzXwVM5ls
1ptfjenPtB/47ZiOVXehVlA3ZH0y/fadnLlxvcb9RKexJh71HKDRhZb7uSFrICuZvgzqMMofn0iu
48SO1NpPMejDjyJlmfxX0idPjFrSzSpGDQr+DUxEplpHj9hyb8z/cAxHJJZJT8ZbhHr7kBrPhFLb
ZExL5QBhL/MAsC5PpPzcbOw+ROJKTBED7Z7cbrZPpt5QJSMBhoUBzcZRa98EphqnsCsGUEAuJTaA
cFxUED0C0FTNTSbPpTxVkFEIbNJWRlZhUALYRaDeb/UHcIguJXzNTWhQBYR+728JbTg9RZZoUFxo
wx8GL7xCYGhbBSUKBbho8HUNEMK041CPhf5MTZkOD9BEohxlZyRkReq0UFMJhhJmwh0AJgAx7a0Q
UMDrRoQvBt6/QibwEKkOJMRL5ixkRjMKcRa3pjzlES0Q4xxYEPL/hn6nqOkEgt5l8RUL8Tpmi3ZT
5vQwZnUScTi6pppoTYUQ5ozz8L0KsQYy5ipoESBqEQMVsW5pZIhq5RxrTyUX0SpsBlZscZgqMWsY
6uxvCmJpcLRrJuL98a5mYoq2om0WRvj2cIUX8RjrxioucAJCpvsAkcBNLkKirkcBZyqvpzDlQrzl
kKJ0AjjmAGx0jmbJw9jmx1g4bnJ4J2bnsd55boJ3g/0hTnchjmyrDpbHDpx5gkx5yrA5B6Z6p657
LrZ7iFIEB8B8R8h8yXj66rx9qDzz7570Qyz0r0D5A+z1LupExoKlSAUMz2JEz2Y2iBT2xKL7qDL3
YlL3qCb4r4MpT4Y7Epr00m6DLAUmz6D5smL5jzKEpA0kyFZDg9cNQhLQAkZD4uQrR5YwrLYyA/wI
R/6yhQktcdp7po0gwFsuZR5G8t6USUiUx6SVI9ClhNqrImpZaAIjamCAJ07QAyCWyOUwCXR86Xp9
UlwBoFpAIhQsCYUy8zIygKiYqdYHgKgIgEAIIJgJII4JwHoEQKU1IJAKgEQHyf6gKaSWqapAKZqW
qYY4s0CYwEE4AEAHgIwJ4JwKic6dKdYIYJ4JgJ4KU1gEYIKcwmIFAIJoIGAEU2igSdKY4JILQIs1
gGU7KaCgadQFAIwFIoI+86oFIyc9YIc8AEQIKeaeokafAMINk2U7U8oFE4M4QIU2c8k5M/s4IKAO
QN4NQMoMYOihQOibKegGhPoFAOgHU/c7k/wHgIQKVAKb6gk/1A1BFBVBgIwNINwNKa9CtAVD04IH
gF9ACiCUb6zsyYAtTkg9h2cwpZ9G6SNCJaBnYhJSCLA8YMYvQF4JINoioIgN5xsejzgBp2cNy4rl
RR4hAvVKAgsgQiwkVKh7ohQkZGKHxSIiojwkJpbfYnpYQGColK4oiDpz5WYltNlNQk5QTSYlqpo2
UxFOoz1PAu6ANKbZlONLx/p/VLbZlK4ztKVQwhD6UyCrUyclrs9Pp0owdN5lcBytDNaZq7Iq5Z6H
y4rYLdlS7WA9jFivRN4q5yy6NULQFUbh9NS8aw9VA3FH9StUUNCx6zrcoyYhgHKL9VizkUqs6tlT
SzxFoyYggi47dS1XAm9Uy1JAwyaJZe1W1VtZrWSwjMaGayYu9ZdW8PRLiwzcQ5QyaTDrdatYNTC5
SwzjVbYjAr6ANYFVzXb0FdlTlXwuxnFdFebda8SwzUFY9MJzdeNZlcEoNf7SwyZy1HFfdXC+7AbL
BTQwCF1htgzASvLAkry84o4w9eVh1bD+ZN5TVZLlFitYRPqw1bRTSKgmdgtk7e9lNdpTQmoohMll
1TDFbSjFxFpTSTFltb9l7K7RTHFjTDRxNj1gzaLIVnjEpIVm7WBRjOrJlpi4aH9k1nDeyI1kSv4j
dp1oFnFbAgVlTIgjZQlpFl7OtaFniGBwdr1a1gzOjShhZ2YnR3lq7WBKbFhHS7LOiQtt1dNvDGxF
KlMrzNwlFs1p7h8I1wbSx2bCEP1u9xTdpR7cp2bDUHNs9TBOdvUCFwq26wtyLXYuTRUblJ4nrwdN
1r7WBP7WdsbHQ9t0LdbY7SjZNnil4ud1Nt9l5SVvVlTWxs1UFxLbFwRLjbd2wnRFF2MTsOitTclk
TK7N9n93VTFt7cbd45RKYmrmt5S6o1DeyKd56J9X16VwDh7f95tqd7CpB498lfl5bhEEUrwzBsFg
l1Th4wzNbK957TBs19tXBDjhFxd9TUTYN/0PVJpyDkg2cfBy7lJzUfpz7l48zmL2cgh1Eg7nDokh
Z2jn0h4wzoUiWDUijo7qR4CvkjJFEjZG+Esj7qkkLrEkYk0krryFTsElVGUyrs9REN9QFKt0zUVL
IhVRdLqm1MBoyntMjha/UxFNNNdL1Nt/1QRy1OZuBKVPkxNP1OmKwytPsn+HoytK9QlLRJohGHdR
WMgsYsrzTkVJ5eha9P4ghMLtmNp3Z+6vmOR7uNwww26HpX1MgudL5QiLYu732OjR1jqTDvuQwoIw
5swuxsNOIhxKQnmRyH1NeSQvB+uOKytOONzK+TQkaypOYhkNWOGUImVRsrpFuHD7FJ+TF/o2yvrd
UVyu78Jw17GD4vqDuROWcZCPZAaPdiMsIvteOXkaFkJC9kQ7JtGWIheXsbDIL/5FVxr8j2eRGWUa
EBAkGYR0ls2Y1cBJRJkvUrz+72eYubGcF4uYFNGZRYUnmZsbVk7cd+LEFuZIBMOa+Z0aBPbceeym
y0Imeb+eRPsGtxpMOUOc+fWdMHpRZp1nkE2PGeGZ8cJ/hKxKdkUF5OOfOeMGbTsJxWuh6lhN2iUa
AmJmxOduZT5lmhOjkHkMUMOjAlJOJIWgWjpa5isNmjAjBQOjeiZr42BZUOuh5F5QOb2dGgZd8MLg
SqBZ5QOlmnxdwvEQt69J5oFL+mmo+mxg57NtV7BdIimnsaBkMO5vWUYka1OkmhZj57MDer2ONM5k
ehWpBlRmkVJOalimmuOlsKy6cWNkQuGv2tOucniOkG2NumUsewWmxpiOmh2r2nbdGxUHhqpsUwkr
xnZm+rGuWxZsJpekGr2ptc+vWqBfRthsV0pOamyPmyUKwnZvFnd7A0UgQ7emsHhwcdmW9J+R0gWz
WvZqeBEezkuBjlBzLlZ3Dlsf50UgTmR00gqGTm8hOETo0hp253OD8iI80ie6ciz6cjB5OFN9kjr6
eFrqqO8kTrWGTrpweGslLsUlarmHKYGs2Uoi2TeOes0gQwWO+UWPVktfBoIhGP+OMESM+QmMGN2R
mgObGTqHJXwntXuSGVxhOSnCGS/Ce+uU/A4hmT/DGPG+eyO/eVGNVGtHTK634EFG3E0utZImhQml
V7IjlIiUlI4sFJRxpCe25vG3MbYiuGe9ck7kZ3yqAw7IlzajpZcpSZgkVNQipZYooiDlQ3IjxZYm
okAsB/cgQ8cw6zYyFgWAvKZR5GYmVMKKHJt06MQjlfC0IsBSWUmArlWAqYcMQuPKBowmRZZF9nJF
R17HBZZ2TBxE8LIiHOXM9WrIhuHFB3wzpQnQ5qLY6pPInQQECYYMScOVQ5VCKmwnjLQiAvXTIkfT
eRIiBZYrsN905JfMzCC/QhPU5sPQhKKpvVmppsJSRBxaKneBvWqPb4JQXSZyI8JaKv48QyHOfWJF
QxJ2nJC9CZnZFIZyLLQwq7vZvFC10SfYfanTXVnXvSis+AF5uAXbskm9Tr+VyTGWE9zp1K0fyqPd
BFFOJJayi4vdokxOYotq1+YihzBdIjQ1T45LqYfeq6EpynlNffdq3IWgGpnePVghiCSqFN/Tfho0
ngD9qH3IniQnB/sHCoPjB7uXOIPhAsFQhgPVjwoivihevfsp4yGSPlIiOojSfjRSKlymxFB/vczu
Hmok3bnHBwkuhA3Hjrkr7zp/YydeIgj1ijohVHTSZR97SQ2IRsA1T9pnYjgxnNSqJIByQuhKM3VI
Aosnq58zXr+UKG684wwpBIC+SQ8www79p23XzcjyI1Wg/KiQ7T9IGmSWXhqKpgHpKYaGgqN5JgFT
Yixz4vwwZBzHAxCAfo8nYmXSnSz6hJ+O5Dp90ER+XypMjeKmgu8K4wRrRFfpYmy4v0PGKPIqxBI1
cQ3tguxIXziJrA2d6D0EXwH2RIQwCSKWYgYpHeBHQui4ZB5R6IpSXXwhQlJzNIH4gunAZMn3PDvy
32gsHnj/Hb9du9HoWGnIB12ppQiyYmg8Z+QrxE12H78Pz35eozP8y4o7OxKvhnft0HH70IvncqJS
OQQpT3P9tsxZ+xPj4G4gAgGI3GwuGg2GcCGg5FwxGQ4gUEg0IEBjBoxGY4Fw2GkRgsHhJsi4zgoy
GAxj0ThMYGguGQyjsDjQ0mIzlsvmI4GAuHA3HMVkc3mECHM7GYzGQgkUsl1DGI5GQuG43lEYksno
ktG40iEYjUcrNSrlAMQNGAgnY4Gw3tE8GVss5rs1SG8JO4gGc8sBNEANk15p42gQwnY5HMoNt+GE
tHIzGogxsbhYgk07Gw4x44lo1G0/POKvI5zognsureUGA1F1FlA4hg1qAgz8mgowHMd1wuGeG1Ez
h2kG8bwQyGIx3WtlozglAk0MGOY0kM2mo4IwwW3g0v3sup+DwuH5gw31JGOEqQ5iF/3Wu73n9Iww
Gi9uGlEWMQqs1o/Vxi+GFwahkx7ysAGLBMSp7XwCwaChqGaUJMqIZMawbpN4kzVBu8UKJc3iLOah
rtPLCqfuI4z2PLBkHMo4qeJ/AaGwK5kWPY/0MqTD6HKS0TVps1EMQ1HbGo7DwYQjCcgx7BD/wVGs
iqJBMBPhGDBPsucAMes6dhkxz9LknYawAEC7rytSOr4kavpjCSNt/A6FxArs1hs36lhq4zOLYhyG
Tm8kGv+miBLejcuBjPwa0AhzVMCoFCrzQ6Y0KsSQovQ1EIw3TFoFOz/rWgUWKRPM3ocrtPrfRiMs
lTzjVApSRquqtSzymym0gvIZ0ypicU9DAaISi1cqdAKGvkpdZ10hzgoRASSJcrE9TY8lULBZ8+LI
Bqjx+mMdhpTLEpsgqnvJbdMpEmyvpXcaOscy0NKeloaVNdaN3aw7VhwiCLXkG12hwqMGsfcoa3Yr
qdBc2zBXNQaIo04qf2/YbyBvhju3yxypVxiUYJ/cqjpcG0BYzhq8Qcl17oFguD5G4yH4Jf0uYrle
TKe4z0IhjmYq67F4LYo68hlj6iI/TNsYvbWhSGBqyyyvS4LcuAQS8ui7LwvUzL7bjVJerq1pdFTE
24grRTy2CePZbioqowVCrS2zZAbsGDWdQwYo7bjgsalcwJ4pG3W5hmf001SEJ+GjyoNRE/cJS6bT
6y0YotwuVoHwPDsFbiGNs8l9uEpPCy1OyBa5Lb67fwyaJjrj4IhrDsqr1KMhB1mtdC4PRrI/Esv3
qG3pO/4azyzrdM4EGv97ME8hvtCqdixbdQUgbVQbwgYOC0/oP+3agcihtDoj6Ps8K0MQ+SuiUfC1
cQ+Cx0qdL8XNNU2/OxZQvUMA0+7LF0P7aRbjk+eQghr93jO/dC/BeDzE7wEQKQx9a1mllHIEl1a7
BTnkrKQRsGpEFvQUBxBZnzQCMmWesx0G8BCMsxKrCSAi+QcImZlCpni/TdE+IEx1n5jyMlROUi6C
7H18QTh1DQjBUTUkohO2UrrJHhxHIfClO77IQkbhHE8vEHILREdBFGCsNSow+KAGiCa4EwQ1TIgp
bxRU2KyjLDg3JajyEweEUkjJqjUp5JerQoBGS8wljfC6KrPj4KBQiUOPTBgbNqJMQZ7MLC8nWKrI
k5UfyGpJOeceI0HZDNqkqg50hGTGHdOKRqTirZPGrlApE8RHVymaNWmE4sdDNRVk+i5uiICEmfkK
daTRLSHKTlzIdT0jUFSrMYzJS6RWAQTmKqRO8HZSSsMPLQnbdCkzElMi48RBjbzPX8dA8q55Lxde
7N9gzdAQB2iAVKSJ5XakUh23ubBJUJF4YyVsqs2VCydnq4UwZM3AHKK+8mfrJSIUAikeSbJ2l8sZ
LXG8navWNrXoZQIhyJjf0GX2mpmhkzlLJV7IKPFC1HGxRyTyfhyktFOY6QiIxEoSxkKlCuCZRlox
rnoV9ZzFi1sOha8KGqvC2QsJaykjBqoWsIkwkljq/Y2RiWXTYiwZncO+KSmNqoIEzxamdEODEGqZ
kNq3DaEDBS1k1j3CansTaYQlqDBOF0SazwxiDDyD8bK5xcq7HmGUO68RFirW+GsVImQtsCpyvUIi
a2CitX2LNi6uReItGAjNTqYVMeIteNCc41FujYQyNygTkphjmwaBUd1dSMpjH1sski/0gV1L+RFD
5FwTkanNQJRoYmAkpKI4skpdKet5J2aEp7gzPlmrtg0sZrA5ldKiWMpZoqel4ltt1sLpS2mfbWTU
wpk3QmNdy4y9pmH/mdcuU804D3mmwTObcq5upRnBFWcRMZsknI7OiHM6k8vUY8Qmd8HZ4lNYdPue
7DHQULI1Paga8GEUToQRpllN6D0DoVRKgNDpFURoxRQ4hPKL0MVxh02+A6PErtMUOkR/6SR3M1S2
lNZlB0tILS8jFcbDvOsqgqjFOXBQ0iOoRixW62ylqIxao8kqlU2sm9yp9nCgBzPyWlTpaVTFnCWX
Mo5KC7rXfmqbGpugaFsW9NmtlhSfRGNSVKWKz2BMOzSRhQOCVAEWCnlE/RKC5IOQwSRQJ0sxZcX9
TUhqTlyozNTXhgU1cuR0OJnE4WGlIl1kRn5VoZsuEFMvEk4yRc/oOXejHL5dbuy1Xu2pWaepSKRz
1DVd7DtIvU1Ys3VxH5gZfVuY9fJAzdA5VkVFRaDlkvZIwiaQjk9h0EjygUjcL9NqmJFZLXRBIkmF
pet7XRt1ZHGUSXiSuNbCoSoLJU4liUlq+y4RpOxNYdQZ249WwmX0txy103TUxoWTa50woXWINjtI
OJLnCorcdw1GcBwEq2yTVK31NwltunkWk1jpNvhzyYUmMMnrln088vmdLZoUj4NEBJrTLql6pl4a
7UmTVIuZ8EsMGKSTsrZPz+O5LOSjK8nDTR2I0VApOYzX8AZIkW/xts1Kyl5CZGaJ2LFQk6pc+kNV
k3P3nSo4NJ5Kr3iTwyH5SDLSuhsdYvEkGJcnYMXXbmEDlqjUwT/fEAU1IMIPtyRvby3bcZWVPR3P
IHO6P4g5CPY+NoNsvzgqCy6hmn8JEkrW3CorchTHTwWuSor98eQbsCDi8k06y8KIyl/FI86b0eCx
m/O1DPRZWZ3mIpVwex01n27Mvky8ZjGmCW7/EONN6xj+5iyhCCoA0F4RiuggCppbgjVCFlsBaTdo
B1debcM2WNZCfyEhUMTzSCJcghBYBAC8I4UyOhnDmCAIoWD8hUIsWcKgdwGgoCcCkKgagGhF9+0s
tTTV+tPyv9v7v3yEvxPyPzO/CNuNFZjdjENFmDKPuDN5F3qwjjG/PZiSNppDNcFrqEjnlAuquhnB
MTCWjNM3FFMTN0JInIGfnyrCjOwEF4F3qcppkuF4QICHwNCePBF4OYHrFBDxIfs6lelVk4lkpzGv
iHiGlpmSCaDBCRGdnDoeC0u4wlFbjhOQjqs4QoQfwaE5pVAGtLFeodG+FnjlQVwouwKuHqKIlekv
oriDOzQoDCjYK8IOm6mSDHIUl/QbILretjiOO2G3mOjFoUkvw5GfKwppuTQujJE1E9m+HIILijo3
oGHltnw+vMjfwwDumvmOjYJHiGCDnCISO8FqIDlekyPYORFOxGOjwKEMiExRjsllk7jlxDohRGxF
w+kIw3quDRHLGSDMLNjHHOwjrNixxGQ3KYGPw5Q0q6MMnYwoiSMmkJNzF4CNCew1Q/lWxDjxEXQi
CTGbRJiDRKk1kHKIuVCduWC2knOYDJuZndObG3wTumQaGfkDR3FFLSoGRDFhQfNECsQlkGvRmPQL
F4RFCajawZxZOTOAoSw5DNwvqVkwxGCSj5NjoxleyCpHjfC2RWsVtMPIw+qLE4wPnCQiDLk1FFCw
MGH0JHp2n2GlO+Hdwlu9NjjDM/x+jRquHCnVlBN+MYDFm6wiDFsmjdq2xpCJsmqXyBGDKSKVrmHY
k1nTvaqXwTCGCfNewayfSpoDquCXyMxwkQxeSox3OdknSJjtSiC3xXj/u8SYSvGaPnkqvfAGvjvM
vnvlyAAQPnSMwolwlAqjCeviPrx2Hdv+PvPwAQQAPyv2v3v4v5v6i2v7zHMqgQP9vuTCP/vxzESz
OzKuNRLLw0NlxhSTy9MvE1oSnzSfxwCZm2wTEyN+S+C6SfO7k1D4xWJEipu6F7nSM6oHiVoJECvJ
ysteDziOkDt+KTFxTUnXFbIICnxpkJkCjQltTmtzECvom1D0EWiVmPmDHYTmPLHXI6TuTgifGkEC
zwGcjgjnngTqmgiNyJIAJtjAz2n2TnjdTlkdjOm1TijNFxT0S/TfTjCiHqptrIiLjLsPTojVrbED
i6jTTrOdrbCBtAiqjciuGtnqt9T0jdT5pDxv0JwqT8qjTW0Ms+TyipHnjMS0wLUSqKUUGBUQDziV
pMCaHgEMUTvMswlGGuHfmCUbuO0Cjg0dmTqUlWkCwg0J0h0iy0iuifCXQ3jP0Vnn0mEAqI0oGQGG
LbClmuCOHkUriUUsqPHkMZju0v0lHvPc0iUdPAUGCKUsmslEUGCCUaDjiV0GN9J0USjdm1HyDdkX
TiiF0llVmgECwICIxBq21BiDVClOHXFVkVCBvMinE5z6iq0GDHUVVJMsmTnoqX0s1G0JmwvpVJGf
0YjqpvHNlbjyDSs+FfjOUm0PDVxQEAGyl0MElOlCxOG2zujXTpziteEXTrjRVGGPDUC00MCOG4kS
DzF71eMZoxjKpWn3jVjeTu1gnQxppzVqLbKoncTAsrkvkwstz/z90AzhLL1xTgTkH9T61aTsV1T4
Tr1d0cz11dTnTtHVCiV00S17in0BTyV7Twz+z1E/zrNMT3ToT2T8UczlF0WCz8zfz+KwHgWH1yTx
ov0C1r0EVq0FmfO01gUIHyEAUJxOGZGuCqEBVVUNiPw8jSiT0XrP0R0Xnk2T1N1L0a1ND/wyTtCf
UY0eoC0TWT2elf000eHD0fUk0gjn0h0yE50jimnaUyiBjpUnUC0amQWpUqWdUo0u00UwGFwi0vUf
jJUwipUx2w2kIS0z0yWzi802WqCXU3o91bTtPMVFU7W3U8iIodVp0/PTiB1AkBVJCY0GCH1D3A1F
DOVhVM1HjsnUVPVFVLUc3HDn2aU0XJC1DV1QmViKUMjxXACjSx2UFGVWkA1XteGxvJqtzr04lNVc
VfzpUcio1fV8UE1hHAVnoW3AKhm23bpnWhVmjH1nrmVojDXXXaVrUD3Z1qiLMoPsD+CUA1GqORkz
z3l+kVu/zhgG0UFbiEjiXrjSDVCaEHvcC3r73s1NkSXxjTl6jlXgDrMwG3X1saCtnnQtIACpmQH/
COz3uAX5ikXy1jq/CB38gQXqEb30iOjPyWuaCNndiUAlC+0W3xXvDE4IjUGhCf4KjaQ1iIJ0UUF9
i2YNHYX1uwYNMwiIDP4M4DlW4FT6oI3nT9Ssoet2TiWJt4VBIAGeq1oFT3sYMy2hV5oYWfV9qxXA
TzK8LIW3YhosHXYgIqT6T4IlUN2FrCnh1zlo4lnQ4a4ZIfowEC2MMcjH2N0G4wW8klpHrQnNULuQ
pB1/WVJHo/US2XsTnUWqrbxl2hWbCHLcWfWdrgJLY+HnpNre2hUgPAZBWwWj5DJYQtUk2mLkJU2n
2kJapem3Uqrr5KU22fpguXJk5G0cDirwWl5PkWIMlJ5ElSL0NFZTsFr223CYL6L408OAL6s4U725
yJL+VR4sptCu33CX0+1CJyJ83I1EpyF4XAXJKE2SZksICk2hXJJEqIXK1JlAqLHNXNMTKN0+3Po3
42XRCSnQKSsWlNXUIPPaVbvLRlYfUC3YxZqbVEOCqdIhYAVcsg0cXfKYllqjNQTtXiYyYvXkMvrL
Vtj84Hiz3oTWGrZ2UALH4Z6F1x4bXAYptQ4d2D6KXC4gMbV9TuYiYhaOJxIf6Nok4sTqWB4qT86L
Yo2FV16T5d6IIL4A4YYrq80CaAIWsYLLYxC3t6snUI4zLQI42n2TLXMUUC43ZqrV440RY55AOQrZ
Q+UoY7J12dTnZD6m4/JR5CWoarW1ZFLk5GUtQ8rnHUZClSLppb23WZZLrqZM61ZQZOWuWxZNpka4
0tlVLyZTWhlPZU642kJsiF6wU3ZYZz255ZiNCTiE5bOE5cJ2zsvG2+5fONXDZhMD0C5g6/n/5mNk
VEXFKE5nbLZqY9Rl1O7QsOoW5rr+6kMRnQ5uaiTyXR5wsWJ+FC5yxjVHGyHL4dXC52xlLLZ4OFop
U+3dIeKgUc3fqfsPUX5/aBH/4v7mQLMoDHCGCizrROYwlrmybqViLSGeVTvn1nlDqC1JDCCO7wRh
lr1JZHbzbxNfEnVno6i8TijylxbrI875Sx14FACSDjZHTuxf74tNlcTr7/l87vE88BrRbswyb8l1
cFbqiDQLLJTtCej3nHNOkM331nrNb4jXpvF6m6F1VjipkXDc2W77PMsaF7sJiSXYuC8SkY8WM1cS
HakVcCm0KtjSzfb4vJoFUUEB8d8ZWb8f8CiWiOVUlFJAly1j8jGTkTDl8lci8U8nGEclysmCjDjH
pcTimJcSDCt9clcbkXUmIW0fCSCtQ88xnJ8oWyVKJRVOb0ciysiJEhJScqmImsi1c6odF220F4L/
TiqOiIwPuwL8U/U9Khox7pFOGIphIjIMiJ3BOLNzDHCZlp20DiKC9HjdmQJYC8dNSmHriTpO9P2T
8aWwdKNd2TqccGpRMvcVMFDHDgiSG1cXooE/NVjnyBi8E3tsbt8/dPCPuzb177RyqP8NHJ9UX/DU
PGnl79uy3uEinsQ+CSEyQMkIF57xLa9ocLb4qjOx9jq2uVdFbtElOQPB8Hbt74CSCjbvjzbw8AG4
7y93bz9nb1d572NBkbjzd1b776cIb7b2zjqTcQ7+Q88EI5bx8BJRSH70d2cD+Fo5d0Vdb9eJD/dz
UCRnCedvjzcNlvcMEe9wcOLyEBcP79cRIhda8Tw19VcV1e8XHMcYctkTjSnbcbM1VSQi+EceE88f
JA8Y8uchJA8iDJcjtBpfc7cm+NQk84IpWT8p74841U8vcs70cw0hJTLu+ZcxLPc1emCqVKeucy8R
c0c3es+oiU86c18mHriH+l8Ylb0l3wLqe3xQX5idDBdCvG9DrSIcGyDOdGOXdHdK9I3MdJ9HiD3B
GswM9k9QW0ENfGdOJy9RpRdQeaEVGA/KeWKM9PdW+eM5dHdZNa+Ul89b0MDciEF1deUcVn9fn1w1
9tk/utnNjF/YcN9kih9rswojbx9hdonpeVIWj3ou/HoADrfa9kcJ+N9uXlsommTIP9MsdzKrXpC+
kJR7m1FuFMM//rUNfsEvkJ/uDYCu/srLfuF7iY/yEFF8jzNjf0ocDzPHCFfvuhqHlnfslbsh/4f7
RytGlbppgbiACAYjMci4bjkQDIcwUcDgaQKCQaEGMGwqCjUcjiIQWDwmFi4ZjYbQIaDAXDAZDGPQ
WQyMYyWQDAbiCKGiKx8YQiBjiDDiEG2bwWcxuTjcayuQDIZUQZzKkDYYRqByynRSLC6fQ+pzGZ02
TDEZUetzKj14XWCxDOeDefTQG2a0RCeDUYDOkVm5C4ZDel1eoVK1Xq+W6rjOlXm932cTrA3S7Veh
zuexMGzamjcXDkazOBjMXDWNUDL5nNxDPDiRCCmzwY22BjSTjmu1EXDQb1oZ7CczOKauDS7c7HZz
yF0vO1jU77i6bPxre7Tl8eFQ/fDfgZ4YDal77bbjsdq3b7W4zv9uZaTODPPdPVefNenPaC3ZYYDU
XDYYyqBjLPjSjtE+r7vyiD+BwGaVKa+yHLs47svMGyzhkwDyvC7Lape5kHPbCAbBo4ECwPDb7w9A
j+qO58ORI/a9IxEQaQxFaUNnCCwMA/kZQrBQaQYwyTr29r7Pw/UerChEEwFIb+Bq/z5relCzs05g
YtTAD+BjKLjv88z+BpH7jhtAz2v4G6BuZMC7Oe/iFvI+8wqa9ceM9LT2zhKTUufOsVobMTMoXEsO
o0psxzLFdAQrLkvR7Q1BSgtMC0DJ8rrSz0ppGmsnPtP0atq+oQQBTKdQk+4cwRCylONUQcsOpsIL
oqVUsPFCJK1WDzMwlCxVEG1SPbW6woFUSSxPJ1fVy1krxEg9aMwhsZs+qNgWYHDeSdCFT2irFpyB
PtgWPI0A01YNO0vN6zrZYCLhkkcAUpc6wIYsE6QuiCTBhHd5V24F63vPDMhw4ympPe6mtglMGIUr
F44IvVCYQGt1QrguGoKGTqLrf1UKFaFy3zdCT2hfsX48GGN4uGN3YRit5ZPV900sysnJNA9c5dT2
YpAGOaYS8yTSW9N9rss0DYBoEKhis7W3pgWghho4Z50HGFaakGdYfl6m6dnWVaxpGW4/SCTaHkeQ
Zvn2x7BnGtYtmWc49q0mums9OoHHWbbiGO5pDCKj7i9T0whp6Z7i7WAcA0qrBy2Ac2ggfDcEzSzt
xGlfoU+0YaerCH8RyzcPsGslo9xXGcwwzFNhwiIPt0rCcSkAZvT1TD7vvPPdB2a07rS6FPiGsebD
Mm7Bz3keaPnPHs8ti06ctu4plIflspvoauB6HQuawHitLuLQMB36VcQ2HuaU0CR+lfWqIf5vgIHm
XQcR5AcLT9v0+Ez/e/G1CPeHpVp+/mDlX7LLJAtooEAHPwCBsDcx7kC2EuL2ZlexHkIEyVQZhxbm
ibuOWxBeCRzVQmYgTAtVproHlqWoQqEcH25EqhQ1Qzi6jkEIhbBRYCEDUPRgY/ksENldkedrAJvE
LHIQHWxCZuBslRsHcU694MIHhLAPsUqBcFlfloNq58jxPCUn6LDFdYZCieA0BzA4+x/m+EZIMhKK
BegZQLLXGosES4TxoL4q907D4sm1jGsA2CXY8xbj4bUpbiIqK5j6YqJ0Sj7x4IVImQLwlqE2MKmG
OLH11lBgHIohRiiCn4kMZ+NpSHFxcfDKE55X1tSVYe0wkyL47F6VUe2VrSZKskauyRC6r3kM8LPK
mNptU9lXlGsBOSe3ESdbaWCYpGpJsHl2UgtUipbNwJ8uaCpWGmt2mqydVBPCouCmqSVg5PEDzMmq
mBUM5GklWmqbJYzOJmOLL0U5Tc3yPEmBlPSB4OJsuInxPozANW2oSILO5bCEjHznhIZihBhJwl1o
OmGgk1lsUCb5NswZYFmT9f+qSRcDk1EoeC0cGz05iS9ni0dZtJ0XwyVUuaZyF4cJcRbMqmRHj+K7
i4pSYNL6dLApDIMm9OVeFgpylOnEV1Qn8LU/RK0CqgQDgwQqlUvqmEOI9SSk1RkBPlo9SWkEEKhS
SIaRJVBJnhSXQkWuWJYGjlKhZNUlCtGjn+oSSyLldX7zsIulglMV67lYS9X+uBCZqr/hfWgkNDiG
WDJNSWw1fVcyznNXhYFlLGI+VpZitdZrLyLsNWys5mbFrkanVCtzcjQpOaPaiv5BGLNHjHXk+6v1
GMVhfSRX6aTPnqWBbosqTzrK5ac4lPlw7f2qUOb+ydgkt29YOz1b5/LcWfRac+2R+LrLftbdG5x7
bu3Jbwc5mCrJekCZzIsmaAEaFSvS4lpiEEXnGSmuZiyHCM3oRobdCqECMoMvqydi1DJk3vYGeclJ
Yr00lWoaPBN6HVPAvNf/CBZyCIiV3e5y2F1ZXzwqVNEUtL0uvVLe3CuDEmlNYo/G9BsGTl2QBivB
UfUW4qM+yfFqo1SkMpEfl06vDet4JOnvH2OjVZCMNjk/yRskX0xdVDILMr6GnT2gdeuRCB0fPbjz
KeWjnkXxwfkz1YMtl6xZmJbKkMZY5xfEenJhz84reDm++hF7ISbKw/fOJEnj4WJ0lfPjrE5RV0AQ
fPuKM9vTjPmM0ue41PvvVeg4lxndyCwUWs8GlcQH50xULPD8cAadqS6jTifanW1zrmaahBUX4AMw
i+9ZFZwqEZOQakVE0O4KgsbmyNpD9a1eFVOeRKSXbA14QqVoNL3GYBvreeQNNlXo1fjifxtdon5M
wQOIU+KkH5hsn6ibwtf7fejOdJm3isbg1nq7C1cdWa02nJEm7PYdGttIf/eZzdisUMU2HEWrJGUe
bxgDgGnqPFqz/wWrNtdf784WdrX5xGnust1xFEdLnq6l1hwvgekkLxz39e6MOONkb648h2l29Ni8
SWGHMm7nL9NyrU5BGF9SCRCwjfRDkoYAUlvdztNHLzMr33QdqES5sFOAV5C1k/SeZOsv3gpBRilM
9EvS+Lnp8j8uemN0J199OuTx5h1uwUPnI8xbwy+SU8i+FayyXvmZJu23oPjpmeRmtivI0pR5iuXV
lcUlAZzLPf6qEGprll6ZirW+HPWdbwBRs/pq6XR5h/gkxot8L329Hl4cVoq2WDw3KY09u8ltv0fd
DBdqgzbXACVi1PB6B5uQT9IbRYPzTmLEjXI6/9xF+JCXfLSLjPCDrXoEuv0+Je7115Pdc+vRSrgO
r0vH5tqR7bLIj8266hnnBX2oW9G+fnkxXsfb4WvJ2s04NvWtyxgTf9P6+EPWJzgrN8QjYFq95wx1
jp4E+y4gesJ8+UgGpcNhAC9k46fA3SvcpUaScG/6+y5Mb6ai/CfI/2Ni+7AifqNQwBAYni/fAOog
tMpUt8/K46QBBG/gLaUYOy/o/0UYae/y/+t4/U2K/qT4NRAE/iUZBxBA6DB2TA/CaiUgpysXAhAr
BeoFAofyt5BZCUJGa4QNA4YSUhBRB6xSZM2g9QL43wXKJe7cN0QGXKde2KYKj8Y4PAyK80X6cS8F
DKPMyez/DAVLDhC0t2SdDozQR2W+M9DY9QnyNmzHDQ7eKqScM9DHD8KdC7CzDywvEU7cl2WGPpAK
4mzRC2ZsYWQMxmJPDCQCOzDIL1DMQCaeydFAqESO/UvdDcW2lSJfE2VKQU8FEgRyKxFiNrEaQDFR
EQNmdUjwzRD/FnE9F0PbEmwUTlFvGJDrEiUwPu/UIEJyTatXFPGabwoKv4SOLwPyn/CeQsxFG0v6
NqNTGynnG2vwKlGeNkvuVHHMk666vMwzGc1YogvMQ8JdGeZOxKvPGoXMf9GuuNH1HuW2JEQZGenF
IDGnGeTA/OtYpuvGkW/aa4pbGc4ku4kWP1HswkamkhHhH2uWWvH/IwpoK0OhFvJDIlIcuWP9JEnJ
CAtuzgNocavAtIM5JetLIWpLIsNYsXIgWRIaJDCpIYNopK6C7Wi03PKCT2gKjQYqLEOgv4jANqBv
JmYoU7KeOtIHKm98KE2vGenyjOzlIbHQKQjhKO+YI/LGjC2dK1HMNYce0xIHLYdYjDKjJM5JKVKN
LQMVKLKYJ5ISiOhAZVHENyIfKTL+7cseimzy2KbCu1KeJevpMWf9Ke+AvRMgjypKz/MPMs8OZlCy
cRL5M2JOPlMkS9GeX+q8NYj9H1NMdYWYq3NKYg+bMAyEPqnjMLMoJBM6f+mqoE8EjKxYgLN2zCvT
LmomNu5+Y+36JO143QZI4Myk5jOanufs7AIMceZ7F6vS2U99OvOoSu9EySyKjHOtOVC+My/6r4IM
2vFbPE17N4w+3UzBN6mA5aAabCfynwjwrRAmyuIQCXPrOmBADuBAScLmMiPUOaeCIYqwJeZkKcDY
kwQ6YAjeBBQeUYgSQmOFQoWqSgPSSUSZQqNoLoTYPlQe7Wk7NSMCJ8/acGdozyJnQeomemVfNaLt
RgdaKie6J6KPRsfDCKcwVUJHR4LO0aYCIaJ+ZuLYi4IuXPRAQK27QO21Q0XKLYYyWeIRRAVacYVE
SXRrQ2SvQ62sJVRAfhSqO7EulwIaVoIuXvSalgVCaOJzTFEKM+KNC0j9RAjKgjEqWhSxPSz+SCv5
TaIsuSJQKXT6M2hfLlMHQ3CExOIfRAIYdAyKSvTkvNS/I2gTUqQCJLEe1sI1TaNs/yWRT6jaONIQ
pFRAtlJ5KDVQScuo/WSLSkYuLo7zPTUNVcR9LePupFKSJ4ajJVV3VvMbNknwlDTaJRV0KhVuPouo
U09AKi5m2yie/KPrWEcggS6ceNVlWbTeb3Q0mEl8N1WMJui0jgYqNJR26EIyVyMwPVXSzxJ4KUMz
VG/cyG8EYoNlVkXqzhXPWRW+4Ez+PWuNOAoKX+wqLpWEnbPVXaT9Rsey0vXnRfXqqMvRXxYkgA2a
z+cnS68y8YlhUeJuj7BJWefzRsm9MwjZY4nbYM2wdcm034u8IzYupePYq4xZRgnOoyVEOzX/DAMY
bCdBRsUzCSo0JjTkCnPqBAZkQZaUBBP8L3V8wuXeQjSOL3K0gcIKXeISLYggMAfCQGDy3yaaheTk
eBRgIOl69JFtTlatbS48MdW+Q61U1LbhRhblXNayIVW/a4/VSra1agKxakYRa0DsAaDEAaCECoAa
oYj8BhabaiKWReN0XdGe2aJUCoKBcdc0IEBADWAaBQCmBSCoDUAaKEfvc2+ogidenJUkl+xRcxaT
c3cdc9dBdFdICLcUnxGbc0a7abc9dlc5P8/SIeCbQGdKORSUU5C4YCNAVDHjXSPUS4loYQWENVQO
mHaKVUO3eumyh2NjB9e43HSHYkPVD5e7FaMMUCR6lc9kIcLLeYNc9BfcPDXkNQ/zfnQqr+LqvoQK
SYQPTXDiKSUC0ASXY1fGPDgIjEhre/SlgShVe0NVf1PBeoU7ePfsY9eqIpcPcSAalKJHc2c8O2tf
PA0AQkJHdheAJVdoCQDCDmDRdsAajKyTc252fSP8sFJmqYpFdgCECwBABeCOCmIeDODmBACKCwAa
BaXqZJcuIpdADGDCDcDcDKDJhhiUfsIQBbcuCIAaC2BQCMDSDcDOBSBaIYBQDKDkDgDljCDoBSC6
CoCUAaBeCMbxc4CoDMAbV8SYbDfKBACpi5i9jBjFjRjJeYBRjVjJFaBuBRjZjdjhP+LU/7i1j9kA
BQCoBS1KBnjODaDgDYDCDoDLkdjjjmKlj9jxg9abcdhCNUemN+YOSVXzhRj9icChjWDdjbdHiSZl
I1i0L1kpi6BQCIDTjHjKKxjODnjbjfjjcYKXc3cgIEiQaaQYTIlAKPh5h9iACmLtiJiNiRdrlzdM
LtdRTgK0PxE2QYrKIOLtlleBdpdDlzdxP+XVnFaVd7dmAabxlWSufCZEKBF82udaSXTk7IJkM5oC
+wvqq2frNo5joUrfb0Io3Qq2ailhS7okJdbQQ87cPtoKIFKiX81+PW2vo+Iyf9nylBo8gtAnQe4G
VHpTpBGcuocZoyQ7pinmKlood2LcbxpkKk75b1pYSenzp8Ow60Yuh7n2P7Itn1oOf9g3cVlRhBpR
paU0IckEKXnZabhVc/hZhdhhhlmbabhqBAL4Myv4Sm2YQxmvh/iDiHiLiPl0Y+myCpidmEDODSDo
DCDZis3pgVknj/mACaDKDmDmDCBSLmBRmJjNlDmVg6lBg/abn0Ii/ULENQPvnXczlnc+CaDnjHlz
iud6ZVl7qxkrrtjII5mPmTkfjnjrcvjxi06meAxcKjnXi5dADKDYDZGcBhhhcdr/tthcDCDlsGBA
DeDNhgCoBVc+CCCECGCJuRuVi8CSDcDIDrmQDlkSdPkZsGC4MMBjlEAbuTc+CUDeDQDcBACmDbrx
hflzlJjtjxmZlSBBmenzD4UIlwQOJnrXmzm3rfm9nfdJnDvldTnLTgYa0Zv1sznbc/wAAbnjd1no
K+aTnvpPF7go3xn+a9erpYvTo7aneroug2zhoSgcgmifojxI7QNLw4VbE/fSwrw9fk3O7fPVf6WH
wrf4czXTpbqRxlKZp6xzxfp5pvxUWpyHqHgWJzotqFS0ipVMzHedeVGdn1wuLdqfscbfqlF6YvWc
zXqzcdq2BRq7vZdJrBvlrGpKl6JGfqNvhOKBh7rZiEBBm5rhiuZJrmIpi9lrkwi0BQDeDODkDCDb
vA7kjGLtt/c+CGDeDJlDlzqjsjqmMbT1XkXtmtszrp0T0X0bdJiuQklDtHl/i9tNmLkXsHtVlHjp
zBlMLe/1c2j6qQd7MSJJWaIfdhztn3s11uSiCoDvmAB5j+BACCCYCSCOCcB6BECl2ICQCoBEB90I
BB0RiXzxrjzvcv16BQBB2yBAB4CMCeCdkvlzvFi8CGCeCYCeCl2OBGCDueIIBQCCIWBgBFvBvFdA
CSC0CL2OBl3l3Duji+BTbQBl3cBSZSBQCH3wBECDuxi1u0DTr12b3nuV2x20B4CF2d35mB20BBlq
DeDUDKDGDpvRrz4UJh4CDoB14hc/4z4oCl4tdJ3p4z43474+BBkEDThd5P4v4l2yB4Bf4rhhvdtd
dLNDwivQYFlYm9LmSulb0tdjvlc9zhv5znv9aT0xcd15wZhhweL1d3nq05d9VwNAK0jHQ5EuyQXi
SuRpXzQq9AJeP17HUuQOzHMAdaTIOoyyO17EUeWH7itqK0X+6HSuLf7vMBooYV7Y+xbQ/UK77MON
8SiYt57Do8k6iZRA7lUl8cceYooz8Kk4MEON7+cShx80OMpeIbXfLMoz7oQwLMKN7F7SNmSVQX7f
Xzg1cRqhsfvllWa4Pr78gnLny/c5hXhbzJcRmxrb6lm7cWT6Kcsfl/4L01r4zN0+rf1DmDmHtPmN
1NvBvjmdcDciXA3OJEftwT+Lzjv7+Tm/zLFtrDcdrGLDXKM51iVJ1rzf+NzlzpiRztiZs0BQCgDS
DGIAdDqcjKKSoagaRSoDSiDTiDRiIDSIIgMxcOBANxuOBcMxjGBqOBoLhkIBaNxqMRcNhoIIJFYv
GY3HY+IDaDSuIDcDRhGRyMhcMBsIBsMZLJ5/LjLOJ0DSFCxeRhlLYiVDMDY4MoxPZ7WYwNBoNxdR
hAMrNQZaVJuMJWIIjXI7LTXPBAVDHPKCMRyObqdwaWxQRjSZ4GZRANRcIBSLRkMMQNxQQTceToaD
SbjOIMqYToIDGYTcIDFhjJgzSLRSXSoSroLZVGo3dSIDRQdDSejKZM9oNFpNMdDCbDYeRAc8Gbty
LIkbjGbDqZNRBwaVBUDRbbBh2ardxRl8ybTKczmYTP4eUcDkbzOcjCbc8bzIZfOaTH0YR1NpAoIc
+VoN0LgZhmGzMDKOT0Muzo6DKNo4DYzjwhcgz7uqFApsuMbDMqwzjDONzvBAMo3NsOjiDSObNDQw
w3jc4cJOnCg3jkM7QNuzg0xWEA0DeNjSsxFDDQOO0Hxc/DADWMo8hSGwbJWFD+uE946xFAozDKNM
FDlE4woIEA3jqzo3jM1LVxe2gxDq4zkPEEEpDY8MTw04jPtCN4xOAy4QDDIkKDEN43jpNzMjGN44
OJMMUM4EEgweEEjjzAAZBjPTpSKFA7QKxYYrEHIUOI0ozQBAQxjqNkEjCOY1okM0fuK48CokOcxt
Y/AUDKPECjG28PjPPzdDmMtRjlK7iPQN8MDIwo5wi6SFIYBqAg1lbmRzdHJlYW0NZW5kb2JqDTQ4
IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyBdDS9Gb250IDw8
DS9GMiA1IDAgUg0vRjQgNiAwIFINL0Y2IDcgMCBSDS9GOCA4IDAgUg0vRjEwIDkgMCBSDS9GMTgg
MjcgMCBSDS9GMjQgMzYgMCBSDT4+DS9YT2JqZWN0IDw8DS9JbTMgNDQgMCBSDS9JbTQgNDUgMCBS
DT4+DS9FeHRHU3RhdGUgPDwNL0dTMiAxMyAwIFINL0dTMyAxNCAwIFINL0dTNCAxNSAwIFINPj4N
Pj4NZW5kb2JqDTUwIDAgb2JqDTw8DS9MZW5ndGggMTMxNjENL0ZpbHRlciAvTFpXRGVjb2RlDT4+
DXN0cmVhbQ0KgAxEBnBpCLAgF5HKYygZzEBFLANGIzFw4EA3G44FwzGMWNsSikWjEajkWNgNMwNO
MSEBpEEgisXjMbjogGo4GguhgtG41GIuGw0EByMswkUzkogj5XEBuBowi45GQuGA2EA2GM7G9Sod
FplOqFhnQgqBriVTHEWGQzG8bm82G85GEWFoyGA5Fw3q1Eo0ykk1j5mFUFKgNF5GhkCKkptYurlh
EGNrkdto5uMXxozG1WKkfqEEGFUn0WKhjp9UGQ1G4gKh3BpbFBBOp0NBlNx0NJjMO4N5uEBXFIz0
I2FBp2ggIhpM/GMJsEApLpUJQNFs/GA0HECFuhHAwjGsImnGE+1elBooIZlOW4M253ZlOYpKhqBt
4zdk/H2qw0+0WGoco0HIaM4j7ttQxTTNgIKlDCNQ3jkEAxjeNo4N62w6BAN4zBAMo2DKMY6DkFIW
hqioUN63IQDnD46ha6DpKeEDqhcGIaBkHLwOo0IYBkibWQSFA5OMPMRhk7KNuLEYYhsFwaBQ+Lqy
ZJznui6apv+nz8Co8MDBg68cPM2Awtm2rbvc3g3BcEAkt82gyhBEIwjI4w0t6FMaxoFEXSq6krhz
LMZxrG8cy6GAYhrH7xNS0jXTE5w2jK2g3jJIqZhvE8NxWMY6yEOkiJmGoUBZDg8DDCkPIdDUXumK
jB0LQ1Ex21LOUaFExzdMzdTQEAwqJXgQDJIQ7PULgZtTO67ybJ4QDY3LbRXDMRT5VsdKpLyGPNWw
QDgMI5jnCr1zUKja2gNI3DnEI60g26HV6Mr5PpalXwQ17i28OoyjIEAxDzXjfVuNEHyHf19Xcgbb
PVPcYXlHdr0TWw2DZfowjGMYyjgOl814hwzYoOg6ubgk4DlMgzDqNk1XgBoisKsQY0OskmtWqAlx
iJT8DUECJpiO+dKgJoQC2LqoDIBr+KA/wYraGAZo8Bq7NW8iqabZgGimwjDCMqzFJS/T8Khr2jht
pKKabAlqy9WDzVkGjytcFAiw9EA5RQMdeTJC8zzq3w0oc+A6DCMVmjm2tKPnlbC7E/yqyat6P6gm
3GBot6T6uITC68yGwv7yK0Kq1iPhQO7jDRYDlOY52LPWNNis1XT4BdlTDsS1iUqhGYbxqGcc1kGt
aPPBc5uXwHUvU3HWht14QC5iA5jfCLmw9fQ4DqMUXcP26f0FMDwthZoxhaNYy371Xjhn1z31TCHh
dRNYiDmLgUpbdtVgbhlrR5RLYeRD04DQbtXgdGMroIcHR57zlIIWWKscGKyQZrLQeipCa71pquYa
2pICDwzhhDcGkPRu29wLBqneBqylUh3DcepwgaQ4IZUyHBD7rHzvJfqtQ2D7HiLAN2GF5aTw6hjd
Kt1X71HBIpfEHl+LsYKnnCGHIPLGA3hnDkGEOAaEUhvhhFNNC7VfRZeuvEwYKAzIPUgvo3qEXjQy
fRANODzw4N0DsGkMibwwsqhsCiKwZzaoQQ8sM5yGmNhzU5Bxi0LoJQJhTCJZBeEnHxiWbAN8KIVR
WhabSDivw5hpVOGVUYblTBlBetxbzClWQWfwthIAd0HvTDCGlERN0TRKRgYdrbtUYu4d0oSC69G2
NuPOcl4bIXyxqeS+lXivm+yCY0vwrqEgzwdD0vllT2UaI2e4edgDAjcOwdkYhnUticg0aYRYqCW1
FO+NY294Lp4czDeQ8pvr85lOGPoC2cM40ZPamsjk2EzIeLpXQxo2krgyAtW4etiYbl9TxDqitfUB
oamDNhG8MqwzbyHDKhYEAZm6BtkCupcwZ1eURXqx0Ni0AxxOihFKKkVm7Rybyp6HoZQXBnBcqOOs
SwUBtg4C1cwLU3AtDbHIMj/TduADGGuJJv0yggDyG8Osdow0NTem4loboxhyp4rtcyv4cTCYTVI8
75o11VeeHY5scj3yYOVJ5j6voI0QcOtQFDyKFP+TfER74IIjyGqepyq7GaFTSrmYNhoMpUKKBsth
WpRAxwsDShdUdf3oG+DEm+QSIkSLKTfICq1MA3IjJInqkjDXdtrNQDZRBrV6m4plZ42saLNEaVDW
SYrGZFQNRKDiCEkkIWXN1VR+pHSdA4NUZEjShwaWnS5BexLvZfLandDOeCqQ3MSBBWhZrBQzMZQg
cYED/z4vYnzNVQc5p+hlNs8tYwMg3BvcAkKaIZIFu7eZV9iK/ZMzPXy/FfaRIlrzf0tqx0UZoMam
yp1T5eAcgoTU8wKd6gQBGOUpxN6TH4v1lpN8xctyfu5uW7w1DbZ0r1XGm8IYQQUg1RKDGuqxoRlx
SQfEGAKEIxWDKhtkwbkQN7fnG27J6g0hmX7aC1yRHfJ5lkdN2eHHbXle3iJHk6LWGxtlbZ5WCWBv
MxTf6eMl28xfftGGmUlkMVHb/AV59n45pmtehuHkXqxKFBmmA0ysrF4lNg8430EURzhROHKDc0IQ
G9TUgt1QKbaAoywe+kihQa3PNQf/PStkyTaX7UOPQdFKkaOJZdfypLvSedShNbkpMxtoR4aTO+k7
Vq1DckQHBU8GqjkFEBjYIArLIRKpfIQU62gsUrg3M0LgzQqtlqh+7adJZTujo1jKKj1RxYsHNUcE
YeYpKUcoNCGNQQcznLth65tRshg1ByD2hTfa3iCu1CKD0K5ijvFpN4TQkhTWAxdXodF1h0XFbHFI
KSMLKkUkxUONE843siGbR9zsB47x7GeeMBsgpCyJXglubcjwupICimNkV2134pMlfDppgvFdXO99
NYkxQCb/SHIGxcjJD4ERq3mS8PF5lzObASYQUBZTualE4dSlUNQwG8MTgKuw8u1HJbb1XvvhfG/W
amUeecOWzdOstG6Oq/wLM+D2CNLpC3lKZLwNJeGoMtpXMsBzbKULrklUMHO4GpLaqGxwZQ0rDSLi
woCT0WFE7r3KnZ8NldmUNnZRRl7WZ7DCGc+HfSKJOQf31EsDwyQ7diXUraeQgr/DJUODq6ItVxie
Gnw+qn82o2dpU3V+Z5L4IdfjK8xHX3W4atZJasTUO50rZd/4bEN2wgBlpT3Ai2pOpxQpIoNjQqXd
GxHvvNgUXv05gFhoNChc+vwxLvpeFL37tCXUrHf46/kKnA/rVt13/kJ+cQOqZg2JF1mC62ptcAML
8RBic7vzYDdDfA7KoNcKsuMOZs3uMM5E+GWEYjuAbHdjuAZChCymngZEmQHndrVCfgZi3lDi8GlC
6IGiKCsCugGi2EAgcEcAZOBjLCrDAjBnLmsiamuCJDrQJj8GXiqChQJCcmXwMkbjHCOHQCWDQPeE
ePGG3lxlzA1pDKrPaHVMxHblsLmn8F6NGPbK1ohMwG5EQm6qxDiuNGBjdA5IzEIIeL8NwpTsBlgu
9liMYOBC8LeCHHvlnqaH6wGAoiVCWCXGnjvDHCGC1mlwVmdAciKAajrkZC7D7EfC+L2iqPdnfQRg
ciBClgVCmi+iRiaD/CcCxieCfCgChC+Gdiji/mnCvkYitipnPisCtCuC+RTjICoCBGaioGbioGcv
ntKGeiQiggQGgGhGiCCiDiEgpndgziHCIGnv6gcjJnJiKljClGnjNiYlDjuCuHKwGwcK+RpEmCLR
qiKiuHHgbC2jNDVkakAxmGqwLQRsWGdRPrjHdiTwLCSFBlDipkaihR5RpxvRDxwCGCTsnxYxtjQj
hChGewKxuisjIjhRHkcGxiNi2EZQ4mlQSghGsDDoGsnGjDHCtmviriqAbxAJxC8gandrEErsQjOx
sxZRtiDCECFChRjiHiIpykgD0rNM6kTD2Ezv2rEC2reNdvOknIVG9w7mWyPQKSXRiRjRkCIrESEx
AAYi8AanJiriSSIgWyJjVi+SLQYicjLEcDIEmDvSRESnJwVCsiqGxwhyBCBCzSlSYCGyZkYvGgUM
IrNE8EnA0mQgnF1LLlpEYQGSBSkxhiFSmS5yniKyFRFJqirSHnzjVyszFStiiyunEyOSwj8SxyQy
FubJ0C7P3jyjPSPS3RhSXgpyYyml6tgJnjdsLAQAgg2AzvKjqoHnSA2yjSVj8S3zCxiy5RkzEjsj
EkACgTOTHysStSKmsSvyOyxSQSRP3xeypHtE/y2TSSWzezUy5jYAkl7j1IesEklTbFPMMwFyjyBT
eTTzDzgQLTFDEi0idAbwMyrzIzkyuTlzMSPTNyREmFBGdDui8u1yVS2zsTTztRkjYNdyHknK0k5q
ZAiOVzzDxDvRtTCT1TfynT2zhGdOBityHT6SJTJzlSvT8znSyDIrlv7QSGlSCC1zrDITSy4TUUMT
Vnqg1EPkMHmA3k7iclQrfTyzAzzyIQIEaRe0LSl0aTgyFElvkyrSIT60RT70SSwT9TnyFkSjLCBQ
PQ/vtzR0YUCxiUDiIjYAoHqk7tFq9gljgvwOPUzllF+k2OGDhNAu+llKtyi0JRckcSD0ZT1iIiOQ
NkjDIkvEmmnEbi2jNirLEDQkex8mrGnjLCgD71FidEaxokbkmEBC1LiC2R/1INeyOyTjHC5x1RmR
QRAC7CdNKR5VI1EjI1U1GmqiUiOP0wd1CEAQXVIC2vdklz9mqmr1D0imdRp0TnH1TIGjExprliTV
PiKie1hiKDr1HVMSQChUmC80XVWVdmt1iTOSAAGw8iViBQ+EjC2i4ndoGiNCeiGHHgcDKnzmfV1N
IrkSf0KQfGkFEA81ICNQJV0GmCgFBx5T4HPxCkmyq2BCNWCC8FDCBR5JYSpCLVTWGR1WHkAV4ySV
PVyv7SqWL1116C8sQ102MLsgGxYSkUwTDUkpYEekcWCvtFEDQjsVFVGCLC+HbRHwISPCzFF1sCrW
XSq2YgcWZriwS2bkeCrT0Gnj/idV4Wf2YVC2h1BWbDxM62T2d2ljL2nGY2ZVB2iWpkdks2kwLVGM
SWtWg2o2aii2jUjWdRpRcihWzWoWu2pW1DxDv2xPywLCBW42uVYW0iUDxTMjIWdvyi9DV2+WhW52
/2bwRWrRpCpwV24PJ2gW5W/WijTmX2YW2wLCpiM293J2n2+2aXLjQispyXNwHri2I3QWt3E3LWvp
qiBW8CKCtlEXEW0XSEaWOW8CcjhCGXb3FXc0mXHQLCcju2W3WWz3g3YGlXBTdxpPLvd3gXX263Sj
H3ULd0XXp3R3YC7XNXBxuSIAQXt2vXq1K3T3wQLRuyI3yW6XAVGQhW8RyPtXx3k3K3uXzQeXiRxi
Kks323FjTlZ39iSLj3/3cwLXnQKR5iKxe4DXutZ39i8C2XP2DXQ3XX8X3idTq28Q4iM364K3W3cX
YDhX0XnwVyCLjYP2X4Q3l3zRoWxAbxrXf37XRXy4Mnz2c30nciNx04HYXEB3iYdgc2CYaYL4bWbw
OYExtwVipu0Hd4fYbzOYYNaYZ4QXlXqYb4U4YPJxB4oYkO14twg3JYrX74jjTu0Ygpw40YvYz0XY
YSvjsYVXKYa33Wbrl2kXNienG4x4V4r4MY7D+Yg0sQSY2WYwSYYEpS15CmZQb4dVM1n5FjsGZ48v
k4IZF3v4TQWQU45YLYRXzCfYc5MiND+WfYi5PYMtI48YdWFmmZOYWYsWbyS4lWdvO3/ZTYW5UWw3
N0AFDXD5b5YDTnfZG4TUANI4+Y54jY65g275djrQhZL5ZxlCfyS3V4yY6YADh5W2xP6jr3bZf4/j
TisZMYFP6sWYKY+4y5lDh1BZt1oi35Fig3ZZdxDLVZXY/YzDh3d5di5TOZ4Rx3iRODVXkZrZk5sT
i5okjESi55S6CZT2bgbXr30rjP7RC57Z06DYY5x4l2hEaaLZr3cnc4S5yQL0KZFz5Z5aJVd1LaTX
6Zt1EEe6PaC6QJ0Ztrk1BaTaIaANPQOaY6HDTiMiGZtwPkbae5cWb3a6AD7Y45Fju6RYl4h3dZva
G6jDTtZ6UYTaoDN4q50aP3YAcV4WxRJ0i6B6uaZavYgawzQ6Gay6fDuNKawx76v6i5gDuYpXNipC
gayZka2iK4ta7iKSpZfap66RwZJ302C4Y5j5O6qDQxJ3iEBVK5z697GQ/5Q4FbIaQ655wbGjNbHk
SrEapa2bKEBaEE/i8xoZFgc5D67kmC169bF7CDLZh7LkmC47Q7J7Y13bHi2jU6t7cZwar7L1zNKY
2Vww9iXmoQ/yFxBRzWCxDihC6lkisHdxGrERHirRI68xKWSxLCnRRi/RNCbROCtRPxexRCQ7wCki
lxLioRUy1CryFCeRXCvb2TrxaAQRbAQRcP7HPxd4GChRfmhlgTTUkSZTgV3WQV/V5V2RlV38FWR2
NDuxzGdmx1819idWQ1/rFkcWEb32tcO2FRH2G2lLk2LWJGX2KcSxvC52R2BO72OWRWPWNVz2O15g
7AGg51wQ9Vx7kcECgiRV1C71L8Eav8gC88hcZyFavxQHd19Ebrk44z5P7XE8XDHZ63UpxR48G8rF
ESH7VcOWlHtVLcvac2HcxChFLchcqyziL8gwVcfco83WSWTWk0+2VHtAZihcsZtaL3SGY2Jkd8UY
Fby89PJ8+au3q8/rEdFag4ltIpq8u9DUidEX38/6wGp2c2ripwNCr9JZX7N8/6WwdQb2r7ALj899
J6zdE2wQJjRdSWlQRwH9Okm9D9VdKkd569cXNWrwey19UdP58c/i9dhY8deTi9C9adU628/7dEd9
m9HMWiLdf5751c/2LEd9r9oGkTHdPdqZsGYoGywkachdBz+7Hdp8+2v9wagkadG2rwLu190dKSAk
aUiEfdB7eZW95dbd6Ea3ZXY4TDVcjyHdu909V3dd2R7eA1+cx+C95wG0i97dZdB11CGd99l3SjL+
M9XjUi8Sn9Z8s9gdq3S4tEaa/WrvwRoeL7GdwbVeW9i23WmDV+V66GYi7WkCdHP4FPncE+Qda+MV
KmZ+g4TW85A+adQVGZ2CdZ2Yl3Cx2+j9g34dxbXeiXIdudk+Rdv1GWnjU+qi8j7+oeRidZD+x55X
CCKYmefdleWVGYpT493RpXaYPew+tLi0iEjdMxpCc+8e1es8/VGEBebfA+diciM+Cesdve/iNxES
CfGem7Pzq+6fFCOWn/KeiLdlYfJd1UW+cFjeYX1fF+r+Q/E/N0nmYzIeiSoe+/SeD88pyCN44+dx
yCa/NfW63i3TM3CSfwJfV+DdbiN+hSI+dyr/e+HixGqYUeiObaefa/fs69//n+iYJY0fm96Jxd2f
r/pCKsSfq+IYnWt974l4Yi3QM+Hd+fvfeWY/0/xa3dpfzegLl3Q6eYFYdjNdkfR/ffra0WDfP4d7
dAbCADMXDQYDMQDCBjgbCAZQgZDgQHIyg0zA0YQeBjWFwgaRqDiA1g0ZDcZC4ZjeFjaBQSDRyFQy
HRCJRSLRgaDYbzacR+QyOSjgcDEQSqBwWbS+Gi6HxGJxWLxwbxCoVKQSIbwIZjic0SWUeF0mlzOn
Ucc2SeVaBDgcwauUaXV+Y0yaU8XDWMXaLz0bjSTDmIW2Wwm4UqZU2awgajGhYjFWeR3wcjAaUOV2
7BTDCXKx4gZDK753HDcawOhYCvZiw4a6DUZ4HWS2qyPRjkYynK4EaUi42LD3UaZPEb/QjaB6DTW/
UYW53ca8C683hi4cyPKUXcbrM7zVja8XXuaEbwPW9Wu8iwcrN3WUXf13mreG12Xj5fz5rejWtXf8
+6RjiBo68jLNywbUuWxC/LvBD+Ki6S7PnAbkvsugbBgsqEQpCzYhuHKMts6zTvq7SMBsz0LxLDUO
BzEkAuvAj0N6lURtgnocI4Gy/tvEDdtVEYaMWFwbR8x0aukq8WR07MeQuGsSyBJkhhigcNyO80dw
NIEYwvLLYqC6QcQdHMqyTK6cOdMshpKGjaSo+krPTG7uzhNDpRVNkIRDJUgTrC89y4gQahgz0Hux
Ar0huGCNhdQ6Ny4vgYBhHEPzFQrehuGKcoRS1MUauoYsnQcXQkjCSKlRSlv5L4XBgGL5TDNsx0MG
cLUVWUhtHJkwUlV9KLo0VRrxLjiIK0tXTvN1KhtH6UMXYK6pPO1CRfXqSVHalUPCyVBWLaNRUyHD
AqjGaRK031IvLXdpVGHLnQ24EuP8GDoVBCMRIRGrnXvIb/I9ec8SuoLu4BIcOURXNz2NWDehwGVE
4XRkaQ4GtLWhUN6hdb9MYvZ7+MjVQbq3beKzyHDcoxkiqJ7jr8LZkN6ZGGtZy/DOUyjSFzQFbmLP
3i9N5out14pl1/1KoDHOmF1iV1hFeZNNd7ac2OjwpD2D5zPLIybrGjIExWk6rkUrtowOxa3IFL6D
fz0um5216MvgYhllmlatsIZu6tdgZSvkSVbuewbUm6MXXh6RBy0YYhnT+W7S3vDUTx2jNHIO0WOu
kVYzy+jOJT2qZxv/GqjwXQ444juW1v2hbUtXBdXjjwhjiXKYSi6hWZlLwhtGN+2OKIGjiBqhDSEC
RBg+DPbjbDqVZP7JBAFqGw5ZKDJmGbO1U2oQI0gQbTWNoGiuFQQDd4C0hBj7/BmGKIPwvjPBa0Uo
8mmfEYv80GfSiHvCv8Saw2kqiChtwec/4uT+3xlPI+UIJZNQlEfDUXeAAdwQFpcmE0EAWwukXDIA
0IQWAQAvCOFMgwZw5ggCKFhcbuGSoMUOWV7xDzwrfIhCxCpDFyKWM8t9IANCDB5cKf5T0M0/kvDZ
Ck6R3zTRFhhEdBx/kVFliUYlpCnihxOe4CCKKUTFGThpFCIxHSyxdhtCqGZ/oWggDsA0ObwAQQNK
FA8hAMXmwSMnBYkRRAZNnUuaNQIIIXncN8QtS5xAcyFIYVckwMiyvqNGDQnJPknF2fUzU/IYyrEl
IbIJDaqjvkjUygBS7uHmsMQ4ySTRxDclCksww/yJCDKXMgYkhjuVVMMBApeTBjZWMXLXLckiQC9g
glWodJxnpcINLLJAzsry9tIkOo5KcsGLnUmGXxb7tTRNIjzIc4gM1ky+OIaAkchAZSSJQQmVRVpS
uBlDNOZM2WJTYKwUsx5z5NElL2XaYaUSFSLUs0iQxsiMyve4kUiE42fy+IQVkycw0OI+mwlErM7z
RqklvLQrRBiHkIXjMagsMphANCmRYpRGJXlnIvA0i8cFVNAgkuNp8vjRuJIXC9IiajJx7JMfiLE6
jpR6oK7kiESmFm+mYQIv1GodLxn828GRk4fEPJ/OWcBxXjw6dhMw8MiiF1RS6DOAE7SUF2qIYhot
OmFmTrKcUiFaEn0bOlVSnT8I0LjSjOWTUjWSQ2pjTqmldQxLjqRMZj9LX8rjfaUGXy+4AVrRVTmT
bdiF1rQpVo6TJaiWDl8thBERbAwIdolxKJiZsIcjzYch9o2Fy3S6Tisi43NqQJgQ5I1RHoxUVYhx
Z9RJrHffUvZ4tPSHp/l6peVqU6iWjMape0z6qekVkUpl7BDUokdKFC9dbSF4kMNqUqPsSnDGkoPH
kupRpFFYBqXYzpJTFGejTeendGnrGKJzeCu8PCGPWNZMktR0m7Xcq2VkEFXlhJfJgSVvlwmOqWLh
dWWURSnUloXLdo0cToW5KUkK7F0pkqrP/cIhSqj8kNwRIrECt5xKPPFgrC1OZC4ZKFZ6xDF1v2sa
eQamzh1V2sSiVeL1qVFJrfUSVleILRpGkmrS+uMygSvSIWog2Mo4kYmNShjxEKX3wMVeq+biI/OF
kw5O9ZhJkm0SlfJeyT73sdRuUKPND7psdfVRpVhSpHlAS9m67riCDSrhulOPJJZClfXIxIyceaJV
7iWR2R5imkJqpCQ99DhruKZhrEsv2h0KpAxre/QswSGytdjEu1JMD/EKqVISnmoWLvNz9OHRSkJe
VXnDVR6BSoqaec2TvW5rM7nhfTdwvhJ9D54fVMm7puaGrjYJFe07P71YLl1eQrWZWuOwvzezL0lr
P4Uds8CThBoJQUjq8Oct7JvuwQvjuF5zTnzGIJeUr5uVFWybgvCbdUTWFKqfLd9KitD3pxpv4yB1
N9ObnY4lLDx2YEmPG4iTDE2GFYuc3A8Jop9R3oWnVxGw06zlPDI6nKPjvTJ4aoitqgEgY7lXw01s
r+VGtvUkw4pOd1cO5nuh2vKkKTp27aA2Mjop0532kzHBIuhRblufjXFB+VHTou//fs5XJW4RJLXZ
bDKFw1Nr1LQ6QYpyS6ZaeWbb9sVZLq3HSPYMty33owug6FCTdcI7LXhnVeRx8NBy0hHUFPd6eP0m
3Hb56eC6In/tW3Cau1ysofLG5t6FRiEqro85aF2KlpRom5CS7MSSLV3pFD069yI6V+KTDCt5EsVv
q6pwurkE4Cn+K/crFV434QvzyGyy8tfa6Hq5nZH80PGThVVspylY6hIgo3LfZRhJ+awhm9EVF2l+
l/zUZmi/Kz6A3n5Hz+d1Bp2qZoOXQwv/B+KIHxuhJ1SIkHmbNSy/tQB7zfgIP5czOIaInKDI5dO/
ydi/GdC5a/+/2n4ZKnKfaUEt0l0ikhqoKfSnSqePgJTAWzc/OIMn+ZO+ika/EMhAE+4pIVY28NCb
em8KG76cSy+nqcQJSoWV8nqPwLK4aOmeOmyiCeyRS72KsoquDBmnEnOew7kJOvVCBBav86zCKgCI
Gl6oEUOK2SicGkOcOZKWSsuIWmqLqdXCrCjBXBNCqTUo0mbBZBPCOpCDQp8JVBklKZhBUh0V84aZ
khsIEXiU+X2xGQYRI/2OCIgmG5CqomIIU0OnONojDD2m4yDAwvY6gmG/y+ykwvTEOS+IXDE+goQQ
3Awbe+gmGX2fNEyyiKtE4mybaiUnPEufMNm37FI/yl6sKbgsnFALqfsm1FeP6WcKFFaltFq+oXgM
aqjFLFZF4xiKtFXAwYI7VFIX2Rik2UDE/F0RiSIbtGFEsl7GgwfGHEQ/sfiuRFgLstbG3F0/sa4/
IuEnOv+qW4knOR8IMh0cmvfHS/i2GeqkOLShyNGIfCIJ+tkh0MTCRHyIgh0YYzcl+nzHCJNDunwQ
Ah0/mku4A+pEUM9FJIQ+o76OokgzafMuBIEx6TqmIObD4juXgcmoK/I7iMgm+7kIKkemI/IMnB8M
9Cw4nBwYvDZIsSm6YdhIFHsMa6YZs0isKL2KFJ46msKMk9xDWneeiVrDhDYkswiUAIWyzDFC9BQM
mhfKlCNCGmfCzDUrjBrCmfXBzJfB23qJzJdEPCDBdCI13DILXCRLXC/CYmzCdCVC5BtCpCgcDCxB
jLocDC6JSurLjBLCNLbDNDRKVKPDaIFDfMQuGVUXlDtJUlaOpI6ZLD6OLImYuzFEHBFMooPF/ESo
BLFEtEcKVEgoRElE6aRErM/NSqzJ9FDE9HJFDFQrVGvFNFFFTNtFYdeltGRFjFxFoQYNZFvN4K/O
EfNGCwHN1AxOTFVGxGXGPG5GVGNGbOFGeoXGtGnHXOxGlNZG8x/OPO/NlFiqxHHOdHNDnHQlQy9H
YMnHclRHg4dBrHo/tHswMkgRrH+T+iomHH9ILICkPIlIKKzJVQFIU4ykhIIl+VZIhIZQVIpQK05F
vIykPI3EnEMlWRuk4U+RSdCYZJMNKo4Wek8SLJbLDJ8faRjKWnewRJsiAlkoE0QeyXgaLMtKBRm6
wkOWwcDRWkPKTK5DiksjWtCWYgWuU8eAaeqJWWojkn4uvSSrAVoIguy/IIWNaf+mCSIo6gmbiSkM
9JWl6kspHSILPSVS8luw8sUe8eq0E2CL8vKi8fSoex2jkcksbSSYYVM5sUDCyp7TMkcmNTTGEIrT
+WpTA6Oeq/zGU43NrTk5WJSkIdWiLTYUVDYmbQBUnS7UBIwTpE+M2+8Kq6AgVBCSeyzTyNEkEvIO
aMm4UNqLKBaMgtkJmCEg4CoAaBeCMjkwoCouhCXVBDnBMbjMUlsvo1aIWCoe9VEKqg6g+hCMmhIh
MhQo4UeKECoksC2BQCGDKDkBSBaVkKUBQDoDSDMDSDGDCDoDLW6M6OIBwBQCsBSk2BoBRXSBajiB
QDkDmDSDeDcBSC6CoCUAaCLVs6APdWYhAhEBBWghOJFVOI8MUm6gBVaivVgOlVkInVoCFVsTSQyI
vWAK+m8Y8kWbgO8IhWQMOgTWWg9YPWehLYXWmj7WsAbXq+Kx2CoDuAbWwCnW3W6U8LqBQDSDCDYB
ACcDqDaDFZ3X9YBYFZOgQJDYMhChHZahRXXUqkE0cjkJzYlVfViOVYxY1V8gRY8IYeqUUY/TQ2Ai
vZNWVadZVWdYTalZwBQCmDSDODdXODqIkBACCDYDODfW4BbZ6BrZ+DoDQDbX7X/YDYHVBYLbbYRY
VanYakEXiZ4gmbfYna4Lla8JFbAI/bEbibetWjkvZHlbVVAKFbZWaCnZZWipIUfZqksIvZtbiCSD
mDmDrW2BAC4BQDCDrcJb9Z4b3cGDyC4BTcPaVcU6BdRYPajdZapVRTQQuYna0edcxVnVrc20hbC8
pY+lQm2RUv8INdKgRdOg5cbdXYXWxXfQ1cEDDW7XsDYDSDIDSDoDyBACJXODKDneNcTdauCtDcZd
TeZYXecI8vCh5VZcta3Yra7evY3V/e3bGcOIMzMe5WPWTdNZTdTfPWlZoM9ZjZnddWrZvZyDqDED
UDKDGDpdyBQDeBSfpXkDuDdW3eJf3aWLo5eIwNqXdeVahbfebciBAY7c/cqaRcvgXczgbc5Y7ggb
iolHNPhgtaYwph5dVh9ZdZpWrdgBBdlWwChhLhcP8BkBRfgDGBACWBS5IBjXnjBXBfqCSDcDMBSf
ThZfcaRXvXVcEDbXPX1X5aTVuCMrbi2IqjMy9fGRM3mP8h4kkTUKUcnZNafcdbhWyCCBSCoDUAbA
9Y4KGY8quNmra6EdDkffNitWli3WvWzZ3cABzXDXGDyDSDcDOBBbnbrbvbyDEBSKTjUDzf3hAMiI
hcBi2CJZlWmSNZjWxcJXoYYvZlRb+fUSBlZXJXNXRXU7kBsBRkokUUUBRd6DRb9fnl3j8L4NYQBm
ACpmFhBWplMAaBRd0CGCDhpksAbjCQUgSjiePQ0znCUdzi3gveTfLgDlIJrZjknkrkvhtFjn88uB
AperAkohzTbSefSnCRWqKLXGEfSPCSfoq2CfwWc/jCggFo6v2/sSW2XpEVqlpnzUnmdpG7AOnSsU
u7SOqMjphomdPpopDoaxFpvTukUlKqoKJpwkU1Ou3pdFzTeRqQcc2xqlXqQu2/aOgvBqJG7pAeOx
eYXG7oggmw8Uhoev859evVxV1WqIrkzVAWEWorAe236kQKDWrn7ZQJDnRdfbjW1b/W/lWDpjrjUB
dl4oWz4edWrmFdiksBQCJbpfzr1njVxkDV4eAfiudfHcsIgeqQudWS6ohn48WwoPcBQB/oLf4MRc
WKrp0ZgpzZGfUJzTWu6Y/tOvYPzpWXhHkvaaQPzUcXidrauRugmzrtxTQRSnTtullgMVrpWYJuHd
AKFo6IKM8LXiKM9olbKMnuc67pyw9tNiCa4RXUmxUNaIXuoRXp8JMbOuykmIYxfoxiCkaVrqbAXT
3uAwVvclvt1spu7BNtptTq2tGaBvwkrBBYzj/rHkFkwSLk1rRugIKxodqMk1wJzfFrjmHixnVWxr
tW7rxXDr2BRr7j9ZmfSPHnLsHnVsNsQDnsVoNYHoRVAJCMQgi3NfWKMMURNSergVltPxkxBSxtzx
vMavwjktMm/x4leeLCzQRIVgnkTGlyNiC/yPGqkY8KEvC2Ir4L7umpmmDQysZgnytNqYZXYltyi1
AkAJuJze+Kuo1zEJ3TeSFQykaJ3axyIuFzRvfkazcoxWIjkSAm2l2UAlfzwRJrBwBsZV2IqdKVqg
QXg4+kAKBumt0ebwetDxXwloGCQDCDmDRtAeeoNVeMrBFnNnXndtBrMgRwPt4NGKCLg5CaLlFg1o
DsJrrlSVZmhXLfxr8MIRjxBbjlfjjmdmthbXsDlj1XFX31qM6vx1xWxd1leBADgDYDDlfmnZ7msD
wDphpj9aWKEjcBApZS2joBAjtkhgFamN+Vpuy4XBU7qLVumb2rfkYKju+1OxHkYN+LLe/gq0jkZ2
LvU04vU3opxiClj34XgQAuyVk+3AkPFgnrWoO8247iDEf4Xozt2aO0glX36ZKalHkqetMPHucxII
Y5UNryg9lCuJE5U193KUso0ikrBubRT5UtV3UL74M32MkLsvCUQ+C76uCaOKD5yIH4c7TQRkYXju
+x6re5VA0zMU84YurvIolIW3OmnzJAN58L9G6YidW+O0f6nk4pDTGwkJNs5VCjagcIwMkJyyy6Ln
3ucYdBU32m9SmLS2CijDnSm76iJ5K494S0e4D3X5E1wqh7yWd5im976T1SmmtOV60Y/5sj4v/7oN
J5sUcO/8g5l3/ZD4+iH5iUCIgve32V97Y0p60I1u/HoIWjSsC6oxFygL4UOM83bHsRXgNp632Qpy
qY1Gk32/Dy1FmuE4EUh9Y3rQa+70h5KLTbMvCJR9f+Mp/uakIx+I0aQPWjk1h+geMkXcmYx98VuO
he+vTFo3cNpSmka6h8gK1zIoru2JonLkSraUQZ4tQ7klhvmfbqi419xvmkIlG4a91vmq2BgIAORA
dgaMhqORcNxyOBAMRiNxcMocIDZBRqOISNBnDYeLhoMhkIINGBgOIFDhpCRuMRAeYsNhcMRsNIaM
IgNBsN4pFowNIYMRhMBwN4ZFTMDRhERBSY3LBgIDXPJiOZOMBrKo2balPpZQKEN43FYNMJkNZrN5
zO4NVxwOJDXhcMxtRakMapNauN7BOzFFquNRtGxzMIPAq1axdOZCOYgMJBahrKRhDxBjI8NJpYhq
MxcOZLlcbEshf8DlcJd4rfaTTqVTqhSBcMBnAjuIItCJzJ46MhhhtvEcjHIgMsZIouLhxF45hIVA
62NreMbYNpZI4iMab0oTQ+NEOp0ZTEoEY4tjYnDhliRr1cBnc/DhjyMxxqFZvhCRlOvJBogM7sjj
4hqmzupiGKaIcpKqJogixvcn6gI8HD2JgG7oI4pKLppBobMnC4XBrEAQP29oZNLBEPrvBoZBnA8I
Qq50VKtDwctFBq9BsjjORZAiJRwlC4hys0Ru8wCOKuGizOsGi9OE2MaOM3Dmoc4bexEBq+iiBo4g
alg0ts7DkBAvSMP8hkMqUFobvWxKaDkMsuM4hkxriGKGK0K4QDcpExRo2McO+EE0yfNwGzxPQhCo
BoXiMGUDhAKijowGSGKep9JIYGjZOQhiJIwGsS0erSkx8palrimiohapIYVYlgqPJVa7IEKg7gaL
YUCMNIzjrNwQJgEAiV0NI6DCNkRDKOQ6DSLgZrkMYwjoMo5hSFqQPiGQUDDNwUi6KglT2Fr4r0ol
HiIBoUDSOY5jqMoyBAMQ8hAMIQDoOQ6jnaN3DoNA0jldw4W0Ol4jCNwyBSKg1AaKgVXPbQyhBe92
3oN6B2KNIyWhh95jnXQ3WhXmHjeOWJ4PhOF1sFFmLlgt6DRh44DqMQ2DSMaoDLeI3jNeQQTcMY0j
gNIyjcOgXBALIUsiuIUDeOoQW5b2FYYFFnjdd+NXVkF3ZzluH4voVlYEEGt32MuS6jlAx2RZWVBt
Z9o2Yg2kL+FA57EO43WRq1n4jnen2/k+p7VZdm7bjIQXTsQ3DZeI7YtdwwjNaOR2GEA0DDaeEbOF
AxDLoQQbgGQ3DfYg5DSPV27gjeRBAMlhWINnFhBjgz7xg3M5PW94Z3no39p02JDCOt95FYY86QlI
ZhQF2/AaItE0quNKM6minqikEjvoxNyRW+IcJpcKEBmkNCSXUb/JqpMKxwrQzYZRFFCNUlIS49K2
1Kp4Y/rTgZwSkNGnxSCQwKiojEkNfuqc16q1GkhVoucJAbzauzY8HRkBA1kODWctANIb2qhwDkG9
tK6nKhhDgHBoTmGEqLLeo8o5uEcKVMqYlHCmU4kMOgQghRG4Bp7DOA1VRsVWQMVgbE/ij1at0g4C
AO4aGKBjDYGENIbW6h0YpBBqrZFjrJgw4VaLy3MlPXCQlA0OlzQ/VYh1V7KGjv5Bq0tpobQws4DE
sQNLVW0xabY25aTYg7N5bI8yMB8UDHEXLD5VcQVHnkVuEloayG8B0BAGaD4bQQBWBSVQ5AKILhTY
6vIOgOnmO4BQGgOgdA4A6BeC8O8qwUkKkyC6PrpYJAuDGG8NrzHnJ7NWdJUyS1ShLT2EpUoaiGpx
iUTUEATQQBbC6U8MgDYaKbBADVNRHjlFaQERgu81EjnKIqFMBr71FvyhbDJ+8MQbQzKCmyaZKzkL
NVDIaIEaIhmOJ9EaBzQQ5LaDGvxZ6xo7trcJHpETlo6t1bNCqAz84fqTmooFcUY5CwKSLA1W6wQz
rDWLFmgUGVohzBYRQNIa2NNVa80N4sgKIExI+rNczU1tBkpCGUPDQFesEXc1RqzPAyh2DfSRdwaW
dR/du1KWock3BzDhBx1obgzggg8Glxq0WbLxcs3VzjQmzSilqG2D0tl0rtaKE2KEjWPBubS2JnVA
YtgtlCwxW8em6uIixUmpYbmOBiDSzNsLY2XLyDJW5brf64AoDbHVdK9VoMiaQQgHLygQBCeE5WCD
rGKB5aYVB0Qd63zyjPEJc6+1oNcXk8KJjpWw2ikguldbEosMRDlVtqS862R5cMHdy9pXhuldOvpi
gZGKBzDeD9p0X6VkrI1IWMyrZEsoCpX9ggcw7t5ro5aSFtHBW2qpXQPLQLBNQkDSyQgVIyyHMdc2
uKxXYuiuu7KOoZw2MPbZfGkIYrJ20oM1VnNna43ZoG4a+ce7VEUDKGEMlWAwhjDWxNeQbrOgoDqG
xZUcKqPBt3SlzJEAbqTnPC4ECS5tHUw+pNOkOlRXNKfA1lL4gYtmw9DDDxPibkCI+mQ7E8bl3njT
RQnWKmBNAn+7GojCQWkYBsiAkMYZB0uNgY45WKqusADcvHAbM2014wFX9aM/XRBsd68aotnrmY7i
JQ/FTq4sOXuEz6DUSQuSaBcGcF1IQrBJCmEFsVscw45tACisi+FkBDpiFwFLRWzXhuRGTMU9Fz3P
YfbW/9VJ+1lkjmiv+LilYwKUp89KjSdAzKIYmeEO8UnkBQFN52mJ04dnNNF+xciIEHxNotV0imU6
nDKGOCoRb4hjXrBxmijwUnYIQDgFE+68YJWVBzQjsoTM+u+t+8OS5C4ro9BukzdQ5xMbu4dqquVd
q9Ig58FGmCQ6aJCp8hD+SBAzPaiDWepVz6oCpqqF6pcPIgKSZgs27jCGbxxeYmkaV0Qoh8doh6ja
V7UvJrS9C2URBvdhrnZd+qh7IDnsrbFUIPxUlqGxadg2z58uaCiKjstcsgdjLVgoddfAgDLr3X4b
tg1drdnu82tVzhtWRWmJMWJGOSkeC7ZoQZIRYaE1oM1smUXYjxpFh6/FkT8DQvFxC84qBwBbfGPo
bLO8kjTf2LQZg83vt1aelOodjUhiWzQNDh4p7D33sd5iYEDT3xTeU2JQMe6mXuvlsy4TOd3IZkql
tylYlB4eHdYcTHhLUUaRgG62fIE+Q+4Hp9HmyrV8t5PpZq9jy28qRjYzBHjec8k0tslseRMnxzzr
sSyuydmwt2hgUrZtWQ0dVBmOVqq1qlw8+A+5zXkXPShVJOoC4nKmopJNSgTeQ4RwoQwBSUJP+lcf
krIDX2w8ThEQnRgS4myBBu6aQLfzP2UJ92cT8aFlHfzNKGH8X7YkMBDMq6PZ4ksh7vIFAoBsyXJL
IgINZW5kc3RyZWFtDWVuZG9iag01MSAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dCBdDS9G
b250IDw8DS9GMiA1IDAgUg0vRjYgNyAwIFINL0Y4IDggMCBSDS9GMTAgOSAwIFINL0YxOCAyNyAw
IFINL0YyNCAzNiAwIFINPj4NL0V4dEdTdGF0ZSA8PA0vR1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0v
R1M0IDE1IDAgUg0+Pg0+Pg1lbmRvYmoNNTMgMCBvYmoNPDwNL0xlbmd0aCAxMDY0OQ0vRmlsdGVy
IC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADEQGcGkIsCAXkcpjKBnMQEUsA0YjMXDgQDcbjgXDMYxY
2xKKRaMRqORY2A0zA04xIQGkQSCKxeMxuOiAajgaC6GC0bjUYi4bDQQHIyzCRTOSiCPlcQG4GjCL
jkZC4YDYQDYYzsb1Kh0WmU6oWGdCCoGuJDkXDcZDUQDIZjeNzebTMZT0QC0ZDC0DerUSjTKSTWPm
YVQUqA0XkaGQIqSm0DarWEQY+rDTHxYbDKfjW2FSP1CCC0YVQYDDGGOn1S11YqHcGlsUHQ0GUQHQ
3nAWmwynYymwQGMynI6GkzHk0m4ziAwnXZG85Gk6HkU1sXDkUCzlGw5m8Ul0qEqn3efjEaDIciAq
ETXig1m43nc3cqHbLaHI3m86CA1mXpdTrOwNo6jm/IxNo44yDKFruu+BoqMK2A4DKN0EDcOg2Dy/
T3Pg7AzOcEAyjwMI2jg3TsDE6TvPBBwGhRArjuSO40wRC4QDgOoxDYNI5tmMgXBSKg1PCFqfhu8g
ZvQ9TRNIGCGCo1DYCoFIYuoG4UO5JQYhQEAuBmGQZDkOr4vo340DC44WS4twUrwGaKBsFAwt+OQ8
jg2wQDmPMBjKNsFvAqEhhc8jzSQBslNK0z0NQFEBjC4SHRi2TatmEA2PeMsBt+4Lhy4GYbDGMI6Q
NMTZx/IMV0M0sm0UMcyzO5UJhBAVL0k2kbRwNIxv0/iW1GMtSwawtUURJz1jdED8jQNIztmOVMuE
NNOU9UDaTs3jnuLWk+2BFg52UN1QDqogQDfXtKUtZrgWfaNP1DH0gW3YUj2I0cmNY10oWShw4SkG
qNhQOVtIoGKsLJQlDBizlEtTJi5Na9Y3uAOaHR0rsI2mMj5VpMkzPjHVtBbgWCUBQTzvTFg6DkML
eN0MlfooGrzLYqGTWFVWFrWG70NcFA6jgO9GjIh0wuG30xjYMNMXTTc2htBV35AF2YBytmRvLkr1
BRdkDIdX6pvPmck3oGIYM61F6LWzud2taGmDLjFIDRjT7PxXUMDeM1s6frzxUDq2DXoqt5bM1TM5
09Y6jY4Y22m5TmDQ5zoOkHCfhmFAXBAJO8THWQ5TSGspImtNF2dpdOwVFN4cAGOSyfrPGbXaIUhs
oAUUuFk1hlybY0mog4jrS9Q2a9r3vnMo6W1U/ASZhWzhrnOHd22mlbZTutJahw7DDHMehBX8/yJI
1CNgIPE8eOtl9J6lpVDjbjodT74wLcYzW17++0HmnlNO9YwjdDBujkGyOwfRDCjTaICDq9pGi5Ea
B0Dudx1CKzYIeNkUR6Smn1NaIcpU5DlwqKTDac5X0EVgvKZs2dgjDjYBmREGlHKjWNBzQkghZoaQ
UlrdEHOG6/UqvdBk7NLLx4cJVO5ENLS2mxqBBukdsChYUPMNUw1naYyiHADStZ+av0hmjSmkdqr+
D1PNefFOEClw5hhDOGWAakzdMSV+RoyyRWCv5SW/sFCxm3K0XExQ20Wo4A5jlF9q560JBjUrDJV7
GFqnBOIhh6a61phzcuEY5zyISpLZs7VEKI0SktbwFN36d4ZkODbGaNCs07BChcGxX8EnarWQwGQM
J/SNA4OuCCUD0n+vddQRoGBbyBRNUMXl1khA3SGDfDJ3AMzrBhmWXA60j2mNaY/L6YDfGSKEXoRx
eS92sqtDc7dNhaEsh3WSqyZc5AUSqDZKycagQUOwbbDovANzRg1Ssmtfqbw3T6dobWfybw0T+Sqr
4Fs+0tLRYBQdqKi5/T4ePCSJxVDyGscGkwyzhjYSyckT9N7l52NFWYCll7tQwhmeCnc2zACcg0dq
Q6XLnnQAyoceNLStkchjktRM0zZIoMMXses/cBVYHuKVCI36azyHVdrUonJ1qFpTJ0bGpS/Usw2S
HVYFDsXUF7K3HOMJpC60/Zi4Z1yoSHIemk6aLVXjzyCb/HWsgNagmwetPJ6qoA0rkIdAYpoZWIxn
TmdM6yPjRy2l4gx+yRQaLybDJhhQKAgyiQmcEEE5pkvSDeiN/qGGKPDPgbUN73V3v2mzHRQ8doqW
ADLFeyzi0MR4kVaOQshzaQMOku9FaVljPpkg+wLgKEdBzd+xhE7Ggx2bDgGFpypkHx3DyFwFJ2Jz
HBDK0g5VlIaWXcfIi5NnH/U7uE0IN1oExWjtXFaLFsK/tulaYU2NtJj22NrA+3005IuXsmGc+7LV
3hFMOFElRLCXANLzNAhhb5ag2SOl6XwNa3ptJy5MvpRXVmjLfg0nxaSBFLBUU0v5IyaEWJuTkrWG
ygldxCUgwQDSvnhK2VMqpVysl3xjirF5kioECCWeEJTBQ1FkBcDQyFlwQEhxSE0EAW6WsDLaToGB
FgulQDIQUg5CQppHDOQ4iADQZmlUCDlI4MyblUoyR/L8XAalCM1VYvilMDHlJ0DkoTqy0S/zgDLO
R5ihA3wmkck4Uzw46P0akjpVg75HIrknJeUwQZVLqWgHIMSBAzBpLXS4IAaE/zEUIFrs6MYqCEYY
xARmxggMYSkijZGZMFIoWoqzuY4ZF0sTkGZOD0GfYLjvQpBiEEKKFlsh5EX9MKUNpci0KgUBDOCm
sGho6aHDDMrhxgVrCVTOCt1ci2sAaD13r3K5CstZcIjpE6ulMj5yPLprTmli76gz1qLUmq2EmS1f
D8tuky45jLedV52udva8LNr7LGwdyHh2UFPZqQycpvDS9oEATg6htQKwB1G3dCFlytr/LJDdh4GP
9uhphVJmbsOru7T5qihF+1GEIw+9NWlQ3vrEHBcMv6VI41HN5nuA6o3Bxzg3HzYBTW8uBcT5L+VR
4bcI2SfOLmH4zz/LG4+P7m0npU8xQMa6b5Pp7eHKyi8t5eVTeuri074dznfeKXaraZ55oQgXA9wh
T6Dl02ASWJO/WbcE5ZzelO0cjdLbnUNv8a4JuLj2XerciLcTojnJtO7v5VvLl2Xuycx0VrDfKRC1
ZHI6WkGzz9dGS7jxvgviSImw2sDYjVNJnAwBQ9tyIIAiSR8GwsGDOdeeG7n1TxXIdKsDIqDAoXXP
I8p1Dyzefl9v8z3zFwHB5yOFT3d2/b/pfD909QeuUAYg1WAPzcE7joaXHwOD4Lp+gyNptyEwMoXv
OOe+3L8DzxozykM+Nyjr/lOx6s+a7O5oX6Bq8ey+X6amZK9GYK+w7m7q9SBQCgRuSkJI9iVwBACW
pIOsV88+cqQwCSDcfo6ycqkqLwoQcWOG22/S6i7k/i+28WIEdy1WS88g/08m+U8q5g/+801kyGyK
LqI0M42TAS4E9M2A+22OBw2Sm82YoW2eqm2k2ofY2sOopo2yr2n7BS8K6k8Q2E9+0k3QLqdmwg+K
3a69Bq7C+W/83tAA8232LaLUUC8e+s9JC0+1C42Io0BQ4U7+4c4g4k4o2bCw0JBW6nBa/oLq2gIn
BnDK+TDPBu+ZDVB05qI2UQh+h4M7CE59EHCLDs+46KDoXCNo6RBGqW4c6a9vBVCI47E5BcLawYLS
BwMrDI8lEYILDQ7K5lDW7S8mLWLQS6SbExAW6A+27u7yss74cdFG6W8CBTFPCzE1FU4PFYZwyGp8
/zEW3jBs/7Fu8y7Q30IwIYLWa8024A7hDpAaPW9W9aTgBS9g9kOi9o9tBSNI9058/hEJFXEMBqNG
kAZzGtFnGxEbG08w+cPM+gPOz1DCPJHI+vHNGHDyRu++DG/Cny/IBQ/Mc7GZEC/WiYUCxTHtC3Gj
EMBoJywhFi67H+7BFrEdDS7NEjAE8ez0i4/ZDlAVIbE4NhAgDFAkX8pzAtAwqbA2BRA7A+hvF6Ss
oWhwTfBNCtGbEFFS/kwMS9I6IEdWLgdzJM+O/3Gy8tJZFxB0y+w4LYdWKmBwLdIXDnGfHPCPCSPX
CW2c2gqo9gOJCgNpCkLRCoDk21CuQY4xGdKfBbKkYHKoBysOwhEVJQ/5K5G3IITaKAzw0OI2anLP
JrLS+2Zmm9D0qc8BD64m4rKa2/GfKgS8KnME1QJwyGIzMO+RIBJVIFBy7Q6yM5KoBwbEKFJpCG+z
HO6HE9FABBFFD26YDQ6dL48JKc+zNFMCYISmwfNVK1IDMVIHFy5yLqzqiWai5rMnNxAZIc7wuJGM
ThGROBGXM+MlNDMBNJOUSKKABsPPH9NXJS7FOhNe1i0sNUMW9CygNZGBJs4O9UdlHUe0Rk9m9qrR
FPHnJrI/Gg6rOTKoBsX6z0/xFlPfMTBxEg7QS6yG5KYGNGJHOzEzFTN1Ie+8/AS3IoIo/KWNIxKb
I2/bI9DpORPRKozLFgIFPdOdNbPlQs1iLrFfRk1skBQ9GC9PJvAfAjKDJ7AumZKBAnKHBBKNBHKS
BRKXBROI57QTRg7JKpKk9CItRtDNRxQrJbQuNGBsxm0o9aYRSDP44/LXDxLcBbCa2jLmetLs2xLz
KZEDNBL/FXKkbJKo+ELXRrQlRvPjTDK9QvROzE1Q0pFfCC57SFE24PMu+44XFIuFHYnhM5D+4tSr
FROPPPSy1QL0IrH7UHS/ULEfTFR2LRJHKobJGo9FUfTW7tDzN46ODY6TM1FLOFPIYLPNT4xkJ9VF
ROsbObVPFtOjK+PHQcMmI0kBARVlMrSJO671RK76cfPEOi/RU7L9U/WBVCkAKocLS9FpVRK7G5Po
Io0mSOKkaiBzUdHLWlP6BRHSqnQCDJQHHjU7QO93RfVBT8MnTI3dXJNZXNMXOk+oUHFgiUMZP3Xk
6FRFIjIm/HRPItRTW2PBL6ww/Yi5RdV/GjT7WFNOLWSPYJPhWRPmLbR49CIESpWhXjRBIdJzJ2cq
lYi4uEVzSTAzZpKEcxKJBDKOdxBKr1SpYy6hB40Q0VFgKEyUyYyGycKmLyykypT3GiBy0k5KM01A
+IKUy8zkKqIszsIqLkJO0sxk9Y1RMaLyKFbLVGU6MWz0aiIFbbF6cKL4Oqzg0FFQ+haSyRaY0bap
F8I2ozKqJ1FhWNXLZRR0yPLBMISPLGIrLNNvQ/NzCMXo2RTc4XTjLiuE2nTo2vLxL1V7Su+3cE0s
POwvbHPbVNcTJXYO80Ta1e0nNMdmmZEvWjZjE5Um6HUrGVUwSzU1M9TzPLaq4/dNcJNOBpNTZNQp
VTUOKsS6L3Q1NoopNtYddzXm6IDOW/E/VvVy4Y8BFNeHV9eKy7ePdQJnGrdZYLcVVVcYJ+yIMXOs
JvVjZhcrWnGK73PA79V06YujIzW5OM97dLKldO1RPUMhdXJPQnK3UNXRcYxNQbKsxncnUhDrXnXq
9dHcQxQIUvQMNLHomDX9E5fO1RQcJ03XeZgbedgeTaKmMyZzQ2LTNTgrVnAc+7YlRLYoyHYs/PgB
aM/VdjRa/fhG4PhKYQwXUFgXUJfbeeyPR4BzPY1QzXMjfrIZYfVpZnSPArZ1SWX9SbKKX9ShaHBP
L3iA/syK0Tb8BBaaya1iyham0ffKIjbNXFbDPql+IYzQJ7MdbgX6TaJMy9j5TKIYIw7PkDb0ai13
kU40z4ai1oKCIqzJa7kdYAU6z+LYPMTc3dkvaeItk0KBk5FdMIKENRlAwYKEU6Io1vIOzpVDbeOq
87kcrpegMzliIZlMamKoItlgkBHBl0jiyPFdlY3yX7mDlUOra5lzmNSBk603k/l0yjmFkw3zJJkh
moNQDQwMzE51egwhhnkpm4edm9ANcO5u60yOroKA3wy/RPTSU7Q4eWNRnaLSxmU6J/Npl4l/aeLZ
lhOoyO+IOqUHlg5LnnoDXeZzoJMky+dmiWzHlthdoBoa/ZoUN+y8KqLTopTKIqJrbaJIxTnho5kC
y/o/lTogPPbpNRmE+ppRovVZoTo2cnpHVHeVmFQ4+kiSdzn7piJqDyy9pyBxp3pYzgI4J/a1pXMj
qJUZqPpCzfbKKzQy+lo3qdp+KmsbqlqHqeTcYJorq1PW0rp5pGYQ7JqksPo7p+qe3XlgK3l5rGyJ
lqKmiWPODtp+iAzxlhgS88dnXfmEqsrGI5j/p21ALlnnrG0pphsHrbQfo0iAydsAzmwSMgUCydoM
qfoHsk0oKtba1fpBsxsdn2KDl5swz9oBndsEOqPPoNLJdmLe/s3jlAz80rOsdzBfm5lRmELgz8Kt
lyZezfk6SLlaxla4U6iAIxDYzplqJCyJosPNnxCRmEM2Sm3zt7rgUC3/lBnHnSq9osMI8taXjZcB
jllnmvkkLYI/krWFk6BxknlPlEybmhk3pNXVmVm3vjmFlW+jmrlfltl9v1lpqRv7mXl3wBllmBmb
mHvyZiyHwPvnlLm3mZphvfmLwHvVvZldv/wqLZmzvrm7u1nBvPnFt8M4OrnMNNnQzIdmMzehn203
p3njlxou1fnsKw+Hn1tNqRn+y/stqxqTsrxJphpZn7oxodqRojoZozofqHoNonofrNpnpLptpFqI
yiI3s7qzpdpVq7yxprpDplynpfyiq+I42hqDyjy9p9zHcNqFqTqfqNsdpPqVzdlrQ5s1qrqjzDzq
+nzvy0m5q/yLpbz6MhrBydqUX6bJrLylqfrTsjrjr5sfrfqRrkBBroI5rtyTPXpxr3tFr9oTrHkn
uI7IItsKqtul1AbJsU8dofsbehrGPNsj1Xotx1oFql1hs29BpN1hnptDmFuLlTxZnfslav1iSYIr
tYnsyHtfm5tiyPtmcnunlDpNtzuXt5w7t+dW3zuF1wiUZzuaOruXmQJxt3m3udtFuj25xDuqYR3P
upw9uMNQDnSs0Lb4yMy9xGyJdQ8aL1QjiXWPddWTnZkiSZce8+MzZfivexTZcvue2VTfc3Cfc/Cm
drTvaKAbY1T1W9iN3tilszPWLZhVOfgc+d1A6vUXaieXhrixDu4Td7M2N9D9eFgD4vgHhJ41dRqB
DH35dbNdcXlhqDdRVfLLYbdxfvezVtFDVxGTfDV5fHdJ5pmN43n3qDVL5zfZ39ZTk6JuIZavMiXl
ev6JYhWpO/Wv6TFLf/dHiLeN5qMmLheVKxBp51RzfcU65tXY1Wxr5R4RVpgyThg3HhQLHlhBQR7R
fN7U30+JS7fXZP6t55hOz8ZzYWJvdvftO3SJhxRI/ESlYrIvYx4rOLRZY7iJY/7T6ePPNOMh6nKz
37537lxoyj9K2ha57x6/izSNAnZsnhi5J/A1SZZ9SdjFKRjJTx5jeJ4w6rMJNRS1hfeX8TebXPIJ
62YZUXTR8l4P9mIjTb4Zc1Lh4e2rdB4ldF6Z8G3L+PeVT+dnUDcR6r9XidnPXXUWSJ4X698pUlDx
MzfBD55dM7EB+HfJ+K8UByIAMBcNBuMRAMRgORcOBuIBoMRcORmNBALRsLhgMoocjKDSFHioDRnG
BqNRAMJOIJGNxkNhAMhyN4WNoNCBrAxhDSobQbKJ9BxAa48WBALyOU4oZzmICKWAaWxQUzSZzcYT
odY4ICCbDObzkKRaMRoLhsKDSdDQbRSXSoSgaRZDP5/QiFRKMUxmIKVTKdMIFBJqMJGNBpeYfEYn
FYvGY3HY+QpDIxhJZTKJXLZeOYUNRxFByOIiNxyIJ3PcrQLpdqPSaXTaeKCSczmdTKchAXBQYTra
K9YLFZLMdDyXBTa7bb7jp5RqaLR7ze9dfoHBRBMYwNhlDohEopFoxGhBHI9IJFJJNP8vLhnGRcMx
n2RyMhcNc/pJ5ctRQ+bSL1racqArBSGzQBk3I2DSMizjyEAiKsMo5uMty4J6jCcpSgzlv0u7nv8B
rpMA6qBBsxLDu4xTvsa8bIPKybzpS9KVBggQbho0YcIuGLqNK/CDOYu7WL414pjqMQ1DKMY6NuFA
3hSGLBhQO43Nq4kIuQ0yBPcvKBBiGyKQyur9w5IMPuozoXBkGrDO2xLvMY8LHPIyTKPQFyWJcmDF
hygzRTq0cdtPHsNNW/sgqgKEiSa0AZhQNgUhgswxhAJYUhmHIUDLRL2hRBYkjcMwUphTTehbNDgD
aqw0jeN0qwmgUZS8iKHpOiLMQzEQauyO6VJmigmhBQS8UI6LrRG0b1y2sQQJ4mCFIRO6JVozKb1w
l8bzOzgQDzDzPzPPVqtAGqKWZWjsw+HKXW1Y6MBwkzpSzGL5BhWQZBw0EbvVeSBxvas8pMMaRPYG
yJMzLaG3U0aYLGGqWRiiCGBxGNkIpf713jebNIiGqDJgmQcIyzKFBzjTMplYuIhcGNk3+MQVSu06
hYS+YaOy9btwtZYc4VmcYrGG96syi+HximQYvBcYbvpoeUPBimAoo9eiPA9axpik2pzrn+r6rhqI
wtpuqaRkDv3w+Uu6AslvaPpM8bQg1/7ZoW2YFjec5lcuMIzZ+dZoGGbIblcKVfWecwxWiXQzjiyU
ql6JzPn+cWaGE73ojGc2k+dyhkv732zbcCbSGT5ILcWMPjzKxhsht0xldd2o0+cLYqjF5hkyWn3y
Gl99CgSWtHpuy4H0Kxon26BYRykaXxh2fcYsd6Yh3/Z43xui3a62PXL6k0ZJxWEcb54QZXlr8cRu
tw+yxYcINnG98Y0Fz7voPmI0iCYYhtWEMP+3w4BstxP6Pq1psLtX3nYZ4aFdoM30tuYA2CBJI2+P
+cYQJG71iFNIe9BQGy/ltvyfuesmb1n2u1ggZmEcCl1wMDE4FeTg1ZPGVqUFDylSFg4NGWJcC1Fl
mHBmDUlxYj5Q9g+TIG5DUnOoXO50jRAlwk1hQTF+7M2UHUSc++HsSopHuIpFVOrDCNPOhuDMmTUy
Xg0IuDeBRB3GppLy28wisS8xcBsQmMpIyxQ3MKRhjcb2ixGdyfNakbowEHj+DOG0ZVXLUhwe2Q7t
SFL1jxDk7L4mXFzhnGc+JBwapYBoSZZcKDRHZBimlM5mJHNLiMSU+cBiNLxBgxCUa04DSChrDeVU
PlykElKSaUcEJTS6dDLyTZ7ZOv8I0TKYMhCZRmf+WOSEhCbtFfzK6WEnWlu+hms0GUfpokwcZJiU
UupmTfT7KKYZE4OQrVdC140L3DEpZhDSIpo40Kxk8h5/RBAQOpTrAlkpLo5rrNGtqJZAwZkGOwe0
6krTrnZS6e2bcWD5TJoelyZrKH1T7eAQ0jRFzsEuPpO+WgOD3T7LGjKPbtp9mgBox+L8emIT1ZzB
yl4MaMz1Z89lkLO6cA4p1F2ehI6Zv8ZZJWeElyyU+BA0hOshllVIQGdlnxZAYveIU31iDHmMv/Yc
ZoEFWmRMTnwz2rLxlwxlaJKOpZoCaP5rSSapkaHoT4rfUs+S7KORveYDeJgMo91dnpX2Bkp6sVLs
FOSqNdiFsLsRUquNTnATrVg4RwcMShETVdEWQkkqnkTIguGLcWVsHuJkyKWDjWBLoJFS1Os3knEX
igSq0UYYrEmXTFJXEopDRdZpG8glp4xwtInbA8ERz50lYpNZJ0Tq2R0ImSO0khDJEGeIe2tUiySy
TtWWO39m5GLGtZcWQsh7MEYs1diQIDaivkhke62EsJzzFJ5e4iN8JfHqhpQeYUsrenyqrD+W8s7V
k3JzKm/lsplpOk1ffBBA8FSjk5BwieCY4zibNOi803Jr2yv9EksU3ZsHuIVfqaGG76H1LFMvC8T7
4YRqJCyyc7j4uHvbPWqpDUaHtaTfPHINmzIDZRhcgt5mIUBk2XldM9TOmjoSz5q1TCCZMZ6rLJJN
0u0OYU8yMRMj6ZFjsyklVWl5EUoCYlilU3t0PIfk8i8nSG5AfUeqItBiXY5h7iHOeXalljv+Sqes
acc59jFHYmOe8dTYvWcrGqW6lo4h0SKvjKKl1XpLGI+RhSTPqPagPPxN6Dku01AqucYjQY3q+RDU
WYYmUlT4YIvMhtVl5Bvo67WsLj6yggdTUjKNC6RIlk/TyXLDGIwkSyg1cHjRXjFoyes27qaRT3rT
F9koXOFxnUc9epavUyvkwAhWPqAREas5Jdc+1XSHdWvZkdCYxXUIQvqhDw6Irp3el3MmfMLtFLJR
ptDBpRuzpAyEzDFEnLXLzQ+lBKmUkDaTkClrNN9GFxxUKYvBGy1LJXUrbOm6pcZb5tqoM9qiPj0V
ZcybKGP2PYhfPk5CKpVsqq0riVX6zNP3fQestW3+UH0IjbmvClpxXqnW3oFx64E3rlzvf6aa4V3s
ZzzXlgXMbuSxTbYauIGNQoNjiw565o8p6cwblvKekWQvUeQF4RpYGkDMA1nqaTT9IiSe9qhlD3yP
M6faoygQWqudSaRf4KAgmyDeGMNKqFVApCoGpCkYoklhNIEQ14Qzam+M2CgOgaQzBpDGg5KvfcHW
azbEUnXkp1t98AA30CMvUBUDua8KQbw3pJUnwUGil0mpPDylVHGYCfzLWo4nUjYs+p/Cov8lHrgG
goCl4rxnb0tEp7kep1+s078IWwaX1ff/j/LCOGUN4LQ4BvQP5nzqjfFoUk3BsipBgqeSKh5Qr5Yf
L+Z8350OimC2Fu96hglL4Bu6MZ+Y9yhTvT5LwIIL5ztyfr6IlD6Yl5gQshEYg7HI+glz7TvwnTwI
2I2byr9L0B9QvLyD97ybyr+g+bzDzTzjzz/YBr/o08ABxghTNyZRxQij4zwII8BT6DuJPr66Zx5g
hDPhejvT7cDTyYMIr6mxTQMgND8gMjysFp3jQb9ryMEr+aqsFD+0Fb/L3hlD3z/7hiXKChsKepvM
Az1I2EHcBkHo0Q9TIB0KG6pikhiEDA68I7wQMYOIOoNIjgr8D53gmI7r9z+AFD+Ty0LUFT/D/Q48
F738MQlSGhLqXiXREcG4+8NMHT9MHgn8B6lpnomgg5fJ88IsDL1IqAJrysJZRYMYFJcAFANAMINw
Ojz4iByRHMKsEgqD2pJ5TD2xTZRwFApgPEVsV8WINwM4sCR73EKQiJHMQcKz+ME0LIGsFL+8FkRs
L7/wlEGLSwxDOowcS40z7rwUNZpEBoEEB6LQ+Zn4hC6EUsO8U4FEVMJRRQFEYsFEY8WkFr0AsQws
XMQsQ8E8asLcRcLxlMbapcSDrQiSmIyQzEHD5cBL9JCYKIBoOIBogwNJX7gqmKqbnEdJMw7IFppA
iBsw8Ujqpcj7qwngK4EANw0yUI66fZooiqUJN4Bsl0mBFbtKUTtgBrb7GglEoIl4lprEkKIJfZP4
M71T047L7pVxNAnT14FAOQOoNgMoFoN4MwFotAOoNoMQEANIpYOgN4EAMoNwMYNgN4OYMoEANQOo
OcWj9IlAsJlBmZPzyT1bhMcktAN4OoM4NAEErYEAMJ8I2rzILi90RZ8MWININwEAOcswtAq0BQKh
lrzANEt0scDo20wgtEtwNAqczUuQEErAOwMoNkw4OUxK9wFsyxlsvZj77oqExkx4EE0ExoMM28sY
EAO81M1QNYNwN5KM3EyczRKsy8ppCr1pf4qAjgMYMoNM1Ar4zgiIFAFwEAJIM03EzQrMJMtwNsq7
zIOErBN7wwOANM18Fs5RS8WYOYFk7stEs84cwEwU6M1gNMxSBURYpYOcJ0q4Mk2A14MUzctINgOs
KAMk4x8IN86k30WJJIMoMIMcwU6ANM9M9Y485U2Up7wMtBJINs0ZJJKQMoMgF0BRVpWZlI846YlI
JY0wJQlINSNQhc30UQEBXwLYLolAMhD0ox5h3MGapy+ZMwg1ISgxiANgBoKbtAIyH8n8ogn8oh0K
M5iB3LpEpQnk2T9z5BFEqbyYN8sEx8x4M8yIPINoNoMoOgOTzkwoN1BYOBIhA5SINYMpBYMcLAi5
RYPIOEstFEFsnooAKjtsuoiB0YvMElDr1MqKxj5TwUUQjQFoMQs4EFOQMVOgoNO8sUsk0QpctcZA
HVAYFBhKvBgR3JSpjiHwwhdhuakhGiHwHMBVQ0u6b0EgFAhju9VolhcKMVLAmgjSBRGhdhc4nNUY
z60hOyMUSZSohlVaQxpBLtYhStFI5KDRLQhY8BxBUpfavjmCWxZp5gsLhZG4vI8SQy/ypwwqJhfY
ngMxlsngIzqz9ztrhadhC8Wx/66DMhurMA0og0plLlRg75sNR4IM1c1s/hB03FPsFYNgNhBcsdWY
isp8Qs4ZJMwwOdMs80/YG0rE+IMQ3cws5MzFCs3cyEwk/FhIG0/s7syr9M9srAMIMgpYMVCgNdBk
WQEE8c9VAYqBU7/Mwo3cJ1No4QFJPhS1QA49FRLBiCdqo6YIgYhzk4gq+BZol0E5zlc5zSUqhFqg
0dd1eAkLtNKFQkjKu9pxC9tCCZaJSp4w+pHbfcbaYiGUqJndR4KkzQEAKYuFhE/Uxdhdk0x8BUnq
Lcn5AltIlFxEUSM5csJZXEC4+4740kqgIwqYrEtwmU7UyE3NlVv9hVoNwUyAMw3suj9qLp5lW83N
vgKkyIOBI9z9ljxAN0+M3MsoOAFs081IEFUdzwMwPNMtoQ3lotiIpYq0wZKU+lBcrdAcvcOs50zM
0INI2sJNCr3aHwgc7A0lT14VohBVTk3Ar7NoFEuL/NAU9k2L09Lr5YO4s9AFjFv1jsxgMwOVMVN5
Bb2c71AcqM2b182sxDzV4EZF7orxBQFJcJTU7IKgFKXQG5JYsBLcYUxR2uBlQ8qsYIOtzk5F9BwK
qpP1/0e8x12hJpEYhYFGCYGZRxlEYUw1PLyxTdP0swOYPMuQMoNsyIOkJIOgpd9otE+Vkj5ctc38
0tz1+Vhc29zuEUxRlMBSGheqQ7iIwkG7yWE6g4GMWVBcuJB8+VS1OdN1O1iODRTF00uz0kOtiwMo
PBJM0UwI2t+NwFoMsoEE6mAOLmIAFFjQqgq1zF5GLmIWN2IuOAMuBVT1UYOF+s6I2V8Ajl15B1BY
MNTst10VTlUdNgMM1ErGLIOAO8JOLMWYNM1U3INmSBJN/cNOQN0EzYpeOljtE03192Ll+r2d5t9U
eWMEwc7k3NnloEtw3V4eAyUhAtpQt1QVekoECQ08oilokZn5LqOxyUNFgMp0NIzjWZ6tXp9QiRGi
mxGhPSDYhCuRdlicuyIEvL5Y+Iz6kgwAzpLmbLWZ3IwiQyDZSrN1UaAiUYh4mMSamyDYwiv1WJny
MzLoGlUZjRPQ+JGomB2qvy39yDHxeSOZcImmFNmEzEvA0S/RhaSCqowiHwmgmmdohgzWgmir5aMx
Lg9xlOlLHyZkQRJy0DexLpLtUag9KqTokqTuJ9aJc494jTrGfo7GWk5lRLwIz4ko92f9FGMlQ4sV
RMvWacqA79R0qlvMtwN4MlmmXAEFAt4INeUGTOrZBZA8wIOgN1MucYiGcsK1gUck8AoE240dSlh5
VIN2Qmq2rApcwl9oN01+ktRccms2AdjOHNoMtYOj/IORBet0jUyAilEWuZVWpTxlDmWs2gFGqswe
vGrQMV/IEEWIOF1+wNMxVWH+Dmv96AOYMNNQEAMgMOxQrI7OOU3Imk0r8c386pe17QJMfdDZ8eqU
OuEEWNmoMs+ZB7zOXlBcyljFh+rU0GIFRtMFn78hI8q+LeJFvQKus06ktswoNsv8Wc42IE2WohwJ
NG4A1+2M48tyElS04jys62B07JKrtNw1sxcB3LGlRWqFLwjOqciVSIGlSdStS9OkBQFu+5feckvG
teyt6GW83u9OLjl3ANShJO2w2oEO+YI0n1s1WlRHBk5lDz5e3d8G4wNO5FlxJMsu1tiJJIO8v4Nl
AWpdWuc2tjwOHNO0UUmoJoJIKAOYFoPNCYOQpY3BVUt3HgKAKevuyczHIMJIEAHooGx5A+0kx8uU
qxJGugpd1420toMfJYBs9pVVBd0g20w3JwOQ4lBgMQjgMNnEwwGIFgxnAUufJj5fAmL9TeLW5Ms0
tFPNPpJO1uHOyXMN9PEMNIK8zWDU3ur1OGrQMdMU8uNJZQq0zXME5Vn5VAMYpc3sq1lEyGFvSI3e
9+3M+PLnMtDQt09pU8tMtwOeIUsks2FoOQMIO4NnQnD2pvED1l9YqGBZHMZZJhR8yL8k1GLmQ4N9
TGG25tvXV84lSw2vVI03BVW2p/Q+y3MvVk6OrXPFOtTb84Mcq92c+G8XBr5e70KAOUyHP2xNP2ul
M+GoNopeLVkeksWAPPNhBFBtMYqrzO0kwndnQGulUXe1jvIYOk+OGdNNNdNpSPgPdxVXfwN2CYGH
ig4VDN3oMNh5BYIgIoKfinik3vPdBnh/FU5Gv2/b5dCgq/jRZRB+1IM4MoHc+UyHbtTT3flE5nXs
93P/iEyHkUtvMgr1S2HTzlDEWW3nVRloqGX3RT812c+OW5BPK4NNkPiU+OLHcva7wJBIM4s/luPP
ftzAOe+UigkKXC6zg4wdILVCs4FqHqGsnC36fqjhjSjAl1sNJ1stettYn7fRn6Hylh0IhzFT9wnl
gEcbwOJnswBsiwgIDWVuZHN0cmVhbQ1lbmRvYmoNNTQgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYg
L1RleHQgXQ0vRm9udCA8PA0vRjIgNSAwIFINL0Y0IDYgMCBSDS9GNiA3IDAgUg0vRjggOCAwIFIN
L0YxMCA5IDAgUg0vRjE4IDI3IDAgUg0vRjI0IDM2IDAgUg0+Pg0vRXh0R1N0YXRlIDw8DS9HUzIg
MTMgMCBSDS9HUzMgMTQgMCBSDS9HUzQgMTUgMCBSDT4+DT4+DWVuZG9iag01OCAwIG9iag08PA0v
TGVuZ3RoIDIyNzM5DS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMo
GcxARSwDRiMxcOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRi
LhsNBAcjLMJFM5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKga4lUxxFhkMxvG5vNhxU
xnVhaMhgORcN6tRKNMpJNY+ZhUDRrMxtarZbotN7ldLteL1XZRgyEVAaLyNDIEVJTaxdXLCIM9XI
nUxkNYvnrnVipH6hBBhVJ9FioY6fVNONxAVDuDRQQTdDzwYTacDYZRATzMICCICQeTEcjSZBAQzk
eTgdDeIBSVDUDbrsowIBbsRwMPGVCJtxhPt1td8UzyczoZTaOu735+M5xdPM9D3vW2L2pq+EBtO2
jehQKDpDsMIxjyFoijcNAwjcMYyuoJowi4uYajY/IGrwGyrNDEarBpEaLBsGaKLs1iPvKqgYBgzb
bQOGrWQUJw3juEA6QqOgQDyN46hAOo3DIMo5PpCzqSA5AxjeNwWxCqAWp+GIaBkHLdvWLYUQw7KH
De5Y4DqMQ2DSMYQDWMo8hBJwQDmPI2jaMo6OlNk3DyFIuioJQGiowcwDLC7ruyNMphZOKHDuMo2D
ZRoQDINIzjSOgw0kOdLDcMMqz/QNBvBAcaIY+EwDoOqiIdOVK0vTNJQwOQ6DTDq5jGML6jnRjjjp
DrThSGK7o2FCHDYN43jXP1AUEwcZRpGrdtsFFdTi4IyuG4rjhBMs4hANDoOk6gx0Q7U5vnKrvWdU
kZhk2kbtwG6hN4BtUvtOMhDuN45DWFzdjQ5AzDfSMejSNwz0oMo53KNIxYXZlRWfUoZ3peIYNPej
e1TgIQDgOQUpyGQUDfDA5zI5Y50NSuEBSuqMLzYwyjHVbkTuOdQWbUdoRpGz2NPHTfDmMIz4Xa7q
VuGzjocMw5DeNtrjyO+AqJH7twtCMQ1GFGpyW5A3jtJcjjdlWaKI6g3Txfd+15rTB65gMoDlH+Az
gMOqjDH99hbNW0qVheh6KFm3Xtau9DeFo0SLuY27ANIy0ZfmoyBg+E4PiN2TBh46UfQ1/ioNA0od
j+S8BI+VIcMQ3yBj00ZziTfTVPc36PdE7TxPU29pQ1yuxWsphdKzyJ+G8tBnL122jU7bTALgZBo1
AUhqFwat/OeV7Fcoy11o287KokhZvwIy8w2Kt+L4YXS1LnkZ5aVUBQLn4xbpQyi4FKWuDKAQDG4+
7ggfk1NNYaClBhT6qFdgKGDv9Dqkpa6+VMhjYC0h+i3FvH1DwHRRjpF1HfZ2qVjC02flvXqmAM4c
jiP8DekpyLcwyK6Q4Cl4MCEZPnIElgvLxn2wgZ8jg97G34vPei9MGwKHQJRXMdtOh9F8IVDmwEhz
+1+KWDS6828Nn0vrS6ep5KpoRAoU8pJ8TRDkLnaKkJvMY2iqUUswsOjhH3M+WqkluihgQO8XNFFj
sanyLrg+jOEL8FXxuBAHdTEBH9h1ZUHJYANVhAwI0DRYzHkGvcTmp1T7mI/rRjkqpqqfGrP8KJJZ
70mJPMCX5HCEDyzfJAWtHx4K64ag5fRDh4oNHjxcebEI7j03qnNhQklp7dGnB3BaGEO8BgQBECKF
N3ScH5SpgQ+aWkN0spbi2etaBE2LOFdW1R2yd08prBbHhlxGgbgod8oo4KmgzuIk0xMqhEzWMXBm
DkzcQDpJADa/dly7y2g5gUy4iYLpJBzoIRSST/KE0GBQyCBBOQbE9IYVCLj7pWQ+N2gp7Z9QyKMT
klA4LonToZasiEFtEqKRZmw8gFEeHfR1b+yeMjn3QkOpJIoOqmg2J9j9PKTkX1cqRpM/t1CnEpzP
gAChgbc3KEOdRB1zKxp2LdOWlJOySE1q6cq/dbtTo9sLitJuLz8HxzPBSTMHAKF/hTaengNLN6ZK
cDOp6U5LaEQIa3TA7NJpDOsf3HxwgKElBwZW5VI4cKkv7dIdpKQbJYnflnLV4kOouI4QS4V5z0Je
lAiMx13p2YlHzPq1BZCyiHB1DhTJPjmAYl4kg+wGhsQck3M3NqHkIqNL1peHiCSFo1qzVq0lXJ9a
rUyKIGMNIcHHhujeutK8132S6gU/pjrKkkpLkbI8vFBwUmxBiCiNisFNJxDIGRVhDmknHcHXpt6c
mwnSaS0ZTAIAxJwbWGuxFqo6yqRmDM1CBjcA5aCmC37B5QpQn+8UnVD1kxvZeVO8NrS44NeDhF9Q
KAkrCodhAGQN8JAopFgsn7I3tPcryzqoBd5WJgDDgsjT1VkBjTcGQFqywbYZfJjm8KfS60TWKtm3
7CHyF1BkT+IqwAZKGbCsiwywAZ0EwZeG+88XkrDnqb6vitWWrrJyDcudFYdyAh6bgwtG5WsdmZM6
o9VbWyyy/mGll0z1tckPTJM6aU11KyEhXIlSky3+eVbo3ANotxAf3RBZuYqLoHyzZjNFL7lXMUMH
Rf4STltyOQ3c5DKr4qapQTu6U2XkoIi/cm5dzQ6Nty8Rsw6Jcx1BwExhHOkX92hXPEu0soqOsQzh
q4HBdNR0ubzjPGsdw3ZNDfYYEFTY7oPgJqjSlzl/0ompZSHMuNY1lYvqaEsQbOPSs9EeUTvrRxMa
hSKksenyTTLzNXOepLdxAUgzNPKU89htDCGlTdpF8a5ZXf290XX3rUy3SaPijKjSmZq4On+aTkbG
pNkxSGy37LGfvSCOmCuHpguwkqRgM1grDu7JOUGfbgabjpXQNzlcrJhSXcN+lxWjPywO2Sry59Es
z1TpWyK7YsS2ssl836QopNy2QdSC7Hd6hj3vy0Mb5d47bkCtTfW/F0bo4Ux3aWqiu3xdRf3h7cGC
adDKHEOrvAyn4ug+mW8ubcZkhFLvcMRLPnI67pXctous67virZ+jRny7v2xFp5DHDkHT0qphOHS+
zXZZATcz9bAQBJ6MGFN2KXYM8BpN1HCp9EMdZc9OgWeXZVKYGkg6mCNbpLWET+tfMi51jxWlrQjG
AbegcLzROLqmw4LLbEWVyQvHUlbnfWknf/acEzLrSH7hQzB5crxo6kir6dGO2krXFc1LfLTBXZmr
Hg2IPpNYtjv1uQ8jWJQd/nMfAez5fzTS/RmAnBidFCmVwv3g25pYNg6prfR36dqOirAODTjdgroO
YOoNi56DzFbqpwqv6RCsKmiNaQY+hhRBqkzKrgaOKL77RcyxDhaupXT8L8w5CRSqSskCDSDb67Tk
SRzkhYohz/S4h7hf4JyR6hwN8HR6oO8HShcHQGagYGJ6ZkaN8IrBo7iBAvBHLM6izuJGoGrzzMz5
4FANYNxHqPRXSlEJoGzM6HDwzRqebWrWY07Q5wqRKRa7YGIrKSbJS4TKDBbkoNKgh8xY0OxmMJZZ
r4IGgnosjbbI7uYFBBxNSj7GBYp0gOw6blyGkPsP8MKlsMbQcMzM63h/ZtKDKADkQGUOLkR44ML3
zxIh0Qo6bn6yaazbLuCzSXjcR6rcjXDc7vxJb/Zo0TBbKN7dzoLYcSZnqL50IM6cEGrmaSy+5H7z
EERjrPKqQjojYHAgQuYz4tY2kKLbh2LPaUD4sYZXCUkUQlr7B4USLOj5iL7v76L7kEiU76jZpghZ
AO7djQUazmBWj/b3jm6xKZIOQMinC6x0UeLgr6AMKJ6qpJBWpSTRLB6pTv6+bzRdijCL71sekGy4
xax/Y7QOBf4IL+kfzjoFCxRg6DS5DnjaZIULELRukipgLK0Dysx7D9MGL9aSb00bB2ikhooNwOpg
5yBo7l74b/JCrBCC4OSRRITmz90iZhafzsanINw6JZSOx+UUoMh+8U7a8VLt7qjFrcCIZ6ju4rrS
bVUNhYkIcGiJLvpfBJCK0qzqcXsgBMDY0BDvK50NhYahwhxV5TC8rijJzdrFRwsY0ECdZhEb6QrO
7ncsDSsug2K7zgZMBj4NJBy4zk63zPyNa1omagTraRUlaVcQZB7tANI6UwaoxwCqp+SPir0y6gKt
hzEVDtzoaEazLukriIsWEszXTf7+phTXEhstccTeUKrNDxCmas8CSuc0qpK1sDq3I+B+Kl4FwM4F
xRjNbjJ2qoZmj8ZXZb5m8FUB6VhYyMi8aQkE84imrazwkq82E2azsV60E27fy0xZINa1K1bBUXTe
E37qiOUmZNjlkEqT52j4rj5sRy7h8h85pKE0L9siUYg+sdb6ynEcFA05h5iwhmZc047yExUuyS8d
LhpboMT7zETfbls0a68l0sTkohyPk8Q+iGZZs1zoTbUtqjLM02Urazs2s9zc0s7dM3UAsA7wcXZ9
USTojBTH56pzkHjH4nK8KwVJiwiNo+gObC4GQoLDQMyf9K5KCA8vzeY30AKCTrbvEkbr0k0d8lEB
sh1CibwNyntDLkCFUBY6hCpsJ665zgUv1A7qxwCMkdcnywNPqNcjkBxwsqTS7TJupShKa7byT2KA
oOlMSmU7kzjuU5qs6Jy+wMqOzfg44M6nhOBxpSq+Y6hJz/whwogNTexDLn4IoyygrI4gRFgnTM7A
AioiwFtWwtIyR6B6Z6B47D42IGoqopQyYgoywzAqwzYlIrNW8QAqFZtXYjgoCe4EEPwnRFI3Yj4g
Q2CL4rJENVwBoKIlQlglwBoGTD9WgtQuzd4tQvQz6EJLAGoijEB44vjzonT3Nawtp55LopYFQpov
okYmgxYnAsYngnwoAoQvigoo4v4jwBor4p4qIqdYgrArQrgvliRA4sieZEqg1K0QAsw0NaAEAJdi
YJUQANVjtYYqxHwkIoIEAJoEALYLoqAMggog4hIKZ44M4hwiFc7yQGozS14qgHIoQj5BB6gGAoQi
Yto9o1Ak4/gqdZQxNqAEFqTCoqwHFXzbQk9pVYYoVrig1r1oLGNpgEEGTAAhlr4xNo4i1tVodrFc
9twGluAGFejYNuddAjRGtuCgoHNYltojQuwgQrInL3FvY/iedoi2FYFxdwttNotvAEAO1ugkifFy
Vxw0VoVxtowoQPIBoMVcVcggVcxLg2JFg1Au0I1atpNwIio040Q9onVat1AoAHItUuoGLEBIYBoG
ZGlW4gQuxAduVr92C2twwHAvAHLkVvd5An1tK2qg13NvbBkP16VX16tr9643V1l2pLt48xazl74t
ZLt291V2d1pLty1jdZ9kVnIhAhVntn4iLD4n8P1YF3d3on5GooQuo2J54yQlIsVvAgRA5Lostc7E
CgwHF71/YzSed/9dmAQvmAljoqqio2WBJNuBYilYd4eCFtOCQ8mClhYouC5Ad5uDFXeBTD4nIn11
eEV/r22AFbGAdia8AtdjsNoi2Fwnp6h9jI68F/mEmG2CuFGHJ9UKeHl7GH7HMKd/WImCN/2EuAOE
4lGJQjo1GIg3WH4toGrM+IZ9WIuKuI+LGFInQGNj5F9+DD7GJ9GMd3mKmGuE2HAsR5+L12uLmDrD
8Jtrg0WGeI2O2C2JTD+PVK2Pgsxd91OQOKeEeM2QmJIsV4GHwnVo+N0Z4oD22OWMuOuK+O9jpFuB
IjeAWF1rRd+R2MmOmCeUGQuSmPTAB4+U4igoIhmTuVmK2G+V9jq2eA8Z2WePtg0L4q2XGSGT+XeS
eXt50xYrOTKImB+R+GmVuZOLIsQGlfV8bMWRbYIoAnGVWOeY+amJGa2XuFcxZ9GU74N6uY2aeXWc
mNNoYoVYWTKdGZ2duQeV2ZVYWMNlmYObgyDD+cGT2ceNGJQm9j+MODmRd2BeeEOaWfOauNIrGPQm
+hdc6fAvOfufGSOfWct1OJ2TeH2PoqQvLQ2geXOM+UN1IjNjooOkehlvOKWVecWd+gwsQG4u+lw8
eF1o7wmlGmulWXh82eYvNYmnp6cZ+h+mmd2oWfYvOdIvIueNzAl2OGWiGjuiWJQ8+DQvWRWjAtoH
F22QWrOeGreZjd+r5LgjVrmmecOpuSWj4ipFljouOeekgvDYOaOpmiOs1cYld0wl9dFfgt9dCald
zHNwLUVeYvOHde5kVfVa9ftYoK9gAp1hov1gguBkQ8gnrJGLGzFgYpIpdgIqArdioq1i+ztjIr20
t94gVk4qFlIqFldYVYll+uYoVmdmtm9+Nnd+gh9+12F9N8t12jA812W4t8+4edmEV0N4A80Z92d4
ttm44z96Ijt5l518W69w16ZFIk2Bd/A3S197W8N+6g1712l81598d1e9d224bAF9V8FyoBoOd0mw
Alol6XG1AzWkui1Yu/tWm/4qfAPAYrI1C1+MFdF3zzouSSFtOBygyEIk/AYtluBmBd+6vC+lojot
Fu1ua2YkNuXD4ivEPC1vAivEvAF5fEVaeB3Ap6nF3AeDN6XA3F19u11kmDog1+Vnghu4IBvEfFe/
/BmOgneuONJjGWY3GbfIdpm3N6XI+Y/JOj3JekNpmr62epIyPBeIPJGm2lYqmPQquL2Dq2bHItNu
CWnMHKvMWodo3JqSGi62agPKfN2GnK2rQsUNuPUNuA/NCSAz+Z3L9ofMOp2uT2y8Bit+C2d5mAXQ
3BvPXOGp+NfJsIrWAswGkut5tZXNvQ/N/RONIjvP+luBXTgn9t/PHUPSnUeQ2X/J/TgqbAnVnSdx
nSuuQtfJtdGf/IdwF/nUHW5GvPes2PEJ9bHLZLQz+b/SXRHJWQ2S1K3M/TcJIHPWvZ3UXaGSlymA
POt3hGfNnKnV3beUWgQ2IjnWUZqEPbPcnK+JW+fdHRvVFyd53dvXHV+WHJrAHTXIddlplpvYXZ/d
+SiWmUQrfRzI42XT/cffHcsxeDWX3hO1HcXPPh3gmXrbXiHXxLYinCPe/YnXONObGPTzvfpLdxA0
ngXbXjExeUmbGmHfx6ZYfgPhvkPfNlgiec3hLHmNfW3gfPmf2iuZ3VFdIrPivVvi/oNYWhPePNBd
9Inn/lnpfGfJuMPanfwvEIvI3i3m/h4oA9FlnhHVF4B9VmPkGZ3nF1PJoGxaXshLPL3lfd3qkL/t
mU3NDkR9VXftHYum+nePQoPk5FosfvnkWJXwAw/RxiuNXrnpPr3luxvtlzPskI3SPuXpXY1jpeeP
R4vjkaItfhnrvtPr+nmqXLYxJ5/pHYf0fyArfJonvrCXFwn0Px31nqkZ/znmKXAvDD/xv1fvvMeb
4//WS2YnXZvy/x/2+um5Gu/TfTmS/2n3/w2v9cuwVdLU2w1do0Vd+xR4exletXmyAhmyVbNf9gO0
IpAmom+zlhGz4yX9Fh+ym1204qm1PtO04yV9w0O2FlFlVlgGAgA2EB3EAzFw4Gw0EBNEBbLowEBk
BpCLAgF5HKYzEBnOYgIpYBo0GYyFwwGwyEAxHMkGo4HIgNshkYuGQ1lEqlkuEEikgxmspHI3F02l
B5kI0kgzGA4lI4oQ0GEoNkypI3pgxG9CGQ4qVUFwzq1Nkg4GlMqdQgw4m1ig9lEFnGFptc4oc6s4
zGMHG83ld1l88ksnoE5l52BpzBpRBpxBoxEBpEANGQ5GgurA3lNZyw1gUxyeVGY2zGXzcCz80hQx
rklnVGpWVpEarF5HI2l9T040HOyG15sm3yWUF263lPGI1t+SG+0G8CGOi4fH5Iy5YuoPOzXHgW43
fWp2ZoXaEGny/g0ogwxXEBuBsQ9wgiBricVi8Zjcdj/K5kv1Ukpb+JKGKFBaGQYNQEA5DKBozPbA
LMPckqlvgED5OokgcpWtj/pTAMBwLA8EwXBq4oVCAYOk+LlMqGCTQ0nS8xPD0DBkhUQwZAwYBqx0
TBkjUUuoGqSpu1cNxhAQQQJGcawVG7AqZE0fQo5QbJKGbUyJF8OyRD8aQRJkRrJCccBnJ8pOooQY
Lc/rWQBGMtyVL0RQMGMTzEkoaORH6rMDIb/SzN0kxBL85tVO0cyjCobhykrmxdNsj0DLsbQaGIZz
y+DAx3MwcRw/ksUfGVBTkzaURMG0ywqHC8zpK8/VBN9RSa56XxNRsftWGNCzXIstUjJdRtUgUTBx
RDJWIyy8UdDlAS5X8mwLKNO01VLKwE5Fdz/SFmzjZ6VUMHNUWNILj09V1l21OFJxm0M7TpYVNyor
DZU/c9Q0lQaaBraLLUrCdUvC79sVfX1uQa6l2hladjBwmk64FetYXvUatwfTCfVpTdF4Ta96SNe1
nQa1923ZH4cxmydlY9iOQQMkdNTmGkSzMHK8xpedzZVgl1K/Ml2x1fzgpImrR47Xtt53S1LzmGuM
Qq7rqMdh+c6PfCwZeywbXfpzKq3Vs2YhnWqhxMs5hvmWnSCyar6LZl03wqGlMtVWgMnKi8T7r+p7
dUakVLiydZKoSRudtl0VjBqRYxOag7pcCv69Xm28PA08XfGc08bRdLchbOP4Lygb33hO/PkpWW1P
lOjb3JrdTthOmgapS8zJvHI8NiUmhqGGK5PivSqir7a9TyXcQam3RStoClIMGmo8Lz1JsUxjHMgy
TqXypgZQ/RXsua6yoyQ46DL2jUQ5imjBBorXWpiK4VPWxq0hArOGLwpiW65JAbx0FyEzipUg7809
v2JgA09R7CIKKP8QI3pKAWwKTjAc9qYiUggCXBMJSEw1KYd0QIghaX/EMIcRAiRFCLEYI0RwjxID
yFZPMeIzxwjQmjOyZw8ZwkusPNcmk4aPTMm0NsdM4RxCUm9LacA3Ju4inGOQbg6p14lnRiafo6yj
TSHiO4QZcENDww2hbFw85hjEPSMaY8yLMSng5Wuao6wNjkExjQV9HJKY2G1ORHEnhKUekHXACAox
In1lXgA/Q5McSsH8Li/0lshX1GWUUSkGDGkulnM0laREkiFSUcE61XLDI7SMKEqeNcno3E7kabqU
cbTkHpfghAhCPiDpdRTCY+sKT8EgfU3YGhzo9kuTa+BsKclMFkR2QcuLQH1JBSsamXqGFlzHmCje
Ya3kDFWdISFszj2ozNl+RqaME5quMmqb2ZDoWeH8m5M+BzVJhTVf2phs05SkrsJ8WmZyMJgTsmlN
VfU8JqJSfU7N5M9Y+TdZW5+eEsDbO+mwy1ZNBJfTPm9PqcALgboSQMaJrRITbFfZRRCe6EZ1uroq
qdYUilLnyl2/UGUvJ7UGm+hBrKJX+vJRTLtwUOZ0z4pG5NTBCVSv9X7TdrNHpt0volQddVP6gtMm
vLuZS3qQUwoohBpiTyhnLmQQkr5WI9VIp5UpQcHFbFDdbUQgxeJmVgQjROklVp+oGJsuGXZSVc1f
oLUmmMHFk1yd3Vt2cka8URrDXuvytDhkIq2y2v9U69VVUwWVB5w5S03aZHKtdebC2QcpZU4bMZkE
tjkTendIqxTts/LA2NoStT3tKiyt1PnKMJsi+CyyVDJmjtfPmt6mAZx9ZbXQGraTKWDpCiynrxUI
FgpOpZ2CeGuIZsdPi2NyrfA1poDNntliDFbnRWy5Fp59s8qCXihieGhMBt3dVllvpit1tCzVMN07
TWGJo2NTCQLQozK5caX9yb2ozazfm7EyDdE0kffS2F4qKs2vySPAzDEz3+nVgxCD2r313pvI06lm
bCX1s4ZaZzi8DW4L3hS6mFmLQuTnEHDbaYg4Kt5bIzaeTLFuw21w0WKK24qTndpizB8N3df9jK9l
CFCTFXdgZoRgsZYAyQ19HBasDM1aZjzBd9iTUnJMsVmKMwa26vBjO6yOLQZmqfb9fOHrj5kwCkKo
JUWFEiwkXO9ePoKUqLAai79msQUkjI9QyL2itSLe1OF7qVGTQOfFRaHz5sdEow4+yAz7z2QAKY/S
rr9yyE0f0/x/yIdMQCfqoV9srX5l9RbA1/SGUQwSPeRAx0FyIQZIhBuv0HiCkHhCQ0h5ET5wnPtC
o/MeI1R0lJG8o7go5ydlVKYp+EKQFMj/ntGkgnxlhLPI2Q8kCDRuLNsuR0lyaSTmxJvcj2pM7nce
fyOspdtyhyps6T+xpUyfjFGWDZeUdFMg/rwhRDHYk1awfxmh1obExu0Xk3RqTu0zILR0lTUSg0Wn
eaGtOJyVRaKYGN2OYSv4FJUji4ZBV9GWpaU2EHEXZpqIRHwgXHjQqLKi4RRboTHW/bStcvtdY/AN
CnOBCZjnSxqXyYOyhKOFHdVzw5IJcTtkhRZRaxXG077rt/t94RqlFxT510cunPiphmBVRwntWjjm
VN6RqOERjdH8LKSV4Uu0DFcWuZM6zB08Oax2pVKhyyX8eTwULqpIqLWgTw2lCRx04eJ7kc55pw53
+CuwdZmhKbtE0Qz47LfmDfY7KN0HzmA1K+fMxHDkDZir+ZIRFPxylrdN2QkWcm2IvMEGzDuv0Zzi
8a8Mx2PstcofYXpslLW8HEW7/IRwEyJSpPQuKw/XMMBX7FD8v9HkPv+B91YP9j2BBXtU1P4967By
CRkkBtb8zJoLBcy/D+k/kbn+2gKn+f8URXmISJH9w0cRmmCBPqmmGov/HhOZCloqv+t+HhP6iTPD
ibwCQAIeCVv4v8imDXu8v4kgiEiFQDDKwJv1o5DgQLwPisEqPyiCwGmzCboBvpvnQEDMvpDMOPAx
N9EON+iBtdvliFozu8DjibwDigulCQvwiuDRk6H+wLDulwJUkCjMLflFlODUkBDoiUPBEcpYibwj
rJCdjjvLDnQrlTiNCoChCsjUwDvAAQQrFOwjN+MCnaH+o6PcOUvQuhNZEpQ3jnIACbDOnYtOjjo1
q5H/P6jNCTI1lqvZw+jKnQw8l4jkw8Q4ihuUvgHjPhsHmzoJtcChvkwcteiQlVMEI9CSGYiFI4GT
CDr5vwxRpCumLSRRPEDhDdrSKMsIOGjrNpI2LfuYiQxYNpJIqLFkizxeQfo0o7xWJIQNFiCdxTGx
wzRkCNPBRPvuwwRkpKOaFLRjwkQxDNHtRhjhtjn1CtHtJIOblkvBRtxxNnRcpCxzxZKatJFFEqu7
xXCFCymardR5w0gGwaJXP0phpZPjKLEJPlROiRO6o+tnC9tlDADdQsjaRvitvrQvtvsTtqi8gbLG
wGjjjHCROMirwDjqCBNqvcOSk6GGJIi/lLQkJIQTI5s6GeSJRvDkPBDQivr8E6ChCVtJErLPo6CS
KLx6SUndDZI2SEx8iRRkNkKzCmCREYJ3tnLsSlilI+JBGGSiwZvgoKKbnrl9DZEPjRO2QhihSuLB
pjyClGI9JdCdvMrSS0yZm7Suy0yXCECrpeyykyNeS6KMnQyjS7y5o6SxCRS1S3o6OnkWyONPFczC
xdSzLGwukWCBCkSxMgFczAQxStzJyvS9wZqKo8nKCfJkI6kWvsCmI4TQjsMJHmwuHNMrjSCrSliV
DrFdDNTXSjEPxwDzTaCkEDIlPsEaSNkPzeE9uOwhzdjZR4LnCdzbPoR4FVNJTYGaCrzmTPvBTYTk
JDiDzPnmpPTRTjsrztHvzToAuPA0QhjYLBTWifo4SIC5zZifzIpYkrkqE8TLK0nGDVGGHmwOQhie
tjz7xfzkyLEXmxjox6GEihsnRTEcvAwhw2irxTCfNJUDCTjnNVFvCkN+UED/FvPBI9vu0KjgDYxQ
OrJHiz0DDOC+Hx0QUTUEQPEM0SrujRxYUXQhq0mHUZUI0YCgEginNqUGUDi+UdttUfUTigEqC7Ua
GeDZDao+JCo9rtUlMJFC0S0MC+Uotw0L0figOupd0m0ciVUtuo0QmDkCkYRBUfTPkCziyl0DDVCN
UyRNDMDDUsOUkCz+TXmGMrloDNyNisKsnskTyayjU+sw0/lVu9VBkj03iax6VECFU3rzVBSxEjuR
iSsriz1Gimyqrinminmfz/GsjMHmwTPSUBz81BCxqBinC2o7xfOcDzGTVGEgmzTjQyL8TqRrQVwy
T3U+mYvxkqET1Qznm5isEgo1T9G+ihq71iUmUsFVFrz2o7kaDhzz1oR8uyHjRNoQPmCQzTQYIAzS
ztzwzfTVOQvx1azXlFzoTcVbTiPJIwTczgTjTUTfzi1vThzdRbDMzVi/zlIaQoTsznzZV/wq1uV9
19TsTnVw2DzkTvmTTwzhzyCkTzVzNHSFT11c2KzkvCIcuXz5zkz6miT8Ej0OT+GOSqzLUAlPWRUC
0qCgOSUF0sLh0HE5xxUsUJukET1+WWi6Wcza0vUP0u0RDu0SUh0EUU0m2d0b2g0PUWiu0QnZCgWm
2P2hUg0e2Y0EWq2kUsiVUjUVK0zJ0l0j2n2wUrWtUiCVWy0p2tkMKzUw0O0Y0wWljMU3iTPdU2CU
U0xbU1lVxk03ndU40fU6HgW0QuU8CX09SNQuSxCw1H171B3GVACfVg1JVHVAVF3FVk3KnZqvTqXK
WXVK0QVMT/FFVGVOnnGGVQQuVRnCWV1TiD1UvCE8Cd1WqHjNVYQuVZTAzW12Hm1cTcVdinpOHvVg
VyFwGon9uEVjvwkdXj0d2dTsVn1dVo2J3fyZDDjGkAiUSB1tnTH+ito6G7MTuFOpiTpBCkr8DuXU
HMOmnHzSHYngI3QsjQC3P6s1CoGojnjhl2OFX7GHCfDhmf36nBPoQpnmwhErOGCf32YDDkugtYmg
DHRMoOwcDJJdvDjxwryGICqWrcEwkCkg4NYODo4MYQEMjDYRF9W54MkMmoCDjkW8kciioqN5qLyA
t1kaQTVnpqnMYcH+orYayfj0YK0jJjisYd1HYLJ44PxvYZR9ysw4D5DHIMjJKin1XK4SwhYRYrYM
FCYX4q4lOpvo4hYUR+4YCdYWirYVGy0e4tYwYsDkx9yVJXMRvjAQYplLDaSbSpSLywGrChtpY9pj
4/NwPMKMpjjDY/CrFr5AiNCwE0SDuCDniFDXRCI+ujFVOo48KLZLUdjnuTDaEu5L5PZEPakcjHZR
QAH+FwPV5DCNCjYnD3uiIy47jqi9ib5GPqZax0OCNCCC5dLSLiYhY/FVJtvFOcxCRrifZg5KC85b
ZCn+pjip5YGeIKrLGGDny6XcwhE8ZrnUCfLcI+5uKhJ0O/nWu9pHO75y2YLL1XZvvDi/yLm5S2PN
Sl54j+o9ZtSjZ7L+5lG5TIZ2KH1pRFidrL1iI9RFF2PKXUKpaBF2ZxZsZ8Z/aCZu5swHR82Iv0v5
y4WEICqcRf6NzmidjoE038Zr3vq6qaxGJHQZKOOGTUzEteQxZ4jdwjF4oXO6TsX8DKrsDHPBZ4lO
QjDYJH6cCnQpCWPL6iVlX/wBZ9CWX8ajjHCziT1kxxqaiNapCWaXxfP06ZanJISqi1o/6f1lQzi1
6pO66yQyXZasKsjZHdvDvXapsw63T5NzaUVPQrk6Wna5GopEqnJC54mrNvKLFC6cCRQzCDXE05Z4
68RRH/PB4XQzN+DpHKi2jRpEsJvKUjH1bBibC/jOOqbEVpwxbQCrbRHk7NbQo6adzUvaO/r5wuyl
7SraaYCV5/0dwpabaWL0OUaavDx6MD31qWqax6Lhs4S0Z3yjLRDP7kaQ7Kw0CfU8K75zkey6U8J4
6fZmySSIP01QojMu7mzs6MiE6QTpkFysNbAQIN1tQdiQrRaIZ+wVaO735vbhm1aJ5x7kGzbPlF6D
Z3b97lRyJt51aRE55+b7Zw595gaLafcDcFlg6CcBaDxf5/7+ynaGzFrRDep0aEZ/6KaI8IaH7658
zxqONv3dbh6Qu2wyTMUjbxE0aXo2bo6RP0J6X8jy7srP38Udx+6caaXwaV8C6c7VqzaeqOO6zG6h
Z4O6p4lc6ochZiSevrcja76n8p7AavE6FF6ucsci6q8ucq6vqLaw8j8hyS8x6960a+61a4iWS9yb
64cu65yVoevda+Rsa9c5a+vcUZ6cbBE6Hx7C547D7B7Fcy7GrKbivCORVAEdI77QCybL0Ybd9IbO
dARI7P7X7RC0aCdNbB7Ub3dPX2aeJC7S7YUd9OtHcdu87bi28gccb3Cevu38mzbgOaJmEqP07iun
5d8CaFPNdcaObn6GbpSNrL7qo9br1jojH9u73UCwaRUy7ytJbx8UcXWCDEYHnKSAPEwcVtxRl+On
DN251ZJvVBsgEQghCjlq1JujDjvT9QoqlPEgiW6rqOQoLQCVFxvptt92DUjNCTywT54ACmvCMqap
QoVPeAGUO2q/F5+DYGw6mLSAFLN/ROdvndKLJSlgpHZt+MjmmOOunk+BpOC+uU7Ki1UlMm59EZjp
C6eT6pjKHneRR6eY6XuXisWCaUeZC2FOcliaeXFODWbi0jJ+jVMp1juTpOehCl7ipxmOCxrBE8en
im6bWCY4ittdd4ut+TQ+bKut+hF5dS4QNmtVJHvUU8TJ+hCoPdOTjKODN+E6vUV0rpRPi497beDb
C+RA+vIjEelykA0QH+ONCXGeX3aUT7uVdgdSlV+CjraO6pismORFMTvacmEhm7SFeYzWOXxrvaEY
ejNOlFfNSfXvjVScIffPqannWviXu2j/J7/CnadSiWVSE/ZtojFc0lKMmUPaUUkrlVjHe53X0HN+
UhPHEekhnKCde0CvpyC6Dnop4HYniFD5HKMgCCdYjUfMPNePGhCkVMu87ijQIrOD0FaCE0PF/zMr
vKct6X/154ZmynUBiV+a/5GOZweddmf5tvzvLLgbCADQYiAYjgYi4ajIaiAaDUbi4YDAcQSDQiFC
Axg2GjQXDMbjaKQeEwuGjIXDIaDKKDMXDYajmGQmTymKDaTjmVRkxA0YCCez8QGueC4aDcbiA7iC
NDWWDOJTWIDiQG2l02nwUcQiQQ0ax0YjSCDkYVqtw4XDccRMY2KyRiNDaxjIbDOw2MajatjaTXKY
VitQy9ScbX2pVGQRkaYG+SuWjGB4m43OQy0YSSzWi1RW4QvEDWujOv5PNzGrZmWDbHaSO1fCxLDg
2d0CewOhYmWDCjwWTDjQCCqbaIbneC6v3mmxeCywaDDH3OW2Dk0TmW7gDka9Dh8vmxwZDDCSzi4D
ud6Kbve4gbePCSYajGj9Xr+XBSrgen5XKc2/jwvdfPANu4T2Pc/7gvk3iBoyMy3vUyYahgujfvSk
7yIKg6DImxKOQy+TcPpCSjMyk0OuolyIJxDgbw8z6isnC7ARW4SRQfEkYMmgqYMSrrvJUgqxhyGa
wQys60IpH0gRJDT7R6F0fyDCTusIg8bvFCcooRGcErfGslvchcIy2HCxhoHEcRKuEeTCs4aScroc
wHJYbzXEibBk3s4TkxKbTGkElzHMs9KlIriBuzi30BPgbhyFypObOk7USyi8zbN9ILg18cspHlKh
hSSOxY91FUZF9POEscurdBU8qJQL3KyHEWQjQ6CUgGLUMAm04oHUCiVqwCHsq/lIIFS4bIej1Z0V
YdfJalFkOJWzEoevToLRRcWPRaVm1ahAZw9Yzc2qGSjWXYFZqzcSjvRXCBXMk9x1VPd2qZD1ZW3V
90gbVIaUUwa6P6G9jt/faWx+xjKsfgYczGxinLKyM0KtS8HIRcbo4amKxwPgz24xRc7Bwk2AXwhu
M4+kyUvpiaHQDZ734m/D5VrkeE4W/uZIZgd+vllGcX5gt/2PLM1qyzz+Iq5aJ4FojPMnFK6aHRcK
IqHMiTXRQY21qciMRgYaBmzKD6pDGc5+iunZ7gl/aOp+uZ9tSDu9IOu6/QTeRxgesOxkqYa5V2pb
3nGl6NuGFcChGmQq6SJ6EoteT5NKn4Eh9lSWGfCzXaQb11NL07uh4chxoyx866kxo7QXSahotBct
uXBUFtiNdN1ddo+rfTX9SD24Rz/Q2d3fS8zXXdNTzHHWd22ccnXsl9jfU6YratCJVgXoXBRVOdum
152dbuEJte/uhlBHZIfWvh0V73lePXfs/XynpIT4P2Wrrz38b892uTnHwU/ar+2uPbW6/o3j/F3L
gKy/aAy6F2vTVQW9EUAy1kHBkDJpMEDiIzgmtxJzJyrpuLORcxLIQYn8hAS5QpwAYPjLCSJV6BHx
o8hAuJDBzivq6LY1Q/MKnNF1JaXgwDISXQ+KKSQwJDS+lsOvCkwMJYZOjV6YlsKti1o+grEEiEEo
ZwWgecBORay9xAQiSx4EYGKIeJYQY3JOCzn2SE1hf0bGdHoQ0DKJJJi9IeI4XosJJjQF5I4deO5E
HyJCKLEkg4NwYJOI4e6OJIgYtPOcVKNcLi6HojInyE58TgLHg2Dk4xRDoRsLka9VKElXlqR+assC
ESOJuiSad4qJYKwmjTCtUZTIcEsYBIVEpvI1mnLyTaFcqimycRKdaYxEGFnoK6WmNbISaKYBqQaP
rhzmldXFCaPEV46JMMHNcwcekhyqJMDl0CVJUlhKsWBoReCTl3LCRxID1FDEdXFPM56fyWgzjiRy
F6qkfxJI4R9vhbyHkohNHudK0SiAzk1PRgtDqIURMMiShJ1p2FnhqTZ0EsSEJkVuS2Apa5hJzI6x
WVbAKRkFosg+Yc8aLT1i6xORUqmMxXN+xM9MjziR2Y63aFtD2UpSU/CBfbIz2lEPjBsu9RSzkOqH
RUmKForwbMrQchqFgcRrLGoQx9SzBw4TEvuqpHaSlsa/JcpbcCPw+NAhimycYfHtSDTaD9OT8r6f
SQWoZaZWuyUUQqOJJowNoatNdfbclFKEmiX8zpY1OSjm6ZYsdELHkpRwxNr0MrDQssiURqlfzQsk
NXDiSDCFFTolGQdNal2cqshA1+1VaLWsUfvX2VVXJ3L5fKkyoEZmFFHckosyVJp4uuIhJqMlUmoW
Yo3Hl0pWViyjNOWlwzVJg2itrIuGR4IXttgzY+rrtyspuhweyujUC4WUSu4t2S55QWKa8+u1k4nL
X2uDGy4cXTErcoIRA8j1SiUsLXPRAdryWxrj2WuA12p9A2d81yhLvsD1RfXNXBjh25LSflhclFsC
HuamXQPDMLLkFzdvQk0NyCHSFv+WK5iV3tGUusWeXGCimYBIjQdBRsifFEKCUMrhSCGAgCaUopzk
3CtYMiTAhRZy6AtPctwugcgygNCEA3JdojoHdMETAqi3bLkvIIDF0dGg2Zcn8SdbWYDF5ry7Ysgk
K8pJey4rVj2Z5z2jzlm1Oqus7K5N9lxOqi6StYSYifNYUyeE+0gqbIeZSJlJjSfbJOeZGkNzPBSF
+YyvnE04Y6PZiQQR/UWbnKpHiVZkJPP7M63z8rdjJRox2stTlynwrrUJ6SQLdJs+ox2nre7A13nV
z8LNaEI1sZU4l89XJ1X9s4tZr9UVdzqV3aup9QlfP4bi4BAzQabP4Y4k94TYFDgsSApOhrLnQ1Wi
nQurkj5om077ORBaOblfMm7eb40mSR2yQhXu+VjXBz0ahCGhim7yzQTbbwIN8zE4dCXBcF1u4NL7
uCSJA987azOhrPC3Sul3LURI6RIN8oaUTmc27WN/8QcQd7RBdOVzxR5uaEfMSO352GUSPnN2vbTt
WpznmaC1SRiyQvj8hNBQJY5mPKMh+Q5e4lnlNups0b9sDxm0S/uLaE4MoM6CnM3T22W+PpJNpw75
upzDexlCB9SkSuzW8B+r6OyAmLSdDy6btNAV26XPzl9d4t4PUNMNuYjnkY7iEPd6XY8coN8my4V6
88fuLKMJdykc8VyQ4jiOdSLLd6DzmdSslG80bfFHZi5lH8jyftjQc8+MT565Y/gVmI85R6rbngqr
+jt6bHSOkChJiXH4DhPktzFruJnntnzDT7yriwTeHgkiPeWf0n7F8Nl09zP93XPgqzGO+nq3KLpO
f/O9L+n8vvU665NPfXh5Z0B/aVr7L+y+PqmD7KVw/u+W5O9S/i1Qwk6SSktGJ00eKANo0MT02+c+
vq6lAg9QniIm2MkU2+aI4EW6V+95A4rZA8567LBC1yIemq42XOmrBOpC43AlBEXFBc2QWYJhBGn8
7KW+LBBGlw62pS2K11A1BoI9B2101G3AL1BtCNAiSYvqSzBHBSzq7YhK3/BQpE/qYLBGVfByOId8
W6KyhK5OfMwm0MgS4c45C8gshCNy7NCzDURTDZCmULC/DXCktO1zDM94mI1NDpDDDskW2tBlC3D/
D5BlCi/qKc81Cs43DkgfDpDg4Ggs+fEeny7iLg80vOZA4GdC1+jsJvDYmenkIyW6X4NS7jE41yVC
iBEsOnFIuM9u3u/5E8Kk9ulepZFcNQ0EoKr9FcjtDZF2+9DUdA95GBDxDqzRFsLpEpFA3OXwQVFd
FozqJYOszE0NFVFqXdGUKcp/F0ItAxG2a82+kCi5FHG2UIzrHHG+bg9JGRGy1ONAwE7LGmzNHLHX
HkOfB3HM2+KapEn8TEBnH2rQoPH9G5GlIFFTFfIMPTCLGvINGpEc6UNw2mIeVfGqNAQA2nDAMlIu
nxAGV5Aw6UPTBBI+9K6UOtDYgTF41CfG6eWfGVJXFM3BIrJKO5JjBQSPI5JPBoXFBtJCJpB9J5JK
OPDEXdJ7IxBoKZB3IiwNJkrNCe3MSbDsfk1AbC3q7MN4IWNAsNCu3APJK0SvC4PJFG0URdB9K9KW
2mfBIA25KO/qflLHLa7MO61/LIr87iOs3E0UQc7KTaY5LHK243L7LzKq/+QnLpMJKkr2zyq+vm7i
sO1BMZFgSu9g3MYO4GI/MGI6iG7jMxJKIOwlMuVsNBMQ7iQdMpNI2oRPLHNQoA+y3NNBHaL1JeIO
ohHEWZBFMqY5NjAKzQLPMakW1TJBMi4GsPCe5oJdDY0u67OOqlHaVa1O5oTdGI7824LjErOA6HJK
Ls7tOw1gNBOHOdNdPAQeuM2LN6US9ujIrNO+IRO4JYjtKzN6grOSJvDnOi7hPJPhOgX5ObPIkFP2
JbP7OVEc6m7gz0SO6kK6TG7A7ZEKK6MwzPLU9g10O83KVwWK/aT0Om8mMHE6e2RO8mvy2MIS8wKj
CBAg15Qe+y104iMc5K2w9AqFRdQDFk5Kgk7Ci49ASBRKQfCLQVQM2Ct7Ge11E07uI84xSI387uwl
CK361VIpHPCgg0yqTDDnEEQoyqYBCK6ScnRzBkZ+yqaw1nEEzM8mINE7BQKZQiWZKzBkJQ1U7Yo1
FG10yaz0eTAy/KyqRG2NSK3ivhSGXOi4MdJSKnDKJuL630bPDoNHUG4DS24C14VdCdGsJOTfUS+p
E8aQzOgSiBFcn86TI0/asHQw7udDUelA14WlI3DUhQ1iylBiKySBURIo9JD7BZUaNTDogrVAePCf
E8xUzOWSPi6ksaNxWCja3FG2OY7AtWflIINBUQVCmtHKdGOQLWUXWSYyeZWuQdKzHM61WuLW+9G2
WK3KVcRPWenDUakVWyuW7A9S3lTmsbOa30Ve/QUULuT5XCYXFwohWOI3Ig88+YTbQQ00Ig/i8mJR
LzJrUQe2Tk3GItTgMpIG1CN43g7Yro90kjX0T1Ncm1B6z0Pc8q4sLk1UmfI24sNxRSK1YWja7BQV
TlYMIbX1QVJekaqa8OLk25YE+4SYSPKejwnS8mnRULK+Lm7AWNVrLI4QWk6NI4kjSewW1m6UTW3g
xG9y6UTjaiOvLyjTQMoS1hLg1TYkJxLouvRLNlLZB/TWM8+9IjFWz0X3JeiFYupJJ7aC7W0WlMzz
NpSwKyqy3m3MJRXfM1MOofUQuonDNGTU1U9TZ+zyRE9E9SnQ24j9XouoRnK+Z5Uajs2s0UTHS4SY
uxK+jtVSpJcMdBasWZM8wXX1TTPjNoro7urA25b7cQIhHot8KctWwcMcauhYzG5odDWYKIqBPYMr
WOl7OqI7XosbAVMWh+3LFU1bN6lA1UX5U7MrRufTBZNWRM6SewY5PYLFUiTVOE2Y3guogLLGLiVY
30NRAxOihfUaINB3PvWjIKSyCECoAaBeCMLUBACoVS1EJgKAR01+JkugycgyLACoKoCECwBABeCO
CmLADODmBACKCw0eCoIyJ6CoDuAaBQDWIGBBhNhPhQKQBSCoDU0eypgCCIAaBaskzQLpg7hlho9J
hAAaC2BRhPgwBADcBADEB7hKBADKBSC6CoCUAaCoBVg5g9gDhCBQDkBADtithQDThODrhXhbidhE
BfhMBxiuBAB+BJhQC3i6AaCLf4J+uMLopyLAJ6+Oxw0qKVghglgoLpgvgzg2ogPY8kzshXEmQkN0
BAOtE+1OLg3OJAMKaoLADyy4OdF8BATIqZGURKU4ImhAIcInkjNqJmIWqRFaWKpTkqVDWMI8slZ0
MKUS/4wkODk2goWaoqOILolAwE1/lKpMzqREnzFHlKk8OYUXKyMCI+2+QtmLkA5Pl8XwDFie72yH
IAsHYRPIao5GJezdImgzmKkS9uX4JoogoA43nA1nlhB7OPnCkUcPKI3s1PnXbbIdHPFHnhVuIiWt
mLb+JUdANXAwlQJhn4Kc+8NQjbkPViKfmnm0zqYy05oSgq2nGnnm3Tf2I0SY5aKA4oJUTqR9MaLu
izgCKoyBAdh6IOBScth8CmDKDcDIDLiqDGywDCDoDLgwDCN9pmDmDCBSuoBQDOBSBasaBRiRp+LO
BQBZpMBzh8BADQDCDmDRpmBADpqdpsDnpxp0Jbp5p9qBiQVNh8DoDfiTiWAatcIMJgyoWfQwCphj
h6DeDEDoDCDTiFpqDbpvpzp3p7qGBvqCBSBhh8DIDTrvq0DmDpqNpOBADDpWIxphplpoBADlsODI
DeDbrBiZhmaiIHrMVrrRrUBQDmDyDbrmDoDkDSDGBADnpuDSDfiEDXiRaoBQDzsNsRpVpfqzqIDy
DgDpgxqiDLqnqrrttprzqFW4BQBdsmAbE8ISiukDhhh4BQJNqPpRpVpZirtkDlt/tdtvtzqlsdpX
siBACICKCmKDtYOVtcKQDTqjqhqduLsqq7Z1swLwKPrThwkI1hhvsrWXhthDh6ywDGDSDgDTpUDo
BPgxtWBTtbtfvGKIBQDxr2BQDHqsBsBRqWDdsBqJt2DgDqDFwgBQDZtHvFwNvIDyBSUgBnqLufsS
DLpjrgDPsM4kDfwe31xLtWDJuKVxesBBvfs1ihg5v1hHwSBpvLx/wXwbwfp2DRr2OIBRsPwruBiO
DdqPySDsDKDYDeDhiRiViZjY3Uj5jc1u+MKGQc3Y1PPKyQKUhoMaevZ8gugtQfQ2UgR+ImzXEkpS
LVzebogtccgQYoygLSykXAo8SxuNz6ZEIJlKUS6Z0Fzz0K4gr9znSP0KoLBZzYxwV0Q/e7uMWqNQ
Nz0tzj0wo87t04BAm2pD0r0YIn1Gmr0qxHZj1QmsPd0A5t0xReeGaI5aXF0+fRzV1F0yUotWbpAX
oo03gK0hgP12xYUQdGj5gdAY0hAcBQCRqZyPhZoqap2GJ7oyIYJRUrn220hZ2Xh6JZxPpTpXpbyd
tnrxuvtxvTt3rnqprrqvyZr1yxvmTG4Fxzvjhjvu6NvsslcBh3h7r93jpmDpvNvQDQDTgwDhtEDt
wNVjyVpltLr+DdxXw/wPxGfTxN3m7qj53vuXg/ijh3wdsV4ppr4DvODCDYBBjVFt2GbhBZ2wKKtc
zMTSOthsKps54lpiDqyx5Xot2sBB2wIVFKIWKNdFpBuYK73Fuj3LtDsODmDbvPwJyFwRxAIRyHr5
yLqvyPq5yXutq3h9sf4iDP4nwoIxpbp9uEDoDSDNtHpjpnqN3nsqdAPj47vlh7ypxh4dxnydygBi
BRylypytutsJqR3Nur3RttpkDJt53fwj4Fth8WDn5yDp53t3q9saDKDGDKDTylur3ny0dGInjcTJ
2GKEgsq+6MRuU8nt9OxwcfcwKOgtb6bVb+IGgsgiMz9qLd9uSGOx90gs4ac39h1EOGI8c2fSJoIz
+ApSrJlj+IZDdkLZXL+eiypwwWUL9kNWjidHHP9akUk0skSJ+99TkspoIyDR0EnOvqfGj21gKp94
YULofGTaWb+ykWyg4stH/srN/ZQCNeBkIAOBiLhgNByIBkMRkLhoMhAbAaMhuOYIM4PCYXDYfEYn
FYuMRmLhwN4dEIkNhcNRuNIRIJFJI3J5TK5aMBcNxjLJNHRyM5rN5zMZ5PhkMIpJJLHBvDBoMYRR
puMqTMhvE6fFBsOYuN5ROKdRYoNRtX64LqzF6gMrGIDHHK6Ma+MBxDKrQrfcbmMRqNYRVRdCaJco
IMRtfaWNKbT7mMMJbKVKRsN8VBBhfIlFJ7k8ZhTzHMxgZQObFdpnLKLodHO5RKtMMJDVZ1no9T9f
NJ3FNdaBrf9dMYFBMRT93RZ9Jt/BZYMRzcxqMoPO7zdeVi41Et3Wodyt2NeVfeuOez4IYOJZbesL
uwIBiOIpZLmN7l6hxKBnoxkOIXlRx8vpo/MHDdhooz+Bc+rCvuvIZL49b2oQHEEwW8QaPIx0EBch
UIu3B8HOuxj1OXC79vuhaesk6aUhwnz/xIGiiJyswZuKBozBUBqbQmwo7hAkL5pYJoQIiHCbPgws
GQKjQ2yDIYYSLB6zBgyT7oGGbevWxavvwir9yswcKyy2D5SvByQhmnEwyfKMUwLM0jBmjT/zJNgc
ptKERS+mjlJsyLLSy10tzmswbr4/8pyrQE9wdJci0BOtEpvJj5IpNyHLaNEgxZFwaRgn0kxG9EWp
a64ZNM46DVC9E0oGgqP00Gz/SDVVTIwhipo63KWozWrcIslseJg1TS16l9atWmiEyGoLbvRF1kNi
y9lquqNasOxKwWk0iqrQrCtL6u9orEsiULPaK1Kc8yyq8yYaLrYF0qKvK9sMv6QM0xqJWovDBsLc
6lrFKLBBgyq+s/erONkzLTvQ1K3WDhLRMLYDWNom7bNlW7iYpZ1bV4orht641Ytbj0ZSk4DkxA5r
no46MTRAgqHPO9LtJS7uYvBD6Mwpc7vuy9kLr6974vW/sDz6GstvnAtXvvAMB6HpWiwhSOfwtDGc
PG8sg6lmejztDqnRO9cHRJMsPuZFMvUwltWxijY5gbASQ4CuM9SRuDXMouMprruKUuWp6BhymkBU
1GLA8Cmi2wE3cmLRxCWcWs1XcBNbJciG3JqLutKbu3fMQizFIcjxsP0kp3CQLtrldMx2+hrv/VwL
0+8bn0r0dF2kPc0s03gbS3IhkGct0FpSnST4HhPUlaCMLvs3OT5bGchvHn+U3YZvv1vqOCGK/LE2
MBSnN3lX6G3wMZ1PoJQuCkosub5oP7v1oUjf3JErPlIoiSNwEhapILI6/siD/S/oKPkTYtT7StE3
Bmk2BANoFG4TwkIv6AEdwLYCguChDSfP2K0cmChJEVANIsbhgR6yBg1Sg/WDEJzftohKSloRvwcg
2P3DEG8DT5OBhsY6GJ82wQ0KtAR/8Oz0Q9M7ESAx625PZIg/Z+B8omn7ieiCKLTyEv8fQjGEBKIs
wDi2+M9amgbkCi0mRXkYybxmjBGh+IOSBg0XjGBG6cnAkafsfdRamgaOTjyfND6/YfIgj0U8myD3
pqqN6xiCB+3UH1MCSGRr2ilnwkiWZ7JTUbs1YCSJCkmiGHdOVIJxQMZNxvcLDUECAi8yqOUQNIT0
zhvYQ/HFDzijKl/eS91653CNo0bu3J3UnXzEOeO7lvTlZVt4deiJ9DgnpuFbaUVx72nGP4moqiWT
kjLRbb5Llz8hneOccu5N2Kc3my5dI7EGbs5pE+nYuaYLfk/usb67Wc7uJhN0nGY538uXgvDl68Zz
sunhqan0kd6FCCgvOe48R7B+5cJkoe+V874noUWi1Rh5T84FPvfw/JC79Iq0gfjAEyUYH/RLpRFq
lcGoHwRgZA4v8EIWQShBAiC0MYMwHVpB1EEH6fQikHCaDUKYVxVqNEaGEC4VNIh5DeBcOUm1RqK/
eILiCDxKqPEc/cSQYUvikQSJ0JIrUhTVWGKlZqTIEi+3ejkWCnRgrieSNdc55oxfjXaMteHnRpjg
QyObd46tgsCDmPEhJAHKj5H6xSi5SVsgqgeTsiJlyKkvJOR4NbMvZlxJWRbeLNSmlCWiQ8n7SFNj
fZGUFqkPypnTK1RcsCCzLlmeGW08nkUCeK24BoQgqNwQuqYGAILizXR2VArL0HAv7Cokm4t0T1Ag
DXb8LAIAXhHCmSwM4cwQBFCwA0FATQ5hnBcCkKgagGgtJsRZsoLSBkOCoEQBoWwUBEDSGcFILSjg
oDKHMOgKQuhUCU3BwMKAQX8JEXy+d4ryXmvReq9iBUS4JviCDBt9r8X6wUDe/2AMBYEAauJXl0jF
yqRbCleJcC8wrufda7F2ifXdu/eEFAU8IgNCLcG6V0rqk2IUU5HSPHzAgR+RGGyBawnqLUSIuBfX
Ul8BaSE8Bkg5Blt/b+4ILwjSmumFQMwDZYGRuNmV/xdSJK+fiqOsh+8X49undUIV17s3bBBjS8CN
jKZLCoW3CZBT2YYDvfUFAQwyhyv2gJC4KA6BpDMGkMYYQ6BlBAFYFJHQZ3+BSDAFAcg5hpDeG7EO
Bcdo2zLj7GGdcZ3ezyWouaVDslSkwzApaMcpZUf3lfLNwMxP3MldLM6UXiFcbAcokSvM36nzjqm7
V3NWXhz+7UKmg77BT0PftF4NQUBpDCGwEATg6htDFtfAepMebKuLnLOmMs77PyRq/JeLCGU2IllH
BOuMrZYCFlrXp89f5mL/miHKFzsl6UCQfZN0inbqxjnbPF4dq35DdpIOuVwQBBDYGcN+iL4Ka20G
kOgaA26jx1ufOHDNVbtxru/JXBVNES1pvbKZ6Nc7635mPf9xdgl95eqAuEcdA8JzLwvZnDt3X2CS
HMOYddDggC4CgMIdeQ8b2xx7bYdA8hcBTyTUucN09F1XyvV3LT1WkLgUTWp9d7803zru4PONlc7J
ka45KUHU4Yuhsromc+G7O5WnTaRbbi7T0JpbJIMuoX7yACgNgaQycgDyCAImkr/9cx4ZTf5Tuv98
5Tw/lmsD1S5PB2jmW+AQa633rzuGwOA7CcZvFvBQehXF73uvo3f893yz94BD3hNqh1DEGoMoYw6d
OBQG8FJLgaAoDuG7Q/WvLamva23IGRfN+27Dq3JPoJTEDK4abtOt+2en5t6rX3cfWl9h4YWoMZvZ
7L85s3lWeb7BQ+B8nV/jNIAgCWCkizTQ9ZAoFDyIJINwMwFI5whj47TbTq/ZBQlIFANrSTUDUTcr
kr6R+4nyQ5UbMrH5pQljIZ+5HxID+IKb7K8I+6BBUwnooAEBTpUr9i9qORgYghv5pKJgEAzsFJJ4
nwkan5BzoAg5JxCYvkHQ34lQyRJwixNIhbIsHxorKiHppIoxrJTyoUJQ+JTzJZQ5bhTwvYh0FhMx
FZ3gEEFiCBLD6Y/cMyLMHZUYg8MKeQMRGrry6hlYyAySxAsxChTqMsO8MqLxWQjpFIvhwRmhVIhk
Mpfp7ptKI8QkRRNLl58aGov5WSux4IlkPKG0KsS0SQkIuAi5LKGsQiWBPiOMMsUhCsQTtSwKCwiQ
5jMkFkT5oEP0TJnQBoMTfjLhLbDDMJMg7q6ShBCcWZwQn0FghIpz97oj3kZAtrQoILHLrrdEOrIC
LMEJHrIxIBBR96MrJgsKxDKDWztbKr8jtwBrLjL0ZDML1bgBe4hB8ywQ5LJogUZDvLhUOsErvzPL
3j3S9ZOhCbhDajQra4FrRQGLRjRzSDyjSrS5STTTTjT0Cj6MOjlDdjz0bQl5LcB5xccDtTmccb1D
m7871kdotQ+hsohUJoqTvD6Toce720fLaEZbQTQjazjjbLbbbrb7cLcbREC0aLk7sD+cFBo8jDJi
+MGbescMjzmscsdbnT9ItSSQ0TsouaPq+Ueslsij27+jG7iTijizjDjUmzqzkDkUiUaUrUE4iMog
kZLZ7ogheMpMjr00kD8zfz9Ekkd4gR+JF7mElbOD2rvsoTPRgL3rwUmbpDpTpgOT4zqLqcsYszq7
rLrcnzkzZUtMwci8trsohY9hA78McUpj1Lt8kUdjNBzAszYrIBekZMl0wTzy+zwwubxAMLxTRbxr
x7rDyTygOciTzElr67hstUzUbiUxoMz70r8cus0ku8kc047c4r0R4Mv7vU1zOsmEwhgMfjaL3sgI
Kb4D4T4j4z5D5T5j5wOT6EysDBwy4xC76060ird04hLYgolJdcjj8Uj78s5jMk5xKKCE+w7J9D78
6ke0rU7D+r+8ALTLxoMb/j/wHMAD/MAkA0BAij5b5Eh8Bw7cCMCbUM3yHq6IkRbjr4pwNU9qFRHJ
HcEUbEoLzxKhKZDYqT6owpJJ7AmwnpmAos9wwp7BVRo4hFHYwgwoOyEghJEIy1IRzBHbJogxERF4
khgx7AlFJw+R68biJ59A6dKxNaG6LcDg9dK4/dItGCwSINMS5NGJEVJRg0XEwEOopwJRIFHzglHV
GkF1IwgclBtaNYg9OlPYhJTRAAh1MlI8Y9PgriDtJrtVQLBYhwztP8lVGdHgjcXDXkXTL7MM2Zv7
hUaiVYsQhhm4uAw5m797r7wcw7wjG7HNN9A8wcggsxm59bBi+gFAKUaEyzVEEstSORxg5o+Qhazg
hxxgnwroljXTMLXiL0Di6RfqrYvZAqLI9ZFgyU1q6tW1XEljVCdsqsqaUy0AyVYgEFY0clZK4NZY
llZpvxHcANAk4zggn1ay8VW69MC9EQ+cDQkVZkaYEFOS4tE69oGsEEbI+Av40cQpMo/cPlH8Yqhg
ogrJC5gRn1QcHIjhPQpywIowsiOMqY8QvQlkHQnBFETA/JzIkh3kPC+KHrNJVAvhn1RMVKfcU5VD
YQ/J/cPKBpEVk4vcNTWsbhc8Js+8Qo5wvsGUTApdogiSBFg9nyiUW8OctDlglUYrV9X5TrJNqcMo
zERYtQig8lAVPSQAiSWxE1LSQFoBVFsBEMz7ntrQ9Frh5cDhEA+pzgiVtsSaMtmttMMo7ZmtkRAU
PFvog481iFr9vhmgi9rCHMP6Nc/45lxdudX4ttSy4MXwg8YA4BEViAgsYolAkbhErD2kabPcZi8Q
IcZ9erUtOK6dgA4AEBHUEYjhHlUTuxMqgluyNZIowQkAsiSpQTstGLtERV3Qo8VLWp7gwQ8D8Arp
tFd6BrtFKiXbuwnqeRmKHtb6hTnhVBsBJgv5m7uYmCU1KgyRc9Y1spYorbWpBbuwxjYQxYGyeDuw
5xfcO1uj0Iw5AcVxZZ+LuxFIsg9o0d7F6hLyBE6MqsQIud+F3QrsNkPpUeBdUN8gx9QL0JDrtA5l
/hANRhWx/aUw7dwZJSkeCpVEz+BKV0+pUZmCCg+tsp66MwtoKbPQhy9q6dU9frMt1o11FWEIyM+l
UlGuEI5t3SQQ4y9qE6XKdovhkB2V+I0ImBko7l7gpasJgxkohuKR28UCFM+9d5UdkGEJFM+kqsDm
IoyFAQpYyJlUHaFWLCbCCgrOM4syX1IsHcvd+8+0UBPU6OH4EFIsXBktw1d4wlhRWA9CM1d4+GNS
EKFaUxXZiGIN64wQg2JWQuQN3aHoiFN06q6sHaOFsouY5ZTmEKxDuozAtQ30Jo/DsuKeTBIKhFog
uGBivBTxjr0Mbxkg34nF3Q94rg31HERdd+UKX+VywTgpfqYxII3ZQSeB4NJA3yLwlTJg4eFRAKc0
jVgWPuZLeceJAJhY+5VubBDE1JOxTQvTWIkJo9R5S5QKeEt8Yg3yPlX9UYlIpLMKBE9qeEDuYh4J
IowhQN26uyOWdt4eVBQI5Od1xY4wjOaOeYhSteb6XWfpcRM2TOdYjGWyTGIGWmE4zCX2JasOg+Au
SmToxORphWgui+kyCGR9Nxn+e7zV0Y3pHWbRMuZmbolkF5xiPuaWemFSMgjQhRTRwWbOiBFsjKPh
msS2LjNiBuFQ16CwhUT1IBOFaMeJwKzhMcShBdI6LmrLWMo8TedBItI5KBPgkJuLJhPSM2OhNRUe
ranRNMTyWghS9tJY+6YTNdo0Rl3+uiZRTwkhE1HeNmohL6E9HaCGsy4ceJnOpw8ZsGZo5yEeu7Jz
Necq2uourZ67IpphNem0eAx2ltEM9o9ly8Oo5y2kvjV+U5TsVhp0AKGwy1j0qmEghBCR1+2ZwV+g
50zqUUAO3O2sTzYuBMVsWO4VaO3W4uVaI5A48WO2eZRG3awUvmNF34822W593+04kW1wpaGu5m1G
2dKafwiI8ROd7g6+Xu1hEhD2DxI+7+2m9p7A0yw+Xu9sURCu+mIcuClO8lHFb19maIkxQArV9Y+k
YQ4wo6OD0PA2h9l/BV7DQPASON+IpfCO8nCb0LV5io5yBAoN53DdifB4wR4Rotr1IFd+gRB3E1AW
BJL3E2MWQwqdifE4qAoPDliN+J/ULJQGCmkxd+/GAt4heYoiwLnwtI+MHXIvHIqOkfB17go6A3BA
m/B4uDgONXAdb3Koy4mPLBBa0ho+We+mkJFHMKars4kRZxQBiQuChEbg+4sORjgxKkUHOBE2fwid
upnyFXO2A++aQ51TYyMu+YjKkPQMWw52y3Lwo5Cg52DW4wxG+fRzsorpm+63SQuA4eXvRBI/Lyhm
2szp2AlwgWyW8u9j0WXoiCYCBBssazIrI+7RIW1O49PHWG124e2Ihe423+6KOXWW3+623nX3TW5L
eW2G4GETeW8W624O5W73T+ym5W6G226ZQJQe8nXPaO7O1vanZ3WvWXZR33a52+8+2m9XceEZN29+
3++MDm7Xdb0Rye6xxG/Qyu/nG/AmO/evLm/3ApI/BvBN7nBg33gGO/C27XI3CvK/DHD/NPDruvDR
Z3EN7jV9sXGfGHFPN9R3DIs3FzBfGA5fGXF+jHGxQCU3JfH/G/HvI9p3lO+otJeng/k/JHC4hnJY
knJvgmk3m/gfKbYq+Iq3AXfl4HK3fY9HLIm3MHLnM3L6NnmiaDspHnhpYPNggnN3PXOJ69/Pq/O3
SnPPOu2fSG2vP+dvRfQbecvnsu/HRLsvtPRvmvR44PtzFPSfKduo0Xt7svTO5hwsGfqh3W5vUJHh
enYHc++3VABpt9S7Lt0TMC4QnO0q455ghCFTNo9RVxikelbT+El8wdVDQgKANgMININzSdC0AQPD
AMCwhW7ZWQl9WjQgIYPIOANEgbRTxH0sBLTP1DklTEdLMQ/NPbBQlX16+32P2cgbYzbX0s8v3cC0
c/xjMOcq4m0eVS5A87BFaZa7F6+wIoNwMbjiBsyP2X1LEX6XyAEH6xdaTBCN3zBhJLG4MoNjbyUw
GFVjCzDFWoOYNAMLK67wN4MwgApKhqBpUFQNFBBIRDIkCgkGBpbFBJNxkOpzOhyFItGI0Fw2FBpM
pzLgzGQxFJdKhKgsHFBKN5oNwgKZtNJ0NEOBovIw4EAxEBUMwNGIzFwxGA5G4gGwuGQ1oJEhBroA
gq1XrAgO86GAgjlRBotGAuGAyGFLKhjiIoq5zjdIFwztggN1vsdyEBiuwuGgoHt7uUojljvtXMsp
lctBtdtMIOQgO2QrBpq51nUQFAvqw4yIgH4krBbnVNGwzHIgrtdHFkHI2EAzGwyFw300/GFjG431
xUNoNIRYEAvI5TGYgM5zEBFLEIKc6IpUBpRBpxoggylEo0+3OrGYxnw1HEeGVeG41GMfGggORl7A
u7Q37neEG9K90xYgG452Qw1w2GLxha/LxvWBr6jc+67p8sYcvSro1gaGSnr4ECntI+CfhqHKjtcj
kNJM9T2Bo8TYhAGgbqcGjTt6MyDiE6CeNcoChKI2QcQU1CfxqnwZBnBbxhkGjzhy8Cgt6scYxwu7
0wesSyNu8bGrGsoaOKKg7oQIw5DeNoQJwMoQDmMqKjKOSShilCBp2I0gJ+oKhtWGUbtUpyfBzDzX
JO1Yahk3beya28RKCtSJCMNIzjq9aNpOpobhQHAUrGGoUBdRQYxPRoqDQw4WpPS4UTDMaNU47z3B
QMb1jCOiR0rTww1Y2YUDakYWsQliuo42btrBP7bp9KKyLMtErokOYwjOMtKU5HgUUzL9TrfDVGjy
OA6DfMA8owMsuDQMI5005EvVqxVeBhGS1SlKFh1ikdi2OEAyUMkY6BAMKKhBMVnw6FFpjo5Cbq0m
6cpUliIIlL0wTEMkyJKp4Uhqjy5OQOA5DSO1Uy+OdDDdVNES+NYyjzh2IUmEAg3EzAiCKKYQY+PL
rORU4y4uMl6Xsi4y5parLoPXj80Etd8VEGIa1hfku00+d2WMMoWaPj2QVpgdxylctfXPYFLKDdQy
jwMduDdY9K6IGNTTIOg0pK2Ax4uEA3jNpz1UUFwchQMoxjSOCRDdeY0rdqSIXJczF2BrSEDtMm0B
m2GcabeuaDCEA2DeMePjIFuW3vruv7DNOC7qN3D8kOEv76EGY5mFyg6RfNLbnfdqWsOdsaixPAao
/+f3QjvC4NbWEIrcGkaDRSx7JfmcaSOd26Zk+eao2HcrIGLTysteMjPjY6Y7pvJcp5ExdCN/RhZR
STBdSVQYVMqTBrhyxhxT/mrDqly+jcs7d4FHMa5r163c9cNwaWwAgfkYwtTZQ5NnbSDZtaqlwLWY
Oetu7eUxB0Uomk57g3pptKAV0JZ9wlI4DUT8uJPg7m2BAE0EAWyPLlKAbIGwNifBdK6GQBoNSkkf
J80MjwNUiG9BqDZsZQIePnSIGwBoU4NGniIjhB8QYhoYaIkAn0QAbEeBoeNoaJwYI2cjDc2iG0MQ
9iPGAowMUYsPL4DQn0SIgxYi0ntYEbYbxCKPEQGp2YZRfKGdIgINZW5kc3RyZWFtDWVuZG9iag01
OSAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dCBdDS9Gb250IDw8DS9GMiA1IDAgUg0vRjYg
NyAwIFINL0Y4IDggMCBSDS9GMTAgOSAwIFINL0YyNCAzNiAwIFINPj4NL0V4dEdTdGF0ZSA8PA0v
R1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0vR1M0IDE1IDAgUg0+Pg0+Pg1lbmRvYmoNNjEgMCBvYmoN
PDwNL0xlbmd0aCAyODExNA0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADEQGcGkIsCAX
kcpjKBnMQEUsA0YjMXDgQDcbjgXDMYxY2xKKRaMRqORY2A0zA04xIQGkQSCKxeMxuOiAajgaC6GC
0bjUYi4bDQQHIyzCRTOSiCPlcQG4GjCLjkZC4YDYQDYYzsb1Kh0WmU6oWGdCCoGsGi0ajUYC4Y1Y
ZDMbxubzYcVMZ1YWjIYDkXDerUSjTKSTWPmYVQUqA0XkaGQIqSm3i6uWEQZGuDEaTmfUIb5G71Yq
R+oQS1jCfRYqGOn1QZDUbiAqHcGigiHUwmwQEsynkQFMynSHCkqGqzz8Zzi8WscDCMbAibMjG85C
AmmU5nMwmc0m4ziAgm4yb00mc3dsz8LiXwbVbKeqrDS+DQa1caRQY1XYR8W6UYDCGNS2YmjeMgyj
kNwQDGOQ8jgOg3hAOY8jmOgyjahw0DCOwyhAMQyjOOsDwa9CnhAFqfswGQcucs7+BgxzVBQOo5w0
MjbNwNbdwe36HDM6QQRu3gyjwMcLu4MsRCow4UC4FEZPA8wQDoNENQgNo2t+OQ0jGFoyjdBMFjoN
I3jdI8kx/KEHSjDSiDGNI4DTLg6JbA4whANA8jFLDwy9Bg3zJFaqP6/8XjnIcKDKLgUhAMLwBBHj
pjI8Y0jo28HvGNwwjoOqiDmF0/P3QEWthF4qSkrowjnMUdx7GQ4DCOVMQ1H6HVdKY0jaFtPP4GVB
NW/wbPm2IGi2FA0jZV0zhAO87QRY9ZUVRg0DfGNYt2OYUi6KglAbJE/v649RV61rX2DYdaBBSAzB
SkIUDNAs4Bc3o3ysEA4DKN44DZIy8ownQUDaMLeDvRY6WvbNtsPT7+1DAAUUMOQzy4MbeTNNY3wz
BVGx7NI0jlP1/Os7DtO4EElzNIMh0XiFEQfCMJwqFk/KhhgxDrOMLwypsHDcMoyvDRwQYdiEujzX
NQRc2eK4u3mfjnS0njhTQ4DfGVOBBESoRKvrMBnFTStbYDZWGJ80umolT1TOQxjYOsCaAPGpDlON
6jkNo0jnXFsW1rETBpFEVSZMMD6ZS1MU0MoWzENjeDgOUBjqMbgXhJYkjNRWYtY1zYNkFE9wblkJ
QpZkD8S3mmvJZ7w4uNIzaI4eD27QNwcA8nC02FnUZzOOTyJiGWVvj0rDpLAxx9avb0klqHaFArb8
Vt24DpXHXW5hL+6PcoxXyF2ViPLnmRtHF/0viErDdgm89f6r/XBYc7O171FDZVHk2f5I5jqMt4Oi
6cgjCNq+AyswfQtwFAeVpFKYAsluwaFkMoSKCBMS1HSm/T8sNmicQ3BvTiwJ8yyAwhmXa5BKCpYN
JSY6TcioKFOvob21o+qKmEgxBqUJACwwkoHQg6BCsCkornRq8WCZwHbh0Dug5qAYgUn3I2ChvDBo
WonRSFQ58MS5w1BQGxLILw4ApRKDUvoKGOxdKAsSLkMoxh2jLF4G4KAwxpi+wSMQNmGxujW1Z9BO
T4GdLJDBFjRwUJmVaxxWZRAQLTDI7c26YjzuuBbHgHMemsxQb+HdSUDIiIODGgVMAXAZl3DGrBqq
pENOdQdDl6RxHqIsV4sNlxDg1wZDusgNgbw3hrYydNNJSmQHZPMwVbUqWjOyTMjJOKi09SaDTJyT
ysFkpSQO3NRzv3ppJSeyZITvENTGUUHJIYaQ7G3BbMoGy+YKxXDeGMNbT3GyZRo7Z3CMlXJDlvCN
I0A0khjU0USDrpjysjmGb93EmW4zJk6DaT6E2isKV4ChZSXFFKVdopmQjdims8QIGReDV0SE/Bu1
uPkwWGBDd4k9Ok1oHO9n+wR10T2+xRinKp9ixA3B2DeGxDJDoMpgdZSQNhuA3uVToq2gabFWvmk4
a2JJe4lrWnsuGKrmwxnSU21I8CcA5u3aal1DSaTePNgVT1B6YKeoiI6ToHDmQZE/V25mKS3YZQ0N
U16tjYQUIckLVk7suaazHY6DYFwNQUSboLQc60viJE/BoZ0oTMqX0gRfNqI8WAxoiRLYixVGy2Ut
b+s5z00Q6rGQmjmfEhErHXOydZTs0zZyiYCsU3DO2ez0orLGk02GPUCsFMu0NnTpBts/MxGVo0NW
llO+mmEVmQnWhGpi2S0zpyfdGvUN1GYWWYo7C+toKKRMpSfPyaqOJiEOKIHEOrHLlQZo1JGzVbX1
R+cYmE6dOaCW6cCshNabU3vmqupWrTlrVPqoXPx2s2Q2MCQigheVypKQ9lyGEOFxZgMKvc4299wG
nMjtxfOg0zJtIXWtaoFEGWgQgDLCJMUurTMQIck1OLnpcprwgwg/gNI/X4TgyRwF/auVfNxXafls
QxG8TTQk01MUmoEr6T+OT2wUxcBkTgtgKAkBvDuGVi4KQbFTjlIh3OGqD31xclKw2EUWmgriayPS
5HOTInFYTJxMwcRsZqtFLAdDeL/N5Xa2FF8x4ysdU5cbm2f4ZzbMwolNMv4niwhJejUWp2ovTRyj
12TdJAmuymCWHziFxM6RY9pQCrAzBgTkGMMgQEcKmDc/BoURoAZk5uo4MURHuj2VDWmqCgGZ1OVk
vuqz9R9XBXI0Dm0o3MbtENUsR7igtI0DkvDfG/VtWHZKLSWJv2hkCdOn8QCHSGWQxFBSDM+mzSo8
F4eKLk7cRFpzJ+tQQa3BlX7eKKUUFryyaA0WwXNGz1jrPUG7tbgzJyVs1+9SgbxPy7B9ernMaBNn
nh+L80ObrLYDIv2p4vFBW/tJGCMmfI9niGibylEJHStOvAJ6IMxXVvVtGxuEqYwlQKnWY1WMEufl
bAg3i03LVNWGv90B09ypXSzECefIeRvgaJU3ADsnxWnfK3LRzVLUnECKYksWpT5lrsTHsJaIwlR7
DUCAiZMZYn3OoCALYXSoBkAaDQGBFFfl0r9DIjwDQalYBdC8m/dS5knCmYgxQRirGOJTrTT56wQd
w7kfMm5Uy1LANEawGhqHNhMnPOlkadELhyPCpAOYa+q+DMabAlMLbrtcvZsDhh/q52r2TtYMLEkt
huSJOyBCxVFBwcYG/2YaNI2Z5dwqhbnveoTcgk9f/uptPCUWHNuodEJhkY8GSc4deokOuhxFB1dt
vOeqODKWc6MiMLReHUOFR2uTiXyQ7E/nFXef2shpHoQwiYxNmFIJ4TV4Q3xGhCDoduoaQOgMDqBA
/GlsTo/YSMv+uONUWGwWgYQkcaww3CQadvAKRyUYeQVO56YMzI/MWEY+xSq2QdAKDkRkDYDMB0BB
Ay3AS+dQ3Gdm5UQ1AWdwTSQPBeQYnoY86GeE6LB0TAxOTNAjBaWkY6tUWGyomeDqey6KR+BSK2Mk
hUNgDQRieOxaDCRuIdBPBkve2ugkWQQ/AQtkUgO0UmNwS4Qy/w6aYYlmXqdwDeDEUmO2tlB83OTM
RDAaz+SUBmV3DG8y/UxwQIc6ZXBOZIoKe0aspWus0mOeBQVIopBtAQnUXuk0N423AmkU+Ckk44lI
l0+euWbkQKVQUuNwm0qiDkial+SSbgmZAW+0UWQ2SmQaKIPDCCZ6Y8xORkDkYuVmUY9mkyOuDSez
BKaAaUgiZgxAZODLB22KTidIXoXsgAh4ks9iXvDZAcNm5nGCZAXo2sWKQ6wUtdFmfilmyqPDD0lQ
STEAnQhG0fEQLu/aXgVJHhC/HCxU/Kj8+2rs+cDcDmXaDlFsWQwazmOkDSD1FyxAXqXuXyQ2dKVs
XwgmScZGTSDaBADsDSjbIW9k9oS49uti+WDY9G6uRGOUBsa4OUBksWR8AarWIqKsKCrUW+hkL4La
o2MwKoIsMAPgI0PgIEI4LihmPmMKMOCEMSMWJq8MsOKpJYKg1LKaMqPqI2KEyy4zJu1YIENIzQho
1hD8BklEVNFKVU6FGaDCuKLWPmLyRUWGVetCWcXMaabqWMlwT6qaoYWWk+OnLgPAnKWi55LgkIXQ
BTJsXYQLFWdeWGXeiSBsLiBjD6LesNJKMoLWIYLKIk4yKELeLiBmLm8eI2LwL0L44uMA4sJ+2cIE
BqLgJ02cKUJRKNKQMYKFKWI03aMpNqIsBmByIErSI0Bq4Q1Y3s7I1rKpJaNKBiByiiroCMPGcM3f
HoVKvuTcTgqOBqBSLS72SYQQjDOQgKT4sM9QJGo+P6K2yMZadCdUnFOvOyuUlyyOQLOrOuL4BySY
3GeqLe2CNYP+roDSQIfMUkaILyLai+yCXOxKjCL0yiS+SfPcPGi4M0iZPs9YzORbOS32WGUuok/p
BorvPhD9OtNUX6+0zYsGVg3GZkseWgVO5FIqVK0JRKoQxAO2miUwzAkwXkqEq2zFD25gYYkuXOPG
OsciBACSTjPSoLPbR3HXBFPeDlPihmqW0bCceITMmM3GWHHaDWIcxexKxsqNQ/OuJyBnO1DMUkNv
SuYapmDLDeQ1QLEJO5PpQWZGeRAisMiUByNcItKwOelZOjS7OnS+qROwsAIdC+VgBbCg5Yo5PE9W
VAlWYa0ugfChSgBlCpLChyZdQkz+WHTejKLjTiQZS2VKtK3TCKyHLuaoabCGRxFQNunwtAuVI3SX
RQ4el2d7DNSEghQ4uJH0yM5PCqSmS4yRSeIpUrULCaskiBU0oUpioo54c9U6LzMrO8xaVLSbWIyi
qZA+z9R6UGcJQ0dvDlDon6rzSVMSSZWFQ9UEjxO1VItPSAxVACmaSy+AqbVoWI+1RwVpHSQcRFJK
CiJUJYJc7e1ILc1Er+Iy1Ok6MkJ8o27ya0a4MBN+LWkeNeBwr81GKsKWBUKaMCJGJoIsJuJyK0J8
1yK7Y8KQMIAaK+RGK2KmPwKwK0K4MBZYLFYvJSIrJW687A7ELIr+PwliJCKC7SC3ZfZ1aMKE7YXO
IKIOISCma4DOIcIgIkKkMlZ1OQ2aByKEI/ORYo7IygLq8KBwL4BxbLa+i8k6MaBuPsRSLbMdJuNU
LaLtYShlbQrS7IBsLWOOMaPkL6hm7JN+7210InNOPgQQAa8DZtJRZ8LrJYLMhkKmMzNmI4MlcNa5
RDNQ7JD9KaNeJOhkRNPKKzNG7/MxUXc0Io1RAPMxcjcHcpa0RSJOMNJMj2IE6+IE7GJ+NOWS7VaU
7cLaJ/Yza/dQBg7vbcI2o7bOKpJuI6KmNa7IByOUBzT0L872I5a/Mc7jcOBi1U72IneELZboV/NZ
baKQJ67JbWr+V3a+sQIFbiBwRNQsI7ZGPleSJxa+JzbDBbcRdnKfJaI6i9ftflZzY0IkBw8bbaBx
M4yzdVOQONaHf/Z+KFc8ygk7T1feIqW/gngBNnbA4RdiMPYAJWIFYGk7YpYaKyONPwI/hKL6Kw7I
rSI3PxhZbLT03iJ0cyDyAbD8LW1UPm1K7qLvdVhZJRh8KreVc7h1YPiI7JKg8fiELULZeXiaLrie
LXh/hfhSa4JOk6b4IFhRhia5hZTxi9hhD8a4DtZXY7Moj2LMIMIQIVahakIi4EL4L3bbhsNa8LeU
KFWkJ0KEMA9PZ87iIEa8RTMu4EI1eJh9jw7y7Jj2RJQTZ1kBJMKpgWNKBrkNJa4ELiOZjI3lkbeA
MxkhMrj+KLkCNKBzZxeI09k0BpYwcyKzk/j0Rbj5kjlKJRkoKzZw1LlYLM4Ei81GMbkZlnlFj7kl
lNlzb/is67kOMyNZhrllkdlplHj9ZPlOLYrPZ9e2NfmaIpmnljhvmJlrlJmtkorSPYJ0PxmbmFmj
lDnHmrkmLFJXm4J1M7jZh07gMlYvhfnbkfmNlvmu4tno3i63k1N0Mkj1nBjzmlmLltnKLE1E09NZ
cdiS2aLnoVlBn9odnjZ8k7kNhjook7U/cHmHoZnfmPlxohnpM7JToMr9lTn5nDpNmppRmu7hkII3
gNnuk6i9N28LpLndppoBkoPrMte7MtoMJzehk9plqDn/ofZ9ldqMMzqRl9YXbKNfoxnFqFqg65pg
65eRkPc3gSa5q1pnqfo5LTZ1LTp3corPjvn7mnrRmQLELS62r/pbqsOVfprNqdo3rpZ877sDkxp2
RRgxqZoXr9nJrSKBe3sDbHsKI1ffqzqBo1sXsA3tmZsbl7h04sIrezr7stnhswKBYTszs5D8r8Iz
rhqbtFprko1Vo/Mbm5k0NaL7fNtDrlr/pTZ8BusW16PZtq4Hp/rjobsvt5h5rCL7iDkOMjt9uJtb
t1uPmuOXqML9oLl8V3uXnZujuNtHuRgxutTxsK0lmhu7pPqHcVZxcbsLh41HpjsTtdqHhDYEJfmd
JuLfLTYSk6IpjHYdtVe9YlQTYqBBYvKbgICvY4Kc7KKOMHZCyhZIyVlvwYMFZBNdZqKjZfJiKyRJ
ZdZPwwMpdrZ4Kg7HLTaA1PJgKECbd47baZjfaeIaIfjnYPv9i/jNNdhYL9jJizYUOVbNowNfhzh2
17h9QGImKti3iVnsPvYxsdyS3tyXimIZi3ihiu1LdzipypiteXjLPxyTi7ixjBx7YZx3zFjQDmAb
vphGJfk3tvbFPnctnxU+7mI7zgRTzbgNbba0Irp1yEhQP8MaygL9i1nxkSMvt81z0JkQKoMuOXnT
dhh1e3at0DMqL3iF0kKl0DztiEsSr/n3zrcrzv06Ixzf1DIxjSLA3dMvjdadjjxl0jU+4RORfxmz
eAfXrnvB0BkFbvkOrKKlz11ph8UAa51xmu1Ht/mDp3OQMlet1nz52Edj2LkoKrnQKrrzs7Yo4Fef
2Dmlez2kLFeJo/kVvJ2Y8Lz3bL2h1vt3mvyvm1nVtqKnlT2B2f272J3Xlyk7m04tsLv6xp233p1t
3tunmTruMxtRJXcrNn3P1qUAJ33u6yObisBtkzuzp7ld3/3R3rq5sZORo/ORsLpfcN2d4z1t4d4H
nl14J01LsLU/hP4X3T4Fu/oChfMrD9sjYZ4V255L43tI3jnQNbpDsNTx3N512H55vAyfok4tuxiT
hNT15f275N5lkpetMrNbrFNPhd5H4YW96PmvbTo7sdrF3jcX635h696pmUI2W/rFv68V7N6j7RpV
nRM74piTqUBt6f6L672/o7elo7tRM7oRi96h5376655S7hqriTpfbX4x65294fqj5o73PxrFU+4v
7h8N8k647m6411rE2bbp8L6N8O73gTqj89oNPnff8f7P9MLVo+8ruDl9nzelrL9J2j85rxpwLVtp
9rNP0/9z8j5PsHZxN/tQb7n1714B4b7lsC4vLTcNm6MlN39d419h7/v1kJlbqVph81+d9Nksr+Mn
lbp7Nb/B7592KDqMKx2u4Fpf7//T3V+K3taHyhpC8qUB8J73+J6mBgIAIBgLhsOBtAoINRrAhAaw
aMxoORcMBgMxAMRyNBcOBxCxjE4qIBaMoGMhoIDkZQaZgaMIQNxgOIQNhvB5dDhmNYHFIPGI1HI9
IBlIpILpNKJVLJdAxvFoGNhyN4ZOBrH4pMp9G47F5BFpHJZPKZXLZeNacLhvGKnDxqMomMRjF4zW
qDFKHX6NYaTZKYN4XTJPN7YM7fFqzQK5FK9RaPYqVL6jLxtccFOY0MBjPbniKsMLvjL1Y6XG7VTB
xQ8rCrfWM3W87i7BSNFCBwNMpG5DqRtExlccPrq7RNjjr5GxtZ9PgYbbBvvMNrbrnuFedlLCiDTi
DbiaRADRpGsyIBkM4GNRvMhn6RcOarIhiNd3aYtYrbA6jUoNExpBzaDSuFQQDc7TCJkG7zhcGYYp
kGraqMkS/I+GzQhjAgQQMHEEQUED+ivAKyBuHK3Bgg7JrvEChrFDsBKWhi4iWsglIYNSEJ0g47hB
AkJBAJoQC2LqXDIBohCwEAXiOKaLDOOYQCKLCHho5sDJ6HCJIyHMNye5ochsj0qPWiMcSgjYZyu3
6LDytkMM8ocFI0mqLDZJ81RCi4bo1CU4Tkic6QUkoYSvOMEy0GU2BxP1AIeGNB0LKswUDMUGSnRs
rohKKaovL0rBAOwGjmBrruy7bu0It0QJOGLeoJMksVIggYVPVLjyvVqmouGTdvNM4Gt6twaygi7M
hcGizBBONWygqQYxHBD02LXdCWFA1gI/KlEJMj72KwuCNhzazbPXBlbQjVdjWgHIcMNWNV1ojNxV
VK9ORUviGMFIciyPJMlybXYaPs21bVwvzEhik68MavadtKhCrrW8cqhlZNbhc8y64I6eDtEiYZqk
0bMY45bxwwHMKYBieBKti2DNCpSJvhejeL/kGN24rGJYpgeCtA6qWongWOohhoZt2jlYYDiucuHh
E9uUnYaNRmQao3iOjZxi+V54uGnp3mKHPGn6FZLm+UaQ6jiIHCjKYWGsrsE8cCX/VGqbHq2d7PmK
dppoK3NPqeTaPumzBczKZY7n2ZWpVGw5Ot+yYxlkFY+nba6Cplz8Vv+Vbqo0R5fP+n66GSJPPou/
arzPA0JpnBYaGUMWluPS7n0+lJMpyEWVtmQYgtGwdhsXGcB2gba1wVFdY+O4ZtxbMcbq6S8J29b9
ZqIb4hy/TZ11Fu5fCjldBN3E995eU+zpUE+hs+ndYwioZruXgdnjL0pt2727baCC9J3/meD+WwGj
Pe7l0CEW+v7fI0l+SdnuN5fuU93rynMPlfkDl2zZ1LttIwQR5L73+PxZYbZtLZ3JwYQw8OAr43mu
aBpBVwUFGGqKII+GCD2IEQfTAaMkjaWurBbW+52L8IJQfgYQgkkAldnvYm5N8UEYas8BoQZl5vXo
Q7I0eZ67sogs8J03coz0oMGEIUR6GcWImnlPHFFoEGFewbh/B2LKoDtAgO4d48BBzxnlPOjg9R7C
4gtPefFkh9Cin3BAflV5/D/IAQEhQjaFkDvnBAgwjSJiqwaNlIxAsj0NIcQ8S5E5E0SOJBaic2S8
kWEuRcjBGSNHOI3RySdHiPkgJCSIkZJAIElJMScuxWC40rn9VaDZV67lZHiWgrV8SuleMTV+XA3a
w08rHdess9M0VoLIWmtxby2FwlwWo9tYy31szEXIs8ty510y+mMqVdqqJ1KcU9HBUSA1cAwI9Blb
pJz+oUN2gme6VZ2tCWE+pVBGkQkyTQ7AGU3WCG4JknGfjgkqEXVeQQHBUqIUCQUmVZRRliUQBtP1
tawCS0fO1SFBFIy4UAJPRk3ZUJ/nroDPWmM+VNn+k6vQta9pbL5l1SdqLQk2EmPW9Izpn4ysLUJU
qHVJyNE5TLUREJPTgweOKq8wJ+nP0nMITliNBqjFCf6Y9vBNpQO2IcZktxllbVgqoYqsdV6JuSa5
Scj5Oah1uMSdKq0AC4O3c4YIzJAyIVRr0a+uMAFmtnetYJtaCJm1SrDXCvr9S/uCieWs96GCIKws
PWKysFmOOCKhZo81kK81FreSG0MLW2QttNP1VdBbVV7qQ2VhERDexEr/Y6oLG6221sRa12sRAZ1b
PfU9oFtKp22sTESkMRFfWmq7ce4NzbhxZhwRyIjhq0ltQQ6G69k7WXaIQgmIiW7TV3etcy8lt3HH
FPSahDLH7v2EKPe61ZsLcGzsJdOwgM4pnaIjeG1N2LQXmsJBelMRmCWcLVfqvd/L4mjTI4RBGA2C
HNUFeO1d8HnEIacbdftyD9oZs9cKquCqBlnadWjAlQYZWfLtc8gZ+7Lnfe9gSp6f8PYTxssKi+Ik
uWahWggGFX8VWUxYTq18T36VpadkjFOCMa2tLMbcnV9sCV3OlhKo+QSFFnLbhpfpRnt5gxXUmPFZ
lfYOTJmjJWVq+ZNctHipqFEMOhyre/ILw0aJ0sEzN0OB8/WtQlfQyeMKIutsNkvOubCCI6KfGk5a
FGoutznofFhBazJcrq90oxrrJYfyCTDDBNMooDMI63Q2prWq1KeZHQZbmIaPzphTEJTFiFMYVWlB
JRnX6ludrFnxaMdoUJKyfYmYdY60LQZOzTodhav2LiwHBpS0Gn2nnvTesNsL/IGobRju1b7f2vpI
gxyCj2CYkreMWNNI39OsdiOMczv2kPEeRkx6I9ntj8fAtEgSVH1PWtKQx+0sH/Q9JiR2EEFoNkoh
FCaFULoZJlJxFaFkQygBAiVB6dEU05RZKklyMSXIzPLK1HBxpYI9R+CBINPF8S4X0k6iMW1gUsSx
RGf3O6ZKnoEd/Q1CDtbvoYT8mKzqI0boonfIdLqJUcpKnkzNIuqUe6tSiqHQKbdSph16mbE57diJ
PPCOKMyPlVJlK7lyO1Rns22qeRhtipTAS8sOjjUVUELYhraB5nSpMQTVAouBzVeAgDGrtBrnlgat
yHo5zZPSY5CIs60+0SltlVSv4tiFXXOFwqfdPv9YvRHrJyCBNAU15yoZA9X01DYKELmB7A+E91x0
PV3ShkayYYEYWsnYjd4pnFojOsb2GNfT+zWcGYFTPDpMJrM07VfKZWI25aQbl53s99LmWe9YBP9A
AtLMqog5YghKf3tPNtyCD2KYIkfDu6uz1IMS7/FvP7e9Fyir6pfhAj95Nqgalr+gwgtJNj4RW4uJ
Yw9UA5OoiRvjpjuSYRU5ED4ajA7UCaYajZiZvMBjVr0JLz+TfarsAMERvJeLkinQhzmiW6XJfYjB
qKYQ3wuYnQ3wkAg5gz1JsxhZDRhLDRLZVxZMGozCvcHIxkHa3Ina4EJbUIqKGI56KsIozsI4ksJK
/xlqy6ezRhc6GJMsIkG4nhi8K6shnqrLJKzRbogihb/jskMJzkHQhcHgnbQQia7htoihVUGkKUN8
Koo0Mg4q3pwTssPBccIcPkI0McOUJRwS8SxjGAkgtxPENsG0RMOJup25X59JhoiqDUL8REKkRUTB
s7IpuzAYkhO53sMES0JERcLBNp267xXaezScPcN0VkK0V0MsSJ26F0PCl4gsSkKcHEUUOaLq3kTg
5omhU8VcUMS8Yxhy3UU7ysYIrMSsZ0VsUajy0YkzVaIqiwzUUEYkZ8RhiCsxW8SCjoqBNkZsccbM
aBdp56po3pCJy0a0YcMUckLBBK+h0MU5VAtEDcdsfMd8Rg9I25BMbyRgtMYUPsYsgyG5ZkdJ8EcM
W8bEXMbRoS0YnMeaJB6sdkcUgkjEYzASsxoUf4+J1shsXEP8XQ4pfqrMkqF5KK5cgcOEgsLBpy+h
fsdJ10ZkkMm8kcRg77Ei3aDB0ThUe8h0fUMr/bG7AR1jXkkEi0d0oUnKPLG5lx+4j4v0T8qkkUls
bQiL6bWR3RUrIspUlg8clw0YqqrIiMeY8YtEhktMi8sMYwszMjHx+5Nx18m0P0tcbQhTLSLx3R6h
dElcu0wMvC0o8o7547bcr0a8qsu8RhBjDA+EuJKMAMv8h8LCYTNxEB1hDBQ0W0ycsExcRh4ay5tc
bzahQ0Q8r8oMysz6FYmZixtrfjbMKM2UwEQA0akI2448ebYLbMyUfE2c1Mz7VKG5mRvcNkusyk5U
Mp9oma6M3JAi9E6M1E34l48Ip6EZmQn64E7c5M7opj1IpkIs3JqI2s3k0880tgsos4tKIw8ZoYj0
zspg4pAw24prLg8Y5ojsis+E30+RyosrHZkI40qdAsz0MpQzDBAyrZhw4w1koFA0bUCI00+zM6i8
n83tB44o2qy82Bhpb67k8tDMYzdY2jdpkDKYjlAk5FFYvaeSOQ7rfI8KO7fqPQwiPg9zgQ+Q2Tgy
QjhKRDhiRbiyTTiKSZB6SpHQsThzi6SDjRD7jpzjkCUbkQlSUynTkwEDlAEDlTsj7CV7uCWTmSWh
e8Fzm8Ar9z+8Dr+b9r+z+FOUEhYSlUGr/x2pbhLojTHRZz9sBxRSSbaUD7gcBECB6yiEDUCtRcDE
GJVxU8E8DD9okhSVO79pMlOMEbtFG6OctcAY8SHiBSYAnJVTy9Uok9UTLaYztcNBNAkxqIjNVQj5
YcBb+h6iOwzAo0D1XTaI8RZZdCaJP5iav9TBMdYr+NZFVdQVVChdVlZ1UVQI3pgLs6nDjaU45cFq
nxfcb49pQlWCt6US7Qt6LgilACjotry5VJGpgbEBzQ3MHsdLtb1NcVMteCxI/VdFCkgBXzwddz0I
t9eJwKwKpVdSMCkdfFd5lFgppTJNdDSyKhkwuNhlgYzFh5jMvZhdBSJBBldtcdfSvsQddETRkCHh
dti9cljRx54ie1j0ZUNFldkdczTBzshSEotVmlh1fb8BjqIaHYiU4dV9fNntkgzJ1TJNBQorRNot
htgln00RjsU5WJsFnlqNpEeJhbIZ+8ST/NgVllfaIpztrZ0B9k0VrFjNsdF5s51hO5kdp9jFcqMs
P53Js8NB+56gkNtVujehnlaJ7k3B3SQDv1sNmtupW9u8RszT41gNkVo9cx1p1RVFAB1otBddw9yN
xJ7axVph0VcNzVrNcxBNyjcRmQpg49uVsVki49xbDZoMriBVvtlpnizp7jAE5zbdx9o10durrqAD
aU7AtB7d2lfZjdyloL+gn9ZF0Vtd1qucWNBVVA04od41kkmB7jbJoJode951vzCpYRhSEUU5mY2t
3lqF59cyFdylsz+k0lhd792rG85pP04kCEhl699bSiIjpZttD0xF/VupKFxY3tBVFD9+AVv7G8Xy
3UebKYHNmd+VfYnR9CLsU7I5kZWeCdkldiNGA6gy9GBS+NUFHKOrfaPDf1H7gCP7gY+bgqQbhA3a
Q7haRRAaRtKhDSSRByUdKDiuHFJjhanKT9LKUSUjkdbRFoEBF7k6VbldMzt6WLmLmaWrmsF6XdVF
atZ1U8GRZtaxk1VlVFV1i4qVWRYZL9W1PNXNURS6HNX1S1VGNtYZZpY1Ywqti2OdZdY9i1Z0BjTL
0laeLMx+L481bBT08Bl5aqzVMb7JHRHhAZO770Wg9goafZXxwQttYVWmTK5LYQmQkmTYoZTmTpfr
v2SeTix4tOT8PIqooahOVJDRRQj9pLpgiF8QrAtK0joSKsx+WWXSm7UQmg32XOWmYOSWUL/wMT1o
i7S9MI7uToiF62U+So7WS+aNYSPAj2ax9QkjSomWUeS6FePExxMqx7UGbBVTo2aGbmaZZ2ZWJrtZ
DRG8DJLTzQwizKfZkYhLvaiWXCkSoYqxZI05wUuiGBiAhbxZBRDDCKRj1IjD0AwzytgBTBqImI3z
zbbmhJAxYUDahruxOuGbNL2Ryz1Y7QmpPajigxyyfek6kJNhbYmFXOXwzCe7xDQCiBA67BYI84g+
nGkOlKmT3T5zo7PehjSqfTo6b7uitZf8LpOye512iKKpHT5b1OhNdbbibwt5YEGS9RZQ3dTCig5p
KGiIiQkwobxcNREAnsgDJIqULoiOl8SRcOkuuBPkgBLjjIBsNSewj1YxoVXKCmjj3ysAoaiFXpBO
oA74hZOOu2uQhOoT55W6SZZJA4k2vRiA8sAMCw9iOyi8DpQuGclR1srk2xBTWxZrzwvz40Cqzj7w
mCGOYaMCYbwlZWkCZjxTxhXCv5RQiRjbv2wRrJTDWy9Wkp0Iwm4W07NCRB0J59P8O0AkfyFugWqd
QTjrN5OpkScBXe4J8OgZ0Onolb549I5r8A99vGah+ZbhZLKahZSlVBuIi49V7I9KSapZChKJlzxa
+baI3zfJEAuI9I8s8iSo2wk/AR4pMrKevO3N1z4wrGWyJ/A7agvwww9Sewg+kvB3Cu+QwnDBLG/g
nWXY9e8PBwjo3x3cuBZy443aCnCD8RPPDZYhCnDxlxOOoaMyFhrwtb62J4EDtz7TuEDJDBMDvujg
iyYDypZRWBqMnlQSjq5ahfI9Ugtw96oaMBWcgHKxdwnOhCI/KuTmvCiZY3LXMMrNaSwhU8ahf4km
hcDfNYuOhOuyiiEpf9RusC6ZZXOsWzoiklPNEHPprKizzsDNQCghVPLsCXQ3K5icL/PHJnKYjHIi
qPJokLxed42l1TcdF4h09TtuRr7YzJqJsRBRBDnomi0ijjtZZI47aqijVrhShKlB1uiJ6iowgplv
NVAQ9vWTPc7TJIgjw22AnLymGeXHDxkhZXDy0ujQq0tHYAiPVgiTw5YDWyPJRSCyjizm3PbClOtm
haM/UR3ml/cAwxLh2PUoi3S759bawR4Yo3FAsGvStXeBWyrva5CTZBiNWm83VCi/fY9b8HZokHgB
kYjwpqZhWHe/Y/hJW3eXbnhBXzum8uWOXNdL8KJI33fx16hpBnOKp3fXjHjwi/d63bw54orHkveI
vImXS6LSM6HFiaLTllM+R6J7gbFJMguI/pBi8Jmqp9uJOKYUDvnNuPd5jYnpaA8wmXo5S5VHNPdQ
BvputiAkDHqaigiXPvoY+HXUNZK/nq44rHYB4fQnm4tPrvshZzE5KHsUZS8TfKkLynrJ9XuC6OrQ
mgqTxfuvpPqHtRO/u3pSPPtfa6onnQEHsxiy2nw3l0CybvwtuI/pLwny4Pw2xtW5dPoAuOwWs5Wx
XqPPzfQ/vutPWGl/qpZ30BNlY3PufW03sa8XySdv13QnxvtvrxZ2jd25ZXtxK+1Ys31PuYof3q63
u5aTxf4SofvpOP4/ztHv3GXvx4uP2nyluPl2RA0eRQwWgd7Oh5BF1XyIt37ewR6oi2gbsIrJ/hdE
LMNp/jxf9PA39Zi39ImE/MAyM/+Tsv7hoXqP+/+gkAk4HAgAzFw0GI0EAxHIyFw3GIzEA4gQwGo1
g8JhcNEBjBo4hQ2HMUhEKhkOjkDGEGhERk8PhQ0lcpFwzG0OjRojcCGg5G0HHAxFwwgogNs3gc6n
gwmI4g0lGsMo8xGwxlguptSGM9n4wmkbhVVnkKGEfEBsjc+Go5r8/sVkrFnnk+GY4ndspFxndXuF
yscbut6q8KhI4vclGAykElwODsGGnk4GIywdInuNgePyMDHA3yg0GUkpA0GsOq84HNSHGfGmC0Yu
meajWngehng0n+Qumx0VKFwxG+C2Ee1W6GWgh+Sq3C4mvyVOq+0w2mxeH53EPNc2vShczy922fZh
237lXG0x3mDs1o8XkzVs888GushGKqke93wtFsrv0q44F2Z9ayt2/QcBy3YYoo2AYsKiq6hozUEQ
UhCfI4tDlN3CAcpwjiHp8zjVBy2iONMiIbJRD7+hkqTXtozSERBFCHvGwq7wwzDILk2sZwkGUKI3
GIZRmuqgt1D7jwIk7fNIlAcP4HAaxSoicrurCgIMsgzBUBqkM6zQ7hAgS5IMJoQOsl0SoEmSHKGk
syoqgQbs6qaPJBE0qIeiKJoq2k6tex0Sz1IU3IlNqFzgiCF0EmE0Iyogb0RGgYJXQyCRKkSMUMiU
50qraSzkitNKnNiYUgpaWpfGlFJrKCjLwn6gzU0kpL7UiqOY2CZOhWjjp9SFNq7WqwLXAC3L+tSK
PYqj0Kw7jwL9ZS9WZKTABkwT8OutLE2qwrDsc2y+P649uMu1MWUlQrPtk1actM1DgoE1tFtg0Dcz
1bt43Q3TeN8pDgO64cDuNfrk28zLjudJyp21gKKOqwjGOa7zt2bFbtWgnjxhm8tj2HG+MP+ttkve
qL7usGsBZC+Nq5LZMmBvjyfBjAUCBjAziwsyCEQZBykQTm7SxPHkH57DMbQ5ac8xPESfxJo8Q3hF
emRfG8ZUG1MbR9HOf3hq8FvIpbaSInkjNTOyiyVJmDz4ospV2oKyDnLIQMk7TJOHuIQDWBqCv4HM
IIlE7NKHvQXb5m+/R+9CcpjPEExBmiCwI0qUJPb6KI1AzPhu0XJp6kAaqQhK78M/XPcHH6D78jjX
bz0nQdPi6/dJBvNPGpSD8TyPXP6g3LcSGfFhh2iUNTwe+9eu/h8J0739TRabQM2iXJByYbhqyHAh
q/kndDFfqoOpsToOhrMKs0KYwx8L3hozlFwMhUI/Qhfse8nwbSb+H1ZvJyqflmYbp+Xpyz+iJkoN
4bsnL8zWAyZuQgn6DYEETNVAwk7qkDECR+XeCUDiyQVBdBcg4MjjLUdWWZ/kIFvwiQNCQ1UCjal7
g5B4x5i4XPlR2iyFiEIaA2LvCxvjC4Rv7hWYBQUG4BQlIEaU/8HAZo7g/EdjLq0zxMMee9f0M4VQ
fiocSIkVzHnjKalWKEHYdQfi8DeMEL4xmPP4WEqUW0Cw7f8TpzrLwbnoWmVQGZBg7Q/MNDtAkCnj
vZL8DNncdXbP+i/B8/hLjBO8kRGaRRu3FoNKoVaO60yrSUYPGomL6n2SaKtAUGCz28ygfg00gr/n
1IsQMaxD7tovA2gW+l9bvCFEQfCiBN5BwZoETeixyaGJMnvcyehzbNHeJGaM4x+LN5KPqekRE4jj
3BstdOYAycASugwmAYAq8CCelWem9155JnpPcMgRpK6WSqPABAl1L7S0xSlb2315YMnAT0eI4WKh
+neu/caSB25QZmOcfY7FzLp6Avec+6ZBM/T0Osoc6ifFB6GuheNQwgdCUEvBds5CgjwHdSfQI756
VHnBPJo6UmQM+3lN/ea6t6CiJxvWdW9lmFCpmvef8hpmaGXyJnfOzOWk6XVvuNK/B6hqn9P1JBK1
/ED3+SigBD+Ab4X/OPgRLKBbYkWRFgjV6g8Fo0wZiTDmHcIYrRAg/WqN0EIPwyiJWSHdcoww1rjC
2NFdXiQ+hTWyGNfa11wMfE6s8UY7WGhnYiLEHYtVWhLFlY1kIVxljPWiMitLL10kjGytbM44ODBt
HM3chpOGhj1HxksH4/0OeG9gu8hLSuIkeSiO8jJP21kigagUiJLH8kxIeSskY8u7lLb6rD/y53Hu
HURpFwpVvwI88KWMsyBy1lLLc0RBT+y7IbL6iszJhO2mJL2nVBpkm1NVTW6E0ytQNoE5CazPHBzZ
qPO2brg5v1/nDTp6j+aZznp2Rpt4MG4n9bmicg2Bglt5VaZCeGCEwpjh0fODBtCJkUKGQwzEBMMJ
4LIFMBuFWS4Xf3hrEccXHGPjxG3EZXb93cwyXsG2KqnxlZHiSsuH7Jzrw4anD2JyhANUabt3z4cc
F7epHiBePMlM7yOzMrrGMlIcdqzPJyVksBCCoA0F4RjVAgCoGYBryywt2wM/6UZBsaqHlC7R6mYi
h4GCoRrOgdwGgoB+CkKgagGhFy7gbQTdm8aDwMVLBpUg1YHc8TtLoDUdnvQ+aKPJrD6FDYw+kzMv
DaQ6LRpk+GlNOn0j3qCSBDdR6fRQT9dCO4OxMOrEtXZsgcoESXi7SL8SHa1P6ZPXJmS0a81uCCPa
O0Yzu2Fr4j7gwaai0sWg6oYm4aGNY3dvIIAlJj1BjVFmldPZD23fPVyOzIbhhtSW1epZWg3jTuOM
cS3Px23QTvWMrduac2eXvaWhtCNw2zpAzhMZ3ao3yUNH6EpN7ePpweau3dU7E0hLJCxKOFFoR/Ko
8pj7W7Q4jxgzWydccBf6CDkAIDhkKOHrvWxk9i8BBnx/lZUuT8Ctjw/aO080bVbwVLf6PywcU4fw
biRL9xkJ5N0O228+Ic+yNayMRO+LuK6S4renEef742+WTfe2G7aLbZhBMaNAaRpItmcofYo0pLQt
ctn1UWcNKJ32d9J6G+dwhdbLlJFX6NjcD3jZpPH/Q6O+3mS58SroElkmlvMS4xLk8QnDEO08EEOb
pgvaxSFGmC0eTB6rNySmZ7i3nZdoCD7sgM1iBRB82kcMgdVFsHcqG8LqhfY7N03kDor64nVs/S8o
TmfyQhKMi2j6gpC0RVs2okcr6JIxljeFgo4DnNTSzeO0BqiU/hj1yS33Y+wHPwCXqc1qoP7cru6E
C86Wn0CiwxJY35gbnfdUDLkRcQZwP8im+AcH9dT0rk5jPqkiEJ7v/iikniEG9nFu6l1OTCgCivPI
4v+IQEOOjGHiOLjQJQHC3pXPsP9iQI6pJEWNliOQPGZP8nLCLFOjeQSwQmdv8lWLpmuP5juwLP2J
2HzvMDJtBm8IFCcCgPSifI6qbQeCTCrMODOiHQhkmvhQcOTDhjKjRMijelFoFGvrvQojBIFH0mHQ
jAZwkDDPcQPQgOjCNQswwPenFQmwqvbJbiVwqQnwzjTwLjOj+v+Pnj+w2w5iXQiiFMjwhw9QfiFw
xgGibIFJ6wliLvQwjlWwPPMKcjOw+PDQPpoQmqewKCsHowpkfpXQNE3jIJADdsrxLlBRPiJFyE7x
MkYpyFDKfwmjxjHjjj3igOZRNRSj6xZRMn/N2DDxYmZi9oFRcrRmLCFkNCyRSQXEbjeluxjFyI4p
cRip8DsjDxmvBxfxAkpRpxKRoieEmD6DqxlxtsEGRxvvDtetcRoCODguYxfRzplmfIQRxRaQXR3M
zxnxUwQspj/xqxdP+jQx8xoR9vXlMR1mTk5ojomQysakPHoPvulwvnqE5j3j4whpRk5xXH1oFPoD
RETOXknyMCfvojaGZwsIbszvXoqyPFIO6DaJCJGtISSFkxTxniwSSisDeiKIFCfEPm1jWH5ScGlF
dJzQpoCollkjJCZOTLuJAPSjJCxIFEtC4ylxhxMv0LwwoxHNVkPiUCPCsuLQnEGi7n6tmPlxqlIS
wEmENRPvYyrOoI7m+RDiGCdp1P3J2tHEvMJAQJ5w/QfDeQxQhQ8y9wuQvEvw6wrw0w3vZSpQyQnP
pPbQmQyjOQwvYQvQtTIwgxMzKQzw+zFwrQ2CDQ3CCQoTOypw6PhTRS9Q9w0TTxATLFUxCniS3qcu
DQuxFyoy4OTPGGMD0RJDiRqkBvPEOFBTFDxkBQgPUxPjmwNRMRxlLyxx4vPCBRWTjkXirxeRZx7R
bRezFRgRdlWxzTtxhRkx1zrj0zwx6tWRmL6xqR/xgirxsRnxclVjMz0xsyAO1C5OOTlxuR4TxkBx
yx1qeplz+thz3kTkPCfR3zxTzu9IOx6SXTxiLR+z/xtCQo8R/TvyAsQSXSCFBiEyumQwpPXicjBN
iyHQEyIyuiIn7CESLRPIbyQCYinTFSMmjyRQmyZyVLHSbyXmjyWRM0bjKIhyXUflWSbQmycuxwNL
RyRldiozkzgtIShopDYCIOoSkqHMikB0dSnjVTCzFSqEWS10jNmStEjMzzPvumYG9mBSyOBywkl0
WmLwixGy2RDTaqcsCPJC5PKMFG7NEpKvNS7EwS8Exp8CIigkUIjsjuDGpGjVEMWuTT+ngElJfIDp
8SnmCtenVMRNBPJsDwaP4NIHMlWzPHxEMMUJ8EVinEUFdkBxfM2jQOZLuONRfIzLRSbmYSeRlVRE
61HVTC9p11LPYVMElp8p8CRPwiOsjxikSD+jcv0IwJ8C4H+O1CtLl1gjO1htNstPJQuiDt+wun/U
eyAp3NMOXuBSFD5ty1zHqO6ReCHQuvgHHNligCt14LuirV5iMQuqSvUvXmS11V+Gek9J3CNV9iY1
+uxCKV7GCE2kvC4jySClF1wH4vz2HVwpRmqWFVzVxE6WCRBgGo8iRJcQBSPvQo8s4SNRYvu2TxQD
jmLujI8wgU0DdH1Eno8ikVpyQqK2byPv6LripWDCPjjw2Pl2g0kFiIzV3iXVRinkm2NHIJN0pk8W
CiCSeWm0M2Y2rDeRKj/2sn6vS2uEvWqz2GWlWuq2gpN2yigLl20QitjmR2siRvS23i924iMDeNOk
l262xwPEzoxiyWvTIkm22JermsOPv2AFaQoEOKctS3C2yPMGjQujxtajRStmWtPnfL60wCzCCWJX
NPv3ORA133QG6y+NLDNQutJXTMOAbCV2C3SklWiW63Yju1JWHHl0mmHj4wumvjgnoXPXYUDsaxbW
MIlvs10EBjBXekAme13XPpVI8iK2VCd3VQ6EPDxmW2NPgUQPdiISW2eUsiK3KQfWeIQWU2S2xWRX
0JuS4gGp1t+NEJ2NGp31Ap5NtWN2MVx2TX810V/2LWKXplW3SV4yIYB3PmWV8Xn2DIl2BV02HWAm
jyy3P4IiYDiWFjmHz17NM2G3YRclh4NX+2M4AWOWB33CbWQxh32PutMOxru4V3q4XC8RhJety2qm
WkpXgWbWl2cjd2d2lpuWfWa4IP92hw72i3CydC02k2xCkE6irjJE8W22r2i2+YqW9n6QPWw3AWx0
uWw3A2wWzAQNY4k20s1Kc3AYy23SuYsCLwoW6YuQgW71an6oRYwDeW/W2YrXT3B3aECW0yckNWDC
m3FjKid3HPERGFCXliZHBqh3LpDXrXQxAPr2bXQNN3To63SXVvhH6XiZJXWH6XX2QXaliDTrJ5QE
lE9Gl3rC5VMXeNKyGGH4h3hPG3i3lo7r9kTXlWHSQpZYBV6XoCB3pWSX23cXr3xiFs44N3unaSoW
qSmSKniWgWl3z5gWVuAje4YFFsCs0MDiDNCjYiKEusJgGvvndSNRXE4SHCHAWoCjQiHA5AygGghZ
zEmO/0V4fPFGZwgX9EbvrmRjHsMPo51PB5zilQoJBC0HApRrSjgmzsXaBFaTdHsixHApW1sRwClL
l1N5vGdvLnFVAJ45yqHiijcqsyoaGO5yNWcHTrgPDEaSlZ+CqDJiYSlHLLuSslB6ZIC3iO3qnvAz
0CGyWn+jWRTZlKnmvpPFWFEGZ6aSgUnkE6XlktZqXic1nakarKhz5ahwaktC9PN6nH6vztXvQ6Z6
xwNLvoXEEsjSNJpMUKfoxSgOXoXaGt70KOxp8ssFCSgNa6ApuPcV8CzIlshrnCdPyvvrJqVn1O6P
Zv7G81cIkF+rl6Sx0aNIx6LpECtD6nMokm/XXDj1wzY7IPA5MT5GMbKG/TwzqDs7CoCjQFySz6/m
L4cuBa4VcHmO3o8oUbANI0gO+bIHl3PEIlkbFaGnqjcvoazMZOyCupPINiwvjzkk8aL0U6yCGsXa
OtqZwJ2NmiHPNqRPpP9DDDBaGXKPHD+pjGZFTDonwwga6UKGE6cSVj9OymHVcHPVJ70skJ2klH/b
yH2b8PwtO7776FkiWwA6nbOi0wFnLbonGcGQA7w2fJZKTpq7xn5CNOtt+ZwkGkuEx6pCfyjz2tWC
paGI18Rz+nqoMYnH17iDQoFsYQQ7Bqja9ta7BMmb+Nax0iqKHbI5ZT5CJQDcf3flaJWGvwAimDmM
WEnPyivaccWvPFfJxcUbaimpgcqv9chavZvCpOdoCo6yYRA69cwPx3dvnCrtWZVCoJWPgWvmHiZI
Kc0n6l582Hwm974F8c0c8ajo685c+DN2R852RlDRC87ioF2tX6ic0iJElILJl8y8xDUrtz4cxc/F
FsySRHB88iWtL7IdAWkMroGCQ0gSoGZ4/pudS9FtbTplL9TITZjdQrbYnWZ9OkeDH9aFopJKn9Wa
+nw9UFySc8AmZRLdhdNEMPyredD9kcGD6J1PCdc603PHA9YWZkOHFoTQuygDmITPlROQDITT445I
P0DqCRL9sdyklGX3gvCd02mrw9wlYlaGb9uppjYCm8a9svY97rvdq95bc9/dpEn9MtVkUPhNbCMd
qd3YoYfIbEOEBC+96QgRQ+In2Ib8geKrAnfDcmd94Q+F0QPieit+NeQECURK8iw0uI/58NVje+Dr
HeRtVuxzdeVjReCqCRJZZeb+X+RdMG8nJjOFwFD59+gdWk/pgNO2ZjnLvJg8k+l8am/JCDsVjKXr
VmHigJgD3+rFDFG+Rm/etkz29aS+pDKCGnNckehezH2HJsakpToVupmegjKC4r1nodWlAit9Mr3l
p7k0YbHkEoLdCCO1W/AI8DgjAalr3km8pUx+15fbEfE+7Yja0e49Ww+JIcHfJC0uBnJmYdg4jnTz
Bzf/QcHP0dTCsZT/QoO/BGlfVe+C0uXrje9H3alkp0kaGfad1CoJrnzaqD4HpFK/dCovl/CjCjgn
6HHe99CC4HQ/Ajcld0kfS/V+OCF7Cfi0AnML8iGElfs+1w+czF4r5jCoDfufqnC/cwNCT33e9Fdu
BwPiGby+f/295CtHC3hjj6vpgCzM4+GFpoKAYCADEXDgciAYjgYC4ZDgbwYYDIXDEaDSDQgXDAZj
KHRCJRQYjcci4bwcQGMGjGHxGJwaQC4aRiHQKCSyQxKCyiBDUbjWaSqCyacQobDGezaYxcYDaey8
Z0cYUmeyMcSUGmaTjEbSKhwYcxwcxQ21esjgZ0QY10XTwYx+IjOG2eIDYc2a2ROm3AXDYZUSgWyd
1yIDW1Wyv2a0DKV2sbwO33MXDkZ1O+4uQTfHDaMwa61+uQKJ3TFwfGzm11S12McYacjiNae85aZD
ip64b1u8WeKSarWscRG5VwZwrM2HecLLcEa5HNb0ajS1ZCRDKbweBjXDcEbDWf1eajXZ9DvbOzi4
ZjTjwrWZqQjIb9+IDna6bxjIYY242/qDmH4CXSDlrSHLnsC8z5N6hbLLi1rqBgHL3MeGSlOKrDzh
kzLdO4tIbsaGiFIa4jxhsGjvw4nT8JDAK7q+rTZvooSuQ4uSGqBFoahtCMVL1CMWp3DbyNbFobBx
G8OBgiTTSAGLnuCG4YRYhKyuAtKPoNFqnxS5CGPkkMYyi7LxJCGqoLO4IcxC9UMx69iqN3FsGueG
rySaEDiL2i8aq5OChrVOoZttAKBzFOsbO/OAbhmnkZoE+CPT/GyPBkjjszw8jvSoiEGUZOAYBqjU
Z0uxEXpEGkdIEqVQsFPbPBi1scBlRCTzqlDnxhMsqISudMqRH9bhxN84skqqT02ly3M6kTZTnYU4
Lcw1LwCh04RrBwZwbaDGQElzMNMpKIrI/lONnbkRWwGbMpQrLBP4h9X3OvKsWMka33Es9jBpJKHK
ytdWIE8rt1lQFGIEhaPWHMN9pdcM4BpYqz1LZELpRIgaPs6tkpRMj0zGiNK4iiL2yjUaHQ5cco04
pSgBhDiQSvACzWHBklPJZ9/qw66LyzlE4UhG6IY/f6YLxid5ZVSD+XtTthZHe68PLoaI1Xb+F5Ei
+Jv5Xs12EuKdSiuamuIlLtVZDmipRntkNwtMKoc4MGSGtOH2E4KmVC7OCSXTdQudeUlpHUN75Q4K
yRvwIaNajC80Y5G7PJczoYm3O4ovV2QQYjbo5YG28bKvOt41rusKDCEevgnmv4E/az51byg2pQm3
rVIqRTFRrrW3S4YxTQt382ssb2jwyIMiw2dahlCIIntz9dgiHJ7RzPDUVqW0OTGVhIEzFZv76HGR
TGEgqP0VQ9JrAYBB8vzpcEA1gahLnJ4O4QIoJoQAa6TepH7qL2rVyRKaFpbDklNDkGUBoQn6oNJE
7hUKDCplhLKTlnwOESOTDYA0jLI3pIqgYCCCr9oEl3NqWlSUDkmtUNmkIgaaoKwXJcgQj66G+wOS
SRFIpFSxtFgqFN9j5oeEJKI+tJ6lX4OBTM/OCyw0+l3V608sER1lraIOb1iZSgZwlSabAhR+4Hku
dqw2LLSCyocNSwGL4ICymLOaRWKR8YzlpI9EstbkI2xpIOqV2sYSBpGI+SEh8VC1xcLMS2PpVIqm
9iuT2QcVYnxKjsUSRR5IoRwSMSYMT7D0FKfhBaP5gosH0I1DInJ2iir3hWSgpCKSBEPKJDI4LuJA
khPKUqFcJTmmNfa1KGSJC5k9fHLMxZ0izEELSnKGScCyQnVuVuWZWSyk3NkehZLvVjlvNYcKWUTj
XwnLG4WaJbC3RKSXAqWbCm+kHZ0V2bsaHOxLOkRqcbnDWlkf6UqGRiyMzULGpKZZwiKvMNTN0rKX
Ioo+IpL43xajUuSiaWV3UwUwN9lmb1akSiEqbk/JpkafSuEJU5ByI5ISySvWJKuTR75RReJQQ2HM
O3zvmfTEBYhTZMxVm2RVnR5ZorcgkRUxaQoqQlUXRspEjo/uZltUOQhEjjVCKfUSZgN4309RtGYr
B5KoU2OFHKqpbo3lxhrHhCszn2g2IbFuoxFaxvVkKY+q5B60xmp1V0vNX641YQq5CStLaW0waECC
mZ9THpiiWQ9D0RzFn6QiQyYZGoqonagQdMCciyvBSzZCYawI8JCodZeqk+YTxoi1VVIUJ1NJqJNN
K0c/S0nJqpGI2xFpa1UspNSjjVbToMMfY+2DVYq2HsEYG1lvbA2JtK9WvMPSDPqk0YtG0zlSqGnS
Xk35B1LrIjaV2uR5SmllQMcq6h5GpWnOoYKJTwWpXcUBNS6pU70EImpc8pt4je3uIqZ6UV6LyX1i
yRS9CFYTunq1YdUEdb91UuZdOhJziCxtubfpDV8Vg3tPrWiFrpZNXzwnW4rVVI+F6v0kW/h4y3Xv
IvJOTSW5d4ExBhwx7IcNRsPGV+xMt1XzNxbjMttRMUUiIZH6WCGie49qTh01pLchYStpjmqmGMkk
TVeVbG2MpR2Fyji4lrC5HItPpSJIMVEaNLJbl2QiLTWE3zCkKMydUmkeyulAjMqadx7afWrNWcT2
qAu3mQ6RLDmIizTRzMGfbMZahqR/QWLMpaGzxojKxNUpoXzezfNhlCZwOzrmw3rF80r8WpnxSl7F
BR0zuofQainv6K1Jml5jatFaaIzquEGlDt6vIVqxDR/b+J1TKbPW5e8F6h0mQpelp0+adI/L9emk
c1ksMW4/TektmLHO3lBlJCp0YErIQWEjY9r0JByZCuCJMXTVMRezatmrVblkIsMj9CHmZ+ke9Lb2
4N4yMLyf627Ct7J9v5uwv+BCUYL3Pa8gXAd17isTwVysVduTxX4mbhm1uHb32nEeVtrMNKHpzxei
l0ieRVbknLDU6OQHRnireMG1SMZJ5JtWduFEbcf5dt2IPB+JYUIxT9IjDCWntkc4cG7ZOez/tvyH
XhIefVw45zijXJUk8d41pAlKRS1SCaLCR2/VZYLFiq8y6ZLTtc/MDnZMEu7bkQIJ0dlvSmNwg63W
Vw/T5ENF6L23TyTNzdoWroo5122wZ2ilazs5QszeB791nu9kup5gj53TCJTzGIR1uXKhfkMhaKKf
ubgqUNFIQ78Z452nvPbrVL5JAy2uu4l6rIbxXiNjmvjl4vqs9j/RV9LtFVfMvQezIi5O2/m5Amhc
nFUhPl9blu4F8U+Pr/KNYmkZgw0PsqVVSZ9E/sfjFlPqOjass3oFFno4fCpNzFWUcQhgaPP1mixt
rbMJXH47pTOS3ZKbyZrLL2+79mdZIURVq+oi6mEMEvYqqTussSExCoC84P0Y8+cQW2MMcPogawuh
oiwOsxCikaWMcSY4+Oo6CNULy6ixOckO+Jy4gPmXoi8VdAGJqz8/AMeo6vEj4yBBcRCj8fu6CqEf
cyWWyOe/MxqOoSSMs/C+wMe1PAWP0sZAck6Tk0gPGImYoMQnpBEOsQcvyxsNYRSZ6vORaVWQQ3uw
gIyfao0Lweez+LyTULwOky8o5AKMc2+zGfazQi8SC1yh9BIJc3oPGIYlQhFDAPGRqNHBAxCx+Rue
ixZCeP5Ci+czIXSY0YGmiTa/OY07C2eQqZsPasYTqOSO+nCL4gsTqgkcScQ1UIu40Y0XK1y1NFEI
e1KIGM4Lw6DEyNXCqzcTqIWVYq8jATa3+LQrJEyISPaUYPeY/DCOqZjEe6kWWwymENq8qZ0XsqYb
63qO+SequkeqhB6WI1mW4U2RSo4ZSrgmZEbAWkLHCJc/KqQtuKyREsSxQ78KyQOIqlgl2keQanil
g98mwrIjePWp+WXBw/uTuket7HkK0cg2oTISnBcNZCk5KV6YOdw36YlDuYW50UoOeJyP2tue9D5E
A3DCLIwqs5+U1AUlSW03yf0RvGBIE2rCEi478l1HQMisw5cavBcIy78YxHQOs4FISqPIY+cbBDQM
cNk20iOeOw8NuVq9SS8aNDe9STKZ4hE9iOCPZCzDPJ6QyWwYXJycQWa96ZO4sdlEKjy3MORA+Osp
/KqdQMc9C8GIJJCMi5kMC3Ai8O87EbTEDKLKC82YoQCpI9sIvIAOgVc4EYFCMOQK3MCJ0cHDPLDM
CNkcw5aI5DkcdKWJSVcZsii3WeCd2LQNlLwseLQJ080jzKuOtDAdiTDK23gdiPpKuRC37L6P5L+a
wCECoAaQ4KMpaU0QiPKMesqT+LOIKCoLCCECwBABeCOCmIoDODmBACKCwAaBQDWKIBBOvOxOyr8B
SCoDUh2f+BACoCIAaBaoq00CoJNPKxLHACoDuAaC2BROxOeBADcBADEB7OsBADKBSC6CoCUAaCoB
Uh3PRQHPcBQDkBADtQTOyDTOwDrO5O9QDOmBfOuBxQUBAB+BJOyC3QhNyrYIKpaKyPqI0IW4KKJA
WPoIpOKgLOROUCmKbOdOhOlPUKearQJRoZSJ5PbPeBQQ4BSMiMfPiCkDKDGDKDSDsDLQQDJSIDkB
SBapABQDyDgDpOeDoDQDKBADmDKDmDmDSDfPqDuDTStP5P8gsQez8f+N8rJPDPGfLQJTdPdPhStS
wDkDCDcDIDeDaBACICKCmfVP2dwJdSjTJP+BaPYckeaMDTZPIoqbbPDPTUaWfR3PgIhR+BzSFSJS
NSRQRU2DSDMDTS2BBTnSyDLTvSSC4IyBrOfS6DODcDSDcDOJLSTSdD+BQDpU8DSDGDCDpP3P7P+h
8dwKVTSKxTXPFQGJNThR5TDStVFSuBADTS4DrVPVTOeDgDqDEBSN6BsBQDZVzT+BTUCBpSiBBTsD
IBADeDEDoDDVfVXVLSWDlVQVcDnUIksJsf84K+5UXPgDCDrTmDdVvV1V5XMDTSXX/TEDzXJTuBBW
tWxW1W5W9VZVdVhW/XDXGDNXAokBQDeBSh9QPXojE5ABBWHXzWMBRU6DMDzVfVjS1VMDkBPVWDTV
bV2DqgHQ6VUaqBanUL3X0BQThUtUxSLSPSSBADQDCDnSvSrWcDbS2DmDDWyLyBQDPSc6QBRV7TKY
EQgKnZHWLPHTkDfXPXTXXPqDCTnaZadYdalSeJFarY5PiDJZjanbXS2DpXoCLNwISQgI0fQMUh4p
gTCkwjMIGiKfoUgu6LuMQ2tCkQqWXIVcRDUo8QqKy2+Ue24KUv8UpcOPeo1cuUPcPMOKpc44wVWY
2ncfrSBc6M0faL/ciMfFetwNOBBcWPJIVdeXeJNcKOELvdqmuZ2tWQjd3dif4LOPxdUJ4UgTheGM
0I5BgfreE/EVXc+g7ecLeUgMfc2Qhd8SpcreDcNe1cSKokrNvQ9N2h5N7eCLG84hmSLOILCr0uSf
WBQCRaMDRQ6Q4PhRAh5RFIBewKwIoTKWOI1RXPgKzZ+BBSHaDU3QTSTVxVDTnY/Q+h4lSUrf0V2t
yJ4mELkKnRWBRYjZmgGBBfrghRDMENaImdkKngwWrg3WWDRWbSxZZXfZfQ6BaUKczXvTUIbWNRwX
LUfUYV1g1TiBRYZaeBnYeDHSzZjYlViDXUBKrXGDpa/XRXVVfhdXpIycna3hzTbh7WTPhhhSTZfb
LS5bPahbTapP2BhbdbhbUBvaqDnbpV9PIhmrcLMeOKxi1R4IFgLgPU1aHilbFOfSLSaf+TBVtVxY
DS2BZgKDYDeDHYwPJOoDFY2OlkgDwBABNYoblUGJbiLkVjjRoTKKJizZ5VKDHkHapSlYFjFabafW
3jNblbbYTXNg6DpZpSwDNSaOpiLTzVJZbXooqOcIpZyIGV7RVa6BQMXj3UzaFQQDHTyDgDCgHOeD
RWhl+IiQblFXxa5R5aXjHlbajbjjbjRjVlfnFjer9TFhbgdk+o5hvWJjxg5XdjBOfXKBBSXV4DkD
bVfVDU9Zsi4/FlHWNTlaVbNm/nLbZjTWfOeDtkfiKDDW6DJY+qlJtfsPYKJoEBQODmVgRaGDqDdk
Zkdl1OpaTSxpBobkjkmlgBQDxXpWGPYJ5oDmPmdX/bFZVhcBBTrTvl5T5T9iZXAORXHhZXoePAFZ
Fm1jxPhmpWqDlSPpPV3Sxm7lZbRptp9YqDzbrbuLyKmfQIJfwfWT6I5DGgQLgmiL0LaRuN6K6vZr
MUMVYTAVAiSWyO/rejkRCwLOGbSv5rsO/rSIWjNr2K40ynQtPsBeGi4iprtRSK4nzr+blCNsZsIZ
6cbsZrBrOK42bIFrNWDsDmuaQDQgtrsm+JYPehqgdtCugI+eukdrMYm15BLr0eOZ86CMYsxtZtle
QlJtArGzNtwJ4hWcyWyzMOww8hWO8lOJZuHdK1JuOhehSKJt+4eJYhvuftBui9eNTuVuMIY+Cjzu
yQMcruu41uWj01uPgu3uNC69EugtPvQzYj4a3uK0zvcPIvZuMRC7cSlvqvmnK7AJJvZrSVqzkuCK
GkgJ7CoBADzurwKw0J0ILvjuYtgP9weSsIqSWmuT7t3wqw3t/wyu+XLupsq2dw8Sht/tjH4KRt8g
sO0rnHbDwsYJ1HPK+6ojNxgcKeGTtE8UO2bZ2LOilvFuAdwIay2Y9rWbkWRyG0MkIRsIGOVyRGIL
ktWUZx84/ygMEVyU3xzyqjpDcZCT6ns84mEUPyoQ5y8jVBfyzzJtRtmP1uoDNQFDjcAiIfkfpsrs
3x7s7rLrDrQQfrXslrdrzsbrkK5rpyUbHHBrwU5r0jFs5rVr/0XzvrJsJ0ePhsP0drvf+zRriVGO
/shtBz9sXcFr/z1sv0rzrrFsFs9tBzShBtJMBtOhBtV1EP7tdKn1ltbtHtpyVti15t6o9wxuCJZ1
7w52AI/uT19uNwp2Kulu9uYhCNZxBwJDH2dZ3uhwW1vux2Pv3u52xwePozMp7vFva2jvNxo0yz28
7vXxVvkkRvh3UJUJ6OVuXvvwMJJuXu33osxuM2+8kTAu32j35vzwRwVDHwjwd3d2T4L2zwhwt19u
AVGmd4Z2H4etVw/4bxN4pxJ081xIKKfxSUO/nxaPNxfx3xkXvx1xiUnywkJxrx4gQYXyoh8WLydy
KYQKn5nyVfR5sdjyST6TBy3ynr/59yudrsJ6EWMyly8cYs3zF0tzKoHNr0kqt1YsDuoDmgsWoMYR
+pAPSgd6wIYNaiqXcvYJf0Elc2Ev4XtruLL7OkJ7TFf7WL37QMDDH7CKH7H7mR162jAcKLTDHkoI
kip7cUeOY4/7TsUVX8J7arGRZ8SXKpBf3BYip698hmJ1SPKI5vA2rEogd744MYuPIjN7J7ibWIUj
SPLbwj180e+tP9F9SLGbwhXSAPodh9f499kc0iQo79iUK2N9zuUUOf6JuloNL9ij5wD+HxB6xUc4
CsX18T6rmXksj9+TgK+dhre4/+A8utwUcjN+yUl+YTLDB+y+WlMqgpV6umN/IlSrL+e+QM0dOvZ+
erOLX/gkJ+frb/e1r+7+MQij/AiBAIAeQaMxmORcMByNhAMRiMhcMhsORAbIGMxqLhvBYXDYfEYn
FYvGYlDIuNBrH4IOIeMJPJBdJpQM5UMpZGxpBxkMZQNBhD51DJuMJzO57Q4bPYjJ4pBBuLhmNBlC
5yLhiOKjBIuMRqN6kM4xNaxVK3UhtGBpOjHILFXBiM57DZPTBcOIzCxnDhwNhwIKeMYeMhpdrxeh
BaafN63gbbg73T6aMpHbqoMriNMfI4hZrRA8tD8xXhsM4VT4uMBtbKmMBpgafDhiMBnUqRZ8LnNd
CIXqhcNRzOooZhVFYNdKjDeHVhAbeFcxvxckNqrfJ5L8Jbb9OdZZ5Xihn1xjgcN2hz3O92YcNdFd
qR0dbu/TxrnyPD5/fkKoNNH4sUMpUNcq67VKk/qTvCnr8L2hsBr4grmOK+zvtHBjiKk46orSNDbK
o3DXsQ3rkwy16RtgpzpKK77cq8yjsxMxTdBqwkCp9FqyhwmqlpklaWtMucbIqmaatei6LKjG6Qo1
IKnBrIi1JE3L+oYmKDIQhTXye3zlym3KDBqoSYrKGwYLYhDdy7IoXPHHUtspBaLrpKkxhsGzWIsu
YbTTM7QtqsM3I2nobssmM2hvKiGIOriCLKGYbpHQqaMa0QXTAtlGhgvbDUgjLi0aq8GSyhkAL2gS
CSkhKNociCJTNJqGVOj1VSOrSXqVH0co2ktZpTWqgJxK6nxMm1eKInzZUiHNcUUpyoKkvyq04rKx
oarwbrBOitNQss/s2sNrPUya42QujYsXOrGu0GTAMFck9NW3c/3SvNysvbq4OleSG2w2jw3sGTQP
S0iDtPZaDtW6Tb3EmlI3zEENxdDyKDmBoYBAnq8tjil0YkNeIq+vY7hABrvou/yRhux6NOU76mq1
cVpzIkYaRTF6Fhs1y8hAgUII6tk5UjOyFholTYQROKMIlnGgJ8luiOhcUuWTmbShikclTOHOdocG
DcLSrS/NUkeiZhKgaIM16fhu70EacGM8hjkqHo1renKehe3NM4qTIw9+65pn+RN5umTIktIxODiX
DYmEGNO+1zx7psi6Q/xaqcbZqnbbn6boyn4cJuHAasUzq883zvPtqrSehzDyq9IxT0N2/iFqtyy2
ddJUEUWqnIbir3bbosqWdp1HVIz1+fqb0W6d5C2QXZzXk+LyWpMVQaD2gqHJ+nx6ucGBohCoBsvo
1w+g1LkKv5Ii4chwvYqOVw+JJ1jQUCmFIqDUBoi+/9/EY0t6hseK8XkwITWPuVUGRJc6NF0AyKaV
gEALSvA5gYCAOQZXuvde+C8IxryFggCoGZkCdSuOHVOyV2JKinkKXOUE2j7WIuIfg4l7oWAQAvCO
FMwIZw5ggCKFhjbWQYE6CoWkFpPTVPrg8HcBoWwUBDDKHIFILTpgyBQHQNIZg0hjDCHQMoIArApd
xFQMsUS3goDkHMNIbw3ApC6FQJT+H9Qwf5DOGsNzYw6h5D6AxHlzkONCYGBhTiLQPgiRCCkFghQY
hCXmEbiISlsByUV2BOThg1iE+6OT8Y6Q2hwCCPEPYftZKjEMBsRSDtZiFEqJgU4nxRO+bsFAaQwh
sBAE4OobQxStjbG9/ML39saCFDSTkd4dygj3AgqpLwbknkDA6CCZ4JwVgu96RbAYSEPhMVUpoNXI
E5IuRGUcmHDyamDHWTsn4fSrDSGcN0Ww6wVBAEENgZw3xQBbK8GssQ6BoDbGyN0cJfRymBMKO0np
ix6dlAcEB2CHueoXA2Qcz4JFcmlImahfpGRykfCcjBOicl+S5OGgMMaBzmhzQeUMQYPFpYkFSVQK
AkhzDmHWJ4IAuAoDCHWfc9ZXE3BtPoPIXAUz+l5HGX8m6CzoZBQmPhrzJwqogSeiU0ZESKoxNaR0
2JIE9S5R5MKyTYwuf3OSgk56URMi+Xoh9OIyFUBQGwNIZA0h0DyCAIkWwyhzqJQCIyYXEE6YzUgK
cxI81LIdQomj6T0zNojIWilVaLwio1Vp2JBj8QIRGyuD04q/wynLJyk9ha+pdlJKaIEqYlvzDqGI
NQZQxh0psCgN4KS2kvBQHcN0T6hV7l64aQTFiqJyjnZ+pNKJj0LiCRhQdD5BVSsdIeab36ryNYlR
sqpZWYLifU1WsNnKSWCtDKC0cQqWRJtSFC1dtCZ1viyCAJYKUcA5BRGOZMVK6hJDcGYFJ9gZ2yra
DGM0UTKKRBQG2LcaY1y7AbBpBEHoQEzfVJl/1C2pMASoc0ubpaxRysDcSwdBrRUrAbE0IL9X729d
exZibbzA2BJ6TIEDHgGmAd+dAhYOSvFaIUcoiB11lNSxyzIihECHNjJHjgsUKjQm7Oi1I1yiqF5L
ksgiSJ8TakQd5k16hPC95DyllpZ9HmaEvdS3Qm5i8o4+OKn8qhd8rn4YA2bM+bshrsRq9POZUTAL
Sc43TMNC2YEYz6227Clc358MVlWJGddEY3yeVwwDnUA5AyToDGpP8kY6NqGKRRN2rEScO785ugD+
mmdjp64WG5x2erLeGH1ppUYiiZE6e2Fafh0v+CgF1e5TEyNpPeDwRIXykiYESdcUSDA3vmHPXGCs
UJKxUUVueHay2ElAYBLbMlzmzJ1jxnhGYVMITklciD6XG7bYTmIpsQTYyUUiufKO6y24UhRcItJE
N5btRGDjHBH98EH3mTSP1i07NVkBck6GSnM2L4Q2vN+2YVcNIVnXCFmC/cJ0AY9RdyOBwqM7AyzE
Ad+734/xsnO9TA5141MggzNM9NIMhAjcRtNsG721zMzenJqae43qFQ2eklYUyK2OzdI4O0ltBiCU
GsKVbEibK2e/LYq6513grXrnCdbACpsKlpadi7HBbsnZezZ/qFOgXuceZzCQMT9ct6R8X2TiTrcA
q2LdWTm2tD4FAP8TPgUi+JxD5EqaKZg7GjAN+49Gk1ePEWJO+5n6I4c0vgyDE0UmSpq1IsPau2GW
kFATQ5hn12/aUuL8cFcnuQ/YNqdjBn2QRjsde3w6g8CQd8rRF+E/bapEHEl7Bd5xG/T0nkPaMS8m
CBsZLzukbKaqWF3m+ld69B6LvuvfTwPOv6vr/ruw+wrz2SN7xy7ls9V1vEf0/Rv3+tlD1Mo9hfb9
fsr79vH9EdKjb4hkjX+pkIVjLDz4Ddw0KjzCoqAwLHgzJs6ZkAhdDIY/gpyCTCiyyBY+yZcAZoJn
xc7ZKSzChRKJDe8CkDbyyhrf0ECryb42ChcBwgrPQ3TSMFJbArS5Am8Fze7Wz5YmkGZgjIb3ZYzg
8HKQBtY3ZYy5EE7dsII3iZir52EGossJEDgpzRbGcI8Ibk5gEBT5p0rd0AsCLv8AcCQ8ABrnR774
iOT48KsDLCgt5QDVSzp+QJAMIOYNDvrFAwi3zfj2hxQEANQvhOqAZj4iwt64QtrM5D40TZLQ0QYq
gvgiIuaQcRInQOwgcRghIn4p8RRRQi6Bg/YlROJm4gaZabAwJ1JyxJYp4gxq0UQgw7oq5tQEEUcV
YEESMQAv4rkV4hovhtUQUSwnQgTTisaGQnQJUP8RjfhBEXcQsYjCJBIjBfkRY4cZUBzxAhUWUSZy
EZYiJQ8UCj5ATQQhRUUZMY0QgikMQBrCDtCv7CZbboK67gDop/awIFAKT6pc5SI/yqR471Z+cOaO
MYRiUPZ/wnSAEPoECAgBqbgubCImijDoixi5yaCx66LBaDaGKD6aq6ihayhngyzRJKUTsNi776Cp
Txi0qIxoB9il7WiKKKaKqK6LKvCLyMDyq+bXKM7BD+jozajvD6MgwlUYrG4ppOyBCqKQkh66Ciy6
SySa6BgrhogizwZzq5cj7o68Ena0aUaIkkal6VjWoxCWKWaWqW6XKKDZyoygT38ncg8nzSiZkoaq
ciEo8iyycpYEDJcBLG5Pxy8qSsik0nadSdidyeCeSekriWCuafkm8d7u6YctEnsZTfhyy5iZy56i
qq0pKrMuZngHDGEdhJQrkvUxSG7zkka8qly1KmKmamqm6nKncwin6uaoKocsknE0DD6pUtMxzP8h
soiico0yqjMpSExpZcR2Q0TxMX7pE0MvoFCtK9YMLXKuCuSuiuyvCvU2SvqRqwE2j4E25BBGpPCj
0tsyayEpE38y84JkRqxuglRts4yTM2k0SU60krE+K1CVa1a1q162K2a2oGi263IOS3c6zFYgi4Bt
bu05E2qlE7h3xHjPU8MosyiyM8q6sjI87GxtooJqUd091BE+C07ESlql69AMS9StauAMa9y+DzEm
a+oFC+6/K/cVS/yUzACezAan7AyKyNUxDFZitHpjCGTF50sgSAUghj7/8nZlpzhpQlRP4vY5Rs5h
I4rgomQ2MRgiIxQ6Av8XgBtKJqRr7IrGzDBStLJ5Q2IgTDBtpcTJZmAk54hfhpTgYvbNhF9LJZjN
wtJ4hv5tYryFIEDDDjBtZIwrh4hlJmdJpoA2tN8RytUoNP51AglQ8eoiVJQmBtdRBS0MJwrDiGUR
htdKbZLeA5VTxvhto65yBlpmBsw84/1P4vx1LC9VhAlLp3lC7DEe1P5zoyBulU9QlXRr9UJ5bNgq
xr89YsdPVC5oh9dOdV725GkD1LpAz5ZtdZ4vdUlKdY0phslUsRg5p5ccjBiDsitPtDRw6FlaxLY6
qtTbFDbVZ+QIbEr0i3tTj/YhsgMPlIsgr5IyzfSnzN03Ut03qaiDSDiISEC6cuSEw/x6q5EhYiUz
9Dsna00ky8zWbqElaKyLCLSLkmCMMmdGiMyNFHdASo9JCpVfYuomhAxZVgE8UiNhE4ArhF5M7Nxq
UoBv9iEqkkU+Mq70s+lip+bqCfEryWiWyXCXSf9edkrasndlC7Qso/jdtB83lCM8irFCkuZz4zzT
B3ldsNtnSs5+adadoOid6LswSnie8rswyftkks1kylFpzRz21qS5s3aqll8y1rFhQkpE4qsVT304
9sC0Vn6UlEM0ymSmgOS2M1YNFtKV81yulANpMspw9BD4FuSbVmiQFqdvEuFmE81mQx5IBzwsVwND
lwaUCtAFNdatlkE6E186aLk6tyiUM7C4dplk6ywuoqpaRglltCE8cuNmIEFmdNR2J1DG1nMkKlEq
zETpk+q1S1i1y2Cm8/Yr0/q3C3U2N2q31AjFdA13EnV3SZRlhLah14Fql4V0FvdmTHLKDQhHl09d
11KH00bYdES9NFtE9FK+NFi9dF6/S/lGaMtGyb7ArA9kd7teks6pQhgpEREzQjAsY0tKwsy6CEFg
YIzBsitqFIBiSbZRhiibJzgqjUdnLrrEceVeSozudH9A5jYiwwNIi4UgpMDDNVYl7h1Ubi9RJtZK
UDY3gjBmZzrfkT1LSxJmYso40uhrB1Q05yYqIgTMZtpr5lUFDJYwFKZRLUxnhaEzKlQtLKT27eQw
LMblxmaywmrJazRtrIrh2MRFLH7DD8cuh1B6Yh2OuG5z2HIs4hRwdTao+IWH555k8g1bZkjT1VuG
5mAth6iFeJqU7NeD0MDKRgN+OSEzJvWRQk+TTC9PpwR8BzpvSjBNeS2RyrhmTMaURumVOP58FaWV
DmwhWQYj1UwuZNeWpkmUDTaRVcj4r5BgYveIQ0J29V8vK70qd+7x2FhkAEEYQnUf5gbGL5FI2UQl
8ax2TLhD9Kj3p2LHIwitRRRza7AoatRVjU5vNTOKDHAkeCQhIqOKBRU7t7ClWKA2E4YhwhOUJohF
+fMKGeJkUToqov1SJpeS73pMmdaBrH+hI6Epj5tSx2QlmTsTibh2OPJueMTzBQByo1dbQ9wlp2Qv
IiVbsDZyufdRWEc4d7ByERj3Lw2CeksnuhqkCQeMR45zeO4nVTxmwqpAzUdK8Zun7d9TJlpaZKmh
KIOMzysCGKsEZlpYw4s7ws+UIKZjb+5Ek7J/uZ5xGaQ2D/pj9KMTWjA9w2NKBZjeByo9DLtaJM95
BJI2IilKKSOdxrAnVNKvxyo0wwNNGu4th2Q8dQg1zwt3qhuKVLovxmAxWCQ/BJdL2i6Axy+uZrp8
qhJ2GsebKP2I0SNKIs+xg85m2sZd2tdSMSLTjDGRub4lbHdLo87t2CRP4rmygpxLp1ZQ2uWxK4Ox
h3lSOubIt+GCQmjicMLxSGVKKS2qYoIoetA92dzVDlNWibDKg25WbNhmjRIvyZetrDE7tfxK+OkW
+wz3u6O5G8WEooRK6EEUA1SSFVlJ9LpROHy7aPoj56hzzfQoui56jU1lTMgqOzp35v+/xse3MbUh
hrMetNxzOjq7ZvlNBFOWzJClWuY0vBu94j6EAotAaDqwNYdaY3p85D+9m+dVm8vCLI4r3Cm6Qlg4
qCS4O4nD7TG7Q3Ece1xHmwCny4VKAvB1WEp9W7ji+qZIUW+2g9GpLT0KO7uvWEpOO6MX0RXDeraH
42LGUUAhIvfAkCFKCb9lnBJmUUAlK5CvovezuCsjhWQhVYbH8UYwLNgmTTE9ZUtPKCNDRqQsp1Ov
CALRJRLUZ4hRYlohOw9RTM5mXO4qjeZ4h1LKgkNDWzvPbG5IRNfP52BqQkpAJ4hMDRJIWb3OhZPQ
NvtN1PuoZY250WO6S7Sb5PPP5I5qx4rNhMKSCFD5dPIm+z7G5sg2nEkJJAxLvK7tfBJsdb+Z2aEP
TFZALGVmx6qzCnzUZlHVxYzfQktf/BI8cFkTl9HBIvTg7dZLre/L5KG4Yv7yhM8JPVXQLlomqxJt
42JrcUYtsJKnw/DG89bGAmh3hykUZfjkK5QzdL5M5E/e4+Kryrg6MHByzixt8GUIVTMhTJnZijqr
w27SAljNrfWPMZvdZfndrGZEY1fc2CaryjEFHg4oTfWxXgJEZReUO/wmUFhFPdS5O7bjhvLiJxkJ
PHp5fgSBnLJEfnlhsgfhxz7g55Tg+zZ5eq/DbF/DtIOrsf3Y49LGXgRzjiJzLCLHhEdLHhZGpJfg
Qy0FiP2yfjvW2b3g+sng40/iAu5UPsY3eI3jXcI3Uu3dZz8b3tprPkA5u4ngVlI3R9TcnrPYDT0C
HqfAfvw9HU/gR9XqrDK5HPfxhRfMu4vdZrKzAkornrArNRPcSIPwCAJd3cQpjf3lThgkM9LIfivy
sIiZQj8X11HkrPvcQ/gk/rDM/uIx52H1BNshiV8Q30ZlRUqhnk30ZITUfcTfhWfg59bg7UWtv2H5
ihpWaEEEQ6CZFXQqPrDzDPRhBoHvZMYqCZkehJXa7v/7aw5mUSJR0LsFP8/5yr4qyj0enwir47rm
RijPogXdbrDCkTJd31AG4gAuGwxHIgGQxGguHAyGQgNgNMwNGAuhsTGYgGIgGAgNYNGQwG4uGgwi
8HGYuHI3i5tj0ggUNg8JHAxHEOlo1hQ0jMHnAyG40m0fnA2GVAmMii8Pj8hkclGMnlNJBpim4uGY
3gsfG0oGU1llCkQ2ksuGQ1htKGEJgkwlw1G42oNpFwxGE1pcUs1xnFXrIwrY5rs2qkTjMThuFjkS
F0kEB3EEtHAuGtGhguG41uFfusUhEGysLo0uHM7ys+hp2lshG1+zwxy1spmdhmuGw20N/Gslj9hE
BjltbGmjg0EvA1g1+kQxmE0gQzuFaqw2G/DyOTuG+6A3wMHyNX6fQt3DkI5HEX1HQnXLkI1HF9rd
O1Q2u3IGNv8UCGnG7AwnGj776oErDjpw9rjIOkIcMY87+IU7T7sA77kBmGKduIG4cNu/Cst2Gocv
036UBw56DpE/jjtU+rPBkgTauO6rKRWy7rqmiSNRsjaOhmGAcrCuCaNclSLpwxitp+EA5DKiAGiE
KgGq2higI2jb1oLHUeJU4yaRWhCaiolkpRsjKOo2KjfBQKQUioNQGrU4MbhBIcfBmhIaJm46tvK6
cvSWLAQBeI4pqAM45hAIosAaLYUCGPI4DQMo5BSFriBqFA6DKFKnpEFA8DoFIuioJQGheIy6IwEA
qIjNqCykhSFzgxa4BmGUeNGuAcx5CaGz3RIiDKMdIBa5yBBRRlO0/UNVTfOKDBok4b2ejCywbPSW
BQKYyjYNiMBgGE0zWjdJVOIgGhQOY0DDJFCDeM1vAaKgVXIIIhCGIl23fRAUCSNwyDqOY6WAhFhj
SMo5i5WQY09UF3XgFAlDeNA3BAKY2jSOg0Xa5SFLTKqUXFclr2zbduzVGtwipcdy3PdIQXXe2GXl
emXXxfV+X9gCEhsFGB4Lg+E1De+G4fiOJ4ri+SVGmqM1QBuMvJC4QWc42T3INaMhBq+sayxt23Bp
VxhaiYYLooEygbsDFroi4qDvfGsUIEGIjEHurBBS9j4XGuyzJtgUDkEA7b/rI06wOuZBQF+rhxwA
QB+Emsi3ri5v9V857JcdE0XRtH0jSdK0vTIaU3Y2FUlFYchm8qNLnj1EigNgwjSN1LUwk/Q05nwG
iLJoogaOOmBBwemJOmtnu6mk4QwigQBay7aKBJHhIUEHiqt46WCvuEaqxFbWIGhvmMBI8k+wN0ao
smqJhzKLEoYnCjMxAOkw6ua4UlXCG+gs302hETFhoZkiC8EmKiCMj5U5EWMg4fQmFFcCiDI6K4sw
1yHkupfIEqZViczEtnW42JU5vmwlFV03wIIdAQMWDK+IMYZQ0h2UewZCi7XdI1DOA0zCKwZqyBAW
IuaGGoIEJqsGID4gGq5K4d8nRKD2AgJYGaASTYEwLI3FFOB8kAggBoSErpcE9kZhqmRMxT4ZO7Aa
QEANZW5kc3RyZWFtDWVuZG9iag02MiAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dCBdDS9G
b250IDw8DS9GMiA1IDAgUg0vRjYgNyAwIFINL0Y4IDggMCBSDS9GMTAgOSAwIFINL0YxOCAyNyAw
IFINL0YyNCAzNiAwIFINPj4NL0V4dEdTdGF0ZSA8PA0vR1MyIDEzIDAgUg0vR1MzIDE0IDAgUg0v
R1M0IDE1IDAgUg0+Pg0+Pg1lbmRvYmoNNjMgMCBvYmoNPDwNL1R5cGUgL1hPYmplY3QNL1N1YnR5
cGUgL0ltYWdlDS9OYW1lIC9JbTUNL1dpZHRoIDI0OQ0vSGVpZ2h0IDE1NQ0vQml0c1BlckNvbXBv
bmVudCA4DS9Db2xvclNwYWNlIC9EZXZpY2VSR0INL0xlbmd0aCAxMzI0MQ0vRmlsdGVyIC9EQ1RE
ZWNvZGUNPj4Nc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAgGBgYGBggGBggMCAcIDA4K
CAgKDhANDQ4NDRARDA4NDQ4MEQ8SExQTEg8YGBoaGBgjIiIiIycnJycnJycnJycBCQgICQoJCwkJ
Cw4LDQsOEQ4ODg4REw0NDg0NExgRDw8PDxEYFhcUFBQXFhoaGBgaGiEhICEhJycnJycnJycnJ//A
ABEIAJsA+QMBIgACEQEDEQH/xAGiAAAABwEBAQEBAAAAAAAAAAAEBQMCBgEABwgJCgsBAAICAwEB
AQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAgEDAwIEAgYHAwQCBgJzAQIDEQQABSESMUFRBhNhInGB
FDKRoQcVsUIjwVLR4TMWYvAkcoLxJUM0U5KismNzwjVEJ5OjszYXVGR0w9LiCCaDCQoYGYSURUak
tFbTVSga8uPzxNTk9GV1hZWltcXV5fVmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9zhIWGh4iJiouMjY
6PgpOUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6EQACAgECAwUFBAUGBAgDA20BAAIRAwQhEjFB
BVETYSIGcYGRMqGx8BTB0eEjQhVSYnLxMyQ0Q4IWklMlomOywgdz0jXiRIMXVJMICQoYGSY2RRon
ZHRVN/Kjs8MoKdPj84SUpLTE1OT0ZXWFlaW1xdXl9UZWZnaGlqa2xtbm9kdXZ3eHl6e3x9fn9zhI
WGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5KjpKWmp6ipqqusra6vr/3QAEABD/2gAMAwEAAhEDEQA/
AOu3NwpLXFwVRVqQTQBR4YCDXF6TxBgtuzdJH+X8o/H5ZooJLpluLxaU3ig7L7uO7fqwbmJIkm3I
FQ2G5+wLIoo4ECRKFUeHf54je39rp0DXN3II416k/qHicDazrVno1sZ7l/iO0cYpyY+AGcl1vXL3
WbkzztSNa+lCCeKiv6/fK5Tr3uXo9DPUS4pXGHWXU+Qesad5h0rVdrSdWfujbN9xphnUZwa3S6eV
TbK7uD8PphiR7/Dku0u885RtGskVzLAOzgK1PHlID+ORjOXXf3ORqey4w3x5Ygd0zR+b0ssAKk0x
MXEb19Or9qqNvv6YWCG5QBoZ/Xk6hZlDb0/mTjxxQahOnEXcP1dWG8320B9ztx+ZybrOA/wkH3c0
Y3qzKUaNUU7EP8W3uBt+OAHJ08qJZi1qxpsd0qfE1PH9X6hpaE7s5k7hV328aLmZQyEJEtH6h9ga
+IFcbRE1sdweYdyicAqhetCCR/zVga7EyKLqOMI8HxUBqWT9taAeH44lbu1tN9SlmIUAvCQOqV3Q
1/l/VgqitX4Gf3Yn8ORwck/TLvH3gqgnUoHaZaHdeI7H78aGWlQ0knLoaU/guArJmhElp8EXot8P
LccH+JaUp0+z9GCmkA/3YWNaUUCn07GmKJCiR+N2yNwfSY/Nh2+nGhaqAYUHzNafTTGmtKhXavdm
3+gE9MawAqSiKPEmv0jbriiuq88AN0jUe+/37DKJj7+lSnXvjOdAeLR1NNlWtf8AWyi+9eRJp1CH
fFNBsmNQKenUdaGnX5DfK5HegWp7BzlcyOP2uh6p098aGJ7NXqPg69q4FXVkoN3360ZTX78BS6kI
pjC6/EO/Gm9B4N74JJB7Kad/TIOFOoRlZhLQEHrQHanWtfHbIZJSjG4ncFsxRjKVS7u9MY9dCOFB
Ye1Qa/8ABYKh8xAtxePbx6fd1rkXLUFPvAFd9t/xxyEoxkG3Snb8MhHUZr5tktPjr3suk1+2Q8eL
eBO1K4Ptb2G6j9SM9NmB6g++QUOQfltWlP1bYLs7l4hII24Lxr1oO4r4Zdj1OQz9R2PRqnhiI7c2
Sy63aRSFN2oSCR0qMc+tWKxiTnWvYDfbIczmngR+A/zBOJ+sWVkfbjUruKj9Xjl4zT72yOmxy5E+
bL18x6eW3JAPQ7b/AEA4p+n9OqAJK16ZAZGfYGvc7EdACT09sdGzlwCSx6UHfqKDbuprh8aTadFj
52fm9Ps7pX4zR14kkEHuK0w3qMj2nxmGzhib7SovL503/HD/AC7iPDfWnX8MeOul/Y//0OvEjCDz
D5ns9EjK19W6YfBADuK/tN4DFNZvb6K0mFinO5RC5VeijtXoTWmwzj880tzK0s7mSRzVmY1OYOSV
curtuz9EMxM8h9Mf4ep/UE4htdX823zyklyf7yVqiOMdht+oZJX8ueXfLli19rL/AFhoxU8tgT2V
EB338cP/AC7YwW2jWqxEBXRZGK7FmYciScgn5nagGuLXT4WBhVWlkC7gufhG47jfJ6bCMk4g73uW
Gu7RygShh/dwh6QI7Hu3Xf8AKxHtl52OjiOxB4rJ0Hyqq8a5OtF1ey1jT4dRRiRKK+mdyrKSCKD5
ZEDFp9n5XsrDWGhhs5lQqVLszP8A3hb4Fr1wFrNzZ6R5dhtNMuvq8F0fViMQf1JFPXdqEA5lTx45
1GEDEmVA7kEB1tzBJnkEjV0TvZelC9hdhFHIit/KSOXy4jHSmAKRO/Og+Jf7B2zz/ecrVbd4o7m3
ncep6kz/AGh2eMAAgfSclnnS61hLHTLcM5tDADcSRkj1JQBy5lfwwHRVKAE/qvmO5j4xqRMeVPQ0
uEtmZ7JlNr/u2FSG4End0APQdxkf1Hzq9pr0eixwi6V2jT1efH+9pX4VHYN45C/KVxph1mBVe5tn
bYR81dJG/kf4V2b5YHitY9b813EaytbwCSV/VU/EqRA0I+4AZOOljGcxOyIwvcVv8FlmM4x/ncVb
dR5vW55hLB6loqerbtzUBgTUDdTxr9oEjI5rXnyCyuFsbCNr+5IHL0zxVSRsq0BYnIb5Nkmi1O+u
IS0kNvbSyUY7GhHHkPHF/IFvHNrU9xeH4ooiy9CeTkVPftj+WhAzlP1iABrlZK+NKUYxHpJJ38mQ
6B5yOo6wlrd2otJ3VkJJJ+JfiHIEAg9cmslyi1Mk21K0QfrrXIQreU5tXa/spC1/FKGkZi/AUYRs
24pTfxyM6reW+pX91MLq71FUVnAhX040UV3+Iv8ACo9sgdPHJP0xljAiLBHXyT4kowBJE9yBR6Dv
euepHIvKnJadXbt4jrjTPFQkSRqOnw70+Wcs8o39zBp+sTvITDBb1RGJIEhDUK18aYX+XbC81h5I
vrckcSMrvEOTF6VPiFFB44DowDPimAIEb13pjllLhEYWZAn5PYZLgRgs0jb0oAAtf+CyKSecJT5j
Gix2/JfUWIzGSh6Bm+EDtvkNe7k8xaxO2oXbQWUCs6jl9lEoAoH8xwv0meRNVF3byMWj5MJGFWof
hFa133ycNJGMZmZ4iIXXIRJ5bpicmWeOMPSJz4QT1rm9tLA0rT2+M7fLKLgChKgdftnIjp0d/fFZ
ru4nMTfZjRiC1D/k1oP8/cmt/qdtpkI9SzUs2yKSKmniSK/ScwjCjXP3OcdOBLgEhOXKo0mj3Nuh
IaZASO8lNsAXWpQKwRXV67151FfAZD77U7q+YNIgRRukcewHh236jEhYXNFndOMLn4TVakfw+nDL
FUbMq+1yo6KEQDknXl5soa4jk+yAR4ddxQ/xxNTX4qEAbkU8PpwoieytEJYKGX9piSffqBiUmprX
/Ro9+lSSPwBzHGKUjQFjvqmYwAn0cXvIZB4U3p3GCLdv7wd+DfP6em2RZNVvgQPUDAn9ta9f9Xfp
88NrHU5yxWe1YA/CXU0FDXtJ2+nLBglEg9zVm0s4x5xPXnR+1Gudzua79Ov7W2IyV/ZOwr06VJag
HvvlyzLHQSfC/YkbfMNuPfrjQf2qEk7KB/HJW0cMo8xXcuRkQEvGGI3O9N9z2+7BlpqFtazBvQWq
GgqTQUJ/5pwuag+zXkNhsOp7DG0D/aqA1VqN+tR99MBlXJmJggidke96NZ3SXNuk8f2XHQ7keIyQ
5B/L8qw2otnJElWYr/rGtBk3y7iPh31cLhh4tX6b5+Vv/9HqMNmI4yJG5MxLSMNixPUnOZecdEXT
b361arS0uDWo6K/7S/T1zqcnBEaSdhwUEmuwA98KL3Tf07byJcIVhdSIEbbie0lOvL+GYUhYLsNF
qJYcviE+k7S8/wCxgWieZmtEjsdRLvYpsqx7MAT0Y7Er9OSfXfLdl5usbee1b0Cik281Ph4tSq8P
owi03yZetqJj1FeFtE1SQamQA9Foa0OT4zW1pEkBYQqq0SCPduI22C1ODDLJCXEDVcm7tL8vOQGH
1SlvLh3jv+lgVl+W0oni/S98bmCGgW3j5Hb+WrH4R8sMvM/kdtaa3ntpktRBGIREwJXip2oRkkOr
woo9GJqeJKL9JDMDjBrWmjeeSkg7MRQe44kqPvzI/M5jIT4uXLbv8nW+AKrh28j+Cwyb8vL+7vLe
4n1D6x6YQSNIpFeJqVWnamDde8n30l5+kNJvzHLSrWu5XoFPAdBUePfJlHd20w5idCp3CxsCaH5f
wxdQxBEa+mvYnr86YDqctg2NhXIVuxGOPKuZs7sD0HyT9WnOs3l2J7xwxhYKFUMwpy4+IwHY+Rrr
S4767M6yTNCyxy8SvDl9s0PX4cncYW1vWiVeazAyIfBwaSL7V2P34vMAY2EtOLAjgN9iOh98B1OX
ff6q6dByDPwoRlEgbDcfHmxLyv5RXQ0uxczrcm6CrRRT4QD9rrseWR6X8v5k1KePT7028AVWq9eX
GQuOFVPxU4Z0Ozb09PgdiI1ESFnNK/ZG7ZFL7zTFDPcrYgSTs/BJn+yAtF28d6nJRz5uKUgd5c9t
tm3HovEuEYWI8j3b96kvlHTtP019NSQm4vqJJdNsaL8fwr4VGR+TyrqWkWd3zv1gtZ1CFaUaUg/C
vE70NcmGiG7ltxfX0pa4uPijoOcnp9uIHwrXrthH5supfXS3eP0QqiQ1bm55Fl+I9K0Xxwxz5bI4
r4jZsXuHIhocUskcZF8N2Rt76YlBZ3MdpLaRyH/SCKoD9qhHHb3yc+WNIOk6dJFIDLLK3KRwSq0o
AFrt09zkf0tV/StsSoT95UO/TkBsd/cf59p44JCs8oFKnnJRR9z1/ADDmzTIMT/EbPvZajBixTgM
YoiNDfpfxeWX+ifV764ignrFUgN3NafB8Nflg/yzopfUPTmdRGV5MQOQIFGofnti+qR+lfXCs5cF
2ZXX7JDVNRv/AJX+fcRoM8VtqK+qRGkoKEheR33HX3WmTlmySxkXdhtjosWOAy44nijEmJsncjfa
2cssrKAkktAP2FRB/wAMK5BNQne8u5J2ckEkKXNaKKgbU+nJuPqhI+GtRu0r8Bv/AJP9mQa+t1t7
qeIEsqsShQ1BU1pvuOjU/wA98bFzKdEBxSJ50KsfNE6NZNdXWwDpEOZAUkE7cRsadP1ffJri+lgB
RkPqU3pwoAfYrhB5ekkW+khVwBIprzYqCVNR9k+5w0v45vUchAVddpIzzpUAfPan44Z7yo9GWYcW
fhnVCIIHJj97efXJuTigU0RaKPHtTEorYzSBYxQ9zt0/z/z8WcOOxBr4U/r/AJ/xHafCw5NHtuBu
ART5E4ZHhj6dnNNQh6dq5I62jFkeUcCS+DsDzFPA8v6YMl1iBI1VqtKdmjBNV77iQOMBTzGOMllA
alASAQa+BwpoGNTuaGpFa9CN6fP/AD704hKUiZmwHF/LxykyyX775o6TU7l/7oLCAa0UVBqe4+z+
GBxdzerzY0cGoACgH/Ygb/dmt7dpq8yaDYNUVPfauGK28SDkEAFPiag3p068vDBlzwgariLafCx3
EQB/He1FqlDxmhDAb1C7iv7RHyw0gniNHRRvsSo3H0YWNPFGQzMK9COp36d/4403SCpj5Bv2WFBV
ep2/hlF5ZnihGUfu+1xMmCM/pgY33cmR28n2WU+4ptnSKnxzk2n6lBIPTlIjkrsx2VvCm/wnOsf5
9sy/X4Z9PqobedOB+Vy+L4fCe+/6Pe//0ul/72TEytW2gNG2oHkHb/VX9fywb8b9PgX36n5YyGCK
1jRRuFFE/swNcyyzyfVI29Oo5SsOqp8/5j2+/MQt/wBRobAfiypXNyaSJakKkQJuLlui0FTQnqf1
Zzq/1y4u5JFSOYQ1IAWg5gdGkJarE5PtbHo6HdR2yUjWPj7kbVAr1r4nOaCSSlfQfffqv/NWUZpk
VEbX5034qINDYbKK3LRvLLLA6xkBqkLsANyd8EyyRxKrcORc0VVAqdq7Vp2GI1MsqQyRskagyMCR
uQaKDxJ27/RguaFJkMcg2Ph+BHyzHMtxd/NtQkNxLFLMxtn+JgyUKVHwKux5bbjJj5Z8wzz3A0/U
BLxI/cSSFSSRvwdlYk7dMiME0kkQb0SzKWRmBABZGMbGlfFcHWM00d5busNCsqEEsKVDA70yYyES
rv2O7GcQQbA5PRb4sHtZacVWULXueYaPb/gsQ1PULezj9FXH1uf93Avcs2y8utKeOB9WfV7i2RbW
KFZVcPzLkrUeHwjvkXg07VYNSF7fwG4cVYBXDfFQ05dNhmUAOZNUjDDGYiU5Vw3t1PcE71GdrLSX
kqHMCBIya+mrbKtB1cjxznhJI9ShU9wRUlT2+nb/AD+1MdbkE9jK0gd7kAFUZG2Fa8Y1pxAoOpyG
AcXLKN22YADao6/ry3HVF2GjMTCRBFmT0e2cLaosPG1g4ChT4pWWmx78dvHIz5ms3WSO+jRkhdRF
6kpLOzAlqtXfcdPfBWgaqhjWzuG+OOiWyoNj1FCSPtf7H+mHkltHcAxzW/rSPUFXNKA9z9r8foyP
0ndxuKWHKTLfv/pA/jzecoXR/UjJDqQQwrQUpsAAP8/oBnmj30Goweolt6s6fDIp4Kit2PU7Ht1w
tk8q2yXHpTTkMaGJIwD7AMW/j1+/B0Hl1NPLywXLi4YELEgBUg9A4ULXfvthnKJHPds1GXDkjXFu
OWxr3FQ8waXLfMk0SAXEVA6r9kIP5itemE8vl3U4OLFEJ6gRsCxrToNj92DbnzFrOnyGzuoY4yp+
yoI5Lv0I/hiuleaEeQWzxC3RyeDVDGtK0q1Ovatf1YRxgbAELH8xjh6RGURvzvZMbXUIlEVtqSpD
ecat9Ybqa7MgNR+OOlsdPu5llZBMj7Fo1CLyB+GjCn/EsR1nT4dUtyyKY7lByjlnPEnb7FD2bIbH
c3tnyjR3UjZlGy1B/lpTr/n4RjHiFg0e5hjxcdyxyMJXvHp8PJlr6IlhJ9etXCSwgssBPqFtvs12
P68YnmK3vERFZ0lJ+JCFUdP2TgvSdTe6s0kLJT7MiwJV1anUrvseu2RPWrNbS9dolIgmq8RanhU+
3UnDEWalzHJOKPiTMM28ojaXu5gpxKqTrxlUHhVQxJqKEdD22wHG0dnJ6UjVEn2HI7jahxmjXE8j
tb7yftBVqSFHwmm29P8APwx2s20wgjndW48uPJ+hDb+HtgMbPCerkj0y8MnYo10DqFYAqT8QK198
ATWjxfEoJi7kjdd9qnENOvm5pbSb1oI23JB/lySJamOynklQfYb4SrHYCvsN8oEZ48ldDzYyyeD5
3yHegYUMcKKQeVNwS3XfvuMTu5uICx05H7TCnTr7dcrTZ5byLiqkyJQOoDb7Deq4Lks5ZYJCwNWJ
2JNRx2HUZUIkZSZxJo2WPHGM/WRz3SegFAdqdB9OLwwSyj4R8JFeZ6f2461tHuZfRCkhTWQDw+jD
UwupChfi6UPf6KL+rMnNmlChAWfdybM2cR9IIs7oBNNloHMoDNQkCp+I9jv3H0+2dm4HOQvfrHRI
15OppQn4RTqB3p7bZ1/lk+Ofhcdb86pwDLU+IJeRrYfTYt//0+p3MyWsfKnqTN8Ma92J7e2Bl9Ox
iBunMk0p5FRUl3/yVG5xEymW7JhX1JI+SQBvs16PK58P2R9NMGwWiW1ZpCZbh9mlPX/VUdl9sxD3
N52Aj8/1JRr/ANfn0q4cqIYwtfRFGZhUfaYVA+ivzyAL9YP7CCg/mP8AzTnVrz0jBItyaRsCvEdT
Xanuc5rqGlazZTM1Y/QYkoxjbYdg1H2OYupidpbVystmEjcXvz3S0NIt2jSqqrIpjqCT8XVa1A67
4McKiFm2VRUn2GBDBe3LywSSRBQqlmVGr8Vdx8exFNsG3FuZYlRSOSkN8a8gafzCor45iyIsb++m
+0FZx3IjIAUBmeX4gaj1HaXiflypg22ju3uoUUpUyJTiDXqPfEFF+xdBJGCrBdo23+FW/n98OtF0
jUDILi5dNqGNfTI/2R+M5OFymDt39fmgna2TubzZFdGbYV4Gg/1fixEC4XkAY2bozGo37V675Qhf
eGOdvF5AFrX7uuV6L8SqTkINiaD6QNq/TmTOVUba4gnp9qi0lxUokHU/vZFcE1/2QWuBJ7exuhSa
14d2k4VJI/y1+WDR65Q0cCNfFeo96MMTZroRkyqjx9eIJUn5ih+7KTMg+n7ObID3pGfL9jM5ewnM
SKasCQ2/0/EPpxPUv0vBGz288scKj4vi5bgGrBwFJr/lYdylGq1zbHiPsCgY/QV3xP4WFYZedPsw
SfEQeu/7WMdVkFb8Q7pV97aMswQSeKuh3+9hDX1zLXlNJXuSzV2p8W7f5/iDzRvMCx0tr+QqpoBd
gkv/ALID9eL6hpVrOfUkQ2ty32OFOBPzGE1xpU8JKFDI3UKvxMAP2qdx/mffNx58eUVXCe79RcqO
TDlHBMcB/T5FmF3pVrq9uGikpF9tbliGJ+RO5H00yFX2m3Gmy0lXlEWPpTgEBgKGq1P+f44rYare
abIKH1IixJgfdK13PXY7dcmEGoadr0Bjlq8lP95aUIqOta9vHJ3KHmGNZdOd/wB5j7xzFpVoWuJc
BLK/pNKaLDJKw4keDDpX3pvl6/oUcge9sqyTCpnijHwkAduu48P9rCvWdDm0yUSK3KIiq8TUgDaj
dPl/nQmuha4ZI1sL5yvGiRFNix/kYgk18DgOx4ofJZR4f8I05uP8Uf2JHo2ptp10rGQrbyCk6LSt
P5t69P8APxySa5pa3lmLqBeJj/eIXarNUb8d9q/PCrzFo7Wcgv4I+EEv2krVg2xHTsf8+2DPLGoq
YhZScA6DlFLL/IOqj5VwyN1OPxTmqUY6rD0+ofr9zH9MuVtL2K4qeCkq4X4fhPX37j/PrKtXt4vq
U6D01DASIoJdg6/EBXbZsINasvql8zIS0E7GRGoVFergfZFN8kOj3Av9KW3diCgMLpGvxGg2qTXt
jM3wyRqKrHqI8tr/AEfJh1meF3ATUBXXlT4e9D/n/mJxO5FlcRzGjqjAl5d2HHY0HjkJnt5LWd4X
HF4iVJ7bV7fL/PxmjvzsxLHt60PFuCUFWQkcmOx3xyG6XWAXjI5Hl97EdJujZ3qSfsP8MlGP2TvW
q77df8ycm9uGFvGTXkVFd5BvTfscgMYJdQf2iBuabmnX8P8APp0ByscZYNsi1/vm7DwGDLzDDXxH
FAgby5/D+1AWr27XF0YyA4cK7FlNaKCf7weJOKXhkeFoYOrqSCAfs+3EsPbthHoF0fr8gZ6GYMSS
wG4PLqa++SGNUl5S1DNJ0JKHYdP5Tv1wEUd3Hzw8PLuboA7sZACkDuNiDv7Uztu+cht7JpbxklDG
OMmtQd9yQtdwP6Z2Oi+GX8QpzDmh40RfKEj8yDX2P//U6laWqWcfBPilahd/EgU96DFZpUt4zI+7
HYAdSewGKyMkMZdqBQKlj7eOQ7WPNJ02Y3Mun3M21IPg4xAfzFt92zHGOUjURZZmQAsskht3lk+s
XO7gnjToo8F2/HrgiUQrEfVAEYHxculPpyOeU/NE3mCK8ubqJLeOBgqqCSQKciWJw8RGvGE8v9wN
4oz38Hb38B/mIzgYkxkNxzTGQIBj1QY06C7kM0cCwRmgaTjSRwtaUB6Df54Iexs4lCLGK9q7np+O
DnZUUkmgGE891LO7+l8MK15S99jSiDx98o8PGf4I/INsSedlSlSxt2oI15seXACrE04/EBv0HXGN
LcvURRiMHctIasD2qq/1y4kSBS5FZHPckn2BJ32xs06wARg8pXqaUq3uQBkCRH6QPhs2i+qiILkg
xNPxAPxsqgVJ6gcuXj444oHDUkb0hsGqO30dMrncT8owojQD7Tbk+1FIofpxNYAwJlmkMSHoSFBp
/qgHbKJz8xf4+1kB3BcYCy/HM6jspoDUd+mJGKYEOZX5VoifD93THNbxgmVy5H7Cl22r9O5xrQqg
LFn5N0USN93XKSfI/o+TKvxbTfXEYfEkjH7IoVoPnv8AqxGUgkpNb85D1ZfiC++1G/DFPR4tRZGM
jDrWoH0Gu2UI7hGZI5uRP2mdakfSOOQsH+afmD9i0fP52ogVrHby+oSP3kcvh9O4+nA5jA+CIFGU
14MTWo/309etO2C5ELUR4QVQnlIhqfxofuxA/vFZFb1Yl3Mb/C30N1+/78lAkbg8vj9oQRshjp1l
qdISfQud6Xg2DnrRkP7Y7/ePYluNMvtLcSgExIaxXUZNKigrWn+f6zqZeakhiEXs3wuO45+3gwxG
116SKT6pq/7y2XZWoASK7eoo2ant882GnzGQo7kBtwZ8sTwg8cekTz+CppOvpcJ9S1AKjS7SXDCo
ao35V6fqwFrOh/VQbzT1Z7Woq3Wg9t9x4HFdU0aNrcanp/H0nNTAvxEL/k/Lw7Zej6ysfGz1AmS3
Pww13AJ6K3Tbw8MvvrH5ORH0/vtPy/jxnb7OiK0TUk1GN9PulV7hlKiWWp5oANvcivbCS9tm0i/H
1dy4U+pbSn7JC709+JO+KatYTabe84h6cZ+OGh2Wv7J+WG9+8Ws6It2x4TQglIkG4K/b/DG6NjkU
jhhOM4f3eagR3SKpqCDXNIWeMGS5QeoqqKKjKfiX8PnhX5ZuvSvHgZ2CTKPhTqWUbfeDi3lm74yy
2czssUlXjRO52BHwivfthbMjabqzgD0xFMHA2rxJDAbV7GmAdYohj2zac8vqj7j+1E+Y7Yw6l63E
oJ05DkeRqoKt44d2Ie60RI1DswRlU7KishIH8p2pXpgPzTF+6tblYyoDFebmpPIV8a/s4J8v/vdN
kAjMgV2G7UToG6fT4Y36Q15CTpcUusTXy2YtaxgXMSKP20HQkmrKBsKf5/jMtalaPS7gkvRk4E8V
Vfi+HvQ98ienKXv7YdR6i/3dN6NXY/Rkg80NxtI4ShHquN3epoB4bjrTCTZDPUDiz4Y/Fj1gZRew
rEWVmahJPZtmr4UH+fYTWeaO3tmdm+CNa0DITQDsKZG/LVtzuzOa/uV/ZXl8TmnhTpXBnmO4ZVS1
V2BaryAhAOI6U40PXele2MjZYamPi6iGMcgNz9qK0eRriBpuPxtI1SACAK/5JQ7Z1ffON+X2d7d4
EJVncmvwGgoKkVA37Z2Pj/n/AJnD0PvH6Wjwx+cEfM7eT//V6pNGbh1hcck+1L4Ur8K/ScEFFIoQ
CPA5UC/uzKdmk+I18Ow+7E7qb0YmYU5Giop2qzbKPvzHlztsCCFpbSXciQRKkakG4ZVA9RhuqEjr
TqcMTTEreIQQqleTdXc9WY7k/ScC6hcSJGIoaGWY8UPYeLf7EZTOe+xZxCjdztcyG3Q/uY9pX/mP
8i/xxBiGeifDHH2G29KfhlM6wqIozRvsjxr1qfHxwLdStVLSGgkkqS38qjqxyB2HnzbgKXzSOXb0
j8X8xGy1/Wx8MuOJYNgecr15MxqWPz8BlRxrGAtKIu++5LdSzHx8cSmuVjfkKvIwpGngNvirvQZj
Slz4T8Gyq3IXSTRwL6ZJ5NXddya9xTviJWechUpDElK93qOg/lAxRIRH+8ch55KAyHbt0UdgMZO6
QoqFvhOze9e1ANy2USlZ2AJ/HRNd/Lu/Qt+rCQ+rLIzgbgltj7gCgyjbxIpd0UsdgD+GUfWuGFG9
CMbhern79hlC1gI9Zx6lN4+VW+kV8crJrma8tvkmr6fP71rJaqCCE5t9pttvu7DKaK1ZvTjfjWhZ
lcjb/Ykb4ofq9uvKTgrMdq0AHgPoxN2sqBEZXJFWIAO3jtiL7yPO7C0PJsRuapFKfTXuaEH57A/j
jZVLqrzIGjToydfnTrja6eSFRkQDqVPE/Koy0AkZmhuPgU7CocGnzqfxw0edUR5fq6r5fpQzAyKZ
GJkEey02lQ7fKvywn1G25xFtuVKoVBopH01HuCdvlh7L64Ilnj5HorRGjDw29/pwJPHyQu3F3b7T
jbpTaQdQR40y7HMgiQ/HkwN3YsEb+aR6VqNzp0hc1dGqJYmHw06HhuPD/PbDDUrKCW2GoWJ9Wn+9
BptSuzH333/28B+isc5tphxiuKAuescn2Q59j0ODtHmktrybRbn4Un+CSu9DuNievMUGbASsXbl4
s3GDkArJj+uI/ij3qlm36X082jb3Mf7t5HPtyjavWoK0+/GeWZHE89ktAJ0qefYjrt8j0wLbRtY6
tJaBuMQLJyXaoFGWlPEqK4tGscWv0G1u0hrSoHFkJ9tt/wDPuk7NkgOHJEfTKPiR8q32Q2ncrXWk
iRqGOUxByKjcsg2B/wA/1qeZAo1MNG5flGC7tvUgkbf2f7T5fTfzEQF9OETJVSDuKA9P8/6Xr7Nd
6mkaoVICRKvf4jUVH+yxvf4Mgbz45d+KyjPMDq+mwuGMjclLSN9kHgTQUoPux2gsi6dMSrycXduO
/ADiu57H8cS8zzsEt4HARQrN6YpyFRxFSPHfFE52HlpQzBPWUgKtSSZN6kn27Y3s0cJOmhGvrybB
KtGRptShBBIBZmCEg7L/AK229P8APoM8zP8A6XDDwVAiFiCQWPLx/wCB98d5cg4tNduxhRQErtUl
qFh8/hGALphfak7RkFZH4oXJOwqq9T36423Gpaky6YofaU+0GD0tO9dlccyXqX4rxApXY9+uRy8u
PrdzLOAKMTRdzQU2HUdh/n2kGryxWmnJaxK78wsau2w4jrRdu22w74V6HZ/WblZSrNHFQsEG5alF
Feg/sw9aa8BAGXUy6k17k90WxNragsjCSX43BQVFRstX/hnU/wDPtnJ9cvvq8f1aIFZpOrM5biPl
03zqO+G/SfePuLiEZeMajqbl8AQPlu//1uxFfhoNsK7mRDfxwuQFhX1TU9WYlV+4VxfWbuSzsXki
IEhIVWO9Kkb0yBSzvMWkkYln6s1Kn5k0P40zD1OUQIiBZIv4OVp8ByDiJoXTOzeQUJ9RaDate+FZ
miluZLgsp4VjiFdtvtEfM/qyJSFlVqH7PswNa9Nzv9OMPKnKtV6Hr1+k5h8ZJcsaUfzvsZPzBJlq
OKAivYUO/wDTA8JIV7tlJlmpxHYL0QfjU+5OEcF00TBS5EbECRfFf2tv4/PBmp3jF/QU8VUAtTxN
Tvx9v15OU+LeqT4EuKvjfmmU9xFDCQz0IFSTuSO+3viUDxVMkkqeod2FRQHso8QMjhYMSK04703B
6+K40lamu3tVsgcYO3K+5tGn8z8mUfW4CzyMymhooqN6eAxkcTA+tMQ0rEhO4QHsB+s5Gqjao2pu
Kk79vtf0+nDbSriRmkilY0RaoTvTffc9vCuU5dPwQM40a5g93zRLDQu7pMpiI4wjfCo3dj2Hz8Ti
K+td0K1hgWnH+Zu/Q/Z/z6Y6Mmatw28daxDx7Bv6YIKqi0BoDuf45icVbCr+Y89i1Ve/RQiht6NM
0YJGwYgs1B7mpxzOsKHlxEjdF27+HjTFY7eS9dWRjHbqRVx9pienH298M4bO3tqyRoAB8JPUkfzE
nc5l4tPKYBkTEHp1a5TA2j80l5KwMaRsyndjwb+nfGSrbFx6kBCL1Jjb+mSF14IHNA5oaf5+2ZkD
II1FS3U5eNLAUeKX4+DHxD5MZpA3xRTGOleCE7/8C/8ADEpllWssi1ciiyRdR7Mu9R9+SloopRxZ
AUHUMKivhgA6bbszyR1hdSQOHTx+yar+GD8rz4ZX7/1p4+8fJh17bF0IqGLVKsN1Ip28Kfy/dgIz
Ge3ikWou7QhJ3HUgk+nIT1Jr1yU3unTxFndfUMmxdBsen2067eI3yKapby2jNNAPtKRKBuGWtWP/
AAVCMnjuJ4ZbWuOfh5Y5RyG0h/QPNM9SkinurC8VeEUyR8iQKVUjl91aYnHdwHXY3mkEaR05ByBX
hHx/E0xscwurGwPGqW83p8z3DlZAP+Fwt10RnU7qZd0ZiFKnau46im/tloPQuyxREvRf8MogjuvZ
NbG7tZNZuNTnkUQxFnTpXeqKPnTA1neW1zqj3rzLUSesIywrXkAq/QO+RpwVAjHIluoqRt4UxNla
vox1JO7ENWtNzT2+eWxxg9WcsfDZB5xEfdEc/myee8jvtSE13JHGrt/uxgoCL8+mPvr1b64S2tZP
WWMlRwPwklvhp1AHhkNmkI5IlebGhNdgf5fh/rhr5UuksbmZ5jQekWTueQ4n4e3Iq437ZYdPUCQd
xuXGOThmPTYiKxx/SyzUL7TtBsPqAmQahInxVO689mb29sC6C9sJH1GSRDHBVUd2CoGPUlvl+vOf
v613LJO55ySMHdmbclivfxrIAPbHm9JtTZrUopqHBA6ihpsCAR7b5aNHHY8RcU6iYjKAAJmbkWYX
+u2mo3vL6wj0Jjio3EUB677bnx/sw/j1DStEsBHLfRtJQt6UTAc3Piwqc5VDHQGSUsqrUChCnHO0
khIBKxitAd+vIcj1r8Q8cn+Thz4ju1z1MpiOIRAjDnz3pm0Nw2oyGSFvVMh6rVqGtafIV/z7d34N
/nXOSeUdLOn6XDcuoheVTI0snUK55UpXrv1Odg5D+bMXgjxGNmuMC/m5B1Y44+kUMchy2s19mz//
1+t6hareWrwMeJO6tStCOhyGXemLE5DToCvue39KZM9QuDa2csq9Qvw+Fe2QGSRnJJPxdeRO57g9
+2a/WmFxsequfk5uj46NGhf2oeeMxqsaPX3UkbDfpgeRmIPLfYjfelAfE4u9eQWo+HpRzTf5ZpYi
ByBHx1FS3zBpUe+2YQ73YA9+6EejPJQAcOQB9iHOK3gIuHUnqVr9IjJy4ojLIir3NB7ljx/W9MHe
YbQ298QBRZEQ0G1diP1qMtq4k9xH2p4hxxHUxP6Eno4YCtW+ElunUJSu/wDlY5BI5FG3JBUcj+1T
+uKhPiFKbbHenwjb9QymWjEcqDanxUPXwxB5Nl9FRLOMgfvVqRsBX2r261GGMdskISAHmbj7bDoI
13b7+VPpwoUlKbAVHc+G2/Tp1w20d/UMoc1ZAqqf8klv4iuQ1HEMZN7Dff7GrKJEc7HX3JpQKQnR
VGw/hlRxC9laEH9yg5THxB/Y+mm/tjXcJA0jkACrV60HUYYWNsYLeH1Nnl3l9y3Yn2oBmPpMPHMy
lyj9sujjZJUKHVExJxgMVaOfh99/H6MfQOgi8B8X0bfrx1AZ9j23+eZCo9RiO9R8v9sZtP7XHWD9
79oAU236E9zlRfDGXJ5E7D3p0GWAQPSNCWND9O5zD7fAdFNfn4Y+5KwBlX0x1JIPsDuf15qD1OK/
ZABI7Zl/vJGJ2FO3tjCaVcdXHT9WFWnYcg5GwJHz2wp1PR4buJ5EASZ9x4VpQAjt9GG0ikBVG4qK
n227ZT7tv+z37VwgA7Mqeb+nLpUo0y5VlgmnjkjfcAGpU0+da4hcTxmBIJkovJrg8aEkn4UH+fjk
91HT7TUrVoLpKgj4W7rToQc53rWnXWm3fpTv6ilR6MvSqioH0jGUK3c3s8njOI8hvE3uK/hQUlBz
TkS/Sp2Cj/bOBCeHNIt+XwszACo8D3GCKV2+kA9D17n9eJEK5bkTXrwVAVP4j9WTxl2U4bIX4UdS
nxuKFWp2BUin3YvpFsZLmRZZRAgglfmdq8VTjTwrtlFZUq6RhT8JDMDTZg9anuSBg3RtMe5mkeeR
Y4kQRl3IqGcL8JBPUIlcyDIcBvuddljUrutxvzPwCQ3Mm6xR/wB2tGAp+0QAev8AqjGwwU/fN1Q1
VT9I3r78B9OCJuMMjJ6YaRTT4h4cen/AbeIJxHg01AahRsPgLL8IA707ClaZlRNgOBOJFjl33zcp
iduTKVQUHwqOpB8O/wBOHuktotsy3Goh5NyVioAD3Nfi3rTwwjVYoSSWap248KbE0ps4NDiTM8jk
P+2S1D8PWvsBTf6AMkRfMlps/SAAO96Rd6y2ocDGxMBp6US9D2Hw7fjnaaN4ZxDyfpjxWi3EgJeR
2eAMP2CaeoR79R887pT3zUCUfGlj4thkjG/9M5hyY6iODYY5f6Y8O7//0Ov6hYm6ha1kYx1IJZeu
xr3woHle27zSfeKfqyW3dNq8On7Va/8AC4F+D/I/4fMfL+X4h4tXW19zfi8bh/d3V9K5sabypbE1
WeRflQd/lix8tWRh9IF61H7yort+GH/wf5H/AA+b4P8AI/4fIx/K71wsz+a2vi+xj9l5ZsrSVJiz
SOh5JypQHx2Ar9OCdT0e11JU9UUdK8WHWhG43w2+D/I/4fN8H+R/w+SHg8EuGuHqxP5jxBfFxdGM
x+XtPtwWk5SbU+I/0GFMmh2skjmOR1UGgAI6Cntk0m9Km/pdD19T8cLU+r1f/eX7R/3/AF6nMHML
H7uUAOnP9TlYznvcTJ+FMYk0e1jid/ioN67VNB7DKttOjs4yVZmZlCmtKVJ37V/HJFN9X9B6/Vab
9frFOvemZ/q9U/3k6/8AF/vmOYZOE8WQV1J4vh0bDLLRuMq+H60oEXr3Vvb/ALLNzZaV+FPi/Xhw
sYCtUfY2UU223/pjLf6t+lIqfVOXoyU4/WOdOSfzfDTxw0HpUm/uepr/AHvh+1l+kjAY6jIHfc78
/k4+Qy4jcT07kAa8RJ1LH4e1a7DMyt6qR0+Gg/4XfB37r4f7j9n/AH7+GP8A3XqL/c1of9+17dMy
aHePta7Pd9yACAzsag0A2Pie/wCGUrEeq/bt7gbfwwavo+q/9z9Hq16d8afR4N/cfZHX1afTgI8x
9qbPceXkl5BX4O7gA/STXHOoMqA9gSR2we3o+rH/AHFaf8W16HplH0eY/uK+/q174K8xy81s9x+x
L2UVdzSgoB703/jjSgMXKm7dPavTDD9z6Uv+89Kt19Xx75b+j8Ffq/an99T8MFHofv8A1Js9xSr6
uh4juSe/QDAt3pdrfB7e4QSIADv1BNd1PY4fp6NRT6v+109Xxxq+j6kn+83b/ftfpydZO/5/2NkT
k4vTGV9K5vMtU8r/AFBXuYeb2pb9lFkdB4nlSo+WFK2OnTAcLhqkiv7pKLXruDnXn9D0U/3lpt19
an9cgt79Q+vy8/0Hy5GtPr3Pr/xX8NfHI1LoR9rnRlrgPVAyHmYA/akaeX9JMin68VpuSY3BHtsc
HWumaPCCHu/gXoI0Ir0Ndw3thov6O3/45X0fX/A4oPqG3/HJ/wCn6vXtgl4n8VV58VM7zdY5B7jj
SOe18uTRM0ltJLPvwcsUpQ/DVgV/VhTPo9gxCohTseTBmYdOpXJkn6PqtP0V0HX69x/Z8f8APphj
p/1X1Nv0R+1/c/WeXbryyyI1XD+65dKv9TjSyYxL1YpE/wC2EfpNPPbfyhHctwWF1A39RzxG/htU
4e6f5O0m2PrTIZim45n4Kr3CdPvycJ9W5P8A7wfR9Yr0wPdfVPS3/R3Rqep9a4df2uP45VkjryDc
pCPlxH9DVOYJHoiO6jH9aX2Uct3MtvZx+pNIwBA+wg/ymHZR1zpvot4jCny/w9L4PqlOA/3k5V+n
1N6Yd5QIYfAl+8HFxRJ2lV0aHL3tPFk4x6TVHqO/m//ZDWVuZHN0cmVhbQ1lbmRvYmoNNjUgMCBv
YmoNPDwNL0xlbmd0aCAzNTcyDS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiw
IBeRymMoGcxARSwDRiMxcOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoL
oYLRuNRiLhsNBAcjLMJFM5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKga4lUxxFhkMx
vG5vNhvORhFhaMhiMKBFqJRplJJrHzMKoKVAaLyNDIEVJTaxdXLCIMZXKzFJvQhuMqmORwORAVI/
UIJeBhPhvnTHT6oMreVDuDRQQzkeTgdDeZzkYTgaDyICmdTabTDsRAKSoagaOaBVsfyBtVhpzIsN
hneBiNBnnY+LdEMBhDCpp9FqtLrAaWxQUzKYzqcjSdDyKa3FRQLBAZfaaDKchAdNuZPaNI3jcMI2
BAN79DKNj0haFIuioJSnhAFqfuqGTOCoIjXP5AI0jG+g2jqOY6JaNwxjYOoyDK/b8PrBI2jKNw6I
cN4zOI4wqME8w4PYOwwjG974hw+YQDCOo6PxGEODCOkADc+g0xgMrbPbH6NSC+gwjcMkGQcBsbvK
FA3QCFqiDhE40yVJgXBAII2SMN46jONAQDvFI0DCOwyy3B8vBQMT0jfF0hjG9UQ0AMoyP2N79v6/
8AwGFkay7HAUDg3D8hSGYahQFoxDCOdDhBT71PY9ylDLNwyDm+g5jqMc5U9PVJAa7SqO4xLThRT8
B1BF88DYN44DKh0sURO0shaO9SDpF9Iy88w5jSM8BDo9dhPpI0UjvAw2URGcWPTDQ3Q5WMvVo7ju
tM1wx0BFw5DHFIxwGNiHDNA0hzmNA3wSpoyjvUNTwLGji1lc1bXS80EXAOUNjHTlPVBUT1ynUI6W
I4NUhdWKoQkFwbuq68LtcIsEjHcMOX/UeJqINg02FAo3PrEjYjhBeB43CYaQqzsMBRJcAvoO40Q5
OQ0ocOYxtuNoxZYNwz3vEKiDCNuA2awWC3Q77XDJJQw1DRUjSUlsYwK9gzyfAYQXXKEYbTLGaxtq
zthhW8vzDEU/K6MIyTUKkVjpbT9tll1vRfpDZQXBs9sFnsmSGolQjy39TvYMYQDWMrd2IEEy6Xce
B2cFHLx+5AchRNQhDfI3LSfVOA5jwzZ8bO08XJxeoReM8jWHLM5jKMI1jdYVPjnjObQin+POtncv
inyMXP5k/RdfmefZhooQDNT1ljkFIa9I+eNeOF0KQtngxSLp8njPfdRKJEXpQ/EIQbwOc7KJLXP8
XP2/jLF76o9Tkp9LJ+Uhu8KIu8NKeHuP5Vm3I7xp0chhDS9x7x8m+H4KIvUoiq3nOTei5h2prnCv
Uca9c9TSj8hzUMokECIFsn3aqa4Nxvj8pvWGmZwqwk1BQDq51yrooYgohGbJ6pLSHKdU+t1mDf1F
HAWw29gjcm6AoickkNgbDdsrSUqB0RDmgn5RS75Vzmz8xQT5BoNqw20vUNqbc3LJz+JYDnGhNCAY
YnmQCipFLW2KpqTYm5OCcnOMsh/CBxMUVatYVxEN2MeXrhtQMimFwZg6oEg1DFq8Uwyh4VclhszT
XLOYd2ohaC0klLVVU2KI0d1crRXEFwGYMwbLxRhFhUKv06QUe+xmQ5HSNyxOvLEFwNDrEWZCeYKg
KQYpABQG8FJ1AUNeDYniPTm2FtLDLGl1wdpKvBNuGINLLD3PhY4+R5YKHNLBDlHREiKWiqsWsUoN
6KA5BuiDIyIocw8ohmysNx6IH1L3N0GI9j+G4QNkTA9dSgJwLTca2BETFXLrDDIjxGAYQzopRnJi
KTB2eorT8/IOIdUBn/cGGZzcPZCShcylmELV6FK5g69CQpu58JpBAE+lC6z1qfUhAyTK6WeuAU8q
wNsjQ3T+RScBFCcz7x6U/RyhNQnYG0Nsbg3TkJ+RpB0ipsIeU3n6R0G+MzcZExTNoutebjkUsRce
5qsAdW2swrGstksrK41iR3Fulh8JdzkeQx95cyJlTMmdNApUEqLpPhap8/ST1lpSVKthT88gyOIS
4zd8bOXy0IXPTE/LMKqqKn1Vsh0Ll7n+bMxVAkpUBVls8wZrJ5lqQbXw0OI0BXpxEVAi4OYc6MJ5
kOuWB1QrVLCREbhYMA1EG0mrLCWS+6IEtRQG62FQbZuMugDZlzmkiLYSQvFZZDlsL/gGfpYlL7it
Zo/Ut4VwQQR8DDH6+K0T2totdKcolUlzxTeun4M4dWYBiN2nZ+r6mgNCjG9drsTg0XXvXBCIUVV4
oErsGhcVI0U3Tfuq27obj33DcXdu6SimuhzOBFc+mAg04aVNb++Fx0QvFoPdhXDfb3YwozfWjL8n
r3gt2bNQ9/DuUKPMHep95bXH5BOQ5HUCa+X5tqimIEzJeJcT4EhTzQpQPXkqkuJyCDdzqjQqDAkr
AxOpTlkpF89IC3NRXAc+0CnupVSFenEVsW50eyAuuo5wczG7vLnKBKl4KulTUElGmeaYVCDKnhmG
J31L7nAiJb18gQYGfm/2e0DJ0JtjAGRa6K7fXAx3jJseSIr31DNbA8wZtDHISDldB9mnksgQxjZL
4QW7QYsSGpe2fg4IBRfpalEkLL2As2zpkOjb2WhPpQOgsa4iWkn2subWDMeX3DZEFd4ckl3bvEGX
BNuHrrQDbOE4MLEsLfYbKxkzlQ03VSWqVeIclun6tVty+KO8mBzvVWeoUhEXqfvpvu1jaT87hljL
Ovm2sSJ5qBhFDKdrkh0vG2O515bvpHSWGNia3ksKRCKYQrJFTokUBoRkECmeUIR5cWkroDS2FoLi
ZAGpbQbGcMAYIIRhDDFWMSSnk/MjH9FLUcgG4MyhA1IoXM7xHyBGhqEdVSJhjEGdJScw5RZAQdcB
ADQGBISLE+KmDI6R2EIEE2dhIJIRGyL3yrnY+i9t2o9p42yGcKIKZ21pIi/tQgh8LDTuKLdSojTw
URgThW4PC8N3HEHjqBqTEOC4a8IIcwuAp3LGOni3NNwFnuHh7aAkCbCSxoLizAdYByIdt/hkstXA
o3Gv8OQdkOODvQ9ZKE9W0G2TeHBUKrQ0QhnRGoJoSQp3xDKpXcCLkYY0AbyVCB1AYg1LJMM0pUAl
oQCV14NQICJkxX8XcEATQQBbC6VAMgDexdk7CDQn8siPANBqViYZ15ifzBsSYBoKYwYwoIzoTrQ4
45LrwqDsD97l46wtouJkAz41LlYzo1oFAIxeySBx5J6Oh6r6TrD8UArWywTZrig8LnMCg10C4/UD
KdwN0DhxqPKQaD4954ycqzh5bXQ8xzSfRySmiljag2aNqrBKgxpISuL4x+pN70BtRaDNz3BaBJaU
C8oKQKYIJ3oMTIiRRL8KBFJsINDjAOAHQF4F4O8Mo+Dvz1y+bPxNUKkKwIhriEI8w9BlJUrH5Fb1
DEBEY3icJDiOzRijq7IKwFIHJ74MKZ4FCK5zCrxETgipJl0GSmrN8OKZpbA/S0Y/Y9LDBfQ2plq8
hRR1hEA/jELLCsyz5dMEyYw1sHR3i8qjKbxtESCC4+w/ROgMRUI9q4UUg1A7sE48j2hAJipJ6NRO
hAZ1Rbxag2g9htBzTPzCDgS9hdrkBtEDZAyKqPIMLNJ9DZC0KVi0aq43I3bPySANyWyFxRCxhhLd
8P6qa9jeJtJdg/Jd76T6gx4vAhgsr+wHAvA54hgtYtpTLsonoqjm4ur64nQvQorlYGx8YHAgRCrp
R5Tnr6oirtIvAHAGQoUfDsQqbpYq4G4vAGzlj645gnY6ovAG4qwvYwMAIwwmroYiQn4GEjLrwGMm
IoRnMewgQGwGsjj+7tTqbPRug8InsFAFBkZhRhhlBiSccGo7xnhlcTpl7IJ6qn6g4FBoLcxoxpBq
RzqUEQzTx25qR1zTCFURaII9pGRsps708YDYqua2BMB1L0JqJvY4Zgb6gKIlQlglz+0kAyAGLWTl
gj4Gsvz/oxozQEAk4nwF0ngq4jUQj/wGonIGQ6MhYtcyIGosY5onQGczEzUzIpMxUhYrIq80Amsx
UzIhknYmj/xCrlQ6M001oqUxgq0zcy8xIBpCs0E1Uy0zs3E3Qjc1QjQGDlgk5CotoGM2s4c4s3IH
M5Aq0j4is3040Qgi8i06c5s4YtU5J8cxE6k58v80c705s3cv8x4t86gnIoQu0wMyMv09gis5gr8v
UjEx4jkmYqD64nIGom4q0wkzk1UzIibpxtIj4F4JINr7AIgN4BsvMvIlYgUvj8Yo4vzsonAsYnkx
YoLmdCYvs1gpQBs+YqArYqYqoq80gngrgvc+bn8AUjEEAxQBojUykmgmggVGYiw6Y5E0gGTsYoDs
btUvwgQsTphy0oMU4qkwBC0CoKY4DcBtrfBRJy6pKti3TeZ3zbpm0g85J8QjDlhkIFBFD3Bd57Be
ytygLJ5HhZZSMe0hoqxjlLyYxniLrN8pRUjMZhatJfR4lNlLdN55AkZ5YqC9gILjBHpy71wEC7cV
g/BqY/wMzcTL5RNPsylLlOFQMEkZ7CTZANIMw98zYGzO53haCdqPUcLkaQ9NtS1QFL5DC2g25X0P
S8qFwOSWA1R7oigGRXJOZeRU7UaQyzNP1LtTBDFQZXDQApsuRBIM0RgPKgI4JN53iO1LVStP5jtY
lI8dsO5QBMp7ZfB/1Wax1SlN1YdVrPTI0RB3xPBehey8prY97px8Z0xWMej7M3wvAHMmYswGgjVA
g1UhckIi0kZ8dP45AGYhgvZTNgD64EAHEzInA68iVFroNGDogtAizo9i4mwuT7EjAn4HI1cCMAlI
goQszXQ8J5Q8iwjpcIoN9KbxEFlO0XJB8vABogINZW5kc3RyZWFtDWVuZG9iag02NiAwIG9iag08
PA0vUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VDIF0NL0ZvbnQgPDwNL0YyIDUgMCBSDS9GNiA3
IDAgUg0vRjE4IDI3IDAgUg0vRjI0IDM2IDAgUg0+Pg0vWE9iamVjdCA8PA0vSW01IDYzIDAgUg0+
Pg0vRXh0R1N0YXRlIDw8DS9HUzIgMTMgMCBSDT4+DT4+DWVuZG9iag02OCAwIG9iag08PA0vTGVu
Z3RoIDE1NzU2DS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMRAZwaQiwIBeRymMoGcxA
RSwDRiMxcOBANxuOBcMxjFjbEopFoxGo5FjYDTMDTjEhAaRBIIrF4zG46IBqOBoLoYLRuNRiLhsN
BAcjLMJFM5KII+VxAbgaMIuORkLhgNhANhjOxvUqHRaZTqhYZ0IKga4kNxcNBrDBkM7QM5vNp7VB
vQhaMhiNZ1FqJRplJJrHzMKqfZBcMbzhhoN7IILMNZyMosNBzGhoMIsNRhUxnO7yOcPVr7gwbkL3
VxxaLbmc3G88N5/Wa7KMIQioDReRoZAipKbaLq5YRBv65E4oNBwM4vv95H6hBBhVJ9jCoY6fVBlc
SodwaWxQUzSbTgbDLDzwYfF5IcTzMIPd7hSXSoSgbUxgORtO+iOBhGBAKgiOuGCfIs6sBOy6juBQ
KA6jENg0jGEAljKPIQCaMI6DQMo2wxCA5hSKg1AaIrbrEGaLOiHKhLK0rIosGzUp1E4QBiG6QosF
oYtAzrZhoGzorWHKLhgiiMqU2iCtu3KrN4lKsorFDGyeHDMtBF4bqnAj/ucoEaMa6IZqEswWuiGE
zN460yhkGjlO2BoUCGokOjcM4QDCEA4QbB8IjgOQ0jtDAyheNcKTwMI0jlEERRI668yi6MaxWw61
sdFrTs6ikftYzidhmGCfhq5S+rwjQahygQbSwF0tMEwkTRQ4EV0q0zJBBTCgMwEAaOIHDPI0jLRK
K0jbIkqcqS/GljSqmNPI1KkCy5Jkvo3MTuhQIg0jMLgZhmGzyiQMo2DZDg3QlQoijwMY0DDOjyiC
NgzjfP0MjaHQQCS9o6DuN88DKN7xvKO92DoEA6X4OYyjcMgQYQMaiYINoyjmOYwjPiT4vm3DdN2/
6UtAhjhY+q8sqsyQbWpaDCug7Aav/BTwPS8oiYlhw0jgOg0jeN1FY0GSoSaBq3qs4WhZHVeS1UyG
UhQKkNBBbFtW5bwW3BcVyMdQoy3Tdd2zteF5DTeiWoddmvDoMo5DdDo7PLg2C6cKQpiDrA854qEc
p1lsAMLAwUa1dV2YtOyHDMN9xDeO453tuwQbw1O9QDMiqTO/7rO8KgUxsoAUDuFPJBiFF+Dhf2AB
BgQ3YJt2EYVhgy4cMuIYlimLIdtwyjDdQQDfDO0Tt1g3DKMuF7d19AztjD6bun7sv/AIUYRiec3L
QkK7cOuEBYEAxDr1MNQqNvr4IMl+bD3W2Dl33ddHcouBRDQ3DG8o7DqNngDkMMHDKLgUqb2F9hyD
WC5ngVDCHeCCxMOrEQQBTPQ9lsqGA6O4UIokupwAUPZDSQ5B4c2zhuDSnQlq5W3O8UQCAMYbw2vg
g8GNDrOg5wCPk8lxpP3HvNb4dZpjTl9L8fazw3IMmOG9OutJEy1SQl4OUVBvaZXKN9CmHUMsPjdM
/Y6yoiRFSOMghtExAblU3gmBBFKICXohHRK2tM1JhgblWLMikGhsolIBi4QxvoQg0rijFFSMpA4r
g0Vk3tySZlPxeO8/sEAag3wfDoGxCocEIBrTsCANgYQ5OCT6eE8oboEhibQ5knIOYLggDIxINIZ2
1NnYW8hnsQUnEaBsDknpjYlxeiUgoOMeYyEpSBLKOR2DKMuTfA51id2GgtZ4Xc1RHDlN4eY3t0Lr
IBmEBRJoNsnH0RiIs0A4UVCzEUW5LxviCguAyBsDaXE2i0g5RnHEBsgYmppZZMCUId0NFEjCiFns
2YqkUI7LGdkSk0zynHOWc8VYzIwMZOyd0g0DJqb0gqDJXZJs4bZIxPCfoFNujFKwBpgGWz/lpPKW
8+Ifx6l0C4jFH4bULTQgeh6b32vjYkG5bZ2XxJ/DTKMEAZW2BuotIpflG5ckSOiUGNNIKG0ioLGV
Vc4KWS0l8kJN0hQUguBAE4MrYZ6yqh/PqIRdyNKfjTMxyEN5w0wnJOakkU6h0HWPQqOcXpprynui
KH9HCfo/n9FuuVI67VsnRSmp1caGssN4gqSh5WGsPgFWuMc6IiGGTCpUFs/CfTLhpLGJbk6GQ4if
FGx1JorQ0mVYOzlLU1S/TcCh3i5ZHBjDW2R1rr2CP3YVCgpsm3e1Csgl6IqlQYk5W6W6cFAKzgoC
w3ZVYNT8uNTAm15wYaly6j5Lu59K4uWonjauqwU2nKEDKHAh1vKDJdIFb8sxOQcUqlnUm1dyZ8JA
Bqy1yU35nXStDW26tKJ/EbuhO27NUDN0vee65h72XtsEhYGwMb9FAofnwXc49payV8vdYiaKb5qT
WrrKutt5lp2Tm7f6cAKAs3KLVfS6997lJYo/iSZwPcO1dv0yuwU7AUUDrVX+x95bIpgWqdEyk68Y
POvgiK+VzXPzNujdOK0ZpYuSZ9WWhabYcBtDeGS8kQj7FrvZHKvuTrrXYtPgKZqCphMLdWGS8djq
OVFt9ZJat6ifRavbQG1eJ74lpvnc7Iqb78Y8tEc86+N8/5VrlRrN2H0qRJbypKWFCSqIquAdKdeF
ocR2jxfmbUfCfonrfDYFFjURI5I0R0G1mCK2acjgGwuA55BJtdJQMK4lwvZy3SeM5Yqj0ojYA0nJ
l6953TfpoNmYtPFABtl/AGZW+2vtjJGxbsChrsfGG23M1bd6LsCkLXmko13AM4qnZlxpapvyOde+
eKs/goDFshleL77at2dPDWFU9RnuXA1i8N44Y4e27GjcGvycowuLSG99yr56pz9vNN+79OUGv3ob
h1T9X5nTftMOmCHuQm1rMbCJ2VVlV1VkxN+DaJsSkjhvbePM30o28YbXu4SzFoPvqHYm58TcKi7f
W/+7sWvMxW87GU2Ma6F2G87HWudC8xP3wNSuQgc7y5/um+W7J+1l6BxGPeNsoqQV3lSwmV8s4zY3
UPLul9iAor8z3QdTa4b1pdPLNLrWFZt5dh/XfMuoXpIruXhCCs9ZI5Hwzn2ouIaC6PlDqmZJBXa3
ugpt1n9ScAx9nHIFlEdFAImjizNZdXWeihvCK5ySJ2m8fXINziITQoTy2d2rTuWTX25xIgV57gIp
iTpi44S+FXMP1of0OgPE9u6O8u/vDrU1S8kvyTjb6s+07zp325je/Gd6FqIOa6yiZqwNtR6Ac3pN
09IDHp/2ZARcysm8O9WpjgyNARnKLy+tO8w7ATZsgo6Q4cKHJ8CSbXD2qPb6pFgigGojJKLnKeT3
zPbhaZbob4jDrQj5DxrGMCTmDgSNTX7xjErwbdQqr4LhzrbwjH5ajqLuDZSLazj/bdDQL4zTogjT
6LLhq/6hcFgFDLCVMAQ3w6T9DMBvrtqkrD7ZjUaY4xAui+jz7xyd7Yp7kAL6a8rvbp8DTSq9bnEH
6HEDxIDkkGjxDoMCrojsxWsGDpEIjpcHbpsDKg8E7IbSUETqy5bwxSCGqZz4sIUMkDhz7sMJYzau
UHMMSjjLsHysztjMTuEPjyDjCULaxhhBqDhsJ7iD5OpDJDAEBQANiKB3Q9rpiMzpzVcKgsxJ6yap
DPDwTnjdkEUOywDiTr0MBN6oEQDD8ErESK7G8RCQg76KCmoGoFI0yUBD7f8O8Vg+qdLpLua1b/r/
5O4PINJcLNkWL6jOJMacgw4uCGZvL3jnUBjwi+b07w79JyYnyuR/BxkGMbECC4wFAHsQzcLHCHqx
yryk4zsYzHKtMTkDDb8UA645DXsN738b0ObVjh70kNcPTkydxUMPzLLpg+yIDwEIEQwykMwFMe8W
bII1z5MGqJg5CuQLEF0YTrqK5TzJUCEhD9cHEhcNEhsQcdMIMVapkiT1CLpAw7wFhzycgGBzgNBC
ANEmwu4rAjcnRhMm4m4ioFCE6aqD54Um5H4w4FCDMphSBvwOIOrWsqK1gN4HSrjs8aL3EUK4T3Dt
cbbdSy8LscBM0cRvsci+LZIxMdCuUdceDvTPsd0e0NETsNTX0NhZ6yTqr37PzrMLzPci0E7F8wKZ
0OEbr4Mw7Jrri6ggiyo6KJAxhvAGYqTsUcMk8HMhg7EljMMx0fbqbEryqu6oZkRkIsYjhFJkoHBk
5MJlLize0RRmB0pdA9B0pnhopogjYqwtwnIrZIRkxlBLamB55DhcTbKawOZ/bJwFqVxGzzzVbrRq
BbZboMpqhcJcZsp6inZrZwLlR8Ypp3YrsqhRA8pO5PZhJhAEB9oMIhymQhxuJuZPJBxCBukCUa7k
y1h1wND1YNgN4M4PJ/bjhgixKSQ8JsJ4R7R6ppwok8oohiJ1Bt8SoMR3YNBQwORnDlR8CDj1qFIO
qDzkBET/Eo54z9pDKnZ3FC9Cx3qTj/s851p6JnU+6iJ4qVCq0+U+5v5rh2hOwojDMlCex85ihnA8
h7R1wMJ65tp7yURfj1a2oMtB9GEpCFRCCFqERfiCJQhPCSZ+NI9F9ICYj752JiZio8qiJ1YOhngv
Uvk3ZbpWw5JVYtguClEjgKg5zwKmAzoGM3M3hZBopE40AHKWA4dOgus2D4ahyYA7xO58B3KTgOhs
59Bs5dU/1ABCr/phhgwogFrawFr/pzxGpzZgQOTNQOgOQOoMaYzf5HKMzUE/L+oOooghwOdVNC89
ynYFpDiO6qxxhx0gTREmkeotUm7+EowJhz0qTakrcMaKrLsK6sznUM7xSwKhC4q7ZBTGQGsJ7yyI
SGjg61clxnzvUY02MY9bImzhh9tDhgj54oiiZP5cKRqjBtpfgOJ/byoFovQy55iyqlD0FPNYcXku
7EC9DdQ/LcruUXK0FakYa0j07uL1Li7AjaAhxIVTMirzEEzv0fkBMLC48xL4Es0xthskK6zdtfIt
CdRY9X7rScdYlgkwiNpo8llhSz78qLFiEPkG7NbvFbqk9mUYhH7hkUjdD38OTdsj8l8x6IcjLUTo
suSwMeladn6IdjUWjqTIkf0BtkTJbrVpVccPC/jdjKdnchUHUKDLkHsh6HFcTt8WyzbyJN9bRnkC
kvrCxBQHLFrr7P9RS1cP65g5TGRHRUIrJltwDhjGRIzRVtLXUTzmbX4vIjYzFjzYqO7Y80ECYjZK
ihNvBN9fJTwtMLllrUVl9gdxsNMfMNdmb4EIjY1nCcrZlc1vxBVipGgoVjFgkKUT91bYA4FzlcEU
to1rlpEVMgkFEEVfIjQGTF0a8OjpRNd09qsvF1UvV1lhDEt19zLZN2MmUPpvtnsaEKNx7vtoULlo
rncBrnsCEEbQroTdtqDHkeLJ9sbEtqk0rgN6rmk0MVy5D37rE/UVVsMYcPMyUmbeliU2TAkP4OIE
FuifAnL81rTn64NuonVvj5Vs9dNwQq+CQn11opTstwOBwmyyZg1jL3DzJMa4IqkPbCtuMJlhdnEB
14K49fJUGEd0iZ102FDEMi+ECf9mz0d7ccz0z3cs+GMpD17lUThL0r13wGIrGI9j4FEsbJMEMjVh
Utdktplu0t5vt+N6cfDvkfUDjHELTwuLEwUElq+H4wycsFT/UjtsDQbZJbkgD4UFeDUzhAcz0iFz
N+uINuUdWEoGhngqd5kVznVvTPawUb+BEJl2hN9xGDkIxk4HDztWD3g7wuBTwjJUIyQvBG1yivQy
pHwoWSmB1YovR0AxAtCVRyWEFf0gVaV6Me93dyEwt7DHF7WLi0bZV2T4co71x7mJku+Jz62KArDO
2KmK0OMB+POBL4lnGRNu7teMN/Dy+FNjcMsDrFFrt9kF16mMl3tk+OExEv9r2NcF+Ai/jP1suJF7
7sltFqrtNzrtdt1clhOQdxQHGCzimLOaQFGCqfFu2R+SeEVxLDpHJk4m7+cbDYmTgzAyAqQ+5HV2
KPwG4+4qotYjCP2EJheEcdYu7kWVtUVZijk04xpkQ/Jo4q4yg4BI1O7/OGM2lIxmYOZmpm56TJ03
Qxpoulq5gq5bow+mQj47wKCR5gpfai6TE5JtAOZ7KUb8SUxQJhYKB3xhYKLuq1opR+hnA8dBhDZg
tAB2CeusiMLf7/A71G085cphJh1UItAGwFAPOndGcHJ+h657IJyGBjJ5U6SG2pGpRdlBhRBhb2aT
yCx7Nd5tdeWpqBSmIN7lVJ6USnCnUWFE9W50wNBw1M51AMpixRLf+wE/VWer6QyEZpz/+sBPcRgN
49p9oKBHKQwg59oKO2gFLuuqaUqU9M9AohwIqqwIpsb6BPBPRCDDI707hrQOBnRhJgk9oFyAIMKq
z+ymoGWuBRJHOueuuu6mhTBuiQ2zSSOvMTAh22Cq+vyGWHRAOwa2CSJwtWVFGxJzWuh7IIh7NWp3
MSm6IFG4gg4Im3O4oMinD8R/NBc9hBfAe2/BgFHAoOynJi+0mTRvetg8hdiixtxO6emzyEJs+0Vf
Bp+4r+yS5QBs9HQPG5x4FCW6W6m6xp27CUeuLUyC2uxnBnSmoGaVVEh6m8arW8rLOvW9A9uvrpml
QqGlhkhXUoC4JpemxmRmhP27+ntP1Nwq2oIq2jM4emZy5zJTJ0IFMqSnZ+G7dUWunG+8p2VMx7IJ
p7M6oGwOVDqE4Nx89AoNgOBdaEz7h3FSQhyD5C2tD2Yhx9oO6KOtSAoFFJQloOhsnPBddSE+25z8
XHBctTJDKiJrU248lAerL6Gt/MuuRzfNIMR6oMINcST6HHnRL2fQO1Q8u53Qx9G9O4h9r+25u59C
QOCShgm9PEu5BCPH23Wy3CPAqEHUvVXRCsw728x66q7uq8CRyEBnXDVBpDZQ5hRtBewIeEiVSKmJ
+wF5+mizpN4Ieuyeps4PBggFZCxnhk4GAxeRVgIItvcVGgOSNbBN4JrsoJwEHdgKXa6D6UfWY9oJ
tupMtlea1j7nXekBtkZRozQ6iHAF4J0cqdtUSN7w0JWeMRLAnW3U/VJO/Vu7HfZhYJ3HQpR24N3Q
j7D+1CHbHgcTW4yRW0J3vCCDL8fXxDVXz+mwSaa3R9HZHk5TBz1QaCyQxzG+3MPMfGfMwjSUHNL+
wMfc5tHdLjYEAIZ7NLQ8vbnV5PBxB3u9IInBXW/FQN9VZjOtaae6FDHXpfJp3Ex43YWqWy48vZD+
3ZohwJx7PaPVPamsQrtXYN3tA+ntXgfL5zerh971vOvqu43QZ7SCWtDWvPJdiBJtBCErXCkAjqN5
0gQFAJuEgJvNZwXdgIfd139iFvtgIIi5RKne0W9iaeXkqq+EngHwXmO9P06fBK15uL94Ra7hWZfh
/hE0RvvihnhRgKIlSK5Iglol6+YsdwIqhGd5hSA2VfQ/ZVI2ZnwnItYoQuCM0jgpYFQpovwkYmgz
InAsYngnwoAoQvoiYmP9ApIpf8wqArY+3LH7H/I2Yr4BogBCKgNF5GGQ5EAxEBUMwNGouGA3EAwi
YgGwuGI4GUWG4uGwzGggGoyh8ZGcLNoNihnBpCLAgF5HKchM5zEBFLEqiAwGEKKhjBotGE7nsLO4
NLYoKB1MQpjIuHIoNhpMYgJYpGlDGIoMtOHAuGooPIpFo2j4zjFKpleqFSqlWrAwrlssNjLpUJUt
l8xKcnms3nIytAzG44iVCFwyGA4kJUIlIpRysgxGmJFBpOwpGWVHAoMJ0MtwrNprtPuopu95GIxj
2GicYkkLx9JKGSFuUy2YzWcz2g0VauemsWovANIsDoY1ivJiprBsfjw55Q1GY5jw3k8p6A26Ui0e
bjY2yoxGsSGujG4wk/iFw3GQ271D9MnoA2h8H6fo9UWh43Gr4POobwP49r/pE6rrvo57+wM6jrBi
GCQvsxLuuor7xPCyr3QAGcLhojb6vG8sDw88K0O46cEQhCUTwrBAbOwECgDRBaMBu8wZoeGYYuzG
oYxvA60BkHAQP8qEdpFIbEhukMbo8GEOIeGjXKAHChx2hSRo6GqihxC4cJO6gZKg1YQBxB4axSi6
QQVM4XBpIDqS3GAQBzMcrJDCyII/OrKzghE9BjO0ZAaHLKvPMMOowHL4UZN7/RI2CJUdOEUq/QUQ
UKi9KwPTbqBANlCq+GTC07N9P1CHNR1LQNB1S60uI3VqN1esAYVkGdPJPWtY1ND6Nwgoas0TXQQD
yBtgze/dZ1BZCezekFI0xZsINYGloupNcvWpW72hxDltSJUMITGwsOUvV1nPG6tpXTFaMXZbNT13
ZyHhsxlfVReqwTTSMMITKF4UssFSjtZyLzBQFFOVCCOytQAaNYGSM4Ai6eQBD7EhohCgQg/uNu9M
bNoRjwXMM82Mx2k+S0NWWUx5QlDUfiEx5VZocrRQUs5ek83YjMOUhyiU3PI/MhVVQmfX686Lv/nt
hXi6iwUFIqOuxoz2wVI0rTCGrWBq10JoPjCL1U+GxYi711uU+qSzi9GwzHOGXZqHKEBtuSIwO6yN
IU+ua2vA6Os25UJx/HCOuk9e3RxHWYKAMwVJUEAj8mJSKjU1+vOUO4QLRb6QiaEAti6igyOfFsUu
tGEeu3Crvw+i0RZQ+T9vZDb4va/e2wo/Pa8XAuMQF2MJv9DnVxj3njb2jEIwI/F/eJDT3+jTL2PJ
HESot1PmRX7bo9VBNCRpw04xyF2bO1xkgsTIkjZxLMlVJJqOhtKEDylKgGyt9Eyy0rYhSXjWqJTG
DlMrRGlq5fQ4FKp1k4OILAnROzJnnJ6SgSdmSf12qZZkohdqjVNqQUCqROsIWBrTKApSEUCgaL6V
UktIi8oWr0heqSGKilpq8VvBtm6sIdwyhdD5XCmwZLAJ4spYi81jLOWEsuHC7lnrXTzE9WizlrLY
gUh1cSzlyrfVNFpbkXVzqLiqu9HjCl0RlQivBhSxVxgwXsviIC9GSppYGv9CBF0eMDPKkRg0eWTL
xYWwBhwMGIMSYpIBi7IWNMcX2kxmkjWAEPZPIxmzLHYnnZq49QqfgbyRZsqlnMBpLMwZ8zCTT6Gh
JmTQ1gg6RIGqnPy01Pj/FrqAak14hCTmrneLQ8kBrW1lteLA2E+6jDvNli82hnba1CPldot4iTeF
Ht0lU3dvKOG+MTme4BRLg4WoEcO4IqCn5oP4f6goOayFBMma88x1gICUmrb5O9ALGlgGKf6y535C
Z9JeZ3P1jrE1T0Bd0yugkBp+T4n8ayhU8JgAxoTRJ7rzqJLWnsoqPE/wcJZo07GgaV6KJ6jxO0HF
GUH0WpNSh8SM1kUEBmDNXDjke0XfRTJ9iQyE0yIga4kaqyQo8l+Dajz+SJMdhYWZJKWyimUM4h1A
8BUymUcdR5NcDFkQtI9TGch/yJGUK/MiCyfDyFDI/FONKhKynRjQos+B5Exkfo8peElcKt1zjJWo
kdd18x0POtCKcblkV/ilDxcaaSPNgsNYNe1io5rUsQfaG8RFgH/X5G2JSxzyNNBrW2HNg0tpnsW9
iYtmIwWHrDJmLK27UFQtVWlcb9kKVorzbFAShq+rUqIyawMSrYmsBu/6j6wJqEHrxH0EEf5qN2j4
Qk6CjD8yISIDGal1JrMjrVbsHMFWM3YusRCrkqZLzUkMyiTaCq11nlLHRjcC2MXnITVo/8MWg1fq
0liXyFJYVZXs/4GktGVwKs6dOXLVKhMmYhL+9CO5ywxmI2Cr9BIWsumVW+mEqzzzOoGaymNCzC1f
Ke3i+jdWSGmT4g5k03GOlPY2wqcDDKYU4TlOWhGHMZPnZs5ByU9J3UeeRTWldBkB0SpFh4/eRGTU
ddyfOtWEp7H6xqmSheQ6Jq4x/k2h1I0VUWydXijZQ6APVybkXMWPKT4+ebUHINEEFI0pth2dD6aX
42VwkK6dPDFnmfkkyndQ6ipvf0jxTdSn/pcIVU6QMN6paHvvcKq96KtFnq6nSsBUIxwXISlyrdtI
UWDrM3aD+ma4pIhHV+vdcoeMd1PqSFi+jyJ+ixYLV9gLR2RsdFSyFjbJ2+sZYnXav9M2csxDOJdm
7L61tDZ5dx5bSxftZYO1MQ30bPPJtG0dsiD6cXdti3Fj7f28tzt+4OXnY3fuMpG5FyoCouK+wy55
9jvXSucmO60jLsMdu1dxkTILvnqaBfDfuGGeV6rMtjga472kgvfOm+JD75yWlXVR/rO2j374lURn
eAKdtNQrgVklMcEX5ojgw6WDmvmupthOZJUIvZv4FhrOdN8PcoxDTq8WoDV7txOghvtasWagxm4S
hvMpyOK6HnA6lNFCTrIp00sBzVkJgMTEVSKHTlTz6lEVXFYTzkJ6kvdRMDjydeMqSTKyb+xsdMZi
nNDEWGUnfaonrlQe4JD7ltNtnUT7pgnJR2t/a+e4zRz3TspI5yeDrV1/vnguukm6mrhh11OvJC6o
nrqz4+ooaicZVW/V/M0HQPQ5QagkpWOPfyyt7Ql4K4PHqBjrdpA56IuxMk5ilRyG9CR4wQIPbGtz
/HDvJijrE8iSqQhDE2a6sIujc5TE/ORwVNdtBXzk92Yu2kRibFiiryYT7y6hO6rFQd2A37P4J0XU
OUqFichUUkl3h+pH8FE1fiXoxP4fNoFfSWb/YiH+P3P0vyJ2lbobiSlov+GcPzt4FjwDokv9P1J9
KxP8j9wHihwIiSv9oiuGOkiMQML4F5QHPyDBCPN4QPwJwQkTwSHzv0QMD7rhP/wWKevIH0Ouoil7
KiJyCDrkwQk1wUnBqKIiiOqYnjkjveCSCwLwjRlGG/QQj7oRQkwbwallE8mIv+vmwjL/r6DWPOlC
PqCeLowqv9qJD2kft4wwPemcJDnmvjjFvfJGCiigQziNDvQmvUjrFGEAK9jBNDvVD3mdm5KQFkDp
H0Qck0rbmSPAPKtImkCMkNE6JUjGKjvPsmMUMWuvPRQsiMKpqOkjraDqL0RNlvmFCHjpKvu1xJoF
CzO3vNFEvODYsdOovKOtu8J5RYPHlIjpO6ETvFkEO3OyDEvDRKO0vPvAxeOxiMu9u7xcOvRkOqqT
vExmMZu/RfRiQgvGu1uzPDuuu1RdJvwZxcxbRovJPHOtRmu8s3RTPNwwOsRVvcm7FgRBIWoYvTmz
CEvVEePWFFpHFBG+DCEkvZmYPevhPcm8Paw2F7vfl+w4JDCdvipPvvPkvwvmPvPnv5v9Q4DcEoPr
DFvvPtPwvuvyiePwyLQAyOwEwAP1v5STQwv2PowTP+QByWv6wBP/CMP3wAv7wCF4CQwGSVQFp2wE
QSv6wIFwP6QMQKkowOQHwPQVQOwNQJShQUSKyXQRRUyVQHwWs/wVyrwYxsydwjCzKPHBiEGDIiwe
EUwfCNwgKbwhwEQoxPHcwlQuQjFSHfNLCFQoiswpwtDYy8F7wywtyLyKS/jYv4FywyDzy9vmw2Q0
QykIQ1kvw/CIQlw4mXQ6R6w7NCQ8kkFBHBwbpUgaRAPSRBpcRDRpxEl7RFxTRHGMxIPEx2RKOcRN
m7RMDVtDzZIsN2quO1DWRQp0RSRfRTiLyqxGPQDqRWu8p1jwFHxyxaTlE4RbwaGMn4HmRejNi0Hw
xew4TQPqzqOxjNlDtWO5veTtjqK8PLztTwSwmTPJTvzuPGSdlrunz3wuTpNWRqz4G5IIRpTnHsxZ
qXTrJyqPTjzmz4jpKPPRS0q/j0kAR5ovCSFtEDvWpHCSPhxnCRx/vakYFTkcDWSCPeUNE7RRCISE
vyF7xfvwvjPeLgmCLMSJFSEhFPygwuDsH+kcGyyNy6JJPuF2UcrsUZQ4EjUfQVSbFSCOo4FEwXv1
EnUjyYv9jCklyiQQIbUoSrPyUnlSSkEeSdpPkbScwVwF0uEftd0pH+PbUmv1UyyNwNiFU0GvzPSm
U2oIyRSXCNEyQG06KpUkSayTu1oW0RStPyO1rwjCRvPeO1rtsXEKQdEhr+xuvkVDGmo5EES2xTMl
J7y4w4O1iRmgSjy7u1j7GXTE1DENPJTEQwUgUYGgVRUlKHQSQqQtj3lLqfQqTHUPnExCGMw30SlR
mgTLUKDEjKCRTNS7rLEuJIzQFMiSFDk4tNCDvjztm9DzzUPsVoOxxHznztC0UDTqNQDNmJL/zGky
1vCMQ5E9S3ztDWDVnGpyiJUAVtl5Sq13KM0BxXz+TmCU17E9RlTlTpxgvmz4zsRhT2yMzu1/z0zo
T4WDvLRnT0Qjz1T91oDuSuzxzr2JztICz7VC181CWIT8zmT/0C15x1PyWQ0DioFB1lHdUGMKveLL
KoTjR8wuLOqejpvTvaVbUNyBvdj31b0RPgQuUTCSUUSHFSGvyHF5UXUaCSU7vp0aEd0bPxPsUgmQ
Udvj2pyNWmj72qUhyT0l0Y2uUnUjWv0bv60rgb0oyXWzUs0iW1PzwDUwlWWwUwEH242yP9000x06
EBU1U4VA03Ss272/0z1A083Bkh3C010iU+rO0qkhjK1Bz71RvxVEwcyyO4KiVHQflvpiopw7Pa1K
qDVMVAlDvd1LwoVPxgVXy+RTVS3VPg2lUY3XUnVWwv1YUTCMmUV0vcWeCoVcEx1dVYjE1e0qVfvn
VhGREkUHlbVjxAWUjyjzVm1u1oGUVpzxvOVrTWVsWSVtKWRK1xjNmMV01xVaVymFzdWSXxV1zf15
Pw142S0I1TgGp1iBCCAjAZiKCfCGkII2Dlp/H0N4UNWzv2msjlAqCUiVnJif4EijgUAnAUgqA1Fk
EbG9DEFbyNjHAGgUAi4H4IxR1gumki1gKEExxgVCKZDGiUgUJ6YOPyDWtQChiI1g4MAUAa4WX9oz
3+wxFcmGSFmcSck4EiYDYMge4WH6iDiN4KkwCT4Z4HYIYJDKKuYKyBYZgiYWYPCQ4QQfPaqtYcF5
CD4l4U4V4nG5KKYYEciJYZkb4bCtF2YQYdN4DBGROgCQFFiUYh4rCICJYQI9Q5NKjGMHCvkmYg4D
iE5CiKDnYYSQiFigAUAmg3gyA6g2A6g54WDjnJtDiKgllkAQHMi9CYCZCaCbCcKs5AofrZH7KasG
TQGgDKtUFQgplkZVHAsMq+J5qeFDGIOylIFxiDtjxH5d5Y10ygL/iMXGFx5ZZWK+FQnIiWiBiHm9
Y91yLKvZlZK9voYhCXZPi+gQC/5R4NA8A4A3g3Ayg3A6ZKiB5si+ZQjALBjOULGpLtvPYoF+L8qT
iEZXqszrmsZ7RaOJPoFEFHj4OEUOlcpGI9lqT4qZGMEdJSOEZ9Z65jAG5mX6Zn49CK4+S0j0p3MC
ZAkp47Z0iZC/ZRCc5G5H5I5J5z5PZ1ZuaR0rHalAZTj918K9mcGsH7U2AG5YOzEj6bCi6Zk/Tn6A
Wiv9piDF1Qz1oq6drJQ5jYCQv1aaEcr86blm6J5nY83+6MUVFRoSE03f4CiU6QZt5u6SAi5wZxZy
ZzYnZLaw515R0sMEZq1tPoV8EJk0mUHP6I6da6kR6AZ+a6Wxa76Av9jt5ZmM6Dv1EJqYwp6GacD3
uHa+T45+ZlnJX6CCwc38iHar5oiMjwn6lsQjCTY7YEYK5FAqCjjaC1inioipiqirjRitjSt2jhiy
izi0ilim7VC3bWi4jg7ZC7Di6w6RZ2QRDCDXDEPbDGjZjIjJuyjLjMjNmTDejQ7XDgbYiwDhjUp2
DW49DYYC7lDa7mDc7njeDP7pi4jSC6bsDi5LDmOnDlZDnUHwM2RaHXS6kBnr7IJ+nbnqJ7smHeHo
b+nbEGHhKGHikGkXpgcDQhnvGxN2CPHpD27+LhpnnZsxb6qKkWb5MUJ4qXJzwNs5cPOQKdH3tSM9
n6EnykEpxIn+L8NCkukvoCEyIApWovqsGfHzE5lJk7oKlFNMIM2jtcIUlD5ZonoQFHoToSIVITlB
oUoTNwlRIYcnoa24rYFCohLFvYFetvcrFbNpNgFklhrcrNIj8wlmI3orttI1c0NnItlyFvSiLTou
c3rRo14utcI3l1thtXI4DWretiI37Ho7tymA6D1zGCmDpAq24eJCw0mJrpmApFpUt7pH2qLut+c+
JKrxGYJMJrMcpOmZr1mbpRzImbJTt/pVGh8aahGkJYoWpZoImnloJcTrmqJeao6AJgJhGuuTpppj
myPUHnm05aaDneJx7+m4pquIJsFlJtO2JuoF1HJw8QnEpzH18PpOZmCKHKiKZO8L8NkYjtHuJ777
8K8Aj1np8Cb/Ea8AMoECHl9xnicB75nlcDqUkJJj9BEM8Ioxl/kQ5iz+l/9vMt8MkUd5gGnydrMc
GYH1EbEcM7EixR8SqgGq8UJ0cVGkqRH4qmIA8YKo8ZJWZiv5k2GkoHccII8dIKLacfJPNlIOchu7
lBcjFONSoS8jtUlNebct8ptfoXFVob8q8sof878uctNWoacroZOqcwInFi8xom+YIoc18zIrNaF5
c483Fzc2Iw85+pozJBcq+vc9I6c+F78/c99Asy9CdbmF9DpAPu1zJCIKdGpE9IH79JGQGO8+JIN7
dLpKG3uAc+GW9Q8hdQdNIadR9Q9TOIdU+Qr8pX+SJZOVmnEzGodZmppdmrdbz49cpKJh9eHnqxZi
R6JmG1GBJn9rG4Jpz89OtQJqCs9muem/9oQcdpeE9qHgdjeFJ1J2J6s0J4p5s194J8sydzJ/MwVL
d2sNqCslsjsqncsqMsuz8OOYqHsUHvOUqMntMkMwqSTQp9EdxZKS/e8MCE/g8EM2uYukfdZ+sYs6
n2qd3fqfcTM+j203qjK1Kk0GeNr4qntFePgYiADQai4ZjEYiAajMbQQaDMQGMGjGBC4bDOHQkbi4
ajYbiCJDgXDkbQgZyAYRWPDUYRQZjSSSAYjkZQ+IyqKDkcy8XTGRjEajKWQeEzAZR2fUCK0KSzuZ
TSj0GSQuBQ42TUaC6Gy6E1KEiCqz6r1mdTGZ18awMbDUcWOm2a0Wqo1iu26KXCt1gZTOfQuzzm71
MQHma3wa36l2SvTWM2rDTC24qNDjDQuS2uzSAcjSZ3fK4mfZjNWyyxEbSsZZnRZ7Si7T1qFXKqaQ
Yi4ca6ubEYjbZjeDTobaHc0DT0qQDUb2s7aSgTgazrm7kZyG0wgabMZDG18GdjbN5rWDScxDc7Mc
jCtd4ZeCPdwXDCLdSgQWHdoYDmOjXvfKnTaK+f4hi3DwIYkb8P++aJo2tcCoI+yPImgqhIa1gcrW
8SJt1CK+JRAC+By5qzuiGqYo8izaL9CQboc8SCpCu0RMiozrrk7qFwonsZBnBr8KvADmvFHAZu6l
bjqM7CKBlBT8pwj0jI2i8cto66nSM8DDIy9LnyAzYZozDz5y0kiBv0iAzBUiKYtpESSByikUhANs
zzYHE1Pw0zgBklaCyEFwbvcj08NoHEIyHP0ftmgVBz5PwYxkHNGOpOy9UbR6EzYjkVIjSctzYGLz
T/Q86KW39JJWHFBN80MfzzSlROBNE5qVTlPINOVQ0tNyIDRTLZotLcxQBN9doJIKSOjJESKAGAcP
vJDWBul0AOiG7dTCrFlqc14aBtAiio0GCDokq4cJKkjlt6iVfqUyiGqdC73owjSOQczECKWk75v4
lrUvE/klqGpiep+qF/0Yo2BKTfaaqQgq4sAsyw30v65qsrGIsOx6fLfBWLtHjK64227PLPj+Gryl
LCMm2DAsGjTCtSszFsll7IMYuLOsukLQs5U2RNBLbHY61bW5m3LTNRiTcN02jbZUr+lN44iKOA9j
huc44QOS7TmOc9bopFD7qtY7D1qA4L4O+8LZJDT0FvSnL6Xe/NgPpHW5UwnyVv7s79K/ASWwJu0H
IHBO9wbdCCN6/FjQpdq0cTbV4vm17Cw+hKNRHaMTOpaW7xZD0FRetUY1BGiQhxG9ebrHgZx9YVe0
hPlroMkDuSS+Ml9nyM1yig7xSpf0uO/LNeWJeEvU/YdfcRTA5gaGAQeelbm+eNaI3G1mTX+krmzg
7FjeypcPWh64bXH3bque2rWJ/86fKd9QcSlSqsfc7CByRJ7MPwj05tZ8z2k5vvfu/94Kgievwfk8
F1j4yrgyfYvCBb7zovlSeRmCL3nsJbIzAZ/j32fkEgCrl6xV0+pPKuDCBywTsQkT8Qk8hTSYkDIE
goGSNXTkePsTt4pLSmNpJinJLhCIatiIcngkCeDDGzO5EVZRFFTkJIGDAs5NIkHthaa8opOTrnxY
YXcG4NzmnXhPFIuJ5VMRiPaDZlJ5S1nXIWDBb5cVxxaNzFZdTa4zx1jgUogZuTmlVOvBuMkUDtx/
AbIE2kgzXxmMSddNkKGQR4kamiSC1Y/STkeseQiACXSOJCk+Pp0zBSeByk9GqfpAKAJFGWVEh5VL
1j7I0vLy5LSyQNKw2JeYJnTLvIyVMu0PuskLLJ+7iZhSXlTFF+JJILP7LyWhai8DTtYlcZSXjwYt
ggLzBYhTu5SzagcRpuJKyRO9lc/eMDsJyzghk2xsMKIwzhW0kk2c8IqESis2CesKZAKMT4DE+874
UxGk+ic2anYtRNfKhFZM5qCIUO7OgnpODpIEYEDJhhMUrzRO8DRVJEUPEEmmWdozb4EURJudl9S0
6AlANqR08VK4rpsSq/yF89CdrnUFJ81xxT30xNm6cwxA0PFGplKYih04VqKhMe2FKZEzQYLzB97c
Knr1TJ0+KDsTkn00fq+qBym36OtqW/FWNY3+QDfyi18daidVVpjW5eEHKywJmbAx9cGiCP7pjBOA
ld6t1YrmbmwL4CQVwAarqpcJSSQnhS92o5JIXl6pDDOIUNqJkZQAltHiSzxUUXGswhZ14mRHPrZJ
I9pYnR8PbFMiEVY4VIizNqfxFo7xfjDPiOEwZTx5hPGqVkbY9RxLvHO2kb7iSLULIe4drJkXMkFM
GUMhpEA4kVb2TFTpIy+uZJljd07syVk2vqUkoJhyjTRN+XsrS8zkXrdiVN7payplvJuW0tL1y5ox
Um3kkpf38ksdOZLYrnYCnOe2ZcEJnThW2UpK5OTkl5mtMFK6j5trDXqmyb8z5xEXBpe6h04Sitgx
BOwrE7p9zxhk+U6mKZ7xjn1U66k/jeUBxdQ9HOLSd2noJQts8cbXxNogdSiUOMNLbIRRejMOYa0M
KxR+GNIi/E2NPSZcT2ULuMsWvJBdL33wsq6Vh3FOycU4IMuDMjFqfN3p3UJatRX+ZgLitt9OciE2
Oda809JQAaH3KXVVOGeysZ+f1J070pazvom0hKYNXnWnpt+YbR2iyrwuqzM6j04mo2I0hpqZhtLC
adJOlavehkQ6fgja/Q8XYFaYz5n6DeoaO6EhA61XR6WvKhzwsHXCLSlWTm0fhRS3LMbBMoxuzraY
HSPgCT+0awIakZIFn6JVGJtEcJDSOYUUtHvlfXHe2ZRTZnGZTbibSKX11IkZa/dBBc/SnjbGBtEc
sc4j3nfmKm8m3YBupF+1t5rnlFIzFLdV7DjrOvff6Q/ByiywmHIDhi05LXkBupxq8m5RcL4tdu9l
1jWLKlxI3j0Rr5yHp2Ru53ItxzRuVLl+JIVgb4kBy9R3AMDJILCy7jF1H1Lv1bJ19R5dSTTwi/03
UFWxEzSQXw2s3oi0rifh86VDn1E/w9iXnBdTu43pXYQ/GLt2LGK71/GUjTeHSxjPaGpMFr9koRtd
LtIzvZAkPt7ax+Mi7LbEVrJRB4HF8tOgujxM7X7COMffKiS9RUBLQ4zUT7su59iohJD2ifFNhPS4
Cg5vT00HwSUshMZ2wkGz9UQ42i9cx3zp6jX1jey1QkPrOt8AdA+yX/VrQWiH2xh0Z7vyekffad0t
7fTGldWWHhD7H42DtQEj1FcDBWpiNaor57E5erLAaC8lYP53ts//J1v5TXXZfa+ptQTjpWwk+7Ed
N84jcIPXQ/ioYXBCH4h2k7gXLalqf8kyqGta26iOVCtG4q3O3HAKi8nSKK7E4KjO3aoAuC3OfuPU
uK3q31Ao5a3zAm/+4C384I347M4G7HAy4giO4k5k4XBM4dA7BU4mk64qJ24umO4yizBi445cNM5B
BQSRByu+J25UXi5S5m5Wjuu4SQXNAa5FCRBA5m5zA45u566Qgi6y6E0+6I5Mcc6Qmy6WMiNcw06e
hI6ixKte6q7u6knW6yLS627K6yN4809e4XAYx0ns4gPIl4oEjC28Owxsx2i02w/8x+oc7sw87y/o
jEySOEYY7+W8ROz4o+gc0qi+ySpK0oPa8YpTEqW+bApc8k1U/Mfmpq86O/DezO0W88g+9C8m829K
RaI6168qzmOnFe/GnsIgeaCECoAaBeCMBmeeIOCoDMIiJWQAJyeiT+IIOm2wWmukT4dYBACoTgee
DOedGeIgeeCoDuAaBQCcBSCoDUIjBiBgI6BaJWhQ5ACoCJG0CLG7G+qIIkehHgwqS+KAgegUPTGe
TgBQVpHYkOicSXHKN4JdHRG0BrH4U6h1GLHgtqqUPqk/B8z6LXGhG0B7H4IyO4KbHIwQPfIHG3IM
J2IaIdIzHMJzI4CJH5HcJdGNHk0Wj6xyLuNOIdIlH0JjH4z4UfHKdYI7I4i/INGGxzGNIWjCSCQm
MMs7HxInJPEtHgeeIWOwL0BoJANqdAJAWfIjGiI9KweoecisjiCoIgBQCaDeDIDqDYDqDnH4CLFz
F9KyBACWIiBADUBAAaCECwBABeCOCmJcDODmBACKCwIjKgUUM2NWNKIce6RYo8w8KuYQKqCmIjMQ
XYR2KhMOOXAo0yxGM8NOZbEaNonSK+RYJiw9KaZdM+UPMi0zMYAaTLLnFyiiI7GNKamWL2exEQtb
KPLpLtLwIdL3L7L+BQCKDwDgDeDcDKDcDpLRFzNxLvLyBBN5L8YoVMcqa8jIe60YbAOiTmJzMbMA
RDOuTSJzOqijO8z6JGb6iUm6QWR6M8QkSCcATEUdPXO6c3O+MTNXFwAbNdKWBBNi6UT6TScrKpKh
NvLrOXN3L5OfLBLFLJLNORLnQJLxL1QPL+KKUIL9MIT80CYElLO8NKIPO2rCk/Q4jjQyLC+2Qk3E
kaReWVDWUENHRALSSSj7HukBQ1GccUIojiKrPtNbKVNgJ2mWKKiOKLNqjJIlOVN1ObQlHVODOHOL
OPG8AbLTQdNzOZOdQmWmRMM2csPKe47qcG9PRvOyMTMchrS+oDOwZc0C2wilTO0HPK7qgnNObLGc
kALSWGPPPfQ9S8ZbTbTFR0TMCiAaDjLeDTLkQANoBAi+sObGLUgaBABajAiUJcDkDLMfURUUcQLW
TgCuBADdGo4qWSJGN0JnUgKbUoAbU5U8ei/gnJJSBAeq2EWOPAJAw+jaYEf2BaTQWJVOTw0rHudY
SHQEThR3F0CMJ7GfGCn8Z5KApcQUTkBBKgr9KtK3WPVWX0erJEj3GrK2hQXZGwAaC3N+DcDGDkBT
VyS6BQDyDgDoDSDcDOBeDIDLXJXMOxXTXXXaDOBADuDSDoDQBADCBADgDqDEDYDSDGBeDgDkDSDs
DCDoDLVeDKDyBSC6CoCVWKZNF/GCTYJnGNY2BAIKvkN+w0avIlGlW4hTW+BQCmDSDaDgDZYfOADD
ZbZeBBIrGRP0gsJGS4hISXZEJDZJHyC4BQDmDaDCDYDZU6DqDaDEDKDlL4DMDeDkBADnZZZdYNX4
DyC4BTH5F2TxKxGAAaBadoRSLXVzM6ObIHXCC4SxXMLyUsBQCZXNGGBQDKDoBACgBAB7USBYBACj
byI8I7aECEDfX6TfLNbtaZYDYUDbYeDdaVaZada1YnYqAaCoTNGuIhbVbYBbbcI0BQBuBSBgBQBB
LrAhb0Vpb+CcBBaFX7YfLDLHLKDnclYpYtctbDHLW1K9XABRbWIFbbM0Btd4BQChVza1dJdWBQCj
eKBTb+JHdKJGB6JFcndqTNc1d9c5eBbhbrL7b+Obb0ChYHYKDHLbYiBADLSZOJONeRSaBADeDMBB
dbcVZZcbcfabL5UoDZYbYXYeDoDfZrdpK2I2hTbNZRHTeFeIBjeNLraFeVgSBTb5aiBAlXXbfgDQ
DTL4DGDCDmDLclShIzgEObbMWXbRHTetILexbfJNIyBjdHb0DCDcDzaTaXabamDqDHX9X7YbX+Dc
BBXbYcDPhpUoDnLIDpaeDkDeDbeQCKCJeWBfaFgReNgZeWB3f/coekO5hCOthJd2CTfeDvYeDhYM
DWBACJb+i/b5dbh4C3aEObLqi/eNVyC7LteRecPXeNb0JdaFhfh7OMDLiADldncpg/ixUeqCnTbT
d5c3c7eDJNdFb+ChYVYZYdfJhjfPOFfTbtb1J5gBa6L1WQAbY9Y6NZY/IOlWW0oPQFJlZXZnZgDx
ZlZdYfZsm7JVZvZ2T4SXlPI/WneFaJaNaRcdhnacBBahalapZnauDpaza3Sha7LXbBbETaXJhFkP
gNd6OaCbb/cYDmDmDDiBb+C4SCBkCmDLaPnAoxioDHOGDtabYcDJfhf9nTXjeRaMDgDQDDaZXZfH
OFapXZOHjvH5LWIPK0iGBumeegSPi2nIN5bRczZVHXc4OLbhba4OBrolgBZNbNoLgHi1GfHTWzK7
obJoBaJUNMBQilXNpINZH0BlpQjgJ3pXenbDo3bPo7dvK4Jnd1hNd+TYBuBQCoBS3Rorf8CLXHXL
XOT5XsDoB1irYtoDHhVgIIjJGvo9dxpBG0CHXUDRnZfPbtmIK9brYdmECneQJjjuBACHb+CbINV8
nSTzJjHTcxGpZTHXSgSGnTIzI3qpK5F/Gs7LZTdeBBdVb0CkDLaLXbXjalfdH5c4bzHFiyfXprH0
BzINoPrzrlGtGfGyBRILrq+nrxrfpsjhqtHLZRGzXCBfdRb1XMW1oKIoBRsJsMDdsRfbfePSWmPr
snVzpdhYBfdDJmJzsHsKDDsPhpfcm0WVHEBABNpjbNsfgLd2W3pbpftQRHb1ujovObGpmni3p1hR
tcCHt9qzq2Dxq7gjScDTUoBACaDLm3m7YfnNnECKCYCZnMIdb1P2JHlIBAegIdv5pjdto/pxobmt
p3qRp/qCBRf9XjXnqPp7XVqVqZGoXBqfPwO/WXpro/r5G0Chfzh9q5mHgjvhZeDprDvrvxrTb/vB
Sgn8IShTrdprrjGvs1JNs7OjUfxfIHwzW3tJbRs1sBsEBBthuHtluLffujxWVWJRxxgNJ5xXxuWH
xhW3tPXppcBxt/uZM0ohudi2BRtVs7hBkLshkRyFuJsTfeOsRSsJdKBhpjlKLULXyXG0IlzZxXs9
zjx1pyBRt6BaopeDtTyDuFzLtoI81HnAzPtyU7bnz2JsBzt/bzXo31H1t8JzaECnkDYtSlZNgEJ2
JmIq0GLWmEZ4Bb1CLXVOX+ONZ0N+I1WFNUTNPvF3WPbBWVzhIVWaIQ28IEJyz6MjKOIPGnrjH1s5
G/SlUCICDWVuZHN0cmVhbQ1lbmRvYmoNNjkgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYgL1RleHQg
XQ0vRm9udCA8PA0vRjIgNSAwIFINL0Y2IDcgMCBSDS9GMjAgMzEgMCBSDS9GMjIgMzIgMCBSDS9G
MjggNzAgMCBSDS9GMjkgNzEgMCBSDS9GMzAgNzIgMCBSDT4+DS9FeHRHU3RhdGUgPDwNL0dTMiAx
MyAwIFINL0dTMyAxNCAwIFINL0dTNCAxNSAwIFINPj4NPj4NZW5kb2JqDTc0IDAgb2JqDTw8DS9M
ZW5ndGggMTQ0MjcNL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0KgAxEBnBpCLAgF5HKYygZ
zEBFLANGIzFw4EA3G44FwzGMWNsSikWjEajkWNgNMwNOMSEBpEANGYyG4uGsMG41mY0G0MGQyHIu
Gw5GwgFo0mc1G4gORlkEVi8ZjcdEEfK4qEBupsiqElEA1HA0F0MFs3GNAGlKpkTp0jqMeBpXq4NG
EXHIyFwwoY2GNiG91tFvuIwu4ws+CHI0gWGGVDuZrgsHhJTGcNh8RGY1wVBoc3ig1GkMj4zGY2ml
SG4yjVfEEn0dgHMX1EVs+smt3m2YF1+1g3sFBkU+Fw0GcmmE3sI0s43GeC5FD2mZoUXGudz+rlFy
EFzucCx2iGoujvJxdAmNTmA20gyGGv0+kvUC1g2md938hxfW0Wd3mwkOn/DLvA1T2vIhiTpS0S7B
m8SyvQtzRp+vb2BlBgbOIGYbsynaLo6iqgv+wQbwrDbUq8/8EwWoERQMgoqAaF4jBis6BColLxho
6LtBBGzowusAZBqzaYo2nQQCoj7BBgwjstyxElrqxgQMcFskBrIoxgaLYUCGOQUhazAUDyFL1BQO
AUr2GAUCpLoYzQIoUuXLQUi6KglOxHLuMehCFLOM6HIgmCaQU165ioIgGymu6LCoO8sBQEAphTDE
wDmOkuzGMs1zQNtMhQOc5TpF0YKHGaUp+4bCuyEFTNVHrwP2G4Y1MGsqyM7AqSvQlGSyIwUhoGoU
DSMo2DIFomjCNI3DpY43DCMQ2DLR4yjGOsuQuFFoCeOAyy4GNfjCOlkDPR480oMo209Oc6iLFoop
UliXKyp6SKkr0fKIsizL+tStXmty4Kwua+rsvAQL0vi/KWwGAIGBoZIov2HJmy6LJwsrlrE9SfxD
fSQ3ktrzDMFUWVChlSIkwS91S7eUIY4bSPWodfO+4bX1rREkhghlbrk21ZyLRktDkPI4CoIoh3Hc
tzhSKg1OwFqypkmUi0NLKjSqII2DFbY6DeEAr0ijQchQMIUsEGcwU/OoqZEFAmDehwj2/t4WBAIY
wjYNIzDeOQ3DSMNVMwmOl6btYGhQKA0DeN1oC4FAaBgHAuBSEAZhyHIWwrJIQBBwYG8KFAjDCPAQ
cbx/I8nyvL8yGPO8LLIkCoKgoB0F4Xjv29Ip+HAUBdLehjpaQXDGN9N3SBrSORlWCuCs+XLvHkMB
c3mao/m8kxnXGeqTRfDCkMo4DkN4yDqMdwcUEA3jMEA6DQNKHDIN9pjaMtkpah1tDkNo0jp4AyJa
G4EAd3ErPfQHJ/4IA4BhDkHQFznS5tPPAZ9mqhnrM5Sso13zRGjAgDCG5/z7FoQZaK0c1Ybwztdg
UtAOgcgwhkXNAoNZDn0t1aFBoIbaXPMigq9hRoU1yPAXO3QJIbnhhyDg3tb4ZX/LIfWGhaAVW+v9
Uesp4BDoOhkBe3t9EIIDPDDqG4FsOHXAohWsEOYLgQNYDZFuJ0BgxQsg9ByOL4HxPkDoVcML84rF
LfXCyFwbYYQygMUsM8YXjOFgqzp7LOUSvcSy+54BS4Px+heHKGL6H1QgDTIMMoc1tPlDSHZaDww2
wJb7J2NEYmRJIR+9toAQw3hwDyHINIZw0R3C4j8GKsXLAgDEHmGjQ4RtIiAQ6BxRC7GoJw1NQ6SH
rwXSyFZMySTcrXbKeAFAcg5hpfODQLhMQYg2BeEoKoTgXuWhwusBq7SVkCXgDE4wNkiA2Vmh1UYO
SKFiW6aQ5ZFmEnNKADU15HCfk9NeVQqxWF9seK4vUsK9waoMLOwmhZbCuFUMCXRgZeWUljYQUxf7
PEkmFSYYk3J9zGp5MiZNPplSJT4ekfsmp3wYJVI+epEE+CuzhLueg61OEmMUW6h0pJ6iynrqEd8m
5Z6jHHIZRGpTUkr1NJiZOqD0nII6BgxYHBSaroYSrU04SVavzwBBVOrZwSM07qUZerSDFY1sekdG
poOES1XBzVus7DWcwRq9TwGFbj1IJL7XJyxArBk0M9XJEJSa0F2npX874NkFVashTKobVrLFAYJV
cn1e7EqzKHVdbpk7EnVoia4HNRa+qxtGjEipPa9qxJI1KiJZS+mvJPbSCNVpd0BnuTO1dZLfk4KS
rEmYOEJ07LKkAs6V7kIpqFc24JNLUW/J2QK6JyLfW4RvbO1ZYbpm5RLdEmRZ6Il2nglW7Z970nBr
1dC8KsyBXvK8Ra6N2ad2QtWCC/Llb9vSqlS8mc9KhF2RDdU9F6C92xu1eGehr73g4ByQK+WBZl0R
IpBa6JXrXkUngjK8JzadkUMuQy+RZSdWjQmYM51L2LW2xaeG/2FTwA5rJi2z6saj1exaTG5+MDB1
Wx+kRWJhqIldx/eyvJuWUk1Yshe8Bgqu45yiyXJpN8lNQL9kdQLFMdVmvkYI1FT8ZsOxqkg5WW0A
slwpk7NjlcLESzeDi+uLaI34zeRnIiDCa3+zqajNhfUq3QzrTLFph72ZvBzhTJTA8u5NnhmaZJo8
pkbVho8jZuqXkUIxehH5d0qknDRS8sByMfHfJwUMj+HdBFINyDgydu3LFAInkpmaMTrS8ekDTMB3
0Y4Pd0t3JVqssbD1AWAHCIr5bDzMWA3mImNHC2KUDQWvAbU12rlC8BP3A7VORsK+Gz9x41VNXomu
p2CbNLDugGWpypa8chnfU5/reGH23syl5Gj0YS3e9KZdvMAbpNyevGpGk2Y5ppmjC5Fa40zPBpbD
tqNQnquPeG8+uCw1uvkaSvPCiwsbtdYrUB30f5YPTcviE4cgqxO+DirvGgYcixwTSz/BMK5M2Ar7
aqFc5qx1OUbjWqzralt4Tev5P7V0H33T3UGVKfa0I0j/Ppx8REkOnmxIF+NGkbnlmzWRr75Eky0T
W9VceBQW7McFqVvEY45wR1/sZd63dr0aa+6Ojcc4g6/3nHGSp88x7mknMxFDEZMI0XjFhne29dI7
v4ihOzJ9zMvnfT3iDS5E08fu3h8tQeR7/3NEPhbgcHIrf0mvjNzKJ8BeLQtfGLJAyU2Y/xJ6mme6
fxG01aZ5XE6Vzypp6L6qx4daD3mdqdk/PkRb4NT/iWirfWqoRPzkevqpa9WXu2oJNoiqas1TZd4S
+IaKx1fDDeo/H7KoFdvknBsrUA+XSSaaZrQ2aXf7a7biuH7M2xk9sEPCakkNHN2DWv+FutpKewDK
zOjsMviOlq9mQmGk2CKttMoLrOmOLMbrXiNDTrdK+CZqtrfCNMPKtDSCvsGQRuZwSigPxCNEbsgj
1DSDpqhQXNHQYjgsnkOL6QViOPnN+K1q0DSEYwWiKuYwbkYrfEIElQbifPfCNvJq+HkPnNvCpQbk
bvhvlGpQbjMPpqAvywtrbPiDNQVjpsGGNKwi8ObQurlPjQZL3QHLvwrGfQAjwLAweJwv+MyvjGzO
6iZDcq3PbJqLXMlOENdKgC8NQOptjw/t/OprFt2KusiOpuaHdMzOpuuGNQ2CaupqfN2NoxCCwi9P
Vi9RGiwrlteHHsfOEEiN2FuxLNRP/OujDxXpdsHwOLCxNiNsUOmj5RStUPTJ6RXivMsN+PUDYjTu
WuujeRJCKstLeK7MwCfmcxFjCMzEIROqXqCvuDgJwKfq+p6L6iONYtRq+C7P2Dpr1EmxAsNjRCuk
hDUKmLAt2xwkEkSj1MTLFx0OvRdx7iaQVR9ELw0PIrKyAQqx5DlL0EhMePjCQvURxNGieR5K8qnx
xEQyBOAR3LmsAK0PIr3RxMTqtDOx8xxGHPmR5DprRxxJeSGDSmKSVEPR+r0yMjwK4yYqzDpqjrvy
OObR3DFSQiaMKyenpKfR+s1jpjBL7vjGNM7i7J8DZq+HdO4OAChmMtYtKKAkdQJk2MfLIQ8KpytS
jCeygKmQJieypCvKwyykNO1qBLQQJjlymLOLTQJjPsWLINfSsjMjhtNDTwoEJsqN8O1s7SqLfk2M
iMER7LfjFyuQLy3GLD5NNDPieLfnKzDrxTJmLOhO1iJx+TKO1NEjXkJiyiOswCyivqirfqRtBklS
vsqQKs8LvkVj1ESSKQTDJqbp4MXMlJ+KdPbC1HHu9iaDiEJp8uVGHP3TCMNusvUiNzExzJezmEFQ
YMGjePFkhysrIPSHHzJi7NuTmCauxQJR6swNPS9kJx6vSMcS0zuklOCCOs5zztrN/CwDRvmMGigz
5q1TUMESbt/jMQvzqNLOCDPT9tetyNsrEUAsfDev6TxHpSCN/z7LILKNqscSyTut3uNTOQ2rrSEs
ENlxvHkQKkhChR4j0yjDRC7rWQhS8DpsQTWQolExwsQD7wbmcsJUUtbj1DvzoUcsxK+UeTl0fSIu
XtX0UuZ0iNbSUymr+q0GZ0luCx4tgMkx9ChSIjXOYR3MQUGj1NlUs0XCwtGqtNlRRUwDhUruCyUj
9PrDCLySKNPUaqaqeqvUUxIqtOTKyEFC7yvK+TaR3TbOiyoFAyKGJENTcSuqrHKyhwPEJtoUjQQE
NTfNlM/yUUoysjXP71KsE1LuC08j3OhSvjXU/ubTUNlCOVRjETCDe0xVKiOS/LYQSVKyzVONfU6Q
hDVVGjg1Rq41Qio1EwhK6LYSF1ZOs1crAyEp+ChyvsTK11NJez4qZELjbUCsn1pDCTprm0R1ISyM
qOyjRxmzJsyVT1KidQvj11Bx3VCkCgGtSziDZVErcKfTcMQU8rIM/zfMTSCUj0azfjy0wSQV3LuU
tDyVXvDSRmHmU13FTx3EfQqi1GHRwiwGfVljwSKNoGN13R/09O/2MvkDpqaM12KHIU6OTILV3RXR
3Ncy5p81ojvnHzw2AspWPlAzkygUcNVWamN2ZtfT4F9zNEADkTJmHxNEADl1VDwKfWZuZ2enkLUS
FESzfD3ObyHyaqeUULcVTkJjSTqyZqBVlQJWtzIScDguv2tKsSUzMzJwZUKWx2IS3Wm20OIzQqeC
Y24zDSsj0z2yVOGWwFEyKTRjqkJ0eO6ySTJqlW2SPplyv2XN0RxJ5UEqaJ6SZs7S5toQ5xxMqy3O
g0cCyt8VckY24q82V13yZ1Nkr12zcigtQOPVTzcQQLvtYOkKfzckFM7vEyiTclZxVTmysj5xQRRS
vrkzNDY07EJrhMMjgMaEJvEubjgPcS3OEN3OlQlkOC91E1xS5vEu/yjlA2e3byXMqMAXjNYyEmoX
qXhW/trUAD5tM2xtZSyD5nk2xu73eyhx6Hn1X32V6t2zJrk3CJk0xXxxZx3EEw2SvvEjVR9Eb3si
wl6EhRNysiSWnC7NfPrEOCdX7xf3ly5YCRdSyQOWkyFNiKpj1RmscvqQ8TfMCzAjxp8D4CUGRCe1
gU6D9CzqbyxC+yEjDNiPbSxKBU8kQMXie4KVqjMvvyxN33rsvkdSxHIUcSkEfrQNE2ZDlyeCezTV
M4qxh4mLcYskQT4TYXwMnPmTYX0iJqwsW3VSZjR4wYsXOTG4rvTyZrI4uOC06EGUs4SXOyPLcQtY
p14HpPkY4i647iKsk49KT083O4yTTSRr1P3sWlYX91XS3K208ulTITfNVXtnHoIy02XW2ZOpdSsm
Zy9jPMyP2XFuQqn5OjlzUOTOH5Wv73BEAr65RUmwJOdqrZb3DU9sJZRM/1cgcLO5Op4UAWJUqZOn
ISyT6PuZi3A1hVm5W5DwJCwOZmKZOijW55rZk4jXKnnrR5Oib4LCwEY5WDDGCVcpWiujERYVaZnT
R5cYN1xjkYG1GQdSCZ6nKy0wOF6Z6tfW5jU5Q2JUYEJxpS2vcObTCKCuDaEuhaDVfZ2T6S9yvvqU
v56pdyyPqOyjhRmz7KCqZaOrKWekIVM6OtqaIKt5sMTKs4NnLL0aOjFzpmwqvaYrl6XPZDPO+UEm
w5ksNtZXoEmaaymjy6U5WTEW5kIX2jPiaXJYSYZ2BicSn12jxzB2GNRCk4b0WU6VMSn4ZOvRw0p4
0QZSb2iy26vi9SUtVMB6vj/WZjfYmWtyHOXwbaqueVK4wOPUjHkLBYWtqVKw2avsKRwiZkf2v7BZ
TVpSYDxj2x3OER26vvoQZzhS/EbYHGw0ajxlBR3Rr4yJ+Wftz7D7NbQDgrF6vjEVEtvLC7IkiDpv
laganigUv1FYc64iKuB1FM7Ki4WyHQzx+Q/Wl7OMBYmCZsQ7hENCemJURvqZqKDUH1bQn1Gaqw8Q
y6sDrQI6v2FlZ4oC3GHWJZTZlSgvbSVUBVpDhNZmG4qp8U6bCiMKf4qql10uIqmYtRz1rGfGHDmV
x1rDqqp4qiZUcQQTzYqrS75D1zQ4qqa1E7C62DgNHDpictLbnOYSEsMLTcE7yrkrC7/GUUyjhqey
qb/1/cPr1kdb/3YcP0drQb/kRbJt376MyVoup1n8WUcCSN9b8xQ06QXYA8CDo7Jxg8TEqSUjU7K5
rWdCdDgjVYemH2Zckj0CeTj5hqyckkQ4yPI5sQTILYSPItbjPQTUMiejO0y8krlcrubZWQTNdcuc
lcqc1YmMTZw2t7dsQUW8nt8YSTn80rOLESxEK5dj3az4fc9tliLc8u2Z2OPK6SxTK52birTSxDhZ
sb27f4KYEijO2dITuzodMJl4h5A5dj581mG7NYEjcYINSb0z6aQvDDVYbvlcyQqCk4elTaanda6x
pUQbtre4mDUx/jcCZdDdSN+ObjcEH9e2yLRjcEmiel+iu9lr49h2kMJdjSg7kjc63djNBdrjTqvd
gP74SVt9nqjy24emJSCKIuQ7iP5qn90jhTQw/CMdlLqbRQa9nmBq9bnCY92pkticcmL974G8VmoW
kja2tcTL1dTXO8Qzld5nmS/UUjD9vDFb6XLdnsyNtGHZQdbLxdhGHD05sOpy8ePuHZbbij9mIqe8
9xEcV7lZfjXcQ7CsM6OsKKi1vq85wxzGN7/Wt584CrEVvzl52v9+SCfZds/WYVvi8ZbTM8QqlQ7D
PKj98kAaDZ2DM2+bvP56YMVS8bxtoX5Z2j5CeU9K7ZWTTcBtlVWehy8b/DXc7KN+geYahsb8TDXV
KamDvcV+3ZbT2ebe08qLL+4uHajrY+ktoZ6UmcQ2JRz6YxDU9Ee52dWsg7sVFPydnzlDzN3mUa/j
a6VKf5RO690q8rEZRWdd05h/SMyeC4u2YZgd2qJLTZi9dd0lZzQ5lQAd3TIeeZA5bDUpe7xj3Ovj
PdfebW15w4QcLnkaL4Qek0Raaxb8EJ+ZWDU3A1v9m52ae+k2XLZDPOlNOeNQnr6jcE2cEOTC/ddw
Y8TGZrO9gYDb0tc9lGzWy2ixcdlsk/wEb+JrrR+cPiMr0AaiADMXDGCCA2A0ZDMcC4cjAYiAajWB
DIYDMQQkci4YQ6IRIXDIaRaMRocRaIxMZxYxwgZxkYjaHyePjIcReWx8aDWOwKXjebRmUz6ZDCdS
szQiQwMYyYbQIajmam2kDYXDUYTUajaqDKdQeQVQbjGdVmqDQYjKDUgbxoc0KtC6wxcaWuW2iyXA
ZT6QWunjmIW8aDa0Su93DBX+txK5WsbjasW+KjbFi6YWMbDUXDiH4S5i4aDmY5fKQnJ2a/VnMVa/
YUaRzUZ6fZy6SW/5gaDTJjMb27MS3cji7aIZ4O1C6FZbMDHQaWs7WNbrJ0/JVkaZmniDCR4ajex9
uP0S01yBWHu2sYXmLx4cXOO1QcjKH+KGDe7VnMjjYwga9WK1j7Bwy70v407/uarjqrO/yqQAzb9Q
QrT2sy7kBI+98ItA1b9qqisLhy3Dsuq7kCPM/EKByxyOvMGUMuS4cIuBBquN63yIqoiKdRkj4api
+y8txA7MhtAjMLaosHMopqOswzTcK9HaNKujoZIYGqaycGC4NoiMphu2iuSxKqhBrKbHLRL7PBi/
0yO27D9SwrkpMosz0ywgj6y4886Sg7sppKvzOIzLSPBhJKQUCGj6omHMMywGCQp2qr2OzN88pk7i
RKtCruoE/EcUy4aTI80CVTc4z2JkHMDU+66Iv4sU9BnVkNKvP9ShnJNWpxPSaP86qzU9OqUo66qY
Q+pCeKWv6nKgtI0KRLCmBizwQKkkDkzYiKFponyvNujSzr/aSzyapEiROjqFyqrqkIWHFZWkmjwh
ohactwiMsROiyvIUyiCoitbbslfdtS7FMkTNfiHOm7zdr03TMpBgwbuWwmHhvQmDBw8CEr4/eJBt
H+H1vMS1q0muKvc/2AJqhKqSFHi+Bg1dbs9ReJMVlDjXPf77sllrjMPbKNYjn6Wv8haezbn6Qu6h
YZuUm0bUfoTAxxmj6R4hYbUdpTWuNcNpoPZyQUazUlKrANq0QymdvUHC/W7X0PI7aUqyspFiN3uj
jMUkDqs1hdxOXvyGX9J4Yo4zjMIdHlpIdHCcoHGlMhyGcf8jFeFyxAGutTiaOywsLV8jdz/SwrWf
MDyV7Uzi7iK/tHQLg31uwWnPZN2kTO0d1nQ6gwqxO7MDG66ulZWgl7JhlIXZIqvXVBxEr9oyG6Fa
66sTqxeaP9pvCq3ciDO7nwkVrH8U0rlAfzaR6vrueu3txkuSBUW0/tuHlik0X7Wncrrr9FmH7Xoh
Bwh517PbKy6M/jeoBFwcS941sByMm3gUR99q9yPvzMooJfDHjONlR4alAJBwzAqP0tJrZWGLvcJ0
tVDRjjTn0TkWgrxTTMuWOc09uBCIbP1OccpMzICBseNeVdlkQgZmuNERsyRhIhKIOC9h27yzqpVO
nEJDyOIhMTOC4tKMTnsIoiKREi5onEFMcWXF5ZyYAxLjJE4zCK40HPiOb1gp1CGHAjKbaIkQnopG
jWkg0KxIgwiiudUlMhSBxiiEedGJMG+LRI0nOGq8C/r4PhGVxxlnNkwjKvhSrW0gyPdCjuS6QWfS
iMEW6TBq5RESODJt18oicyxiGSKWiySsrwMDJ9NC9pIHDVq8tLBZpgLSLMfGWi2JIH7L1K+Y7s5A
SqlCtJAEWnTorbAW2Z82TgpTBgfmYi/TLJTJfLh4cV0plclSmBrhWUpuWZPDyYqty/pTJCj+UStz
TmCQ3Ng40oUpkRmGU8gZyyskCLmtw/R5kqtgbMk5Gxip4H3Iek5bSEI8Hwh2VycEoSgT2SdChKJ2
03qxWafqgcbS1vRIfC46oMmIl3a2vo/RYCmOnYxRIzMSp6nxP+euU5NFMMplOS9GJ3iEo8UCb4rh
fGFvUPRU8hkYqDHAkAlU4yLqCOFoufpdNUaqs+q0DdqdBiGqeXaoKqUTT9EZKufWCcaqtKLO6S5m
xXGtGkaEQ2ec7INswZ1V+wBnz6lrJBUU4y4GeEvR+fYGLrC1liVIjktrBixVASW09gx8GWERLwqF
41bkcwpYMVax5mDBWSLhZE9JmHcsGKhaS0FCKtEgs0QxmzVFEHpKpO+rSVaC2/j00KsyniqNZIYa
SwDMq5EDpk0o+04amGet7ZYuNXTNJmtBFyodlUxlVpZRYtMJSEQrO3MBbTt1qg2smyA5yVbCFvRO
cgzycIalguKaImkQWXS6v4hx5ZZVWRmmGW+JJvCBvgwHgs0McT2YNKvg84yE44OFMeamoUgTQRdp
7Mq398C7nnnEW9NM/St2uwa8sxBxrmFvLyW4qisbK4wZ3ghC2DYknBLLhHG2MiqgxxKVtVOLWQSp
K3TMt8R7iTAPcwWJydZ31mMoi5JxGb6kQyo2YrlTSTZUNBWR6lJcwVZIyyAmOYD6HpIzcLLT2HiZ
dKqWPMBhzs5tl1mWz5QHo5vwxmwgbxL0mZUedkhaFtB1mQyQssOaW/zhPSuleeWnFvJ0NdaFRyTb
6RvvmmOLBa9Geo0dzTt0l02M1IduoFeyhakLDZ9dq/tSIAlnPhqB22tR6hqmR9GuIb0MeWn1SqXY
8xlSnZc7dcGPPLJ5dHZJGjrxOInoJiZGs17MM8hzZ7j4ylO2HWvEpAnUZaa1qCG17s0wDmUU7W+x
GWtKhsS3OhC1HRHIEqDLRa3Kxa3ueA7dLVz7SI+9I3aQd+cDzTS1V+2CaHT4LWa0kNiaQxZK8nbE
9t/6iiDQq3fBSaLGeXXOfuZ6bchX7yMzyY4yvUlNAlU0qVAoT5c0+WeWLe8um1yZRcwCMk0PjCsi
poeeucMJ0AtxQCLwrOUZYoGmy8zF0hy63vRXTq4SFkEkUKz8HBgnsssJz4r89l70VcVKOXEEZZ18
l5wdDufLyuJ5JWV2rx7JtY0OuWfQrVTFfSSP4V2x7ktPqhVazF/vWuso7y9GQXJKnIyS1diK3zTy
yjrGrdZ0xmiUr2xK/Z+O4wKHhYD0bPyOeEwCuNqncv8R/UageF4m7NtUkvEbf5TUCmyQKAIVKHmV
bBeOz0u4HN7ETapWqO38of6SlEgakZa5JLhxfqMz3wjBWP5zbJ9N/fB8CLTf5M7PJLI9EPxMsPoi
pa0sfltufnYv+lOt0fqsvIh5YhP3bW/zWhPb9iuPLKI4i+8Ji8sTGlccW5u8sfakCUQXsM0aGwO8
WJM8a9KbEh4ZKvc3I5SL8vaza9+4ePY82S4y+3E0m82IEI2hiUU5+UU1bBK6ceqvEy+2OYw6KU4y
KO2S5AQyoISXshkeq6yWIZky0S4beaUzBB2T6es82RaLshkmu6Sjiz7Bsp6TM1INa1aTIM/CINs4
6oGRcLyNSxZCiJaL1CpCHCiWtCzAxCCKURw1Iae1aWkVS5++jCWWkO4RjBccyy0WgzXA+hvCWUbC
ALynw2Q6uXPEE4GhiTexY6KnW16hXDc6SnM+2hWNa7ynMoREof9EYoOhUTBCHEOJBE6Lgl7EOJTE
S+tE2JhDeX67SnwjuhkiS5/DhCXBKVeidAq1aXoOvAmxi2y/cjyLQ8hC+/TDqfRBIQlACU4pEvOK
c4wPW9Y78ImyE/miq782OVeSqWIQDFSl1GeYmNWhktxGoYg79Dq2RG85A6+QDGygdDGbqhxHYYu6
ymQ/SRCPQ7q8lHGO5Hc4RHGM1H4+/GeIamG7UUqXcknH4UIKxIO/NIKKFIOiTIIXEVPIONvIAo1I
OKfHm1E/SthCxBmwqOmPwJwhpGYyrJEYAinBcT8/mL4OgLyfoqETCKqdeyoKXAWZi7ypiopJGNvB
8VNACLos46KV8ThJmpk78V8/4smuiR85TJQaGtIyoduisIYqcyoJbACLA7dByc/KqP3HSQQ7iQAo
PDYgXIWSWaJJs/4NtKGvOpjAg01J02yLtGeOBLmMdADKVIIYA388sKhJKvMJodOuyPeIYTmWrJGe
YSqfoTYK9JGPW/SPGoeW28u/nBERweickNPAifQMJM02c8aL6IvNBJlNFENM0kTMuMoi+IRNS5lA
ixYV4yDJE3ERLNmO5MkLgQtM+rg03MYuWL0begtN0eiTNOGJzGSMoofN6znAWKcTg4m8JOUVuZ9O
GKtAgJ4bNOaJzOykmR/OGafAWT6c5OkKu/STwnFM0JLAgoGsJIq2c9kl7MeOS1azPCxMeik4crmJ
FHQhiKBARGe+S2qnkaVGeLNCWpCPjGfC8+uLrNIQfPsKqsq8aUXQSLg2XGeI2zoywNXQYYwSqpPP
UkRHW/6Ue4+5TIWTAQDRQXnJEp05BQFCBRCTlOEiq1vAOSjRQR3F+S7RHJpAWXwWFRa5bAYcROsp
jBrAYiSkA480EIbEQPC8s3QIhMMQ8q+bG8aaeOmVSSgKjNctgVYNAvJPoQkLHTHB7NISJKNTG2TT
UcLSqmQdfIONPTGipTeOBTq7LMytU2RTG6DQMhFTrSFOPLbSqc2z6JpCfUOIYQ5M+RaJjSgPfMye
w+3T+I5RQPWXtTGLOmHQOnfTapRMfMaKFTGyKqIM9ChMMb9NI2OgDMM6nNcTIf8KeoHNkOAwrSqo
G9xVwPOKxMMR3TmWlSZSqoUOhVGsXS4i8bubGyoZA/SW0hw8gZcOauEp6XXF6N1M4rWPC49IoXSj
JF6OVIXWi6ysQWFJmzDCIsQ+3JGaM6SYA+TLI63XhQxLqxmes6K3pAWSWXA82aRLiTk78aRRKNsS
82IsjJEN6m1X0uhLQwXYG2hYUI0k9F6PfIWjDJqMYZ3LtMo4LRKb/IaYA0RLs0KvPKFM4b+jU48n
fIEOvF6Vo/mOTBlLeTlWge4XJMFXcr4KgclS+RW6gNwa2TAduK8UWUjTqImujaMeol0cqLYZ9aO9
1V0t0IeiSUbGxStCAJXauclVKT60na6JNMMPWJra6KtS5GuQba6TLaoVTbMI2My17Ss8La6VHbdO
YAbFjS9bcTnb2ZlbHPIJ1b2JfV/CEnnb2N1bTJoItb29/VWpRa6ejbHFmkALbYpXJMOXIcycLAW7
mR+ROMNc9dEIvdDFU/m0Y+oIRdCardQMMNXdCctLqXbC7dCK/dcVTcsuTAtWsKIL1dCLPIeJdCxc
4QS/m56RcMJeAm1WtPFdKuSuzOQRxdsiJOGKar/djLGeoRRc4ctAWUCZZdiOhWsLa5BdjeZSgUJa
iyJUYLFdgxTUGR0RjeA5bSgKDeeJJU26hfCt+7jSgMCdeQ9UbS5WGbuRXBvLraa5LVWjFSgS7c3a
eKhUinNaXNcMZGmKfXO8qLpZ5YBWZNcacsZS7geWpNcywRpgFbQPDVhKpM0NVhXPdZuJTdApXW2w
XajVndGUJfM2PhaMYuvafQbJmKaPjaeMdAgMY7pdWP4l7JmM1WxgER9JaQldKV9XkpbR1hTHOZKs
rgEYnKgN1emRDKCIGTyRWkQetKqM1fmnjY4jibnaMnW6jIZFJMMxJZlYpd+msjIXVYkaVTGMdX42
hdAbrhaOTKbTGJDIeji2jdXWHNCNs0gRXWGRpIPdPknVTkWPumHkApnLIsjkItbAWxminTRj5LIs
Nj/HNIeZc0nkwSY/mQXNlTGY1KgPPctDqc5JmctemhRl1JGPJdKbrjnYBQphCLthGqEhIhMiSK3D
LeA0mKkx2QlV+oVmVb0POg3WKxcbvmmM/S5O1cHmyOHVKJ4YxmmyFU3BLE1mwnA+/afZjb2bfTOJ
5nFHNnogtcQIcyrmRmsJ9b2lXm2YuNxb2N3aTKsTbb2IbbHLFn/n3fLSqpixZoU0RiiOba5myNdi
iyLmmIdVKkRnEnBhFKLoTozRnhTCxoVjTi8Q5oKt3gEpdj/X6L8a3C5igtUJrpqtaJFS6mcBBp0M
1dgNsujqAZxdW+GMlqAQmfKoCItqVqE9YJ1qBG3qOJmJ9qniLZnqdmyRhiqMyOXp04hj+WIpRp0M
uTNgE/9p/my0bq82DrW2PgCQfq3BZd+QRrKIqwdq8fQpqxdfNolqvryLndAkQt7r6MFiKiqThr6M
bctHtaFryPesJZ6JTq2LBgg1PqSUIPvp41zsgPc9xZ6JLsCPcztdW0PrBs2SLdKJdGma2Pc/NaOP
htJN3j+z5rWRsy5aOIVs0xmvgRXeRs/M3ttjLpoKISpiKrgesa2s3fCrgahuZN3k4rgI5uiMbfDt
RqluOdFtYSgIfuiZBumShq2NSd/aOnDsgN7RZtktduiTSPzSYoPU3JcXJvjsrSqeNnENtHXcuUMB
BvjTEsRFtmwtVWrcuOVcbu2pLwOfBvjrFgywWVrwdJlv7pbuOoRv6PZmauhmRg4VJw2N1VKYAeTw
2TDvwb5bgLBTOsnI/mwQXxWaHats2PxS4QWj1w2S1dCerbXs2S7TPtyL9w3SoOkutocLKeldjUdx
dSjyIsibuKOiSV8z6JhkLAzb0si2tu1ArJLS2/ua3SSLTPENHq2TWh3m8Tma2L5Pxna0DpynDOXn
sjzu/ze1fv/n2PXuMMYN9oxGLzcMYMlb3MZrXh/oJn3J90GbYOJb+eZzS8Jy5biLaLR0aIlbgc2Q
n0mnta6N3z8bRvhbiRR0msvbOZt0aMvwSTAnt0aeqSNa6MD05q71am10aNB0qTRuM3oThow6hu1g
9zsmLsWKue5yDbioXrWadYZmx1Rs0XoRd00TYhSyrwS7L1vKt0UUdVTpyIJaQpSiS3ubNteaBGDw
IJxvJOXzD2CNvu0bq5UIOiS0YYia2cF0LufzmXxw0ZkoDzcc3x4zPCBaGMoeJIjMP31JPv+cQxdq
2dPN5yudOY93+rMq+aec2l74eRQaeccTz4ePB4vw5rWTA5Va520PhsgnrcH5FzRbjcb5Ea53/ydo
T21nT48W/bN21UAL6OtoJ4OYbSqzOg9mx3pSqYIXX3cUjS430XB6IPhUipaST6II3U2aR2QwT2r6
CJnzs316qs56mIbS4f6rd63acXoQt62aDZ6QD6coptEeZowacq5aOTHxkaQQt3+Ip0Li55Iz/ox2
9znt9JKWcae2b2MPuhbyul5rWzOkz3b3wXVp/20erzN3xsWLOkXoc0ORcJgnwUf6IMFpp8m7lpL2
P2yTwLR62jJ8wLxocL4XB9OZBw/zeVvql8mk96nv99ZnPzesd8aTJ9cPMeJ9Z0BtUXP9OzXw2Pfa
F8mu3pKQXtd8no5x6j0JhBKNpxwkz+iI+XBowQWk9+tcjtV2y45+Asmc/+trPpKrhrALEIHaL5+b
5u//TQL4EJP8aNtb93wSF87qH9cUP/w2z2GywBsIAOBANhiNRcMxoNhAMxiMBcMBrCoJBhlCBAYw
bDIcMRmOYHBRcMRkN4XDZCN5JE4eMhrJY3KRiNBcORnF4zJhiNhpH5kOBpNY1IYhPBcNhwMoWMBz
MxzO4JMhoNJJGBnShcOIZRKVAqrSxuOaRBBmLhvI6TSxwN4FYoPFqpVqbTo5DxpHqCMRjMBlZBld
pNHZbBL2M7LNoZY5FAxgOKuOJabAaZhVN7GN47H8ZKJIbZuNquMhjA9BIccIMgM5ZMxtErmOIJpo
yMs9HI/lRnLdRnhlpbYNqBshdP7DcxqNIFVOANeLteDaYXwBveeZxq5wLBNbZysNI4eOY92RzJNQ
NxdFcDc7Fz/IM+xxPD2/INBlcrGNRxofGLhroez8/U/TeLm+Spti8ivvaxAbKQ/IbPewSrhunb8v
avaIp25CxuMpyrPsmrToqtr+KshLfsQ+7FKWGgYRKh6LBtEcVu2vYcKPFDgsW569huGrvxG6McqK
30bR5C7Ywqn0bQahTUQqqMbLU6smsCqy0tC5EmokuDlyZAC1pMxa7BkvYbR+giHJHAkuMs9qHRVK
KyNfMz9BjMMdOXOT0yusiEo+hwbhhJcxLIGCYT8HM3t81iHBwj09IjLyHPDQMKhg/i8Lo8VBJ+9o
YqFKzY061EKIfOjYIYpYY0ZPqDhqpDT1SosA06+UPNihyOy9HTX1emSOLk8i0oFV7bO/WDNNgNCb
pkstis9WgQM4hjPNu1iDJix6bsY1ywqsmNhWymbUMUxjwqBOlSSzbSWJLVC8XHQaaqpc4ZwVd4Zx
rU6irBd6zNQjd7TI7c2yFF7GBo5cPodBsRMYGqlOfRcd3eqNM07SsNsY2VG1A8raYLUkJNGkSU0J
Pb8BlPztRe+KW3lbWPIhcNaoYxkFQ2gy1NxWCo5vQcl1gkduINBuW3AhsRaGmiSvIHN6xfnDXoZY
E75jRjjpvAzLxezwYT5qSyIixTdbDr4c67sT9N2w1Ya7ETPLVczGI5tyZyRmiT248m57XjKYsU8j
dvFoCs5W4IbZ1jKK7/IMi7vlDsZLQ8JVghvIMY2/J6Y/2PpQpF5WWvqP2dxTIMk2KZOK7DuNAgVo
tRfUvbfE8PqWvrz170jYqWpTWLHptvtRcmPNa/3gz2+k9tw3b9BzSzbc82ODXu5iyury7ErYtUw7
64ffOk5DGa7YvcUD8KfqIhDf7lpqiIjjfjXEp+wfKg/mqI13lYNh/5UZovjIDKITR/JwUXExbq9s
4LoSVEQfe8s+S1TSPWVYecgxCEFvLNBBBVqMjyr0NEYhCKplBO8g+qyC6nWmlORAwc6qnSsHfhWv
s5CnSUOqPq341ENCwogP3C1WMOz6lDhmUVJyCj6nPU7BuIzhokEHRxEte7/jRkQiAeV+y/irnyhK
bdiBRSvwlOVA0hx9oSlGUDGOJSIF8MoeYSlEDTV4q2iJCpXptIsI7LWfM8rUY2FNh2VBs5yHUPnQ
U4BVKyCMlVKvGkmTXSWuuVCVg0RMiGH4IYVds7NjgnvPYXsvBEo9IvU/J2AkdCySWR1EWPRKDcHs
LpKBZahzDSujDJOLKSyESvltHghcuWHRudRB4qkuWmwwkomKXsFYQxLO8hI25fIwH7lms5Spokxx
fPYZ4wRooaHGl6tONLKU0r0PLDtM75z2EGmaR8rzEp0xePOUs28cZ3m3JguQGkliezLZ2viXKYiY
NMBuQqYZY2pEfcA4dUzr0GmYIeUahaM0akEYzFo9hYwYHDcu+yi5QjWMNbVQU0k90gy4LGRUuS6p
LUnT5RQpj/pXGyJhPIgsvTETIIIUtMhQHXn3P5GxQko5LsHMCaMHChKFqdJZKAvagEFyXUJHkvZ8
6eKRNBNZVks0/UQQUXtr0ij7VSbSXaRRhIYIVOXMNM8O0Klql6Q5QkKq2snKWU2n6FVxHILRUirs
mzf06g9X2fNf4Exuqm/Z8EmJQUYNdCJclE0QHzTCqiJ6IF7nVVRZCIM9C+x7p+WOrpz6aRVR2pme
UXJmKAO3PIGswJdGonlN6TSdLJxOjzJQ1dq49zGP0uK2DHY/pBswSEwku4QnIQMxJBRnj9kkQ+eQ
1ceZtHaPyDU9hom3zYO4YSHZnlGSjdXXw7gMEcH5IhG48hi2QmeOuaJvSpTkNvRcdwnLJ7mWtvcS
FepuX60/b1Mi+MHb8mLUy1yFV7DvHPINZC7xrzkLWYIdxP6rjY4Gh25dVVzzyyZs6X1TLGa3IKK8
8p2pOjRFeLrbo6MoMUFckURyN1OppHsjG2rERwTtVqJmqXG5spe1KZU8tQ8lokvTQUzW+EiYXHSy
PHup9TUYyFKvbmUhSr0QEqFJ59lyymVky1d0/Rlpe1NsblwgrjXXsXNFguLh7IXKqQUQZVtPIaWV
IpIeYcScbR6ebnQ8shI9KtqeouRhdGiumfSaSWx4TQuunbWIw9Cyl2trOSG/BpyOv1qYyCXrtSzI
KhRm3TKhHVQowBIlclV9QY7xcZkHNRYUTYXuvqosnqkTDYa/FQS0pe0g03danjNcQqCR2+/WdR3V
F7KbLhbUy0QEQlatp+0SzF0weFCUkUznhWLJPWR4Vn8/7GXI/uy1bj2LayNDy32s0Gx5MrlmU5a5
Lr0J3pitp35LnFyecEqRA5Lk6xcYOnG/0azDqm2E32dZnVTyjJdP/Ab9FO3/q+WcntP8TzGQ+jO/
lO0KzcWTfESWJZ5t6YGoaJ+Pmo5NEmZynSclh4dN7klTuOIQlwxa1GaciEP3lJ660s+XY+N8YNGP
Hz5n8dewfH8CeTIVKb0Aorm3XsS0wRTp5vmhnS6qnPeTOF9zvwnv7BZzp3k+JTM9s1QsDHY7Q4qb
JIWldYyni43SDpnmWoJIlZxhe5H7kss5HnYjyzunISzrpK2r9vKVyYnq/ZyXk5gssoc7zw7yJkat
6HlE7y5pzMkmfEnURk8pzkqHie0dsmPWRrkmZckFlwbNlUro4GGJ/oqTWjJEaJjyQaoi0CM+1b3l
ySqpvakIwOfqDeiWHU/be2T2soL2H+Kp7VP8Kr08U0TsNwFjfdQKO4XVNPtXmw7WBdfRJYI3N9K5
7UtMKma8/+mWMo8O3do0IX9Sn+kyge1TvZ2WT+JG7mBW54r4q643yMbj0ArpBPyQL36gxwiRQxw/
D4ruxSIlD+4+rthizxL57viS5OhBb9hxThJjo3D8TeTlzFL6aRr2Llw6T4zS0FBUg8QqI8rOECMF
T35t7VTCS4o079jNbHBbDRD4qrifImZdZaI/ZtLmBWb+0H5uTC4q5mYqUJCn7YRbAhBrL9K3sCY8
h9w0Rgzn8LQ4KmrJpJz6ahMKQn8ExvS4sM6TkKpFcLhmz2i7zZzdD/bBqPJ3cNolbE7wbvMMha8Q
BEj+6QzFjMMEJwEAyzpF6ekKolj+iIkRY8qMjG5JUQ8Sx1Qry3MNMSz/Iq77EKqQ8A4ugu0OTiSt
b8JiwiQwgxo0MH6qzpB8JJZFQskG5uTKkW41biRjL2iMbuxxMCaMbpQ3xxMWyMa1UY64EYBwzfBj
KpAhBW6IrWYnMGgjZ+LWYpTzLTItMVxpjBI9inRgMZi87To/T1hjMTyRJFMdR+qnieUC8ZhVrFxF
LgbYSWZFKrjY6q8cZADthciiEf6gbs5dqoSuqhQ3zEq50Bwg8IzUxbBZMGBrotY+THAzb38NwgcG
o1zer352qIsi4gp4Aush8iyFEcUkyAAnSFxqMlbVUI5CLzMlYnMjjjrt0k0LUm5OcCZ2sM0I5Nz2
iygsMI630ky8g7EI4kcVDbcng3Z/w4wz478paK8qRP4lMoybwhBhowMoLHMjUUQp0I5RhCUSLhEk
aZAhCbSwMkYy76ZrkmLn0VCCpfclo1UGhZbfsu4iMmiRq2Ui5g8hsicqQ27fDBrRssI1ccBPckpq
bf0KMLzz7eRg0rcKrV8aAvkDigTfx3caUy8zog6O0KpCMgyIkqK6CwMbxH8Mg+wiUW6R0TRHkrIj
ahsT8R8jhM8OK6EIxNq8s0kqkZRxsy7n4nRhUo5uUoBhS6kqQkc16Magb2hy5gkW660GhgzBM4xG
8CZmqicW8a4wxhwmcS8V4lhmcJcQg3y9KHEJY+cVy7zHw26pRpychhc8KpSSRRL5Au09rgZZy4s+
Qh6L8/Q3M8JSM+g3Qiw25RaLU/ROgrk8UDw3TPAjM8RHjeVBI8U8Rg7pBaamtBbwcw7HEmiurJic
jvD+7Saiachsz9Z2pMtFj8MgUxhFcExmtBApj9Zy7wM/Q1xT8iZVpjrfyprH0JSJMhSnqDY08JYx
zs5BI/FIKuLfxDLpQ26qcmw3wyqIVCowZgj2UgdIIqT1FEIhdII4rxgost9LgotEwmQ70/hMZrSZ
54NMpMZdzuSQs8JI7iSdVBVMzfzutOBVlDAvjzNIJwNQEJFQToUV69VOrwbs5vT+wqlQ7ac8qTlI
M+Tfw9bp9KzHDeQ+MC9ShMaas9RAFQQyziS6Dt1IIx1UBAFPQmcecV7fVMoxDHkV6fM/ik9FaQ08
MurpB1Bd1JdK9IYlYhR0oyauBs5SKfIECqwhQGAEAJYBtaQJVZ4EANQEDhggQO4hbKYnYJoEALYL
taQMgBpVIgzaAEBVpwBHBaMi6J8kxGgj0H70o7EJagcWxpiaRw5UMswtDG0qQmjxJF8h9PjHEj5e
iqdZ1LIh75Iggq8MyzpDtMpFJjzCS1QjBlAwY5xh1dRdYyC2huolphwxCbxOi5km1kzMInZOjy4y
9j9WTvJVJXps4/cfY2BVKqYsxVslwmtnYorn5VqCorNdNh9kq8Jq4OYBoKIBogINZW5kc3RyZWFt
DWVuZG9iag03NSAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dCBdDS9Gb250IDw8DS9GMiA1
IDAgUg0vRjE0IDEwIDAgUg0vRjE2IDExIDAgUg0+Pg0vRXh0R1N0YXRlIDw8DS9HUzIgMTMgMCBS
DS9HUzMgMTQgMCBSDS9HUzQgMTUgMCBSDT4+DT4+DWVuZG9iag03NiAwIG9iag08PA0vVHlwZSAv
SGFsZnRvbmUNL0hhbGZ0b25lVHlwZSAxDS9IYWxmdG9uZU5hbWUgKERlZmF1bHQpDS9GcmVxdWVu
Y3kgNjANL0FuZ2xlIDQ1DS9TcG90RnVuY3Rpb24gL1JvdW5kDT4+DWVuZG9iag03NyAwIG9iag08
PA0vVHlwZSAvSGFsZnRvbmUNL0hhbGZ0b25lVHlwZSA1DS9SZWQgNzggMCBSDS9HcmVlbiA3OSAw
IFINL0JsdWUgODAgMCBSDS9HcmF5IDgxIDAgUg0vQ3lhbiA3OCAwIFINL01hZ2VudGEgNzkgMCBS
DS9ZZWxsb3cgODAgMCBSDS9CbGFjayA4MSAwIFINL0RlZmF1bHQgODEgMCBSDT4+DWVuZG9iag04
MSAwIG9iag08PA0vVHlwZSAvSGFsZnRvbmUNL0hhbGZ0b25lVHlwZSAxDS9GcmVxdWVuY3kgOTAN
L0FuZ2xlIDQ1DS9TcG90RnVuY3Rpb24gL1JvdW5kDT4+DWVuZG9iag04MCAwIG9iag08PA0vVHlw
ZSAvSGFsZnRvbmUNL0hhbGZ0b25lVHlwZSAxDS9GcmVxdWVuY3kgOTANL0FuZ2xlIDkwDS9TcG90
RnVuY3Rpb24gL1JvdW5kDT4+DWVuZG9iag03OSAwIG9iag08PA0vVHlwZSAvSGFsZnRvbmUNL0hh
bGZ0b25lVHlwZSAxDS9GcmVxdWVuY3kgOTANL0FuZ2xlIDc1DS9TcG90RnVuY3Rpb24gL1JvdW5k
DT4+DWVuZG9iag03OCAwIG9iag08PA0vVHlwZSAvSGFsZnRvbmUNL0hhbGZ0b25lVHlwZSAxDS9G
cmVxdWVuY3kgOTANL0FuZ2xlIDEwNQ0vU3BvdEZ1bmN0aW9uIC9Sb3VuZA0+Pg1lbmRvYmoNMTIg
MCBvYmoNPDwNL1R5cGUgL0V4dEdTdGF0ZQ0vU0EgZmFsc2UNL09QIGZhbHNlDS9IVCAvRGVmYXVs
dA0+Pg1lbmRvYmoNMTMgMCBvYmoNPDwNL1R5cGUgL0V4dEdTdGF0ZQ0vU0EgZmFsc2UNL09QIGZh
bHNlDS9IVCA3NyAwIFINPj4NZW5kb2JqDTE0IDAgb2JqDTw8DS9UeXBlIC9FeHRHU3RhdGUNL1NB
IHRydWUNL09QIGZhbHNlDS9IVCA3NyAwIFINPj4NZW5kb2JqDTE1IDAgb2JqDTw8DS9UeXBlIC9F
eHRHU3RhdGUNL1NBIHRydWUNL09QIHRydWUNL0hUIDc3IDAgUg0+Pg1lbmRvYmoNODIgMCBvYmoN
PDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Bc2NlbnQgNzU5DS9DYXBIZWlnaHQgNzEzDS9EZXNj
ZW50IC0yNjINL0ZsYWdzIDM0DS9Gb250QkJveCBbLTE1OSAtMjcyIDExMzYgOTgxXQ0vRm9udE5h
bWUgL0phbnNvblRleHQtUm9tYW4NL0l0YWxpY0FuZ2xlIDANL1N0ZW1WIDgxDS9YSGVpZ2h0IDQz
Mw0vRm9udEZpbGUgODMgMCBSDT4+DWVuZG9iag04MyAwIG9iag08PA0vTGVuZ3RoIDQxOTQzDS9M
ZW5ndGgxIDcxOQ0vTGVuZ3RoMiA0MTIyMw0vTGVuZ3RoMyAwDT4+DXN0cmVhbQ0KJSFGb250VHlw
ZTEtMS4wOiBKYW5zb25UZXh0LVJvbWFuIDEKMTMgZGljdCBiZWdpbgovRm9udE5hbWUgL0phbnNv
blRleHQtUm9tYW4gZGVmIAovRm9udFR5cGUgMSBkZWYKL0ZvbnRCQm94IHstMTU5IC0yNzIgMTEz
NiA5ODF9IHJlYWRvbmx5IGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVh
ZG9ubHkgZGVmCi9QYWludFR5cGUgMCBkZWYKL0ZvbnRJbmZvIDEyIGRpY3QgZHVwIGJlZ2luCi92
ZXJzaW9uICgwMDEuMDAwKSByZWFkb25seSBkZWYKL05vdGljZSAoQ29weXJpZ2h0IChjKSAxOTg4
IEFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVkLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC5KYW5zb24g
VGV4dCBpcyBhIHRyYWRlbWFyayBvZiBMaW5vdHlwZSBDb21wYW55LikgcmVhZG9ubHkgZGVmCi9G
dWxsTmFtZSAoSmFuc29uIFRleHQgNTUgUm9tYW4pIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAo
SmFuc29uVGV4dCkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAwIGRlZgovaXNGaXhlZFBpdGNo
IGZhbHNlIGRlZgovVW5kZXJsaW5lUG9zaXRpb24gLTEwMCBkZWYKL1VuZGVybGluZVRoaWNrbmVz
cyA1MCBkZWYKL1dlaWdodCAoTWVkaXVtKSBkZWYKL0Jhc2VGb250TmFtZSAoSmFuc29uVGV4dC1S
b21hbikgZGVmCmVuZCBkZWYKL0VuY29kaW5nIFN0YW5kYXJkRW5jb2RpbmcgZGVmCmN1cnJlbnRk
aWN0IGVuZApjdXJyZW50ZmlsZSBlZXhlYwpBUkf3sjCYwh7VScIDaWomeIZZAm4uIpLgYfhn12tI
IgsCFiIaa5pAWVBvbTHaBRPiZu3hdI457TeOMMNq+IrRJ9FSnj0cSuXpDtoAjLfSQaLi2h/etmFQ
wtMGSpi3xQbxNTICiW8K15w0Ef9JK/Lo1gWpO3Gw7ErTwOaAYYtlz/lKzalCzcS8U7O1RocqNUK1
J2sFdQphNfBQ883sNlltUAgqhl428bcQz59cuPiev31HzvK9YTD9PawxOhiujGv2qY92YufoFLN2
X1chySwCZ68nABW9wihkwqOq9VHWTjHA+vA5soFd3CMKCp0BLhe3617r49ACFCkM37UVdM8gihO7
5iKINCb+7eILy8et/iBBchNRH2CiUEEIayvmKJcbwsdhXazHR8wcYG+1YipOk/ehxyMGI+0DrSR2
0W5D889AUwTIlCTDCSwTlNgtP05BJgVp0CyufZNy9DT+Ed3iKReI4/sQSiSFuRYEyQWEC9PAtKrr
fJsmFjBiRxmjjV4kjV+4sIVYa27c31phPNWQCpG1D0oniC29Ve33ljlR69yJPyLb845S/cZcIZQA
jRoq56FJCyTGEVOamnBlbOYSatdFJFc4/4WUt5oDNPRTXpa0gHlMiL6Zt2bFcRgwW75+sLdM5456
wXQEvfi/2OUCPfoCDVfwK2LCqxPKZ5hspwbm4rAIwT4raJpdb5ZBYvJC8LhBOXynrfWQLsEnQiQ3
EuwAwG+DukBlMvbrStFGv7x/JrMDxHryx+HP1m2XwM2qmF7i1XylYOCGg4UJJy2tzrr/QUel/mVo
23QNCtB05oCC39s1QP9yEZa6PQuJwbzdERGCIL1ilhQ7ZOPjoPg0uUNrc/cqsWptiKNbnlQDeMn1
wDfD70lJdS67z7UV2hN0E7z1zxKTkHa5W3qeo8raHB3QO40zQzwOnRIE5G34dy7yRKadCAf1yCfj
DwCt6Ew6Gtv+QVh3u2bF0KYIBorhqGiILTVZB60x+nn4wu6Znb14YrRkV86mWe8NIuy3Dw6BasGi
kqLhwWziUILL25wFJKJjclGtdLRsxjW+0Pe93SDnPX6adeURlb3WFjZ3kDAxrAinZkuDjm8Ds3IM
+er/hw9H3ptKf1LpN/gB9T8rKzlCjCruMVeo2dP2VC3JAYRNEXDntLqTV+gpq4arvy6kESvGNwM+
7oBdp+KGxYKdYsFB0hiCti0d4vGwp+diZmOhsXfcszVeFiwrr40/AeIeRo/2pJ/EazG6pVhlKDMH
oRAfL0KMe9/VhNFZzjkqjfa8m3dZ47ZunlbYe+67CIb9I64vsTI9VKitHA03UDffUQe7SnLi7FqX
uEcR6jMJ7JMPWGOZmMkG+XrjPdmJfYqYzcnXYBChRNsunDbqjvEFXb0Q4d8oo41QGLOeootpzcTW
JZf6tKhhZU10ud8MKCnyO8tUSB82W9tlUnVZheNU4r+ErcL9e6TdzXSWES4xEiMCUyMHCfkinf/C
0Kf/rrtrLF1Fd/0G7DrC3xDhAm2SbtMCL3CGXt9Fhvqc4KvejkMZvdZcXdlMkBtNBbEUL3YcLF6k
kyPvzKTjLnNn8GC8XKF1I+QBIWt+wQ2S9w3mWQziZSq6q0H3GEK3A6FdMWMeD4Z242VQoST6yY6G
fqXSz6pkv2o/I7dtGDf5jpgudhbugwlyLImz2NyFGEZDMQrLR2mFmuidbbnUl+dZARThzSCuAJ2Y
D2RxD3rX7tvsMsiwtBh1sRUrmHCcwcC2fJ6lUqdOyMc8cFi4p+AqhO5Y+gonjjDGjd8ClT6XkzCZ
UapJMjOmlIsPcMHBx4lyoMX78xcUTHNKjkzfGTg85hyFN62E8dQ/Hd5M41fIhJ2EV7oLLu4Au4El
TfGyCkDcXO+TBInO55ZLJuGUjczAMyOoaW2Zd6Tcnyjz00E9GatDZDeJrp8/XRug1dlLsNcFZYBc
fp8FyQO2JqUrC1tJrDwAXJ6sFr+cti8eukINOSO85WIllpj1/CLARcXNaj8MMlHAztW8eLbtIwLC
jiMW5ZD2/BLIN0HZNFKZenHUZPnT3qagXXZ4IZr0daJDiF3bb07gFPaYfHBaNYVmCFN8cNahS0om
SCEYNP+N/+LvKtxue3T/g9baiWisjdwdLSaMYyHr8difYVf8hA59ciG6AQypqudqDCnE+VNIO055
FZgAjX72pWQLuYKSCw+yKLMnlHL6lFG8giGHR0M4ChXH145Q5vOoe73i/R1B7Q/D7MYCzPWA+0nu
tk6wdLz2egcIUE1pqsH6VDVpLMNLP77aAgKEadanDZ4kV0O/9JsnxcWuUJbym9A8apqVTktnjzZ0
qtrF1OZHb64Vtg9jokr8aESgBr++vGPOi7ReMdeKtWna04XvaI6O99lBrjwuj2qvL32uRVITm+Qv
Q6NpmTIJLI9vZOnI0+/u+XnvyZ6LyfrzdXUCeaTdRtTuObdYVtbck6UtJYJ8Zd2lI+rKiwv/JZ4K
ZVeggEteo2Dyn4LK1Lj+ngfbleMvUZVcg8icje7WamVJGOj117jUqSRrZNdD20ZX7a9Cs8LJp+wM
5Fptu2t5IJKutSGdvXGH2USyiC3Qk3pwfwJ373qyxZvEmtcaBXwWk88Ofxah2r1pJmcCHyBRmuO3
oIy0gm/my6iBvj5osbYrFpAy6u2GaQOqXq0CtgOxea2xZzd3H+i2wa2ttQvlf/mKaqqi0LCVsjKR
JhLBsSPF45FdJXec0SVsra41BLdgDl82YuBqNZg/nOusfNiGmGAP0RWmX3rmUcWdFvKk23UlazE2
bW82d09c75TqsDmlvW3kbX7RRqjAWiXVC0cXlMB45+L9iCVs31rVWXHSSIdrBshkX33ZQ74CsHWy
HxBHCpbStuyvYaDL2Sa6Yw9cYNrZpOteLYaGemFZoaDlmcJyR0aHvt4sTCXUbVYquH4mZPpRIII1
S47Bmgk1SBnEN5H+7QjRW/saZ7Sy/2pZ1fNu5DCPz3hPS86i7Bk6BZQrBH+jZlXDW5ZQ+gp+1Mrc
cPa5bTehBDuVvaU/tuy+7fPfPSEkQmS1RAlMR8PjgFBNkOEnATVY2irMq2H5bvbgiTjnUGOqq3di
59siV2kX11W4FMZSiqIYixikgLlY4vbjmcvkoE+8X/SCgUw+npTJlLvzZJYBzn/t1a2qeAju8idY
8VpILoloFjD+ZKXGH/WwvDb6e5XVGukgPHnz2/GY78Sz9Zpbnan5HamfzaoWoDFfw3q5r6b0WtRL
JZokIJ7lymnBwYUomaP+/Zeim9OKnPmYWF969q7bQsJaNksCiAmviS1YHAIJVOVgRLAT6XqV+l28
GDO6f/2GdTjWtE+bjsZqcBUDaibS1Zi+KaDCRnYb74lGPI3JUGk8tWfEPA1Cc+3XCrkdHR7k/5KT
N6IHyJF1t899bxzuLXzoUo458ZPkyYOs2ewkfqx++YEB0/j5XDGD+xBZfYS/Tqpjqply08wP1Z3o
zwOFXLTpY6ZZTvdSGxWExIfEH8atdH0d0TEfDvkbpp9sgdSqN6BErO7wrTkCbnjf5kYrepmb1Ipe
QclkXlzjr7xmRHsK55QT2eLni6aGVRgTx1i94n/7fpe0xmxCrITvJ5yaCPmh3U7nNKP88eu0U6rN
JwZhTKSA7w9qO0r1L+H/4Xv0TxORJ9u4jHBh8XMnfkQsd5wvN0ap2JIrffIJs0kIOFNv+gLXqz06
Mx3NEOwDUPet4VOkbCAClzUFM2HnTdXCMcs9DyBM3eMM7DiWDxjpFGo/py/Vlqs0Qoz/Hs67IHWm
umibcrxxsCQyRjazU+IWs9wXMKnspyO0786F2jhAZyUlqaXoLRwTRRI3Wyek3DkQX0IVOGVgHlwD
2VmCP7VwDQlESAosUt7bH0LEHMNeRXmvtBOqcqMNLa7fAAyZ4QpN8rpvHmD6i/61wR92QP1pGzb2
5ORgRJYob9xTP2FHSAmqURj7XcHzlNx9cMMQV765Ysi3V7PNbLPtNph8ZGHmJW1Y+6anVUWczT/R
HWOBU/KTOTvX2AR1SEJTGAt518xgDQ1Kga3ZLRet0xqwsct7/dfW8GGf4Wf7mPUH5tA830K4hrXX
plCRn8puFCwj6SJymQwTvBgljm0tXzwH3xC0KRQcQ1EDVJGcTKaCbOjnpvogH5WfhsjWsv+qZocL
oKJHo61EQC28XdgrPO2w4wYWJpTfyz3TTCq+ByeT9l9KwnwBujRbc+wrsFaF/4uRLcH4TmJYxfKv
E6II2PLsctrF2X9FSRbpfWmDzHkymeH9IbvuGBlzJKVur5JgcH6uUo1KzVIx5lVKVrsY+MeVwzCH
u5RfccNjU70nCdKIApKanJDQXkL9NNy4LMzQ2xaxv9XLWedMC4Ae5uWUXNHFBaDFRVAcc6g4OIPB
9toLY+pqD+4esm+0pOGFS37bWmUC31xWdvbqgwobleYzpECiNhorYbiUDc4c1Yy1gpXFsJ/doPQ3
UEkyRk6ZY4Y4EzxQ4hSzZK2cMP4tHA8fkIG3ipGW1iF8Rgq/8dvh9S+fvAlIFpXtZdLvbKF7TjGQ
7j9zPT+K/F633m3YBuEJof0kfwmu3y7HqwhxSlevfd08Ff6/2N4H0NUp9bX82PLyfcsORjzMQkx1
RoigdKJzjfF0JjyIFoXxf/C8auPsufUmXZkAQYViImHEh7H6oia96KUqYgxuJ2fkdRnTlC9873LO
8P89Na+yrV6frASiEvtgW13jS7GMt3nnpckvR2TEtsiPj50a2LRYe2MEBwn+7iy0rBe0HDkRUYb/
7JdQQ/b/slv0nkG3y7gtjS7SWLG7ypoiA2b0GEMyUdWTYy3iQlmQIEXAYIj6wJGBsgpfAttjpTVH
iDs6edoiJyKReZA27uOAOcdxhijFndUcxilBVmauSLeR8pZ7XME9ZxN64NYG44ic4OtURv2yQ8w5
a/S8LoTbSd26baJSY8wcgJc4PDoHs1yoxzTcFFqE+Ty+gL6XgTcoCul7vSx2d9zISzsJi+3q6vJy
KXW9hIQrSHdT5xqBdMbBCfhn3mL+eTk9JCXZZtQW2jpJgd6RIzM+nnI2Z0Nq6yeB3xC8+XgWdVtZ
rODmpJViDcDyr+hVOw7Ki/IZSGlm1vruAc6AgZjEAZ2aqLuz2ct+0XN38nQjG4s9msBdEidToj3t
kh2RyRFQ6NRP+WMUBbpvb0Xqoq1iItzjeRVtNffViDFFHxGrCUEWIwJGa7ejyavKVvs+aGthHiNC
1SdoTjIOwvqm5/kc+zpXKxUkddxSowKpd7d1vxvM6avzHaGoLTFOuK3gFlfChkc3OW7iFcEKk1Vj
AHNdq+jWvqD7FakGxgTpl2OElTrEXXf3bM/1q2hqXRcWbG2d7nSCm401hJHO3P2WOoqC4/HbkNX/
OUDiOlrnR5o1Tt4mUU51twm19vGfxuLiZZZUz77PeYz7yXvX0rcMNOhKJ3zV1Te9I3AcTqpzXRYX
BZw2hZnwcoOOTaI+QJgRAsfofKcOAyTCS5oSJkgtTiiXtiPAs3fnxRRToVxVy+DLsLjw/MFb5l3K
GuvEC1UiIhR78IljTX5yibW3vdpHTB75dWJ1roRq8zGTJiZQA4B0BxfQLk9fg21iBN2acpwmpmXE
7K1xUTNgvTaPUFcaYJOCYysfdcaW55vRu82sTWs8NCSsNOaTauzmps2g9TnIa1ZytEZk/zlk3vjH
9WPUChR9+lLhI9LCYEPGGKD08r5OG8evqhUJE5jQ9KyLeYV8vZLF+GMl4weDizi3X6iT8ax0tuc6
oNODUKZtXdZxOSBmuE0N38UBM9YtFfgybSrRt8mCLUBd4YOrD+k4scJ+RbSipIiG886unqTO8H8L
kPRXxcingjdh0ERkzf8DrMfoaH5vrsbHIB/u5n1z0Cp8qOgREDt2GiPtYea9jR+O6ZSvgFPwo6IE
YnPXOiUqCZOHrVbbCpwqVUsxsx40jEg+adTXstAFiYTmrkl1G5k2WEnmIS495gXz1FSJuJyrJuxt
AuyunQu+meDsV96eVhzWG2JSGt0zjEGBc0YYM/GyBndZn/B04QMbVu8ub6viSQOZ7UCzJLwz4DGi
ps4Y1BpyGFwVkk75MIQOfmF+sTOnvUk/Glb1ckMJjF5oRCaco3meHML4GzpXYW4Z/DWioRyoefWb
VWtrFSLLT/3jzx2oPwVfyaAqNAoAG7cZP5401uxFPu3FjjLSQ+tgfkYsh9T62xr6duDTVlhFsoH+
Nj9V+0z16DgvfNxj4rnwmA5h3M08tVShTWEjKu4g0VYr5k0//rGlRnrxcYo1SZWgQxwFgASvHChg
k1xHfOMEjlnSbmvtfjQcmZ5n7+1gNDJsRZ6YRotpyRRUj0QN08TWdjW1/LO86gsTuw0lIYjE9sLb
+fS7Vt3hvYYU/K4NGGvtg5n27DEUBph51Ozn7ovr+fcQef16zO44PWDkzRe5JGF5ZcC2d5DamZ7s
XLcLzlQ/qb04cWHP1A/qsBzRd50/Fr+K5LBHq9xeI0eWYdQOl4hg/MLWZ5O1YTgNI+2mX7pmdTKQ
Zg/RNy/z9kDzO+uyqa9vKJILV6mWkMR/eND+R5h+Y7zUmHC8qJzk8Z5rCsZZM15YdME+/5UmzHQP
zVREuHAHZrHJ0+VLXeYBND4Lv14sWa3AqQzxR8vw7apYB2ujajKg0IgvbDFUVBCZtbXVJh4JoUZN
vrstQ4cRn+H3xmRR22DXp0csr6H0n4vXmeM9Ttl1Q+I5XKlRPToVT26PRpnyCQnNNRB/9hkca7e1
UKTBxxUwc/pjBuZvIajWyflQJ7D6lLx5Epb8WAO8L5epR6G7TmgDYboyTxG+skUbdtYR/23cpvgC
WCnxxEL5w6H5fEw3zsqCNGkWOLvdykreg3/8QWXaFGYbWS8fFcC8lBitKPCbDBXV/ALDYNVo42Jk
3za5qHcta342XYONw1lQG1uhpxtmWzQDdP+YR7W2UTEnpWaSSi5zRx2EGjmN2Sy9OHZgPAvHZ3fq
Hv51opFYVe8zAjFBEguIaBtDEs9tcTfDryW3czpIf4jS12pwoacDIqyztgBxOOUyuBCMnu0NGkHE
XWRFO3qic1qhMMj33DQDr+EmvGeun9B6Aaj/cDlGAh3Eny7IstBEp1Hu6dysnhM8moC72MjA5g19
F8e/SWTi1825jXJk/d+Hk3aSt6uTdVfY4XQiw+y9AngwKMsahkmELr5i6SLTngV72mTDeA0LHhpx
jy/9q33NNF0J0p58RLpeCtFJy+gbFRy8vm3gfpkP7szk1S4ciGO5xsaWlbJ7Q++tCLXDE2ta++bO
ydoPsExhBGOW/CB3EoSWd76IluwhT5LWmeFXjCO12akH7qKXSY2NE/JH+T3070tbKxQFtUlYiBLp
ow4WbWzPMS1r8Z9SLzZFqW3Rb+SsYXyMCKhkccGNczgrOXyum2ra7okPRY7GhGmUXc1IMP1ZJ/4d
YzH+KA5FA0sM3AfA+6OIJMGTB2kA0MH6mdy9urMkclIDAhXVhWw1hXL1+Mu5zr+Z1jjVwJkvUHsL
U6VnhGMaY0kdEoYyJ+3QFZebkalbeBInclSrZVTBibKRyp3DYGuSN6scbFranN98eLEvrKDnGlJG
MnTR8lvFTvXdtrKxtAkQiFLHGqyI44XGTtppltzuQ9ywhkkbkBRdX6XoahekHzNUTtA4UhjfCrUl
C43GcLH323vyBnH8MaL1vVHqr6HrqGHx4pV3d1nqKqanxuRA9As7c3cNzVSXkryMru+jOQ/97B6Z
b5Vy5Ewp/WK18UjIb/CJKTblBlswdcu4l42CKloKRPFcN7fyQyehB2ygPl10yT4IsUPCiylc6vJe
nLYQ8q81mihYtpPipyQaUvFDVhbG0wmR88hVsVpztjUbClJ/Bz2HzK/jl6zBuJjcf7Bk8HLK7LnO
5hkYcT309QbaXBYdKWAyeb+pEQ5aRz0K//LjDwcBmh5pHJPZ6DHIk2B9+O/T7V4I0db6ASz1HyEi
S+XhsNasHeTkPYMc2NuKhl2rhFNRIxijgBXwT2gxmU1Xg2jNbTg7nZP4lTAOLU1VkhcsoiJ7BJs1
5ICWWGXoURGZB1AjKfUlEx6SNG1+wt70zNM6SYlNp4/QqpWWxj/q/q5kQUKCDv/i/O4HFjDNxMh0
a6PSmOO5M/uTA6+jBMA55oaZureR3Tqv/wO3uxTuRjbeWIk2XWBybc0k8pcNGaX4VDQzh8YiAStT
2i5TgY7x1XWp3pOJh52pSClujGpFNWuOK1urvw5bR1OjYaq0XbZdL8+Jyiw3AICMxqkfUO8cu0Wh
neLwP1tHtG0CFBS8pqAGGyl5lP7K5HjAql9o2tdhOVSvWisaDXVrXHw/ityTiZ5CbaE7UL5nHn9u
ffu+qihPgD032XSsixLXEOtA8FAACQIjYKRjoROmD9ChlzuILD42vSF6q0DSCEBNBLmiq2RhB3av
+RNN4TXWDh321iTGiffqMYJ18DpgccerSofAmsQfDtgry1WFrwzNjVuCSCys7seBnBZ5KPKV7kqB
/pmjAOBB1EJbHJZGZrGB0BR/CwUi8xH9EZW6evTYproY9+nnVC/c8nXHV5vaLjt3MH1IsEzwWUxY
P4PP7MmMQmrn/cnM2KbrVZL1DL4Sg4Sy64AkNWYyJSCPSamCju206RblcVnsTj5GHgoR3/IU0Zgx
CAI3qrSlz/mgdD+PN8cbsRR6P237fNkMYEWpz9a3/LpeFHMmgTLpagMwRL32uVwo7EI1jywkMrOB
LAQBHIwaELrf+JmBWrdumajNmBCymWBJLx5gLn8lauAAptyYtBGSkV6v/OHn4VsnselKCBTkYSId
9C+CU0Id7e9gzSRBeO9J3W6tSJcigm/MFKuwsMOf+LxAiID36yyvrtHrgPVfGwnVHatJ7fehL6uA
caMQrwhnya0BnET1kF63RavM/MISVEpeXq0cL34jqPgembKZXMHUPMKozMB8Z1wjAnAJE1Drc3Qe
c0i47+CchBALfZroaNtPhpdVeySQfahBbW35ZKOoWVtMueRkdNJZas0WslUvNo6eXx3/X+iF1pfh
hS1Pp4DY6G6N03eiDqzarWEN7KBeI3I6OgQd4o71nzFc0QJ3PQ32PV4r2HLVBout/04LsoM1gZmn
9JxFmU1Q8V2+rv7ohGNXJzMKixBFie84g/OPalwgotXS8iEZPn43U+8h5xpxukZlvCbvY84jgNIH
J8sMvelmrdB9LgJ6IwrJA/t4sRZtkbAMKFZOvT71GXvIwM9V3XfvmBltISV+44juZoQyUb+hrFht
8T36CS1Vk2JSzcuwv5MVJOacLWOr98FTBL0+rVwqn/DBaEebbo7kU5PPSfLes5KnEFj3nxlQmht/
7p2zEFkZqdDppQggOnIsg0sRSLTTFaEa3IraXT0OsIXcjpOO9A8NKNW2xyKrhbx7QxI3Y3HMMEDq
hBz5hdN1y5ANKLGaAJn56XYwcv8tjDgfmSstU5IrWKZ3nCtcVI/D4syKSUmnvWdJJAyjPmWcmpJa
GD/YqThMZv9dzJoGb2mBht9lWKOS3tfIWjhhfmbJtkGlN01KhZVelw2qJGPsefmbDWVH2vbIAiOv
D1waU7+f5YH3xtyxg2pXuFwOVx+rSzbyxLy8NXn9gZzGITkLhU2VUhYEY/jgZwuW2C4DlgYdqBPZ
Ple/KEe7NNId1xjLECU8mkwK8tvw2sxVr5NIRu+9lRS8zdy2jMZzeTNb0IDx767SIZCyaT1r3Gph
Oro3MoU5uw3xxdmkYGpoNycVFp+d0TrWdqsKuAVTejNIfywPy/3/HDde4TKIF1lvxZfvpeDWFBxa
DdNbUuPh700i5ddDZAb0Y2oZrPWRKvXOd7+02n5e0NNidGJ91deEZbXsoYDl7d9jnf3fld25/KWZ
0RhVPFslVCCkSr9XXZ+DzAV4N6uA/GqVyGqCGIzngs0276IrWYJrxm20BAPctRr7luk7txoQxAUH
TOSA0j4xJzYSFaNtVFrcSQ4x54+jXNSU6rMK3FFcG6Bi0hOg/UwRykoS0utoc9RbAFeCrB2kXHkl
Qi+OnjOkSR9VXmAFRVZkJI/ljP4jyheTIuwwf7j0wlqq8wVgZ9NEWifE4m+IJ/v8308GnzIYmJ2Y
DoEt5GiYEKGyFdV3hxzGZ0UKcOeCTk6NFODgXOIyQqjX2zOuJ45gSM/L0kJ58QQ8nOhLkGr5GdGa
r18CLXpYeSEd4pk1KkDZ1N5E74eKEwofAQ8UNMKeChGUVlBrI8zdaN5fSUk6hgmRx4gSdJv9XBXZ
YMWeeoOyWVRq7PgWWQ4NLaIzc9C+BuTBD1w30hXra84sPkYc6hapQKuT70pnZSzHGzsyemwRtub9
t2DrRJ0Y47pS1tz6UQqZ/uAiMZc0VOoONcQ2xbdoW9CW3ev78dIwUtnc2RO6cM4W4Wi4ltTPuE6U
pObHSb7DkadJNSHqWdZ/CMvhr+3BTATWHQ+7HfYs39/5O6aGz0CB7bbzDk19XK6ytutWkTOQXa85
Bbc8FurjbQF1ZTTPcml3yIbqAfI+g1EWReyqSTS4DhEkp4NuuC9A3ucf/OXZ1CczP69iSS46HRLm
GuLxX1w0GaqFdMG6trkLtUX1MbFG09CBtOJL4kzfDjo1TU2VzH/pFZXD7ipx6mhMWYHW+nVlX0zx
wWhgX4fP/BUgim78U0pgBFGSg1ebLFZC2wdrI2e+WyDq5NqyUbWpj8eiDBiysXdFcZZPrTohkX0V
1dFkzubf7HtLAhISWBdX5WRZa7RryRPw0nbOHXaw1U3isou3hZtBGNyvZhIhdZU8RRx6Kh/a9d5Y
YX7hAhd1ZRza2X4ARySIqI6TL8c6VvasctR7dG6uqiJHqNBj6ZE6TuzTtxBfLsvWs/TFC1vEPLu2
tgLRYgzUiQuNkGaO0ya2TEGN+CZjyhGHsPuTZnJlxh/KzdNuTPUJG/6s7r+87nnEWKW1/i/Yu4G4
auaX35zxpkba9MrbHdmoxLGnycilun1IZWM7Hef4tYnoLxLlB7ixkk8FcasFg3lkTAHY44ezarAO
X1i//uhnRK8xL2FCLpEVdZBp2uftnfkgQ5a9ffR3lvPqBuSaXWEKWYZiHZS2RdSp2Quz8O2hTv5l
lIZZXLVowgRL4FMqFRGKIJcMXhahq6prvSASZwsLSfPjMnYxP4e33uG4yryKNAsQtKGEFjBrITjp
7x0i8V8eHuw0nUH+6cxACajpX2gnTO2G7FsthT9/Hqin35Ord22Cp8F+sKjt97rpd7sph6GOcyUX
GVO1vHYsUb/9/gWqXzjt6FQzO0V4AwksSboE5WLPavKmhKHnswtuYfErJMgeYI0BjvWGzNmieEUI
rWv0c5xWH7m0RnYX0Vap0a8oEY1kX3KwUofDdkrhVtrM7UkoKU6p2IEqTdxSuwY7teBOp1Kg2H1/
zveRhrBvys416AUWZDNStbW0pRF4qgzhUIPF1Su+1Dhvy5I5vXLr2g4jUaVUagkijt9qQp1jFX5x
ph5OK3mxlvwaPypEk9+AYqjTDN20QVIgmm5MdV9a0FY5JAMtsT3waN9Cf4+j+XOn3oFTa2Pok8jC
9HsF9pVOQSw+iOXs1PgvrdpTjTNAt9jPCPFMtFHq+fAXMX2+qv4205ysUvTt7YRzhtcnxIw4Xluq
FIt+LNIvEvqQG3jW1ewn4F4m9bO5HqQ/466AIkQ918dmfj6lwQF2A6Bq3lLvWgHa2oVPzh2wtekh
HMVDX9rPeT0mzJlFUjJFWUNnh4ZVkZA8nr3fG5Y/ImEHhzAhG4JPP9zlkicpj+mfZTCfm24Qm2pL
WuIaVAZW1BmYYXFvEOKSXCPpDpUpzLASwbUlJBkSwAuNyDqpxT5dI3V922gxWaOQ3UBT54S02XVr
8RjBQLoe1po6hi2Tnzo1CP484mTYAhxdO/FtWuaqTosI7c1fJ8m+01tuyji2+jPn0F+tXCZNMa43
Obs3avbvr+m+w0Yc3lQrhhBCfAJ+6Dg48WQ/wt1picrHjeDVqsxD5Rf7fOTVNDOLQJ+2iv74S3Wc
gL0tgdAXWH23I/UpqnsWhV9CNcAZtd6v0lD3E/5WEoWtlwG+p30cqlFp+SQE9rFP1bYbpCnXKavg
yfc0oY+o3y98Dg3uKf3BfRYteXsUi4lGxcBaL1ZzWZvo7yQj9llbZuk0rDjYUh+I5u2tKqbd/IRt
OFIEsh1YGcM8TSP7rflvuCAPyAsEzNXZWdQLTB0wJFFkuAP9bitTATm3HgfU14BXFnuToKb5nUm3
KQCgXYySRGzp3lIkXZ3sNEazmbDhOsX0TgfJt+dJ3Xr1t5o234YDElAHf0cmRUpn7JpY/8O+YmIS
VN751OTQM5uhnms04ebRKpmPdzusKAUYcG0JjdNlR7yrdFQQz5wWb5ZokVAtpqcMT5g4eShhg6IK
4H4Jda84gF5NLbwA8oDlF0F7389/q4+I8I2s16i+uujm/bV9wMTH9thSDnDxqX5s/FXizzBjzu3k
j18az50Qr/JMqZl4sKSo18DhVbjy998NxUo+DN9ggpMZyVdX5f/UaYwGtCS3tpmmiYlUHY5KJpCl
k/alvOxITTMFuskAfrc+rbDqK+D/MIKcilZAwNbeUpBbaRQ+QYqKEb1oLe+yT3ctQyKrsRl3WwZ0
0A8OVMlL/CEjAJO53nYTDxwAZ0idaoJP/IOpM93CiRVaMnsI3j8KE0qHeNw0Ch4PLg8SABdXeZPf
OenTwfnMhS2oQgnHcgr+4k+Kx1t3mNAqffFoB7eauXZz/TRDh6so2pqHDYFP4bE1QmalfTpXpT0C
eMseZe2DEjsLRNSdt2gWNtvmsKvX4ct8uH06/kH9MNApWDwzKnaemtNsbeUV78ub2QzeK3daBoxf
2CjrAtycU1Um3l+NGPGmGdDw0S59R1MftnbF6S3TzRtQbXFsLxoSNcXjQL+zynMmnhtx04aEyCWI
sREz6gR9XoJeejR3K7ZFbpYIWdgVeNj+h1iJrMrP23Ju5FYTbdWMQNy4LARGyhbYjjUwoEvhJduC
akTZDTZq00xH1qPD+IIJC9lemEjqJ5TAdeR8360Jg4EY+rkaPfX64TuwO/aLgzqD0CLcH9REjNwE
sNOL6I81+04mFyLRvQt/tthsPmMiP9ORxYVSAZWMXG3QvsjVJxVOjQqmW3NBcU6+P9XLLBvl9Zrs
Vv4Bx+KWiJJxJ/6bggYFZMHniSWmqUuIF7Ev1kJxv67mttXSGJ8CVvDdJhmq2yIt5obBDAySAYNf
n1XHcaKTlVHZWNEuFr99ZTrv6LDKdaOvhoffGmcDpNIn+qETCB2oic6mwx+bPwExQ9Ey/JNU+9ga
HL9MacCTO8eKKxMjvv3JCTbgnAYyrKKkpF5LJ6/rhoLMyDy2+7P8VV+jDRc3oZ5sqAyBwVEpOJFh
50cGIPsTDrFIlItF9htIoUGHe31n46OtayhX641UZ8NOL1vS0m/RcnCciEkEo+i/xkHdCg5+KYL6
x+cwSccBAC7Gwk5yRqWwlaZhr1W0k3ZxpQtLGrNIRbMqMJR9riawaQktYrAv3N4+Ka1bu7fDicnV
8AtBRMGlEP+8hZMlHjEmf57RMryKcVn151djgd0hFFHIbCrw/i5olZY8BUegwPWPRNWDG1iyuP5C
zk3MNZJ9Se/c6THL1DlyOMIXTQ7kRN0PpGHkfjzQXxdiRExWUYjADJWutbNBT0MfMmCqaok5pQDQ
XVtivpvienxOo+HQaFVH3MVHFfX4RVmYNcH4l5vyml6La+HkzNZVFz4H0lH0+THNObXWwdyCJS0B
jD5buNEebYPUdipjyHEfUTWX5zh4GmpG9a2BedzZURcSrMoyECd2HoghFaPopIBen8xdOw+pTwEH
LKEA1G06P0GJxjR0p9sR1wiKecGVO4bBqOUIrSfe2zRxx9oR2J4WxTLbaiXjs+fvY4LQ4WNg06oU
n1egbNZ+JfJZ6V0MJwHF0px784Us32rWJwhobYhP1DcvVIRuliJd0t92hzM7E/4fxo0NE1+V2gba
Cn1TblHNlnm/d8k3v8uepB0Ud3IyFWvRO0yhzTY9GcMCfFfuoJlMqUw9PmTBA2noqXU9Dn6r9Uqj
/KYS8Z7kGESa04Koz8x/VOU0PTkHmfOj00vgrwZYkKkmfvxh59HJoTgkKXs1Gg5AkV2exjuxPYeb
Qbo7u/VlUC0j+oNI2aaOF4FJxSb9OFPHu9tCUQDPsWeuvZh80u9rviksXaNPbWZKLBnooaLRUMbn
IrjVeDS8syr4zxjoihDd1g0nm9/MnGCKzQZUXWzOzMBKkJbD6Ly6w/oHfZSX6cNzYK8PlFzraRE1
aj8JeYyeZ9BVBqlvc0PyUHJzvWTlldPxSj0d+QCYCfOVoyk1ZpVYNm2lPpwg/KHICkb7+vXGVHEc
A1nbeYVpGIlVOQZ60jVf95mvJhq//gcXM5ssF/eBgKsU3kDDU65WjOCvsUSTaeKt0AjHwoXkacHF
WD1u1+7jDA44FWNoURfaQVeypfb/lwN87HWfQG1su1XqPHbUH/Px2ihE0K0heQ3XjNhTXgilxNQJ
IWR3t7dEU3wJkYRtc0YPylFSvvROGGjdVrBCz6wFHmZU6/ZdyYYBWUpkVLeeQUjj3O1xheg2YrTZ
Zu4GJkWbcH0lgZ3pWCk6+4mBW118GWdN8fc4B7IC880Z4NpdnTJMKK4uBd4sxlXODbrWqbHgSLbb
0lx7Kwep2x39W9IDohOW+GJ14nZaLf750Va8AHDd4nOs8O8cwZnYa2/N8L+TdzVto8GmY4u8ZIiD
FEzdnrl9HhAh3K1g5COWiKLnwvQGGgptmWAR1Xg9rUCzddYo4PI9UZlCCmScr3UvtGrOHjuxGail
A4m3Oj0OMAComFbDqnpOHUC6fCx+yfvoJ1iPWgBIg9ISE1la5NPQE5rJIRgMMJ7ILt6X94U+VVnv
EHqUeg+lByTNX9gKvjIduu6yUGhDdMThHQJjDVEcbwfvD2IhYiCrFPduqXWo5bd1rl2tBsL70Dl3
h/BjslHet4U9zGevLN9PFyla33iTOK0dlrTqtOVlWEN7SWHUJMLn/APaG8YBieaDLPvel3MyRP8R
Vh9IuuOumjBLCTw2s19E7/CCRizTcw1FgRcApYWc7UWB6GT6ydGnGuZ/zuZM4E3683o4z3KI4QMq
AoGyjRcQcYtnElcNsrbuC/KQdA8Mb37M6IF0+e7Dcx+kPiJXHOkTyQ9q9C7bqDvSW85aX6KZPfE9
eVIXCfT09saa1zd4CuXAxhiBP0P6BOvL9g5oj2qtRLB3fwj4avbDmPJCm0nAdWbAFkRmnlqyx0KK
8NMJgGZJ27HVEa1E+RkrXgoigJnDK+/sEJXaV23jWCRML+h2+wLlk0ObQ1p4NvM/luHLpd/7VA3Y
HCKrZ1XE+gMkhS786XBOyqvY1LJH6hSUFtiMTJR5ePYkhyh5P7Y8zD8ZHjJsV5KdCinflGV/gb1I
QuB3DHmLXRcXE97bkm9SUvS4z5gKkyryS++9cBRP8yVIUCicR2rq8WL7SQonSPpZp/SE5tuRy+fo
OuZjX27DAQgSLVgw5/Cb0sLY3i7F1vG2F1HSfRoDmEnbR+pAdOpGxnEfKVQzH3btWaOxhqUjgiHo
4OXdFU9a68om0qnEbOftKbpcpEEW5/1lG69SqFnb9MVW3/s7bUbo+0K7U+/IrzueGIDBWmIYKHSL
OK3JbAnCOIud1nWds2HONxRtCGLieigXKvtZORU9ph3pb3S2XqcALCQjGykkDU8/FLwGRKdFS89N
d6meuc38fIcApSWWacxjO9oDUABInrb/zxtzVoyi53u8oshNxA7kag3LjQz3iKMOwz2Tsd4ckjxu
kJHI5hdp6+PfwGaNQ8JxjbOsU5gCmB9BUBvLAmMiIO/MSI65OYJ03ru5ySn/hVoRergZH1991Vwi
iQgu0YV2CVttrUWPyYNhAt9Zb3UlH9ILPJb5QcQ5ymZSYDHPxQNeIKFFpiGXqcBWlSj6Lwi99jiY
Rxd8wH/ehhPvDjHui9VFJT/dbmDFdvFl5wERpc0hmPyNLyprE8ArW3Z4/fQJW1Qw9lO4r64dMgch
osKd4KsZPjt9xhgkiWx0SzW6F0q4JKyFoSc8lZD4GU/yPCQQ0sgOFOXkbopMbthKTSA3dzKbLh24
Y/Y95W7h481ojdWWNZp/ld13bzYWBsyayV3MXUSoqTNaBtES3DrWCEDWJnXnpeOCPDtsjXReyWpk
DJ8z7Cgk0jDqU6h929/0q6X588zOuLb2xwm/ZsvDRFFFoYwN2EAsWSzcQRZ+TqIt++0DoSYwBLaL
X8XdhLnzzqVONreGGHAx/TrmnS/NMhs0WWCQhX8CZ5/w6SdF3oHt3BPp05MWvc3aiFpMRL1CxIa1
+7qdaPNmXfT0auR9IHsWEQZQ4RjtM3JLPQCG5oNvvmZWHU/Yz9emNYGVdmH6DDcvsSoSL+qclwft
GTqeLZ28q4wi9/8cPiBkiYGyJSNn79n3dRXs3BNzF0PC4SAwui/7yC/xbyjvtW0gYQ26Nb4Qpx0v
Np4R1rbfY7piPFpZSTQOjfLI3kjFEoCjCTS7R71Rn9zTcRo4KPjLDXHIhU3CuuEav14eGlGXR1w6
b1ZjNLL07y8HT18Y5WpTyTHNPbcdnO2qlta0gXJyO9aqhP3LTuuB4o72ss2pfOhWu1X7gbMqZFmL
EwXdrz7gdQV/jHn1skTubqmpEq/e1BY8uEJ69L4FOh0WIo/57XJeEyGfOSaL1+ozpBz5yJpL8A/f
nDK7mluCmC8TCVEj/Ws5sh1WG9dqUZLftMtfIRKSbUj6WIjWrdHBSuncJnbBtGyZABNFyg/Sxjn7
Iqgz/kkNCdK+PWz40AU4s1orQhxDmcScPcqd8Gli8ZTANYquKk7nZQKMi2vVpFhKJRngMzhOICw4
VaZwYAV8Pt5zUdz2R6IGMFrynp5LIDsNIhLBi7QcAqFJL21hbFAW1hPgX09rGmkU+h58a+jTDXw3
a7/CTTq3hXa196ZsTL7rBp4uo19XGml3hVQLzTK78pEdJMxMtfU/5+OBPWqr2H6nksfgus56r70E
SjUh0qYfgxph5zSej1lKtp2Z1vIGVdCOg2G1FdDUi07W2Su5/r8RriQLTaMfouFXIKWudrQYBqZM
RKiHGtUWszVB3/B8GbrTLkG7k4u5iFL9luj3iB6+KwuOleV3PZsP8mL5/WP3lXFWj+k0KIly6ojc
MUoZaVTFnNParv5dESznVzs3MAHYKeyhQGpozrt09iqzMyOEz/LeWZ2eudArMQ2L4Il+wc+BZzki
6ZSd+nhmITYiQOOWZ0RNS4uNtMfwkKk5iBetPVCM0SN0J4LuNMFQT1BxQSEOpgX4ETSLbYx6FQyZ
v1W2cLCgPrympKerb2Y7dUG9JsxjWMG4D09kMHlWVTDe339ClCE5BVLrD6pV91oMJTq5UPAogiVU
hPvlEyEZ8hhZ/4Z9FRVajwE3tvuxUgJ8YuBJqj8fZYXd2MhsPTDaCyllGvy0IUyVwjefaCrdGNLa
/BQHbnn9mBQZbp5XppmzOshuEFWQMrwbaNNu1WjtE9MYnraLr5YpuHG2JBl1oZz/vSNRtbi9rIko
8q3GhQEHPKbdJCHUYOCItK0qcpJLU2XqF1z5+7+dr/mVzt6etNcLLTgH5d6r5iXQeTGkgarMPm7+
EaW77RMWYkkVezG02uHJk8pNvnAR/sbq1TSghZSpFtVDl46m7ufszq6MEpBJ19v2tQADklTapNQg
ntSdWX9JQeC4Haqd+CFAvXppGuZbZZh38tDjzQdpNgzlnwgsdG6HLaVXuHB1vpnyGK69RtpbX5pY
NMfct7pso7pbBu/hEJTg4x3CsWXVKuLSrwI9iVbLQbMVvkHKDTufEwUB75YX9DHfPOqr1sLGeTRY
/aBC5IDMNaii7uCuKKtuv15L4qlqjx5q07Lu3rBpHkVFUNXcbDjb5Fz3uk4qyP5YOo4QkPl5CoES
WjDGfI6DIIGI6uwZCsA8U6D/Edn/zXCScs+1jOAKjeSXMGcf2qRg38e6n+CUMB+w+v9n5h2bwiIL
LHE7o7YSWQgB6cEJxI3BrQAMbufhs7RpCeFkjkVu3aHHzhmk5At0bRqjL5gmCrHhGzYbFMwLn/bT
t8gJvHRyHpJzwwPDHyhUCt4FUvTd2S1Az2gKUldfuNCB3WX6PR8WquoydEdMKxY2lcGhIMZ2Nnfi
OHmoctripDZ2QNd0ltBV48E+azAdViO5dU38r8MyLBbDAyvqx/9o+9BEGhQvmgmvyYdn529k+MKF
NfQ43TL9sSktvrMCYlDZw/K3/w8PDU/cwWtIYsesdvH0BYbN1gGD2L6xMyJIxtqdsRd9kv4PujoD
izuYvrSXvUrkye9ACg0fX1x5OwH3bc5DG2mgaPo20Ov62nnUx0c1UGOfLpcWDDQ4UhpMuRZ3x6xk
WJKjAyvCn52v647UajA8ZhHVgHm8sePzlmiTOGVz+9q4rUFWNu+2Mk57wOpUM3nDGEsDexUtHHJX
iE6C5skACmmtlhFSfl/+TFgV4P/3vsJLlFhrO23O9SFeu1kS49Kj998iVQRDWgRLZ2SrMvYCRBeb
RHYioLtxVehQxOy3icwtNc30iAxcXKqQ05xlXs0UzFPvBvjC1PAl+QaE8UCnYBeMUWjKu+ARcDxO
LC0g7v/ivkThvH2dInUA2X/5+zBMeAIv0jP05TV31AmqSFcUs8LQK4M1KpLWHj2TfwmfN/Q5V0DW
RGk9cSpgs5RtcjTFdltuhPbpy0qdFXbE2KddHVc6vAniWPC3/is2VwplkLHvzKzFihgKu3djhYBR
OvHU8YyHZoeI4JWLvF1+zeHXYTnz/KsrkhyRfYKwzFsCRNcQ3+FCREASxC4E4EaoV/Hn+uXtsZe6
FyGIWlkz/3AzpYinf71ZUlD6Vg2laZWthDgXxB6xH/iKTvMQ+CPsv292X51Z7xKqysLOtYFISphW
2NTQChLkjQACWcbGoEKquzPDbV0Fl7BYHAtChMSv5Twl9vQRMgBdzWWO8PKs6KhEqEnDDFm9hCOV
OmWJufEiWV71oNl11SV+4V9nFiIhebwSU9Cqd5r/kNx4srtoTluaGY7ggRSsHKiEWj7YAMz54MZn
oPAKrzaVFNQKsQNk+ZEreyhQ5THUmkpE57Xy4KT+p0hwekkq6Mc48eH9abdY+q1nVZKhyP+AhLqw
rx2CsjI3N4AyOexnW/PzFNS/y5jDH9zztuYTBOGpA4NnGMTeg/7/hZHGrjJGP/5/4Yyt0VR3TgO8
PjXGL1+ggxo/HcD1nNoyq+oCKRumMtUnl+IA7wRSh3br2mawpa9w14tfYhjdzQclkqgZ0h4uNt6K
Wql8jwjKr31xeYP87SnfuvbqWE9QsW24CcBSgNV4WsYHvhzPpzcogBvKw92cjn9MgRchPru8Dm20
T9EHF/LKFeLzIhzRsQLe8tIl2H4ncDDDcLUcF+IRGRFDccQFdW7a5JpTl1xnm3CwLCmL2D4bovMH
gTza44NQUbZBOD0eY32N0COZjeL1ML0gHSu9s8UqPNkb8IhqPcKnCjf3yDNtX6ZZUKmc8kKO8A+F
qAqolaMwzczPgm2F/g13AFlL5U1FLk91xXe6qxMBQb4UTSMDgsa8B0aL3lmUSwQEZJeV22AIz8oA
ycuGiHFUT38WjpmSPjufy0CIWDWZMd9aoP9P1RUaCfMOA29hd1eZ3tx6cQfN9iF2S7niXHz6OmLV
ziy/MuQXfsQhJZ01SIyALUjgUhNWG374pYF8FN8C7RLwSmnrP6uRf1Dz6I7t9bmdzFMrUdmOfech
e9thyaS+naUpKYnFdY4WY5UAgeMXUTR9RAjCnZbhyDRyeLQ4WYLXCKqm5vB1kqUh1OidNIRRKnf0
Rtuib1eji9BnxRQE1KKyll7QNWhU0bOr00R7zW2imKKDKLRju21SKRDzOtXPMYR716cW5jRRGrxP
jRqsMGJE8fEri4SQ91WEREJfdlxPn9uMgosaY0zHLnv1t30RazQU0q0A/U3MVKoa1OVSrPHhL6Sp
Sd8rSAxOwmnut3SyKMcmvGLFqf1IUiEj80P78Q4XX200JBdUVqI6CVuUczxCseVf6OGw2Gd6o8Va
mlj8DdrWm0Q+JxInQODGqeJwegdlpC+3K2ohSuvLeNSfgvyZOilggf/mpKwUmP4jdBdruL8cqZ6l
3LCI4YlZHlOCsGwnoaL31DJGWXmQ/5U1rZnaBAytfZyUTIVvRzJFtu5mP8I31J/rbgutv7MJ/4ki
DC1cvbVouxVBPm8VEPsF7NOknHvYCvMNixkcrSww3f9/DHkT3ylPL9zoZbFHlS+QhvjJY1+CAOY8
PM54wcpS4KS9LbxGmVOp5YEBuJXccEHGMOU7urWmGW/ltTRT5aPADbfrfnmnR1ujs2EFBxyvUbc+
jRtE7l5Y07fV39E215gIOAoJsLW79vKn5bPMNZUD+SMYIHgQD4/bIbAjZ8CHLwWD3eIjMwLOQ2Ih
398maITtmXd4MMx4XbxjW5VGXvDt9I8Sl0/DNmA31oqHb0luUIw4V8qXcPDE4XnYk5GZ70iy6heC
JhDJM8DIbRnMOfGn3qIx5RZZFxoggZow197YkVYBqqJeQ7I+uBUd69LL5JFG1Y64wtpUPP6t9Ckw
TeVHZxAnFWkc/YtwIq/CtXQM8U4bw90UMTkBuVvkher33fug3bv8DBEIWp4vu3auCTfgf1HosbOJ
HZ/VqEzQF93SG8rrLm+fTC8rS8gLkDFOsHRnSYRlgL7x4L91iXMo/Dba/k5v9tjucYM7jmp8cx9l
12ZP+ZpwSrpmKoVtuckvNsMLzYjnxpbaGIFIZyWAGIBsJvP3Y9iNIXKnuQm4QjSzi43KL7vmoHKx
7C3x/Qr6CRrI0lsu/qSx1nS43UK6tSAKyJKTLymS84sqG57Zb07A9UP+P1rugGSL+rHMPuHkbYwM
EASG+2ZW9aXwUl54KosUtYqULzTFIzuT7aIntCFAr6AuTbr70LaDC4lwHRilTcQ+5MVX+2aFqeAg
EbVpwpscWYXiqg3bA49/g/bEWzwZOhYonc8dguo+4ENYkSlC1Gwnjs33vcZXXgiOX839Ok4s9pIC
2Xnb7d9cZOfs3NnrxXgZtw8/+PcWoaNNoSMzmvVN4y7us7AyTEgoEg51L59XtI5WKbtAithYQrUY
b2+IY4lV5ZS9KggYnUz4tjH9hZstgMH2HLzaJTOG01fH8auHp0EbqaZvHIIEvswFzaNIuxDJllvh
Uxqhel6nzDlnbkZYpNsYWZpIhYjo36IbMJXLEW/3o7YVdMjNmUhpY0ZQiWST9q0/KX662qcDSyTC
Sa2QOEXwv3uLW9ldEuCKXByV3C+lTBxg4raXADQF1xeiYa+Tvc/AR7Th4Zc72cypZtWAg/ZxAJ5l
8PyasR+ZPXxBAJvkjuRSJ1mZH6DolmOPnxjZckTYjJrQN6Cd70BktPlY2PVs8L7HYxjnJoueC7BL
FPd9hrQS6bZH75Fef1nkhoQLHdxBP/N9B1gL/Iy8Sw+ELlcUmCAxa67Oo2y5yw/T+zyoS4cmrESb
tKD8fiGXuW8Uj1ZbjWjuY42+kAbS0ik1p8Pi/ZJbhwim4AflCNda4EBrg37l3JEjjEioYFeuZm5F
LpB/8bJyHrBDa9co8HcNnHgEelyRumXsEdRBughwlu8FYyWP6n8stQrboO8UN/MVlnGB8gAQogs+
tc4zrkS0b6QSe3ol2beiv8ziVzG+BOtnmxKwk/ONUyxJbGySE0+V+9TDbVj5a7QGa/FncXI6wZDu
azxkzSqR9i5vPltxOfKTrG7vJ0iKI6ojRAfPkNxfaUnLeazKw9eP6BYQxktpUZdd1A2CMC6hjn+V
U+9n/KjjQ2tHSDXIPdkp/cD+Furvt8m9pP8WgpKOwrmEwyoUuHokZxw+BxhmgXwCXQM3E9m3mPiT
Z3JEksY0iG8mMEYvE8C9NN8ASqaTo51O1R6RN86VhimevzrW9splltntVWwnR7QSQ0S363vgZTrg
5ttOa53U4dwcnZR8+5PfN3TI7TJDL13Cd+AoFWhwcBvmYCHnk5jPuT2LCjsGt+feEYIAmg+xaR3I
+JoJ1xmygtuylDseV/RG3+7cFfE4FV5g7Ka7WVgc+touCCv7bRJG2ECHGJbtCVJLqow4WiHWrIOD
tAcj7nUTU4bQ1ify1j1RdybSlW16asniEe0UqwIvo3UiNTCxvBEwJuhXbAmZIP7wpGN54sdz1+CV
3wwBhT7XlM22MYRMskk4BtxK+70P0iRx3i/YocvO7s0CNZir31UVmBeyl1Ww664DABGEIqE0FPAC
eY26afsweuraXRjQU6jmsjVSoCPJFxRbmTUYWw1mnVXoEX+ZVvsdqTcPRSfujQxA95SL7nm4Nz1a
PCk/okx2IpDV7JgrL63+pKVfuav8Ix0xMgeWQNdknXkSOInigB2369hqKxIAKirNPR1tSOlqaxMY
YUIeL7K1mklCk6VEivZKkp4W+kOz2ziu2sl5ONeds/omiH7twvLq8uRRBz+FG+DxcjffXHaoDvQC
x4tBgNsoTcCmer/ubaFEF+bWsHcMLahf3edHGbbC2tpvojT2pZ1YArxmS+cS/EJYcRZ9QIpynjOO
+1jBw1j4YlSqUaps/WIa/mMPRwhiDBDY4uyaeDA536tbH2L4H8NdqSDroNtSCNWQixTFbyR9rlIn
26Ubj4bg4gqFNuxmA37N6eO9xRg7qSzmR9/rOF8uDwrC9TbsWgpYutO16Ckjut2C8L7RynIzqWCS
Nyz2V8IUvGCuMxD0pl3YeqHSUJzotHn9yWSLhHa62CrpFT+1E9TJut/HFIZNgNwG2u0HvoVm+BDj
hX5L5mUeWIszTmytuKsTfmhhKxOUMsdkIA05UXZAzHbQQ+FYE1/gh8NlGpRHxplsDEoMWvm9tVHq
x/zIY+WNi7UDnw4EycLcEw5feCs8sqQrWr5gSs+CZXzi9QU4ohB/TAZ4IivwBasyA9goXEQOfbTr
H03cyRj7znSbTcnEgtR4SuJ69QLXJSziBJQll3a+khiM5CUaHh2nB3M331qLVPDhCCi+Wa/RITWA
7y7+KtwoSkfH+MxN3B6OsaCRC5G5rb0fIihPX+U5j/JZZXEQ5aGUxLoW/6V3WnhyTV1Cy/Y0T+QX
Q5Xrjmxid6DeDdBk2Ddm4dfRyBJfWpDV3KWyA1rVcxkHDVyq4FutSQySMb9AYjghQpPXy+boQjOp
T/FwHn61n4++nHlFzllyrjpwkaFW44ZsMsuJXO2ruvALVh2P4YaKUtBtOpL8M4CQE6gvnOnApM2s
Q3mflylnYpLPpunHEzV/0BuGfypoZihuMRLBqMCBLyxpSsuKSS9JVokzrx19cpNg6hTPokTRTMAA
8cKGawoZTXpnWjE9KwCXjDIxIlzPg6P0uwKYoY7C2opG/xhyrJ39hINSKQNP5z3hbx+ztWqcDyfs
S6ZBzZNuMoDwfCKodX7MoUpH2zpRPssE0BeQ1PbyQTCs+8bxwYUHzlEPmfIlFFCnUwoTTZSiSjdn
nJoBk+kbGCYiyOsVJeEYt+kjb4i+9NMqio6VCBlO3BfTtTPTlYe+YcvsW0kqo5BjgMlfzkw5WOtX
KMaoKtRRa/JM4j8Nto/NQk8vZrpNFkZAyo0cY070QZEyZHejvdyxwUSFtW0bJsfBiJrXMlyIFXx1
+ZPJlUu5STLfgrPlDtZ3+b107V7itCrVV2xFHIV8d/Vew66XLh1Orp2vAKkXImr1Z4UCIWEOinbr
JH4qtO+V7JqYPWuda9qSmnavgjI73WtZvX9MG/mbpRtO8Dq2rl6DO2qhd07kA+vjj9hhliYJW6XT
s4Sja4OU70foihGxJsvlrEwStpVR+l2c2vCv5Q0sFejTT7sk4cruJ8XE2LDOeBgVae4l5AfQVcEV
yZ738Bxn+KKtcvKQqfpp1FLqFPJ9g2voXj1YDl+bwFHrl35CTMkRA5B3BYusgl/Km/kBQyswUJUr
I+xGOsMLiik2ywx2jTRXOhAu/NWhL5wzJQgYJBtUEu4+60fe49gjpz1wqkibplwjRXtkkW8Vmaiv
vmiAY/Xw5TxV7wI93axQMlljr82xu/e0yP84O2CfTfF39ab0jGS3qDssnIvgcnHGtLOYl83N1tEu
9GM9LVQZzgwOXetNN2xjaoq5UiK7n4w6sKTyepGNq1Wwq+b1T996wET5Y1d50Y9D9Dbv709xvRmm
nG5menzjsGoek4j+gCfk6Tq1SGHyoncHOit1NYgNwDOTUsOGK3MuYXlksBreXWdRfIZA/29ZxMW3
12VfewE4InU0ETtZFWPuWJIxFVZeAtzt4g92oFUrTSuphtt7b+1N9vc0p8VEPKngGH5js5tuBjZh
M07rkQb7UIk3wFZC47ac1KSKtJN+VYVl40hsWpXCDMByBeNhbLlG/0b0erUdroE4QBSUbJi3+bJx
aHjfCvqF5fXp+/k2UTlUP2u0+ZGkAWL1ePY2sRfLb7Vd87sEF55+mQUxZCVeEUrq9G0dbnBtEGNv
m2hsUbAltTvjUPfAqtWLW+lfns+G7QmhPJIIXIAVedaIP5a9X/Dl+sQxOsekSB/NQzTyhDyqM6Yw
PxjOqpBiR+5PPGfeHhNTiY38Kd1hXicFrC0R8Fe/MbAgR/Dm4XdUJM8vA5wMHTNx8KAw6PSxhNdn
n2gB94KTJWlYWmAUr87YmOVMoFB9m/nZ67XDlzuVPx/SSeXCY/uH35oNJu6anEgkrd4aur3dcGMx
FcpNELbK0Y8hieEmZyFNe32m9/vzrzCgI+xsaKto3wwZ0qRBd6Ctsy3R6Ih6lyhx6xtyG+ZET22c
JZ6LATjTe/mc2/Qu2uzIYSqM1xuM4qB9cYo1pAOlAb0AqivGODmvmJfDlPIPMOyJ4PfbEv2oic5J
Wt5r0Lf98sEvrc7z5wmbIi3TfFm02R515blDwkQiniptjGNKjedIxJ9HKKEuDs72hjUotNJ/AIn6
gHNAKInZG2dTV6httusBsFql/q4I2//tcGFopUW/5Nrb21Q+s1UiN/ErEzt8Fi9d+oTgy0zE9Clg
b6jC7koaFUTaKRvfKNEAj0fB+XATyCqTOFFWFBkHAjJbYZdWVdFNfeDd2agWtudW3uEZmXFIXiz5
em4iRcEFhrguR7hKizj5gL1cQ76cDQ7tQWGS0mkI95QFnxe38qjLnLJRBHHS8XROM8dQtbnt/9u6
ggoNiuwrjF/HzuiX9+5P307ykH0lppsVajsd+u2DxeOpGlZxqeAnb/2/6j0I4gnZ23s0XzJljkDX
9hkcfyiD6w2vN3PTDrJsC74XCRpX/gtVhYTSasg3GAZ5Yj8MGLxbqsQJzWSTnXd74lHAw93xCMn3
dMqhQ7iwI3u+iwXmm4+e6GWepz+lzpaQP7ekTjEP/OLyRbJ7loJSRaHXUyzr2hwQzFBKogTUjzLg
Rixt3oCLaisR9wfO/Z70MbltunX09q7hp9CiPPzO3q00Gvs7gLuAF+PeXnk9eZwRttcCSpKw3Wxs
/VFkPZx8cBBYypBTfMoxtuNnQZEr3gmX7qbbzScHZZ482/CEdQ6q0sbpdgVeVCER32JOWaQrJvek
qjvXExYr6mrXE+/Um4+grOf+G9X4p4NLISXvXcO+LYdEAjU/AvHk8Z9OOxVz4LmYQ9J4O6OuLS1S
kPB99l+3P8555tZHRvVc9xy/2nPZ51wYvhsOIGdbj8uqRdyHoobZJlI5zCjAJU9XLmAcFW0Bo7XL
w9O9bi0KQ0BAUG3Ug/CxjE6Ki+neGpQVqyyi4iFXK32LTUVcKapbfloZgRftNiqC9DHm1UgA+dsH
aY2lk7zmrayIH3Nk54vXSymTNhRvUl/y7n3tSa3CwcolC2Hfmk5p2843TTuen8/dqPqXplpgva3D
5jXGAHBtFvCZ4Ktwr/x30aokvle/8KdW7HuvH2183pE+fQKUbgSKwtKjpF43rBajuuoOEKOGLwpG
RjzOJ/2TGOueNH1+ynDqZotzYxPECiM2xXV1L4E4i7F1Zsgu7KJi37UFrnr1wrZCAi0mrbtczO3n
FAK+DibE5Klv2sLOIye0SrWqretKKi/DNgw2MfIZFr/q6LCx7L8nu+jApb1jMbZJB8uP9/z3t9xy
WUDYKuA5e8TLfl14UbXVXVn9hlUwZ5DerTnDz60+Q7wEXJLGdbhKJX+xtQemnf/o7/kdFHRw3z5Q
ok6m3D/Sz/92ozc+xbF4vSGxLxB+IiquoqovH1AnEMb50fB/g+VB7BykX3BTr0rhsxGrQYLbAvoD
7IFdsUAi4AiMj6D9QCB4GdWlDig8j92OSO6vbsx9p9bINJhU6e1KxyQnzRggqWLAUv7i/jJxrzX7
nM0dy10qEGIgNP84sMz8utgX8YaOtMVaOq4mGVqmmA1tfEoMpCGNZs2FLj9xH3OnrdTNH65dh2+h
6uG85nP948OkvEnFS8+oeZyP300m4d/sw/cTeRqNv55B+xg3KbHiuhEgdGf6XznMqQJrH4d6NOh8
e7ZIGvceNAuQVXJQpcdWADyEh8G/bh3B8ZOjmHVjP11rRHCiidXG53ShrWfxXIZw+b0IkFNIUz4E
8O79iKQINBqMMLH949qaXyNaypFeUEJwyWYP4jWOuZ+ncgQWXhebBYg5wDUhC3/yw0lfGAcmcBYS
RCXBKPnMrEpAj9tYvwbA117On/PQ8N/Kq9rApOP11JDLCegsqmb38pbytFN73wEBqfxuW+qnvQnv
C3NCVDfV8XRQ9Rwad/8b2OFA5CwF37lmxQM7wuzQaB0zSPknW+ZiarUxI8JurcUH5TaY9KNjXzOC
61cq5BB1990MTHDWWxKBXMH9kgeWSRcNaQwm9d91a9UF4RDkDQjBvJszAv1Oe+afdq3dlXpQH5xF
Ym6XCg3y/JMxPK6AaRQEWpOf6FTE0hoBrEnK5bNBoSrXO2YZkyX0OIGOYogwobdiRA8ycRtgFaLb
xxyPu5CebAaXV9vorIRL2dv3nlOecowyJyjVo7V+yJscgIk8cN6n4ErwVTWEAmvHLbii7BaJbZRJ
3V6fPTL99d1t4OhJmrJxCWxCtuQ0PiAJocTUrfTWaMFmAdTwKfPVeA7cR58YuWO9/4Xiq4gSotdp
yEegv32JVxxwijtIlIRnnNDF1RRVRFF2Uk1G3gaHAwJpnBMqaCJDrocad9LoZaWcXtUD4MGK8o+a
mDh0ouDoUBPnJENWUnCO6P9Oh5p674RxT9ujFKGE+CqJ6yBvEzyCDUxFSYXHXoOtYl+G8lmBKGGO
8AiRcSGR9Uls20cLb4PAYLW91AdAwrg45myvM6o4M2Q/grX+WvQ7NKV/dhFbhH8NJdmgczplixwi
8WRM+pngdnStwFYAfLlSP/+asbynaJnPlrfrACS46s4LNRV3Xiaq25SR/GGJfT1pIPXfdQbhNQjF
e8tsmQ6Tw80NicQiTPuiHHdg8qW3rrjAfTGWuS6J1wYi6S43XSWPrhtpLgEs1En38RPK4zrGmF4A
fGIKwWqUNHYCAUq6+1ItUvdWogNBF75BjV7/aM00nhtsD7P/AvHeYttu//6SjIWRPM61xdktaNsb
uc1R3l1dMYe5V/4JBgEu0qsOKQ8lr6x293kQqkOBBA+3jYKuIvvPBK3wsd4ZCmFWVkAwPOoc7783
GV4rRk1nhB/etTnvytDAC5xRkL3l/6mK2iCljv+eBIW5Ohqzbx4tiKDQqTfY8aVe3qkhWgliWUrX
kPePs+KRNG9ffWw0loKnIc61N9M7nQ62sq3sZRQonw+EvYHg0+TN/AjvlH0ReI8uZEsuqUqngrzj
gZ32/KBPfL0JliQKh86rSrI/6uTJJkI5nB5hWxeRF26AkkNYmHPZEzS+orVlEVr/y6SOLfqGUer1
Uu5D7001j6ea+1pNc7quZ3CzZRK2aEKaF+VyWygLvcz13dVP+v6eWIylL9aK+LMWTElkTwRg90QI
v7LneRKlWkkb94qnlD4s287sMJrmPRZqdtsKslpnMiKu+/eTh8NqNPi25y550yYAsUhgnlMqGaht
YXtWOU7QnbEOrVLG4I3fQljj28UfJLVKFuqPKyVA71KybSyZH8fcGVa3Tuk1+0amz+X02ualpKG1
Fg4bNEUvzwdExbhPTgQSxA0pOGUTgQRat2iFiCfo9TBfE6cKtpyWtV/0kpoDaHUysEnMJ+dvpUrY
uoJvjhxUjx1oQzzD/6xql/3z1BLvae0Ff1sR3/DPhLEbZT/tB8zAIqVNTdvn6ohJA29cg4zYAUMt
55nk4FdUg9r36Utaz/a+3WVM/0qMMokSOsiSDlKW/9sf0MXrQjl+rBy5lMO6s8GcAWzUo7T7b9Pc
11Tma5WA7ZHLtUiauuu8nFREjyYmoLes4mhLS5QXfo9DawR3wEXxmUJrCVu55vygyQMj5x34bqpr
oMB6AmjEl9KoqmOZOcT5qc/8JGW/whBJ8+Y83v6ZqAFvNFruyy9K66anW/l4egLpHy1ew+sXdYEu
pYWlszbggf2YLc5yETxloZdubkOy5wz8U1Y+MdO13UkcK7vKTYBhyTz7d2uy2ZW+GByH/G3E3g2k
LZB5Aa3II3D3lX8iUTt69ee9wLEgYDnO3hTieAI01H0NjBjqv/t7BH74m+e0P+8QhT8xliEVwpeu
fv9yck5s4IGxhoa9B8CT3pO+Z+hxIJZvcChmadEPG2GUI3Cm0J4OIpyUqIlQbPiElvNVFKC225tO
MwEd7rfv5StZBsYVda0nO7hN8EfQCXMT0z+hamq5VA5mCr2voiNFdoeffxd6js2VThwLXPkE71XU
Nljr8i5LNkdAlZMuHKG6lUCxwT/n291GuYdqCQBRCeVDcynNdE0yb8HU+ViONtAiC5vsz/k0q9PQ
kBNtENk70ZtRr1c6XXqx748hpQ/m/A0VXOqyDdKZuYpdj67fFegVq66w6VENRFpvSA/eMhcstUT1
MoK5b9UEQsWZyrbUuJN7taWtF0jWvXHtm2W82B+KUjZVJ0c7sQoP5Y2M3L5hp7k4lTZWeWyMVPdH
O+7czdY8kDA1U3IptjSO6A6+/m8hkmfDRa/qckoQNFU8MyDb2GpEALpUnznUh5gl8XLgwgR69QYE
/CH/Auf4JWNASZnQXW6gk/DMvfNVZbNR0xW7VfyqONaMSAgPCUTuWMOm7HWmOP03HGlbyuVdSUjV
sNMqBKwT9PIIU3yKOE1sn7E+a0hpxsCqpJchVYXHla8A/d72XFNwqGd1YaUQcKB9ajQ0sSn+7gDr
hVtN1w3CuaLGgVJ8kUA8PK1QM/9LhDk7DfduvcfSWKnyEeznwegz2c/Oc03yqExnc0s1v0uj2Asl
//wmUQ1ZZIv+h2fJvldva3sksbghU9U3vRMdZnpEDBpb3T8sQwJIXAxvniWzs9uCjSIPJQ13sMao
qSa39KIgnDzC+8w8epw1qu37Z6JjqZKZmrpXhb1ohkFg6PXcO9YwTAV/WlAzN1DASDY22rAwcSiK
R/G7QtPcqP9q5sOeoqbOv0DVukuOIazPuHID3Cz7aovuZA56JKJOXiGN2FEz8fHJ2nnT/WZkZ4ak
tHZE9neCuGkSnQ1L/41t+f1uvC/Drdbaz3IyHXWnCZz4IZHtfdrHGP6i7G5gkMVjEovkQdRpQOBx
DhWUBWTbioLxzYbpNX5/mU8dSzfBuLMaVCLyo7UVH3g7o2xHATKN9wfa92vcnd9vbP4mW7GAACjm
f46UHT3mhnnLDgudSe3xD/5qz0r668xd0aYmXh9O/QZRPn/uNcgiCyk4Fmx6dj+x6OxqAMht9uxw
iaqLSyTqnLUv3Qjzk/UXm46hYkVSM7bSGCIrPLDte4WwnT8ZCEYjz343+PvQ1jb9Uby7Mm6tUs9m
N+LIdk/gve45qNwqpEHqxJW94wn79BgyK7Vj1bfGj46QN7CVQwQy4KJhEk0KBzaKO/NAtF6smYUY
R98ZNzdAfBHT+6i0OgjypVCJp5QVe3S/bOki1sSIPMWAOrUIGaV133qWSxNydcSLNIPDLiuDnKX+
PojhaQZocncG8LvEESmdx3vS0c4KT6fu77xL8FjQZ0W3+YVlCBO/uQJHn9Nb+eBGL6aiRNcVPhUI
DlWK7l7A+HlBSQ7h8Ji3V0Fz2h8ZS9OPP4j8S22/zzpgZknycNCQXdLSM6MqkBZF/LNhe8YaKDkD
ESJrHbCBoW3JUYB3nyZ9VSnUvCceTZapBUTjo7sR8ebaCdbaZzKcFh5qTP64XyJZCxCrZ9KicWbk
AoH4PKMwJnMCczWobpIpTXbgivRqfqaStieVo/yCKWxLwrH7mw8GFkrlhBRPd4QNjAanXdYm8VXr
tllByZbNESJWdybcUEPwKN80paYPlDaJ6+syeV/Moc7YqgDwANXIXnGlTIbHX7BI3b0ZNQZIQhMN
Uj43KjzZpKJ5vWqe4t7x/pUnVPUJO8aN6TVeBtLbSLKtC8IJPYRvaIrcljTVdc+K5BvgEbPs+uPX
L6Mspg0d5hHvY5EcTFoq6shi/h5jC9HR7Tc8FFyAIWfQnaCA0l5mW1cpz4ra2wZ6GpldWsfQlR9z
DeA8PLhLnywcN0qe7f8M7kcJauYTuP78s5Oxh7XcDK52ijlAYFcjBR5abRP3BSitQruQB9pyt2Ou
jm+zL7hHXADgkJkiqCng6J7itikm4fllQZgw7iT8D08OJ6DvFH7OtojPTs0YZFZhBmMw4ftAXY8t
bqm7pYr7bL0T2ms9jcKNmLLa3MOh2yLBU8xtx8mcNtoC9m0pGg4ZPmFXcEcV5nwILzNvQfDU3b3m
Il26V1SS5LQI07cQ9ijMJbDcphd3Xk79nTjNeZ4K1ZQpvUVaN2d/0SY/v6udTm9C0eTO0YM6KPhd
jquH9qaa6oIxWBCsbwCojx4O6pMKiLh5d4Cu4999T/M2G+E6tZKXdyNE7QvTpTG3Amqath8wWNb4
m0bElZ+4Dh3em1PbtDWgZDmuEcKmGU7tHc2QPhF+sVQPjjMpNCHNE47VYngr3wCdRLmaXkB+B04o
9RiNmrgHWpbZhPpDce/4U3IqWMXDu8VaJJ3V+/oEO/QbYG7yJ5NOrIPYZSvO91cRMqINepAc7QZd
mfYrXVErcZav0nJmeqik9oNCIZNPbBbb943J0m4T9IJX/2lg6/LwA5k3YGaK0asJ/Cyp5cqZdlja
e85rk2tg/4WTvLqJjd6kf8C/Fmj7cMv2lu/jB4NFjSa9h3TvGipgTbvmV0c5ZEgPNVtTvpnnmG4C
cVoMjuGjadvQJ3EDivwwArgMf9apnYG75PLPeDLxz2n5H8ein1TF1CYY+o0P9qYFzzObK93Y9nEI
UXeGJIOJKFl3h+R5oGvd82IM3KkISIU2xGOTuf1k90AfglHRBUDwMVzm2f5wlP0CnIG1GHZ9akK2
UwgQ4zR5tNUVErnxrGswjXwSvv1oGKWfSeSWUitPUrmVyDHKyWuvhBs6SyQ1f7ZEsydzwfTD9LnD
LsLNC/3r5PWaGANpq986Pe8UeLAz6Oidql+igTksG0rpGQTyOUgJHW+2BJHRJL6WnlrPQqnop4Q3
KhiP2cC5SrFt5ywwvDX0AakZHkCvQhvLRMOW1T51mJcHf+E06abBDQe2Lt7ngE5FW1P5OiYb9J6M
6l/0tm6OS/SRLmTc8jBtEl7SsmgN/MwpbLzvez48XnF97Gf4JbMA9idZ/ubJS344HChMH5k35huX
yaWhHRUXGROnTQkzV4wcYM0zizfsn/p2JnsAANgqw/tHxaYu7YOZYipKDm4MXbWzwr9/FbwhclUj
LklGE5gdDfy/gc+J3opHakoQgmqsajYsfUzEA6KOv2IJTm0zL3fvF6NfRxGA4oz3jkTThDbSjg+i
efe24n5uLI3ew/Q0X5gyjCYIaSzFWsprzGyv6C6XWgiS1SS2TNpuF1uAadHfxcglWLCsX/5qmqQH
kDAh5uQ5GnW4ExSx3nkZNpKjnu3+/86kjkGJM+caGKluELNuRbapc75JejopmMZwUjadI41q+yP9
beHMrUmtoVSzNMq8louzZgIuv0Vq9Ea4NNw4NHHC5bybCeF4n4t+hrdIT3qFSJA6YRMovAXcADQP
0JSRc5QZ/Cd/bFPlduP8PNtIWRvhNyCk9AmANT595wnDWBOqFd1Fp/uxyDJ2wBn1a/Dnazn3H0Lk
wX4BAFpT7GovLNbCnlSKa9MFqiA4A8mq/0ppjBdkj1KvQYv0vvi7c3Mf4clyKOwijq/WwoasGH85
A8VvngHejFqNw8yoqxq+d5QsCizMYRaINmGkg0HrKwiOJ9zWYy5KCfBlXWtwkd3T9Yq7/LqrWMjJ
pXGwNGpNZLpri73yqJyYOLB2kX7zxsnqkmjO1xR61ECXch8aXhiYYJF7VAcs+KOvfP5GDHTUk8TO
QyU65hmaWWMw8bRPVVP4x0V5IndITY5LNeUUwNU2Ge6bAkI06P+6kkbUdDs2iwXGoB0x4zk3etYZ
hQ8FZ+J1qPK8s0tzMl/KrJBk90J/N/qWv/g7ze9yjCkdHtoPVgjSuAB54G9L83pGCoeyechxvisH
NphqjVXaYIwzeiEv2IaPn0YHyx80BJeyAmW0FFlD4wv2TxG6Ynh6PQo2rcVuXg5qv+nm9I83xGUl
dH3Pwa9uJdIwm9dIVRLULuRExci0JRHaZnvqrmOT1fbwUQZx6vJXw3kM4rXNAga0lnepXIil3UG9
1CfkaytRyErOQGVKpm074bK2YWO0j9can9g7GCvg0A7TO1pM5NJJmF0Q8dRhJo7qHbZONSoYrPi+
hZ8JTFxybyZx5WUYb++rQJ/foZBUrp3SZbr4fmgEfgEc/3L+i1Ih4nt7sUA8JReD3qwkV+JVcZZF
rNCvilSbkwe469iOcaw+YQrwRpAea+gwFcB4b9a4FBYrcXyKqEFjZ6IjEpGyBpVZuCgpQ2BFOXJN
b2iuw08HdD2EMTG1jKx6ac81kmmnV7vBy0ubMNHitrpp9o8y7oI6E1d89gNj2M3Sd+wReXe77ck6
sDKcfiPnfWv3TwxldzFQ0h/bGF3lEqZbQGfmRlMO2Pf8ajmDrMtoa6DEIknraIctioJFJBtZ+sEq
osrTxxZFvvqZRhjM7S3NOGVtzt6ipwXZw/oVxJ83dlTob9Ck3L4abmPjQ2NA27TLoIoiSGbnxyF3
e41PULg/EKk9IR/zXPt6kzCRiICI4JBL7JNIfdM448SSx4kCX7UONbkOIjFRSZsN0TX8vhwx6oWs
5SjeCzb6wyYofM2loDlSiXh2vvxFT1xSChGQQA4mUMe+qMGrDjYK7bj6oBFRCLC4DN2/+GI9a3cD
aiG2DVBZl9M6i6I/XY+axadRC2OVMwAnEiToBnnR66tabsjIhV9sqVcR+vjS5OlovWnQBMpWzJ3R
z6VoAIzVyfrn5lvzGEzRQTcNcun4x3sUtV+Zrxx6OInX9syY5iNCRwpPUsNu3MlAPZ6ui7WTjq8E
Sp3IzlM5pla7jAy5ED30V/89VnjXl0xqVyFqMg+/MY7+5OU0/i/D4w9XaqXo/YKPP2L5BaWxsC6f
pPC/AokupoU25vrgDzlCD/Uz+WX00f68BKBfAW8lvmEkVlsKq35MjUbsriU6oWrCni2smRsIdlg4
F7TZjGdJYdjvrCIROwVSoP90B2JLYvgCrsgGW1Rt9R+92kHye1/BTaVNEH432ACBl5tRGF9IULNF
WdgCyQ9Qx4loydt7Q/cW04qvH9Npzu9fBxwusgj4a/ReZ9ieBxqCHti21QO7Ma23C4zHpr3kbjEH
2OaWz0fv7IACHp1lrxS1HZBcPj2vcUk7dj5FL0aI4DPEIkeDj7BUNvAXEN1BRb16brv94+Ud//Uk
o5E8pZExdZZWeqAYjiFcWWjpDdcR6ZcVzXdJ+wpXlG2VFdEWsUjMkR8/4bQcuYy66gER9nPmUMKT
CRSMbWFlMtG9+6rWPZubrY1/lgkZpzOg91jnDtBs5XfLVnin72AYOeMA20UTwxdRR03XhMt9UtN0
38S1oa66Q+XSYHRD/i0gMsd3Jte6o2Jslu1gHc/Qu7kofDBNZeI4Hdn6OtAg5Rbdw0ac6YEMpRx8
gG1w6K8ubE/t2Wbx92YAVqY5OUaup02Lv/Sr23tG8W6X2Na9i12BC2ygZ32puzl5PGPGPT82sIA0
SyyvUhdBfRUU8ZJeRC884ZdBkFggFIa8+LLqYqGRMIo0Ogmu+aQWzhl+F1VDZ93LeWS9s2akZYQw
hL4JeCdMluvnVnzokSEnOC8TGz/5TA1F5Zmo4r5zcTnEB6gGt0BECzSI6tRVNo1ZNZ5HsxXUAYak
UlZadNursOJOJGmkdmQ/Zrc4Fc3ZvujwBHBkJ8SAx5lB1LzRCZUTMR6QRBkcDOfaEqJ7NUHL9TIm
ldF16/ztmEbyMz59RTI6aOtoSkNnkwOQRMrlCbfmskXPzl/Ax2PFDSPoI5ObQDgza1CfI0goxISP
KQrlV/Eb/kKQBcq7kVYPta7ZWk5/tKNOjiRFhXSrDiRDgvmPIxHcl4QkXQRgryRbzzofBjXJixG2
FxS0ICItd6tWp9JhboLIRcWnj+EMFZJxhkn+/SSKSfk9q8aSdBe63E9V3aRRO3zN78Vv77+kpou4
9D4GpqJsjskP7V2tSmpP994NBHF9FXMfd2qEFxio6/2GNKeM+bFbNeBWSXN80WWXTE57EY547FYa
Jo/+FU//52keJy6BPxZgAS4FFaeMgs8oSZ4SI8CTG6prPj6+2HPd5bf3VnwLDgmxh7e/dsHGNSEV
og7neI38zh6OJHyrYT1neJSD5L2tSm7WyPmeFcs388bnhIzof54F9HlYWtkxGqnRnYir2Nd/Z2sk
6L4p9+OVggIsveWynyGQlKW4CzNEDrqO4nS+rRYO2qs0st9hY54SZwEx/uLP3hNaPorsF9JHF+qI
cfXJ0ohw/I+FB+CdWcEU6c0sSewMk77YwVGcajoQBWHfMJUDvEs/vSETCeEeaTKRlfKlQftRJAJq
n2Gq+MsFCFfEznNj7zZJIsp6UuM6u6DI0VMifCt+3y504FXAMSHGsk57VI4OUkJu3m3YYDdQa/r9
lbs9hmMOejukbbE5A5ICTy+OtetVjv9hyvm9fi/idm/HM59tK/+onhQGaxkyedmQk1pr3//61W0k
V8A9KLFWfh94JlK0aAJQMgSRLQ89g8Cf5QAxgIHBCOu6tTWva7Qx6tXfTTTnXWvS0tRAFdjE7fSa
dVvEYpk3gV5O71ZoNCuVoFXhyLdf8D+YYptnDucKV+FlxJ0dDQgAej8aGXfohBkTJo2hiYBsZXZC
uBsQK5c4o5xobgWjiBFFukSUjDAgqt2bXqA3zJAuBJauyqhUtm6RB3I1HmpPr0VQmHVSLQdMD6bz
NQfNywNcjY/hE406zM2d69/Xr10qZzwgNlK8AOpKZ8kazBYUoPD/vhDse262S52c30ZSpMKe5H3i
uBH5VlgHhZKJJS87qBKZuheEJ+SJ+3gSdOnVYLeS5h8PaHJrC56LhJz+OfqYRSlLvOlXKTLOLrrY
aepjgX4J0ePiTfLPpZBaW9TrYo7s22TiVfTI6KuH5V6luIGTIRvqoXgq3dBIxg6iSTFEBpw5j8jp
bUxTlhHxOPillJ0dIktlpIuzLrbpdiS7hKHPgb7mN+sPqR/qaQ/9cX6B0Qcy7FTLRqeOeIHRq/HH
GZfWaIWwBPaeGzr2K6TrsIajhph4ycDTy6qtiFThszJXtoFjZnh0tVkCMjZ2azkKuJzKFbggORcb
RdPg6MI8dLjT1gHj6tQxnfzfu9AZ1REVzxjQYf+jb7TSNMhTSjGoHt9DKEFCDyPEndPIEZyHQeML
agoN9Tz29IDCizI+w49aGPFVQfL9K3alowGjepUIOtyDbGC12K4DsKfxr0yMqer3HgEH0ZdO1t+9
4r9q3bUbmI/KlOCbPhCqayEPM2QP+xZnAFG72aw17JC82pFvBdMAsZ6XnD561QXCBVHieuW+ercN
h3nJz/ZqeMKfRKhL+c5VU5NvOjzuzDaSzcEmJsINs0WKlY01kuf1z3J+9g9eC20SZuR0XYtoPujk
PEQ6kR3dNZ9/3wPbFqV9pfkyveIZERpjgWf/Yq5oZ81m92rf1AK2Lvbve/o7OcRaVtOhC9MOVUnr
SVpD9ima9APqey6D8H5i8yfJ53hvZzUNXiNx0+S483tJyg//WAUexn+BkO+EOIUy7eZrLvrHoml4
ps8kZp3c6dAn9WKLnjzgh+C17VRxpAXw9wLrg5my/7ui9FK8SCQB6Mzl20lTUnAtYIGyyurGxqLY
HemW93XYREc7nDzxPNMvl/+CqM2XW3cy9fGgy7yA8Lj5aWuzM8s3lLNqTInOok8+wWI0ujGVJ2S7
Bs5Et8x54sVJRk6r7eNk4rziWK7u4jG4V8NK/0tAvo9rqj9xiF+DQLAXCt7Bt5JK1KP/WY4xhrBu
IZxg//OEwS2tvOBti31oMzEgOzV+vZqsoxOYB6xRiTzxVl+yEm9lXYELmjayN5/eTfCP9y0KNGkJ
298eWJQd30LgZawB+n6JXOtlPtc04dmguh6hqpzU/IGQvXy+F2zAoBKz/mHOgBEU8R+TY3K9S5Ju
4YOgURUxMEAf417YqIX17HTDRHSlWm1eHwz4nxptymNrP1iuCwUTUW0nz8wMg9rbJUNnTUMHFDl7
IEL8otZUE0oENFlTEJKvJWoES7QXWBowdy+3HVvI9m7HfGuisPJVxlg8WowSkIUN5sEy15okJtW3
gDxZyu6OUOE8IfDvHVn1cx3MZ7tWeEIvZtDC1vAOW+OEb59CXZBUb2euYH9C5m2vfHxzW4sPMeaK
Mzu8Cp6D8pTDRdpvW2tVhZdmyz1FHBNcw6vbpiGt5jBKXFiHuFchwJbUuNvvYwEFN9CXnLHdFuC4
7kulBZ8kngCNqIe1QT/pSqg9Emmr++8bVtI3xgCPVUQ+H5HNdybOovoy9RdHB1U5+i39Apv/Bwfi
G85c52c3XAqLi+mPYJ0/rTQkJ9zADj/TQ4ZtTFIPsSCPOaBtVl2+Nr8YlbLA98Ec09s9xfBQGAvk
Mkw/kNJ4/NfLfJYbnLjbelGv8YaGXIQNcbttP4sdqkh1lg6xQUSmlEd71VTRRyRLnRe8CiGDD4oA
i6uDwR61RQSHRH+vq/zwflqKtaCqhD7aG9BcoL8n7Ti6scTbLUtbbljrzHe0BQDNqzjYLs2qCfOq
7AFT6TMAzht0IMrNLsClqS/cbeNitbGbq0K7yHISSdRXX2KBgqvhWv/XXBllbUUleXm9cPohy28M
VH006C4HTQeEgFyeW6PCoeMbHUpBSy0sNKbBm8Wb7Df6OFCeEiLs2qA3zcQ4BOS26iewZVCUgu3t
B5yuRSpt9AfdvOQz4YwnifUYy06w65M0gNg/XXNUPHd20cE/94oWm5uMYp/j1zXER6OqsyMrZHJh
OUm2Tve8r8cslyhqIdwrIAxtHATTWj3H15n0zuawpT1Seb1n6KqJ6erMIVV8LGJ+vV3inP4jvEWS
c+PsXplhaEGAiRaCV/Ss6qwMxqnSO2RArVQoAN9cp0Ke/MfMw6G1YCqRamxvdxz8e7amXlQWmw+v
xkeszXdv5ddfNhFduTgUj0faFT5Y0pP8HlElUi9E7Scpb2U9RdkUIldIU8i/xdTfiXy4R/VDCU9r
c+OPGFEJYjoudFmRndqrvFRwJHi4Ajt3ctr0IQ/Pf8LL1CA60HU+LEUPBpr9gXdH3aFXfmyucnWZ
LFFYvaJgT8Y48ZL9cVLDWOJaN0MiIeXDL6CZ71LIz1KRr6iCcjtNRT8LNkNt+9TAVZX9rDBONTxy
gTTWbaaBgNq83Vsi9FdupMXxXlnMmp9757z5bn6/6q20L6XeM8C5uyB9xvgFF+7es6mGRXG14jSI
gIj2orqQNEJHU5ckg1fcR1FeriOEyD6l/6Dae8gafEZKchZ5nyZz8r2+x4LISbFL791Emom48zE7
86FYeUPLDb8y0SW9RKCHLG2rzJmAan/n9aZYtW+s0s3nh3VRRPiSwzdlxbqreiSToUzgrhmTQsF9
UodX1C9TN/Y+oDIYCHfHN5VI8hwvDflTyw2iF5/7Th20GF9txut9GwpR6V9jpHlFcISfXMIP8Gd3
3po9QtKdhmlprK21dN4s5XQhK8ixfiMq/2W3lUxsPLn9Jbe0jqWlJbZev48N11D81sk6R0646wdR
9uYkQfp93SZx3X7wdfWYh2BZzTN/fc1S9uSzIL6QxRoaghrPWUZqv3zxiTCsG7Ct9Mu1ZT9cnVsk
DPMXpGc5xvanHo7paC0z3DaNrAO6meUzq1zsKtSAGjkUYsogH1k5Ggp/tSm9545qXJSMLSQQ2yyu
CSH7V4PotwczvIRES6tUrikHYjsTxRFMAlLRBHdf4xGvCxEModL3Gqo9VY0hJ7x45u43ivg3yHZD
KRQrLuiArgv4kHlUzdSS7YLyQPTIy99+WyzqjesD9nGNLRFxA4I7P7yujlgjSbwQD4Hl4uQt+Ibp
DJ25T18AFVp2pI8W9Zy5NPfpFiYfQ53mzoqyF4iALPRFXNgOwMZdNzKsESucIMjJCR7gVz3avdfm
hEb/LhV5fRe9pGiyke7onNXdyeeU4IBwM+1LhRVOz3jymEIR0IxIhj3fgHd5HBhHwX1UIZOcPcPC
vVrHOLrslHsB/ARp0lWMOWP8GJ9cfhlB6mMSZq25Ngt1b9st/3ElkO+AgmAeKp4d9kr7EnlDQ1Zt
TdReeUujN8KpZcSiRA4ppNuopW+oze+7i6hwmz8e0RdjMOH7QF2zrEwih7v+Kyls2wyrYpAAYq6b
RHnxxdvv6YLY85WC5inZBo+oFOe6H3xVoJ9AxTTpYXk138SZAPw2Xwft/vJRtjINIjJGa1OY8a8D
aph32R7+8jsGNLhagjhPrbpfgudaCD7O2AllEGx05383x6ZVEwetWhBqw6SNvg3mptVWP5o9Y3Tj
xU6EyBIN+oP+64sHs1UrOBx6/AcsEg2si8SBdZnSW43wNx0YWhKLVsMMtQVSYVUty+1+o9tiYzSc
4OZEbU+LUDxUCkbyiPIFKhbT53aXD5m1berCKZ5fr8VbfwMF1mPJrQZPg6PAwAC2TsrKwKeZEi5A
CkwJsv/Ck8VDOcNwEJQEjDEQ5pz+4svGMYngMwJwMWaHwk/s3HxwyLJT9dNZUh2kgCjiwVOBDYvA
thjW8V7imTTPKbNFRfQ03zjOdmUZMW3ADCKuRax4l0xlBsrfTSGY0P3PdFpmo6E9fobzVYRyLCfT
tZEvTb6ZaKRAkMfM6+qEZiQcrb9bzaTOKsKQCVgI+gjuPeAF/1SMvQD3DaDzH+qgGVHG7fvMx0d/
E9aAEn6iyV8yWtjxUyfaShLzZgSXVZ8SnBb0CPy9qfUpaR1T1H1302vTcJ6b256Hb1scOVPethpT
8fGPod6YQfcRrBWqHnu3LseSClxUsU+lpicob6J1m405OoetPppdVp9jersny5pxJONIa4Obf9RF
mAHLmjeto+dhh/DLHtnt8JEixUFn2hEER94mmeGvuaurMpRqQDWbJz/Q9+U2ooA/zoog7DPcQXwv
98FhD/95dPrv/ZUuRNwuzsPVR5ugbqbIzHb7aqHktD+DYdrwjjd0y27cBc//2Saao+Hn1IEt6Yr5
zcTZd9C5cOXZreGwUwZlXwkBfRLfDjICjb+O/ZyadXvrZeWWV86Sf5qWD5OR+PnGIFT5SOfrogkG
gQWSW4+Q05onVAxkvfpro42m9VJUQnaucazxyQO9ePaIH6QFrbvtUYp2nVJwlk4MXowIiV/75Npz
X+RDleB/LOLQyr5UC1ytsqYGRikytDYGVyp1Dxu/d3Yvxor0Qzu+ObZeMuFWkEQodit9WPqjeJyu
2V+ilSaRd15WCL2niqaazWToIjeiCxuOcE6rpZM+8cj6fr9LC3kZH83r8+w28RTxC1ZUEAhpWr/1
OIm3dJhkOMIKkev+5sPlze6cKwZ1Zdtw8wz3YgHlUdWealhsWPb9wIrUfpkrOVp5kKrGhwGCmCgH
RAd8qNvIWjbJN2/AI+P0CKLiR9KLjm/7gTRY7SA+Xljfqp1JS9gAqZCxGtzwA6owv2HD3yhhMBMF
386cjNI+hqQebHCt6esvBEYG34QF4fLo5PfRSIj4/4DvyxfOaUTYVthOWLLEiFw54uXWcxfsg4nH
G9pNugq0eStd2SRzM9Y6bMXg3L7b9oDaEDkkH1B6/kych1WM2V6hRK3S5IvTFeHfrpLs8rSOBWH9
3JgrU/4Awt6k5b/6P857k3o1BzTHfsHHJ2AIzNF7Y65zHrNGNTFT8XTXLpaFCPbe7whUzoA657Zx
qPibM7ubj1QFGWt/pIMbeP+mb6jU+nE6m5TIpVCJDB2JwB/z+yVmqFtJxC1+v7XlWvoZnWyCevIR
ufd4Wknk5XmcvoCvxuFNIIYUuNuLAFVXNnY1SLLoEjBL8xXpiOSStfj31AuubYUtlzRljOoIVHUP
PVOKMnzfviMbstl8vXGkG11YU69wO79bQhKS7J/ItWA4MaiRb7vXjn4v5Qceek2ssDVubBq6VJ9I
31+EYaRjnck4yZ2+oI1QvrX/gn9e+ThRbymgPCqpyWodT3THAQD82uZFLkQ8dPmiQWmfCYEiKBoZ
hIiomzXr5ayJWEGU/hRU28tfbHcC/p3kuAsA8505DU/XZjWuvLl6u0SWtjOBVsz2SUt8IwEoeOLZ
OGVvjzdG7im3IlRIbBsGQrzQBekxnFu2xDMh/aJDEDuyFPH0tOftO4+h8nRB3BEURiEIgOTM1+gJ
1rS4osJLtkWfvSl6MOozObO3V+N2aBPexO8xTOOf3BKIEIEbgVVffjCN2CNCjTdBmc12LuoHL9hM
GYndvz609W93LIfBUNsVEACPRk0lWWpXy7BErFg1xCrKSDNVBUTCgfAGiD7b0KB2aiYicMBS1Dql
82684ffnRdrkrvUj1dAu51Nm6mT/V7xFtSrFBnJJ033CmCE9uD7fB6C8szlZsgdderV63SGbeuJq
wWzcOZeb43WhqKdHEfz+2GvGeiSZ0piOjy8U47FM9ntQB3cSguxrDA0Il/5KdszGWgWjRN2XtLJ1
EmKpCrff0UQektSHsPJd2IxK0C7bhTDWlRagm8WqlMM/H6BWkhC76UbCiLRo91FjlW04Rx1RYgA6
HX3MM5XdElW9YJ+Tfck/yDzv7dPE1ymxqI3ruovem2FTIUPnXeA7MzrZwNj+9BFBIFv1LSz2mCQy
wEyN6/7mGa/wQFSzyQn7xBnubuCv1Z8nN3Dfu9QE5dpcWJAUafljyZZUWEVap72eQA+3umURWmB6
oYdKuomB5xDEuMiPPqFTQ4tVjMxYAl1IJpEerOzjgtdUy2hvzC6nUROgmsYLx8oGhzY8CYlVTO3h
huo1s+EuxBioZriJpA+ETcyMpp8EZc00CLDYmBVP3KmbwlgO9beDWKoYvdvwWbSrs6RsaCWog3gH
NHDRKxdK7XCcPtHd5ZYbGXbYHu0qBGtUnnimZNtG56QSQuSv5m6vc86vm7Z/tHmZVBFUjapLqQi0
PwlsdGKMF9GJzdj9f67WO4FFmtGgIv4eZ1Fitv1xxDqHA1wgbllNXm9EN8EphwqLGhaej1RyNha5
59TdzG1fRsXBJMlYYVIuWJw3VTerSEbPxTJNgmk0SV08ZcvNC2vqf6tJn39ZUFpmMfGR40kIYtZz
yYt0b9u46u9TDBSQqOrUpA8UTig99XoSiNLb8Hrx79uxmmljEaczzCaUiOyhgWrjB7BEmmHNvZoa
iYn8hydi+O+qdQMupXw9aIE6qw3CvkozpCuqk9Wv5CupBfiUbw8E8vXdKyUWQyClUFH0atR9aC/p
P+iwxtqMFtFglqaf5L7beKkxtRXk9AdEA1l6NR1SC7uFQHEl+dmaatnY9rwIvfLE4fzd+q/3x6+3
+ba2HdOSEf/tyecz8HACelKWnyJ3oApgYT5hypyMn9CZFKBaOLYu2u/hi/m9X0SwcNr8AGyuQcIh
Oc6Pj9GC4VRsBM8/qF1jl0tnpdiI91b3znJUlYfbzS3AQYoctscxOK4zgfvOpsesoBt4wpoPULRq
/0vx2PvETAqfsIwO4w83EvgqF8o7+QUBDvQpGlklw0xMftWMKCP3+IpwRLIzMRCWQDbZuCb7CzFH
yzp1KY88n9TTKEx9vmYPfHLveNq+aEbNa7RFAlVJDLJ3X2Rl4A4KPSN5NeYOxqeVTrW8V4gs9ju8
3GZ9T0cH7iCPU1SCGlS0DF1d0bDTlgWFs1UVxlfoAHu66oY/6c8GHAQBO+xxeQEdjWOIOEaAR6/R
1HF8VkVWNi7yenmkeht4EgsjgE9p4D04dQ/iyfCIuOI4hYbylYuvXuxOHPhNbnZG/Z12O32YGU+s
1tnlUsrDDQ8ZearMUQ1t4VE0SrB574Gr3TYfi3sf7WPltNlc6FtRkjPw11YMj0KnWNllqRM5XZN0
T/EjQn8krTqTSQcl+iS3GeaJfo1xr2Hw0TAQDfEif76AnFjaEzDTK7YmiNxa20SmrWLaG/Y15AG3
oFwh3e737N9JESzkn9Zug6BECaFy390ROO9LrfS3qI29dnnjZEtkeU0A2ExpOlhGvfEhBgRy3T6x
VEZX/5pmNDvlm+jI6lkDEdm6X7rw0o+A5ttWVJqxEnl54vl8aODh6Lb4iQN7MhONU3oQRquvej76
j8F7E4YYNWPEJwXK/q05me6nSOMVJ1Ly1Yk6/LMnENUusL6h3BX1BSpe+W8wTuP07k4AJMmE6sNE
2lvG6Ltdy/M0dU8jeR+B4/V0wDoz/df88WqzA4n1otyfD0B6qLFIp6gn1+jQIlyphHB2xmHSvjJh
Vv2VXVdeE6+IiuFOS8oHQX7NIMUrNq5Ra4Vhnx6sG/FS5UJ27ff2O+ZrS8vpiGsZHOVOfe5a0mDg
pYacCIr10/ZeBZtgnLHsn0l60MLJJLko/MsrXhJHa3C3hLYaSbG3+0XsDW3hmHCU0snyCz62P5pT
7/BMan8VCk9F0fQ+gGNY2HfKeuJPCCuMZl2PcrZwKgF4IqDnP4zbjKLm1gVneVtldv1JmXux9Af4
V28TfcSshlqi1dS3cAJg0O95I3IzFP+VIYhlkkqXrQp8Ql5qBPatdnYyR8pK7zEW07Os0mfyvHVl
rNKDmMYpMKt3mK3Yrj9moDfUTZeJxYidR1C+1nvRyz6Fc/FsyDBN6ZoEc1Mu9EcC8tOZNnXixEq8
jucswBTZiwMI/LNOJFcVpQlqvGwdaIW/y2x1LjAusMDkgKO65miAWV3/8A8eyKdkXp3GyiufQDHh
BLmdsVW0Uiqy55zA7ttdiHaKnEENBAJLnyahQcQTrsf9T++2zvkNsfsqMuJCwqw4oEIHptZ1w6SY
Oy5nrMd6ASET4OlS4+j1+ivSQ1jaP3OPasylKbBaV6YvZMSw4ppAtca0oxDGUeEGjA8jjJd37Wvl
cZygJoPpbfsNGC5l9Orcgk7NjE9GGSFANLrQ54fItCpMH2DVpDGa5HKtl/U4qgmR5Q66KxqoHgS7
z3VE7bEA94rJZarfQ2SjwjnGWIspoC1tjO6Fehg8Br4xOfsTzvOYfk5hUNtTALlw0MMJLJw2Jcg9
qoG5aNUccYTZ92N6DKPeoU9MokqSr3DCA5D/bF2oDtQj5IiVP+PzaceuWeTrE1JGdjtrD/HtO+a7
gnxFf6Ta6v6xdv2RWkd4xiuDc5xTFljAL1a0shmixtrf/nwLdPe/tssRY3eA/hwfgIzu7Zx42gHv
QgeWNLuVqgURUHSoYp12AGDOABYCKGZCRJN8fhx0mvHip0MgYAbTSP8Ah6XEg4TYOCLKhsR35Fai
5NJ7uSDcN6/TNC+cc/p2J1Z9ozpDeyBXJXTuHKBsS90rbNLEYTUrR/QlqGGdnss52eWwEwD84QbB
LJTcMW1xuv2vzfBZHGVib3LNg/RbyQkfurs6Se1Dnfv416a2kBuc0L+Qlt1SEnVPjvxrsuhNzHjG
/Ic3ZoooXRwKl8uL+S8zJ9eAoZ3x2dAAC4EmQKPdJtnRsDAPDuUlY9kAcACw75xj4Ertl0CkD8sZ
VEKq9EsuKlh0VY+bbjZMJlLoTTJYk9clnES+v4Vc6rrACzodHdAXKcZA9S9WyCaXHmy0iwcv0qdW
rlk0SUyaGfvVnwsri/FAdLcY2y07NGD3n+tLNXu3+Gv3FlU8xCZZ7mP0GPrLY5DHFsgfaE0PoM74
ayrGQ4wkrnSxRH1Qmch85Upl2ZB0ePP5LtjyQNbD4G6CYNUFvYn4U6a5bCj4nXznyfVGMGP3AXxV
kd3dQ5CVdZVb5nosFZ4hF7wRQRa2cc2OzDtVexWBo+QTkmHjw9BejEKZQgCgz/i+FIqiapoEwGZ+
btTZuEqZzXrQQTryMfeZmMmKN1XE+7shBRmb88E+MktNpwuopzYKFo3xpom7ieb2EFpEJyCZwl/S
ls4YxVyM/YQ3R8S0VpubeCB8wKgWyOMOe5MxhsKnI7GNvf2x1SFzSajxxKLq9FIcuLBFuWrlLdNS
IzIJNexby8yiW3oqw/UIyAm0102NeN9xkSbNeIDjvdyedjZqtITI+tO5nccWSQzS0CFxsa9bz47p
yzblfdCBqBz1WAp9W2yFnNaZxSWH1kOjH22/B4fcN5OX3wp6teFs82kcUDWs/EGjsM5Hfk1biQ3D
XKgVbSl+BPyV/+2vn3/i6fpBRI18Fzlh/ezBCERE6ECarObab2LDYG6TYgdJ41fvV6xH+Gk5LYEc
JAQry9hAL+ZsAJ2Nret0P/fox6r6/44TH0YDCL9Ke5VLlqqq55NfVaJvnEb7wfExBnrHMSRMfGg1
ApleorGKXI+1fhw2BwV4UIPk/Fxso2gm22n04zy7wxCZr0pLN8fbOoBzuaIJq09lJIJc+Ejp8/56
RT3Rc8fWwEoIrH+MdxBjaFLrbgLqwHgNfc5OQdbGVBrynarvhdZlgdCocaw0095uV125FlJ9xmyc
nt6DiKmX1XbnsS0u1urw3khIy7GMLph1zBnJDG85KRn1iNhumsKUBk/IZidEmKJUjzAq6EfmpYFw
fjpGTIQ9NJXHKjCcHDfPLlG5s/GpeLoXaTPzGaeSn38RwWlJzMNszsKOTT4eF5BlOJ/4dQPlUu7r
9iDuNTfND80UtwxFnGR+wlyKjUECKlPhacZB/gcF5CntdtfD3NiHQ38p5sz4GGdy7vVQkUYF5HbM
MooKvyhXwE0FFxnubx/yE1sPOlT9iujiL8ORmfXNaFmkGWTTqPLR40IFLXG/wD59ZiGO5w7eHBFj
JU1U7vmMuAvNzIyyD+hnr010BXtvztqLUW0N4u3DEwSrWG7v2IaWX88WMPgxLDchaaHdoitk5O9X
GacmC2hdon0v6h4Mtu5KSx3KJ3OIJ7A7SFJK+jFNPEfjVCLYrKaeA6aaxU+8pyrvF/8kakVZ6Sdu
Ddo5MksHGmnhB3QCY8dyEUf30ATfntHVsR9twqswCYkrAe0KOeZ0QSxgplixd4JiC4UFZIlMKfO+
wz5BexUHXSoueQWyH5laYJ4+yS0usYezBvyB5Z4MxBrskdknS2CdJC7RuTo/noJjkdO7DtG3uP0Q
77KalEHFtyv2Tpi2YkAMHpIQtwQM4/r1Kq0dkMWmEN5E5hfdHgTlX8CtyQU82bGxMgYnnuczbBeJ
tNB9YVMQAXpCAVthcJUgZpXjkl1E8r4uym2SeBNovi6/tB/AmSRlt0YTXnZQr6cFKGaBhvSBgtq1
SUTP6fYAvWhJyYbMHpdJLuBCEEoghIKRnAQfbGKIV/9fVsLU0Imj98B8Z4KNrkJRBQ0jtlLu3vUr
+6ZMtkh6BWdFstduCigYbmHJV1K7S/3gclJzTbhaBXx3acvJw93u/t1nh10TjAoxYscS25XKCIf1
+2PLQ4RgGyn2T+BULYtWH2p2YQaZAjLVZW1hmyx3L2C6+anA+Toj90KIUtym78l1fVwKxBigTnYj
k/P6qfGy5mkhpigb6hMYojM503Vw8+K+tTqg0P/yNe+QfpFw4SJrWyXywmar891x55ETxCo062/U
0L3XOobMuOqqCCh+JkTz6SyvXWnDxSCbnG++lSIV+CSeNCR3JKynzZt69JIIRdA6dm5AK7i6n4qz
X+3p3SwMWj36K14vCgBdDXkcgLkmRfElFbBOnb+KBrPAaF2iB6Zo4C3P4zUn5ksQp2MS8/t9TcHC
0j53y1jFJ0XYfdpM3FQXScs4+U2U+nTfrfdkBcDXXXpdFimLEw0QgfPv+w/pNOzR8PmQleWDhnGZ
+N8mQteLCnOl0YYx73R+WuB8JWSG4Tq3rF+hJKmOQdRR1QoB/yL8UtXuymB2ahPJrxLoLxaRjQ3f
MSmmXtfxWLbSj0l19ZYUIH8+jARkDHrIpYJDZ6ibBSwaZmLX19ev5sX2RKRAN3ubHZMmZZmpCaFJ
N2k7E70p8Me5TDGcMujTWfy/fepkbM2LuMJmoxLleB2FYTxOsFtth5ihXXZ4+sTuVmcDOLc2FXvH
/iMTi8fKoLg5LUqfkrL2JAB9qEDx2j3VeFBWMRGZlwdPKS0ujpqEQC/OsYPYJip/QtKr7e3TJWop
nzdbjOuNjQHK0CrG4tkBf11UIY8j5HqPUjsixSXYtSQ9PX3TsgW/GnyDZ4uK/BdzNj2dy5gdcwRy
3cC/x1GBn1L1ww95ix9owJSv7j9Ur8K6ELcqeW30DMqc7/7bD/dQU+yCCXHRehwEdIV94DYbji46
SBL5hppml4T3K3XgJG5xh65YHx9A2SwJBP+/8P8tR/4C5Bs94VjnJlJX0wWOVSrto5rKvzfs2KVe
5RkfU3o1LhJxCBKUy3sP/P2ZUqxCUUGz3bUXePZfp+JjPRByZvEcQlqNeb+wfeFrPlWGdoV4FQiS
VbzjzrI4D8qu7In9OVU3hF6DnNkUXBeSNWh4bzQVtEAbF9puriLE7c+hkHIxr5n9O3rhpHDzF8uS
gdYLYmpCIaBHBrIjPH9L+kFolPte8mD/NOV6Ra/L8qmOaguwQas46BtVcNT/WQLx5HsYbGbwEujl
UGR8qcKiGe0cGsA60RZkeOI9+rvlBu0IV7O3lXhTgWqKm5TmgrsNr897x01+rOFoXc3+J6OI84jV
lSkrWFy0LuJKj6FCqJMZp5T+a7Rdpa8gCbnI5oBintyLyfHHRtbdB6kH562fd38uuN7Gkh1IG2zd
+9wIPT4cnVLW2M5lV2wKW5tESrFFCfgM9jZF4bj633X8pmn6ompqLahCG6NpwyXE4K46iGPZljgx
iz8J6230EU9G4DV1EHTna7Xpv86bZoF4VDQBH1XiZYPA2Wr6ttSstwXCyqhA1EMkUqVPtOqb9/YN
fIemOjN8bg5E3rTpEO9mL6DtDHkMzZvo85OX9Y+hapLgs0a1C8dcK4CnrjdGY6RzBOdtAVe9Q00r
its7zHF6t+bcN3EDtFdllBuKfFKosxw0pgx24aR7BjFs/CMunKAfnzEhjmY8aWummQKmzaRAcIKp
YSGCTCaW07uRCE323z+zSR8tLFy01ZLC6ZGyoL5jRAz9NM5smq8AkSU5Yrjyxo/eOtxOKw3os+Bu
pmBAQKL4oG+S+INrAer+YS6wyZI+4LKF7m9ws8J34zj/9TSEF7f/65ce42zlurN7Zd+OjtxTgn1K
LCfMT/LTTBiTfgfbfWsQIu1xS47IknmB6KJajQakMn+AgEdNFPBxm32DLGCLxo6booHWz+U8ZfHW
qnqvGGxooLvWS9rSNcPf2dJ78UtT9kqI2SucAWTWDP+kSKzQ4dSQDo1YaBClXB4P4QZB6NwnSOgh
D3WjCg30ZFXtBaugi0l2tozrJsWeTLK7/CdDKbqyUYze19PPU25vSb/vP/zFkXUFKCNy8+fqyCyb
pnH+1jUF9JhK42PYP5PGVGp56vfWjjy4yoYRALmA6ACTkN7zrR9xFD/+7eGTGi65rE++KallHSsl
PUnefk1wOQZHATOr+plbqR7euK8oJ3QdNJkWZUrhLXgOQlevPu/OK0wO8AFd5gFOcFdoNbJjWGuB
5icgb8d1p8Nt1k9l7889sqIURLKJ0PzeUgPJDvEv+hysoDnwb4md770XqHVOrvPguGvNzXJa6IpQ
2XoX7gfSzQL+V9kB68IWzNxLtxAcXUv/+p+kJG220KAVl6KnHPkSvkDa9teS5SnY5BGyxhpv0PnP
c+M4jqoshADgLwjQ5i2vjKcH85ogLlcF1NFkjiRyzTNGL4UTrhkH0oi4fdHYQHdjYdyeN5RpbTqM
wmWmmuVDft5DXWS6OWfraaiH/9P0fCwmFFeZXsHFuQ626PMtK7q+qVzDHHL5WXvTLeivFBQvHF2j
JS3Fpacl84qN1YSio66prUJdgraZ/tgC0TsUvte/Lvva5ymyAex8kGVIsK1mcPPCjEs6xaK9Xwec
zaIsXxmPexLaHvwHdaauNfjEi0OW9TcWlVkrU2K7NStwUbEc3cEuFxV0ol6KXZdJlwbVz8rPpVZj
xx+FB/VoW7hgN0TpJ3Zj3XNoJkxWIkE3kGq/b0t7CFZYJr3/6yxeK9bLpvrxQrq6nOlZt1Nw4kDg
einVXr6qSuVb8hzvaK1m66cG/Vi2MuftBjisI1A9I2DAQVpTbjrd72s5IqUu1UZX3sklgnwYYKvb
q5fzxYM11pb+E3AOuZnsxy7LsvMv1c7kPqUFf6KPwxGM9u+n3kQzo4vPsBq8kcuRjLFL521ioiPA
m/L0TGsP7cop2z/huwuMTk8sMhqCTLnM4fGL48nMtGPxsCU9XSOyoGIJx8MXseXH52NtNHrXOJ4k
wFhIHVwcv+Ck/lQ83sr3vtbjMWTGj/5pLvjS70whYLwqv4ykqAEhvCSXjKQHnJPIx3wqq1i1Y5rE
XFGwVIkj7YgA5ps3OdNpJmTDVqSFmnB+e0GZShSNO3JMWDXr4YMBhqg9Sy8AUQqAM995DFkICoXO
fGux3IsyhdE1XQ5LR9nEobiLNsfn7+F335q8N8/SH8Gnq4Mcinuzbq/Zuih5CEZhCwIMQwnXHjEn
cEY4Vigj1XUISKhv3atc18nR/SeNQVlJ6acE1t0CKxd9LlueM5a8EBBCZyBiJO9UDd+MSw1q3wL5
YGSNzTEdG1RudGWWbDW7mW3TN9NK3c/R+STGqM72dvGtEz/anlj6bQjZiQQPdVbG7WxagS3QSO2N
lAaoUkVcf8SINmJaWWgBu1W3CXw7OCb3yyAbN7mnDE2fDL0bOdcv5MG18yvNndY8DL2dal1JqM32
DqwXlgT/OCW40q7wcDCshiGJtlH5boF5O//7DTssxD6+fc4ZqgUPQ1J40YhSVV5VlawSH/Ql5H8y
zsn3XYSmOD0oOBj+7gRKgUcC9l5PkkNkSnxcMiAeaymfm8+hRbThKqoiPqqwh95TjkRWiHF0FUgf
79FyquVZB+VIxCJx9oY7UQ07cuv/udZLBVHSQw5+GhE+iHb+xuHXMSM9QDm2rSdOyb4c6OD6C7x7
2ehQGkFNxlSb5TIoRJxLlQDH6S1i8KGDsgueHLOjrV17/kJlzYzLn7n5KjaC6h7DcDMLU+sizUik
iJPsAW7Y287opFhWzuBzCIbofgVZJX/5iAmXaVLsjcaYj2WpkXKtwrQ5i3cqWMEi4bG1/VjAKSvK
RJqzqVaoiSZe5JqkWfhsNOd5xnw/1To4nXkyJRUmI9+Xj3MFg3DIM98C7nsuqzJdFO9V7DVFBzfi
XR55qMnL6GPAC2DUI3b9qpAq6LPso4/waut4WAL8Fn9d/Ws1n6xDq9wnERHfHHvIZO7wVCb7aF4c
h8Cf1HyAgmgb7q9MPGNSmQ4pmSdUrUUD5mdZVOp3DmqkS0MORwmYIgYjpPzMjjcwoHr9xRqRRQEh
uZxm+f/FGQ3y9Xa4cCA/BxcnfTts2l96N97NQKhr7STM74FjiC/V4nCiAljJJ2vMscjK2hklJgX4
y+Wzp9txNeHN56Y7Dn3KVLx+tloHWVz4mpFH6kGxBHou3Oxk1rxc4VUPqQDJpyuU2945KTY2P1KN
kzzHIXGwQ7B3AOKQ7t0yCJDESnh2sqHpUrwGehdSVWegs4YRd3Dt5cCRm3jWBCzCFtPFNMbkwvZI
bvS1s0EiQVAxmW46DYo2VD+MWPHjpmPHtBqy64X3uKLEOI74S1wQjzQ7iP+A97UOwomyZCcz+hTe
8kWnKqvFEpuC8Q0fMlpkrsqtK84LtTfRIPPjue/EHZ48nEKIN18DpsB/nOGxCQQE6KW89lvmrEP5
Pb0N9mP3TuLV/h5imfdKdKpM9v71Og6qtpn0FcdmILxpohppDPuQdwY5AR5xcm7ic3XXYt157/P5
4LJ5ubOaH2kxbgcGpGk9InT7ZY6/aR9FNrfR9KGdE5VXC+uPda6dJtg1QSeSWEtmg8/J1fiG2WcG
FRRqwaC59uBo6Y4I7FJHZLcHTbqaFrsZcQXQRndg0H2d9CtMU5izlw+o1PKG5KuVSLubx9gd4ATz
VpdQElSo5Q+S5ngPj0qcnqE7eAJ5N/GP2Dp+JhqGqZA8/V4QPnMMUIpAlV9uBWDKW0X84XjF/JGI
98cF8EWXNw1lyJx8Mqehn6Mu3zLi6ZP7Ter/lg/oHK5Pe3SggiNEdWa8Sih0VwzlVunHCkZJ9vgq
SCYuzncwfwv+LBGi5fy8874Z9Okqlw9WcSrVEUJ58BaRbs75ugNMBfd9AbimgYR3pPEyUmcPWpgF
/5OAPFsOWXnJ86QZeyL72N5/gQqXxvjg2AsQrNK5icDkD874KBYt4nUICnloDiGCZbt5/ryGHkp1
SElrddSe0jMW+1smK1vQIZKSto17sbBReJi0c0PHi7yTsao3BWz9heTPjkbiYVDvMXXF+ZdskwJG
cFNWFb+T63xwILS7w/A+6wqODnzkHc9SsW4IIy/i3rMEQiV+ezTyGOkzSAYVIZ4Xzs8egWOmCfkJ
+pValE8+kBKLYv8hjxHfGEuEZSksehhbCLKhv6vGNeoVey5Gy1BySyyre/KSlLmx7yk4Ha8AYCc7
ajulBydD9BIVK3Q53x5ZJwHAgus0vFvIvJvz7u6QeXN7RQo2rSClxSm57DRQ59MVh/uIXmW6Id2v
lhr27m6+TjH2Gg+KHg3ZFQt+YlY+ckaxzZoPZKwgD8b9jDep4OnD3lZZ0VVYggG4RfliIatkVjW0
MuGPSxvmnAmhxoW6rXmob0xYGILr8SGAlCwZOv4Ca/CwSrm1zUAy6ETBCuExn/FCtXByuQXGxAJx
Le1fB5FbWZBA0Jf1kfnnrYtP1gcdK+B7dlRBulTDDscTD+q6ackkPnpeQQB8SY339aISiR/I+D84
95ZRa2yUHEL+CP00JSm6VC4LTvDD8k62bxEN+roRmye0wo6F9RhpxIr3MAyTiRGMjGiNeaO7xb1I
M1/X+clJYud31hcvGmnnkqYuNoRVPPgTIdaWURM/4XiO4BQv0lGot7NVHAOG0BUq9g/1aN5FLMor
ykRQ/HljuksBTSXUR/V1OoggH6xfy6Xhrr97Tcfz+4AFfAP6TqgzY3AgiAKBHG7MIjvtR2y/N0Mx
rQllSNrr4H78y1hT7t0EVEGi9NuFlp2EJrV0DvSSBGBmoF2VI/51ggFjoC0lYAIYq9ftGfrxDyLH
eWu1hYH+8W/3epXPLmpakhgQ+gbUCT5a4Ro8rHcxxO+dbZlbr9NZsbIbayWAgLhIDyYl6OUpTqoB
r7a+AjjzA7W5PDk6c0BGMa1/fiFi8expb2AmCtNZaYbTi9HWNG9zPJiyWGVpNPPvrLGA+OnN61X+
PmtqtgNMpmRadscqTn1O0HvbeHTrCUMt8CK44OEKGJi5O1JtUYZgNpDHKrypQli+cPNpUM+FANpX
23l9WqOzoPFMaZuVKNXr3vlTqqz/iHfvt91T3GCP6PiBlcG6UAW6EhFwV1ZTQTHhMNiuQOAdBY/L
L5woG541cF6jehyEwFAu46cG8uPjCwuzufk1gbbhWIpNdYQCG9yhCAHoueGcalsKfWV15fJI4Dwo
bYzMJ5GxEc2Wyn8kTkZDNam4KSRqNzNDXV2Jvjsud7exyerkwR76SrXQpIs81CfY47aSFq4JA4oC
PBDhJppfP5Wd06N2rBARFqTPmUOVsH2SoMXfyX7P0S37UfJ4S/UE7jsgPllJgf+A5Xzja/MoteVh
QlavTiOohFZTQYC+rw7CzgxzfTdl61sp+09yR9JusONTxe4Hfm9HPIQYRz6XO6F/QSmtZ6a1P9qv
oHlRYOpLrNHaV62rBdC8LIe+jVUAu/nTp8js+9S/PR2zRKV/jF854oHBkL94FBAkTGoiMl+vvasi
xwtvXLQOvIZWe1lRHyp+TT8iD30KVaZqBVKWyFCM6I+c6Ix1mPCSX7eGbozoT9k3oWxrhdytbvlx
Jsn1I/HtIb6oUhbEVS4hTrsCKK2L5uKzqCJULM2ldZoFYiUTOHz43iCZRD5AC1AvJ5pJZl7vfM5A
QNMDdeLohSQZmA2uHA9sH/kGRiTTMGAbDx4bukqYjK3TUP96iF1iMhV2AOQz3DkQnTI9dnVC77Fw
dohwzYHNtBCz5r+GrOj5ty74UV1xkW8KcNKe+N1WZCKcVmEj5ov2bCNeVWzHnHNHe/8TQFZ0O6RO
LQ4pd+9a8z56IySr6399AWlLgcKh08YddzkOtKw0EOqzKL4QVAJdWAMT0OJ2UZYriDHYXqdNjDs0
qlPGt97TdUQ6s3R9oAH13nHoNgvOudJay8SeQWD5Lr2e8LJ+KqHblay3d54Wi2ii6DirqV1SX10D
CRbqJqwyebwnuz/3i9ESiA8Ht7GOBIA/pZNp/3bHeM4OKu/J+9gxBTeuSQF+DQd02x9wNZ6elMci
n0APv7lPRmJ/yUB644XRbLYtqOqbnd90Tgy+WYl8Gp3yf8YQUdbV5hVU/5khOG+mx7mrl/rQc9lK
uzm1F3WPucFMIV6zWW5pcTNDEVAUkqhvDnjLtB9QYReMJNK8DQsWPrPyH1a11fqTYXjIhCik30jr
mMDRjInFiJjXhmtzRlSHsiYE1gu7hXsodE2Yz+GyRDVx3UUkoMkQ7xSSX9+1cRnGzGP/ZYopUZwZ
pVSgZJnBJ4LS79MMJ2clhuuQK4eZsCcL4F6WC282r22PxQpbwOPqGkfn3EsyGYroOP04qbAFItzb
DkV5t+y5uNGFFmDQi1XZnBjgenW3SAt4tVuLhM1vkPTq8ZOnz5xOgEPHA5m65wjCpyovZIs5Q741
wjxbpC9QSfb5ORUL07XpxvgEAc57TUaFg5JZBUPPat9idy/lEkjIe28Z17uYcbRce3ivhnMdLXi3
EBB1RoR+HB3C3vsEsOo/4VPwBzsFYmrMXynFkjHxi1XbZ65slWfajuTr6kcfxK0/Y92XEDJ0LcAl
JLmpYGq4tbnPzNXRzcWO79f23i7VivBuQOe42wlKwHG6WYJDMxfYJ5HUUVOdwB4IPAVLTrEoPb1d
SDPBCTZ/t0PijZ5m6QcfEir6sAggikHo7NRgV8TLb9ZfvSeudJjvYDcw48FwRZUZkbAALQLgXv1w
pZ5+8Zxptrn2pJ1cQQ2AQfLX3OczlQko67g/80boW1Rt3rS8MgRfh1Qc0GTbQ+yIk3KMVeQtCZjK
ZPgQdcYztPGhgePW/e0kpn1gDlMj8TOe7VEAjJuA5AaOTAdWB1sc0uvU1ZzWIZotJYpcObgtVzet
whkw6kX7gzTtb62yWRguJNptPT28O92IIUmkX1oaX/mPT/tuMIjf8BMbgeJ7HMK/japhlPdLQf9B
d4VqPFILTGNtoMaYN/Bq0ke0kJAQuFgTHlDhGUgs7Fc5vLdotlNO7Xie64sjLVZ3PsfZs0k3v5MC
z2JYM8VVNzEk91/k+NwuNllZlIJxkmOC/A79ykgIkoo7QesascmJYw8Kh4AYM2GFlFxHa1msFrGJ
AaycE6xr7ll57eGCGIJ6EzoJiJBRDLGwWjYiQRcBtIAyLBk3Ic0Yd4lBSJ7g6BUTwUvtaxWH0aFw
UbsEaFo8kt3od74o4uMKWHcjcRlCUbLSPq+9BAx2scBg1VVW73AJlQBYhspyiYP9kJsoX76ZD2j/
ZOTcORgFoRUOvWF1cSIU9tzcMDJo/s1UjZmXD4GFAKzwBzvn6zU2qOD7LRjO3ZchMJwwdypQaYAM
O+G/BqYX/FJkeS/t1rVBudUFJei6Y0vTvLRHl5f/kidIuZqWgyaOsvju2X6KfIYmFfYxYdz3y2LX
cEzE8trAUgcqnT4Uz2C9yK62yxhDk/nz0xWqlFVhaN6xfDHEDUZHS+ZfRs7S6WoLzTojqC+mDU0I
b0WRL6csKBpRwVN/gD5X5i1WWGL2OBvsx25ykngHTVm9Rn1o4Waik97JYv/fK38wmq0LGKeTjMRE
WqsNFDTWvtNPd22OcGRHtbp4FU4/VzemFpitOpEbxUJyZSchm1DItdVZpXrQcZ2CtcGeGvHcRyBF
e1yYHE2nj6bm1KLCpx3bqdPY90xz7wqceQON2iRA3OyHyhL4PZHX66uqii6Q5nASRVUCPcoCXNM1
lwehUTsATfJ4dL+blCgzRkAXSMYJ6+ubN3BJmcpCSm/7qSH/s/wXpUBZtCiKQ9nXIoNVVRbLDXgn
jwvn1w0X1e+lBXFdi7BQLNiZ1aroEN/Hqnkt1W/h5pJNsOTjXDEC/SI/XscCVuDrQF+s+TWU76lt
O8jkMcdanyz8cvDfgHudpXjsPBLoNd6XlGrfJBmWdqjNVaWy0eijVswEmehIukSZG85fISmX186H
7+iEB4zPgMl02MEZ0WNaM1AFJR/GA3ZVkLIcLC3sKbT3l2oTc8i7bGlxLkMX/AGrAF3EoJQNjCqT
HKLPmh9OBqLKCgstw/utI1Wlw/ZxUZg2cJXRAnq56M65u2mwg15t+IlVgkhru/3s7iuge9dFVP4m
xOpvnV4/TNF/r/anJyRwA5HrMXWZ41XK+A+zpbsrCmeLp9qXWQmPMkETLLQRXV4DbsGsVQGWHaKZ
pHEn1rYhXn1b3ZOtKlEntr5AgBMFiSWs+kIKzFfMrXx+fPdYr7KKzbXff1ehZBd6itaTV0Adf07C
+YXjI0TLXR/oLt+hx4pg8elH5ydJ+I84o5ABkJzybuKFCcSe5xAZ4IrxQG1Vn2nr6o40r5e23Vux
zHcAIkqPBxMZiTq41Lbz+8srVD98D4PS5t/FAPB4HBU6R9w8fZkNZW5kc3RyZWFtDWVuZG9iag04
NCAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0FzY2VudCA3MjMNL0NhcEhlaWdodCA3
MTMNL0Rlc2NlbnQgLTI2Mg0vRmxhZ3MgOTgNL0ZvbnRCQm94IFstMjAyIC0yODggMTE0NiA5NjJd
DS9Gb250TmFtZSAvUEhGRUhBK0phbnNvblRleHQtSXRhbGljDS9JdGFsaWNBbmdsZSAtMTUNL1N0
ZW1WIDc3DS9YSGVpZ2h0IDQ0OA0vQ2hhclNldCAoL3BlcmlvZC9IL2Ivby9CL2MvcC9UL3plcm8v
ZS9vbmUvQS9zcGFjZS9yL0UvYS9mL3R3by9oL0Yvcy9nL2V4Y2xhbS9pL3QvZm91ci91L2Qvay92
L2NvbW1hL20vdy9oeXBoZW4vbC9uL3kveCkNL0ZvbnRGaWxlIDg1IDAgUg0+Pg1lbmRvYmoNODUg
MCBvYmoNPDwNL0xlbmd0aCAxOTEzNA0vTGVuZ3RoMSA3MzkNL0xlbmd0aDIgMTgzOTQNL0xlbmd0
aDMgMA0+Pg1zdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogUEhGRUhBK0phbnNvblRleHQtSXRhbGlj
IDEKMTMgZGljdCBiZWdpbgovRm9udE5hbWUgL1BIRkVIQStKYW5zb25UZXh0LUl0YWxpYyBkZWYg
Ci9Gb250VHlwZSAxIGRlZgovRm9udEJCb3ggey0yMDIgLTI4OCAxMTQ2IDk2Mn0gcmVhZG9ubHkg
ZGVmCi9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL1BhaW50
VHlwZSAwIGRlZgovRm9udEluZm8gMTIgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDAwMS4wMDAp
IHJlYWRvbmx5IGRlZgovTm90aWNlIChDb3B5cmlnaHQgKGMpIDE5ODggQWRvYmUgU3lzdGVtcyBJ
bmNvcnBvcmF0ZWQuICBBbGwgUmlnaHRzIFJlc2VydmVkLkphbnNvbiBUZXh0IGlzIGEgdHJhZGVt
YXJrIG9mIExpbm90eXBlIENvbXBhbnkuKSByZWFkb25seSBkZWYKL0Z1bGxOYW1lIChKYW5zb24g
VGV4dCA1NiBJdGFsaWMpIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAoSmFuc29uVGV4dCkgcmVh
ZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTUgZGVmCi9pc0ZpeGVkUGl0Y2ggZmFsc2UgZGVmCi9V
bmRlcmxpbmVQb3NpdGlvbiAtMTAwIGRlZgovVW5kZXJsaW5lVGhpY2tuZXNzIDUwIGRlZgovV2Vp
Z2h0IChNZWRpdW0pIGRlZgovQmFzZUZvbnROYW1lIChKYW5zb25UZXh0LUl0YWxpYykgZGVmCmVu
ZCBkZWYKL0VuY29kaW5nIFN0YW5kYXJkRW5jb2RpbmcgZGVmCmN1cnJlbnRkaWN0IGVuZApjdXJy
ZW50ZmlsZSBlZXhlYwpH8O0y6mDGopMcBXVx45oyEFuo9df87vwnlSxPguR7R5UjKT1WTF6mjSMB
ZQlJ8wGqaLKYjIr9+KWbtQCvePwxj9PGx+fdZi7Ohke6t4yMTJhmO1hnFQgvFGccuZd0EwTm7jRO
nlqjRPqTxxPEa4TcAPYir18iLrgdHqMuvFShfjzvEiZDDbsldLY5Y+xLsN95o9pMrZuhKBRGq7OK
ip74pFazzYsXS5Flux6/HTd7ivod2xnpy2nvrWdeAjOYPKVNg21WNvQv2EG98CcV4qQAYWmMOgM0
CXQVor5daEGzKSWpi2rpzjGiWz7UawKrqUIqNic1ZGs8m1ZMSnMGnnNnlCPLiA+wJwLZa6cCuXc3
H2HpOn7ZUqNNSlLBZutDEoXS06KonJsTaCqUep170GzJdvOFi9xquNDZEcQTIBZlwkE22XPRTbYK
8m1TC0r8fjDwvgRvXP1S5DS5/tIX1OXbD7ucir9GNMk0cTpAik/TxqqmsZUi97iHXTKNa3SpBuVy
l4K5uHnh0h8L49AQ6ktvHrWxaJZWQ3X9Z/TVM+LrGqTm+oRfiFKubQ8AHFCSPmVxdMdLkvAvqAW8
e1dnGjpLbLz+SZ7WtxxqPmJwCA3ksewp61Pnz6S8AbEFfqCZnPSdQ5/sRvWePvauWStxVx0fRAdF
vvk2Sxc85mNZN5yGSqSTXpenpSpkI31C41SjeKxCHn69gi3MxSC0Iol2Jime+K6ypXc9LU0KCmQh
XPDdEMAYOXg5ttmxM55kKViDy7leDVD/7wS/vWK6s4zeKivrhADJfU5f1a3j/LUgCTGEm2n5WGa/
qmezCyC37Li4OSyVIAtSgHgXxvZSlw+McbQLZzvKMHDdq2j3oUuzoCRq6+gfmzFebzIhyEidFjBS
01a+b5Lv5hg1M4KwSj5HRdJSRMDI5zyywpwAv5t5DMFYTjiGlc7TCpCPpB33oGpOjw57d5JadbcN
efYUpwhITYX3gPe0vusKR6BOctNR+kF6pa8LU4mNO6se0/kGgLaw9rc6RCi3/+MvQRFGL15YIrl4
0qTe6tuF4Ey6Iq7XHEP7pjpxw8Goi0qmIc+cGi6k6WLe9PWI0YmcyEjIUE/ZcGTdCqj7gAoyN/Mp
TbRKbSUlMm8w21y7pqRCbumZtaJGH0ORwyqbJD8Rsi9IWLufR/IqyRu1RJmpsrp7C0/K3Kb3se7o
GXg5uEX2OE20sgQe1Q6Ha73/sj3FliIfkheF4S3abkZiizQIuIRTS//tZJNr5iz+yxrKrgPfXqDP
Ig6GZ1NTIgxONeelbVPZEJxS1k59z60U0kqI3aJd8qajaizMMJ93RdJTYdXqQUHB+aL61WnW3SB1
uUPfDqWvXLsSd3J2P4TL8mvsaktHuLfjf32iU0U0Py62DZr9hgNtsSLluY9W5UHgwIgXvqs9sl8G
UggeOzXA2NURJ+mvSbUwbYf2KB0ZC2fnosZhP17w33CJQVTJO6obpV+u8nf8DvpAS8AnQ4acTYzV
nML/H5TGSxDIl1Be8AAApfeiRAWV9aG/uG79ZLoCFyJZgGS0dpBJ086qZdrVgeR98NfV/5RAGhJY
3T9ODlJ6sdqLxGBtOXyvc7QCq2m6FZbbgHxDwTvQe6bu7X/k8HlVblRp/283OXxi3xYe0iUldiKY
cyAJWtvZ0EpkIQThkeDRAOr2Pv7tM5yXFKt8Q8bCe+xRJvSpl2hylMEWlHHJF0HhT75ECN56LM/R
FK+Lsla4FEsRannSDrFTgU8EL2PIEm/hCMk7ciG3Bec2xbt1lqY6oAMoykNqxwpH4tGeQznJVy4m
8QjgbepNAY51ZPYO8FDFHQJcYK+p10xXuIdb7DUB1awFG5GkvRNBVT/FRBN/JttwGRUe6+ifgZHG
mLHXGlThjVxdGBoc507ToWavmtcEY+CWtbC1wGCUKtwcPD5xm21tULDSoB7q/GKwT1U7bvqO5b3A
WFnIbxLhzlzzIU7JthNxy6x/WrzAZezGuH9QTmzqPhd4D/IN1jkH2LC6ZtgdFiq6ts8cqg/on9fV
6fB4JIcfrN51IkCKTDwnv+FkRF2Wypw6eNdtaVVJBK5/+GpUUN9SMnpdQ7uwHIK4bukbmnykdccd
n2UV75peAOYwISBzW0DYRTVEZFKgoNteKD/65J1AChXMIoDYBZj33We31d2qn8/3OxkcKdre5TVl
A8qwPEq6GJa1I8tFAdX6XhN4l16SflCJPm88VDIbsynTatlcLy43K7toR+KTOAejW+3i17ZB6eBq
2SmXaoiFKs36Z9gH5GxAQ3cHMXbPm7N/psqcLx5ynrj5o/RiiijS+uvp+SgIeGCDI12rSTQCgQUl
DiLQlJH+1D9DeEydI+j0iHLM45B2Utl2SvI4Enr8uPUxX9BffyGWbI3oT6waavkRsVEz8dOjuXKP
EAnml5SsIPcdTG4O2LP/TqX6BEtwS3xKptl0y7hs8m3KPCiC0fK+rwCHJReg2zLm7SaKFGr3+Yab
NnvRMIq6BQdE80lcxuR3aE0NNdsOJSO5kdAPCt7HkIlm3CeekOOcykgET2K4vYuT5eq9gWKoWi8G
7cwztQBYzhnsA7Q1o1fA6c6xAZOEJ9pyBHcKP7u8bmgjKZhiH0KjPGR7+5VaEKNC+9HhmfZJL7Ko
igPzEXHXljuTWi5h20FQGzOsQJDKbAykyllI4noSI+Wtr7d5uH0n9owkcAAdK0YO9/prrCUM0OSI
y62cm9EqqKo1TDbFOL9XkQoONAuoAcq9Tx/RbcSYLqVWyFNpB70VIg3vLK1yx+R4CFxCRaWFe8Ap
m9UY7iiyy/RNx1svol8NsemznSntt+x5rkA+PJVOCQPJtDO7ZLlQ+rZdR8WB667cxr43VmMnOkCG
g1HpmVbqSuN6+FO9Zh1OJREu/56kgyNP0jcej++AKWI0rPhmezG3fhmgsiUNOKbySK/lqdtWYDWA
X4ES/s0ag1ZaQVCrGUULTj5MZIYBE0bQiBrC3tTe1+ZLCKAJZtbNehxMrx9EKwHOG2bgFj1t5L69
294KhIavcpBxRbstOkQ0QZawUiORYrw/zj8jWrVmUFQn0C5NiRnuqT6w0D/0OhRheSPT3CNewbuc
q7W9QKkmFAiTsCNz8sOKr1bOMv6MB9TIZDTMmd7CP6ZfAv0ckvjH4ypXBlj+imfEq4v6WQNe58CW
blsjkZRVQXyhWGTcRMjGuTOr9qUfxiAtRVD8IHNYQxXN/BHxnphAy9Ymiv1UkP75xK6v2G+3Tmbj
Kik4uKsSs+UGgDaBKSCkslbevJtKObYP12bIFsunx0aTgEaIBU3ptb3rbhklrh3Vym9lhWAF9F/L
X2ohiPIvAfhX2M7XjCR16Uvb5oc7vtJK5iXZTTHPhFtfy+XQoxexVcNezWPJ46ba5/DnICbdfjEd
K7nCkvK+zsCc/SeyDsfojc36UyQWzRNFepg6mun8eWAcSeWcWKRBXf+kae2eqntJo4YymAvZA9r3
Dt2PyWnKMvkpgHa4Xfz+V/ggN8XumRQzgnqK81tpQNm9+M/w17t6bU4pHfb0QGugfagbEt1NugvM
igXEsRfkbgnLxpaHSHzxA35cANK43j70TGtUOj3P56VotpB5IUKaSF7OzoWDdwbHzr93wuLimYxU
259iwrHLtDLPRZUHAbNLhz8qvu2NDafgIltXEXvMghrDNsdPe0ym2Rvd27hvWbAvGs3EhGQdO6Z4
xwdnrWeyUsp8OhTt5k3bqe+H1Y+VZmAc+cDMy85+8+9wXREwu0SruuZ62xvPFjJmQpavCoVRlj8+
qCSUNpXQ9wit0Bl4VmxWyjO2sQerX97MXRYSN0ULH2kr0tmQhE9J3Q1tQjS0nNwurVbyOUispCyw
kBqwk8YtC7txrB0AAcrA7Pk+ONQ1f0cu+dq0vjUb6QTbqZZTW6YE/CwuvWPJQJ/gmskJQVkXG5Nm
i6fSTck+Dx6v8AsDZpAnFMrdT+jqJp6EULJkD5Ea0hjUYfB6ymG7PqPI3ykYfNARBhziJgu2Vf0I
heY3dv6zAuxaPQYr02X55VF26mRQLA4TlXxIonp4eodp7X457TP/4lzLT3CJbYqkMMXGSLQ8/ogz
wGa9BbXtkYd5i+vfnzA0RY180SbURm8Ky4PZxGlYpSXPzkfkrirBNNnZ5dHOzrCb4H1JPmQxRnVD
bYTd/CwNpgZG6Cqo/8mh3YYpayHFPyWFuu/X+r4S+veOXOTTa1gGM1vfVou+vWj1kpJpjEiD01SR
fb6i/Gw2KAevHG1L5CD+2dJVoyettqgrtPTdtWEy63IDoFR31IbRUespG+pz0ycoq1Fuvja6UB2y
b5QNlpAf7IujFI1LzzjkhJgDy3yuYdTFTYvehkXBxWIjrYRbsXsiSKKc9BiaqfYBBGabKkBrA/M6
grrZjgz36OOUFyl6BIOgYXQF8dbnzqDGHHOLxJmHlVPcIGJheWclu7/8t6BKDLjFXBZ7AiJJi3Tg
UQ6axoQKHlM71ejcAFf//2Xz/Nu65ryPTEWJbRHRu84WHMf/gLkkPBVbN9ydmd61n0dQqYCzwx+3
C1NX+t7Ffa8ha8wOZzwTwBx7I4t6K+w32geAxfIKGI5qtu5BqbDj9x6EhrW8+AwdNjWcjwRsP8yV
QtiFhSTvWfEXSjB7VL6+Z+7Zw8anvas3qPEa816MubCgoZ4xEOt7FJbG3+odLwH7N+muhVozIX/g
a8Nv0GActwahovDGrXreKwuq2naI+xY7V2ASlT2k2KksHPqF+D6ek0mCBMEs6gr62EvYehI9FoJb
/df5TkampcUOPfLKSZHEFYrCrOWGexraehxF29f5iKrAhh5QgvwgcFRYXe5KUqFOgulUu1Rxgi6z
SpDFX5dWzpdastIZpTie05iZfALu1/DZBzEHkYUlcWWbkNqlQJei+O3TXT6CdYIiszV4NuNRVLzE
gEuQzTfDvsvt8KzoQ9yJJmM8I1GDIZPOamIuBLwd8nmluR5IkshXeJJoleDljt2l1dkIYmhY8X6v
R6lytqTEwjYhtd/sVvsM26nmC2ntwKMXs/HwI7SUbeRVPtMuHmy6OS9RuIscbSHPUuM8qKiPtjkn
scXV70MGnMmVDr6teWfGCRiQy9FZmKyFLu0fZQi2mLT72T2KIaPoLCY8lZHDvAjpPgRTcjk2buDr
EGwbU1q1hu2RgWrNgJYFk1cwrNSwZZV7qZY9i87obYCHS4vjop4KKoYmZDK024MPolq2W1g/ZDGx
4fbRhV2FAy//WYnnCI7PesbDXdmu+GEKn5DfLmk1qZARltn4rM9IuPhgWVZ4v6MR0P9qaQczoSRI
eExlGuZBabXVCASNjfaj+6Yxqfm0PDbbyRLv8iZxYbJX8KNtSA16ho2+m6Rkb1UlKrlkPTQFwX07
uNYNMciY5yHAu/HO0p+SIi6gKi5h3T1LVP0psLE75YepW/ziGiSoi4L8U2gD8WQG40pnJtvYktbO
7Z6n9k0ZtBLoEx84efEjJ3rk5Kv/x69szofXhJtEkc2sTkXuroPRNWByY77ZZT3egqPr493uhEEI
WB8NwB0OwCz9dxRrNuX1RD+wxZRF0FkMpt+SJrRzWldT1wlRl71Vt9g/8IufkgsJlBaVw/fXzH0z
uxK+Cr/ThLnul0irjqSPc8aONWCJ5sr49FWlr24LVXnTj4li8eUV8q1/bX5BidV90T9JJh4eB2xs
8LmZVC+iTZ9frDwqBmmlJipx/KgUjWbx9wsrOMn5W27ZI28hd00BuFogLy7K2Q0PDsbFnCjkXrEB
zakjOCVKCko3mixf8jjJFeMWLpNkW5JxKX4PLZczieKL61lppcHOI/uhCj0PPcWY7ooVntjxjO08
kJnga1kDi3gZyzs4zqToUaoTV6U4XfiX4Amhr9GVIChoBVQ7ynMAAY5lPFVnXhXF7DLJJwpywWfu
Dh55fj3ZfvFJ9V5PV+TF8yjjGqcofhwuP3iAbGcGicDZ12pTDU2JhLXvhj92rBzEB6veRQeqaCVG
eYsAm6ipHnLlM4LdFeNlqY1yKMCqQkUlklLwliy72/KkVVKHmYkawDSkAiNp0SIc/Hy/TWo+cNY1
9OwycjWTVOKiI9wi2b1Tk7qeu4oIKNWUeKwrlJO3TXpnin61HNdrOEBnMhcj94dN1pbRzyjVNktL
jbPKAdmHnz0c+5IDS7YDU6PhJUIdozn7HvdM5GEGlmhNQYVNSkz5BD4Bg7wjs6HsD7nHfsyAxyoQ
5zLcMvjRorQPZ2bzKTPE2J9AuS50il+CWasSSm71zBTZ1Q9Tu+babDFq1h8IzvXbNZJV/cPeuaVl
Oi39hReMkPHRmxD3ZjHGhp8xiSq9lS8ibdz4qoZIhqtdPBQf8AggwxQ4CW+8wJxT6leMoxc6k0XY
K2srjJ8sk7w3I02oZxoB7/P8Hyu2q8nLv5s0v+PtAIz4GX9xR7ody7u9xU5+G7P42ulz5KnYIs8o
NOzaztopT5h/4c3CGg6cUSeNkqi1x/20YqvlAVxz7M7h7tQheRFgf2XUzGKIcN3dSR0degQRlyUI
a3FBEgfHB8Xk8poUdV+YikPKfskoED0qHxK1OiWEROFPbOMB6ru2YHjLzdJ1rpNWGBNuDLkXl2Xt
R5fGXG9UsxxYy8SyfFw45flHEjzAbWwKia1F4L7kkpZ7++ztRl6ShfWtOtI8TxEI9vswKipI0EyT
E/sxSrw7QtukiRSTvXQ1qLpDCIkqNrV/U9UPyhYdxdsfAe3IxdFDuS+t9ILkNDcBwW3LMF/YJH2R
huzn3CLXO2IEE6PiLs1jyS+AXy/a2q2ZFcYFMAshcOq/wfgdgAz8PoduNFaaySxnyLvaG9CKrwft
1wUCRd/vJpRPqVQz9f1JKIBLHoxcXLMHjPmYHBfbr0NwxMPTFzGS9gf8MlgVowa3tpZi7xeL5zzA
jllAP638qMGLhqZQncIYzaGzIlkVG/Z9lFTFCm2WoPw2kbDxY4dOqcAqEVT/5BblnOixCXI6aaKh
LPdrzt3VcqX65VAmmpgpwi3UlwsX+8UCVWem5QARSdXEzY53Tz/g9XrDFIhWeNld9svkGx5kRSKL
pCWUyzqIHGpeRVC2pdSpp39ktTbgX+hR9j+QoaJHzwveznb9NWKY0CnUk2tDrniLfPJDoIb00t0Z
WKX8umTM1ZoOeqNSjDlajRISG4YeIAP5VujaEWN7Jzd80O8VG3Mi4xBrjWgAlu1eSl/cHpVUxec6
vxrV3Qt+Lr/NwS48hmvERGO9fxxOOr0B6NlVBM1OoDtkM/ZMsHf3pc7MOVrCdXun3bO1XUvGVwMO
Yr1XY5wNuWChPYVs7aUpM1cYGIc1OlBN4Zg+pxFHn1bUvzfplJuzRRkmsRPVB7wpPlYJ3aMvXMgr
reXQpIB1fpynyf5jMMWynzlIoTb6Ferz4YMF0H7ffeZhZSWQv3uACRa9N1tQulmYbL6BekcrffJm
reFJdF8zUWacKtteNA2UxZAtFGEbzSgS6jZ3ymtY9kMskQMx3g7+V4EDG5mbYoGkyIzmoQHgWMjY
m5HBAxSWm+1kT3C8I5TQHqe6auD4ynb4aEt//v66BtrSKq/P29BWcWs8uAuLc6/BLFd3owKJ7KRm
jXF/O2Bnmy5utoc+qXqRjKUjXxDBRlmEwucYrdBe0ziGaiKUZ9WoSTs9QbKQygz6GRnPFF9ku7FE
EzrI0g9QGvDfkaQgRjSiSGwMTh2GwWdiBk3yX6MnWLbtEZuKNglpn1bL1lPf1uQQbEhzrYV3UlXK
5LRRUGfeObeNNukuRkIzAXGbs2rEI0xbSqVRufDDpC+PymJD0LdnvvxlslfEciiIre+qZagaKx4i
VlT8r+ZNimM0+F+vtXSJqISu1o9Fyj58Iz7XFTkVZuIcVEmDwiy/IeYlczfxfqquLEbrJn3TazO9
PgY86b+VE1IA0ssmbiJv8maUs6rTX5VjbsKW490PHHwhMQReFJYKxO11pTlG4/S2SMfWTKJwfqIw
YVdApXPdThCtM0tDut6TCaBh0bKO+58Yf6DCEVXo6ZM1LEAdL9s0LTHwbREgaGVhkoAONmlcCU4Q
s/DTReXC0OsOLDN4uDmdIHr3L1pQs3/bDSQIoVQE2y7W2cJ7rJIBKO6nxj/70lBWnnjHDF6qHb0Y
X8xFYSvdrXB5Y8iNWUuS1cv0hYPQ9RZPKXAhKHCWRF6ctARljBaREtNGkzcr8pXsceTFWqi8CZdF
k18GK8MkUbtHPD1OxzouncsCVhPlN5uvblKRKAjoxVNSYNTqX/ra9IOt+wbRLLR1xCL/MCBJkVec
VQi+g2JX50b6BIfcGSvW2qVH9+37pcPsSdlObOL7MTps7GPwfUA5uhmzeTjmRE8U4F6lIvozMAQC
mMS5O4qLcgTwSj9futp6GSyzTTYv6vMYg1DYZtdUHDnXZer1bYwMWlLqtniTi6uECFLGmZb6C/aA
eFN/HkzJHoYoSqQutGCWp7Q8zDfVcmi6RCWbNS7nE844S7xbFUvPmSF/iabvQcpRIqN4ea/kcoK9
jefsurmMY4qSQS7cKhWnR3bmzAvh2QjkxRLhquEQhdaOvpWfpVePvLSUsaJhIXRENaO1+gOM+syg
zZjrZYGlC2piPnS+3s7+bNM4URhM8Rft6h3JDsN3fo0LpvJfDm1wFq0Ic/kw45IRFYIPZ1HZ7yIX
QN7n94qLYhyJXv6WHGKZW71L9yKnnbxViypTvr/1AAFUXE84Vo76CaVy9A8UxrGKDssLhlanQQJL
X4X3sx5HOTw8TCTgcgYBdbd58QeVhkmyFKzNjH8yo4WMig6x+BT7cm7LkxXwtXIdgqKSGUOK/xql
lySbzyDwx+NolEFuPfHUb0z7H0beNmVbeu3VHq5GhfAzpR0Lx1q9eKjvMkPWN38QpRil9HMl7wKh
iff5a5Powoqky2abjlgKYWPR/vtPSHY2IYJZGkaegpLs6F5Pr+r/LWDCY3+Hu5LreewSO0UggebU
FHcNPHodGChkPo7SHLVW4GaTC5wLUzXEarvAnO0TjeYKRXlF7zduh5n43tu+kjimQLh/eQqKP9v4
8ajrUJ9Gi6upM4FFS21JWym/onuGIisSdUlp7Mx2OO0J4+eg+FLFe6zGNI5+WbvG9CasBnWKSLDQ
5EAAaHo2bkEoOaHii/TPwhbMghgxtiIAyO5hH/V/Bp28YRpBtaW9tTqXUqbMqq9F9u13tRTmzI0D
YP/r9I1CGZj43Q3C7Q84WIIn9kDkxfhWDs7x6hisLweaWo8JxjYOMOpUGxUBSIL+7IyR3eNibWl3
Hqcji7wJ8wZ6f5YC//52UBIdddv5+U3yUNsPeb6oc3ny1x8AJi1KNdOw9laSEhTPDa5lHuU8NOTf
g64YVg63ONj7pOZDHa/jSDdsI1D1OsBqetwc4gjVx+2Vrf0w3YNTfzdSzgeJ72g61MfcTAF7t5kK
1MEpk942lWzBE+WZhSvsGhDecQHxxoV2+0IEiCpw9axVwcKoYBkofMnEGhjj+mdyOfZI7LUjP+op
te3KrXDTOa1MJDwsbAY7L5WCLXYhaA7AZBkc1sqMKaJyRvP5+Et1nA7YDzsNEpKDREiWkRCvzJy7
KjCkt1OKo3rVWZFUgJ6ZRQpY1IuLZAFA0xfIr1vtpbIsAvDhXf7PM8QdqXs1TDDZfrIwK+r5ZEp0
lfTELf9Ng+gaIc/gPP+hJ29uiBfK9VHkHXq2bOS5jxQqZlrEm+fyq3kTjlCzLg+wEemDghbLw0x5
Tbcp0h+AmQNwW+nPD6HglCvuBKMv5W2LQpsJBdKvxcb7i5yAss9RszRot3J/p0z3qDomtwuSiCru
3XE58BiZjyl26he+cKxsH63hbWcgbH0foVUu3PF5zgftaWxwmNCdWJsWLzBF8bN/hom0KFetEAfW
Q47i9YPEpfmq/kzQObtILdvzaXmATd9h82xb2Lphsk3sWmbcKSRZA774dTFWwz7IDL8AFEh7406e
9Rn7OFVqk7cU9niC0RWHMId33B1pob5B65Oe5KNmdsx/PcAE1vTHWmpwo1QuwE5oA68lgvVRWvfv
79268B5vVDIC4r6eUy+oCyC08a7eFAJ7Cu0VAgByx2EA9egk+FtcOt3I4ppRzguY0qLxNHECWr5t
02Sh0KCoZM4Gj7ccrMtQKseQJJYb2p0IiLlS70RrQxZ+6CV8V4s7W55OmeDKb9OIj5ZxJqQl2OcZ
waMn1ldl81iTOtgE9npnm7VCJ/17wftcSPw4NIt2YH5Bs7oBsU09MZUEqOoLehUwybSJhlUvS3fU
5RJOsaE/q5zjbFvULMytcMfnNIvd2brcXY0Q4+EWKeEAviRWiHWtEZwz/OW/dU/hnuqFKOy/XKrJ
x/sQbfNlUCwn5F+odHfAib1UlaWpjqiVAKCf+rtfljEsK5oiuk88YA84ffpQxdaGx9IKp48KRGlq
y906gq5tut8vmlEXG/i9/bDAp1fJmM9i3fBLAK2CLCOBqzMae9EVZA75xzeUvKTevgwvLuBZNg9Q
Yg4GUg2dvXkp315g8FnwFLm8u04q+zIoaWAsSuieIjlL4u/aOxxOebSYQDyC+ehaYDfeaXmxY2CS
/XcS4W9grfVLd2C0bmQpEcTL6rVl+U3Q7gTjqnVlBmGntKks9r4LKLkFjbynjiNTYf9qrDE0PcNn
WzyK0KgQcPEkQygR6uRUW1z2GKmFny2anqJ5Y4B4f4aXC5kxfQ1BUnVnRpunVEGp6sDnZYSEU6uA
WcnkeOV57i+qYI6X8C0IBwEV9gMlW10EUBTdHItBGdjIsDuuEkf3ZNhFOACo5uvpwTXpIkKzPg+M
uRoVa/F0srESPKkKMG6yT4vXYWsGKv5uB/jfIAf+1JAiwhExHxG7tvxQ9wcbZwpu510nTyZ9qXPU
Vb6VA3Zdm/yrEDM7eWKdOQ73hmryj5G0Sjh+2nUa3QGCLK7Jm5Mz1wODMaFXI0T6XZpkonkU5CUW
QcUyOPzoGmsmEW0ceu+G7kHahmVAbTfFWptD5T6IOCDhYTGxcPfxvcx+LsCbbTGxe+dpS+DgM3lE
oah3I3cVYOMKUZkN1moVvwRuacDBdFOxUgvs45oPPnBY/R/HYTMHTFOU99YhV1GfV/AQIKZ+fv9J
EctwGc5Qb1gvYPmsRod2eQAzjnkTn8sZW0ZQaG+4YPk3JFTg0ziWVugkY9ZAgD9JGvhWali2L3dA
qfBNezo7SYIi7Gf67KvxiH2c7G4ewjYDHxFF6eOlVZxp5EbF6elHU0qwQH0b+NKePcVDcz0O+tk7
Q56MMZGy/sJF+5ZXFimS2FXcieCS/yIfOpu+rdkha71/pOfgu3WgJYjlIioHFg0oxDghlR/rCOIu
+DRZXpbh5G6xDoUN9Bn6jhDO+BRL5ESP9OxtbPuEfvHGpd/KJApcnFt+Q4anwEcH75MNFJLDc3LN
5aUqGctyGbUq1sYZV1g++g/VVgt+gqY5ShAn/qByuRiEZsYbPA63kmaWCxTqXbOPvUYDcaSKTFuM
GoBY0dxICeGALNPXMPCqFweA2rPApdsSXbea6BmNDm2JkqM2foUPnZ0ncVQLNiyJfz2Sgnrb4ztu
gddAYPAcNkA9Bn2V83nOm0CBv4mHHePtHRdVl6gdrZExGGFTkWaSqGRLpEtpVWwTlS1rFUg6zEAW
QFsMg+paPHMxtvRHFKg77zs9s8b/y4588OhBqz/3wpoA+Pjuzwb8vIOhiUzCUF0Hku4k2VCvaGUY
vmlo8OP/tSKBmKG8CpKa6mXC2JMc3/w7DndAPF3O/Cw1p5vsUSU/497S3oJ5c643DxUTyP+rmOsF
QwFfBspVg9YyjEck0TpnbAcfTvPoQkK+OfrZJyPqOE62ijm4XDpeXRckpOf0ZjZKipu7KxRQanQE
bcupbDTRMNSrM/ZMMMWpXYbmYn2nQ3dmprUX7xPmzWFJogGOYTT6au7GyPV1zWLC/LjxDD443bC3
6CEqVI+BU+RZidZ4E1NwpyX7/4fNT4sNnGPa//+GEYwUdZCyrJdk9rQ5TuLbMNq5vuBzj/+bo/Jc
QkpKSfI0dZt4Q+9PblGyPiRMDnoM5WQtAgKXxYt9qXPnXI6AZ7ZcHNQXmMdkD5RTpImFoB1qUETh
FSlOMyT4pEzGLoLYOfbDV5youIzqemH5VGlRS4tqpSjnszlbv15+BLZEMTRHMJzkuOWV4AFouwhc
x0qVuxMw72fR3YvFvkBDGB4pFtOMJHwm/qC9j4EUZ/8ZMke6sPlODIgRzu+96mHyfDpysWsBUoLW
Jb3F5WdJnT7s2cKIc56p5fQfloMM8aUXLghCDKWuDPrfWPHF08Y1+d6fUSjUZEnlLsT1V55SDFE3
WapBufZxPkyL2rT/J+AH6TmblHbvIiHB4EQj7usMkwpDzzf0VZHfw7+AFq6Mv4UBng0I+rs1ZURR
DnlWvKdnkY7JIlGS3Pmvf0QMWAtnyk/W/PDOIbRCIEQ7hFnnwHjZhGt5nZqKFD2nfnq+Zm5badQs
wP2vURhKmZMoRiwzYTnd3EvOLGSvAXQ9N2gBk5FGf1cI3dKBMQBiEu3m1wo8P950kTY/HyATo8gj
ZqQMU3HeUbddC0TBC+7qBU74ubluLSQWs5nba91EHa9T4Rh46gjHu8OvQV4TPw4+jNXXQlqslvzr
5x4We4E4sxzTJaWJ8etUAFu0ViAALCsUfkFpSwPZlZtCY1ktF2tVTWAuKTI57Gdb8/MXcmvpVqyO
6zgRvivJSKkm+7gAofSvXnCxP29soxfBpzUf0A5AFlLLFiDAbn2U90qkZOEGmgp8IKmhBVBbhj3a
OfLpfAEFlY67HHMbWEZg3r7OOI6EY05rjAkfFRAjNH7nTmqCb6sttSaLhkXOKKyMU5i1aXDNFW0f
1xuJv9RwOz74pSv9Kw1zqE7ypw21+diK1Hdga0EqvsczaJdwOxpjBSJqd4QpKSvD28CXQ+Jede/4
er93xnrt8AZ7Vuke0RiVPO6hBTHrahYnncI1q8djGprpelpewLl+TzYypshR3ArPzTX9n+yFwaEQ
oYolPkZ2ohG1ip4Gup8ctyO/XMjqits++aSqSraEM/60gziOprksyQb3Bj8kUiPOKf8L5rFlDHoj
ZHJCyibNSzVykHcUzK2lO+15LaSLe/7wREn9VhPhT6XXgIMd4dj8eeS9pqNLG9gnkiSKHfpNLGp5
y98TqvBCvjPFWBi+sc/UtQ19shcueOMEOl+v/fOv5AfoA6ZXJQqHxwfAXrEPqmvjOaMjFgh8eUt7
XTjXQkiwcB9hT3Ohqrx9M0vfXNXvOQArpqc1JaQ4qxS3HtZtBOawY9rxtkmClAh6CvMFHuqlhBq7
4L+vjZnuM5vQoRUUs3/q+yLIq+2zD+nQheVkYfo3hN2Zil3U2VgDt9ldptNft8lVKGd0qB9QPF/J
gzR/fvBf87RaMoWgq7ytmzkVFRFuZWPooLuYAndIJZf5KxzOsv6Nw/y4tc6lsywG9QTLbWXnEQvc
whsuHekN62F+1lSfI9h+Upm/ri9qwpiK1nBchD37a2OHn3aH3iLJeWPM9J9YYW5WbiINqfPJJwhx
2L1+lytPccd3G0uvjvFAWXjavS+aTy/AQUiDS+JIpIZKadNyqVDrcoa3t/YuK8R9Tz2Emzo7XYRb
TTCPqnVa0LvXwdZsUEO1LXvbSeeUVgRARNDb7MiLDsB8R5ISjB25jOlfAiZSe6eKaTN27MSc/96g
jKiCBUuyVNNKrItSOVuR8rx7T1DJ+xUzSdplOLcxDTNefF39V4/cU4vodCUXgLMOon64HSDTetXY
oqV4I0aQiuiv27gcdyCcKHYTtzeMKfmHxIzMP0flZ67d3qcol7D5llfT1Z699Ke7Vs7i1n3HFasO
eoyWanus+SDtkt2u6JXifl6zLZPu8KwiYw9i5l9TskX2zoWO/ey4fHSgvi6beQFBHYkiMUoxBC7I
it+jpGzds+5NEun7a9bniTwnR2zx0GfxUrSDtdNXWAZrdYox6UkEm/wK6mI+hthq8/ItV+Q/zFOX
s8+SU3F7AYg0Ra4ZcxAmKdnv/kvyIfbUkwI6o3yHCQplVDMSMdwh7PPbcmZ6qN7mPuXVbD3yeCa9
MAaI5iYjzbBWdsXYSQfjAVQdV5f7eNK4Fql0Lm7Xg/WOC9JslmOwoKb/T9W1GzttfNGV4AvQaCCi
qWCv/zgpUI6AJl/I02mcHpxnM1VkOvqke0oXeX+6NgPIEPkUkJGFdtWjIG+eyw+rvazZyjqeNNM6
FtUToEjzRRIzb5Ta9RBJjp7p4R4Zxv822nrEWOV6I3rz2FvKw+puxUjaaBrpR/DanE4oK+rQwYUC
F0crMyvrN4w4HsDjOLSrlOHkAy18QBmozjWztgUJpbPsYcl371OLD5fD9TKqU6DUS8UnNYsL8JVa
XXMwRNZHPqI69CdWc1mbG73z0mAPNsZsym1QBjjKrnX49pVOQSw+iOafWVWKM8qpo5QWFLYaSj2l
Df+GawAE/CH/vNYT4F9PaxppEKY5R9dXiw/GlnI+jFLzBYDd22SjNg7xCQBrfXiLRSWlCMDKY+Gj
yvNMculjvjDvu+tkkLFQrvsIP9JLbzrNHda0NIS95l6w+qicjJZJ3NvW/9l7/voPulZx7VzXsMgs
fM9KPd/sDZp9jWMZHHcvAVImxcvA0twXuvZo/te4WW8GOauwxmrzJEk1KCDyMvZgN6g2rPTrTV5e
OAIg9V337p83V6NhPWg3mSxPMdm+/90oBggdMAbPMWUPLINQM12VBTWejW5k2izh22J9fbE5t6so
80BBvgK2O5XFsyhiuQnLTZBVrpUgAoY9APxNroLEvYQOvtLgoQdGoUwWWjDGd4LY2Qu5Emg+qOuo
R0ocoKuKZEu4a0oNta+hbDxX219yC5xA6R/vBrjf9ICySi2fjhgWq+vhz7329pHDVbe6FjS2Nn5I
rls04zuDFVnper4DI2zI7vN0cyC4oFDWlNRQNk5D9Yt0H2RY4IczCP2RXzxQG6oc83K3NfsbH5SQ
3eJljfD8qwSOj740aYs4PkZTzAUUwVbefu33ljkOol120NrFI0zSwgU5BiJif80iJupFipPk5jSB
c/LYabK2937lThgPw92lHuoXhJ3Tn0D5c3Pzi5i8EbO1gxHnct7T0ahqnoWVsRtdfByRMDMjALlH
QXm9pL40jJtSixSfV6Bs1n4mpdwWv6caqVwpOa1FwIhT3ItyO+mWy7gy8dQo04xyvZ4sK2IIIbgf
l9L8kg3vKyxErtVgNYsbEuJUws+RkN9+4ldVy59Jty3L5G1SqWJ3sel46Usc3ZEyaYFjRsZrYY2d
LbDC88BMb3erKmewWJySn/88XhfxM07KrED7Sc7/CVI6OoXtxLWnjB0vVA8u66ZePQwz9PDP+H5R
8cxwJ5fQEOD8pOxa1bO1G88UqWrnbtbtxqH8STP58tsXacKbOhOXOwLR7OPsW6ejyWUSgvCVn/pI
D/Sg6cH6gZjIVy/sagOOEwc7MPpUi6eiKFXZTIlfliE5e1zIpnzP62YzWDFLMQ3wk4slLcqq0LTz
zwyavzYF6a///ve4/bHjrF1o+GMDJuV8p9XqAzFb1IsE88kR4OdlGOEO7kgrFLnNJVWDeC4Vjq4u
ap6r3tSJKmbU4YoRKuzi0boaFx9mQ6SaZ5OfeVvJnTA/GQ1tx6/OHF+DZOMSIFtzxAIRtcnNNbDl
RRnz+zkaYjmCLyIomweQTit1AyEJkwXPyl1mzdVXL5tRvpRMcxv53NS1xciBPLBS7FfNwrvLYpuV
rl+Tq2XNSa7zldHanriqrylp2fLdGc/NQJbAFiSRi5QKqkrw4WHZqNwpqD+/Iz5Qdf4nFm0Zqn/i
IcppNKsxwpQuyKYO2oMMWDglvLNc9uRYcaa80PJ/vmYW7Vv7u2cvIzztvP9d21CfjSFNpLEnwHCS
XoeJb7KUXVKko5CPwAjD/emym2QT5wSYqKODpWveXGv/utuycSALBNhPnr0Za1uIUwjQDWPfD3ZY
hbA8bATYcZHX5gGGBfwduCpFaqZzLbqcTv4efHJAw/62HVL18N877qLdgm6zZboslYcMWHGj/S+f
ot68QB97lYPTY+kkUUYTnkjcTgUHvIDjFV/JmZN8avWLHZ/Gt/QCVCFZzVVjB9N4vxisGBAlr5N3
AB7BaoZ6j+hdrSurdtEUMuJASn1qT7KOPS5xEIc38hQ94jqM4utoyEUSahNgg7J4mKzOiVBOmRNq
bSojwwheiJpMt91xC4naIxKirjPXjG78CBPdQu4uKA0hC6VkstITv23kxPx7b+Rn/5sksuqNGYH2
blx4qJuQPTpkBIXW0TLm7tAfspprj4oB45cLObeD6EHMN2hRmu5aa41spZQlyF+qfsjdsM99/0wi
LWOS8YYMdHAaV2DdnwXY+csP6Uh+OY6MafZiaUkuBF2KaGq0YS7ElR5Actp2ev3hWrBIo6/7fs2B
A0+If3OzcsJOWLdSmJ663XLD2iGIjHXjezwpapX5Em0cctE6bc00eq7DABLzsbc6hLteflnd9QlB
XbseGLlWfx6ryyOVhkky/x/0zpwvOp6sDBVA9mFrKvRuN0D6TYJlfSoQKpk0k//2OXkDhPDZI4tD
dSLhYXC2+0/hLrI/S/5KSn5378bSWguRVTsDBFAL4RwxZQ1LPVp2AFrQrx3SrNQHhKYvgh5OLJvJ
mvz+KY1FluNck6Me3j4Tm41Z2mZMUdi/21020WSNYZVQzoAKgMtG6ZUJzsb7EshsfwT8JMdTP5Vi
lBkxVasSDjMj6NkVPuFGXqGhecM3dPeAkhwcX0TVsduX8mTbcJlOve10ylXmItcfyJuJO0fLGPFz
PGpCNx6JGPVSQFS/RtVkWl3GkjjRGURoHxl21/piEh14e1gJ/6wr+Ys0LEFvCT+lkfPMLpndVfjO
Yen298tt5DjkNr8k73rEwH3H3FSRlnN/R7o9pdmog7kPe16bJzUBvYgWAKIcBmKZqcePRIsH75y1
kCg+YFcYO25kFfp235NufeWvXUPS3n7Y/tNJx4lKLyPyLtEYp8BFpxVb/N+bLVv49TjMPLvtye5u
Gfyv/Pi/ET16t0yh39Epi12lPAbPA2Th4tNvMIT1IFAh4acXg+GzwML6CMQH2wNcGMd5alstGfpj
TxVGCotVuCZlQZfmoSnuDIXX0rkMt8hKsJBIueaGPgQWpANo+q7fRLsiHj4uDc09fGDZ3jlJqwgl
iMH+g99NT3nsNpYhyp0krbLYBbephfe6K3ps+T5bPTnhUKr1UXgG/5d1YluM33OCYDX4bQWWiE1t
9VWLb22bAS7mS1vSKU2QdFw/gfngxyjdsz9OMWOrmRRm/encgQ57pkAKr8Vm1TG3XyWT7fJ3n1AE
BamyEME6g8qNcb0BuvU1DpJkPU714LbIhE03u/Rem4wJugTsS8H8voHMIxDDLeTS5Zr04xm9mv3O
TtAKerR64LqIaX9gCzr7O1rZ+/acvBVwhINTa6aFFPVIOujA4HNFC16bTy0uGRqclPjFagMr21My
aJE3OCmNYjPxZ0W8FwDZpgWHaA/r3g491Ce2kNlMF6K9NxXAspNzIMBFthNXZWHQTRVWRbzHWwvG
da00G6rVWyKQKYnuIoPpMC5AYQNhk/Zsq3RAcLWlksMxtdxmEsgu2OIH5RJK0DjHpQvJvG6GycJU
UCmDleVbLOWDA6b7EwxWm7Fgi6Vbc6iz8d11uJ50XBt3ZwwhrCLGHnQe8vrza+8eUvYO7Ss8/q/+
IaUFA1oCwWkH4TVbnLK+GUv0cUvRILZQFq1uJNv0VP+DtGOeJUy9uuTrowPvtdTXrK9oosuPyefZ
e9dZXWlOcYWnRat1c+6hKNWkuNXunGUUdAizbMFF/q1aUeWjDHvAjmy8F8rtMdXqphCCEwMTR9VP
4PoijkMAKPs8A3P/i32JFjwkoTxsIGpTFL+Dy7vPg72tCQMUg1OKnvdAGBdM9879vVEnSJEeB8r9
moyNm5gCd2IE1AFr82k8V2kEV31hpjfjMCmNfes1mvoF+VHu7Hm8cyagjbacTMW/5PVIEoKHXHkQ
KxPCaMIyp2/Uu8m1J+E9tX0GNYo1PsX2XG1kw2E1Om4+cAhsqQSgkxnW19EqDsO9iRJcGt7IwifN
lrJD8KzUDQT6Swsh2kQELwpNgyvnLbZ9AoxGFMBokaKgvgrRHXOe2hQP5GXjMlF14a802p5XJbCh
u/RleW2QT7mItVeqqNCUE3vuYx2ZvKUbN086ClhoPGXhgAa8d/sEComUNxB9Cz1HWJr8O3D7mxAM
vFPjp23XylrTgHuJWCkLCyC11PmWUog9OI+89zdWz1vg7gB9wwO7xOLYdozhnjQZY2cgpkwDMdf3
KJKbU9X+2aBOFI1Ig/z4UMGY4OUaZK1Z8nN4IXTqleJ/O+1CIvsu6qJ5kw5znf3SjsWy8zKeqGrm
3NTgAxTyWz0Z8VCBOC2tuwJlkBtvSCI044iFVqVDKhYiSDPnAeHD9Cxs5pwJNwoiAFQ/qlVTZbP/
iuzMYTHfguEYP68aUy86rqLKb+zq7IZnplUMCqEoPPxIjUSEGIG1UwDzesOsJznKpNzmlhmEOvux
VK8N2OnSSZWZoz6pkW2Zd+Wwp7ngYX4dXZrPW/94DhcCi/t42wzOUYWdziejJSu/YNGn4YVNegKP
jo9lAGjX8snbHbaQzNiVrwwR8ghI3gu1VG7vIpDnJzu2OZv02KeVFeV6q84JVvIr21AL1p4BJlv9
/8OIXGz7+osB07l7ICQwo5nlsS0WCHy07ju+qp0pq0KwJyRu7Pa9KH2iGQ+Y0limLSZwsKtSMmUh
iW9yR32Pe6KdK/1lgKBeGy+Trxmbh/JfZCyIO6hUQ7khvjdYi3Hh/+OgPjCYMHTHUPrvm2GvLB0o
edH3ojai/jQhfVrILXfMDRZVJ2HA8lbj9Ff3sxFeWD0Esl98c6SHcrBDSatggRJ5wBYXcq8pSRub
P2n2EVql5J/RZ8LfP8CiLg0qgSjGuRMnrWGJs9En/gFVeiVhL3ARDSTgZTweaXXmRYihZoJ3rgTd
davtbzhollkLqpptTqmNUh0b2iHNZBzQ0bsOSKH3WeR41XaopoqYFsqqwrm4WkAqwEeuPgGkmx5u
/MxUOgGgkQF6zThaBF8XBdUnxh0b4zmngEA6qjgjP5Z+V71Hom3PGao2p2DKJGk9p/AiIL8SUy1n
Vae8FOlhYEOR64/FVHOBwp22hQH4y9vIbSgEZU+zogZyzEdiPA3MPp4aVis8YCcGTIZ+Vmgn2ad5
qTR3Wo93wShBblFAj1LKdypGhgpWr8K/SP3FCYnseLtTL3Sp1kAstOLSehdRiJALAjdnGBX0woJj
8ckIV8FmRRhQUO7b3GWQEmsnUZhle67jne/j9CAHfEaJGtN6lUo4TTCJwq/CvMTN3uNoblpw/0gD
cQQcroTn8frwiL6H7Ty5sJl36Sar3GOTZKNEpGQ1/dFH/kWLId7yk9jbEQR20YMcC1Ze4Uf5elxG
UMrnH9kMm28/C2svhHz50kUJ1/KqBKPPgNhez/Xh3PN0DScvWyunKz4+6Hs76j/xWmldPxpmZbJ8
tKGluH8450HMeYCKM8I4lyu+BR0brd5l4yhKw8fJNq4oe9QLyg/Dkqwfb9jg6E35PlBHmAsQsR6N
gaMoz23DTb0mWQURZ/TpvWc3mBb34HbLn8MB9vTLyfAhAcdid5tS5Ykmcz7eMwlP1/9LavjHzui+
9w1LWZHJLit4hSsAYpw6IrYfCzVSyPSD6fAmfWySGBIThfrtI1UdTRd9YadIVbj2k4sBcTj8gV79
R1vAMCrKVRcXmYcHruEjkZKT+np2FyAQzt3LS5InqmNPKG1c5VzZJYBebZZ29FvtZ6d53adn38kf
ej7hbCQ6BFgpcD3PjhWpW42bM++PpWmrQcrcmagaFQTkGatrmzW9XDb37mdKbABZOnvrzhgimT3g
w97jOQxvI6bb8H4BRmL77udPuDOlLaAF69jvgJ2ApiDwOeB/clK77iCN/YEsC4aETnFFbe8FbhHT
0grYX89N1AW/jVxi1tGVRn89dolDPVuGE8pQtOyqKXnRez7Aa4/PLtgc1mE2qI8xVuibyJYwd3ZT
OenOiIG9iVJN6TdOCGGqBtC/mvuRxM7zq6qNnIe7hj6kH1tyMME2x++nTcfKITcvbObo75iDtd0H
7GA6TySQYhwqKswjdzFr4VK6Om4QNWPKgpRMlIWfz8TmJz8yOv1E+9EcXizOk2RXuF+YJqq2nrVX
cw1ZWFc52pvZHSrmz3HnZ+vyFa6UHhvYM3H+9IWz3Gc/ouRlU6B4DMrw/fCr0sDQDgQyS1uNL2/M
torxErfc1T5w8vSw7yr7Oe1gnCHRWCDdMvgBk1B3bgrj0gINzUxcpU9eHfTN6wT8EXU6fzJVecxh
+jOsxJIWe9PVkQiUqjeDFXPh9dmYpWK6ZWgRreqZzlbTM5ytiv4WdGMmzaa5glzp0h/1QnUKAn0+
QQCuQRUAfs11gaN5xpgKqs+9yB/AJxdvLdjC6cNoovcXau4HacFhVLDafsXJtco97uDdodg3sKy8
+Z9JuMAleegUQ055UoKEZ9oi+784sxtvkXvw+fK9py2FPPv+0BhTMo9cV3sCBd4hyqAIO9N+Ck4z
ZNlcm63y3cLvMe/ZAwPqNZy+gcVNPD+6P3ITHjNLsA1mW3JlBDivzcGIHky/380qPKhJQoK3XebB
1tmmmUqnLLCX6fp6FDEqZ1a/sf5aWrCmqluuoc6tlsEhX/PksqoT7gzeNfhSoKl2MxI/5by2IW9o
8icwyt9awa1+In4R1XNaeCsv7K+OOGGLZ/3YSBd/zGO9AFsq1KZogq0enxmk8WmJf3zQzVPJIAi6
KcaDDWbqbGrO9kw4YbwysyXpcIYT77GQK9dDo1NvGOhISkLK3eVvQjZ4+0xLQfNnhPVsJkkWGIUy
Mw/4UID7WDVARjFe1MptFPyQbYgUfaXQjWALDEOXpZ7QpLb7/2xC7Y4t+pjQZhnEz0Ta00BMk52B
TSzNDnfqCaa0hu5yrrHTQ0gZ3i3KqZy1PiQzROpJ7XdMRtXxAUkjSLuJ1rP0/8JDeguGJkVvfuay
oJ5PMFqmC/mYBgtvb7gkkzwQiG+MmY4+IwPBLbJxL3vdQM8az5ulqGzF2v64hv5ysSxL2fhKSv3R
kk/NAYCIbLV/BJ1itwuNd9TvRr+5CXe/Q96wl4VsqzjNzJsSd7syZSNYEY2b6j0b9HPwYPtNXt/S
Etz5mvZH4WFW97nFaQ13y2X79dkMwpmcCurLZAVsEGJmLscGaVDbSWcIjQ+cikJDlu344XvVDEji
6U5kvIODClpB3Ps1mesPEb/1ZzjHRZ1ZaBRNhBbtUhewuk4mmnKiEzms2Bl2cLEnOnCFvF8quphN
4LJGpzNwI2p9aVfzluCzX6hpfxU+m3gKIbtn466dOl5rakdk2aCPtHUY96zV/nndnj43ImQWqjIK
BMsK+Oe2SRVFyIhTBdhNHTWWuLFqxNIJz0K+eqtwFslDHUHAapVZB4nAqxZFhl6sRtYBWFYOvRnz
dm+nNa6+pEeZpjrGelpOeoo+pUMRBshc+VA4EW5UwbH4wHXuoA598Qkc2ilp8pO7AyVIUTA5Q00h
gr53BVCuXt3saEDpiyuKEMaEGrtluqQtt9ysQ+wdmTAsqNmW+EqTIJ8qf87LbcIpsx4QTYEmBG7N
6yYBoWTwNIOXm9zsFg6DnQQekTW/eEi6RfyXIe2R4Gqs7oBAoBDxAOAsjtMqzWkHKMDOtqk6X7Dt
Vv+KSbakvSzP6j1K6K/AkkrtNNy/K6Knm7DKEtPsVaURIASidV/OT19460oqCgAQH3VO66FejRk3
wc/6ljOCIx0U2np7fI7yKqvErHUSWICSd5LF4hbqRi1qihwkjlCb+kI2Phyc4ClMz1t1xBpg6OG8
QXmdiyudqPZF3wKu0nvvsmbNPfa234Y+iaoUsgLtQop7LAXdvZHcJAszKEcaLYMrKhPApkGjSvns
vGT0eFwZXJBNQVYORl+lVCKHmhAqDxeyy7VDXfjJA7lCPqVOUghKthL36xbK6gVTPIc4QUcixQ2h
dFNb1JNFr28gYcU83cX61yOVsoFxeEm+NYm9mF6Tc16DDBU1ISGYzcM5kJpDGaMgP5WjgrUEQaro
bEscx/mqKPGsBSqf1soMqQW/nxrroH/JeqcaCmwv7FYPhfvBXfOWWpMXzoh9Pc0RotVbXf4m4PKJ
uc3daYnK4qBuoKH3QZLI/FyswP9vZ6Mw9FeE5pLOEaOpE0doiqmyox+HtnQPTFabIm+LGegrGyun
XqiQXlQy/lgKzpWFDbithCgtBHShWQmZgjCRGOeCQnmil1/cuKYqoZSCpNHq+vZ9E1yqlLj5AWmC
Gl4y2era6Wk0PuNaju5MSWARO6DS68DJ1jbbyYdUJM9H6v+aLsP6Kb4TSTy++jh5LNAMG/GHeNF0
lXhL2GQ5/oY8r/+tgkvqJJbxF1ipYTHFxqM8uGYjDP3tY9BFCOyxNV//QI5CZgEiIdQw3ux2yxIm
NqqFk5pMfsZz2f12TD5KZYy9ItjCdBgsNnDKXqj6jdzKsL1ZP1bm8JBMrFlY1A7HJqTltkvfnRD3
5h6h4EmWXRKKgIprxfh3CEKAKg7ehlct2K8wPi5qzj42lg5iY0LEw/C3pJJI4JF0hkcRX2r3fSDI
8GmpueomHJl7VjGvMz/4VmR2ZrF4u8nRprQB9tcPPb4Q3pX6tAzLslfs6wAW3mggp0IUMwZ6xF47
gvv8/D5tbOB3S5ZmJGVfDfVUMiw0LBAWxN3hM2ovP56q5UExWfdvcZtIb4nT17jCq05iP3gebSMc
BFHt7sRDQz8T+dA5nfwuvY0NJo2nJQN1VIAd4hwkJC2kCq6N5HHZMbaBTXDl1pOVKgAgRoCrjVo7
Azo0+2YuUCrfnPQOA6zIpIJ9SmKI+sjvRbIWrBh94F+4pXKro5Wnn1f0vgHoerFUmFPHjlsEu9d4
bqJiQPEc6epGh7nAMkUHq8wo2FVVeEVMW4u0NiN3HMovwmtfzCeB/XUWSnJjNSFj55Nn13EHEoZ2
F7GidYqQjn9GbA1yy5Pkno9tvS5zN3YQqR+hwHaRPzN28P9YWuvBjS24M00vIxpbkdVYOE1G5DgP
NFlM1ZI6uQcF31sxCcjwh1+NNoRwg7It2SUjhe9AoC8uxnoTJShvokHpUT9ufalkPX50J55QrM+u
eBp6K7Pit08H7ajLiJ6Y4eFmuY6/sM+HRepWCk1cmOdT7SEknKR+MW9Nz8nob2T/pBUutmD4e8XJ
Jti2z5zUpOGPL0hFeblG3lF+8NNxDiCkpMeZXg2xDF18BqaVQixD9ARskzb7ZNhkKH65uSsTL4x+
d5hnjpDRGKxTrUBYQtqDJZFdVpW4N1jTzV3RQYc6d8REAtWAW5u63pKLAxkpxfqhE659bFFQyQte
AwQQCwI6OeJayxNuH1RaAtUmGGxhXjubcJ8ZBBx2ZZHfENoz/+0KEIXWvmYlufjXrAof+bdTEkLw
sRBagbrAraBZSzZ4VavfjmvpOs8M+Fv5l9mOKhf1SpOORed+RKXa0NjJijsir/YI2Z5YO9ACo9Hw
s6Q9SnPBNtbGBTxx06wvU9DXLvwsIHYZG91uFUQTK0AbEmN4lpKvwBxlFNHg2n62Ot9iUD3tYSJ1
uGjTqdtnaeY0djxdvvVwzYuMQVsDxY16C8N5N1xaqcD5t9BgcZufhWYReQlL08ttXDj/leSFcwnW
c/OcvZPB0a/VrhOj0og/bIpcd2V0FZguQi6L3X7dG3nv2/OFMjrHN7CBbfNrRnE1KZDMVcX+lEid
8ocAX1MxopMVW5buub+06VaWeegxGbhiLJp6p8OK5nZcluC5cs1T4p59bqwGLwO59fXf2cDK+u2/
pztfOKEP5Wr3V6IUFp2/SYjzl9TnUEGm90XSDh5taQo1gqvBD3TPB/cvRLn0bXYaFC6PABsWcdMo
6jtCApM8MdT61AwVQATOXzo6FPCDVApnU/iPSJi4pmDpToDOClziksgZU0AwWOU4wqwcI6Q0f9wh
TkDTvsKEOUf/+OLdU1SpMgCUx5pVSdTyg13Lt+3ioVSppvuMQBbb4dcQhsgvrB+IWW0C7Yj02UVs
X3jWcRq7dU+BtbR1TvgGAs/qeRMQecN6UbsK3iH33++gASeMN4KUN+G9M3O78EiUSqhhgadF1RAq
MnaKRS4M28Nte8ei6yvsrWUXGygcCk9MqDkviQXsR2Vcf+WLCPk8RGWg0MPq5FTUlmvM4sEJp7Vd
GSvquYhb7GAsSo2zo5NgBigH8Pdxeqs6kWAEhV3NH99gSy+JLlLtzKnBy60fIHFn1siEuOmgc1Eo
h9C6v7DdrEvihuJx1KPY0MYSR2FKaWB3Ufd4D8E4oG35PSPM2FoGHwBvK/U0lK4TKKFT8xqMgZoa
HD1tsQR9ijx++pPpvv7bzBmGD/Jwr0Z6QSvP4YKK2VssOhxBiZ3+LJY3dQRhx6amDaDoVvoNH63V
z3INO5kwIEliYvNez82PMmwAPss9BxLWCbFM03IWSDtMtIPIiCud4ibDe6OVPtQkRkZDM9oHDWVu
ZHN0cmVhbQ1lbmRvYmoNODYgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Bc2NlbnQg
ODA3DS9DYXBIZWlnaHQgNzU0DS9EZXNjZW50IC0yNDkNL0ZsYWdzIDI2MjE3Ng0vRm9udEJCb3gg
Wy0xNDAgLTI2MSAxMTk1IDk5MF0NL0ZvbnROYW1lIC9GdXR1cmEtQ29uZGVuc2VkQm9sZA0vSXRh
bGljQW5nbGUgMA0vU3RlbVYgMTQxDS9YSGVpZ2h0IDUwNQ0+Pg1lbmRvYmoNODcgMCBvYmoNPDwN
L1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Bc2NlbnQgNzU5DS9DYXBIZWlnaHQgNzEzDS9EZXNjZW50
IC0yNjENL0ZsYWdzIDM0DS9Gb250QkJveCBbLTE1NiAtMjcyIDExMzYgOTkzXQ0vRm9udE5hbWUg
L0phbnNvblRleHQtQm9sZA0vSXRhbGljQW5nbGUgMA0vU3RlbVYgMTI3DS9YSGVpZ2h0IDQ0Mw0+
Pg1lbmRvYmoNODggMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Bc2NlbnQgNzUwDS9D
YXBIZWlnaHQgNzUwDS9EZXNjZW50IC0xODkNL0ZsYWdzIDMyDS9Gb250QkJveCBbLTE3NCAtMjUw
IDEwNzEgOTkwXQ0vRm9udE5hbWUgL0hlbHZldGljYS1Db25kZW5zZWQNL0l0YWxpY0FuZ2xlIDAN
L1N0ZW1WIDc5DS9YSGVpZ2h0IDU1Ng0+Pg1lbmRvYmoNODkgMCBvYmoNPDwNL1R5cGUgL0ZvbnRE
ZXNjcmlwdG9yDS9Bc2NlbnQgNzUwDS9DYXBIZWlnaHQgNzUwDS9EZXNjZW50IC0xODkNL0ZsYWdz
IDI2MjE3Ng0vRm9udEJCb3ggWy0xNjkgLTI1MCAxMDkxIDk5MV0NL0ZvbnROYW1lIC9IZWx2ZXRp
Y2EtQ29uZGVuc2VkLUJvbGQNL0l0YWxpY0FuZ2xlIDANL1N0ZW1WIDEzMA0vWEhlaWdodCA1NjQN
Pj4NZW5kb2JqDTkwIDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vQXNjZW50IDgzMA0v
Q2FwSGVpZ2h0IDc1NA0vRGVzY2VudCAtMjQ5DS9GbGFncyAzMg0vRm9udEJCb3ggWy0xNTcgLTIx
NiA4OTMgOTY5XQ0vRm9udE5hbWUgL0Z1dHVyYS1Db25kZW5zZWQNL0l0YWxpY0FuZ2xlIDANL1N0
ZW1WIDk0DS9YSGVpZ2h0IDUwNQ0+Pg1lbmRvYmoNOTEgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNj
cmlwdG9yDS9Bc2NlbnQgMA0vQ2FwSGVpZ2h0IDANL0Rlc2NlbnQgMA0vRmxhZ3MgNA0vRm9udEJC
b3ggWzIwIC05IDcxNCA2ODldDS9Gb250TmFtZSAvUEhETU1LK0V1cm9wYXRjaA0vSXRhbGljQW5n
bGUgMA0vU3RlbVYgODUNL0NoYXJTZXQgKC9BKQ0vRm9udEZpbGUgOTIgMCBSDT4+DWVuZG9iag05
MiAwIG9iag08PA0vTGVuZ3RoIDE0NDANL0xlbmd0aDEgNDA3DS9MZW5ndGgyIDEwMzINL0xlbmd0
aDMgMA0+Pg1zdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogUEhETU1LK0V1cm9wYXRjaCAxCjEzIGRp
Y3QgYmVnaW4KL0ZvbnROYW1lIC9QSERNTUsrRXVyb3BhdGNoIGRlZiAKL0ZvbnRUeXBlIDEgZGVm
Ci9Gb250QkJveCB7MjAgLTkgNzE0IDY4OX0gcmVhZG9ubHkgZGVmCi9Gb250TWF0cml4IFswLjAw
MSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udEluZm8g
MTIgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDAwMS4wMDApIGRlZgovTm90aWNlIChDb3B5cmln
aHQgqSAxOTk4IEFwcGxlIENvbXB1dGVyIEluYy4pIGRlZgovQmFzZUZvbnROYW1lIChFdXJvcGF0
Y2gpIGRlZgplbmQgZGVmCi9FbmNvZGluZyBTdGFuZGFyZEVuY29kaW5nIGRlZgpjdXJyZW50ZGlj
dCBlbmQKY3VycmVudGZpbGUgZWV4ZWMKqlr3r5edU/BMpUcGXDHB+Cp9nw+gb0HD4WtOSYosjtRd
GhDSMXuyCB4svPU3PrPBYjRa02Ro279G1Ccx+vMDj0SMRzN4EqTL/X24z4OcVRmPpIdchBeKacMF
E7jjW3IsidmeYB2sty8KYYZX1JrYy3cLFZITDbthJZgLVFXcvQx8DuqeH9WRYeBi0+RxAyUfTRZM
Ubo1FCOJxUFKREoqDFePgLjkWvWYE09vrZs2uvmI0FwBKz1zaL0MOQf72IP59F6cUrgOKTbOKHvI
hNvke3MOmWSZhTeDoBTXvf3Eha7M76PnrcO3SdoDgzymw/Eqt6qHRX1ybj4DU+CzUBX65vQyamN0
Wdyd5hO8eniUK/kjax3mU5fzqQNXigdPmInXR3naKPJ2dyJDmajBxCRPmp+3R/V5awFtmAxzXbFE
VVN6qmqOXQzNVgbK3lqljvFfLo/5mf+5JgFejyrPj4Yjnz1gNlBsHnEGoRrOEngp73SL7uuk+NM9
op3fa2f2PsGmAg420nwiIZtwY5SomcnZoZwpxQAIBUJQSLAAjkEdNwVIjPFrJoq06uXMQ+mWowae
7A7jJ0OhX4qQvrPLj0BOAdeCodKQWuBF6IFKS8AfTfk855NIDFcjXO8Lnw6R2gc3T43ruaXDXh/T
DNI/8BkaG7kqcDAxHAT45oYsiLP3nvdaZEssq+HepOFnLj/pgPVTye1NonoD//fxmv+pZZuKLx44
0gscgSLjmgiqJCFsXQWErrvsPEqHbrzGSjmNuKsl6ko1jt1Yd2rDa0P9+IlW9u1ZCgPu/LfFEiMu
DhLVTqaVGGtzQSOS4cx8LuaBgdeniNegwi+e1lz+ElrUKfchFJGafX3E7OOlBV1z49X+U4m7uW3a
u+CiwdSxFQqqM3wwOr4QyH2HVJ0VDC2WZfmardCBkoLzTw2mMWDvjEY3tIaHb62z5b1ROxonQ7ML
WVxza7/mcg3SWi9g/wSvri54xu4daNeXJtUu3zGZ0CyelzemiXILi4MrzwAOuXCoRY0OqZiYpsrv
fYQ7st1+xTskwIQhRVb3+a5oP16s5ftrdCyMSCR4F/p2d4k6ex+D67y3ESQZ5UxXqeYDrU6xijoU
gl+IiZJcOICD2qpf9iOrmDyvlORCeGSGShbZLuCLhyKpBO/q2S7YDbodFRmdGj32zqDb3FlLlUB3
hk889QMiYVmHyxb0fnZRq0VC7ErleD4vtEYeSp1xZ07bPdmeffU3lgyxJCMaKtVDd7o6BKkn8pWm
6jP08vjbCeEp6/rxS9XDmEsSmYSY4RrrGcEUJ2jHVVlNx7GAVWsY548nxi6ncrwP5iBSzcwiMRFb
DqCW0LCHujK2ZnwYSVgLirHhEnAoZaF9qipzAVYQDWVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9iag08
PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUgL0YyDS9GaXJzdENoYXIgOQ0vTGFz
dENoYXIgMjU1DS9XaWR0aHMgWzI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1
OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1OSANMjU5IDI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1
OSAyOTYgNDQ0IDUxOSA1MTkgOTQ0IDgzMyAyNTkgMzE1IA0zMTUgMzg5IDUxOSAyNTkgMzg5IDI1
OSAzNzAgNTE5IDUxOSA1MTkgNTE5IDUxOSA1MTkgNTE5IDUxOSA1MTkgDTUxOSAyNTkgMjU5IDUx
OSA1MTkgNTE5IDQyNiA4MDAgNjY3IDY0OCA3NTkgODMzIDY4NSA2MTEgODMzIDg3MCANMzcwIDM3
MCA3NTkgNjg1IDk2MyA4NzAgODMzIDYzMCA4NTIgNzA0IDU1NiA3NzggODMzIDc0MSAxMDkzIDcy
MiANNjY3IDY4NSAzMTUgNTE5IDMxNSA1MTkgNTAwIDI3OCA0NDQgNTM3IDQ0NCA1MzcgNDYzIDMx
NSA1MTkgNTU2IA0yNzggMjU5IDUwMCAyNzggODMzIDU1NiA1MzcgNTM3IDUzNyAzODkgMzcwIDMz
MyA1MzcgNDYzIDcwNCA0NDQgDTQ4MSA0NDQgMzE1IDUxOSAzMTUgNTE5IDI1OSA2NjcgNjY3IDc1
OSA2ODUgODcwIDgzMyA4MzMgNDQ0IDQ0NCANNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA0NjMgNDYzIDQ2
MyA0NjMgMjc4IDI3OCAyNzggMjc4IDU1NiA1MzcgNTM3IA01MzcgNTM3IDUzNyA1MzcgNTM3IDUz
NyA1MzcgNTE5IDQwMCA1MTkgNTE5IDUxOSA1MTkgNjA2IDUzNyA4NDAgDTg0MCAxMDAwIDI3OCAy
NzggMCAxMDAwIDgzMyAwIDUxOSAwIDAgNTE5IDUxOSAwIDAgMCANMCAwIDMwMCAzNDAgMCA2NDgg
NTM3IDQyNiAyOTYgNTE5IDAgNTE5IDAgMCA1NTYgNTU2IA0xMDAwIDI1OSA2NjcgNjY3IDgzMyAx
MTMwIDc5NiA1MDAgMTAwMCA0NDQgNDQ0IDI1OSAyNTkgNTE5IDAgNDgxIA02NjcgMTY3IDAgMzMz
IDMzMyA1NzQgNTc0IDUxOSAyNTkgMjU5IDQ0NCAxMTY3IDY2NyA2ODUgNjY3IDY4NSANNjg1IDM3
MCAzNzAgMzcwIDM3MCA4MzMgODMzIDAgODMzIDgzMyA4MzMgODMzIDI3OCAyNzggMjc4IDI3OCAN
Mjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IF0NL0VuY29kaW5nIDkzIDAgUg0vQmFzZUZvbnQg
L0phbnNvblRleHQtUm9tYW4NL0ZvbnREZXNjcmlwdG9yIDgyIDAgUg0+Pg1lbmRvYmoNNiAwIG9i
ag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUgL0Y0DS9GaXJzdENoYXIgOQ0v
TGFzdENoYXIgMjU1DS9XaWR0aHMgWzI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5
IDI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5IDI1OSANMjU5IDI1OSAyNTkgMjU5IDI1OSAyNTkgMjU5
IDI1OSAyOTYgNDQ0IDUxOSA1MTkgOTI2IDc5NiAyNTkgMzMzIA0zMzMgMzg5IDUxOSAyNTkgMzg5
IDI1OSAzNTIgNTE5IDUxOSA1MTkgNTE5IDUxOSA1MTkgNTE5IDUxOSA1MTkgDTUxOSAyNTkgMjU5
IDUxOSA1MTkgNTE5IDQyNiA3NzUgNjg1IDYxMSA2NjcgNzc4IDYzMCA1OTMgNzU5IDc5NiANMzUy
IDQ4MSA2NjcgNjExIDk0NCA3NzggNzQxIDU5MyA3NDEgNjMwIDU1NiA2NjcgNzc4IDY4NSAxMDAw
IDcwNCANNjExIDY0OCAyOTYgNTE5IDI5NiA1MTkgNTAwIDI3OCA0NjMgNDI2IDMxNSA0NjMgMzcw
IDI5NiA0NjMgNTAwIA0yNzggMjU5IDQ4MSAyNTkgNzc4IDUxOSAzODkgNDQ0IDQ2MyA0MDcgMjk2
IDMxNSA1MTkgNDgxIDY2NyA0ODEgDTQwNyA0NjMgMzMzIDUxOSAzMzMgNTE5IDI1OSA2ODUgNjg1
IDY2NyA2MzAgNzc4IDc0MSA3NzggNDYzIDQ2MyANNDYzIDQ2MyA0NjMgNDYzIDMxNSAzNzAgMzcw
IDM3MCAzNzAgMjc4IDI3OCAyNzggMjc4IDUxOSAzODkgMzg5IA0zODkgMzg5IDM4OSA1MTkgNTE5
IDUxOSA1MTkgNTE5IDQwMCA1MTkgNTE5IDUxOSA1MTkgNjUwIDUxOSA3NzUgDTc3NSA5NTAgMjc4
IDI3OCAwIDkyNiA3NDEgMCA1MTkgMCAwIDUxOSA1MTkgMCAwIDAgDTAgMCAyNzggMjUwIDAgNTU2
IDM4OSA0MjYgMjk2IDUxOSAwIDUxOSAwIDAgNTE5IDUxOSANMTAwMCAyNTkgNjg1IDY4NSA3NDEg
OTYzIDU5MyA1MDAgMTAwMCA0NDQgNDQ0IDI1OSAyNTkgNTE5IDAgNDA3IA02MTEgMTY3IDAgMzMz
IDMzMyA1MzcgNTM3IDUxOSAyNTkgMjU5IDQ0NCAxMTY3IDY4NSA2MzAgNjg1IDYzMCANNjMwIDM1
MiAzNTIgMzUyIDM1MiA3NDEgNzQxIDAgNzQxIDc3OCA3NzggNzc4IDI3OCAyNzggMjc4IDI3OCAN
Mjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IF0NL0VuY29kaW5nIDkzIDAgUg0vQmFzZUZvbnQg
L1BIRkVIQStKYW5zb25UZXh0LUl0YWxpYw0vRm9udERlc2NyaXB0b3IgODQgMCBSDT4+DWVuZG9i
ag03IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjYNL0ZpcnN0
Q2hhciA5DS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbMjQ1IDI0NSAyNDUgMjQ1IDI0NSAyNDUgMjQ1
IDI0NSAyNDUgMjQ1IDI0NSAyNDUgMjQ1IDI0NSAyNDUgMjQ1IA0yNDUgMjQ1IDI0NSAyNDUgMjQ1
IDI0NSAyNDUgMjQ1IDI0NiAzNjAgNDkwIDQ5MCA4NTggNTkwIDI1MCAzMDAgDTMwMCAzNzYgNDkw
IDI0NSAzMTggMjQ1IDU0NyA0OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCANNDkw
IDI0NSAyNDUgNDkwIDQ5MCA0OTAgNDU0IDgzMyA1MjggNDc5IDQ1MiA1MzAgMzkyIDM5NCA1NjMg
NTU1IA0yNTUgMzUyIDUxMyAzNzMgNzIyIDU3MyA1ODIgNDg3IDU4MiA1MzAgNDQwIDQxNCA1NDQg
NTY1IDc5MyA1NDUgDTUxNCA1MDggMzIwIDI1MCAzMjAgNDkwIDUwMCAzMDAgNDMzIDQzMyAzMTUg
NDMzIDQxNCAyOTkgNDM3IDQyNCANMjA5IDIwOSA0NDAgMjEwIDYzOSA0MjQgNDM2IDQzMyA0MzMg
MzE1IDM3NiAzMDggNDIzIDQ1MiA2OTQgNDg5IA00NTIgNDAxIDMwMCAyNTAgMzAwIDQ5MCAyNDUg
NTI4IDUyOCA0NTIgMzkyIDU3MyA1ODIgNTQ0IDQzMyA0MzMgDTQzMyA0MzMgNDMzIDQzMyAzMTUg
NDE0IDQxNCA0MTQgNDE0IDIwOSAyMDkgMjA5IDIwOSA0MjQgNDM2IDQzNiANNDM2IDQzNiA0MzYg
NDIzIDQyMyA0MjMgNDIzIDQ5MSA0MDAgNDkwIDQ5MCA0OTEgNDIwIDYwMCA0NzggODMwIA04MzAg
ODAwIDMwMCAzMDAgMCA2NzQgNTgyIDAgNDkwIDAgMCA0OTAgNDIzIDAgMCAwIA0wIDAgMzAwIDMw
MCAwIDY0MCA0MzYgNDU0IDI0NiA0OTAgMCA0OTAgMCAwIDQzMyA0MzMgDTEwMDAgMjQ1IDUyOCA1
MjggNTgyIDc0NSA2NTMgNTAwIDEwMDAgNDkxIDQ5MSAzMDIgMzAyIDQ5MCAwIDQ1MiANNTE0IDE2
NiAwIDI2MCAyNjAgNTM1IDUzNSA0OTAgMjQ1IDMwMyA0OTEgMTIzNCA1MjggMzkyIDUyOCAzOTIg
DTM5MiAyNTUgMjU1IDI1NSAyNTUgNTgyIDU4MiAwIDU4MiA1NDQgNTQ0IDU0NCAyMDkgMzAwIDMw
MCAzMDAgDTMwMCAzMDAgMzAwIDMwMCAzMDAgMzAwIDMwMCBdDS9FbmNvZGluZyA5MyAwIFINL0Jh
c2VGb250IC9GdXR1cmEtQ29uZGVuc2VkQm9sZA0vRm9udERlc2NyaXB0b3IgODYgMCBSDT4+DWVu
ZG9iag04IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjgNL0Vu
Y29kaW5nIDkzIDAgUg0vQmFzZUZvbnQgL0hlbHZldGljYS1Cb2xkDT4+DWVuZG9iag05IDAgb2Jq
DTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjEwDS9FbmNvZGluZyA5MyAw
IFINL0Jhc2VGb250IC9IZWx2ZXRpY2ENPj4NZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBlIC9Gb250
DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjE0DS9FbmNvZGluZyA5MyAwIFINL0Jhc2VGb250IC9U
aW1lcy1Cb2xkSXRhbGljDT4+DWVuZG9iag0xMSAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlw
ZSAvVHlwZTENL05hbWUgL0YxNg0vRW5jb2RpbmcgOTMgMCBSDS9CYXNlRm9udCAvVGltZXMtSXRh
bGljDT4+DWVuZG9iag0yNyAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05h
bWUgL0YxOA0vRmlyc3RDaGFyIDkNL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsyNzggMjc4IDI3OCAy
NzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggDTI3OCAy
NzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggMzMzIDUwMCA1NTYgNTU2IDk0NCA4NzAgMjc4IDM1
MiANMzUyIDQyNiA1NTYgMjc4IDQyNiAyNzggMzcwIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1
NiA1NTYgNTU2IA01NTYgMjc4IDI3OCA1NTYgNTU2IDU1NiA0NDQgODAwIDcwNCA3MDQgNzk2IDg1
MiA3MDQgNjMwIDg1MiA4ODkgDTQwNyA0MDcgNzk2IDY4NSAxMDAwIDg3MCA4NzAgNjY3IDg3MCA3
NDEgNTc0IDgxNSA4MzMgNzU5IDEwNzQgNzU5IA02ODUgNzQxIDM1MiA1NTYgMzUyIDU1NiA1MDAg
Mjc4IDQ4MSA1NzQgNDgxIDU3NCA1MTkgMzMzIDU1NiA1OTMgDTI5NiAyOTYgNTU2IDI5NiA4ODkg
NTkzIDU3NCA1NzQgNTc0IDQyNiA0MjYgMzcwIDU5MyA0ODEgNzU5IDQ4MSANNTAwIDUwMCAzNTIg
NTU2IDM1MiA1NTYgMjc4IDcwNCA3MDQgNzk2IDcwNCA4NzAgODcwIDgzMyA0ODEgNDgxIA00ODEg
NDgxIDQ4MSA0ODEgNDgxIDUxOSA1MTkgNTE5IDUxOSAyOTYgMjk2IDI5NiAyOTYgNTkzIDU3NCA1
NzQgDTU3NCA1NzQgNTc0IDU5MyA1OTMgNTkzIDU5MyA1NTYgNDAwIDU1NiA1NTYgNTU2IDU1NiA3
NDcgNTc0IDgyNyANODI3IDEwMDAgMjc4IDI3OCAwIDEwMTkgODcwIDAgNTU2IDAgMCA1NTYgNTU2
IDAgMCAwIA0wIDAgMzMzIDM1MCAwIDcwNCA1NzQgNDQ0IDMzMyA1NTYgMCA1NTYgMCAwIDU1NiA1
NTYgDTEwMDAgMjc4IDcwNCA3MDQgODcwIDExMzAgODUyIDUwMCAxMDAwIDUwMCA1MDAgMjc4IDI3
OCA1NTYgMCA1MDAgDTY4NSAxNjcgMCAzMzMgMzMzIDYxMSA2MTEgNTU2IDI3OCAyNzggNTAwIDEx
NjcgNzA0IDcwNCA3MDQgNzA0IA03MDQgNDA3IDQwNyA0MDcgNDA3IDg3MCA4NzAgMCA4NzAgODMz
IDgzMyA4MzMgMjk2IDI3OCAyNzggMjc4IA0yNzggMjc4IDI3OCAyNzggMjc4IDI3OCAyNzggXQ0v
RW5jb2RpbmcgOTMgMCBSDS9CYXNlRm9udCAvSmFuc29uVGV4dC1Cb2xkDS9Gb250RGVzY3JpcHRv
ciA4NyAwIFINPj4NZW5kb2JqDTMxIDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UeXBl
MQ0vTmFtZSAvRjIwDS9GaXJzdENoYXIgOQ0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWzI1MCAyNTAg
MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAN
MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAzMzMgMjUwIDUwMCA1MDAgODMzIDY2NyAy
NTAgMzMzIA0zMzMgNTAwIDUwMCAyNTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCA1MDAgDTUwMCAyNTAgMjUwIDUwMCA1MDAgNTAwIDUwMCA4MDAgNTU2IDU1NiA1
NTYgNjExIDUwMCA0NDQgNjExIDYxMSANMjc4IDQ0NCA1NTYgNTAwIDc3OCA2MTEgNjExIDU1NiA2
MTEgNjExIDU1NiA1MDAgNjExIDU1NiA4MzMgNTU2IA01NTYgNTAwIDMzMyAyNTAgMzMzIDUwMCA1
MDAgMzMzIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgDTIyMiAyMjIgNDQ0IDIyMiA3
NzggNTAwIDUwMCA1MDAgNTAwIDMzMyA0NDQgMjc4IDUwMCA0NDQgNjY3IDQ0NCANNDQ0IDM4OSAy
NzQgMjUwIDI3NCA1MDAgMjUwIDU1NiA1NTYgNTU2IDUwMCA2MTEgNjExIDYxMSA0NDQgNDQ0IA00
NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyMjIgMjIyIDIyMiAyMjIgNTAwIDUw
MCA1MDAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNDAwIDUwMCA1MDAgNTAwIDMz
MyA0NDAgNTAwIDgwMCANODAwIDc1MCAzMzMgMzMzIDAgODMzIDYxMSAwIDUwMCAwIDAgNTAwIDUw
MCAwIDAgMCANMCAwIDMwMCAzMDAgMCA2NjcgNTAwIDUwMCAzMzMgNTAwIDAgNTAwIDAgMCA1MDAg
NTAwIA0xMDAwIDI1MCA1NTYgNTU2IDYxMSA4MzMgNzIyIDUwMCAxMDAwIDM4OSAzODkgMjIyIDIy
MiA1MDAgMCA0NDQgDTU1NiAxNjcgMCAyNzggMjc4IDUwMCA1MDAgNTAwIDI1MCAyMjIgMzg5IDEx
MTEgNTU2IDUwMCA1NTYgNTAwIA01MDAgMjc4IDI3OCAyNzggMjc4IDYxMSA2MTEgMCA2MTEgNjEx
IDYxMSA2MTEgMjIyIDMzMyAzMzMgMzMzIA0zMzMgMjUwIDI1MCAzMzMgMzMzIDMzMyAzMzMgXQ0v
RW5jb2RpbmcgOTMgMCBSDS9CYXNlRm9udCAvSGVsdmV0aWNhLUNvbmRlbnNlZA0vRm9udERlc2Ny
aXB0b3IgODggMCBSDT4+DWVuZG9iag0zMiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAv
VHlwZTENL05hbWUgL0YyMg0vRmlyc3RDaGFyIDkNL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsyNTAg
MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAy
NTAgDTI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMzMzIDMzMyA1MDAgNTAwIDgzMyA2
NjcgMjUwIDMzMyANMzMzIDUwMCA1MDAgMzMzIDMzMyAzMzMgMjc4IDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCA1MDAgNTAwIA01MDAgMjc4IDI3OCA1MDAgNTAwIDUwMCA1MDAgODMzIDU1NiA1
NTYgNTU2IDYxMSA1MDAgNTAwIDYxMSA2MTEgDTI3OCA0NDQgNTU2IDUwMCA3NzggNjExIDYxMSA1
NTYgNjExIDYxMSA1NTYgNTAwIDYxMSA1NTYgODMzIDU1NiANNTU2IDUwMCAzMzMgMjUwIDMzMyA1
MDAgNTAwIDMzMyA1MDAgNTAwIDQ0NCA1MDAgNTAwIDI3OCA1MDAgNTAwIA0yNzggMjc4IDQ0NCAy
NzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgNDQ0IDI3OCA1MDAgNDQ0IDY2NyA0NDQgDTQ0NCAz
ODkgMjc0IDI1MCAyNzQgNTAwIDI1MCA1NTYgNTU2IDU1NiA1MDAgNjExIDYxMSA2MTEgNTAwIDUw
MCANNTAwIDUwMCA1MDAgNTAwIDQ0NCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCAyNzggMjc4IDUw
MCA1MDAgNTAwIA01MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDQwMCA1MDAgNTAwIDUw
MCA0MjAgNTUwIDUwMCA4MzAgDTgzMCA4NjAgMzMzIDMzMyAwIDc3OCA2MTEgMCA1MDAgMCAwIDUw
MCA1MDAgMCAwIDAgDTAgMCAzMDAgMzAwIDAgNzIyIDUwMCA1MDAgMzMzIDUwMCAwIDUwMCAwIDAg
NTAwIDUwMCANMTAwMCAyNTAgNTU2IDU1NiA2MTEgODMzIDcyMiA1MDAgMTAwMCA1MDAgNTAwIDI3
OCAyNzggNTAwIDAgNDQ0IA01NTYgMTY3IDAgMjc4IDI3OCA1MDAgNTAwIDUwMCAzMzMgMjc4IDUw
MCAxMTExIDU1NiA1MDAgNTU2IDUwMCANNTAwIDI3OCAyNzggMjc4IDI3OCA2MTEgNjExIDAgNjEx
IDYxMSA2MTEgNjExIDI3OCAzMzMgMzMzIDMzMyANMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMz
IF0NL0VuY29kaW5nIDkzIDAgUg0vQmFzZUZvbnQgL0hlbHZldGljYS1Db25kZW5zZWQtQm9sZA0v
Rm9udERlc2NyaXB0b3IgODkgMCBSDT4+DWVuZG9iag0zNiAwIG9iag08PA0vVHlwZSAvRm9udA0v
U3VidHlwZSAvVHlwZTENL05hbWUgL0YyNA0vRmlyc3RDaGFyIDkNL0xhc3RDaGFyIDI1NQ0vV2lk
dGhzIFsyMDUgMjA1IDIwNSAyMDUgMjA1IDIwNSAyMDUgMjA1IDIwNSAyMDUgMjA1IDIwNSAyMDUg
MjA1IDIwNSAyMDUgDTIwNSAyMDUgMjA1IDIwNSAyMDUgMjA1IDIwNSAyMDUgMjUyIDI1MCA0MTEg
NDExIDU1MyA0OTQgMjUwIDI3NiANMjc2IDM1NyA1MDAgMjA1IDI0MiAyMDUgNDA3IDQxMSA0MTEg
NDExIDQxMSA0MTEgNDExIDQxMSA0MTEgNDExIA00MTEgMjA1IDIwNSA1MDAgNTAwIDUwMCAzNDEg
ODAwIDQxNCA0MTggMzY5IDQ2NiAzNDcgMzQyIDQ2MCA0NzMgDTIyMiAzMDMgNDI0IDMzMSA1NjEg
NDcyIDQ3NiAzODggNDc5IDQxNiAzNTQgMzIzIDQ2NyAzODcgNTkyIDQyNyANMzkyIDM5MyAzMDAg
MjUwIDMwMCA1MDAgNTAwIDI4MCAzODAgMzgwIDI3OCAzODAgMzYxIDI0OSAzODIgMzg4IA0xODAg
MTgwIDM5NSAxODAgNTkwIDM4OCAzNzUgMzgwIDM4MCAyNjkgMjc2IDIyMSAzODkgMzU4IDQ4NyAz
OTUgDTM3MyAzMzUgMjU4IDI1MCAyNTggNTAwIDIwNSA0MTQgNDE0IDM2OSAzNDcgNDcyIDQ3NiA0
NjcgMzgwIDM4MCANMzgwIDM4MCAzODAgMzgwIDI3OCAzNjEgMzYxIDM2MSAzNjEgMTgwIDE4MCAx
ODAgMTgwIDM4OCAzNzUgMzc1IA0zNzUgMzc1IDM3NSAzODkgMzg5IDM4OSAzODkgMzU5IDQwMCA0
MTEgNDExIDQxNSA0MDAgNDQwIDQyNSA4MDAgDTgwMCA3NTAgMjgwIDI4MCAwIDU2NiA0NzYgMCA1
MDAgMCAwIDQxMSAzODggMCAwIDAgDTAgMCAyMjggMjI4IDAgNTYxIDM3NSAzNDEgMjUyIDUwMCAw
IDQxMSAwIDAgMzU3IDM1NyANMTAwMCAyMDUgNDE0IDQxNCA0NzYgNTk4IDU4MSA1MDAgMTAwMCAz
NDQgMzQ0IDIxMyAyMTMgNTAwIDAgMzczIA0zOTIgMTIyIDAgMjM4IDIzOCA0NTkgNDQ1IDM1OSAy
MDUgMjEzIDM0NCA4MTcgNDE0IDM0NyA0MTQgMzQ3IA0zNDcgMjIyIDIyMiAyMjIgMjIyIDQ3NiA0
NzYgMCA0NzYgNDY3IDQ2NyA0NjcgMTgwIDI4MCAyODAgMjgwIA0yODAgMjgwIDI4MCAyODAgMjgw
IDI4MCAyODAgXQ0vRW5jb2RpbmcgOTMgMCBSDS9CYXNlRm9udCAvRnV0dXJhLUNvbmRlbnNlZA0v
Rm9udERlc2NyaXB0b3IgOTAgMCBSDT4+DWVuZG9iag05NCAwIG9iag08PA0vVHlwZSAvRm9udA0v
U3VidHlwZSAvVHlwZTENL05hbWUgL0YyNg0vRmlyc3RDaGFyIDY1DS9MYXN0Q2hhciAyNDcNL1dp
ZHRocyBbNzUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMTAwMCAxMDAwIA0xMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAg
MTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIA0x
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAw
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAxMDAw
IA0wIDAgMCAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDEwMDAgMCAxMDAwIA0wIDAgMCAwIDAgMCAw
IDAgMTAwMCAwIDAgMTAwMCAwIDAgMCAwIA0xMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAx
MDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIA0wIDEwMDAg
MCAxMDAwIDEwMDAgMTAwMCAxMDAwIDAgMCAwIDAgMTAwMCAxMDAwIDEwMDAgMTAwMCAxMDAwIA0w
IDEwMDAgMTAwMCAxMDAwIDAgMTAwMCAxMDAwIF0NL0VuY29kaW5nIDk1IDAgUg0vQmFzZUZvbnQg
L1BIRE1NSytFdXJvcGF0Y2gNL0ZvbnREZXNjcmlwdG9yIDkxIDAgUg0+Pg1lbmRvYmoNNDAgMCBv
YmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1R5cGUxDS9OYW1lIC9GMjcNL0VuY29kaW5nIDk2
IDAgUg0vQmFzZUZvbnQgL1N5bWJvbA0+Pg1lbmRvYmoNNzAgMCBvYmoNPDwNL1R5cGUgL0ZvbnQN
L1N1YnR5cGUgL1R5cGUxDS9OYW1lIC9GMjgNL0VuY29kaW5nIDk3IDAgUg0vQmFzZUZvbnQgL1N5
bWJvbA0+Pg1lbmRvYmoNNzEgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1R5cGUxDS9O
YW1lIC9GMjkNL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nDS9CYXNlRm9udCAvSGVsdmV0aWNh
DT4+DWVuZG9iag03MiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUg
L0YzMA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcNL0Jhc2VGb250IC9IZWx2ZXRpY2EtQm9s
ZA0+Pg1lbmRvYmoNOTMgMCBvYmoNPDwNL1R5cGUgL0VuY29kaW5nDS9EaWZmZXJlbmNlcyBbIDkv
c3BhY2UgMzkvcXVvdGVzaW5nbGUgOTYvZ3JhdmUgMTI4L0FkaWVyZXNpcy9BcmluZy9DY2VkaWxs
YS9FYWN1dGUvTnRpbGRlDS9PZGllcmVzaXMvVWRpZXJlc2lzL2FhY3V0ZS9hZ3JhdmUvYWNpcmN1
bWZsZXgvYWRpZXJlc2lzL2F0aWxkZS9hcmluZw0vY2NlZGlsbGEvZWFjdXRlL2VncmF2ZS9lY2ly
Y3VtZmxleC9lZGllcmVzaXMvaWFjdXRlL2lncmF2ZS9pY2lyY3VtZmxleA0vaWRpZXJlc2lzL250
aWxkZS9vYWN1dGUvb2dyYXZlL29jaXJjdW1mbGV4L29kaWVyZXNpcy9vdGlsZGUvdWFjdXRlDS91
Z3JhdmUvdWNpcmN1bWZsZXgvdWRpZXJlc2lzL2RhZ2dlci9kZWdyZWUgMTY0L3NlY3Rpb24vYnVs
bGV0L3BhcmFncmFwaA0vZ2VybWFuZGJscy9yZWdpc3RlcmVkL2NvcHlyaWdodC90cmFkZW1hcmsv
YWN1dGUvZGllcmVzaXMvbm90ZXF1YWwvQUUNL09zbGFzaC9pbmZpbml0eS9wbHVzbWludXMvbGVz
c2VxdWFsL2dyZWF0ZXJlcXVhbC95ZW4vbXUvcGFydGlhbGRpZmYNL3N1bW1hdGlvbi9wcm9kdWN0
L3BpL2ludGVncmFsL29yZGZlbWluaW5lL29yZG1hc2N1bGluZS9PbWVnYS9hZQ0vb3NsYXNoL3F1
ZXN0aW9uZG93bi9leGNsYW1kb3duL2xvZ2ljYWxub3QvcmFkaWNhbC9mbG9yaW4vYXBwcm94ZXF1
YWwvRGVsdGENL2d1aWxsZW1vdGxlZnQvZ3VpbGxlbW90cmlnaHQvZWxsaXBzaXMvc3BhY2UvQWdy
YXZlL0F0aWxkZS9PdGlsZGUvT0UNL29lL2VuZGFzaC9lbWRhc2gvcXVvdGVkYmxsZWZ0L3F1b3Rl
ZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvZGl2aWRlDS9sb3plbmdlL3lkaWVyZXNpcy9Z
ZGllcmVzaXMvZnJhY3Rpb24vRXVyby9ndWlsc2luZ2xsZWZ0L2d1aWxzaW5nbHJpZ2h0L2ZpDS9m
bC9kYWdnZXJkYmwvcGVyaW9kY2VudGVyZWQvcXVvdGVzaW5nbGJhc2UvcXVvdGVkYmxiYXNlL3Bl
cnRob3VzYW5kL0FjaXJjdW1mbGV4L0VjaXJjdW1mbGV4DS9BYWN1dGUvRWRpZXJlc2lzL0VncmF2
ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0lncmF2ZS9PYWN1dGUNL09jaXJjdW1mbGV4
L2FwcGxlL09ncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWdyYXZlIDI0Ni9jaXJjdW1mbGV4L3Rp
bGRlDS9tYWNyb24vYnJldmUvZG90YWNjZW50L3JpbmcvY2VkaWxsYS9odW5nYXJ1bWxhdXQvb2dv
bmVrL2Nhcm9uDV0NPj4NZW5kb2JqDTk1IDAgb2JqDTw8DS9UeXBlIC9FbmNvZGluZw0vRGlmZmVy
ZW5jZXMgW10NPj4NZW5kb2JqDTk2IDAgb2JqDTw8DS9UeXBlIC9FbmNvZGluZw0vRGlmZmVyZW5j
ZXMgWyAxNjAvRXVybyAyNDAvYXBwbGUNXQ0+Pg1lbmRvYmoNOTcgMCBvYmoNPDwNL1R5cGUgL0Vu
Y29kaW5nDS9EaWZmZXJlbmNlcyBbIDAvTlVML1NPSC9TVFgvRVRYL0VPVC9FTlEvQUNLL0JFTA0v
QlMvSFQvTEYvVlQvRkYvQ1IvU08vU0kNL0RMRS9EQzEvREMyL0RDMy9EQzQvTkFLL1NZTi9FVEIN
L0NBTi9FTS9TVUIvRVNDL0ZTL0dTL1JTL1VTDSAzNC9xdW90ZWRibCAzNi9kb2xsYXIgMzkvcXVv
dGVzaW5nbGUgNDIvYXN0ZXJpc2sgNDUvaHlwaGVuIDY0L2F0L0EvQg0vQy9EL0UvRi9HL0gvSS9K
DS9LL0wvTS9OL08vUC9RL1INL1MvVC9VL1YvVy9YL1kvWg0gOTIvYmFja3NsYXNoIDk0L2FzY2lp
Y2lyY3VtIDk2L2dyYXZlL2EvYi9jL2QvZQ0vZi9nL2gvaS9qL2svbC9tDS9uL28vcC9xL3Ivcy90
L3UNL3Yvdy94L3kveiAxMjYvYXNjaWl0aWxkZSAxMjgvQWRpZXJlc2lzL0FyaW5nDS9DY2VkaWxs
YS9FYWN1dGUvTnRpbGRlL09kaWVyZXNpcy9VZGllcmVzaXMvYWFjdXRlL2FncmF2ZS9hY2lyY3Vt
ZmxleA0vYWRpZXJlc2lzL2F0aWxkZS9hcmluZy9jY2VkaWxsYS9lYWN1dGUvZWdyYXZlL2VjaXJj
dW1mbGV4L2VkaWVyZXNpcw0vaWFjdXRlL2lncmF2ZS9pY2lyY3VtZmxleC9pZGllcmVzaXMvbnRp
bGRlL29hY3V0ZS9vZ3JhdmUvb2NpcmN1bWZsZXgNL29kaWVyZXNpcy9vdGlsZGUvdWFjdXRlL3Vn
cmF2ZS91Y2lyY3VtZmxleC91ZGllcmVzaXMvZGFnZ2VyL2RlZ3JlZQ0vY2VudC9zdGVybGluZy9z
ZWN0aW9uL2J1bGxldC9wYXJhZ3JhcGgvZ2VybWFuZGJscy9yZWdpc3RlcmVkL2NvcHlyaWdodA0v
dHJhZGVtYXJrL2FjdXRlL2RpZXJlc2lzL25vdGVxdWFsL0FFL09zbGFzaC9pbmZpbml0eSAxNzgv
bGVzc2VxdWFsDSAxODAveWVuL211IDE4My9zdW1tYXRpb24vcHJvZHVjdC9waS9pbnRlZ3JhbC9v
cmRmZW1pbmluZS9vcmRtYXNjdWxpbmUNL09tZWdhL2FlL29zbGFzaC9xdWVzdGlvbmRvd24vZXhj
bGFtZG93bi9sb2dpY2Fsbm90L3JhZGljYWwvZmxvcmluDS9hcHByb3hlcXVhbC9EZWx0YS9ndWls
bGVtb3RsZWZ0L2d1aWxsZW1vdHJpZ2h0L2VsbGlwc2lzL3NwYWNlL0FncmF2ZS9BdGlsZGUNL090
aWxkZS9PRS9vZS9lbmRhc2gvZW1kYXNoL3F1b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0L3F1b3Rl
bGVmdA0vcXVvdGVyaWdodC9kaXZpZGUvbG96ZW5nZS95ZGllcmVzaXMvWWRpZXJlc2lzL2ZyYWN0
aW9uL2N1cnJlbmN5L2d1aWxzaW5nbGxlZnQNL2d1aWxzaW5nbHJpZ2h0L2ZpL2ZsL2RhZ2dlcmRi
bC9wZXJpb2RjZW50ZXJlZC9xdW90ZXNpbmdsYmFzZS9xdW90ZWRibGJhc2UvcGVydGhvdXNhbmQN
L0FjaXJjdW1mbGV4L0VjaXJjdW1mbGV4L0FhY3V0ZS9FZGllcmVzaXMvRWdyYXZlL0lhY3V0ZS9J
Y2lyY3VtZmxleC9JZGllcmVzaXMNL0lncmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvYXBwbGUvT2dy
YXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZ3JhdmUNL2RvdGxlc3NpL2NpcmN1bWZsZXgvdGlsZGUv
bWFjcm9uL2JyZXZlL2RvdGFjY2VudC9yaW5nL2NlZGlsbGENL2h1bmdhcnVtbGF1dC9vZ29uZWsv
Y2Fyb24NXQ0+Pg1lbmRvYmoNMiAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDE2IDAgUg0v
UmVzb3VyY2VzIDQgMCBSDS9Db250ZW50cyAzIDAgUg0+Pg1lbmRvYmoNMTcgMCBvYmoNPDwNL1R5
cGUgL1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyAxOSAwIFINL0NvbnRlbnRzIDE4IDAg
Ug0+Pg1lbmRvYmoNMjAgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291
cmNlcyAyMiAwIFINL0NvbnRlbnRzIDIxIDAgUg0+Pg1lbmRvYmoNMjQgMCBvYmoNPDwNL1R5cGUg
L1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyAyNiAwIFINL0NvbnRlbnRzIDI1IDAgUg0+
Pg1lbmRvYmoNMjggMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNl
cyAzMCAwIFINL0NvbnRlbnRzIDI5IDAgUg0+Pg1lbmRvYmoNMzMgMCBvYmoNPDwNL1R5cGUgL1Bh
Z2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyAzNSAwIFINL0NvbnRlbnRzIDM0IDAgUg0+Pg1l
bmRvYmoNMzcgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyAz
OSAwIFINL0NvbnRlbnRzIDM4IDAgUg0+Pg1lbmRvYmoNNDEgMCBvYmoNPDwNL1R5cGUgL1BhZ2UN
L1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyA0MyAwIFINL0NvbnRlbnRzIDQyIDAgUg0+Pg1lbmRv
YmoNNDYgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNlcyA0OCAw
IFINL0NvbnRlbnRzIDQ3IDAgUg0+Pg1lbmRvYmoNNDkgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1Bh
cmVudCAxNiAwIFINL1Jlc291cmNlcyA1MSAwIFINL0NvbnRlbnRzIDUwIDAgUg0+Pg1lbmRvYmoN
NTIgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1NiAwIFINL1Jlc291cmNlcyA1NCAwIFIN
L0NvbnRlbnRzIDUzIDAgUg0+Pg1lbmRvYmoNNTcgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVu
dCA1NiAwIFINL1Jlc291cmNlcyA1OSAwIFINL0NvbnRlbnRzIDU4IDAgUg0+Pg1lbmRvYmoNNjAg
MCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1NiAwIFINL1Jlc291cmNlcyA2MiAwIFINL0Nv
bnRlbnRzIDYxIDAgUg0+Pg1lbmRvYmoNNjQgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1
NiAwIFINL1Jlc291cmNlcyA2NiAwIFINL0NvbnRlbnRzIDY1IDAgUg0+Pg1lbmRvYmoNNjcgMCBv
YmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1NiAwIFINL1Jlc291cmNlcyA2OSAwIFINL0NvbnRl
bnRzIDY4IDAgUg0+Pg1lbmRvYmoNNzMgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1NiAw
IFINL1Jlc291cmNlcyA3NSAwIFINL0NvbnRlbnRzIDc0IDAgUg0+Pg1lbmRvYmoNMTYgMCBvYmoN
PDwNL1R5cGUgL1BhZ2VzDS9LaWRzIFsyIDAgUiAxNyAwIFIgMjAgMCBSIDI0IDAgUiAyOCAwIFIg
MzMgMCBSIDM3IDAgUiA0MSAwIFIgNDYgMCBSIDQ5IDAgUl0NL0NvdW50IDEwDS9QYXJlbnQgNTUg
MCBSDT4+DWVuZG9iag01NiAwIG9iag08PA0vVHlwZSAvUGFnZXMNL0tpZHMgWzUyIDAgUiA1NyAw
IFIgNjAgMCBSIDY0IDAgUiA2NyAwIFIgNzMgMCBSXQ0vQ291bnQgNg0vUGFyZW50IDU1IDAgUg0+
Pg1lbmRvYmoNNTUgMCBvYmoNPDwNL1R5cGUgL1BhZ2VzDS9LaWRzIFsxNiAwIFIgNTYgMCBSIF0N
L0NvdW50IDE2DS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdDT4+DWVuZG9iag05OCAwIG9iag08PA0v
VHlwZSAvQ2F0YWxvZw0vUGFnZXMgNTUgMCBSDT4+DWVuZG9iag05OSAwIG9iag08PA0vQ3JlYXRp
b25EYXRlIChEOjIwMDAwMTE0MTAzNzA2KQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDMu
MDIgZm9yIFBvd2VyIE1hY2ludG9zaCkNL0F1dGhvciAoQ3J5cFRFQyBNYXJrZXRpbmcpDS9DcmVh
dG9yIChRdWFya1hQcmVzc1wyNTI6IExhc2VyV3JpdGVyIDggOC42KQ0vVGl0bGUgKENyeXB0byBU
dXRvcmlhbCBcKHNocnRcKSAgNi0xNi05OSkNPj4NZW5kb2JqDXhyZWYNMCAxMDANMDAwMDAwMDAw
MCA2NTUzNSBmIA0wMDAwMDAwMDE2IDAwMDAwIG4gDTAwMDAzNjYwMTUgMDAwMDAgbiANMDAwMDA0
MzM3NSAwMDAwMCBuIA0wMDAwMDUxNzg1IDAwMDAwIG4gDTAwMDAzNTM1NjIgMDAwMDAgbiANMDAw
MDM1NDcwNSAwMDAwMCBuIA0wMDAwMzU1ODUzIDAwMDAwIG4gDTAwMDAzNTY5OTYgMDAwMDAgbiAN
MDAwMDM1NzA5OCAwMDAwMCBuIA0wMDAwMzU3MTk2IDAwMDAwIG4gDTAwMDAzNTczMDIgMDAwMDAg
biANMDAwMDI4ODc1OSAwMDAwMCBuIA0wMDAwMjg4ODMxIDAwMDAwIG4gDTAwMDAyODg5MDEgMDAw
MDAgbiANMDAwMDI4ODk3MCAwMDAwMCBuIA0wMDAwMzY3MzU2IDAwMDAwIG4gDTAwMDAzNjYwOTYg
MDAwMDAgbiANMDAwMDA1MjAxNSAwMDAwMCBuIA0wMDAwMDY0OTUyIDAwMDAwIG4gDTAwMDAzNjYx
ODAgMDAwMDAgbiANMDAwMDA2NTA5MSAwMDAwMCBuIA0wMDAwMDgwNTkzIDAwMDAwIG4gDTAwMDAw
ODA3MDEgMDAwMDAgbiANMDAwMDM2NjI2NCAwMDAwMCBuIA0wMDAwMDkyNDc1IDAwMDAwIG4gDTAw
MDAwOTQ3NzcgMDAwMDAgbiANMDAwMDM1NzQwNCAwMDAwMCBuIA0wMDAwMzY2MzQ4IDAwMDAwIG4g
DTAwMDAwOTQ5NDEgMDAwMDAgbiANMDAwMDA5OTUxNSAwMDAwMCBuIA0wMDAwMzU4NTQ5IDAwMDAw
IG4gDTAwMDAzNTk2OTMgMDAwMDAgbiANMDAwMDM2NjQzMiAwMDAwMCBuIA0wMDAwMDk5NjU3IDAw
MDAwIG4gDTAwMDAxMDc5MzIgMDAwMDAgbiANMDAwMDM2MDg0MiAwMDAwMCBuIA0wMDAwMzY2NTE2
IDAwMDAwIG4gDTAwMDAxMDgxMDcgMDAwMDAgbiANMDAwMDEyNDcwMSAwMDAwMCBuIA0wMDAwMzYy
NzQyIDAwMDAwIG4gDTAwMDAzNjY2MDAgMDAwMDAgbiANMDAwMDEyNDg3OCAwMDAwMCBuIA0wMDAw
MTMzMjQxIDAwMDAwIG4gDTAwMDAxMzMzOTIgMDAwMDAgbiANMDAwMDEzNDk5OSAwMDAwMCBuIA0w
MDAwMzY2Njg0IDAwMDAwIG4gDTAwMDAxMzY2MDYgMDAwMDAgbiANMDAwMDE2NDI3MiAwMDAwMCBu
IA0wMDAwMzY2NzY4IDAwMDAwIG4gDTAwMDAxNjQ1MTIgMDAwMDAgbiANMDAwMDE3Nzc0NiAwMDAw
MCBuIA0wMDAwMzY2ODUyIDAwMDAwIG4gDTAwMDAxNzc5MjEgMDAwMDAgbiANMDAwMDE4ODY0MyAw
MDAwMCBuIA0wMDAwMzY3NjAyIDAwMDAwIG4gDTAwMDAzNjc0OTMgMDAwMDAgbiANMDAwMDM2Njkz
NiAwMDAwMCBuIA0wMDAwMTg4ODI4IDAwMDAwIG4gDTAwMDAyMTE2NDAgMDAwMDAgbiANMDAwMDM2
NzAyMCAwMDAwMCBuIA0wMDAwMjExODAzIDAwMDAwIG4gDTAwMDAyMzk5OTAgMDAwMDAgbiANMDAw
MDI0MDE2NSAwMDAwMCBuIA0wMDAwMzY3MTA0IDAwMDAwIG4gDTAwMDAyNTM1ODcgMDAwMDAgbiAN
MDAwMDI1NzIzMSAwMDAwMCBuIA0wMDAwMzY3MTg4IDAwMDAwIG4gDTAwMDAyNTczOTYgMDAwMDAg
biANMDAwMDI3MzIyNSAwMDAwMCBuIA0wMDAwMzYyODM4IDAwMDAwIG4gDTAwMDAzNjI5MzQgMDAw
MDAgbiANMDAwMDM2MzA0NCAwMDAwMCBuIA0wMDAwMzY3MjcyIDAwMDAwIG4gDTAwMDAyNzM0MTUg
MDAwMDAgbiANMDAwMDI4NzkxNSAwMDAwMCBuIA0wMDAwMjg4MDU5IDAwMDAwIG4gDTAwMDAyODgx
ODIgMDAwMDAgbiANMDAwMDI4ODY1OSAwMDAwMCBuIA0wMDAwMjg4NTYwIDAwMDAwIG4gDTAwMDAy
ODg0NjEgMDAwMDAgbiANMDAwMDI4ODM2MiAwMDAwMCBuIA0wMDAwMjg5MDM4IDAwMDAwIG4gDTAw
MDAyODkyNDcgMDAwMDAgbiANMDAwMDMzMTI4MyAwMDAwMCBuIA0wMDAwMzMxNjIzIDAwMDAwIG4g
DTAwMDAzNTA4NTAgMDAwMDAgbiANMDAwMDM1MTA1MSAwMDAwMCBuIA0wMDAwMzUxMjQzIDAwMDAw
IG4gDTAwMDAzNTE0MzggMDAwMDAgbiANMDAwMDM1MTY0MyAwMDAwMCBuIA0wMDAwMzUxODM0IDAw
MDAwIG4gDTAwMDAzNTIwMzEgMDAwMDAgbiANMDAwMDM2MzE1OSAwMDAwMCBuIA0wMDAwMzYxOTgy
IDAwMDAwIG4gDTAwMDAzNjQzNjYgMDAwMDAgbiANMDAwMDM2NDQyMCAwMDAwMCBuIA0wMDAwMzY0
NDk0IDAwMDAwIG4gDTAwMDAzNjc2OTQgMDAwMDAgbiANMDAwMDM2Nzc0NSAwMDAwMCBuIA10cmFp
bGVyDTw8DS9TaXplIDEwMA0vUm9vdCA5OCAwIFINL0luZm8gOTkgMCBSDS9JRCBbPDI1NmZlNjMy
NjgwOTg2YjExOTZiYjY0ZmExYzhmOGYwPjwyNTZmZTYzMjY4MDk4NmIxMTk2YmI2NGZhMWM4Zjhm
MD5dDT4+DXN0YXJ0eHJlZg0zNjc5NzINJSVFT0YNZ2UNL1BhcmVudCAxNiAwIFINL1Jlc291cmNl
cyA0IDAgUg0vQ29udGVudHMgMyAwIFINPj4NZW5kb2JqDTE3IDAgb2JqDTw8DS9UeXBlIC9QYWdl
DS9QYXJlbnQgMTYgMCBSDS9SZXNvdXJjZXMgMTkgMCBSDS9Db250ZW50cyAxOCAwIFINPj4NZW5k
b2JqDTIwIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTYgMCBSDS9SZXNvdXJjZXMgMjIg
MCBSDS9Db250ZW50cyAyMSAwIFINPj4NZW5kb2JqDTI0IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9Q
YXJlbnQgMTYgMCBSDS9SZXNvdXJjZXMgMjYgMCBSDS9Db250ZW50cyAyNSAwIFINPj4NZW5kb2Jq
DTI4IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTYgMCBSDS9SZXNvdXJjZXMgMzAgMCBS
DS9Db250ZW50cyAyOSAwIFINPj4NZW5kb2JqDTMzIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJl
bnQgMTYgMCBSDS9SZXNvdXJjZXMgMzUgMCBSDS9Db250ZW50cyAzNCAwIFINPj4NZW5kb2JqDTM3
IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTYgMCBSDS9SZXNvdXJjZXMgMzkgMCBSDS9D
b250ZW50cyAzOCAwIFINPj4=

------=_NextPart_000_001B_01C02F9E.B8D85F20--


Received: from cata.hud.ac.uk (cata.hud.ac.uk [161.112.232.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10891 for <[e-mail]>; Fri, 6 Oct 2000 08:42:18 -0700 (PDT)
Received: from elros.hud.ac.uk (actually host 61.232.112.161.in-addr.arpa) by cata.hud.ac.uk with SMTP (Mailer) with ESMTP; Fri, 6 Oct 2000 16:46:17 +0100
Received: by ELROS with Internet Mail Service (5.5.2650.21) id <4HQ0ZBDG>; Fri, 6 Oct 2000 16:46:10 +0100
Message-ID: <[e-mail]>
From: "D.S. Macauley C9951632" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Public Key Infrastructures
Date: Fri, 6 Oct 2000 16:45:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Dear Sir/Madam, 
I am a student at the University of Huddersfield and I was wondering if it
would be possible if you had any information on what PKI is and were it
originated from and any other basic background information. Your help would
be most appreciated.

D.Macauley


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06397 for <[e-mail]>; Fri, 6 Oct 2000 08:14:35 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id LAA22412; Fri, 6 Oct 2000 11:14:33 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 6 Oct 2000 11:14:32 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: Carlisle Adams <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: RE: Path Names to AC Holders, Targets and Proxies 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 6 Oct 2000, Carlisle Adams wrote:

> Hi Polar,
> 
> > ----------
> > From: 	Polar Humenn[SMTP:[e-mail]]
> > Sent: 	Friday, October 06, 2000 10:28 AM
> > To: 	[e-mail]
> > Cc: 	[e-mail]; [e-mail]
> > Subject: 	Path Names to AC Holders, Targets and Proxies 
> > 
> > Greetings IETF,
> > 
> > This is Polar Humenn with the Object Management Group (OMG).
> > 
> > I have some questions about total interoperability about the PKIX 
> > Attribute Certificate when used in environments where your application
> > does not have control over both clients and server, i.e. they both don't
> > subscribe to the same LDAP server.
>  
> (...some text deleted...)
> 
> > What can we do about this problem?
> > 
> > I would suggest either changing the definition of GeneralName to include
> > DN paths. Alternatively, I may suggest attribute extensions (critical or
> > non-critical?) that complete the path from the Holder, proxies, or
> > targets.
>  
> GeneralName already does include the full DN (not just the CN, as in your
> example).

I only illustrated that with a "simple" DN, consiting of one RDN.

Am I under the false impression that DN's have structure between the
Subject of a certificate and the Issuer?

I had assumed that it can't from the mere fact that the relationship can
be idempotent, i.e. the subject and issuer can be the same DN. Which would
imply that there would have to be some recursive rule governing the
relationship on the structure. 

So, I think, and please correct me if I am wrong, it is perfectly
reasonable to have the following:

Cert 1:
Subject: "CN=Mickey Mouse, O=Disney, OU=Mousekateers"
Issuer:  "CN=Disney RA, O=A BIG CA Company, OU=DisneyRA"

Cert 2:
Subject: "CN=Disney RA, O=A BIG CA Company, OU=DisneyRA"
Issuer:  "CN=A BIGGER CA, O=Another BIGGER CA Company, L=Lamppona"

So, there is no real correlation between the subject and issuer DN's that
can be counted on within the certificate and from certificate to
certificate.

Is this correct? Please correct me if I am wrong.

If this is correct, then we have a problem with the Attribute Certificate
in the general case.

Cheers,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com



Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05555 for <[e-mail]>; Fri, 6 Oct 2000 07:59:19 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <4D81QN5Z>; Fri, 6 Oct 2000 11:04:43 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'Polar Humenn'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Path Names to AC Holders, Targets and Proxies 
Date: Fri, 6 Oct 2000 11:02:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02FA6.82DD6D40"

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_01C02FA6.82DD6D40
Content-Type: text/plain

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[e-mail]]
> Sent: 	Friday, October 06, 2000 10:28 AM
> To: 	[e-mail]
> Cc: 	[e-mail]; [e-mail]
> Subject: 	Path Names to AC Holders, Targets and Proxies 
> 
> Greetings IETF,
> 
> This is Polar Humenn with the Object Management Group (OMG).
> 
> I have some questions about total interoperability about the PKIX 
> Attribute Certificate when used in environments where your application
> does not have control over both clients and server, i.e. they both don't
> subscribe to the same LDAP server.
 
(...some text deleted...)

> What can we do about this problem?
> 
> I would suggest either changing the definition of GeneralName to include
> DN paths. Alternatively, I may suggest attribute extensions (critical or
> non-critical?) that complete the path from the Holder, proxies, or
> targets.
 
GeneralName already does include the full DN (not just the CN, as in your
example).

Carlisle.


------_=_NextPart_001_01C02FA6.82DD6D40
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.2652.35">
<TITLE>RE: Path Names to AC Holders, Targets and Proxies </TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 06, 2000 10:28 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Path Names to AC Holders, Targets and Proxies </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Greetings IETF,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is Polar Humenn with the Object =
Management Group (OMG).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have some questions about total =
interoperability about the PKIX </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Attribute Certificate when used in =
environments where your application</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not have control over both =
clients and server, i.e. they both don't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">subscribe to the same LDAP =
server.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What can we do about this =
problem?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would suggest either changing the =
definition of GeneralName to include</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DN paths. Alternatively, I may =
suggest attribute extensions (critical or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">non-critical?) that complete the path =
from the Holder, proxies, or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">targets.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">GeneralName already does include the full DN (not just the CN, =
as in your example).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C02FA6.82DD6D40--


Received: from marcy.adiron.com ([128.230.111.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04561 for <[e-mail]>; Fri, 6 Oct 2000 07:27:55 -0700 (PDT)
Received: from localhost (polar@localhost) by marcy.adiron.com (8.9.1/8.9.0) with ESMTP id KAA22302; Fri, 6 Oct 2000 10:28:01 -0400
X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs
Date: Fri, 6 Oct 2000 10:28:00 -0400 (EDT)
From: Polar Humenn <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Path Names to AC Holders, Targets and Proxies 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Greetings IETF,

This is Polar Humenn with the Object Management Group (OMG).

I have some questions about total interoperability about the PKIX 
Attribute Certificate when used in environments where your application
does not have control over both clients and server, i.e. they both don't
subscribe to the same LDAP server.

I have some problems regarding the use of GeneralName for the Holder,
Proxies and Targets fields of the AttributeCertificate.

When using DN's for these names, they only specify one level of naming.
That is, they do not specify the Identity Chain, (i.e. path) upto a
certain authority. Specifically, they do not name the Holder's CA, and its
CA, and so on.

Even using the Issuer-Serial type of GeneralName is not good enough to
identify a holder, proxy, or target of the Attribute Certificate because
it has the same problem in identifying the issuer.

Let me illustrate a security hole that this specification has:

Let's say I am a CA that defines employee identities. I'm pretty low on
the totem pole, because of my organizational structure. My identity
certificate has a path from a real trusted authority, such as:

1. CN=Baltimore
2. CN=General Motors
3. CN=Manufacturing
4. CN=Engineering, L=Germany
5. CN=Human Resources

All my employee identities are defined by 5 and their certificates are
signed by 5's public key. Here's one of my employees and his certificate
serial number:

6. CN=Henry Ford      Serial#=1234

I obviously listed the chain with 1 as the most significant. For example,
if Henry authenticates via TLS, he delivers a chain of these 6
certificates.

And now for something completely different, let's switch to Holden Car
Company, Australia.

The privilege service that Holden subscribes to wants to issue a attribute
certificate to Henry Ford from General Motors so that he can access the
Holden plant through the Internet. It is clearly not enough that I just
define the "Holder" as using the Issuer-Serial form of GeneralName, such
as:

CN=Human Resources
Serial#=1234

I really have to fully define the path of the holder so that we can verify
that the attribute certificate actually applies to the identity I am
presented with.

For a contrived example, let's say the GM has authenticated a client using
SSL, and the plant has Versign's verification certificate (i.e.
CN=Verisign). The authentication provides me with the following cert
chain, which the GM plant has verified:

1. CN=Verisign
2. CN=Holden
3. CN=Human Resources
4. CN=Ian Botham, Serial#=1234

Then he delivers to the plant the Attribute Certificate for Henry Ford.

Does it match? Yes, it sure does. 
Should this happen? Obviously not.

I know it's a bit contrived, but it is a security hole.

Now, if the Holder contained the name path to that serial number, then
there wouldn't even be a question of whether the AC applied to Ian Botham
or not.  (Provided both the privilege service and target both trust the
same named high-level certificates, such as Verisign or Baltimore for
verification).

The same goes for the naming of the targets and proxies.

The problem exists for regular DN naming as their may be two CN=Henry
Fords at both GM and Holden.

What can we do about this problem?

I would suggest either changing the definition of GeneralName to include
DN paths. Alternatively, I may suggest attribute extensions (critical or
non-critical?) that complete the path from the Holder, proxies, or
targets.

I do not have a problem with the Issuer of the Attribute Certificate,
because that will be followed by some verifying PK certificates, which
consequently defines the issuers name path.

Any comments?

Cheers and Thanks,
-Polar

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[e-mail]       2-212 CST      
Phone: [phone]           Syracuse, NY 13244-4100
Fax:   [phone]           http://www.adiron.com




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04512 for <[e-mail]>; Fri, 6 Oct 2000 07:27:23 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA31492; Fri, 6 Oct 2000 16:36:40 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA10972; Fri, 6 Oct 2000 16:30:49 +0200
Message-ID: <[e-mail]>
Date: Fri, 06 Oct 2000 16:26:56 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

Thank you for your response.

The only remaining issues are numbered 3 and 10. See my comments embedded
below.
 
> Denis:
> 
> Thank you for addressing my concerns.  I address each of your proposed
> resolutions below.
> 
> TECHNICAL
> 
> 1 and 2. Your proposed resolution resolves my concern.
> 
> 3. I am not satisfied.  I accept that this is not the place to define TSP
> policy or practice statements.  However, I do not think that the RFC 2459
> syntax is appropriate for use in the TSP context.  Also, you ignored my
> concern regarding qualifiers.  RFC 2459 contains:
> 
>     PolicyInformation ::= SEQUENCE {
>          policyIdentifier   CertPolicyId,
>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                  PolicyQualifierInfo OPTIONAL }
> 
> I would prefer a structure that said "TSAPolicyId" instead of
> "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> confuse matters.  Also, I would like to omit policy qualifiers
> altogether.  I do not like them in certificate policies, and I would like
> to avoid them in TSA policies.

I had corrected the text but I did not understood your were also requesting
an ASN.1 change.
Sorry about that misunderstanding. I agree with your request and I have done
the changes, i.e:

 TSAPolicyId ::= OBJECT IDENTIFIER

and in the request:

 reqPolicy       TSAPolicyId    OPTIONAL,

while in the response:

 policy          TSAPolicyId,

> 4 through 9. Your proposed resolution resolves my concern.
> 
> 10. This comment is related to comment number 9, but it has absolutely
> nothing to do with flow.  It has to do with the specification of file
> naming conventions.  I would like to see a section that is parallel to RFC
> 2633, Section 3.2.1.  Further, I think that that file naming conventions
> should be labeled SHOULD, not MUST.

I understand the last sentence of your request, but I'm not sure what you
are requesting for the remaining of it-- all the text in Section 3.2.1 of
2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
would like to see something similar to the paragraph regarding base name
(i.e., 8 characters, can be any distinct name, ..) although many systems
today are no more limited to 8 characters. :-) If you want some specific
addition, would you be able to propose it ?

Regards,

Denis
 
> 11. Fair enough; CMP should include a state machine too.  I believe that
> many interoperability issues can be avoided by specifying the state
> machine.  I am not going to hold things up over this issue.
> 
> 12 and 13. Your proposed resolution resolves my concern.
> 
> EDITORIAL
> 
> 14 and 15. Your proposed resolution resolves my concern.
> 
> 16. Okay.  As I said, this is an editorial comment, so I can live with the
> current text.
> 
> 17 through 24. Your proposed resolution resolves my concern.
> 
> Russ


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00580 for <[e-mail]>; Fri, 6 Oct 2000 03:51:44 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28131; Fri, 6 Oct 2000 06:55:48 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: An Internet Attribute Certificate Profile for Authorization to Proposed Standard
Reply-to: [e-mail]
Date: Fri, 06 Oct 2000 06:55:48 -0400
Sender: [e-mail]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider An Internet Attribute Certificate
Profile for Authorization <draft-ietf-pkix-ac509prof-05.txt> as a
Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by October 20, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-05.txt




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29551 for <[e-mail]>; Fri, 6 Oct 2000 03:27:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27530; Fri, 6 Oct 2000 06:31:18 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dcs-07.txt
Date: Fri, 06 Oct 2000 06:31:17 -0400
Sender: [e-mail]

--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 Data 
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev, 
                          R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-07.txt
	Pages		: 48
	Date		: 05-Oct-00
	
This document describes a general Data Validation and Certification
Server (DVCS) and the protocols to be used when communicating with
it.  The Data Validation and Certification Server is a Trusted Third
Party (TTP) that can be used as one component in building reliable
non-repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to assert the validity of signed documents, public key
certificates, and the possession or existence of data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-07.txt

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-dcs-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-dcs-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dcs-07.txt

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

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

--OtherAccess--

--NextPart--




Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA17125 for <[e-mail]>; Thu, 5 Oct 2000 19:26:03 -0700 (PDT)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA07908; Fri, 6 Oct 2000 12:36:41 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2650.21) id <4JT5LG4S>; Fri, 6 Oct 2000 13:28:11 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Jung Joo-won <[e-mail]>, [e-mail]
Subject: RE: Requirement or API for EE's key management
Date: Fri, 6 Oct 2000 13:28:11 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Jung,
I'm afraid there is no single API covering all aspects of credentials
management you've listed.

Probably CDSA CSSM API may be the best choice here. Not sure you'll find
anything on certificate validation path creation. There is a number of
freeware and commercial cert management libraries, but I'm not sure they use
common API. I'm pretty sure that they aren't, actually.

The CMP presents an acceptable model about EE keys/certs management.

Michael

-----Original Message-----
From: Jung Joo-won [mailto:[e-mail]]
Sent: Friday, 6 October 2000 4:03
To: [e-mail]
Subject: Requirement or API for EE's key management



Is there any documents or specifications about the requirement or
API of End Entity's key pair management?

I do not talk about CMP but about the common API or security
requirements document about key pair generation, storing to hard disk
or floppy or smart card, key pair export/import, certificate download(?)
and certificate validation path creation.

Are there acceptable models about End Entity (or keyholder)'s
private key and certificate management?

Thanks in advance.

Joo-won Jung

-- 
Jung Joowon				| E-mail: [e-mail]
Dept. of Computer Science		|     /\^	Always being
Korea Advanced Inst. of Sci. and Tech.	|    /   \/\		with Network
Taejon, Republic of Korea, 305-701	|   /	  \ \	Mountain Duck
(Quack)


Received: from jupiter.kaist.ac.kr (jupiter.kaist.ac.kr [143.248.135.80]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07049 for <[e-mail]>; Thu, 5 Oct 2000 10:57:29 -0700 (PDT)
Received: (from jwjung@localhost) by jupiter.kaist.ac.kr (8.9.3/8.9.3) id DAA06051 for [e-mail]; Fri, 6 Oct 2000 03:02:59 +0900 (KST)
Date: Fri, 6 Oct 2000 03:02:58 +0900
From: Jung Joo-won <[e-mail]>
To: [e-mail]
Subject: Requirement or API for EE's key management
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i

Is there any documents or specifications about the requirement or
API of End Entity's key pair management?

I do not talk about CMP but about the common API or security
requirements document about key pair generation, storing to hard disk
or floppy or smart card, key pair export/import, certificate download(?)
and certificate validation path creation.

Are there acceptable models about End Entity (or keyholder)'s
private key and certificate management?

Thanks in advance.

Joo-won Jung

-- 
Jung Joowon				| E-mail: [e-mail]
Dept. of Computer Science		|     /\^	Always being
Korea Advanced Inst. of Sci. and Tech.	|    /   \/\		with Network
Taejon, Republic of Korea, 305-701	|   /	  \ \	Mountain Duck (Quack)


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06648 for <[e-mail]>; Thu, 5 Oct 2000 10:46:30 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA16210 for <[e-mail]>; Thu, 5 Oct 2000 10:49:59 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 05 Oct 2000 13:49:20 -0400
To: IETF-PXIX <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: TSP: Response to the comments raised by Russ Housley
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Denis:

Thank you for addressing my concerns.  I address each of your proposed 
resolutions below.

TECHNICAL

1 and 2. Your proposed resolution resolves my concern.


3. I am not satisfied.  I accept that this is not the place to define TSP 
policy or practice statements.  However, I do not think that the RFC 2459 
syntax is appropriate for use in the TSP context.  Also, you ignored my 
concern regarding qualifiers.  RFC 2459 contains:

    PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

I would prefer a structure that said "TSAPolicyId" instead of 
"CertPolicyId." Using "CertPolicyId" in this context will, in my opinion, 
confuse matters.  Also, I would like to omit policy qualifiers 
altogether.  I do not like them in certificate policies, and I would like 
to avoid them in TSA policies.


4 through 9. Your proposed resolution resolves my concern.


10. This comment is related to comment number 9, but it has absolutely 
nothing to do with flow.  It has to do with the specification of file 
naming conventions.  I would like to see a section that is parallel to RFC 
2633, Section 3.2.1.  Further, I think that that file naming conventions 
should be labeled SHOULD, not MUST.


11. Fair enough; CMP should include a state machine too.  I believe that 
many interoperability issues can be avoided by specifying the state 
machine.  I am not going to hold things up over this issue.


12 and 13. Your proposed resolution resolves my concern.


EDITORIAL

14 and 15. Your proposed resolution resolves my concern.


16. Okay.  As I said, this is an editorial comment, so I can live with the 
current text.


17 through 24. Your proposed resolution resolves my concern.


Russ



Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26558 for <[e-mail]>; Thu, 5 Oct 2000 05:01:00 -0700 (PDT)
Received: from hippo ([64.229.128.18]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001005120456.RIEP625.tomts8-srv.bellnexxia.net@hippo> for <[e-mail]>; Thu, 5 Oct 2000 08:04:56 -0400
From: "Raymond Lee" <[e-mail]>
To: <[e-mail]>
Subject: unsubscribe
Date: Thu, 5 Oct 2000 05:06:46 -0700
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <[e-mail]>
Importance: Normal

unsubscribe


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23335 for <[e-mail]>; Wed, 4 Oct 2000 08:39:53 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA19701; Wed, 4 Oct 2000 17:43:50 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 4 Oct 2000 17:43:50 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA26164; Wed, 4 Oct 2000 17:43:54 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA26749; Wed, 4 Oct 2000 17:43:55 +0200 (MET DST)
Date: Wed, 4 Oct 2000 17:43:55 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

> 
> Thanks a lot. 
> 
You are welcome. 


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18381 for <[e-mail]>; Wed, 4 Oct 2000 08:13:29 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA14136 for <[e-mail]>; Wed, 4 Oct 2000 17:22:37 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA05280 for <[e-mail]>; Wed, 4 Oct 2000 17:16:52 +0200
Message-ID: <[e-mail]>
Date: Wed, 04 Oct 2000 12:05:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocsp-path-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on the document on Path discovery

It is questionable whether this function, used alone, should be considered
an extension to OCSP.

Today the basic task of OCSP is to provide the revocation status of the
certificate. However, path discovery may be useful even if no OSCP service
is ever supported by the CA which has issued the certificate (but only
CRLs).

It would seem more appropriate to allow the same server to support both an
OCSP service and a path discovery service, rather than to consider this
service as an extension to OCSP.

Since an OCSP request is assumed to be used, that request includes the
certificate identifier of the leaf certificate. However, the definition of
the "top" root key and the constraints are is missing. They may be indicated
using one of the following ways:

1) with an OID of the validation policy, or
2) with a set of self-signed certificates, and, if the Certificate Policy
constraints and the naming constrains are not included in it, to specify
them separately. For the revocation information, it should be possible to
indicate whether CRLs or OCSP responses are requested, at least for the leaf
certificate and the CA certificates.

The response is missing an easy way to relate every CRL or OCSP response to
every certificate of the chain.

In the security consideration section, it is mentioned that this service
need not be trusted. This is an interesting remark which may be used as an
additional argument to dissociate that service from an OCSP service, since
by definition all responses from an OCSP server are signed (unless there is
an error) and if the service is untrusted, then no signature is necessary.
So returning all that information, without a signature should be considered.

Remainder: As this has already been raised on the mailing list, the fact
that the server is defined as stateful is not appropriate. The parameter
"retryReference" should be deleted.

The structure of both the request and the response should be modified to
accommodate these requirements.

Denis




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18371 for <[e-mail]>; Wed, 4 Oct 2000 08:13:29 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA86976 for <[e-mail]>; Wed, 4 Oct 2000 17:22:36 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA05278 for <[e-mail]>; Wed, 4 Oct 2000 17:16:52 +0200
Message-ID: <[e-mail]>
Date: Wed, 04 Oct 2000 12:04:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocsp-valid-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments on the document on Delegated path validation

The validation has to be made against a set of rules which may be more
complex than validation against a single root key associated with
Certificate policy constraints and naming constraints. These constraints are
not necessarily embedded in a self-signed certificate. Multiple root keys
may be used in parallel. In addition, it may be important to use either CRLs
or ARLs only, or OCSP responses. This may even be different whether it is
for a leaf certificate or a CA certificate.

This set of rules may be called "validation policy" and is thus fully
distinct from a Certificate Policy (CP). The protocol should support as an
option the possibility to simply provide a single OID which will be the OID
of the validation policy.

As an alternative, when the rules are "simpler", it could be possible to
support a set of trust points with their constraints. 

For all these trust points, it should be possible to specify whether CRLs or
OCSP responses should be used for leaf certificates and whether ARLs or OCSP
responses should be used for CA certificates.

For every trust point, it should be possible to specify the self-signed
certificate and, if the Certificate Policy constraints and the naming
constrains are not included in it, to specify them separately.

The structure of both the request and the response should be modified to
accommodate these requirements.

Denis




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18186 for <[e-mail]>; Wed, 4 Oct 2000 08:12:39 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA76962; Wed, 4 Oct 2000 17:21:46 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA14710; Wed, 4 Oct 2000 17:16:01 +0200
Message-ID: <[e-mail]>
Date: Wed, 04 Oct 2000 17:16:00 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

It is a good catch. 

Effectively there used to be another field after which was:

keyUpdateWarning       (6)
         -- Otherwise, the Time Stamp Token is not present
     }

This field has been purposely deleted because it was not meaningful in a TSP
context, but only in a CMP context.

However the comma was still there. :-(

Thanks a lot. 

Denis

> > Peter,
> >
> > Sorry. The time for new comments/text improvements/ text
> > clarifications is now closed. We are only processing commments
> > received during the IESG last call period. Of course, if the comment
> > is purely editorial, e.g. a typo, we can still certainly take it.
> >
> > Regards,
> >
> > Denis
> >
> 
> The ASN.1 in the compilable module is not correct, there is
> a comma (,) which shouldn't be there.
> 
>          revocationNotification (5),
>           -- notification that a revocation has occurred


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05005 for <[e-mail]>; Wed, 4 Oct 2000 03:51:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14903; Wed, 4 Oct 2000 06:55:14 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-02.txt
Date: Wed, 04 Oct 2000 06:55:14 -0400
Sender: [e-mail]

--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		: Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-02.txt
	Pages		: 10
	Date		: 03-Oct-00
	
This document describes how to layer Certificate Management
Protocols [CMP] over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-02.txt

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-cmp-transport-protocols-02.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-cmp-transport-protocols-02.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-cmp-transport-protocols-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA18382 for <[e-mail]>; Wed, 4 Oct 2000 01:56:21 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA14590; Wed, 4 Oct 2000 11:00:14 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 4 Oct 2000 11:00:14 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA24072; Wed, 4 Oct 2000 11:00:17 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA26601; Wed, 4 Oct 2000 11:00:18 +0200 (MET DST)
Date: Wed, 4 Oct 2000 11:00:18 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail], [e-mail]

 
> Actually, I think the comma indicates that
> another line is missing that should follow
> this one.
> 

Right, in version 8 there was indeed a (6):

PKIStatus ::= INTEGER {
         granted                (0),
         -- When the Status contains the value zero a Time Stamp Token
         -- is present.
         grantedWithMods        (1),
         rejection              (2),
         waiting                (3),
         revocationWarning      (4),
         revocationNotification (5),
         keyUpdateWarning       (6)
         -- Otherwise, the Time Stamp Token is not present
     }

Fortunately some people keep older versions of the IETF drafts :-) 


Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06639 for <[e-mail]>; Tue, 3 Oct 2000 19:42:16 -0700 (PDT)
Received: from asn-1.com (user-2ivf1ot.dialup.mindspring.com [165.247.135.29]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id WAA24939; Tue, 3 Oct 2000 22:46:06 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 03 Oct 2000 22:48:35 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Actually, I think the comma indicates that
another line is missing that should follow
this one.


Peter Sylvester wrote:
> 
> > Peter,
> >
> > Sorry. The time for new comments/text improvements/ text
> > clarifications is now closed. We are only processing commments
> > received during the IESG last call period. Of course, if the comment
> > is purely editorial, e.g. a typo, we can still certainly take it.
> >
> > Regards,
> >
> > Denis
> >
> 
> The ASN.1 in the compilable module is not correct, there is
> a comma (,) which shouldn't be there.
> 
>          revocationNotification (5),
>           -- notification that a revocation has occurred

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17524 for <[e-mail]>; Tue, 3 Oct 2000 08:06:04 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id LAA01653 for <[e-mail]>; Tue, 3 Oct 2000 11:09:57 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 03 Oct 2000 11:08:24 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: FYI: AES announcement
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

FYI,

NIST announced the selection of the Rjindael algorithm as the Advanced 
Encryption Standard (AES) yesterday.  For more information, check out the 
NIST AES website at http://csrc.nist.gov/encryption/aes/.

Thanks,

Tim Polk



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13405 for <[e-mail]>; Tue, 3 Oct 2000 05:16:52 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA02977; Tue, 3 Oct 2000 14:20:42 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 3 Oct 2000 14:20:42 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA19857; Tue, 3 Oct 2000 14:20:43 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA26188; Tue, 3 Oct 2000 14:20:43 +0200 (MET DST)
Date: Tue, 3 Oct 2000 14:20:43 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail]

> Peter,
> 
> Sorry. The time for new comments/text improvements/ text
> clarifications is now closed. We are only processing commments
> received during the IESG last call period. Of course, if the comment
> is purely editorial, e.g. a typo, we can still certainly take it.
> 
> Regards,
> 
> Denis
> 

The ASN.1 in the compilable module is not correct, there is
a comma (,) which shouldn't be there. 

         revocationNotification (5),
          -- notification that a revocation has occurred