RE: TSA draft V7.0

[Michael Zolotarev <[e-mail]>]

I agree that it would be extremely difficult for a CA to evaluate a TSA's
practices before granting it a certificate with id-timestamping. It would be
even more difficult for me, as a client, to trust that assessment.

That is why is seems reasonable to expect that TSA would use self-signed
certificates, taking full responsibility over its practices and operations.

However, I reckon that this is largely outside of the scope of the
timestamping draft, really.

Regards
Michael

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, April 29, 2000 10:22 AM
> To: Carlisle Adams
> Cc: [e-mail]; 'Michael Zolotarev'; PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> 
> 
> Carlisle Adams <[e-mail]> on 04/28/2000 10:14:20 AM
> 
> To:   [e-mail], "'Michael Zolotarev'"
>       <[e-mail]>
> cc:   PKIX mailing group <[e-mail]>
> Subject:  RE: TSA draft V7.0
> 
> 
> 
> Hi Michael,
> 
> My interpretation is more along the following lines.  If a CA 
> explicitly
> puts an extension in a certificate designating the subject to be a TSA
> then, in some sense at least, the time stamp authority 
> function becomes a
> CA service.  Thus, I see no conflict with such use of the AIA 
> extension.
> 
> [Tom Gindin] I have a hard time with the idea that a service 
> becomes a CA
> service in any meaningful sense simply by having the CA issue 
> a certificate
> containing an ExtendedKeyUsage value.  A CA issuing a server 
> certificate is
> not vouching that the service will be properly performed, 
> much less that it
> will be performed on the CA's behalf.  How much verification of the
> features of a service by the CA occurs  when an operator gets a server
> certificate for a Web or LDAP server and asks for Extended Key Usage
> id-kp-serverAuth?  So how much more is required for 
> id-kp-timeStamping,
> which is the standard way in which the CA designates the 
> subject as a TSA?
> (snip)
> 
> 



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 SAA10188 for <[e-mail]>; Sun, 30 Apr 2000 18:10: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 LAA13834; Mon, 1 May 2000 11:20:26 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <J6GQ3BB3>; Mon, 1 May 2000 11:15:08 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail], Carlisle Adams <[e-mail]>
Cc: [e-mail], PKIX mailing group <[e-mail]>
Subject: RE: TSA draft V7.0
Date: Mon, 1 May 2000 11:14:59 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I agree that it would be extremely difficult for a CA to evaluate a TSA's
practices before granting it a certificate with id-timestamping. It would be
even more difficult for me, as a client, to trust that assessment.

That is why is seems reasonable to expect that TSA would use self-signed
certificates, taking full responsibility over its practices and operations.

However, I reckon that this is largely outside of the scope of the
timestamping draft, really.

Regards
Michael

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Saturday, April 29, 2000 10:22 AM
> To: Carlisle Adams
> Cc: [e-mail]; 'Michael Zolotarev'; PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> 
> 
> Carlisle Adams <[e-mail]> on 04/28/2000 10:14:20 AM
> 
> To:   [e-mail], "'Michael Zolotarev'"
>       <[e-mail]>
> cc:   PKIX mailing group <[e-mail]>
> Subject:  RE: TSA draft V7.0
> 
> 
> 
> Hi Michael,
> 
> My interpretation is more along the following lines.  If a CA 
> explicitly
> puts an extension in a certificate designating the subject to be a TSA
> then, in some sense at least, the time stamp authority 
> function becomes a
> CA service.  Thus, I see no conflict with such use of the AIA 
> extension.
> 
> [Tom Gindin] I have a hard time with the idea that a service 
> becomes a CA
> service in any meaningful sense simply by having the CA issue 
> a certificate
> containing an ExtendedKeyUsage value.  A CA issuing a server 
> certificate is
> not vouching that the service will be properly performed, 
> much less that it
> will be performed on the CA's behalf.  How much verification of the
> features of a service by the CA occurs  when an operator gets a server
> certificate for a Web or LDAP server and asks for Extended Key Usage
> id-kp-serverAuth?  So how much more is required for 
> id-kp-timeStamping,
> which is the standard way in which the CA designates the 
> subject as a TSA?
> (snip)
> 
> 


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 RAA07438 for <[e-mail]>; Sun, 30 Apr 2000 17:51:19 -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 LAA13605; Mon, 1 May 2000 11:01:04 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <J6GQ3BA5>; Mon, 1 May 2000 10:55:46 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Carlisle Adams <[e-mail]>, [e-mail]
Cc: PKIX mailing group <[e-mail]>
Subject: RE: TSA draft V7.0
Date: Mon, 1 May 2000 10:55:42 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Carlisle,

Let me explain my point once again:

The 2459 defines the AIA extension as containing information about the
ISSUER of a certificate. Be it a TSA, or any other certificate. Therefore,
the AIA extension in a TSA certificate is expected to provide details about
the CA that issued that certificate, but not about the TSA itself.

Assuming that a CA generates a certificate for TSA so that the AIA somehow
contains the TSA's details - how would you know if the extension really
contains information about issuing CA, or the TSA? The freedom if
interpretation would be dangerously confusing.


This is why it would be only reasonable to have the AIA in self-signed TSA
certificates.

Regards
Michael


> -----Original Message-----
> From: Carlisle Adams [mailto:[e-mail]]
> Sent: Saturday, April 29, 2000 12:14 AM
> To: [e-mail]; 'Michael Zolotarev'
> Cc: PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> Hi Michael,
> 
> My interpretation is more along the following lines.  If a CA 
> explicitly
> puts an extension in a certificate designating the subject to 
> be a TSA then,
> in some sense at least, the time stamp authority function becomes a CA
> service.  Thus, I see no conflict with such use of the AIA extension.
> 
> On the other hand, if a time stamper independently sets 
> itself up as a TSA,
> without any explicit "endorsement" from a CA, then this time 
> stamp authority
> function is not a CA service.  EEs will need to discover in 
> some other way
> that this is a TSA and will need to install the TSA public 
> key in a secure
> (out-of-band) fashion, independent of any contact with any 
> CA.  Use of AIA
> in this instance would indeed be contrary to the spirit of 
> RFC 2459, but
> that's not a problem since this instance is defined by the 
> assumption that
> AIA is not used.
> 
> So, I think the text is fine as-is, but I'd be interested in other
> opinions/interpretations on this.
> 
> Carlisle.
> 
> 
> > ----------
> > From: 	Michael Zolotarev[SMTP:[e-mail]]
> > Sent: 	Thursday, April 27, 2000 9:35 PM
> > To: 	[e-mail]
> > Cc: 	PKIX mailing group
> > Subject: 	TSA draft V7.0
> > 
> > Denis,
> >  
> > Something I've just noticed in the draft, which skipped my attention
> > before:
> >  
> > The TSA draft defines how the AIA extension can be used in the TSA
> > certificate. 
> > ***
> > A TSA's certificate MAY contain an Authority Information 
> Access extension
> > [RFC2459] in order to convey the method of contacting the TSA. The
> > accessMethod field in this extension MUST contain the OID
> > id-ad-timestamping:
> > ***
> >  
> > The definition actually contradicts to the 2459 profile which says:
> >  
> > ***
> > The authority information access extension indicates how to 
> access CA
> > information and services FOR THE ISSUER OF THE CERTIFICATE 
> in which the
> > extension appears. Information and services may include 
> on-line validation
> > services and CA policy data. 
> > ****
> > 
> > Note the "FOR THE ISSUER OF THE CERTIFICATE" bit.
> > 
> > The content of the AIA extension does not depend on who the 
> subject is. It
> > only depends on what information access services the CA has 
> to offer. In
> > other words, a CA would most probably use the same AIA for 
> a TSA cert and
> > for any other entity's certificate it generates .
> > 
> > The only possible situation I can think of when the 
> definition given by
> > the
> > TSA draft makes a tiny bit of sense is for self-signed TSA 
> certificates.
> > If
> > this is the case, the AIA would be presenting a set of 
> protocols that can
> > be
> > used to obtain timestamps. But then it must be clearly stated by the
> > document that only self-signed TSA certs can have that 
> information in the
> > AIA extension. Still, it contradicts to the spirit of the 
> 2459, which
> > defines the AIA as providing information about how to access the
> > certificate-issuing authority, but not the services offered 
> by the subject
> > of the certificate.
> > 
> > The current definition in the TSA draft goes back to the very early
> > version
> > of the draft. Probably, it is just me who is wrong, and 
> there is something
> > I
> > simply do not understand. Would like my concerns to be explained.
> > 
> > BTW, an alternative and in my opinion a better way of 
> specifying the set
> > of
> > URIs to obtain timestamps would probably be defining a proprietary
> > extension
> > in TSA certificates. TsaAccessDescription ::= SEQUENCE SIZE 
> (1..MAX) OF
> > GeneralName. Non-critical, with the id-ad-timestamping OID.
> > 
> > Best regards
> > 
> > M
> > 
> >  
> > 
> >  
> > 
> 


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 RAA07107 for <[e-mail]>; Sun, 30 Apr 2000 17:30:32 -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 KAA13465; Mon, 1 May 2000 10:40:24 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <J6GQ3BAD>; Mon, 1 May 2000 10:35:06 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: PKIX mailing group <[e-mail]>
Subject: RE: TSA draft V7. OIDs.
Date: Mon, 1 May 2000 10:34:55 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> > C1. The draft uses both id-ad-timeStamping and 
> id-pkix-ad-timestamping OIDs.
> > I'd prefer "pkix" to be preserved as part of the name.
> 
> They come from two different arcs (SMIME and PKIX).
> 

Denis, I've put the OIDs together below. To me they are identical :)

id-pkix-ad-timestamping  OBJECT IDENTIFIER ::= {id-pkix-ad 3}
id-pkix-ad               OBJECT IDENTIFIER ::= {id-pkix 48}
id-pkix                  OBJECT IDENTIFIER ::= {iso(1) 
                         identified-organization(3) dod(6) 
                         internet(1) security(5) mechanisms(5) pkix(7)}

id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1) 
                      identified-organization(3) dod(6) 
                      internet(1) security(5) mechanisms(5) pkix(7) 
                      ad (48) timestamping (3)}


M 


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 RAA06902 for <[e-mail]>; Sun, 30 Apr 2000 17:25:22 -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 KAA13381; Mon, 1 May 2000 10:34:55 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <J6GQ3A00>; Mon, 1 May 2000 10:29:37 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>, PKIX mailing group <[e-mail]>
Subject: RE: TSA draft V7. certReq field.
Date: Mon, 1 May 2000 10:29:27 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Ok.

Except is probably sounds a little better to say: "IN THIS CASE that field
may also
contain other certificates."

Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, April 28, 2000 8:39 PM
> To: Michael Zolotarev; PKIX mailing group
> Subject: Re: TSA draft V7
> 
> 
> Michael,
> 
> On the gfirst point I answered to quickly.
> 
> The idea is to return the relevant certificate in the certificates
> field from the SignedData structure.
> 
> Here after is the complete fix:
> 
> If the certReq field is present and set to true, the TSA's public
> key certificate that is referenced by the ESSCertID attribute in the 
> response must be provided by the TSA in the certificates field from 
> the SignedData structure in that response. That field may also
> contain 
> other certificates.
> 
> If the certReq field is missing, or if the certReq field is present
> and set to false then the certificates field from the SignedData 
> structure must not be present in the response.
> 
> Denis
> 
>  
> > > A few more remarks:
> > 
> > > The draft says:
> > 
> > > "If the certReq field is present and set to true, the 
> TSA's public key
> > > certificate that is referenced by the ESSCertID attribute 
> must be provided
> > > by the TSA in the Certificate Values attribute and 
> incorporated in the
> > > response. The certificate Values attribute may also contain other
> > > certificates.
> > > If the certReq field is missing, or if the certReq field 
> is present and set
> > > to false then no Certificate Values attribute shall be present."
> > 
> > > Q1. "Certificate Values attribute". What is it? Was it 
> meant to be the
> > > signedData::Certificates field?
> > 
> > You are right. It is "Signing Certificate" instead of "Certificate
> > Values". Good catch.
> > 
> > > Q2. If the certReq field is missing in the request, 
> should it be up to the
> > > TSA to decide whether to include the cert of not?
> > 
> > The text is pretty explicit on this. The TSA does not decide : No
> > certificate sahll be present.
> > 
> > > Q3. somehow it seems more reasonable to default the 
> certReq to TRUE. This
> > > way TSA would be well-behaving with no extra efforts.
> > 
> > The answer should be as short as possible in the general case. If
> > you really want the certificate back, then you have to ask for it.
> > 
> > > General comments:
> > >
> > > C1. The draft uses both id-ad-timeStamping and 
> id-pkix-ad-timestamping OIDs.
> > > I'd prefer "pkix" to be preserved as part of the name.
> > 
> > They come from two different arcs (SMIME and PKIX).
> > 
> > > C2. PKIXTSP is defined but never referenced.
> > 
> > The name is there so that *other* ASN 1 modules may reference it and
> > use what is exported.
> > 
> > Denis
> > 
> > >
> > > Regards
> > >
> > > M
> 


Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02785 for <[e-mail]>; Sun, 30 Apr 2000 08:22:51 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3]) by mail.inter.net.il (8.9.3/8.9.3) with SMTP id SAA08829 for <[e-mail]>; Sun, 30 Apr 2000 18:26:49 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1) id AA20789; Sun, 30 Apr 00 18:29:25 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com" via SMTP by radguard.com, id smtpdAAAa20787; Sun Apr 30 18:29:19 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id RAA20977; Sun, 30 Apr 2000 17:29:27 +0200 (IST)
Message-Id: <[e-mail]>
Date: Sun, 30 Apr 2000 18:29:59 +0300
From: Efrat Prag <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: [e-mail]
Subject: enrollment protocols
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I am looking into the subject of certificate enrollment protocols. From
what I've heard CEP is the most common one. However I haven't been able
to locate a draft/rfc of the protocol. I did find a draft on SCEP with
no reference to CEP. Are the two protocols related?
Can anyone point me to such a document?

Thanks,
Efrat



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 RAA22741 for <[e-mail]>; Fri, 28 Apr 2000 17:17:54 -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 UAA32984; Fri, 28 Apr 2000 20:21:17 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id UAA229954; Fri, 28 Apr 2000 20:22:35 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568D0.00020E48 ; Fri, 28 Apr 2000 20:22:27 -0400
X-Lotus-FromDomain: IBMUS
To: Carlisle Adams <[e-mail]>
cc: [e-mail], "'Michael Zolotarev'" <[e-mail]>, PKIX mailing group <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 20:22:21 -0400
Subject: RE: TSA draft V7.0
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Carlisle Adams <[e-mail]> on 04/28/2000 10:14:20 AM

To:   [e-mail], "'Michael Zolotarev'"
      <[e-mail]>
cc:   PKIX mailing group <[e-mail]>
Subject:  RE: TSA draft V7.0



Hi Michael,

My interpretation is more along the following lines.  If a CA explicitly
puts an extension in a certificate designating the subject to be a TSA
then, in some sense at least, the time stamp authority function becomes a
CA service.  Thus, I see no conflict with such use of the AIA extension.

[Tom Gindin] I have a hard time with the idea that a service becomes a CA
service in any meaningful sense simply by having the CA issue a certificate
containing an ExtendedKeyUsage value.  A CA issuing a server certificate is
not vouching that the service will be properly performed, much less that it
will be performed on the CA's behalf.  How much verification of the
features of a service by the CA occurs  when an operator gets a server
certificate for a Web or LDAP server and asks for Extended Key Usage
id-kp-serverAuth?  So how much more is required for id-kp-timeStamping,
which is the standard way in which the CA designates the subject as a TSA?
(snip)




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16278 for <[e-mail]>; Fri, 28 Apr 2000 08:04:05 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA14418; Fri, 28 Apr 2000 17:08:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 28 Apr 2000 17:08:03 +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 RAA27558; Fri, 28 Apr 2000 17:08:01 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA14276; Fri, 28 Apr 2000 17:08:01 +0200 (MET DST)
Date: Fri, 28 Apr 2000 17:08:01 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: TSA draft V7.0
Cc: [e-mail]

> 
> So, I think the text is fine as-is, but I'd be interested in other
> opinions/interpretations on this.

I would like to know how the two type of access information that had
been in earlier drafts of X.509 were lost. 

The AIA tells you something about the issuer, and there were two others
that concerned End entity information access and CA information access.
(both seem to be identical with the only difference that the subject
is a EE or a CA.) 

I had asked this question a year ago I guess.


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16019 for <[e-mail]>; Fri, 28 Apr 2000 07:58:17 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA14318; Fri, 28 Apr 2000 17:03:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 28 Apr 2000 17:03:11 +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 RAA27510; Fri, 28 Apr 2000 17:03:10 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA14269; Fri, 28 Apr 2000 17:03:10 +0200 (MET DST)
Date: Fri, 28 Apr 2000 17:03:10 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: time-stamp-draft-7
Cc: [e-mail]

> 
> I suggest changing the tagging to:
> 
> TSTInfo ::= SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
> 

Another way is to change the order of some precding element. Idoubt that
one of the choices of GeneralName will ever become a sequence directly.

TSTInfo ::= SEQUENCE  {
     version                      Integer  { v1(1) },
     policy                       PolicyInformation,
     messageImprint               MessageImprint,
       -- MUST have the same value as the similar field in 
       -- TimeStampReq
     genTime                      GeneralizedTime,
     accuracy                     Accuracy             OPTIONAL,
     serialNumber                 Integer,
     nonce                        Integer              OPTIONAL,
       -- MUST be present if the similar field was present 
       -- in TimeStampReq. In that case it must have the same value.
     tsa                          GeneralName          OPTIONAL,

     extensions                   Extensions       OPTIONAL
}

And in order to follow the 'MIMIMAL' tagging I suggest the following

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(1) },
     messageImprint               MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy                PolicyInformation      OPTIONAL,
     nonce                    Integer                OPTIONAL,
     certReq                  BOOLEAN                DEFAULT FALSE,
     extensions               [0] IMPLICIT Extensions OPTIONAL
}

in order to get minimal tagging and to avoid any possible conflict
when some interpretes it a EXPLICIT.  



Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15705 for <[e-mail]>; Fri, 28 Apr 2000 07:47:14 -0700 (PDT)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <QAA26904> (multiple receipients); Fri, 28 Apr 2000 16:52:12 +0200 (MET DST)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id QAA13640; Fri, 28 Apr 2000 16:51:43 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 17:00:20 +0200
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: time-stamp-draft-7
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

It would work, but who knows in which way GeneralName will be changed in
future. To add one more tag seems to be cleaner. Another "dirty" change would
be to tag Extensions with [1]. Since In GeneralName the tag [1] is used for a
primitive type (IA5String) the encoding differs from the encoding of the
Extensions tag. I'd rather add another tag.

Jörg
--
timeproof                               phone  [phone]
Development                             fax    [phone]
Harburger Schloßstraße 6-12             mailto:[e-mail]
D-21079 Hamburg                         http://www.timeproof.de

[e-mail] schrieb:
> 
>      It is equally safe to give extensions a high tag and leave GeneralName
> untagged, e.g. TSTInfo ::= SEQUENCE
> {         [...]
>       tsa                   GeneralName          OPTIONAL,
>       extensions            [30] IMPLICIT Extensions OPTIONAL
> }
> 
>      Wouldn't this be better than throwing in extra tags?  Tag numbers
> above 30 should be avoided whenever possible, of course, because they are
> multi-byte tags.  Of course, since Accuracy is an optional sequence,
> leaving extensions untagged doesn't work.


Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15030 for <[e-mail]>; Fri, 28 Apr 2000 07:18:41 -0700 (PDT)
Received: from darxstar ([62.252.196.47]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000428142339.JKR381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Fri, 28 Apr 2000 15:23:39 +0100
Message-ID: <000701bfb11d$c312cb60$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: What do you put in crlEntryDetails?
Date: Fri, 28 Apr 2000 15:25:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

The RevDetails structure has a field called "crlEntryDetails" which takes
certificate extensions.  I have written code to access this field but for
the world of me I cannot think what somebody would use it for.  Can anybody
give me an examples of certificate extensions that one might stick in
crlEntryDetails?

Cheers,

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.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 HAA14782 for <[e-mail]>; Fri, 28 Apr 2000 07:09:57 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <20Y5FBXD>; Fri, 28 Apr 2000 10:14:21 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: [e-mail], "'Michael Zolotarev'" <[e-mail]>
Cc: PKIX mailing group <[e-mail]>
Subject: RE: TSA draft V7.0
Date: Fri, 28 Apr 2000 10:14:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Michael,

My interpretation is more along the following lines.  If a CA explicitly
puts an extension in a certificate designating the subject to be a TSA then,
in some sense at least, the time stamp authority function becomes a CA
service.  Thus, I see no conflict with such use of the AIA extension.

On the other hand, if a time stamper independently sets itself up as a TSA,
without any explicit "endorsement" from a CA, then this time stamp authority
function is not a CA service.  EEs will need to discover in some other way
that this is a TSA and will need to install the TSA public key in a secure
(out-of-band) fashion, independent of any contact with any CA.  Use of AIA
in this instance would indeed be contrary to the spirit of RFC 2459, but
that's not a problem since this instance is defined by the assumption that
AIA is not used.

So, I think the text is fine as-is, but I'd be interested in other
opinions/interpretations on this.

Carlisle.


> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Sent: 	Thursday, April 27, 2000 9:35 PM
> To: 	[e-mail]
> Cc: 	PKIX mailing group
> Subject: 	TSA draft V7.0
> 
> Denis,
>  
> Something I've just noticed in the draft, which skipped my attention
> before:
>  
> The TSA draft defines how the AIA extension can be used in the TSA
> certificate. 
> ***
> A TSA's certificate MAY contain an Authority Information Access extension
> [RFC2459] in order to convey the method of contacting the TSA. The
> accessMethod field in this extension MUST contain the OID
> id-ad-timestamping:
> ***
>  
> The definition actually contradicts to the 2459 profile which says:
>  
> ***
> The authority information access extension indicates how to access CA
> information and services FOR THE ISSUER OF THE CERTIFICATE in which the
> extension appears. Information and services may include on-line validation
> services and CA policy data. 
> ****
> 
> Note the "FOR THE ISSUER OF THE CERTIFICATE" bit.
> 
> The content of the AIA extension does not depend on who the subject is. It
> only depends on what information access services the CA has to offer. In
> other words, a CA would most probably use the same AIA for a TSA cert and
> for any other entity's certificate it generates .
> 
> The only possible situation I can think of when the definition given by
> the
> TSA draft makes a tiny bit of sense is for self-signed TSA certificates.
> If
> this is the case, the AIA would be presenting a set of protocols that can
> be
> used to obtain timestamps. But then it must be clearly stated by the
> document that only self-signed TSA certs can have that information in the
> AIA extension. Still, it contradicts to the spirit of the 2459, which
> defines the AIA as providing information about how to access the
> certificate-issuing authority, but not the services offered by the subject
> of the certificate.
> 
> The current definition in the TSA draft goes back to the very early
> version
> of the draft. Probably, it is just me who is wrong, and there is something
> I
> simply do not understand. Would like my concerns to be explained.
> 
> BTW, an alternative and in my opinion a better way of specifying the set
> of
> URIs to obtain timestamps would probably be defining a proprietary
> extension
> in TSA certificates. TsaAccessDescription ::= SEQUENCE SIZE (1..MAX) OF
> GeneralName. Non-critical, with the id-ad-timestamping OID.
> 
> Best regards
> 
> M
> 
>  
> 
>  
> 


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 GAA14429 for <[e-mail]>; Fri, 28 Apr 2000 06:45:49 -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 JAA253018; Fri, 28 Apr 2000 09:49:03 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id JAA12336; Fri, 28 Apr 2000 09:50:37 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568CF.004C0AAA ; Fri, 28 Apr 2000 09:50:34 -0400
X-Lotus-FromDomain: IBMUS
To: Denis Pinkas <[e-mail]>
cc: Joerg Seidel <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 09:50:28 -0400
Subject: Re: time-stamp-draft-7
Mime-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk";  X-Lotus-Encap=encap3

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

     It is equally safe to give extensions a high tag and leave General=
Name
untagged, e.g. TSTInfo ::=3D SEQUENCE
{         [...]
      tsa                   GeneralName          OPTIONAL,
      extensions            [30] IMPLICIT Extensions OPTIONAL
}

     Wouldn't this be better than throwing in extra tags?  Tag numbers
above 30 should be avoided whenever possible, of course, because they a=
re
multi-byte tags.  Of course, since Accuracy is an optional sequence,
leaving extensions untagged doesn't work.

          Tom Gindin


Denis Pinkas <[e-mail]> on 04/28/2000 06:10:29 AM

To:   Joerg Seidel <[e-mail]>
cc:   [e-mail]
Subject:  Re: time-stamp-draft-7



Joerg,

Thanks for your careful writing. We came form a maximum tagging
version (which was safe) to a minimum one. It is hard to do minimal
tagging by thinking to all the various combinations.

You are right. Thanks for providing a change proposal.

Denis

> Denis,
>
> maybe the TSTInfo structure has some inconvenience because of the mis=
sing
tags
> now:
>
> time-stamp-draft-7: IMPLIZIT tagging
>
> TSTInfo ::=3D SEQUENCE  {
>         [...]
>      tsa                          GeneralName          OPTIONAL,
>      extensions                   [0] Extensions       OPTIONAL
> }
>
> X.509 IMPLIZIT: Tagging:
>
>       GeneralName ::=3D CHOICE {
>            otherName                       [0]     OtherName,
>            rfc822Name                      [1]     IA5String,
>            dNSName                         [2]     IA5String,
>            x400Address                     [3]     ORAddress,
>            directoryName                   [4]     Name,
>            ediPartyName                    [5]     EDIPartyName,
>            uniformResourceIdentifier       [6]     IA5String,
>            iPAddress                       [7]     OCTET STRING,
>            registeredID                    [8]     OBJECT IDENTIFIER}=

>
>       OtherName ::=3D SEQUENCE {
>            type-id    OBJECT IDENTIFIER,
>            value      [0] EXPLICIT ANY DEFINED BY type-id }
>
>    Extensions  ::=3D  SEQUENCE SIZE (1..MAX) OF Extension
>
> The parser can't ditinguish between the "GeneralName" field and "[0]
> Extensions" in case that the GeneralName choice is "[0] OtherName". S=
ince
both
> OtherName and Extensions are sequences the tag will be encoded
identically and
> can't be used to distinguish the two optional entries. They could onl=
y
> distinguished by checking the tag of the content of the sequence. Tha=
t
isn't
> very convinient for implementations.
>
> I suggest changing the tagging to:
>
> TSTInfo ::=3D SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
>
> Jorg
>
> --
> timeproof                               phone  [phone]
> Development                             fax    [phone]
> Harburger Schlo=DFstra=DFe 6-12             mailto:seidel@timeproof.d=
e
> D-21079 Hamburg                         http://www.timeproof.de

=

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk
Content-type: application/X-Lotus-Encap2; 
	name="encap2.ond"
Content-transfer-encoding: base64

GgAAAwAAEQABABgLTADPaCWFAAAAwAAAHgEAAPcHAAAAAEgLTADPaCWFCv8BAgAIAACAQwMAoLMA
CAAAAQAAXAMA+iAAAP4gAAD8BwAgAEAAAkAAAEAAAACAAwAAAAAAAAAAAAYAAAAHAAAAAwAAABEA
AAAFAAAAAAAAAAAAAAAAAwAAAAQAAEcLTADPaCWFAAAAAAAAAAAAAAAAAGgBAAAAAAAAAAAAAAAB
gEULTADPaCWFGAtMAM9oJYUAAAAAAAAAAAAAAABFbmNhcHN1bGF0ZWQgTm90ZSAvbm90ZXNkYXRh
L210YXRlbXAvRU5DQVAyLlRNUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAGAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABHC0wAz2glhQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAEAAQABAAAAAAAAAAAAAPogAACqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoAvAAA
AABICgAASAoAAAAAAAAAAKqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA
AOAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAP8AAAAA
AAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+P//////////////////////
//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8AAAAAAAA
AAAAAAAAAAAAAP//////////////////////////////////////////////////////////////
/////////////////////////wcA1gAAAAEA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
3voPAAAgACABAAAAAQAAAAQADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAPu7u4AAAAAAAAAAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAABAAAAAwAAAAA4gAAAAQBAAAmAQAASAEAqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoBAAAAHAAKAQAA
AAAAAAAAAABDTj1ENTFNVEEwNC9PVT0wMS9PVT1HL089SUJNqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqBgoAAAAABgEAAAC+AAAAAAAAQHABAMByAQAAdQEAQHcBAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//+qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qgAAAP8AIAAAAAAAAAAAAACvHgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoBAAD/ACAAAAAAAAAAAAAA
rx4BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqAgAA/wAgAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqgMAAP8AIMQfAAABAAEAAAAD7gEfEAAgAN8AAQAAAAAA8B8BAAAAAAAAAAAAAAAAAAIA
AAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQACgAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALgAAvwAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoCAqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqBABmAgAA
DgEAAJl3NIq7Yg3mYnxdALVkJYULAAAAA7NiALxlJYUAAASAOwtMAM9oJYUlAAAAAAAAsAEAzWIA
ADYLTADPaCWFAAAIACgAAAABAAkAqQEAAAIACQAIAAAAAwAJAAgAAAAEAAkACAAAAAUACQAIAAAA
BgANABgAAAAHAAkAGAAAAAgACQCwAAAACQAMAAEAAAAKAAkA+AAAAAsACQC1AgAADAAJAAUAAAAN
AAkA/AUAAA4ACQC2CwAADwAAAQIAAAAQAAABAgAAABEAAAECAAAAEgAAAQIAAAATAAABAgAAABQA
AAECAAAAFQAAAQIAAAAWAAABAgAAABcAAAECAAAAGAAAAQIAAAAZAAABAgAAABoACQAgGgAAGwAJ
AM4aAAAcAAkA7gUAAB0ACQD2BQAAHgAJAO4FAAAfAAwAIAAAACAATABMAAAAIQAMACAAAAAiAAwA
IAAAACMADAAxAAAAJAAKANoDAAADAAQACAAEAE1lbW9Eb2N1bWVudE1lbW93NDBGRTEyMDA4OEZE
NTUwMDY0RkYxMjAwRTMxMDQwMDACABUAMQBDTj1SeWFuIEphbnNlbi9PPUlyaXNDTj1Mb3R1cyBO
b3RlcyBUZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzNDBGRTEyMDA4OEZENTUwMDY0
RkYxMjAwRTMxMDQwMDA0MEZFMTIwMDg4RkQ1NTAwNjRGRjEyMDBFMzEwNDAwMENOPUxvdHVzIE5v
dGVzIFRlbXBsYXRlIERldmVsb3BtZW50L089TG90dXMgTm90ZXMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIwQABwIAABIBAABLO2uG9LErIEKxEgC1ZCWFBwAAANCxYgC8ZSWFAEAAAj4LTADPaCWF
BwAAAAAAABMCABBfAAA9C0wAz2glhSAATABxAQAAJQAJAIMxAAAmAAkAUCoAAAYABQARAAAACQAN
AAQAAAAnAA0AAQAAACQACgA9AwAACwAxABkACQAZADEAGQAxABkAEwAVADEAQ049TG90dXMgTm90
ZXMgVGVtcGxhdGUgRGV2ZWxvcG1lbnQvTz1Mb3R1cyBOb3Rlc0NOPUNhdGhlcmluZSBEdWZmeS9P
PUlyaXNNYXJ5IExhbWJDTj1DYXRoZXJpbmUgRHVmZnkvTz1JcmlzQ049TG90dXMgTm90ZXMgVGVt
cGxhdGUgRGV2ZWxvcG1lbnQvTz1Mb3R1cyBOb3Rlc0NOPUNhdGhlcmluZSBEdWZmeS9PPUlyaXND
Tj1Mb3R1cyBOb3RlcyBUZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzQ049Q2F0aGVy
aW5lIER1ZmZ5L089SXJpc0NOPURvbiBIYXRjaC9PPUlyaXNDTj1SeWFuIEphbnNlbi9PPUlyaXND
Tj1Mb3R1cyBOb3RlcyBUZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzAAVFbWFpbFBy
b2Nlc3NpbmdzMzRRMSMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIwQAPQIAABYBAACsel65JEqIJ0WxEgC1ZCWFDAAAABSyYgC8ZSWFAEAAAkAL
TADPaCWFBwAAAAAAQHICAJNSAAA/C0wAz2glhSAATACnAQAAJQAJAH0SAAAmAAkA2TwAAAYABQAR
AAAACQANAAQAAAAnAA0AAQAAACQACgA9AwAADQAxABUAGQAVADEAFQAZABUAMQAVABcAFQAxAENO
PUxvdHVzIE5vdGVzIFRlbXBsYXRlIERldmVsb3BtZW50L089TG90dXMgTm90ZXNDTj1SeWFuIEph
bnNlbi9PPUlyaXNDTj1DYXRoZXJpbmUgRHVmZnkvTz1JcmlzQ049UnlhbiBKYW5zZW4vTz1Jcmlz
Q049TG90dXMgTm90ZXMgVGVtcGxhdGUgRGV2ZWxvcG1lbnQvTz1Mb3R1cyBOb3Rlc0NOPVJ5YW4g
SmFuc2VuL089SXJpc0NOPUNhdGhlcmluZSBEdWZmeS9PPUlyaXNDTj1SeWFuIEphbnNlbi9PPUly
aXNDTj1Mb3R1cyBOb3RlcyBUZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzQ049Unlh
biBKYW5zZW4vTz1JcmlzQ049SGFycnkgUGVlYmxlcy9PPUlyaXNDTj1SeWFuIEphbnNlbi9PPUly
aXNDTj1Mb3R1cyBOb3RlcyBUZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzAAVPYmpl
Y3RWYXJpYWJsZXNzMzRRMSMjIwQA5gAAABoBAACiXw3z1YEtbU7kbgDAZCWFBwAAALuxYgC8ZSWF
AEAAAkULTADPaCWFBwAAAAAAAMUCAER+AABDC0wAz2glhSAATABMAAAAJQAJAOM+AAAmAAkAJDwA
AAYABQAVAAAACQANAAQAAAAnAA0AAQAAACQACgA9AwAAAgAVADEAQ049UnlhbiBKYW5zZW4vTz1J
cmlzQ049TG90dXMgTm90ZXMgVGVtcGxhdGUgRGV2ZWxvcG1lbnQvTz1Mb3R1cyBOb3RlcwAFRG9j
dW1lbnRDb252ZXJzaW9uc3MzNFExIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMEAGMEAAD6IAAA
cd3qwEsTgZAyC0wAz2glhQEAAABEC0wAz2glhQAAAQBHC0wAz2glhSkAAAAAAIBLAwDODgAARgtM
AM9oJYUoAAwAIQAAACkADAAEAAAAKgAMABIAAAArAAwABQAAACwADAAJAAAALQBMADYAAAAuAEwA
BAAAAC8ATAAoAAAAMABMAAQAAAAQAAwABAAAABEADAAFAAAAEgAMAAUAAAATAAwABQAAADEADAAI
AAAAMgAMAB8AAAAzAAwABQAAADQADAAEAAAAGQALAGwOAAA1AAwABQAAADYADAAMAAAANwAMAAwA
AAA4AAwADQAAABQADAAEAAAAOQAMACEAAAA6AAwADAAAABgADQAaAAAAOwAMAAQAAAAVAE0AKAAA
ABYATQA2AAAAFwBMAAQAAAAPAE0AIQAAADwADAAMAAAAPQAMADkAAAA+AAwABQAAAD8ACAA+AAAA
QAAIACQAAABBAAwAEgAAACAATABdAAAAQgAMAAwAAABDAAwAEgAAAEQADAASAAAAAQAdAENOPVRv
bSBHaW5kaW4vT1U9V2F0c29uL089SUJNAQAAAAEAsDMGq/CneTqECzgAz2glhQEAAQBCAQAFAFJl
cGx5AgAfABEASm9lcmcgU2VpZGVsIDxzZWlkZWxAbWF6LWhoLmRlPmlldGYtcGtpeEBpbWMub3Jn
AQAAAAEAJABEZW5pcyBQaW5rYXMgPERlbmlzLlBpbmthc0BidWxsLm5ldD4BAAAAAQAAAAEAAQAw
AQABADABAAEAMQEABABNZW1vAQAbAFRvbSBHaW5kaW4vV2F0c29uL0lCTUBJQk1VUwEAAQAyAQAA
AAEAAQAwAQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAQAJAEJvZHksQm9keQEAAAABAB0AQ049VG9t
IEdpbmRpbi9PVT1XYXRzb24vTz1JQk0BAAAAAAAAAAAAAAABABYAUmU6IHRpbWUtc3RhbXAtZHJh
ZnQtNwEAAAABACQARGVuaXMgUGlua2FzIDxEZW5pcy5QaW5rYXNAYnVsbC5uZXQ+AgAfABEASm9l
cmcgU2VpZGVsIDxzZWlkZWxAbWF6LWhoLmRlPmlldGYtcGtpeEBpbWMub3JnAQAAAAEAHQBDTj1U
b20gR2luZGluL09VPVdhdHNvbi9PPUlCTQEAAAAjCEwAz2glhQEANQA8T0ZDNEQyRUNCMC44OTk3
NDA0Qi1PTjg1MjU2OENGLjAwNEI0NDRDQExvY2FsRG9tYWluPgEAAQAwAQBLQJeJsOzSxExESwDP
aCWFAwAdABwAHABDTj1Ub20gR2luZGluL09VPVdhdHNvbi9PPUlCTUNOPUQwMk1MMjM3L09VPTAy
L09VPU0vTz1JQk1DTj1ENTFNVEEwNC9PVT0wMS9PVT1HL089SUJNAQAAAAAAAAAAADhASUJNVVMg
QCB1cy5pYm0uY29tdGdpbmRpbkB1cy5pYm0uY29tIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMDAEAzAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjAwAAMwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwMAwDIAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAyAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAMgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAADIAACMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAxAAAjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAMQAA
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IwMAQDEAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMDAAAxAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjAwDAMAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgDAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAwAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAMAAAIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwC8AACMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAvAAAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
AwBALwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIwMAAC8AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMDAMAuAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCALgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQC4AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAuAAAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDALQAAIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgC0AACMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMD
AEAtAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjAwAALQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIwMAwCwAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAsAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBALAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAACwAACMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMArAAAjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAKwAAIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMA
QCsAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMDAAArAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjAwDAKgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIwMAgCoAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAqAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAKgAAIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwCkAACMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIApAAAjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBA
KQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIwMAACkAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMDAMAoAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjAwCAKAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQCgAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAoAAAjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAJwAAIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgCcAACMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAn
AAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjAwAAJwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIwMAwCYAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMDAIAmAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAJgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAACYAACMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAlAAAjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAJQAAIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQCUA
ACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMDAAAlAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjAwDAJAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwMAgCQAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAkAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAJAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwCMAACMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAjAAAjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAIwAA
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IwMAACMAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMDAMAiAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjAwCAIgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQCIAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAiAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAIQAAIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgCEAACMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAhAAAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
AwAAIQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIwMAwCAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMDAIAgAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAIAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAACAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAfAAAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAHwAAIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQB8AACMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMD
AAAfAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjAwDAHgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIwMAgB4AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAeAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAHgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwB0AACMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAdAAAjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAHQAAIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMA
AB0AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMDAMAcAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjAwCAHAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIwMAQBwAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAcAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAGwAAIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgBsAACMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAbAAAjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAA
GwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIwMAwBoAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMDAIAaAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjAwBAGgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAABoAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAZAAAjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAGQAAIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQBkAACMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAZ
AAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjAwDAGAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIwMAgBgAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMDAEAYAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAGAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwBcAACMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAXAAAjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAFwAAIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAABcA
ACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMDAMAWAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjAwCAFgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwMAQBYAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAWAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAFQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgBUAACMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAVAAAjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAFQAA
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IwMAwBQAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMDAIAUAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjAwBAFAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAABQAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMATAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAEwAAIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQBMAACMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAATAAAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
AwDAEgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIwMAgBIAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMDAEASAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAEgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwBEAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIARAAAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAEQAAIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAABEAACMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMD
AMAQAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjAwCAEAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIwMAQBAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAQAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDADwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgA8AACMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAPAAAjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAADwAAIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMA
wA4AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMDAIAOAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjAwBADgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIwMAAA4AACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMANAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCADQAAIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQA0AACMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAANAAAjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDA
DAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIwMAgAwAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMDAEAMAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjAwAADAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwAsAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIALAAAjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBACwAAIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAAAsAACMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAK
AAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjAwCACgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIwMAQAoAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMDAAAKAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDACQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgAkAACMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEAJAAAjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAACQAAIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwAgA
ACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMDAIAIAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjAwBACAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIwMAAAgAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAHAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCABwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQAcAACMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAAHAAAjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDABgAA
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IwMAgAYAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMDAEAGAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjAwAABgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwAUAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAIAFAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBABQAAIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAAAUAACMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAMAEAAAj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
AwCABAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIwMAQAQAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMDAAAEAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAAwAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAgAMAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAEADAAAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwAAAwAAIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAwAIAACMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMD
AIACAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjAwBAAgAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIwMAAAIAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMDAMABAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwCAAQAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQAEAACMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMDAAABAAAjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwDAAAAAIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMA
gAAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMDAEAAAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMji/8oAAEABRJUaW1lcyBOZXcgUm9tYW4AAAAAAAAAAAAAAAAAAAAAAAGoAQgA
NAABAAoAVmVyc2lvbk9wdHwBAQABADYACwKvABQACgAqAMIBrgAKACsArgAEALUDAwAHABAACgAJ
NlM3UzlTMTRTAwAaAAsAJFZlcnNpb25PcHQAAQABADYAAwAHABAACQAJMFIxUzJTM1MAAwAYAAkA
U2F2ZWRPbmNlAAEAAQAwAAMABwAQAAkACTBSMVMyUzNTAAMAFAAKAFBvc3RlZERhdGUoAAMABwAQ
AAkACTBSMVMyUzNTAAMAGAANAERlbGl2ZXJlZERhdGUAKAADAAcAEAAJAAkwUjFTMlMzUwADABwA
DQAkQXV0b0VkaXRNb2RlAAEAAQAxAAMABwAQAAkACTBSMVMyUzNTAAMAYAAPAE1haWxTYXZlT3B0
aW9ucwDaAAAAAAAAAAAAAAAKAq8AOAAMAAEAAQAwAK4ALADaAAAAAAAAAAAA8D8KAq8AGgAMAAEA
AQAxAK4ADgABAAEAMwCuAAQAtQUDAAcAEAAJAAkwUjFTMlMzUwAAABwAAQAKAFZlcnNpb25PcHQB
AAEAMAB8AgMABwAMAAUACTBSNFMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGGAEA
ggAAAAAAAAABAAAAAAAAAAAAAACwAAAAhACJAK8AegASAAEACABOZXcgTWVtb64AaAAFAAcAU3Vi
amVjdABoAQUABwBTdWJqZWN0AAEAAAALAhwCrwA8ADAAcgCvABgADAABAAIAryCuAAwAAQAAAK4A
BAC1AwUABwBTdWJqZWN0ACICrgAMAGkAVgGuAAQAtQOuAAQAtQMDAAcAKgAjAAk0UzZTMTJTMTNT
MTRTMTVTMTdTMjFTMjNTMjVTMjZTMjhTACcrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmly
b25tZW50OjI6NTooT3B0aW9ucyk6MDo3NApPcHRpb24gUHVibGljClVzZSAiRW1haWxQcm9jZXNz
aW5nIgpVc2UgIkRvY3VtZW50Q29udmVyc2lvbnMiCgoKCgoKCicrK0xvdHVzU2NyaXB0IERldmVs
b3BtZW50IEVudmlyb25tZW50OjI6NTooRm9yd2FyZCk6MDoxCgonKytMb3R1c1NjcmlwdCBEZXZl
bG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KERlY2xhcmF0aW9ucyk6MDoyCgoAAQAsAUxTT0IDABQA
ZW4AAAQAAgAVAAAAAAAsACgBAAAAABgAAAAAAAAAAAAkAP//AAA4AP////9UAFQAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMALAEAAAAAGAAIACoAMgAyAEIANgA2AEYAMAAAAJIBbAADAE4ARQBXAAAAgAAGAEQA
RQBMAEUAVABFAAAALMT//woASQBOAEkAVABJAEEATABJAFoARQAAAAAy//8JAFQARQBSAE0ASQBO
AEEAVABFAAAAiAAGAE8AQgBKAEUAQwBUAAAAphrQAAAAAAD0FawADwBFAG0AYQBpAGwAUAByAG8A
YwBlAHMAcwBpAG4AZwAAAP//DwBFAE0AQQBJAEwAUABSAE8AQwBFAFMAUwBJAE4ARwAAAPwAEwBE
AG8AYwB1AG0AZQBuAHQAQwBvAG4AdgBlAHIAcwBpAG8AbgBzAAAA//8TAEQATwBDAFUATQBFAE4A
VABDAE8ATgBWAEUAUgBTAEkATwBOAFMAAAAFADAAAAAAAKfGZ70YAAAAAACwAIB6KAMAAAAAAAAA
ABgAAAAEAAABwC+UAwAAAAAAAAAABAAZAAAAAAA6AAAaAwDSjAA6AAAaBADS1AAdAAACAAAAIE1l
bW8nKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KE9wdGlvbnMpOjA6
NjYKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6NTooRm9yd2FyZCk6
MDoxCkRlY2xhcmUgU3ViIFF1ZXJ5c2F2ZShTb3VyY2UgQXMgTm90ZXN1aWRvY3VtZW50LCBDb250
aW51ZSBBcyBWYXJpYW50KQpEZWNsYXJlIFN1YiBRdWVyeWNsb3NlKFNvdXJjZSBBcyBOb3Rlc3Vp
ZG9jdW1lbnQsIENvbnRpbnVlIEFzIFZhcmlhbnQpCkRlY2xhcmUgU3ViIFBvc3Rtb2RlY2hhbmdl
KFNvdXJjZSBBcyBOb3Rlc3VpZG9jdW1lbnQpCkRlY2xhcmUgU3ViIFBvc3RvcGVuKFNvdXJjZSBB
cyBOb3Rlc3VpZG9jdW1lbnQpCgonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVu
dDoyOjU6KERlY2xhcmF0aW9ucyk6MDoyCgonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZp
cm9ubWVudDoyOjI6QmluZEV2ZW50czoxOjEyOQpQcml2YXRlIFN1YiBCaW5kRXZlbnRzKEJ5dmFs
IE9iamVjdG5hbWVfIEFzIFN0cmluZykKICAgICBTdGF0aWMgU291cmNlIEFzIE5PVEVTVUlET0NV
TUVOVAogICAgIFNldCBTb3VyY2UgPSBCaW5kKE9iamVjdG5hbWVfKQogICAgIE9uIEV2ZW50IFF1
ZXJ5c2F2ZSBGcm9tIFNvdXJjZSBDYWxsIFF1ZXJ5c2F2ZQogICAgIE9uIEV2ZW50IFF1ZXJ5Y2xv
c2UgRnJvbSBTb3VyY2UgQ2FsbCBRdWVyeWNsb3NlCiAgICAgT24gRXZlbnQgUG9zdG1vZGVjaGFu
Z2UgRnJvbSBTb3VyY2UgQ2FsbCBQb3N0bW9kZWNoYW5nZQogICAgIE9uIEV2ZW50IFBvc3RvcGVu
IEZyb20gU291cmNlIENhbGwgUG9zdG9wZW4KRW5kIFN1YgoKJysrTG90dXNTY3JpcHQgRGV2ZWxv
cG1lbnQgRW52aXJvbm1lbnQ6MjoyOlF1ZXJ5c2F2ZToxOjEyClN1YiBRdWVyeXNhdmUoU291cmNl
IEFzIE5vdGVzdWlkb2N1bWVudCwgQ29udGludWUgQXMgVmFyaWFudCkKICAgICAKICAgICBDYWxs
IEVtYWlsU2F2ZShDb250aW51ZSkKICAgICAKRW5kIFN1YgonKytMb3R1c1NjcmlwdCBEZXZlbG9w
bWVudCBFbnZpcm9ubWVudDoyOjI6UXVlcnljbG9zZToxOjEyClN1YiBRdWVyeWNsb3NlKFNvdXJj
ZSBBcyBOb3Rlc3VpZG9jdW1lbnQsIENvbnRpbnVlIEFzIFZhcmlhbnQpCiAgICAgCiAgICAgQ2Fs
bCBFbWFpbENsb3NlKENvbnRpbnVlKQogICAgIApFbmQgU3ViCicrK0xvdHVzU2NyaXB0IERldmVs
b3BtZW50IEVudmlyb25tZW50OjI6MjpQb3N0bW9kZWNoYW5nZToxOjEyClN1YiBQb3N0bW9kZWNo
YW5nZShTb3VyY2UgQXMgTm90ZXN1aWRvY3VtZW50KQogICAgIAogICAgIENhbGwgRW1haWxNb2Rl
Q2hhbmdlCiAgICAgCkVuZCBTdWIKJysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1l
bnQ6MjoyOlBvc3RvcGVuOjE6MTIKU3ViIFBvc3RvcGVuKFNvdXJjZSBBcyBOb3Rlc3VpZG9jdW1l
bnQpCiAgICAgCiAgICAgU2V0IHdzID0gTmV3IE5vdGVzVUlXb3JrU3BhY2UKICAgICBTZXQgdWlk
b2MgPSBzb3VyY2UKICAgICAKICAgICBDYWxsIEVtYWlsT3BlbgogICAgIApFbmQgU3ViAAEALAFM
U09CAwAUAGVuAAAEAB4AkgAEAAAAAAfYAgAAAACoBRgA0AUAAAAAJACIABgAOACsANAAAABOAAAA
AAAFAAAAtAB0AwAAAAAAAAAAAAAAAMwCzAIkAiQCtABsAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AHQDdAMGAAAAmASsBgAAAACYBJgEAAAAAAAAAAAAAAAAWAVYBcQFrAaYBpgGAAAAAPwE/AQAAAAA
AAAAAAAAAAACAAAAJADQBSQAJAAAAAAA0AXQBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAADANwCAAAAAFQACAAqADIAMgBCADYANwA3AEMAAABwAGwAAwBOAEUAVwAA
AIAABgBEAEUATABFAFQARQAAACkA/AAKAEkATgBJAFQASQBBAEwASQBaAEUAAAAxALACCQBUAEUA
UgBNAEkATgBBAFQARQAAACABBgBPAEIASgBFAEMAVAAAAEUA6AAAAAAATwBMAQ4AKABHAEwATwBC
AEEATABTACkAIABNAEUATQBPAAAACQAAAg4AKABHAGwAbwBiAGEAbABzACkAIABNAGUAbQBvAAAA
TgBoAQkAUQBVAEUAUgBZAFMAQQBWAEUAAAAYAgYAUwBPAFUAUgBDAEUAAABJADQBDwBOAE8AVABF
AFMAVQBJAEQATwBDAFUATQBFAE4AVAAAANwBBgAlAEwAUwBYAFUASQAAAE4AjAEIAEMATwBOAFQA
SQBOAFUARQAAAAYApAEKAFEAVQBFAFIAWQBDAEwATwBTAEUAAAB1AMABDgBQAE8AUwBUAE0ATwBE
AEUAQwBIAEEATgBHAEUAAABFAP//CABQAE8AUwBUAE8AUABFAE4AAAAAADQCCgBCAEkATgBEAEUA
VgBFAE4AVABTAAAATQCIAgsATwBCAEoARQBDAFQATgBBAE0ARQBfAAAA//8PAEUATQBBAEkATABQ
AFIATwBDAEUAUwBTAEkATgBHAAAA//8JAEUATQBBAEkATABTAEEAVgBFAAAA//8KAEUATQBBAEkA
TABDAEwATwBTAEUAAAAAAFgCDwBFAE0AQQBJAEwATQBPAEQARQBDAEgAQQBOAEcARQAAAHwCDwBP
AEIASgBFAEMAVABWAEEAUgBJAEEAQgBMAEUAUwAAAP//AgBXAFMAAABpAP//EABOAE8AVABFAFMA
VQBJAFcATwBSAEsAUwBQAEEAQwBFAAAAVADAAgUAVQBJAEQATwBDAAAA//8JAEUATQBBAEkATABP
AFAARQBOAAAABQAEBwAAAACQ7+5HGAAAAAAAjABAW20HAAAAAAAAAAAaAAAAJAEAAAAAAAAQAAAA
0AUAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAABBUTKe0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAA
AAAAAAAAAgAYAAAAbAQAAAAACgABAAAAAAAIAAAAbAFsAdQAAAAAAAAAAgAAAEwBXAEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAXAFcAQAAAAAAAAAATAFMAQAAAAAAAAAAAgAAAAgAAABLAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAAQBcAQAA7AAJAgAAJAADAAEAAAAAADgBAAABAAAACAAAACQCAABQAQAAAAAAAAIA
AAAEAhQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQCFAIAAAAAAAAAAAQCBAIAAAAAAAAA
AAIAAAAIAAAAWQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAADAAEAFAIAAOwACQIAACQAAwABAAAAAAA4AQAAAQAAAAgAAADM
AgAAbAEAAAAAAAABAAAAvAK8AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAC8ArwCAAAAAAAAAAABAAAABwAAAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwABAAAAAADsAAkCAAAkAAgAAAB0AwAA
kAEAAAAAAAABAAAAZANkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk
A2QDAAAAAAAAAAABAAAACgAAAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwABAAAAAADsAAkCAAAkAAgAAAAAAAAAqAEA
AAAAAAACAAAADAQcBAAAAAAAAAAAAAAAAAAAAAAMBAwEAAAAAAAAAAAAAAAAAAAAAAAAAAAcBBwE
AAAAAAAAAAABAAAAAgAAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwABABwEAADEAQYIAAAAAAMAIAAAAAAA7AAJAgAA
JAATAAAA1AAAANAAAAABAAAAAQAAAAAAAAATACwEUAEAAMwAAAABAAAAAQAAAAAAAAATAEQEbAEA
AM4AAAAAAAAAEwBcBJABAADLAAAAAAAAABgAAAAEAOABqG5tB0BbbQcEAAAAIQB8BEgBAAAIAEAA
/AQAAAQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAGAAAAAAAAAAAAAAAAACEAfATwAQAACABAAFgFAAAcAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAEAAQAAABkAIQB8BLAAAAAIAEAAxAUAADgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAB8BFwCuDiUAyB7KAME
AAAAHACoBTgFAAADAEAAmAasBoACAAAQAAAAAAAAAIwCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhUTKe0uaRC/XQDdARGG
twAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAgAYAGAGAAAkAAAACgABAAAAAAASABQA
AAAAAP//CQIAAAAAAAYAAAAA0AUYAAAAAAAAAAQAAQAAAAkC0AUJAtAFGQAcAKgFSAUAAAMAQACs
BgAAtAIAACEAfAQYAAAACABAAAAAAADEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABkABACWAAAAAADSsAAdAAAa
DgBbHARJDATKJACmGg8ARxwEy9AAAAC0ABoQAEccBMvMAAAAbAEaEQBHHATLzgAAACQCGhIARxwE
y8sAAADMAhoTAB0aGAApmARdXAEjGhoAHRoeACn8BF0UAiMaIAAdGiQAKVgFIxomAB0aKgBbxAUr
0AUkphorAFuYBklkA6YaLQAprAYjGi8AHQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgQKC/0YA
AQAAAAAAAAAAANgJAACgBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AHZjAAAAAAAAgwQBAIX/FwABAAIJQWx3YXlzIEhpZGRlbjogAIr/kgCEEAAHADACAAAAAAAAAwEA
AglWAAAAAAAAAAQAFAAAAFYAAwAyAAkAUHJpbmNpcGFsAAEADwBDYWxlbmRhclByb2ZpbGUAAQAF
AE93bmVyAPcCAwAHABAACQAJMVMyUzNTN1MAAAAIAPQAAwAHAAoAAwAJMFIARnJvbVBlcnNvbiBt
ZW1vIGlzIGZyb20uhf8IAAEAAgmK/6AAgAAABQAwAgAAAAAAAAMBAAIJeAAAAAAAAAAEAAAAAAB4
AAAAYgCJAK8AWAAYAAEACwBEZWZhdWx0TG9nbwB8Aa4AQAAFAAQARnJvbQEAAQBAAEcCrwAsABwA
AQASAFN0ZE5vdGVzTHRyR2F0ZXdhea4AEAAFAAQATG9nb64ABAC1BQMABwAUAA4ACTRTOVMxM1Mx
NlMxOFNMb2dvhf8IAAEAAAqK/0AAgAAABQAwAgAAAAAAAAIBAAIJGAAAAAAAAAAEAAAAAAAYAAAA
CgDZAFYBAwAHAAwABQAJMFMwRQBTaWduhf8IAAEAAgqK/0QAgAAABQAwAgAAAAAAAAIBAAIJGAAA
AAAAAAAHAAAAAAAYAAAACgDYAFYBAwAHAAwABQAJMFMwRQBFbmNyeXB0AIX/CAABAAIKiv+KAIAA
AAUAMAIAAAAAAAACAQACCVAAAAAAAAAAFgAAAAAAUAADABwADwBNYWlsU2F2ZU9wdGlvbnMA2gBW
AQMABwAOAAcACTFTMlMzUwAAABoABQAPAE1haWxTYXZlT3B0aW9ucwADAAcACgADAAkwUgBEZWZh
dWx0TWFpbFNhdmVPcHRpb25zhf8IAAEAAgqK/9wAigAABQAwAgAAAAAAAAIBAAIJAACsAAAAAAAM
AAAAAACsAAAAhAAFAAwAJEtlZXBQcml2YXRlAQABADAAAQAAAB8CCgKvAF4AGAAFAAwAJEtlZXBQ
cml2YXRlwgGuAEYAcACvAEAADAABAAEAMQCuADQABQAEAEZyb230AAoCrwAkAAwAAQABADIArgAY
AAUADAAkS2VlcFByaXZhdGWuAAQAtQcDAAcAJgAgAAkzUzRTNVM2UzhTMTNTMTVTMTdTMThTMTlT
MjFTMjNTJEtlZXBQcml2YXRlhf8IAAEAAgqBAoL/RgACAAAAAAABAAAAyggAAKAFAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAsAAAAAAAC7/zgAAgAAADSUmgKwNSoA
AAAcAAUADwAkSGlkZU1haWxIZWFkZXIAaAEDAAcADAAFAAkwUzBFAIMEAgCF/w4AAQALCUZyb206
CYr/YASEAQAFADACAAAAAAAAAgEACwkmBAAAAAAAABYAAAAAACYEAQBGAAMAV2hvAAUACQBQcmlu
Y2lwYWwAAQAAAAoCrwAkAA4ABQAEAEZyb22uABYABQAJAFByaW5jaXBhbACuAAQAtQMDAAcAFAAO
AAkxUzJTNVM2UzhTMTBTAQAgAAIAQ04CAAYAAAAAAAAABQADAFdobwC0Al4BAwAHABAACQAJMFIx
UzJTOFMAAQBAAAEARwAFAAIAQ04BAAAACgKvACgAHAACAGkAAAAAAAAABQADAFdobwC0Al4BrgAM
AAEAAACuAAQAtQMDAAcAGgATAAkwUjFTMlM1UzZTOFMxNFMxOFMAAQBAAAEAUwAFAAIAQ04BAAAA
CgKvACgAHAACAGoAAAAAAAAABQADAFdobwC0Al4BrgAMAAEAAACuAAQAtQMDAAcAGgATAAkwUjFT
MlM1UzZTOFMxNFMxOFMAAQCKAAYAU2VudEJ5BQACAENOAQAAAAsCrwBuAAwABQACAENOrgBiAAUA
AQBHAAEAAAALAq8AUgAcAAUAAQBHAAEAAQAgACICBQABAFMAIgKuADYABQABAFMAAQAAAAsCrwAm
AAwABQABAFMArgAaAAUADABYNDAwRnJlZUZvcm1eAa4ABAC1BwMABwA6ADQACTBSMVMyUzVTNlM4
UzEwUzExUzEyUzE0UzE1UzE2UzE3UzE4UzIwUzIxUzIyUzI0UzI2UwgAzAAFAAQARnJvbQEAAQBA
AEcCHgGvALIApgAFAAYAU2VudEJ5iQCvAI4ACgABAAAArgCEAAUACgBGcm9tRG9tYWluAQAAAAoC
rwBmAAoAAQAAAK4AXAABAAMAIEAgAAUACgBGcm9tRG9tYWluAQABAEAARwKvADIAHAAFAAoARnJv
bURvbWFpbgEAAQBAAF8CrgAWAAUACgBGcm9tRG9tYWlurgAEALUDIgKuAAQAtQOuAAQAtQMiAsIB
rgAMAAEAAACuAAQAtQMDAAcAPAA2AAkwUlI3UzEwUzEzUzE0UzE4UzIwUzIzUzI0UzI2UzI4UzI5
UzMwUzM2UzM5UzQzUzQ2UzUyUwEATgAIAEZyb21OYW1lBQAJAFByaW5jaXBhbABoAa8ALAAUAAUA
CQBQcmluY2lwYWwArgAYAAUABABGcm9tAQABAEAAXwKuAAQAtQMDAAcAFgAQAAkwUlIxUzJTOVMx
MVMxNVMBACIACQBGcm9tU3RvcHMABQAEAEZyb20BAAEAQABgAgMABwAQAAkACTBSMVMyUzZTAAAA
ZgAFAAgARnJvbU5hbWUBAAEAQAAiAgUACQBGcm9tU3RvcHMAAQABAEAARwKvADIAHAAFAAkARnJv
bVN0b3BzAAEAAQBAAF8CrgAWAAUACQBGcm9tU3RvcHMArgAEALUDIgIDAAcAHgAYAAkwUlIxUzJT
M1M0UzEwUzEzUzE3UzIwU3RtcERpc3BsYXlGcm9tX1ByZXZpZXeF/wwAAQALCSBvbiCK/6QAgAEA
BAAwAgAAAAABAQIBAAsJRAAAAAAAAAAWACUAAABEAAAANgAFAAoAUG9zdGVkRGF0ZWgBrwAeABQA
BQAKAFBvc3RlZERhdGWuAAoAaQCuAAQAtQMDAAcADAAFAAk3UzlTAHRtcERpc3BsYXlEYXRlX1By
ZXZpZXdUaW1lL2RhdGUgbWVtbyB3YXMgY3JlYXRlZCBvciBtYWlsZWQuAIX/CAABAAIKgQKC/0YA
AwAAAAAAAQAAAEALAACgBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADRrAAAAAAAAgwQDALwGAgADAIX/CAABAAAKrf+IAA4AGQAAEHwAfAAAAGIABQAPACRIaWRlTWFp
bEhlYWRlcgBoAa8ARAAKAAEAAACuADoABQAEAExvZ28BAAAACgKvACgAGAABAA0AU3RkTm90ZXNM
dHIxNgCuABAABQAEAExvZ2+uAAQAtQUDAAcAGAARAAk3UzlTMTBTMTFTMTNTMTVTAK4Chf8IAAEA
AAqBAoL/RgAEAAAAAAABAAAAyggAAKAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABGkAAAAAAAC7/2oABAAAAESbmgKwNVwAAABEAG4ArwAiABgABQAHAHRtcERhdGUA
AQAAAAsCrgAKACsArgAEALUDBQAPACRIaWRlTWFpbEhlYWRlcgBoAR0CAwAHABYADwAJNFM1UzZT
OFMxMFMxMVMAgwQEAIX/DgABAAsJRnJvbToJiv9cAIQBAAUAMAIAAAAAAAACAQALCSIAAAAAAAAA
FQAAAAAAIgAAACAABQAWAHRtcERpc3BsYXlGcm9tX1ByZXZpZXcDAHRtcERpc3BsYXlGcm9tX05v
TG9nbwCF/wwAAQALCSBvbiCK/6IAgAEABAAwAgAAAAABAQIBAAsJRAAAAAAAAAAVACUAAABEAAAA
NgAFAAoAUG9zdGVkRGF0ZWgBrwAeABQABQAKAFBvc3RlZERhdGWuAAoAaQCuAAQAtQMDAAcADAAF
AAk3UzlTAHRtcERpc3BsYXlEYXRlX05vTG9nb1RpbWUvZGF0ZSBtZW1vIHdhcyBjcmVhdGVkIG9y
IG1haWxlZC6F/wgAAQALCYECgv9GAAUAAAAAAAEAAADKCAAAoAUAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAECQAAAAAAALv/cAAFAAAACJ+aArA1YgAAAEgABQAJAFJl
cGx5RGF0ZQABAAAACgIFAAcAUmVwbHlUbwABAAAACgIcAgQABQAPACRIaWRlTWFpbEhlYWRlcgBo
AR0CAwAHABgAEgAJMlMzUzRTNVM2UzdTOVMxMFODBAUAhf8IAAEACwmK/wYBgAEABQAwAgAAAAAA
AAIBAAsJzgAAAAAAAAATAAAAAADOAAAAmgABAA4AUGxlYXNlIHJlc3BvbmQFAAcAUmVwbHlUbwAB
AAAACgKvACgACgABAAAArgAeAAEABAAgdG8gBQAHAFJlcGx5VG8AIgKuAAQAtQMiAgUACQBSZXBs
eURhdGUAAQAAAAoCrwAsAAoAAQAAAK4AIgABAAQAIGJ5IAUACQBSZXBseURhdGUAVgEiAq4ABAC1
AyICAwAHADIALAAJMVMyUzVTNlM4UzEwUzExUzEyUzE0UzE1UzE4UzE5UzIxUzIzUzI0UzI1U3Rt
cERpc3BsYXlSZXBseUluZm8Ahf8IAAEACwmBAoL/RgAGAAAAAAABAAEAyggAAKAFAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAkAAAAAAAC7/x4BBgAAAHijmgKwNRAB
AADCAAUADwAkSGlkZU1haWxIZWFkZXIAaAEFAAkAUHJpbmNpcGFsAFkBHQIFAAkAUHJpbmNpcGFs
AAEAAAAKAh0CBQAJAFByaW5jaXBhbABoAQIABQAAAAAAAAAFAAkAUHJpbmNpcGFsALQCAgAFAAAA
AAAAAAUABABGcm9ttAIKAhwCiQAeARwCBAAdAokAAgAFAAAAAAAAAAUACQBQcmluY2lwYWwAtAIC
AAUAAAAAAAAA9AC0AgoCHAIEAB0CAwAHAEwARgAJNFM1UzlTMTBTMTFTMTJTMTNTMTRTMTlTMjBT
MjRTMjZTMjdTMzFTMzNTMzRTMzdTMzhTNDBTNDFTNDVTNDdTNDhTNTJTgwQGAIX/EQABAAsJU2Vu
dCBieToJAIr/OgKEAQAFADACAAAAAAAAAgEACwkGAgAAAAAAABAAAAAAAAYCCADiAIkArwDYABYA
AgAGAAAAAAAAAPQAtALCAa4AwgAFAAQARnJvbQEAAQBAAEcCHgGvAKYAmgACAAYAAAAAAAAABQAE
AEZyb220AgUACgBGcm9tRG9tYWluAQAAAAoCrwBmAAoAAQAAAK4AXAABAAMAIEAgAAUACgBGcm9t
RG9tYWluAQABAEAARwKvADIAHAAFAAoARnJvbURvbWFpbgEAAQBAAF8CrgAWAAUACgBGcm9tRG9t
YWlurgAEALUDIgKuAAQAtQMiAsIBrgAMAAEAAACuAAQAtQOuAAQAtQMDAAcAPAA2AAk0UzEwUzE0
UzIxUzI0UzMyUzMzUzM2UzM3UzM5UzQxUzQyUzQzUzQ5UzUyUzU2UzU5UzY0UwEAIAAIAEZyb21O
YW1lBQAEAEZyb20BAAEAQABfAgMABwAQAAoACTBSUjFTMlM2UwEAIgAJAEZyb21TdG9wcwAFAAQA
RnJvbQEAAQBAAGACAwAHABAACQAJMFIxUzJTNlMAAABmAAUACABGcm9tTmFtZQEAAQBAACICBQAJ
AEZyb21TdG9wcwABAAEAQABHAq8AMgAcAAUACQBGcm9tU3RvcHMAAQABAEAAXwKuABYABQAJAEZy
b21TdG9wcwCuAAQAtQMiAgMABwAeABgACTBSUjFTMlMzUzRTMTBTMTNTMTdTMjBTdG1wRGlzcGxh
eVNlbnRCeYX/CAABAAsJgQKC/0YABwAAAAAAAAAAAEALAAA4BAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQJAAAAAAAAgwQHALwGAgAHAIX/CAABAQQJrf8MAAwACQAA
EAAArP+5ANZiAJQBAAsJCgCqAAAAgAABAAQAVG86IAIABgAAAAAAAAAFAAYAU2VuZFRvtAIBAAIA
LCCFAiICBQAGAENvcHlUbwEAAAALAq8APgAyAAEABwAgIGNjOiAgAAIABgAAAAAAAAAFAAYAQ29w
eVRvtAIBAAIALCCFAiICrgAMAAEAAACuAAQAtQMiAgMABwAoACEACTFTMlM4UzEzUzE0UzJFMTdT
MThTMjFTMjJTMjhTMzFTAAAAhf8IAAEBBAmBAoL/RgAIAAAAAAABAAAAyggAAKAFAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAkAAAAAAACDBAgAvAYCAAgAhf8MAAEA
CwlUbzoJsP8UAAAAAQAAAAAAAAAAAAAAAACK/9gAhhABBR4gAgAAAAAAAAMBAAAJAAAgAAAAagAG
ACQAAAAgAAAAEgAFAAYAU2VuZFRvfQEDAAcADAAFAAkwUzBFAGoAAABQAAUABgBTZW5kVG9eAQEA
AAAKAnAAHAKvADIAKAABABwATm8gbmFtZXMgZm91bmQgdG8gc2VuZCBtYWlsLnsBrgAKAHoArgAE
ALUDAwAHABgAEQAJMVM2UzdTOFM5UzExUzE2UwBTZW5kVG9MaXN0IG9mIHByaW1hcnkgcGVvcGxl
IHRvIHNlbmQgbWVtby6F/wgAAQALCYECgv9GAAkAAAAAAAAAAADKCAAAoAUAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGCQAAAAAAAIMECQC8BgIACQCF/wwAAQALCWNj
Ogmw/xQAAAABAAAAAAAAAAAAAAAAAIr/dACGEAEFHiACAAAAAAAAAwEAAAkAACAAAAAAAAYAKgAA
ACAAAAASAAUABgBDb3B5VG99AQMABwAMAAUACTBTMEUAQ29weVRvTGlzdCBvZiBwZW9wbGUgdG8g
c2VuZCBhIGNvcHkgb2YgdGhlIG1lbW8uhf8JAAEACwkgAIr/3gCEAQAFADACAAAAAAAAAgEAAAmk
AAAAAAAAABUAAAAAAKQAAAB6AAUADQBEZWxpdmVyZWREYXRlAAEAAAALAgUACwBCbGluZENvcHlU
bwABAAAACwIcAq8AQgA2AAEABgAoYmNjOiACAAUAAAAAAAAABQALAEJsaW5kQ29weVRvALQCIgIB
AAEAKQAiAq4ADAABAAAArgAEALUDAwAHACgAIgAJM1M0UzVTNlM3UzhTMTBTMTFTMTJTMTZTMThT
MTlTMjFTdG1wRGlzcGxheUJsaW5kQ29weVRvAIX/CAABAAsJgQKC/0YACgAAAAAAAAAAAMoIAACg
BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFYpAAAAAAAAgwQKALwG
AgAKAIX/DQABAAsJYmNjOgkAsP8UAAAAAQAAAAAAAAAAAAAAAACK/4gAhgABBR4gAgAAAAAAAAIB
AAAJAAAmAAAAAAALADIAAAAmAAAAGAAFAAsAQmxpbmRDb3B5VG8AfQEDAAcADAAFAAkwUzBFAEJs
aW5kQ29weVRvTGlzdCBvZiB1bmRpc2Nsb3NlZCBwZW9wbGUgdG8gc2VuZCBjb3BpZXMgb2YgbWVt
by4Ahf8IAAEACwmBAoL/RgALAAAAAAAAAAAAyggAAKAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABAkAAAAAAACDBAsAvAYCAAsAhf8RAAEACwlTdWJqZWN0OgkAiv+Y
AIIQAAUAMAIAAAAAAAADAQAACQAAXAAAAAAABwAQAAAAXAAAAEoABQALAFBob25lQ2FsbGVyAGgB
AQAMAFBob25lIENhbGw6IAUACwBQaG9uZUNhbGxlcgAiAgUABwBTdWJqZWN0AF4BSgMDAAcAEAAK
AAk3UzhTOVMxMVNTdWJqZWN0U3ViamVjdCBvZiBtZW1vLgCF/wgAAQALCYECgv9GAAwAAAAAAAAA
AABACwAAoAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0YwAAAAAA
AIMEDACF/wgAAQAACa4Chf8IAAEAAAqBAoL/RgANAAAAAAAAAAAAoAUAAKAFAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMGsAAAAAAACDBA0AvAYCAA0Ahf8IAAEAAAmt
/7QADgAZAAAQqACoAAAAfAAFAA8AJEhpZGVNYWlsSGVhZGVyAGgBrwBeAAoAAQAAAK4AVAAFAAoA
UG9zdGVkRGF0ZQEAAAALAgUACQBTZW5kZXJUYWcAAQAAAAEAAQBOAB8CCgIEABwCrwAcAAoAAQAA
AK4AEgABAAUATW9vZHMArgAEALUFAwAHACoAIwAJN1M5UzEwUzExUzEyUzEzUzE1UzE2UzE3UzE4
UzIxUzIzUwCuAoX/CAABAAAJgQKC/0YADgAAAAAAAAAAAKAFAACgBQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAAAgwQOALwGAgAOAIX/CAABAAAJgQKDBA8A
hf8IAAEAAAmK/ygAijABAAAwAgAAAAAAAAIBAAAKAAAAAAAAAAAEAAAAAABCb2R5hf8IAAEAAAmB
AoMEAQCF/wgAAQAACb0cDwAAAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAC+/ygAAAAFAAAAiUAAAA0A
AAAAAAAARWRpdCBEb2N1bWVudGUBAAIKvv8+AAAAAQAAAJ1BAAAHAAAAAAAAAEZvcndhcmQCIAAA
ABIAAgDICwAAAAAAAO0BAwAHAAwABQAJMFMwRQC+/0wAAAABAB4AikAAAAgAAAAAAAAATmV3IE1l
bW8uAAAAIAACAOgDAAAAAAAAAQAAAAEABABNZW1vHwLtAgMABwAMAAUACTBTMEUAvv88AAAAAQAE
AIpAAAAGAAAAAAAAAERlbGV0ZSAAAAASAAIA2gcAAAAAAADtAQMABwAMAAUACTBTMEUAvv8sAAAA
BQAVAItAAAASAAAAAAAAAF9Nb3ZlIFRvIEZvbGRlci4uLgUAPXy+/6gAAAABAAAAiUAAABcAAAAA
AAAARGVsaXZlcnkgSW5mb3JtYXRpb24uLi5SegAAAF4AAQAMAERlbGl2ZXJ5SW5mbwIAeAAAAAAA
AAACAHkAAAAAAAAAHwICAIQAAAAAAAAAHwICAIIAAAAAAAAAHwIBABQARGVsaXZlcnkgSW5mb3Jt
YXRpb27fAwMABwAaABMACTRTNVM2UzdTOFM5UzEwUzEyUwC+/yIAAAAFAAcAikAAAAgAAAAAAAAA
X0ZvcndhcmQHAAQKvv9QAAAAAQADAIpAAAAFAAAAAAAAAFJlcGx5ADQAAAAmAAIA6AMAAAAAAAAB
AAAAAQAAAB8CAQAFAFJlcGx5AO0DAwAHAAwABQAJMFMwRQC+/9YAAAABAA4AikAAABIAAAAAAAAA
UmVwbHkgV2l0aCBIaXN0b3J5rgAIAF4A3QCvAFQASAACAA0AAAAAAAAAAQASAFJlcGx5IHdpdGgg
SGlzdG9yeQEAGwBUaGlzIGRvY3VtZW50IGlzIHRydW5jYXRlZC4AsAOuAAwAAQAAAK4ABAC1AwMA
BwASAAsACTRTOFMxMFMxM1MAAAAyAAIA6AMAAAAAAAABAAAAAQAAAB8CAQASAFJlcGx5IHdpdGgg
aGlzdG9yee0DAwAHAAoAAwAJMFIAvv94AAAAAQACABNAAAAKADgAAAAAAEFkZHJlc3MuLi4gAAAA
EgACAMcLAAAAAAAA7QEDAAcADAAFAAkwUzBFADgAAAAmAAUACgBQb3N0ZWREYXRlaAEFAAQARnJv
bfQACwIcAgQAAwAHABAACQAJNVM2UzdTOFMAvv98AAAAAQAbABJAAAAFAEAAAAAAAENsb3NlACAA
AAASAAIA/BEAAAAAAADtAQMABwAMAAUACTBTMEUAQAAAADIABQAQAElzTWFpbFN0YXRpb25lcnlo
AQUACgBQb3N0ZWREYXRlaAEdAgQAHgEDAAcADAAFAAk2UzdTAL7/ygAAAAEAHQATQQAADQA8AAAA
AABTYXZlIEFzIERyYWZ0AGoAAwAiAAkAdG1wQWN0aW9uAAEACwBTYXZlQXNEcmFmdAADAAcADgAH
AAkxUzJTM1MACAASAAIAxgsAAAAAAACxAQMABwAKAAMACTBSAAAAEgACAPwRAAAAAAAAsQEDAAcA
CgADAAkwUgA8AAAALgAFABAASXNNYWlsU3RhdGlvbmVyeWgBBQAKAFBvc3RlZERhdGVoAR0CAwAH
AAwABQAJNFM1UwC+//4AAAABABUAE0AAAA0AcAAAAAAAU2F2ZSBhbmQgRmlsZWZqAAMAIgAJAHRt
cEFjdGlvbgABAAsAU2F2ZUFuZEZpbGUAAwAHAA4ABwAJMVMyUzNTAAgAEgACAMYLAAAAAAAA7QED
AAcACgADAAkwUgAAABIAAgD2FwAAAAAAAO0BAwAHAAoAAwAJMFIAcAAAAFIABQAQAElzTWFpbFN0
YXRpb25lcnloAQUACgBQb3N0ZWREYXRlWQEdAgUACgBQb3N0ZWREYXRlaAEFAAQARnJvbfQACgIc
AgQABAAdAgMABwAcABYACTRTNVM5UzEwUzE2UzE3UzE4UzE5U77/TAMAAAEAAQATQAAABABWAAAA
AABTZW5k3AIBAKoACwBQcm9tcHRWYWx1ZQAFABYARGVmYXVsdE1haWxTYXZlT3B0aW9ucwEAAQAy
AAoCrwByAFAAAgAXAAAAAAAAAAEADgBTYXZlIHdoZW4gc2VudAEAKABEbyB5b3Ugd2lzaCB0byBz
YXZlIGEgY29weSBvZiB0aGlzIE1lbW8/sAOuACIABQAWAERlZmF1bHRNYWlsU2F2ZU9wdGlvbnOu
AAQAtQMDAAcAGAARAAkxUzJTNVM2UzhTMTRTMTdTAAEAZgALAFNhdmVPcHRpb25zAAUACwBQcm9t
cHRWYWx1ZQAAAAAAAAAAAPA/EAEKAq8AMgAYAAUACwBTYXZlT3B0aW9ucwDCAa4AGgAFAAsAUHJv
bXB0VmFsdWUAVgGuAAQAtQMDAAcAGAARAAkwUlIxUzJTNVM2UzlTMTRTAAMAUgAJAHRtcEFjdGlv
bgAFABYARGVmYXVsdE1haWxTYXZlT3B0aW9ucwEAAQAxAAoCrwAcABIAAQAHAE1haWxpbmcArgAK
AL4ArgAEALUDAwAHABoAEwAJMFJSMVMyUzNTNlM3UzlTMTFTAAMAFgALAE1haWxPcHRpb25zAL4A
AwAHABAACQAJMFIxUzJTM1MACAAyAAIAygsAAAAAAADtAa8AHgAKAAEAAACuABQAAAAAAAAAAAAA
AMIBrgAEALUDAwAHAA4ABwAJMFI3UzlTAAMAUgAJAHRtcEFjdGlvbgAFAAsAU2F2ZU9wdGlvbnMA
AQABADEACgKvACYAFgABAAsAU2VuZEFuZEZpbGUArgAQAAEABABTZW5krgAEALUDAwAHABoAEwAJ
MFJSMVMyUzNTNlM3UzlTMTFTAAgAMgACAMYLAAAAAAAAsQGvAB4ACgABAAAArgAUAAAAAAAAAAAA
AADCAa4ABAC1AwMABwAOAAcACTBSN1M5UwAAABIAAgD8EQAAAAAAALEBAwAHAAoAAwAJMFIAVgAA
AD4ABQAKAFBvc3RlZERhdGVoAQUABABGcm9t9AALAhwCBAAFABAASXNNYWlsU3RhdGlvbmVyeWgB
HQIDAAcAFgAPAAk1UzZTN1M4UzEwUzExUwC+/wwCAAABABUAE0AAABAAVgAAAAAAU2VuZCBBbmQg
RmlsZS4uLpABAwBSAAkAdG1wQWN0aW9uAAUAFgBEZWZhdWx0TWFpbFNhdmVPcHRpb25zAQABADEA
CgKvABwAEgABAAcATWFpbGluZwCuAAoAvgCuAAQAtQMDAAcAFgAQAAkxUzJTM1M2UzdTOVMxMVMD
ABYACwBNYWlsT3B0aW9ucwC+AAMABwAQAAkACTBSMVMyUzNTAAgAMAACAMoLAAAAAAAA7QGvABwA
CAArAK4AFAAAAAAAAAAAAAAAwgGuAAQAtQMDAAcADgAIAAkwUlI3UzlTAwAiAAkAdG1wQWN0aW9u
AAEACwBTZW5kQW5kRmlsZQADAAcAEAAKAAkwUlIxUzJTM1MIADAAAgDGCwAAAAAAALEBrwAcAAgA
KwCuABQAAAAAAAAAAAAAAMIBrgAEALUDAwAHAA4ABwAJMFI3UzlTAAgAKAACAPYXAAAAAAAAsQGv
ABQACAArAK4ADAAqAMIBrgAEALUDAwAHAA4ABwAJMFI3UzlTAAAAEgACAPwRAAAAAAAAsQEDAAcA
CgADAAkwUgBWAAAAPgAFAAoAUG9zdGVkRGF0ZWgBBQAEAEZyb230AAsCHAIEAAUAEABJc01haWxT
dGF0aW9uZXJ5aAEdAgMABwAWAA8ACTVTNlM3UzhTMTBTMTFTAL7/dAMAAAEAdgATQAAAEwA4AAAA
AABEZWxpdmVyeSBPcHRpb25zLi4uMBIDCABGAAEADwBEZWxpdmVyeU9wdGlvbnMAAgB4AAAAAAAA
AAIAeQAAAAAAAAAfAgEAEABEZWxpdmVyeSBPcHRpb25z3wMDAAcADAAFAAk0UzhTAAAAEgACAF4b
AAAAAAAA7QEDAAcACgADAAkwUgADAOYBCQBfVmlld0ljb24ABQAJAFNlbmRlclRhZwABAAAAAQAB
AE4AHwIKAq8AtgEIAL4ArgCuAQUACQBTZW5kZXJUYWcAAQABAFAACgKvAJQBEAAAAAAAAAAAQGVA
rgCEAQUACQBTZW5kZXJUYWcAAQABAEMACgKvAGoBEAAAAAAAAAAAIGVArgBaAQUACQBTZW5kZXJU
YWcAAQABAFIACgKvAEABEAAAAAAAAAAAYGRArgAwAQUACQBTZW5kZXJUYWcAAQABAFQACgKvABYB
EAAAAAAAAAAAQFVArgAGAQUACQBTZW5kZXJUYWcAAQABAEYACgKvAOwAEAAAAAAAAAAAgFJArgDc
AAUACQBTZW5kZXJUYWcAAQABAEcACgKvAMIAEAAAAAAAAAAA4GNArgCyAAUACQBTZW5kZXJUYWcA
AQABAEoACgKvAJgAEAAAAAAAAAAAwGRArgCIAAUACQBTZW5kZXJUYWcAAQABAFkACgKvAG4AEAAA
AAAAAAAAADdArgBeAAUACQBTZW5kZXJUYWcAAQABAFEACgKvAEQAEAAAAAAAAAAAQGRArgA0AAUA
CQBTZW5kZXJUYWcAAQABAE0ACgKvABoAEAAAAAAAAAAAACRArgAKAL4ArgAEALUXAwAHALwAtgAJ
MFJSMVMyUzNTNVJTM0U2UzdTOFM5UzExUzEzUlMzRTE0UzE1UzE3UzE5UlMzRTIwUzIxUzIzUzI1
UlMzRTI2UzI3UzI5UzMxUlMzRTMyUzMzUzM1UzM3UlMzRTM4UzM5UzQxUzQzUlMzRTQ0UzQ1UzQ3
UzQ5UlMzRTUwUzUxUzUzUzU1UlMzRTU2UzU3UzU5UzYxUlMzRTYyUzYzUzY1UzY3UlMzRTY4UzY5
UzcxUzczUlMzRTgAAAAmAAUACgBQb3N0ZWREYXRlaAEFAAQARnJvbfQACwIcAgQAAwAHABAACQAJ
NVM2UzdTOFMAvv/CAgAAAQAAABFAAAASAGQAAAAAAFNwZWNpYWwgT3B0aW9ucy4uLjYCAwAgAAkA
UmVwbHlEYXRlAAUACQBSZXBseURhdGUAAwAHAA4ABwAJMVMyUzNTAAMAHAAHAFJlcGx5VG8ABQAH
AFJlcGx5VG8AAwAHABAACQAJMFIxUzJTM1MACABeAAEAEgAoQWR2YW5jZWQgT3B0aW9ucykCAHgA
AAAAAAAAAgB5AAAAAAAAAB8CAQAPAFNwZWNpYWwgT3B0aW9ucwDfA68AFAAIACsArgAMACoAwgGu
AAQAtQMDAAcAFAAOAAkwUjZTMTBTMTNTMTVTAwCwABMAdG1wRGlzcGxheVJlcGx5SW5mbwABAA4A
UGxlYXNlIHJlc3BvbmQFAAcAUmVwbHlUbwABAAAACgKvACgACgABAAAArgAeAAEABAAgdG8gBQAH
AFJlcGx5VG8AIgKuAAQAtQMiAgUACQBSZXBseURhdGUAAQAAAAoCrwAsAAoAAQAAAK4AIgABAAQA
IGJ5IAUACQBSZXBseURhdGUAVgEiAq4ABAC1AyICAwAHADwANQAJMFIxUzJTM1M0UzVTOFM5UzEx
UzEzUzE0UzE1UzE3UzE4UzIxUzIyUzI0UzI2UzI3UzI4UwADAEgACwBEdWVEYXRlVGltZQAFAAkA
UmVwbHlEYXRlAAEAAAAKAq8AHgAIACgArgAWAAUACQBSZXBseURhdGUArgAEALUDAwAHABgAEgAJ
MFIxUzJTM1M2UzdTOVMxMVMAABIAAgBeGwAAAAAAAO0BAwAHAAoAAwAJMFIAZAAKAAQAAABCAAUA
CgBQb3N0ZWREYXRlaAEFAAQARnJvbfQACwIcAgQAAgCnAAAAAAAAAPsBBAEAAAAAAAAAABRACgId
AgMABwAcABUACTVTNlM3UzhTMTBTMTFTMTVTMTZTAL7/xAAAAAEAAAARQAAAFQAqAAAAAABTYXZl
IEFzIFN0YXRpb25lcnkuLi4AbgADACYACQB0bXBBY3Rpb24AAQAQAFNhdmVBc1N0YXRpb25lcnkD
AAcADgAHAAkxUzJTM1MACAASAAIAxgsAAAAAAACxAQMABwAKAAMACTBSAAAAEgACAPwRAAAAAAAA
sQEDAAcACgADAAkwUgAqAAAAHAAFABAASXNNYWlsU3RhdGlvbmVyeWgBAwAHAAwABQAJMFMwRQC+
/zAAAAAFAAAAnEEAABYAAAAAAAAAX1JlbW92ZSBGcm9tIEZvbGRlci4uLhMAPny+/yYAAAAFAAAA
nEEAAAsAAAAAAAAAQ2F0ZWdvcmlfemV0FABOfL7/IAAAAAUAAQCcQQAABQAAAAAAAABTU2VuZAAV
AAMKvv+IAgAAAgAAAB1BAAASACgAAAAAAENvcHkgaW50b1xOZXcgTWVtbycrK0xvdHVzU2NyaXB0
IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6NTooT3B0aW9ucyk6MDo2NgoKJysrTG90dXNTY3Jp
cHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihGb3J3YXJkKTowOjEKRGVjbGFyZSBTdWIg
Q2xpY2soU291cmNlIEFzIEJ1dHRvbikKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmly
b25tZW50OjI6NTooRGVjbGFyYXRpb25zKTowOjIKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50
IEVudmlyb25tZW50OjI6MjpCaW5kRXZlbnRzOjE6MTI5ClByaXZhdGUgU3ViIEJpbmRFdmVudHMo
Qnl2YWwgT2JqZWN0bmFtZV8gQXMgU3RyaW5nKQogICAgIFN0YXRpYyBTb3VyY2UgQXMgQlVUVE9O
CiAgICAgU2V0IFNvdXJjZSA9IEJpbmQoT2JqZWN0bmFtZV8pCiAgICAgT24gRXZlbnQgQ2xpY2sg
RnJvbSBTb3VyY2UgQ2FsbCBDbGljawpFbmQgU3ViCgonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVu
dCBFbnZpcm9ubWVudDoyOjI6Q2xpY2s6MToxMgpTdWIgQ2xpY2soU291cmNlIEFzIEJ1dHRvbikK
ICAgICBDYWxsIENyZWF0ZU5ld0RvYyhORVdfTUVNTykKRW5kIFN1YgAoAAAAGgCJAAUACQB0bXBu
ZXdkb2MAaAEdAgMABwAMAAUACTFTMlMAvv+WAgAAAgAAAB1BAAAcACgAAAAAAENvcHkgaW50b1xO
ZXcgQ2FsZW5kYXIgRW50cnknKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoy
OjU6KE9wdGlvbnMpOjA6NjYKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50
OjI6NTooRm9yd2FyZCk6MDoxCkRlY2xhcmUgU3ViIENsaWNrKFNvdXJjZSBBcyBCdXR0b24pCgon
KytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KERlY2xhcmF0aW9ucyk6
MDoyCgonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjI6QmluZEV2ZW50
czoxOjEyOQpQcml2YXRlIFN1YiBCaW5kRXZlbnRzKEJ5dmFsIE9iamVjdG5hbWVfIEFzIFN0cmlu
ZykKICAgICBTdGF0aWMgU291cmNlIEFzIEJVVFRPTgogICAgIFNldCBTb3VyY2UgPSBCaW5kKE9i
amVjdG5hbWVfKQogICAgIE9uIEV2ZW50IENsaWNrIEZyb20gU291cmNlIENhbGwgQ2xpY2sKRW5k
IFN1YgoKJysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6MjoyOkNsaWNrOjE6
MTIKU3ViIENsaWNrKFNvdXJjZSBBcyBCdXR0b24pCiAgICAgQ2FsbCBDcmVhdGVOZXdEb2MoTkVX
X0NBTEVOREFSKQpFbmQgU3ViACgAAAAaAIkABQAJAHRtcG5ld2RvYwBoAR0CAwAHAAwABQAJMVMy
UwC+/4gCAAACAAAAHUEAABIAKAAAAAAAQ29weSBpbnRvXE5ldyBUYXNrJysrTG90dXNTY3JpcHQg
RGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihPcHRpb25zKTowOjY2CgonKytMb3R1c1Njcmlw
dCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KEZvcndhcmQpOjA6MQpEZWNsYXJlIFN1YiBD
bGljayhTb3VyY2UgQXMgQnV0dG9uKQoKJysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJv
bm1lbnQ6Mjo1OihEZWNsYXJhdGlvbnMpOjA6MgoKJysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQg
RW52aXJvbm1lbnQ6MjoyOkJpbmRFdmVudHM6MToxMjkKUHJpdmF0ZSBTdWIgQmluZEV2ZW50cyhC
eXZhbCBPYmplY3RuYW1lXyBBcyBTdHJpbmcpCiAgICAgU3RhdGljIFNvdXJjZSBBcyBCVVRUT04K
ICAgICBTZXQgU291cmNlID0gQmluZChPYmplY3RuYW1lXykKICAgICBPbiBFdmVudCBDbGljayBG
cm9tIFNvdXJjZSBDYWxsIENsaWNrCkVuZCBTdWIKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50
IEVudmlyb25tZW50OjI6MjpDbGljazoxOjEyClN1YiBDbGljayhTb3VyY2UgQXMgQnV0dG9uKQog
ICAgIENhbGwgQ3JlYXRlTmV3RG9jKE5FV19UQVNLKQpFbmQgU3ViACgAAAAaAIkABQAJAHRtcG5l
d2RvYwBoAR0CAwAHAAwABQAJMVMyUwC+/34AAAABAAAAHUEAABMAKAAAAAAAQ29weSBpbnRvXE5l
dyBHcm91cDIsAAAAHgACAKIPAAAAAAAAAQAIAE5ld0dyb3Vw7QIDAAcADAAFAAkwUzBFACgAAAAa
AIkABQAJAHRtcG5ld2RvYwBoAR0CAwAHAAwABQAJMVMyUwABACwBTFNPQgMAFABlbgAABAAMADIA
BAAAALgCuAEAAAAAJAIYACQAAAAAAAAAiAAYADgArAA4AVQAVAAAAAAAAwAAALQAmAIAAAAAtAC0
AAAAAAAAAAAAmAKYAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAVwBAQAAAEACQAIAAAAA
AAAAAAAAAABAAkACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAACQAJAAA
AAAAAAAAAAAAAAAAAAAAAAAAACQAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwC8
AQAAAAAkAAgAKgAyADIAQgBDADMANQAwAAAAAABsAAMATgBFAFcAAACAAAYARABFAEwARQBUAEUA
AAAAANAACgBJAE4ASQBUAEkAQQBMAEkAWgBFAAAAaRD0AAkAVABFAFIATQBJAE4AQQBUAEUAAAD/
/wYATwBCAEoARQBDAFQAAAAYAOAAAAAAAAAACAEOACgARwBMAE8AQgBBAEwAUwApACAATQBFAE0A
TwAAAAAA//8OACgARwBsAG8AYgBhAGwAcwApACAATQBlAG0AbwAAAAAA//8FAEMATABJAEMASwAA
AFQBBgBTAE8AVQBSAEMARQAAAAAA//8GAEIAVQBUAFQATwBOAAAAAAAcAQYAJQBMAFMASQBEAEUA
AAAAAIABCgBCAEkATgBEAEUAVgBFAE4AVABTAAAATQCgAQsATwBCAEoARQBDAFQATgBBAE0ARQBf
AAAA//8TAEQATwBDAFUATQBFAE4AVABDAE8ATgBWAEUAUgBTAEkATwBOAFMAAAD//wwAQwBSAEUA
QQBUAEUATgBFAFcARABPAEMAAABFAP//CABOAEUAVwBfAE0ARQBNAE8AAAAGAAUAvAIAAAAAC04d
jxgAAAAAAIwAWHQnAwAAAAAAAAAAGgAAAAwBAAAAAAAAEAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWEynt
LmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAABDOAQEAAAAAAAAAAAIAGAAAABQCAAAAAFoE
AQAAAAAACAAAAFwBAADUAAAAAAAAAAEAAABMAUwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAEwBTAEAAAAAAAAAAAEAAAAIAAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAEAAAAAAOQACQIA
ACQACAAAAJgCAAAgAQAAAAAAAAIAAAD0AQQCAAAAAAAAAAAAAAAAAAAAAPQB9AEAAAAAAAAAAAAA
AAAAAAAAAAAAAAQCBAIAAAAAAAAAAAEAAAACAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAEABAIAADwBBggAAAAA
AwAgAAAAAADkAAkCAAAkABMAAADUAAAA1QAAAAAAAAAYAAAABABYAUA0lANYdCcDGAAAACEAJAKw
AAAACABAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAwABAAAAAAAZAAQAAAAAAAAApAEBAAAAAAAAAAAAAAAA
AAIAAAAAAAAABAA2AAAAAADSsAAdAAAaCwBbBAJJ9AHKJACmGgwARwQCy9UAAAC0ABoNAB0aEQAp
QAJ+qAIjGhIAHQIAAAABACwBTFNPQgMAFABlbgAABAAMADIABAAAALgCwAEAAAAAJAIYACQAAAAA
ACQAAAAYADgArAA4AVQAVAAAAAAAAwAAALQAmAIAAAAAtAC0AAAAAACYApgCAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABcAVwBAQAAAEACQAIAAAAAAAAAAAAAAABAAkACAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAACQAJAAAAAAAAAAAAAAAAAAAAAAAAAAAACQA
JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwDEAQAAAACIAAgAKgAyADIAQgBDADQA
NQA0AAAAyA1sAAMATgBFAFcAAACAAAYARABFAEwARQBUAEUAAABAANAACgBJAE4ASQBUAEkAQQBM
AEkAWgBFAAAAAAD0AAkAVABFAFIATQBJAE4AQQBUAEUAAAD//wYATwBCAEoARQBDAFQAAAAAAOAA
AAAAAAAACAEOACgARwBMAE8AQgBBAEwAUwApACAATQBFAE0ATwAAAAAA//8OACgARwBsAG8AYgBh
AGwAcwApACAATQBlAG0AbwAAAAEAoAEFAEMATABJAEMASwAAAFQBBgBTAE8AVQBSAEMARQAAAAAA
//8GAEIAVQBUAFQATwBOAAAAEAUcAQYAJQBMAFMASQBEAEUAAAAAAIABCgBCAEkATgBEAEUAVgBF
AE4AVABTAAAAAAD//wsATwBCAEoARQBDAFQATgBBAE0ARQBfAAAA//8TAEQATwBDAFUATQBFAE4A
VABDAE8ATgBWAEUAUgBTAEkATwBOAFMAAAD//wwAQwBSAEUAQQBUAEUATgBFAFcARABPAEMAAABG
fv//DABOAEUAVwBfAEMAQQBMAEUATgBEAEEAUgAAAAAABQC8AgAAAACAnaGfGAAAAAAAjABIQCgD
AAAAAAAAAAAaAAAADAEAAAAAAAAQAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARYTKe0uaRC/XQDdARGGtwAA
AAAAAAAAAAAAAAAAAABkAAAAEM4BAQAAAAAAAAAAAgAYAAAAFAIAAAAAWgQBAAAAAAAIAAAAXAEA
ANQAAAAAAAAAAQAAAEwBTAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
TAFMAQAAAAAAAAAAAQAAAAgAAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAQAAAAAA5AAJAgAAJAAIAAAAmAIAACAB
AAAAAAAAAgAAAPQBBAIAAAAAAAAAAAAAAAAAAAAA9AH0AQAAAAAAAAAAAAAAAAAAAAAAAAAABAIE
AgAAAAAAAAAAAQAAAAIAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAQAEAgAAPAEGCAAAAAADACAAAAAAAOQACQIA
ACQAEwAAANQAAADVAAAAAAAAABgAAAAEAFgBuDUlA0hAKAMYAAAAIQAkArAAAAAIAEAAAAAAAIQB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQADAAEAAAAAABkABAAAAAAAAACkAQEAAAAAAAEAAAAAAPA/AgAAAAAAAAAEADYA
AAAAANKwAB0AABoLAFsEAkn0AcokAKYaDABHBALL1QAAALQAGg0AHRoRAClAAn6oAiMaEgAdAgAA
AAEALAFMU09CAwAUAGVuAAAEAAwAMgAEAAAAuAK4AQAAAAAkAhgAJAAAAAAAJACIAAAAOACsADgB
VABUAAAAAAADAAAAtACYAgAAAAC0AJgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAFwBXAEBAAAAQAJAAgAAAAAAAAAAAAAAAEACQAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAJAAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAkAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAADALwBAAAAABgACAAqADIAMgBCAEMANQA2ADAAAAAAAGwAAwBO
AEUAVwAAAIAABgBEAEUATABFAFQARQAAAGQH0AAKAEkATgBJAFQASQBBAEwASQBaAEUAAABwAfQA
CQBUAEUAUgBNAEkATgBBAFQARQAAAP//BgBPAEIASgBFAEMAVAAAANoC4AAAAAAAABwIAQ4AKABH
AEwATwBCAEEATABTACkAIABNAEUATQBPAAAAUBn//w4AKABHAGwAbwBiAGEAbABzACkAIABNAGUA
bQBvAAAAkBn//wUAQwBMAEkAQwBLAAAAVAEGAFMATwBVAFIAQwBFAAAAAAD//wYAQgBVAFQAVABP
AE4AAAAAABwBBgAlAEwAUwBJAEQARQAAABAJgAEKAEIASQBOAEQARQBWAEUATgBUAFMAAAAAAKAB
CwBPAEIASgBFAEMAVABOAEEATQBFAF8AAAD//xMARABPAEMAVQBNAEUATgBUAEMATwBOAFYARQBS
AFMASQBPAE4AUwAAAP//DABDAFIARQBBAFQARQBOAEUAVwBEAE8AQwAAAAAA//8IAE4ARQBXAF8A
VABBAFMASwAAAAAABQC8AgAAAACeAFnoGAAAAAAAjAC4YygDAAAAAAAAAAAaAAAADAEAAAAAAAAQ
AAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAARYTKe0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAEM4B
AQAAAAAAAAAAAgAYAAAAFAIAAAAAWgQBAAAAAAAIAAAAXAGYAtQAAAAAAAAAAQAAAEwBTAEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAFMAQAAAAAAAAAAAQAAAAgAAAAk
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAMAAQAAAAAA5AAJAgAAJAAIAAAAmAIAACABAAAAAAAAAgAAAPQBBAIAAAAAAAAA
AAAAAAAAAAAA9AH0AQAAAAAAAAAAAAAAAAAAAAAAAAAABAIEAgAAAAAAAAAAAQAAAAIAAAAGAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAAQAEAgAAPAEGCAAAAAADACAAAAAAAOQACQIAACQAEwAAANQAAADVAAAAAAAAABgA
AAAEAFgBKDcDA7hjKAMYAAAAIQAkArAAAAAIAEAAAAAAAIQBAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQADAAEAAAAAABkA
BAAAAAAAAACkAQEAAAAAAAIAAAAAAABAAgAAAAAAAAAEADYAAAAAANKwAB0AABoLAFsEAkn0Acok
AKYaDABHBALL1QAAALQAGg0AHRoRAClAAn6oAiMaEgAdAgAAAAEA+bJiALxlJYV8AgAAEAAAAE8A
AAB8AgAAAQABAAAAAgBqxiL3ewMAAAAAAgCwbG0ATWMlAAAAAAD///8AEwEAADcBAAAB7QACF/ps
AExjJQAX+mwA8YYl7QACDQBPPUxvdHVzIE5vdGVzAAANAE89TG90dXMgTm90ZXMAAIgAQlYEADEu
MABCQwEAA0JBAQAwQkwCAHYCTk5QAF3Gu22rAGXIucZJp5ksEk2Z3iPufVDl9CZfig3h1ATVsCPh
YIHSXSRgF7q+zmrMUAJTTl+jqmch2GxG5Mg7RRhcW6q7hR+oo+RUic36PikARU4EAItxAABNQQgA
Vz7OwTKCRI2AAFBVUlNBRk8Ae51CP3Nw5K/ale5Zfe6aMzlk7nTxHmZbJZFkC1wxIaV1QDuiJGYF
Izm3xeCFAE03Ij4KfC46I1UFHnQLzTBnZIz3nS5rGsEh51Aj2zjdEgEgAADFbG0ATGMlAHATbQAn
ZiWFAAANAE89TG90dXMgTm90ZXMAADEAQ049TG90dXMgTm90ZXMgVGVtcGxhdGUgRGV2ZWxvcG1l
bnQvTz1Mb3R1cyBOb3RlcwAAiABCVgQAMS4wAEJDAQADQkEBADBCTAIAdgJOTlAASU+yNkSo28E5
tnf2J24n8UfuRFdRxcGGIWCUubXm8RoVxD79a+5Xjzg6CWfUKeVrJUhTxYS96i3/6EEL5oX40lUb
jcRbGtJB9sgKnhkLIQBFTgQA714AAE1BCACYtBc8DNecDYAAUFVSU0FGTwDZ6maAoXlGA7letu3t
ADzqo5knuWxBflbrsjsoc4J/0OWnbuJ5J5WLKgo57uRAoYDI+0Sp5S2zgWIb0tm7ksiOLHrwFHjc
149GZGUhZl5eowh1E9TBfT0WbsGoJkVodOwjq2xutWTefEydWRpb1IWoDlAn3cAuNjUuwA52/05p
VbjA7U8iPXjDiSRzkgfMgHyF8Cahbjko0rgVFH1oZArF0RK0XtH9SshgaiCXc9xyCxIAEgDRAAAA
AAAAAAAAAAAAAAAAAAAAACQkRm9ybVBvc3RPcGVuQWN0aW9uACRUeXBlSWNvbgBFeHBpcmVEYXRl
AFJlcGx5RGF0ZQBDb21wb3NlZERhdGUAJFRJVExFACRJTkZPACRXSU5ET1dUSVRMRQAkU2NyaXB0
ACQkU2NyaXB0X08AJCRTY3JpcHROYW1lACQkRm9ybVNjcmlwdAAkJCRGb3JtU2NyaXB0X08AJEJP
RFkAJEFDVElPTlMAJFNDUklQVE9CSl8yMQAkU0NSSVBUT0JKXzIyACRTQ1JJUFRPQkpfMjMAqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqJysrTG90dXNT
Y3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihPcHRpb25zKTowOjc0Ck9wdGlvbiBQ
dWJsaWMKVXNlICJPYmplY3RWYXJpYWJsZXMiIAonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBF
bnZpcm9ubWVudDoyOjU6KEZvcndhcmQpOjA6MQpEZWNsYXJlIFN1YiBFbWFpbE9wZW4KRGVjbGFy
ZSBTdWIgRW1haWxNb2RlQ2hhbmdlCkRlY2xhcmUgU3ViIEVtYWlsU2F2ZShDb250aW51ZSkKRGVj
bGFyZSBTdWIgRW1haWxDbG9zZShDb250aW51ZSkKRGVjbGFyZSBTdWIgU2F2ZURpYWxvZyhTYXZl
ZERvYykKRGVjbGFyZSBTdWIgQ2hlY2tTZWN1cmVNYWlsCkRlY2xhcmUgU3ViIENyZWF0ZU9MRU9i
amVjdApEZWNsYXJlIEZ1bmN0aW9uIElzRW1haWxBdXRob3IoKSBBcyBJbnRlZ2VyCgonKytMb3R1
c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KERlY2xhcmF0aW9ucyk6MDoxMAon
RW1haWxQcm9jZXNzaW5nOiAKCidFbWFpbFByb2Nlc3Npbmc6IAoKCgoKRGltIG5ld25vdGUgQXMg
Tm90ZXNEb2N1bWVudApEaW0gRG9Ob3RDbG9zZSBBcyBWYXJpYW50CkRpbSBDb250aW51ZVNhdmUg
QXMgVmFyaWFudApEaW0gVGFza1JlcGx5IEFzIFZhcmlhbnQKRGltIE9MRU9iamVjdCBBcyBWYXJp
YW50CgoKCgoKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpFbWFp
bE9wZW46MTo4ClN1YiBFbWFpbE9wZW4KICAgICAKICAgICBJZiB1aWRvYy5JblByZXZpZXdQYW5l
IFRoZW4gRXhpdCBTdWIKICAgICBJZiBub3RlIElzIE5vdGhpbmcgVGhlbiBDYWxsIEluc3RhbnRp
YXRlT2JqZWN0VmFyaWFibGVzCiAgICAgCiAgICAgSWYgKG5vdGUuSGFzSXRlbSgiUG9zdGVkRGF0
ZSIpIE9yIG5vdGUuSGFzSXRlbSgiRGVsaXZlcmVkRGF0ZSIpKSBUaGVuCiAgICAgICAgICBJZiB1
aWRvYy5FZGl0TW9kZSA9IEZhbHNlIFRoZW4KICAgICAgICAgICAgICAgRXhpdCBTdWIKICAgICAg
ICAgIEVsc2UKJ0lmIHRoaXMgaXMgYSBtZXNzYWdlIHRoYXQgd2FzIHdyaXR0ZW4gYnkgeW91IG9y
IHlvdXIgbWFpbCBmaWxlLCB3ZSBuZWVkIHRvIHJlbW92ZSBhbnkgb3B0aW9ucyBmaWVsZHMKICAg
ICAgICAgICAgICAgSWYgSXNFbWFpbEF1dGhvcigpIFRoZW4KICAgICAgICAgICAgICAgICAgICBu
b3RlLlJlbW92ZUl0ZW0oIk1haWxPcHRpb25zIikKICAgICAgICAgICAgICAgICAgICBub3RlLlJl
bW92ZUl0ZW0oIlNhdmVPcHRpb25zIikKICAgICAgICAgICAgICAgICAgICBJZiBOb3Qobm90ZS5I
YXNJdGVtKCJTZWN1cmVNYWlsIikpIFRoZW4gQ2hlY2tTZWN1cmVNYWlsCidJZiB0aGlzIGlzIGEg
bWVzc2FnZSB0aGF0IHdhcyBub3Qgd3JpdHRlbiBieSB5b3Ugd2UgZG8gbm90IHByZXNlbnQgdGhl
IG1haWwgZGlhbG9nCididXQgd2UgZG8gd2FudCB0byBmb3JjZSBwcm9jZXNzaW5nIGludG8gUXVl
cnlTYXZlICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgIEVsc2UKICAgICAgICAgICAgICAg
ICAgICBub3RlLk1haWxPcHRpb25zID0gIjAiCiAgICAgICAgICAgICAgICAgICAgbm90ZS5TYXZl
T3B0aW9ucyA9ICIxIgogICAgICAgICAgICAgICBFbmQgSWYKICAgICAgICAgIEVuZCBJZgogICAg
IEVsc2UKICAgICAgICAgIHVpZG9jLkVkaXRNb2RlID0gVHJ1ZQogICAgIEVuZCBJZgogICAgIAog
ICAgIElmIHVpZG9jLklzTmV3RG9jIFRoZW4KICAgICAgICAgIE5ld0RvY3VtZW50ID0gVHJ1ZQog
ICAgICAgICAgbm90ZS5QcmluY2lwYWwgPSBPd25lcgogICAgICAgICAgQ2hlY2tTZWN1cmVNYWls
CiAgICAgICAgICBFZGl0VHlwZSA9IHNlc3Npb24uR2V0RW52aXJvbm1lbnRTdHJpbmcoIk1haWxT
dEVkIikKJ0VkaXRUeXBlIDEgPSBDcmVhdGVTdGF0aW9uZXJ5ICAgICAgICAgIAogICAgICAgICAg
SWYgRWRpdFR5cGUgPSAiMSIgVGhlbgogICAgICAgICAgICAgICBub3RlLnRtcEFjdGlvbiA9ICJT
YXZlQXNTdGF0aW9uZXJ5IgogICAgICAgICAgICAgICBub3RlLklzTWFpbFN0YXRpb25lcnkgPSAx
CiAgICAgICAgICAgICAgIENhbGwgc2Vzc2lvbi5TZXRFbnZpcm9ubWVudFZhcigiTWFpbFN0RWQi
LCAiMCIpCiAgICAgICAgICAgICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMCIKICAgICAgICAgICAg
ICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIxIgogICAgICAgICAgRWxzZQogICAgICAgICAgICAgICBJ
ZiBMZW4oRWRpdFR5cGUpID4gMSBUaGVuCiAgICAgICAgICAgICAgICAgICAgVGFza1JlcGx5ID0g
VHJ1ZQogICAgICAgICAgICAgICAgICAgIENhbGwgc2Vzc2lvbi5TZXRFbnZpcm9ubWVudFZhcigi
TWFpbFN0RWQiLCAiMCIpCiAgICAgICAgICAgICAgICAgICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIx
IgogICAgICAgICAgICAgICAgICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMSIKICAgICAgICAgICAg
ICAgICAgICBub3RlLkFzc2lnblN0YXRlID0gOQogICAgICAgICAgICAgICAgICAgIG5vdGUuRHVl
U3RhdGUgPSA5CiAgICAgICAgICAgICAgICAgICAgQ2FsbCBub3RlLlJlcGxhY2VJdGVtVmFsdWUo
Il9WaWV3SWNvbiIsIDgyKQogICAgICAgICAgICAgICBFbmQgSWYKICAgICAgICAgIEVuZCBJZgog
ICAgIEVsc2UKICAgICAgICAgIE5ld0RvY3VtZW50ID0gRmFsc2UKICAgICAgICAgIElmIG5vdGUu
SGFzSXRlbSgiSXNNYWlsU3RhdGlvbmVyeSIpIFRoZW4KICAgICAgICAgICAgICAgRWRpdFR5cGUg
PSBzZXNzaW9uLkdldEVudmlyb25tZW50U3RyaW5nKCJNYWlsU3RFZCIpCidFZGl0VHlwZSAyID0g
RWRpdFN0YXRpb25lcnkKICAgICAgICAgICAgICAgSWYgRWRpdFR5cGUgPSAiMiIgVGhlbiAKICAg
ICAgICAgICAgICAgICAgICBDYWxsIHNlc3Npb24uU2V0RW52aXJvbm1lbnRWYXIoIk1haWxTdEVk
IiwgIjAiKQogICAgICAgICAgICAgICAgICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMCIKICAgICAg
ICAgICAgICAgICAgICBub3RlLlNhdmVPcHRpb25zID0gIjEiCiAgICAgICAgICAgICAgIEVsc2UK
J0NyZWF0ZSBhIGRvYyBmcm9tIFN0YXRpb25lcnkKICAgICAgICAgICAgICAgICAgICBub3RlLlJl
bW92ZUl0ZW0oIklzTWFpbFN0YXRpb25lcnkiKQogICAgICAgICAgICAgICAgICAgIG5vdGUuUmVt
b3ZlSXRlbSgiTWFpbFN0YXRpb25lcnlOYW1lIikKICAgICAgICAgICAgICAgICAgICBDYWxsIG5v
dGUuUmVwbGFjZUl0ZW1WYWx1ZSgiJFZlcnNpb25PcHQiLCAiNiIpCiAgICAgICAgICAgICAgICAg
ICAgdWlkb2MuR29Ub0ZpZWxkKCJTZW5kVG8iKQogICAgICAgICAgICAgICBFbmQgSWYKICAgICAg
ICAgIEVsc2UKICAgICAgICAgICAgICAgRWRpdFR5cGUgPSBzZXNzaW9uLkdldEVudmlyb25tZW50
U3RyaW5nKCJNYWlsU3RFZCIpCidFZGl0VHlwZSA1ID0gRWRpdE5ld0NvcHkgICAgICAgICAgICAg
ICAKICAgICAgICAgICAgICAgSWYgRWRpdFR5cGUgPSAiNSIgVGhlbiAKICAgICAgICAgICAgICAg
ICAgICBDYWxsIG5vdGUuUmVwbGFjZUl0ZW1WYWx1ZSgiJFZlcnNpb25PcHQiLCAiNiIpCiAgICAg
ICAgICAgICAgICAgICAgbm90ZS50bXBBY3Rpb24gPSAiQ29udmVydE5ld0RvYyIKICAgICAgICAg
ICAgICAgICAgICBub3RlLlJlbW92ZUl0ZW0oIlBvc3RlZERhdGUiKQogICAgICAgICAgICAgICAg
ICAgIENhbGwgc2Vzc2lvbi5TZXRFbnZpcm9ubWVudFZhcigiTWFpbFN0RWQiLCAiMCIpCiAgICAg
ICAgICAgICAgICAgICAgdWlkb2MuUmVsb2FkCiAgICAgICAgICAgICAgICAgICAgdWlkb2MuU2F2
ZQogICAgICAgICAgICAgICAgICAgIHVpZG9jLlJlZnJlc2gKICAgICAgICAgICAgICAgICAgICB1
aWRvYy5SZWZyZXNoSGlkZUZvcm11bGFzCiAgICAgICAgICAgICAgICAgICAgRXhpdCBTdWIKICAg
ICAgICAgICAgICAgRW5kIElmCiAgICAgICAgICBFbmQgSWYKICAgICBFbmQgSWYgCiAgICAgCiAg
ICAgdWlkb2MuUmVsb2FkCiAgICAgdWlkb2MuUmVmcmVzaEhpZGVGb3JtdWxhcwogICAgIApFbmQg
U3ViCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpFbWFpbE1vZGVD
aGFuZ2U6MTo4ClN1YiBFbWFpbE1vZGVDaGFuZ2UKICAgICAKICAgICBJZiBub3RlIElzIE5vdGhp
bmcgVGhlbiBDYWxsIEluc3RhbnRpYXRlT2JqZWN0VmFyaWFibGVzCiAgICAgCidJZiB0aGlzIGlz
IGEgbWVzc2FnZSB0aGF0IHdhcyB3cml0dGVuIGJ5IHlvdSBvciB5b3VyIG1haWwgZmlsZSwgd2Ug
bmVlZCB0byByZW1vdmUgYW55IG9wdGlvbnMgZmllbGRzCiAgICAgSWYgbm90ZS5Gcm9tKDApID0g
T3duZXIgT3Igbm90ZS5Gcm9tKDApID0gc2Vzc2lvbi5Vc2VyTmFtZSBPciBfCiAgICAgbm90ZS5Q
cmluY2lwYWwoMCkgPSBPd25lciBPciBub3RlLlByaW5jaXBhbCgwKSA9IHNlc3Npb24uVXNlck5h
bWUgVGhlbgogICAgICAgICAgbm90ZS5SZW1vdmVJdGVtKCJNYWlsT3B0aW9ucyIpCiAgICAgICAg
ICBub3RlLlJlbW92ZUl0ZW0oIlNhdmVPcHRpb25zIikKICAgICAgICAgIElmIE5vdChub3RlLkhh
c0l0ZW0oIlNlY3VyZU1haWwiKSkgVGhlbiBDaGVja1NlY3VyZU1haWwKJ0lmIHRoaXMgaXMgYSBt
ZXNzYWdlIHRoYXQgd2FzIG5vdCB3cml0dGVuIGJ5IHlvdSB3ZSBkbyBub3QgcHJlc2VudCB0aGUg
bWFpbCBkaWFsb2cKJ2J1dCB3ZSBkbyB3YW50IHRvIGZvcmNlIHByb2Nlc3NpbmcgaW50byBRdWVy
eVNhdmUgICAgICAgICAgICAgICAKICAgICBFbHNlCiAgICAgICAgICBub3RlLk1haWxPcHRpb25z
ID0gIjAiCiAgICAgICAgICBub3RlLlJlbW92ZUl0ZW0oIlNhdmVPcHRpb25zIikKICAgICBFbmQg
SWYKICAgICAKICAgICBJZiB1aWRvYy5FZGl0TW9kZSBUaGVuIHVpZG9jLlJlbG9hZAogICAgIApF
bmQgU3ViCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpFbWFpbFNh
dmU6MTo4ClN1YiBFbWFpbFNhdmUoQ29udGludWUpCiAgICAgCiAgICAgRG9Ob3RDbG9zZSA9IEZh
bHNlCiAgICAgCiAgICAgSWYgbm90ZSBJcyBOb3RoaW5nIFRoZW4gQ2FsbCBJbnN0YW50aWF0ZU9i
amVjdFZhcmlhYmxlcwogICAgIAogICAgIG5vdGUuUmVtb3ZlSXRlbSgiTWFpbE9wdGlvbnMiKQog
ICAgIG5vdGUuUmVtb3ZlSXRlbSgiU2F2ZU9wdGlvbnMiKQogICAgIAogICAgIEFjdGlvbiA9IG5v
dGUudG1wQWN0aW9uKDApCiAgICAgCiAgICAgSWYgbm90ZS5IYXNJdGVtKCJJc01haWxTdGF0aW9u
ZXJ5IikgVGhlbgogICAgICAgICAgSWYgQWN0aW9uIDw+ICJSZW5hbWVTdGF0aW9uZXJ5IiBUaGVu
CiAgICAgICAgICAgICAgIENhbGwgU2F2ZURpYWxvZygiU3RhdGlvbmVyeSIpCiAgICAgICAgICAg
ICAgIElmIENvbnRpbnVlU2F2ZSA9IElEQ0FOQ0VMIFRoZW4gY29udGludWUgPSBGYWxzZQogICAg
ICAgICAgICAgICBJZiBDb250aW51ZVNhdmUgPD4gSURZRVMgVGhlbiAKICAgICAgICAgICAgICAg
ICAgICB1aWRvYy5yZWxvYWQKICAgICAgICAgICAgICAgICAgICBFeGl0IFN1YgogICAgICAgICAg
ICAgICBFbmQgSWYKICAgICAgICAgIEVuZCBJZgogICAgIEVuZCBJZgogICAgIAogICAgIFNlbGVj
dCBDYXNlIEFjdGlvbgogICAgIENhc2UgIlNhdmVBc1N0YXRpb25lcnkiCiAgICAgICAgICBzTmFt
ZSA9IElucHV0Ym94JCgiV2hhdCB3b3VsZCB5b3UgbGlrZSB0byBjYWxsIHRoaXMgU3RhdGlvbmVy
eT8iLCAiU2F2ZSBhcyBTdGF0aW9uZXJ5IiwgIi1VbnRpdGxlZC0iKQogICAgICAgICAgSWYgc05h
bWUgPSAiIiBUaGVuCiAgICAgICAgICAgICAgIENvbnRpbnVlID0gRmFsc2UKICAgICAgICAgICAg
ICAgbm90ZS5SZW1vdmVJdGVtKCJ0bXBBY3Rpb24iKQogICAgICAgICAgICAgICBFeGl0IFN1Ygog
ICAgICAgICAgRW5kIElmCiAgICAgICAgICBJZiBOZXdEb2N1bWVudCBUaGVuCiAgICAgICAgICAg
ICAgIG5vdGUuSXNNYWlsU3RhdGlvbmVyeSA9IDEKICAgICAgICAgICAgICAgbm90ZS5NYWlsU3Rh
dGlvbmVyeU5hbWUgPSBzTmFtZQogICAgICAgICAgICAgICBub3RlLk1haWxPcHRpb25zID0gIjAi
CiAgICAgICAgICAgICAgIG5vdGUuU2F2ZU9wdGlvbnMgPSAiMSIKICAgICAgICAgIEVsc2UKICAg
ICAgICAgICAgICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIwIgogICAgICAgICAgICAgICBTZXQgbmV3
bm90ZSA9IE5ldyBOb3Rlc0RvY3VtZW50KGRiKQogICAgICAgICAgICAgICBDYWxsIG5vdGUuQ29w
eUFsbEl0ZW1zKG5ld25vdGUpCiAgICAgICAgICAgICAgIEl0ZW1MaXN0ID0gbmV3bm90ZS5JdGVt
cwogICAgICAgICAgICAgICBGb3JhbGwgaSBJbiBJdGVtTGlzdAogICAgICAgICAgICAgICAgICAg
IElmIExjYXNlKExlZnQoaS5OYW1lLCAzKSkgPSAidG1wIiBUaGVuIGkuUmVtb3ZlCiAgICAgICAg
ICAgICAgIEVuZCBGb3JhbGwKICAgICAgICAgICAgICAgbmV3bm90ZS5Jc01haWxTdGF0aW9uZXJ5
ID0gMQogICAgICAgICAgICAgICBuZXdub3RlLk1haWxTdGF0aW9uZXJ5TmFtZSA9IHNOYW1lICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgbmV3bm90ZS5Gb3JtID0gIk1lbW8iCiAgICAgICAg
ICAgICAgIG5ld25vdGUuUmVtb3ZlSXRlbSgiUG9zdGVkRGF0ZSIpCiAgICAgICAgICAgICAgIG5l
d25vdGUuUmVtb3ZlSXRlbSgiRGVsaXZlcmVkRGF0ZSIpCiAgICAgICAgICAgICAgIG5ld25vdGUu
U2F2ZSBUcnVlLCBUcnVlCiAgICAgICAgICAgICAgIHdzLlZpZXdSZWZyZXNoCiAgICAgICAgICBF
bmQgSWYKICAgICAgICAgIE1lc3NhZ2Vib3ggIlRoaXMgTWVzc2FnZSBoYXMgYmVlbiBzYXZlZCBh
cyBTdGF0aW9uZXJ5IGluIHlvdXIgRHJhZnRzIGZvbGRlci4gQSBuZXcgbWVzc2FnZSB3aWxsIGJl
IGNyZWF0ZWQgZXZlcnkgdGltZSB5b3Ugb3BlbiB0aGlzIFN0YXRpb25lcnkuIiwgMCwgIlNhdmUg
YXMgU3RhdGlvbmVyeSIKICAgICAgICAgIG5vdGUuUmVtb3ZlSXRlbSgidG1wQWN0aW9uIikKICAg
ICAgICAgIENhbGwgdWlkb2MuY2xvc2UKICAgICAgCQkJIEV4aXQgU3ViCiAgICAgQ2FzZSAiUmVu
YW1lU3RhdGlvbmVyeSIKICAgICAgICAgIE1haWxTdGF0aW9uZXJ5TmFtZSA9IG5vdGUuTWFpbFN0
YXRpb25lcnlOYW1lCiAgICAgICAgICBzTmFtZSA9IElucHV0Ym94JCgiV2hhdCB3b3VsZCB5b3Ug
bGlrZSB0byBjYWxsIHRoaXMgU3RhdGlvbmVyeT8iLCAiU2F2ZSBhcyBTdGF0aW9uZXJ5IiwgTWFp
bFN0YXRpb25lcnlOYW1lKDApKQogICAgICAgICAgSWYgc05hbWUgPSAiIiBUaGVuCiAgICAgICAg
ICAgICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMCIKICAgICAgICAgICAgICAgbm90ZS5SZW1vdmVJ
dGVtKCJ0bXBBY3Rpb24iKQogICAgICAgICAgICAgICBEb05vdENsb3NlID0gVHJ1ZQogICAgICAg
ICAgICAgICBDb250aW51ZSA9IEZhbHNlCiAgICAgICAgICAgICAgIEV4aXQgU3ViCiAgICAgICAg
ICBFbmQgSWYKICAgICAgICAgIG5vdGUuTWFpbFN0YXRpb25lcnlOYW1lID0gc05hbWUKICAgICAg
ICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMCIKICAgICAgICAgIG5vdGUuU2F2ZU9wdGlvbnMgPSAi
MSIKICAgICBDYXNlICJTYXZlQXNEcmFmdCIsICJTYXZlQW5kRmlsZSIsICJTZW5kQW5kRmlsZSIs
ICJDb252ZXJ0TmV3RG9jIgogICAgICAgICAgbm90ZS5NYWlsT3B0aW9ucyA9ICIwIgogICAgICAg
ICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIxIgogICAgIENhc2UgIlNlbmQiCiAgICAgICAgICBub3Rl
Lk1haWxPcHRpb25zID0gIjAiCiAgICAgICAgICBub3RlLlNhdmVPcHRpb25zID0gIjAiCiAgICAg
Q2FzZSAiTWFpbGluZyIKJ1dlIGRvIG5vdCB3YW50IHRvIGRvIGFueXRoaW5nIGlmIG1haWxpbmcg
aXMgaW4gcHJvY2VzcyAobGlrZSBmcm9tIHRoZSBTZW5kIGJ1dHRvbikKICAgICBDYXNlICJDb252
ZXJ0VG9UYXNrIgogICAgICAgICAgbm90ZS5SZW1vdmVJdGVtKCJEZWxpdmVyZWREYXRlIikKICAg
ICAgICAgIG5vdGUuUmVtb3ZlSXRlbSgiUG9zdGVkRGF0ZSIpCiAgICAgICAgICBub3RlLlNlbmRU
byA9ICIiCiAgICAgICAgICBub3RlLkNvcHlUbyA9ICIiCiAgICAgICAgICBub3RlLlNhdmVPcHRp
b25zID0iMSIKICAgICAgICAgIG5vdGUuTWFpbE9wdGlvbnMgPSAiMCIKICAgICAgICAgIG5vdGUu
Rm9ybSA9ICJUYXNrIgogICAgICAgICAgbm90ZS5Bc3NpZ25TdGF0ZSA9IDAKICAgICAgICAgIG5v
dGUuRXhjbHVkZUZyb21WaWV3ID0gIkQiCiAgICAgICAgICBDYWxsIG5vdGUuUmVwbGFjZUl0ZW1W
YWx1ZSgiX1ZpZXdJY29uIiwgMTY4KQogICAgIENhc2UgRWxzZQonSWYgdGhpcyBpcyBhIG1lc3Nh
Z2UgZGlkIG5vdCBvcmlnaW5hdGUgaW4gdGhpcyBtYWlsZmlsZSAoaXQgd2FzIHNlbnQgaGVyZSBh
bmQgdGhlcmVmb3JlIGhhcyBEZWxpdmVyZWREYXRlKSB3ZSBkbyBub3QgcHJlc2VudCB0aGUgbWFp
bCBkaWFsb2cgICAgICAgICAgCiAgICAgICAgICBJZiBub3RlLkhhc0l0ZW0oIkRlbGl2ZXJlZERh
dGUiKSBBbmQgTm90KElzRW1haWxBdXRob3IpIFRoZW4KICAgICAgICAgICAgICAgbm90ZS5NYWls
T3B0aW9ucyA9ICIwIgogICAgICAgICAgICAgICBub3RlLlNhdmVPcHRpb25zID0gIjEiCiAgICAg
ICAgICAgICAgIENhbGwgU2F2ZURpYWxvZygiRG9jdW1lbnQiKQogICAgICAgICAgICAgICBJZiBD
b250aW51ZVNhdmUgPSBJRENBTkNFTCBUaGVuIGNvbnRpbnVlID0gRmFsc2UKICAgICAgICAgICAg
ICAgSWYgQ29udGludWVTYXZlIDw+IElEWUVTIFRoZW4gCiAgICAgICAgICAgICAgICAgICAgdWlk
b2MucmVsb2FkCiAgICAgICAgICAgICAgICAgICAgRXhpdCBTdWIKICAgICAgICAgICAgICAgRW5k
IElmCiAgICAgICAgICBFbmQgSWYKICAgICBFbmQgU2VsZWN0CiAgICAgCiAgICAgbm90ZS5SZW1v
dmVJdGVtKCJ0bXBBY3Rpb24iKQogICAgIElmIG5vdGUuSGFzSXRlbSgiJFZlcnNpb25PcHQiKSBU
aGVuIENhbGwgbm90ZS5SZXBsYWNlSXRlbVZhbHVlKCIkVmVyc2lvbk9wdCIsICIwIikKICAgICAK
ICAgICAnSWYgTm90KG5vdGUuSGFzSXRlbSgiQXV0aG9yTGlzdCIpKSBUaGVuIFNldCBpdGVtID0g
TmV3IE5vdGVzSXRlbShub3RlLCAiQXV0aG9yTGlzdCIsIG5vdGUuRnJvbSwgQVVUSE9SUykKICAg
ICAKICAgICB1aWRvYy5SZWxvYWQKICAgICAKRW5kIFN1YgonKytMb3R1c1NjcmlwdCBEZXZlbG9w
bWVudCBFbnZpcm9ubWVudDoyOjI6RW1haWxDbG9zZToxOjgKU3ViIEVtYWlsQ2xvc2UoQ29udGlu
dWUpCiAgICAgCiAgICAgSWYgRG9Ob3RDbG9zZSBUaGVuCiAgICAgICAgICBEb05vdENsb3NlID0g
RmFsc2UKICAgICAgICAgIENvbnRpbnVlID0gRmFsc2UKJ1RoaXMgYmFja3Mgb3V0IGFueXRoaW5n
IHlvdSBkaWQgcHJldmlvdXNseSB0byBNYWlsT3B0aW9ucyBhbmQgU2F2ZU9wdGlvbnMgYW5kIHdp
bGwgZm9yY2UgeW91IGJhY2sgaW50byBRdWVyeVNhdmUgbmV4dCB0aW1lIHlvdSB0cnkgdG8gZXhp
dCAgICAgICAgICAKICAgICAgICAgIG5vdGUuUmVtb3ZlSXRlbSgiTWFpbE9wdGlvbnMiKQogICAg
ICAgICAgbm90ZS5SZW1vdmVJdGVtKCJTYXZlT3B0aW9ucyIpCiAgICAgICAgICB1aWRvYy5yZWxv
YWQKICAgICBFbmQgSWYKICAgICAKICAgICBJZiBUYXNrUmVwbHkgVGhlbgogICAgICAgICAgU2V0
IG5hbWVsb29rdXAgPSBOZXcgTm90ZXNOYW1lKG5vdGUuU2VuZFRvKDApKQogICAgICAgICAgTWVz
c2FnZWJveCAiTm90aWZpY2F0aW9uIGhhcyBiZWVuIHNlbnQgdG8gIiAmIG5hbWVsb29rdXAuQ29t
bW9uICYgIi4iLCAwLCAiVGFzayBNZXNzYWdlIgogICAgIEVuZCBJZgogICAgIApFbmQgU3ViCicr
K0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpTYXZlRGlhbG9nOjE6OApT
dWIgU2F2ZURpYWxvZyhTYXZlZERvYykKICAgICAKICAgICBDb250aW51ZVNhdmUgPSBNZXNzYWdl
Ym94KCJEbyB5b3Ugd2lzaCB0byBzYXZlIHRoaXMgIiAmIFNhdmVkRG9jICYgIj8iLCBNQl9ZRVNO
T0NBTkNFTCwgIlNhdmUgIiAmIFNhdmVkRG9jKSAKICAgICBTZWxlY3QgQ2FzZSBDb250aW51ZVNh
dmUKICAgICBDYXNlIElEQ0FOQ0VMCiAgICAgICAgICBub3RlLk1haWxPcHRpb25zID0gIjAiCidU
aGlzIHdpbGwgZm9yY2UgdXMgaW50byBxdWVyeXNhdmUgbmV4dCB0aW1lIC0gdGhpcyB0aW1lIGl0
IHdpbGwgc2V0IGNvbnRpbnVlID0gZmFsc2Ugc28gbm8gc2F2ZSB3aWxsIG9jY3VyICAgICAgICAg
IAogICAgICAgICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIxIgogICAgIENhc2UgSUROTwogICAgICAg
ICAgbm90ZS5TYXZlT3B0aW9ucyA9ICIwIgogICAgIENhc2UgSURZRVMKICAgICAgICAgIG5vdGUu
U2F2ZU9wdGlvbnMgPSAiMSIKICAgICBFbmQgU2VsZWN0CiAgICAgCkVuZCBTdWIKJysrTG90dXNT
Y3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6MjoyOkNoZWNrU2VjdXJlTWFpbDoxOjgKU3Vi
IENoZWNrU2VjdXJlTWFpbAogICAgIAonSWYgU2VjdXJlTWFpbCA9IDEgaW4gbm90ZXMuaW5pIGFs
bCBtYWlsIGdldHMgU2lnbmVkIGFuZCBFbmNyeXB0ZWQgYW5kIHRoZSB1c2VyIGlzIHVuYWJsZSB0
byBvdmVycmlkZSBpdAogICAgIG5vdGUuU2VjdXJlTWFpbCA9IENzdHIoc2Vzc2lvbi5HZXRFbnZp
cm9ubWVudFN0cmluZygiU2VjdXJlTWFpbCIsIFRydWUpKQogICAgIElmIG5vdGUuU2VjdXJlTWFp
bCgwKSA9ICIxIiBUaGVuCiAgICAgICAgICBDYWxsIG5vdGUuUmVwbGFjZUl0ZW1WYWx1ZSgiU2ln
biIsICIxIikKICAgICAgICAgIENhbGwgbm90ZS5SZXBsYWNlSXRlbVZhbHVlKCJFbmNyeXB0Iiwg
IjEiKQogICAgIEVuZCBJZiAgICAgCiAgICAgCkVuZCBTdWIKJysrTG90dXNTY3JpcHQgRGV2ZWxv
cG1lbnQgRW52aXJvbm1lbnQ6MjoyOkNyZWF0ZU9MRU9iamVjdDoxOjgKU3ViIENyZWF0ZU9MRU9i
amVjdAogICAgIERpbSBzUHJvZ2lkIEFzIFN0cmluZwogICAgIAogICAgIE9uIEVycm9yIFJlc3Vt
ZSBOZXh0CiAgICAgCiAgICAgc1Byb2dpZCA9IG5vdGUufiRPTEVPYmpQcm9nSWQoMCkKICAgICAK
J2lmIHRoaXMgaXMgYSBuZXcgZG9jdW1lbnQsIHRoZW4gd2UgbmVlZCB0byBjcmVhdGUgdGhlIG9s
ZSBvYmplY3QgICAgIAogICAgIElmIChOZXdEb2N1bWVudCkgVGhlbiAgICAgCiAgICAgICAgICBu
b3RlLk9yaWdpbmFsRWRpdG9yID0gc1Byb2dpZAogICAgICAgICAgdWlkb2MuR290b0ZpZWxkKG5v
dGUufiRPTEVPYmpGaWVsZCgwKSkKICAgICAgICAgIAogICAgICAgICAgQ2FsbCB1aWRvYy5DcmVh
dGVPYmplY3QoIk9MRU9iamVjdCIsIHNQcm9nSWQgLCIiKQogICAgICAgICAgSWYgKEVyciA9IDAp
IFRoZW4gCiAgICAgICAgICAgICAgIENhbGwgd3MuRGlhbG9nQm94KCIoT0xFTWFpbEZpZWxkcyki
LFRydWUsVHJ1ZSkKICAgICAgICAgIEVsc2UKICAgICAgICAgICAgICAgbm90ZS50bXB1c2VPTEUg
PSAiIgogICAgICAgICAgICAgICB1aWRvYy5SZWZyZXNoSGlkZUZvcm11bGFzCiAgICAgICAgICBF
bmQgSWYKICAgICBFbHNlCid0aGUgdXNlciBpcyByZWFkaW5nL2VkaXRpbmcgYW4gZXhpc3Rpbmcg
ZG9jdW1lbnQKJ2lmIHRoZSBPcmlnaW5hbEVkaXRvciA9IE1haWxFZGl0b3IsIGRpc3BsYXkgdGhl
IGRvY3VtZW50IHVzaW5nIHRoYXQgRWRpdG9yCidvdGhlcndpc2UsIGxldCBOb3RlcyBkaXNwbGF5
IHRoZSBkb2N1bWVudAogICAgICAgICAgSWYgTGNhc2Uobm90ZS5PcmlnaW5hbEVkaXRvcigwKSkg
PSBMY2FzZShzUHJvZ0lkKSBUaGVuCiAgICAgICAgICAgICAgIHVpZG9jLmVkaXRtb2RlID0gVHJ1
ZQogICAgICAgICAgICAgICBTZXQgT0xFT2JqZWN0ID0gdWlkb2MuR2V0T2JqZWN0KCJPTEVPYmpl
Y3QiKQogICAgICAgICAgICAgICBJZiBOb3QoSXNvYmplY3QoT0xFT2JqZWN0KSkgVGhlbgondGhl
cmUgaXMgbm8gb2JqZWN0IGZvciBzb21lIHJlYXNvbiAtdGhpcyBzaG91bGQgYmUgcmFyZSEhICAg
ICAgIAogICAgICAgICAgICAgICAgICAgIHVpZG9jLkVkaXRNb2RlID0gVHJ1ZQogICAgICAgICAg
ICAgICAgICAgIG5vdGUuT3JpZ2luYWxFZGl0b3IgPSBzUHJvZ2lkCiAgICAgICAgICAgICAgICAg
ICAgdWlkb2MuR290b0ZpZWxkKG5vdGUufiRPTEVPYmpGaWVsZCgwKSkKICAgICAgICAgICAgICAg
ICAgICBDYWxsIHVpZG9jLkNyZWF0ZU9iamVjdCgiT0xFT2JqZWN0IixzUHJvZ0lkLCIiKSAgICAg
IAogICAgICAgICAgICAgICAgICAgIEV4aXQgU3ViICAgIAogICAgICAgICAgICAgICBFbmQgSWYK
ICAgICAgICAgIEVsc2UKJ3RoZSB1c2VyIGhhcyBhIGRpZmZlcmVudCBlZGl0b3IKICAgICAgICAg
ICAgICAgbm90ZS50bXBVc2VPTEUgPSAiIgogICAgICAgICAgICAgICB1aWRvYy5SZWZyZXNoSGlk
ZUZvcm11bGFzICAgICAgICAgICAgICAgCiAgICAgICAgICBFbmQgSWYKICAgICBFbmQgSWYgICAg
IApFbmQgU3ViCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MTpJc0Vt
YWlsQXV0aG9yOjE6OApGdW5jdGlvbiBJc0VtYWlsQXV0aG9yKCkgQXMgSW50ZWdlcgogICAgIElm
IE5vdChub3RlIElzIE5vdGhpbmcpIFRoZW4KICAgICAgICAgIElmIG5vdGUuRnJvbSgwKSA9IE93
bmVyIE9yIG5vdGUuRnJvbSgwKSA9IHNlc3Npb24uVXNlck5hbWUgT3IgXwogICAgICAgICAgbm90
ZS5QcmluY2lwYWwoMCkgPSBPd25lciBPciBub3RlLlByaW5jaXBhbCgwKSA9IHNlc3Npb24uVXNl
ck5hbWUgVGhlbgogICAgICAgICAgICAgICBJc0VtYWlsQXV0aG9yID0gVHJ1ZQogICAgICAgICAg
RWxzZQogICAgICAgICAgICAgICBJc0VtYWlsQXV0aG9yID0gRmFsc2UKICAgICAgICAgIEVuZCBJ
ZgogICAgIEVsc2UKICAgICAgICAgIElzRW1haWxBdXRob3IgPSBGYWxzZQogICAgIEVuZCBJZgpF
bmQgRnVuY3Rpb24AAQAsAUxTT0IDABQAZW4AAAQAXACIC0gAAACYDuQOAAAAAAQAGAUEDQAAAAAk
AKwAGAAAAAwBdAFUAG0AAAAAABEAAAAYAAgOmAKYAkgBSAHYA+gNcARwBAAAAACwAOwGGADMBgAA
AACsBqwG8AHwAUADCA7cBmgLAAAAAAkAAAAEB/QMAAAAAAAAAAD0DPQMJAgkCAAAAAAAAAAAJAeU
DAQHrAtoCGgIAAAAADwHRAgAAAAAAAAAAAUAAAAkBQQNJAUkBQAAAAAAAAAAAAAAAOgFBA0AAAAA
AAAAAAAAAAAAAAAAAAAAAHgIeAgACgAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMA6A4AAAAAOAAIACoAMQA1AEUARgAwADAA
QwAAAAEAbAADAE4ARQBXAAAAgAAGAEQARQBMAEUAVABFAAAAvAckAQoASQBOAEkAVABJAEEATABJ
AFoARQAAACoAiAAJAFQARQBSAE0ASQBOAEEAVABFAAAAWAEGAE8AQgBKAEUAQwBUAAAAIxo8AQAA
AAAkCNAADwBPAGIAagBlAGMAdABWAGEAcgBpAGEAYgBsAGUAcwAAAOgADwBPAEIASgBFAEMAVABW
AEEAUgBJAEEAQgBMAEUAUwAAALABCQBFAE0AQQBJAEwATwBQAEUATgAAAKwDDwBFAE0AQQBJAEwA
TQBPAEQARQBDAEgAQQBOAEcARQAAAJgCCQBFAE0AQQBJAEwAUwBBAFYARQAAACgCCABDAE8ATgBU
AEkATgBVAEUAAAAFffQBCgBFAE0AQQBJAEwAQwBMAE8AUwBFAAAACH3YAgoAUwBBAFYARQBEAEkA
QQBMAE8ARwAAAHQHjAEIAFMAQQBWAEUARABEAE8AQwAAAABLXAIPAEMASABFAEMASwBTAEUAQwBV
AFIARQBNAEEASQBMAAAA1AEPAEMAUgBFAEEAVABFAE8ATABFAE8AQgBKAEUAQwBUAAAACAINAEkA
UwBFAE0AQQBJAEwAQQBVAFQASABPAFIAAABcBAcATgBFAFcATgBPAFQARQAAADwCDQBOAE8AVABF
AFMARABPAEMAVQBNAEUATgBUAAAAeAIGACUATABTAFgAQgBFAAAApRrIAg0ATgBPAFQARQBTAEQA
QQBUAEEAQgBBAFMARQAAAPgCCgBEAE8ATgBPAFQAQwBMAE8AUwBFAAAAOAccBAwAQwBPAE4AVABJ
AE4AVQBFAFMAQQBWAEUAAABmALACCQBUAEEAUwBLAFIARQBQAEwAWQAAAEQDCQBPAEwARQBPAEIA
SgBFAEMAVAAAAOQDBQBVAEkARABPAEMAAADIAw0ASQBOAFAAUgBFAFYASQBFAFcAUABBAE4ARQAA
AAgDBABOAE8AVABFAAAAJxrsBBoASQBOAFMAVABBAE4AVABJAEEAVABFAE8AQgBKAEUAQwBUAFYA
QQBSAEkAQQBCAEwARQBTAAAAnAtYAwcASABBAFMASQBUAEUATQAAAHQDCgBQAG8AcwB0AGUAZABE
AGEAdABlAAAACS2UAw0ARABlAGwAaQB2AGUAcgBlAGQARABhAHQAZQAAAJgECABFAEQASQBUAE0A
TwBEAEUAAAAjGnAGCgBSAEUATQBPAFYARQBJAFQARQBNAAAACH0IBwsATQBhAGkAbABPAHAAdABp
AG8AbgBzAAAAAAQLAFMAYQB2AGUATwBwAHQAaQBvAG4AcwAAADgECgBTAGUAYwB1AHIAZQBNAGEA
aQBsAAAAzAt8BAsATQBBAEkATABPAFAAVABJAE8ATgBTAAAAQAQBADAAAADABAsAUwBBAFYARQBP
AFAAVABJAE8ATgBTAAAAZAQBADEAAACwBAgASQBTAE4ARQBXAEQATwBDAAAAoADYBAsATgBFAFcA
RABPAEMAVQBNAEUATgBUAAAAoAYJAFAAUgBJAE4AQwBJAFAAQQBMAAAADAUFAE8AVwBOAEUAUgAA
AFgGCABFAEQASQBUAFQAWQBQAEUAAAC8CJQFBwBTAEUAUwBTAEkATwBOAAAAbAUMAE4ATwBUAEUA
UwBTAEUAUwBTAEkATwBOAAAAjAQ8BRQARwBFAFQARQBOAFYASQBSAE8ATgBNAEUATgBUAFMAVABS
AEkATgBHAAAAiwJUBQgATQBhAGkAbABTAHQARQBkAAAAvAy8BQkAVABNAFAAQQBDAFQASQBPAE4A
AAAYBhAAUwBhAHYAZQBBAHMAUwB0AGEAdABpAG8AbgBlAHIAeQAAAEtE5AUQAEkAUwBNAEEASQBM
AFMAVABBAFQASQBPAE4ARQBSAFkAAABEBwgJEQBTAEUAVABFAE4AVgBJAFIATwBOAE0ARQBOAFQA
VgBBAFIAAAAABgsAQQBTAFMASQBHAE4AUwBUAEEAVABFAAAAzAYIAEQAVQBFAFMAVABBAFQARQAA
AAAxQAYQAFIARQBQAEwAQQBDAEUASQBUAEUATQBWAEEATABVAEUAAADIAOgGCQBOAE8AVABFAFMA
SQBUAEUATQAAAEAICQBfAFYAaQBlAHcASQBjAG8AbgAAAJgGEABJAHMATQBhAGkAbABTAHQAYQB0
AGkAbwBuAGUAcgB5AAAA0QBEBwEAMgAAAPAGEgBNAGEAaQBsAFMAdABhAHQAaQBvAG4AZQByAHkA
TgBhAG0AZQAAABrTJAcLACQAVgBlAHIAcwBpAG8AbgBPAHAAdAAAALgHAQA2AAAAHAcJAEcATwBU
AE8ARgBJAEUATABEAAAAfAcGAFMAZQBuAGQAVABvAAAAOAVQCAEANQAAAFgHDQBDAG8AbgB2AGUA
cgB0AE4AZQB3AEQAbwBjAAAAqAcGAFIARQBMAE8AQQBEAAAA3gBoBwQAUwBBAFYARQAAALwHDAgH
AFIARQBGAFIARQBTAEgAAADQBxMAUgBFAEYAUgBFAFMASABIAEkARABFAEYATwBSAE0AVQBMAEEA
UwAAAKgJBABGAFIATwBNAAAAMRooCAgAVQBTAEUAUgBOAEEATQBFAAAA6ADkBwYAQQBDAFQASQBP
AE4AAAAIfWAIEABSAGUAbgBhAG0AZQBTAHQAYQB0AGkAbwBuAGUAcgB5AAAAEAx4CQoAUwB0AGEA
dABpAG8AbgBlAHIAeQAAAABLtAsIAEkARABDAEEATgBDAEUATAAAADgOwAgFAEkARABZAEUAUwAA
AAQKBQBTAE4AQQBNAEUAAAD//ywAVwBoAGEAdAAgAHcAbwB1AGwAZAAgAHkAbwB1ACAAbABpAGsA
ZQAgAHQAbwAgAGMAYQBsAGwAIAB0AGgAaQBzACAAUwB0AGEAdABpAG8AbgBlAHIAeQA/AAAAGgns
CBIAUwBhAHYAZQAgAGEAcwAgAFMAdABhAHQAaQBvAG4AZQByAHkAAAADv0wJCgAtAFUAbgB0AGkA
dABsAGUAZAAtAAAAEgEgCQkAdABtAHAAQQBjAHQAaQBvAG4AAABYCRIATQBBAEkATABTAFQAQQBU
AEkATwBOAEUAUgBZAE4AQQBNAEUAAAAeAJAJAgBEAEIAAAAAMbgJDABDAE8AUABZAEEATABMAEkA
VABFAE0AUwAAAA5LoAkIAEkAVABFAE0ATABJAFMAVAAAACV9IAoFAEkAVABFAE0AUwAAANgJAQBJ
AAAAxAkEAE4AQQBNAEUAAAAjMTwLAwB0AG0AcAAAAOgJBgBSAEUATQBPAFYARQAAAEu8LAsEAEYA
TwBSAE0AAABLvPgJBABNAGUAbQBvAAAALLwMDAIAVwBTAAAAoA/UCwsAVgBJAEUAVwBSAEUARgBS
AEUAUwBIAAAAWAuDAFQAaABpAHMAIABNAGUAcwBzAGEAZwBlACAAaABhAHMAIABiAGUAZQBuACAA
cwBhAHYAZQBkACAAYQBzACAAUwB0AGEAdABpAG8AbgBlAHIAeQAgAGkAbgAgAHkAbwB1AHIAIABE
AHIAYQBmAHQAcwAgAGYAbwBsAGQAZQByAC4AIABBACAAbgBlAHcAIABtAGUAcwBzAGEAZwBlACAA
dwBpAGwAbAAgAGIAZQAgAGMAcgBlAGEAdABlAGQAIABlAHYAZQByAHkAIAB0AGkAbQBlACAAeQBv
AHUAIABvAHAAZQBuACAAdABoAGkAcwAgAFMAdABhAHQAaQBvAG4AZQByAHkALgAAAJALBQBDAEwA
TwBTAEUAAAB0CwsAUwBhAHYAZQBBAHMARAByAGEAZgB0AAAAoAsLAFMAYQB2AGUAQQBuAGQARgBp
AGwAZQAAADwNCwBTAGUAbgBkAEEAbgBkAEYAaQBsAGUAAADkDAQAUwBlAG4AZAAAANQR/AsHAE0A
YQBpAGwAaQBuAGcAAAAwDA0AQwBvAG4AdgBlAHIAdABUAG8AVABhAHMAawAAAOgLBgBTAEUATgBE
AFQATwAAAIQAUAwGAEMATwBQAFkAVABPAAAAEn04DAQAVABhAHMAawAAAEu8hAwPAEUAWABDAEwA
VQBEAEUARgBSAE8ATQBWAEkARQBXAAAABA0BAEQAAABsDAgARABvAGMAdQBtAGUAbgB0AAAAgqXI
DAoATgBBAE0ARQBMAE8ATwBLAFUAUAAAADhG//8JAE4ATwBUAEUAUwBOAEEATQBFAAAAtA0eAE4A
bwB0AGkAZgBpAGMAYQB0AGkAbwBuACAAaABhAHMAIABiAGUAZQBuACAAcwBlAG4AdAAgAHQAbwAg
AAAAhADcDAYAQwBPAE0ATQBPAE4AAAB6AXgNAQAuAAAAaA0MAFQAYQBzAGsAIABNAGUAcwBzAGEA
ZwBlAAAAAABEDRkARABvACAAeQBvAHUAIAB3AGkAcwBoACAAdABvACAAcwBhAHYAZQAgAHQAaABp
AHMAIAAAAKQNAQA/AAAAkA4OAE0AQgBfAFkARQBTAE4ATwBDAEEATgBDAEUATAAAAAAAyA0FAFMA
YQB2AGUAIAAAAIgNBABJAEQATgBPAAAAAAAgDgoAUwBFAEMAVQBSAEUATQBBAEkATAAAAAAA3A0E
AFMAaQBnAG4AAAAAAP//BwBFAG4AYwByAHkAcAB0AAAAQA4HAFMAUABSAE8ARwBJAEQAAAD8DQ0A
JABPAEwARQBPAEIASgBQAFIATwBHAEkARAAAAGAODgBPAFIASQBHAEkATgBBAEwARQBEAEkAVABP
AFIAAAAAALQODAAkAE8ATABFAE8AQgBKAEYASQBFAEwARAAAAAAA//8MAEMAUgBFAEEAVABFAE8A
QgBKAEUAQwBUAAAAAAB4DgkATwBMAEUATwBiAGoAZQBjAHQAAAD//wkARABJAEEATABPAEcAQgBP
AFgAAAD//w8AKABPAEwARQBNAGEAaQBsAEYAaQBlAGwAZABzACkAAADMDgkAVABNAFAAVQBTAEUA
TwBMAEUAAAD//wkARwBFAFQATwBCAEoARQBDAFQAAAAFAJwOAAAAAH9bnZoYAAAAAACwAGg6VQIA
AAAAAAAAAAgAEACwAMwG1AAAAAAAAAABAAAAUAhQCAAAAAAAAAAAAAAAAAAAAAAAAAAAUAhQCAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAwAAAAQAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAQAEgB7AbsAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAALAAAALAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIABAA8AEAABABAAAAAAAABgAAAOABuAwAAAAAiAuI
CwAAAAAAAAAA8Au4DAAAAAAAAAAA4AHgATQLJAwAAAAAAAAAAAAAAAAAAAAAAQAAAAwAAADlAwAA
cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAAQA0CwAAKAEAAAAAAAAIABAAmAIAAEABAAAAAAAAAQAAAIgCiAIAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAiAKIAgAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABQAAABdCAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAMAAQAAAAAAKAEAAAAAAAAIABAAQAMAAFwBAAAAAAAAAQAAADADMAMAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAMAMwAwAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAkAAADfCAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAMAAQAAAAAAeAEAAAAAAAAIABAA2AO8BpABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAABuCQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgA
EABwBOgNtAEAAAAAAAABAAAANA40DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADQONA4AAAAAEwAAAL8JAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAQAKwGAADYAQEAAAAAAAEAAAAI
BQgFAAAAAAAAAAAAAAAACAUIBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAALAAAACgsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAADAAEAAAAAANgBAQAAAAAAGgAAACwC//8AAAAAEAAEAOgFAAAMAgAA
AAAAAAYAAACMB1gMAAAAAAAMWAzMCcwJAAAAAIwHjAfIB7wLAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAQUEyntLmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAIA
GAW0BQAA6AUAAAIAAQAAAAAAEgAUAAAAAAD//wkCAAAAAI0EAAAAACQFGAUAAAAAAAAGAAIAAAAJ
AiQFCQIkBQkC6AUZABAAAAB4CAQNQAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFBMp7S5pEL9dAN0BEYa3AAAAAAAAAAAA
AAAAAAAAAGQAAAAAAAAAAAAAAAAAAAACABgFeAYAAAAAAAACAAEAAAAAABIAFAAAAAAA//8JAgAA
AAASBAAAAADoBRgFAAAAAAAABgADAAAACQLoBQkC6AUGCAYIGQADABAAvAYAAPgBCQIAACQFAwAQ
AMwGCA5gAgAACAAAAAMAEADcBgAAfAIAABgAAAADABAA7AZIC5wCAAAoAAAAAwAQAEgLAAC0AgAA
OAAAABwABADABgAAAwBAACQHrAvMAgAAFgDACdwCynYAABkAHQAEALAHAAADAEAAPAeUDPwCCQIA
ACQFIQAEAJwAAAAIAEAAJAhECAwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAFADIBwAASAMBAAAAAACSBAAAAAAk
BRgFAAAAAAAABAACAAAAAQAJAiQFBggZABYArAyYA3k8AAAZABIAFADMCbwLsAMKAAAAAACRBAAA
AAAkBRgFAAAAAAAABAACAAAACgAJAiQFBggZABYABAggBDrGAAAZABYAAABEBLqlAAAZABYAtAlo
BKU+AAAZABwABACoCgAAAwBAAEQIAACABAEAFgB0CZwEdmUAABkAHAAEAJgKAAADAEAAaAgAALQE
BgADAAIAAAAAAMQEAAAAAAAAHQAEAJAHAAADAEAArAsAANwECQIAAHgIEAAAAAAKAADwBAAAAAAA
AAMAAAA4CRALAAAAAAAAAAAAAAAAAAAAADgJOAkAAAAAEAsQC4AJgAkAAAAAAAAAAAAAAAAAAAAA
AAAAAAEUEyntLmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAIAGAUI
CQAAJAUAAAIAAQAAAAAAEgAUAAAAAAD//wkCAAAAALIEAAAAAHgIGAUAAAAAAAAEAAEAAAAJAngI
CQJ4CBkAEgAUAIAJAAAQBQYIAAAAALYEAAAAAHgIGAUAAAAAAAAFAAMAAAAGCAkCeAgGCIEIFgAA
AFgFxGkAABkAFgDICpgF90EAABkAEgAUABALAADABQoAAAAAALQEAAAAAHgIGAUAAAAAAAAGAAQA
AAAKAAkCeAgGCAAAgQgZABYA1AroBfjLAAAZABYABAsEBpk5AAAZABIAFAC8CwAAHAYJggAAAACX
BAAAAAAkBRgFAAAAAAAABgADAAAACQIACgkCJAUGCAAAGQAQAAAABA0AAEQGAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRQT
Ke0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAgAYBZAKAAB4CAAA
AgABAAAAAAASABQAAAAAAP//CQIAAAAAKAQAAAAAAAoYBQAAAAAAAAkABQAAAAkCAAoJAgAKCQok
BQYIAACBCBYARA70BoB7AAAZABYA+ApIB4oNAAAZABYAyAxcB3UDAAAZABYAAABsByobAAAZABYA
dA6AB6g1AAAZABYANAysB6sDAAAZABEAEAUAAAAAvAcGAKYEAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAMAAgCICyQM1AcAAAAAAAAZABkABAAAAGgLaAssCAEAAAAAAAIAAAAAAABAAgAAAAAAAAAEAAAA
6A0AAEQIAQAAAAAABgAAAAAAGEACAAAAAAAAAAMAAgDwCwAAVAgAABAAAAAWAEAMJAnbHwAAGQAd
AAQAoAcAAAMAQACUDAAAUAkJAgAA6AUSABQAAAwAAFwJCgAAAAAAnQQAAAAAJAUYBQAAAAAAAAYA
AwAAAAoACQIkBQkCJAWBCBkAAwACACQMuAx8CQAAIAAAABEAEAVYDFgMlAkAAH4EAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAUAAgC4DAAApAkAADAAAAAWAAAArAmrAwAAGQAWAAAAyAmtDQAAGQAWANQM
3AnlAwAAGQASABQAAAAAAFwHAQAAAAAAlAQAAAAAJAUYBQAAAAAAAAYABAAAAAEACQIkBQEIAQiB
CBkAHAAEALAGAAADAEAA9AwAAPwJAAAWAOAMCAqrvwAAGQAWAAAAMAuPBwAAGQADAAIAAAAAACQJ
AABgAAAAFgBoDtgLtw0AABkAFgBQDuwLkw8AABkAFgAAABAM5LAAABkAHQAEAIgKAAADAEAAAAAA
AFQMCQIAAAQNEAAAAAAAAABwDAAAAAAAAAEAAADEDcQNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAMQNxA0AAAAAAAAAAAAAAAAAAAAAAAAAABMUEyntLmkQv10A3QERhrcAAAAAAAAAAAAAAAAA
AAAAZAAAAAAAAAAAAAAAAAAAAAIAGAWUDQAAAAoAAAIAAQAAAAAAEgAUAAAAAAD//wkCAAAAAGUG
AAAAAAQNGAUAAAAAAAAFAAIAAAAJAgQNCQIEDQYIEQAQBQAAAADMDAYAWAYAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABAAAAAgOAABIDQEAAAAAAAMAAAAAAAhAAgAAAAAAAAAEAAAAAAAAAHwNAQAAAAAA
BwAAAAAAHEACAAAAAAAAABYAAACMDWLaAAAZAAMAAgAAAAAAzA0GAAAAAAAWAFwO4A0T8gAAGQAW
AIwOAA67dAAAGQAWAAAAJA6g+AAAGQAWAIAORA4VrgAAGQAWAAAAfA5GfgAAGQAWAAAAuA7ZagAA
GQAWAAAA0A7WfgAAGQAEAIwLAAAAADoAABoDANKMAB0AABokAE4EB1AQBzgBABwaJQBHJAeBxTgE
ACk8ByMaJwBLJAcsjAd9XAMjSyQHLIwHfXgDI8M4fQAaKABOBAdQvAeDuDgKABopABwaKgA6XwAa
LAApcAQjODUAGi0ASyQHLMgHfcwDIxouAEskByzIB33oAyMaLwBLJAcsjAd9BAQjoDgEAClAAyMa
MgA6HQAaMwBLJAdR+Ad9PASlGjQASyQHUQQIfWAEpRo1ABo2ABo3ADoOABo4AE4EB1G8B4KlGjkA
GjsATgQHUBAIOPwAGjwAWyQIhKcCGj0ASyQHUTAIR0QIpRo+AClAAyMaPwBeUAhLaAgsOAl9QAWL
AiOlGkEASlAIfWAEuDhKABpCAEskB1FoCX1wBaUaQwBLJAdRdAmGpRpEAEtoCCyACX1ABX08BIsC
IxpFAEskB1H4B308BKUaRgBLJAdRBAh9YASlGkcAOm8AGkgAXlAIBiWGujhcABpJAFvcBoKlGkoA
S2gILIAJfUAFfTwEiwIjGksASyQHUQQIfWAEpRpMAEskB1H4B31gBKUaTQBLJAdRtAmOCaUaTgBL
JAdRwAmOCaUaTwBLJAcszAl9XAaOUiMxGlAAGlEAGlIAOj4BGlMAWyQIhacCGlQASyQHLIwHfXQG
IziTABpVAF5QCEtoCCw4CX1ABYsCI6UaVwBKUAh9nAa4ODIAGlgAS2gILIAJfUAFfTwEiwIjGlkA
SyQHUfgHfTwEpRpaAEskB1EECH1gBKUaWwA6OwAaXQBLJAcsyAd9dAYjGl4ASyQHLMgHfaQGIxpf
AEskByzMCX3QBn3sBiMxGmAATgQHVMgKfQwHJxphABpiADqPABpjAF5QCEtoCCw4CX1ABYsCI6Ua
ZQBKUAh9IAe4OGkAGmYASyQHLMwJfdAGfewGIzEaZwBLJAdRaAl9KAelGmgASyQHLMgHfVwDIxpp
AEtoCCyACX1ABX08BIsCIxpqAE4EB1TUCicaawBOBAdU4AonGmwATgQHVOwKJxptAE4EB1T4Cica
bgAcGm8AGnAAGnEAGnMATgQHVNQKJxp0AE4EB1T4CicadgAdGnoARyQHgcU4BAApPAcjGn4ASyQH
UwQLhSVHRAi4SyQHUwQLhSVLaAgtEAsjuMNLJAdTMAiFJUdECLjDSyQHUzAIhSVLaAgtEAsjuMM4
NQAafwBLJAcsyAd9zAMjGoAASyQHLMgHfegDIxqBAEskByyMB30EBCOgOAQAKUADIxqEADodABqF
AEskB1H4B308BKUahgBLJAcsyAd96AMjGocAGokATgQHULwHOAcATgQHVNQKJxqLAB0ajwBbvAaD
pRqRAEckB4HFOAQAKTwHIxqTAEskByzIB33MAyMalABLJAcsyAd96AMjGpYAXjQLSyQHU2gJhSWl
GpgASyQHLIwHfXQGIzhKABqZAEo0C33oB7s4OgAamgApmAJ9EAgjGpsAR8wGflgLuDgFAF3gAYOl
GpwAR8wGfngLuzgOABqdAE4EB1TUCicangAcGp8AGqAAGqEAGqMASjQLGqQAMn1wBbg4eQExGqUA
XogLfWQIfcQIffAIgIAGSJulGqYASogLfYQAuDgZABqnAF3gAYOlGqgASyQHLMgHfQwJIxqpABwa
qgAaqwBHJAg4OAAarABLJAdRdAmGpRqtAEskB1GYC0qIC6UargBLJAdR+Ad9PASlGq8ASyQHUQQI
fWAEpRqwADrMABqxAEskB1EECH08BKUasgBbrAYrJAVbrAskphqzAEskByy8C1usBosCIxq0AF7w
C0usBi0ADCOlGrUASvALNSQMLgAatgBGJAxVNAwgCAAAk48DAwZKk5MGSZN9vAm4OAcARiQMVEAM
Jxq3ADckDNL/GrgAS6wGUXQJhqUauQBLrAZRmAtKiAulGroAS6wGUUwMfewJpRq7AEusBizIB31c
AyMavABLrAYsyAd9eAMjGr0AS6wGLFgMhISLAiMxGr4ATpQMVKAMJxq/ABrAAH0kCpuFfcQImwYH
GsEASyQHLMgHfQwJIxrCAE4EB1SsDCcawwAcGzoYAhrEADJ96Ae4OI8AMRrFAF64DEskB1CYC6Ua
xgBeiAt9ZAh9xAiFZbgMAZuAgAZIm6UaxwBKiAt9hAC4OC4AGsgASyQHUfgHfTwEpRrJAEskByzI
B30MCSMaygBbvAaCpRrLAF3gAYOlGswAHBrNABrOAEskB1GYC0qIC6UazwBLJAdR+Ad9PASlGtAA
SyQHUQQIfWAEpRs6fgEa0QAyfUALuDkYADJ9XAu4ORAAMn14C7g5CAAyfSgHuDgfADEa0gBLJAdR
+Ad9PASlGtMASyQHUQQIfWAEpRs6PAEa1AAyfZQLuDgfADEa1QBLJAdR+Ad9PASlGtYASyQHUQQI
fTwEpRs6EgEa1wAyfaQLuDgFADEbOgIBGtkAMn24C7g4iQAxGtoASyQHLMgHfXgDIxrbAEskByzI
B31cAyMa3ABLJAdRyAx9hAClGt0ASyQHUdQMfYQApRreAEskB1EECH1gBKUa3wBLJAdR+Ad9PASl
GuAASyQHUUwMfQAMpRrhAEskB1G0CYWlGuIASyQHUeAMfTQMpRrjAEskByzMCX1cBpCoACMxGzpu
ADEa5gBLJAcsjAd9eAMjKXAEI6DEOFQAGucASyQHUfgHfTwEpRroAEskB1EECH1gBKUa6QApmAJ9
PAwjGuoAR8wGflgLuDgFAF3gAYOlGusAR8wGfngLuzgOABrsAE4EB1TUCica7QAcGu4AGu8AGvIA
SyQHLMgHfQwJIxrzAEskByyMB33QBiM4DgBLJAcszAl90AZ9PAQjMRr3AE4EB1TUCica+QAdGv0A
R7wGODQAGv4AW7wGg6Ua/wBdiAKDpRoBAUskByzIB33MAyMaAgFLJAcsyAd96AMjGgMBTgQHVNQK
JxoEARoGAUfcBjgyABoHAVv0DCsEDUskB1PIDIUmBggAAJskphoIAX2IDEv0DC3EDSO/feAMv5uF
fegMmwYHGgkBGgsBHRoPAVvMBn0IDUkwA799QA2/m374DX1sDUkwA7+bBiulGhABR8wGGhEBMn5Y
C7g4HwAxGhIBSyQHUfgHfTwEpRoUAUskB1EECH1gBKUbOjsAGhUBMn4YDrg4EgAxGhYBSyQHUQQI
fTwEpRs6HgAaFwEyfngLuDgSADEaGAFLJAdRBAh9YASlGzoBADEaGwEdGiABSyQHUSgOS2gILDgJ
fQQEhCObpRohAUskB1MoDoUlfWAEuDgiABoiAUskByzMCX2oDX1gBCMxGiMBSyQHLMwJfbgNfWAE
IzEaJAEaJgEdGisBDAAABAAaLQFeNA5LJAdTRA6FJaUaMAFHJAg4dQAaMQFLJAdRUA5KNA6lGjIB
TgQHVMgKSyQHU1wOhSYACAAAnCcaNAFOBAdUaA59ZA5eNA59hAAnGjUBFIWyOBUAGjYBTpQMVHQO
fZQOgoInGjcBOhoAGjgBSyQHUYAOfYQApRo5AU4EB1T4CicaOgEaOwE6sgAaPwFLJAdTUA6FJiAI
AACTBkmTSjQOkwZJk7g4dwAaQAFOBAdRvAeCpRpBAVvsBk4EB1OMDn1kDiWmGkIBW+wGBiGgOEYA
GkQBTgQHUbwHgqUaRQFLJAdRUA5KNA6lGkYBTgQHVMgKSyQHU1wOhSYACAAAnCcaRwFOBAdUaA59
ZA5eNA59hAAnGkgBHBpJARpKAToaABpMAUskB1GADn2EAKUaTQFOBAdU+AonGk4BGk8BGlABHRpT
AUckB4HFoDhiABpVAUskB1MEC4UlR0QIuEskB1MEC4UlS2gILRALI7jDSyQHUzAIhSVHRAi4w0sk
B1MwCIUlS2gILRALI7jDOA8AGlYBYQIAAISlGlcBOgwAGlgBYQIAAIWlGlkBGloBOgwAGlsBYQIA
AIWlGlwBGl0BHQIAAAABAMSxYgC8ZSWFfAIAABAAAABPAAAAfAIAAAEAAQAAAAIAasYi93sDAAAA
AAIAsGxtAE1jJQAAAAAA////ABMBAAA3AQAAAe0AAhf6bABMYyUAF/psAPGGJe0AAg0ATz1Mb3R1
cyBOb3RlcwAADQBPPUxvdHVzIE5vdGVzAACIAEJWBAAxLjAAQkMBAANCQQEAMEJMAgB2Ak5OUABd
xrttqwBlyLnGSaeZLBJNmd4j7n1Q5fQmX4oN4dQE1bAj4WCB0l0kYBe6vs5qzFACU05fo6pnIdhs
RuTIO0UYXFuqu4UfqKPkVInN+j4pAEVOBACLcQAATUEIAFc+zsEygkSNgABQVVJTQUZPAHudQj9z
cOSv2pXuWX3umjM5ZO508R5mWyWRZAtcMSGldUA7oiRmBSM5t8XghQBNNyI+CnwuOiNVBR50C80w
Z2SM950uaxrBIedQI9s43RIBIAAAxWxtAExjJQBwE20AJ2YlhQAADQBPPUxvdHVzIE5vdGVzAAAx
AENOPUxvdHVzIE5vdGVzIFRlbXBsYXRlIERldmVsb3BtZW50L089TG90dXMgTm90ZXMAAIgAQlYE
ADEuMABCQwEAA0JBAQAwQkwCAHYCTk5QAElPsjZEqNvBObZ39iduJ/FH7kRXUcXBhiFglLm15vEa
FcQ+/WvuV484Ogln1CnlayVIU8WEveot/+hBC+aF+NJVG43EWxrSQfbICp4ZCyEARU4EAO9eAABN
QQgAmLQXPAzXnA2AAFBVUlNBRk8A2epmgKF5RgO5Xrbt7QA86qOZJ7lsQX5W67I7KHOCf9Dlp27i
eSeViyoKOe7kQKGAyPtEqeUts4FiG9LZu5LIjix68BR43NePRmRlIWZeXqMIfyyGH6vpGADj+Swy
rpHW9QdneCSTO8rzdNCrHYoCCeY6GiW5HBP9m4rwixSjHduefwYfvUsPIglb6/BnCi1xTHA2jYIR
UcpZXB4snVgMs7cJX1IlqwhAaSMNBrzstQQFAAUANAAAAAAAAAAAAAAAAAAAAAAAAAAkU2NyaXB0
TGliACRTY3JpcHRMaWJfTwAkVElUTEUAJEZsYWdzACRQdWJsaWNBY2Nlc3MAqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqJysrTG90dXNTY3JpcHQgRGV2ZWxv
cG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihPcHRpb25zKTowOjc0Ck9wdGlvbiBQdWJsaWMgICAKJysr
TG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihGb3J3YXJkKTowOjEKRGVj
bGFyZSBTdWIgSW5pdGlhbGl6ZQpEZWNsYXJlIFN1YiBJbnN0YW50aWF0ZU9iamVjdFZhcmlhYmxl
cwpEZWNsYXJlIFN1YiBHZXRDYWxlbmRhck93bmVyCkRlY2xhcmUgU3ViIE1hcmtUZW1wRmllbGRz
KGRvYyBBcyBOb3Rlc0RvY3VtZW50KQpEZWNsYXJlIFN1YiBDcmVhdGVEZWZhdWx0Q2FsZW5kYXJQ
cm9maWxlCkRlY2xhcmUgU3ViIHdJbml0RGVmYXVsdFNldHRpbmdzCkRlY2xhcmUgU3ViIFRJTUVH
ZXROb3Rlc0Zyb21MUyh2TFMgQXMgVmFyaWFudCwgZHROb3RlcyBBcyBOb3Rlc0RhdGVUaW1lKQoK
JysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6Mjo1OihEZWNsYXJhdGlvbnMp
OjA6MTAKJ09iamVjdFZhcmlhYmxlczogCgonRnJvbnQgZW5kIGNsYXNzZXMgLT4gd2UgZGVjbGFy
ZSB0aGVzZSBhcyB2YXJpYW50IHNvIHRoYXQgYmFja2VuZCBzZXJ2ZXIgdGFza3Mgd2lsbCBvcGVy
YXRlIGNvcnJlY3RseQpEaW0gd3MgQXMgVmFyaWFudApEaW0gdWlkb2MgQXMgVmFyaWFudAoKJ0Jh
Y2sgZW5kIGNsYXNzZXMKRGltIHNlc3Npb24gQXMgTm90ZXNTZXNzaW9uCkRpbSBkYiBBcyBOb3Rl
c0RhdGFiYXNlCkRpbSBub3RlIEFzIE5vdGVzRG9jdW1lbnQKRGltIHByb2ZpbGUgQXMgTm90ZXNE
b2N1bWVudApEaW0gbm90aWNlIEFzIE5vdGVzRG9jdW1lbnQKRGltIHBhcmVudG5vdGUgQXMgTm90
ZXNEb2N1bWVudApEaW0gcGFyZW50IEFzIE5vdGVzRG9jdW1lbnQKRGltIGNoaWxkIEFzIE5vdGVz
RG9jdW1lbnQKRGltIGRvY3VtZW50cyBBcyBOb3Rlc0RvY3VtZW50Q29sbGVjdGlvbgpEaW0gY2hp
bGRyZW4gQXMgTm90ZXNEb2N1bWVudENvbGxlY3Rpb24KRGltIGRhdGUxIEFzIE5vdGVzRGF0ZVRp
bWUKRGltIGRhdGUyIEFzIE5vdGVzRGF0ZVRpbWUKRGltIGRhdGVJdGVtIEFzIE5vdGVzRGF0ZVRp
bWUKRGltIGl0ZW0gQXMgTm90ZXNJdGVtCkRpbSBOYW1lTG9va3VwIEFzIE5vdGVzTmFtZQoKJ0dl
bmVyYWwgUHVycG9zZSBjbGFzc2VzCkRpbSBPd25lciBBcyBTdHJpbmcKRGltIE5ld0RvY3VtZW50
IEFzIEludGVnZXIKCidDbGllbnQgRGlmZmVyZW5jaWF0aW9uCkRpbSBJc1dlYkNsaWVudCBBcyBW
YXJpYW50CgolSU5DTFVERSAib3JnY29uc3QubHNzIgolSU5DTFVERSAibHNjb25zdC5sc3MiCgoK
CgoKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpJbml0aWFsaXpl
OjE6MTAKU3ViIEluaXRpYWxpemUKICAgICAKRW5kIFN1YgonKytMb3R1c1NjcmlwdCBEZXZlbG9w
bWVudCBFbnZpcm9ubWVudDoyOjI6SW5zdGFudGlhdGVPYmplY3RWYXJpYWJsZXM6MTo4ClN1YiBJ
bnN0YW50aWF0ZU9iamVjdFZhcmlhYmxlcwogICAgIFNldCBzZXNzaW9uID0gTmV3IE5vdGVzU2Vz
c2lvbgogICAgIFNldCBkYiA9IHNlc3Npb24uQ3VycmVudERhdGFiYXNlCiAgICAgCiAgICAgR2V0
Q2FsZW5kYXJPd25lcgogICAgIAogICAgIElmIFR5cGVuYW1lKHVpZG9jKSA8PiAiRU1QVFkiIFRo
ZW4KICAgICAgICAgIFNldCBub3RlID0gdWlkb2MuRG9jdW1lbnQKICAgICAgICAgIHVpZG9jLkF1
dG9SZWxvYWQgID0gRmFsc2UKICAgICBFbmQgSWYKRW5kIFN1YgonKytMb3R1c1NjcmlwdCBEZXZl
bG9wbWVudCBFbnZpcm9ubWVudDoyOjI6R2V0Q2FsZW5kYXJPd25lcjoxOjgKU3ViIEdldENhbGVu
ZGFyT3duZXIKICAgICAKICAgICBPbiBFcnJvciBSZXN1bWUgTmV4dAogICAgIAogICAgIElmIChw
cm9maWxlIElzIE5vdGhpbmcpIFRoZW4gU2V0IHByb2ZpbGUgPSBkYi5HZXRQcm9maWxlRG9jdW1l
bnQoIkNhbGVuZGFyUHJvZmlsZSIpICAgICAKICAgICBJZiBFcnIgPiAwIFRoZW4KICAgICAgICAg
IEVyciA9IDAgICAgIAogICAgICAgICAgQ2FsbCBDcmVhdGVEZWZhdWx0Q2FsZW5kYXJQcm9maWxl
CiAgICAgRW5kIElmCiAgICAgCiAgICAgT24gRXJyb3IgR290byBFcnJvclJvdXRpbmUKICAgICBJ
ZiBwcm9maWxlLk93bmVyKDApID0gIiIgVGhlbiBDYWxsIENyZWF0ZURlZmF1bHRDYWxlbmRhclBy
b2ZpbGUKICAgICAKICAgICBPd25lciA9IHByb2ZpbGUuT3duZXIoMCkKICAgICAKICAgICBFeGl0
IFN1YgogICAgIApFcnJvclJvdXRpbmU6CiAgICAgTWVzc2FnZWJveCBFcnJvciAmICIgKGNyZWF0
aW5nIENhbGVuZGFyIFByb2ZpbGUpIgogICAgIEV4aXQgU3ViCkVuZCBTdWIKJysrTG90dXNTY3Jp
cHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6MjoyOk1hcmtUZW1wRmllbGRzOjE6OApTdWIgTWFy
a1RlbXBGaWVsZHMoZG9jIEFzIE5vdGVzRG9jdW1lbnQpCidNYXJrIGFsbCB0ZW1wb3JhcnkgYW5k
IGNvbXB1dGUgZm9yIGRpc3BsYXkgZmllbGRzIHN1Y2ggdGhhdCB0aGV5IHdpbGwgbm90IGJlIHNh
dmVkIHRvIGRpc2sgICAgIAogICAgIE9uIEVycm9yIFJlc3VtZSBOZXh0CiAgICAgaXRlbWxpc3Qg
PSBkb2MuSXRlbXMKICAgICBGb3JhbGwgbiBJbiBpdGVtbGlzdAogICAgICAgICAgSWYgTGNhc2Uo
TGVmdChuLk5hbWUsIDMpKSA9ICJ0bXAiIE9yIExjYXNlKExlZnQobi5OYW1lLCA0KSkgPSAiZGlz
cCIgVGhlbiBuLlNhdmVUb0Rpc2sgPSBGYWxzZQogICAgIEVuZCBGb3JhbGwgICAgIAogICAgIAog
ICAgIElmIE5vdCBJc1dlYkNsaWVudCBUaGVuIEV4aXQgU3ViCiAgICAgCiAgICAgJ3JlbW92ZSB3
ZWIgQ0dJIHZhcmlhYmxlIHNvIHRoYXQgdGhleSB3aWxsIGdldCB1cGRhdGVkIG9uIHRoZSBuZXh0
IGRvYyByZWFkCiAgICAgQ2FsbCBkb2MuUmVtb3ZlSXRlbSgiJCRRdWVyeU9wZW5BZ2VudCIpCiAg
ICAgQ2FsbCBkb2MuUmVtb3ZlSXRlbSgiJCRRdWVyeVNhdmVBZ2VudCIpCiAgICAgQ2FsbCBkb2Mu
UmVtb3ZlSXRlbSgiUGF0aF9JbmZvIikKICAgICBDYWxsIGRvYy5SZW1vdmVJdGVtKCJRdWVyeV9T
dHJpbmciKQogICAgIAogICAgICdpZiB0aGUgbWFpbCBvcHRpb24gZmllbGRzIGFyZSBhbGwgZGVm
YXVsdCB2YWx1ZXMsIHJlbW92ZSB0aGVtCiAgICAgSWYgKGRvYy5JbXBvcnRhbmNlKDApID0gIjIi
IEFuZCBkb2MuRGVsaXZlcnlQcmlvcml0eSgwKSA9ICJOIiBBbmQgZG9jLkRlbGl2ZXJ5UmVwb3J0
KDApID0gIkIiIEFuZCBfCiAgICAgZG9jLkZvcm0oMCkgPD4gIlRhc2siKSBUaGVuCiAgICAgICAg
ICBDYWxsIGRvYy5SZW1vdmVJdGVtKCJJbXBvcnRhbmNlIikKICAgICAgICAgIENhbGwgZG9jLlJl
bW92ZUl0ZW0oIkRlbGl2ZXJ5UHJpb3JpdHkiKQogICAgICAgICAgQ2FsbCBkb2MuUmVtb3ZlSXRl
bSgiRGVsaXZlcnlSZXBvcnQiKQogICAgIEVuZCBJZgpFbmQgU3ViCicrK0xvdHVzU2NyaXB0IERl
dmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpDcmVhdGVEZWZhdWx0Q2FsZW5kYXJQcm9maWxlOjE6
OApTdWIgQ3JlYXRlRGVmYXVsdENhbGVuZGFyUHJvZmlsZQolUkVNCiAqVGhpcyByb3V0aW5lIGNy
ZWF0ZXMgYSBjYWxlbmRhciBwcm9maWxlIGRvY3VtZW50CiAgY29udGFpbmcgZGVmYXVsdCB2YWx1
ZXMgZm9yIHJlcXVpcmVkIGZpZWxkcwolRU5EIFJFTQogICAgIAondGhlIGdsb2JhbCB2YXJpYWJs
ZSAicHJvZmlsZSIgaXMgYSBwcm9maWxlIGRvY3VtZW50IGFscmVhZHkKJ3dlIG5lZWQgdG8gYWRk
IHRoZSBmaWVsZHMgdG8gaXQKICAgICBwcm9maWxlLkZvcm0gPSAiQ2FsZW5kYXJQcm9maWxlIgog
ICAgIENhbGwgcHJvZmlsZS5Db21wdXRlV2l0aEZvcm0oRmFsc2UsIEZhbHNlKQogICAgIAogICAg
IElmIElzV2ViQ2xpZW50IFRoZW4KICAgICAgICAgIENhbGwgd0luaXREZWZhdWx0U2V0dGluZ3Mo
KQogICAgIEVsc2UKICAgICAgICAgIENhbGwgcHJvZmlsZS5TYXZlKFRydWUsVHJ1ZSxUcnVlKQog
ICAgIEVuZCBJZgpFbmQgU3ViCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50
OjI6Mjp3SW5pdERlZmF1bHRTZXR0aW5nczoxOjgKU3ViIHdJbml0RGVmYXVsdFNldHRpbmdzCiAg
ICAgcHJvZmlsZS53RGVmYXVsdE1haWxPcHQgPSAiMiIKICAgICBwcm9maWxlLndFbmFibGVUcmFz
aEljb24gPSAiMSIKICAgICBwcm9maWxlLndDYWxHcmlkVHlwZSA9ICIzIgogICAgIAogICAgIHBy
b2ZpbGUud0VuYWJsZU5BQnMgPSAiMCIKICAgICBwcm9maWxlLndFbmFibGVGYXZvcml0ZXMgPSAi
MCIKICAgICAKICAgICBwcm9maWxlLndJc0ZvbGRlcjEgPSAiMSIKICAgICBwcm9maWxlLndJc0Zv
bGRlcjIgPSAiMSIKICAgICBwcm9maWxlLndJc0ZvbGRlcjMgPSAiMSIKICAgICBwcm9maWxlLndJ
c0ZvbGRlcjQgPSAiMSIKICAgICBwcm9maWxlLndJc0ZvbGRlcjUgPSAiMSIKICAgICBwcm9maWxl
LndJc0ZvbGRlcjYgPSAiMSIKICAgICAKICAgICBwcm9maWxlLk5vdGVzTmFiMSA9ICJuYW1lcy5u
c2YiCiAgICAgCiAgICAgQ2FsbCBwcm9maWxlLlNhdmUoVHJ1ZSxUcnVlLFRydWUpCkVuZCBTdWIK
JysrTG90dXNTY3JpcHQgRGV2ZWxvcG1lbnQgRW52aXJvbm1lbnQ6MjoyOlRJTUVHZXROb3Rlc0Zy
b21MUzoxOjgKU3ViIFRJTUVHZXROb3Rlc0Zyb21MUyh2TFMgQXMgVmFyaWFudCwgZHROb3RlcyBB
cyBOb3Rlc0RhdGVUaW1lKQogICAgIFNldCBkdE5vdGVzID0gTmV3IE5vdGVzRGF0ZVRpbWUoc0Rh
dGVUaW1lKQogICAgIAogICAgIElmIElzZGF0ZSh2TFMpIFRoZW4KICAgICAgICAgIGR0Tm90ZXMu
TFNMb2NhbFRpbWUgPSB2TFMKICAgICBFbmQgSWYKRW5kIFN1YgABACwBTFNPQgMAFABlbgAABADK
ABUDeAAAAPgccBsEAAAAAADMAcgJAAAAACQAAAAYADgAsAGIAFQAVgAAAAAAmQAAAAQAaBpoCyga
8AcIGtAIaBe4CSgWoAQIGcAISBiwBugZBADIFwgEiBjgCMgYnABIGtAHqBmwCGgaAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAANgB
yAnYAdgBAAAAABAIEAgAAAAAnALICQAAAAAAAAAAOAU4BQAAAAAAAAAA0AbQBvAI8AgAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AwD8DwAAAABwAQgAKgAxADUARgA5ADMAMgBDAAAAqwZsAAMATgBFAFcAAACAAAYARABFAEwARQBU
AEUAAAAAGjwBCgBJAE4ASQBUAEkAQQBMAEkAWgBFAAAAGkbEAAkAVABFAFIATQBJAE4AQQBUAEUA
AAAgAwYATwBCAEoARQBDAFQAAABLBMwCAAAAAAgtGAIaAEkATgBTAFQAQQBOAFQASQBBAFQARQBP
AEIASgBFAEMAVABWAEEAUgBJAEEAQgBMAEUAUwAAAAYH7AAQAEcARQBUAEMAQQBMAEUATgBEAEEA
UgBPAFcATgBFAFIAAAAaWhABDgBNAEEAUgBLAFQARQBNAFAARgBJAEUATABEAFMAAAAlfRwBAwBE
AE8AQwAAAFABDQBOAE8AVABFAFMARABPAEMAVQBNAEUATgBUAAAALAIGACUATABTAFgAQgBFAAAA
SpNYAg0ATgBPAFQARQBTAEQAQQBUAEEAQgBBAFMARQAAAOABHABDAFIARQBBAFQARQBEAEUARgBB
AFUATABUAEMAQQBMAEUATgBEAEEAUgBQAFIATwBGAEkATABFAAAAI4UMAhQAVwBJAE4ASQBUAEQA
RQBGAEEAVQBMAFQAUwBFAFQAVABJAE4ARwBTAAAAjzxMAhIAVABJAE0ARQBHAEUAVABOAE8AVABF
AFMARgBSAE8ATQBMAFMAAABwDLgCAwBWAEwAUwAAAHwCBwBEAFQATgBPAFQARQBTAAAAaAINAE4A
TwBUAEUAUwBEAEEAVABFAFQASQBNAEUAAADgAgIAVwBTAAAADFCcAgUAVQBJAEQATwBDAAAAEAMH
AFMARQBTAFMASQBPAE4AAACoAgwATgBPAFQARQBTAFMARQBTAFMASQBPAE4AAACGqJQDAgBEAEIA
AAA7hswDBABOAE8AVABFAAAAK3z8AgcAUABSAE8ARgBJAEwARQAAAGwDBgBOAE8AVABJAEMARQAA
AIgMRAQKAFAAQQBSAEUATgBUAE4ATwBUAEUAAAAUCDgDBgBQAEEAUgBFAE4AVAAAAAhRKAQFAEMA
SABJAEwARAAAAIQDCQBEAE8AQwBVAE0ARQBOAFQAUwAAALwDFwBOAE8AVABFAFMARABPAEMAVQBN
AEUATgBUAEMATwBMAEwARQBDAFQASQBPAE4AAAAYBAgAQwBIAEkATABEAFIARQBOAAAAAJWkAwUA
RABBAFQARQAxAAAAAAQFAEQAQQBUAEUAMgAAAEwGCABEAEEAVABFAEkAVABFAE0AAAAjfeQDBABJ
AFQARQBNAAAAGo5YBQkATgBPAFQARQBTAEkAVABFAE0AAAC0BAoATgBBAE0ARQBMAE8ATwBLAFUA
UAAAADQP8AQJAE4ATwBUAEUAUwBOAEEATQBFAAAAYAQFAE8AVwBOAEUAUgAAAKwECwBOAEUAVwBE
AE8AQwBVAE0ARQBOAFQAAADoBAsASQBTAFcARQBCAEMATABJAEUATgBUAAAAgAQMAG8AcgBnAGMA
bwBuAHMAdAAuAGwAcwBzAAAASxQgBhIATwBSAFMAXwBNAFMARwBUAFkAUABFAF8ASQBOAFYASQBU
AEUAAABLFFQGAQBJAAAAHAUWAE8AUgBTAF8ATQBTAEcAVABZAFAARQBfAFIARQBTAEMASABFAEQA
VQBMAEUAAAASfSQFAQBVAAAAmAUSAE8AUgBTAF8ATQBTAEcAVABZAFAARQBfAEMAQQBOAEMARQBM
AAAAEn1gBQEAQwAAANgFFgBPAFIAUwBfAE0AUwBHAFQAWQBQAEUAXwBEAEUATABFAEcAQQBUAEkA
TgBHAAAASxSgBQEARAAAABgGGABPAFIAUwBfAE0AUwBHAFQAWQBQAEUAXwBTAFQAQQBUAFUAUwBV
AFAARABBAFQARQAAAHgSuAYBAFMAAADgBRgATwBSAFMAXwBNAFMARwBUAFkAUABFAF8AQwBPAE4A
RgBJAFIATQBBAFQASQBPAE4AAAB9bCwHAQBOAAAAgAYZAE8AUgBTAF8ATQBTAEcAVABZAFAARQBf
AEMATwBVAE4AVABFAFIAUgBFAEoARQBDAFQAAACIBgEASgAAAOwGEgBPAFIAUwBfAE0AUwBHAFQA
WQBQAEUAXwBBAEMAQwBFAFAAVAAAABq6wAYBAEEAAAD0BhIATwBSAFMAXwBNAFMARwBUAFkAUABF
AF8AUgBFAEoARQBDAFQAAAAyAGAHAQBSAAAAlAcUAE8AUgBTAF8ATQBTAEcAVABZAFAARQBfAEQA
RQBMAEUARwBBAFQARQAAABKEVAgBAEwAAADABxMATwBSAFMAXwBNAFMARwBUAFkAUABFAF8AQwBP
AFUATgBUAEUAUgAAAFgHAQBUAAAAJAcUAE8AUgBTAF8ATQBTAEcAVABZAFAARQBfAFAARQBOAEMA
SQBMAEkATgAAAJuA9AcBAFAAAACMBxIATwBSAFMAXwBTAFQAQQBUAFUAUwBfAEkATgBWAEkAVABF
AEQAAADjADAIAQAxAAAA/AcTAE8AUgBTAF8AUwBUAEEAVABVAFMAXwBBAEMAQwBFAFAAVABFAEQA
AAC4CAEAMgAAACgIEwBPAFIAUwBfAFMAVABBAFQAVQBTAF8AUABFAE4AQwBJAEwASQBOAAAAyAcB
ADMAAAAICRMATwBSAFMAXwBTAFQAQQBUAFUAUwBfAEQARQBDAEwASQBOAEUARAAAAIwIAQA0AAAA
XAgSAE8AUgBTAF8AUwBUAEEAVABVAFMAXwBSAEUATQBPAFYARQBEAAAAABZsCgEANQAAANwJDgBP
AFIAUwBfAFMAVABBAFQARQBfAE4ATwBOAEUAAAAaCLQJAQAwAAAAWAkUAE8AUgBTAF8AUwBUAEEA
VABFAF8ATwBSAEkARwBJAE4AQQBUAE8AUgAAAMQI5AgTAE8AUgBTAF8AUwBUAEEAVABFAF8ARABF
AEwARQBHAEEAVABFAEQAAAAUChIATwBSAFMAXwBTAFQAQQBUAEUAXwBEAEUATABFAEcAQQBUAEUA
AAAAOGAJDwBPAFIAUwBfAFMAVABBAFQARQBfAEcAUgBPAFUAUAAAACwJDgBPAFIAUwBfAFMAVABB
AFQARQBfAFIATwBPAE0AAAAAAIwJEgBPAFIAUwBfAFMAVABBAFQARQBfAFIARQBTAE8AVQBSAEMA
RQAAAEYsCAoBADYAAADoCRIATwBSAFMAXwBPAFAAVABJAE8ATgBBAEwAXwBGAEEATABTAEUAAABG
LKAKEQBPAFIAUwBfAE8AUABUAEkATwBOAEEATABfAFQAUgBVAEUAAAA4ChEATwBSAFMAXwBJAFQA
RQBNAF8AQwBBAEwARQBOAEQAQQBSAAAARAoCAEMAMAAAACkBEAsNAE8AUgBTAF8ASQBUAEUATQBf
AFQATwBEAE8AAAB4CgIAVAAwAAAACEugCw4ATwBSAFMAXwBJAFQARQBNAF8AQwBBAEwATABTAAAA
Dn2sCgIASAAwAAAAGi/ACxAATwBSAFMAXwBJAFQARQBNAF8AUABMAEEATgBOAEUAUgAAAKcC1AoC
AFAAMAAAABo0HAsQAE8AUgBTAF8ASQBUAEUATQBfAEEARABEAFIARQBTAFMAAAAjOOAKAgBEADAA
AAABMlgMEABPAFIAUwBfAEkAVABFAE0AXwBOAE8AVABFAFAAQQBEAAAAOtNUDQIATgAwAAAAmQD4
CxQATwBSAFMAXwBJAFQARQBNAF8AQQBOAE4ASQBWAEUAUgBTAEEAUgBZAAAAAUs8CwIAQQAwAAAA
QAFoCwwAQwBTAF8ATQBPAE4AVABIAF8ASgBBAE4AAABefEgLAwBKAGEAbgAAAJQLDABDAFMAXwBN
AE8ATgBUAEgAXwBGAEUAQgAAABpEdAsDAEYAZQBiAAAAhAwMAEMAUwBfAE0ATwBOAFQASABfAE0A
QQBSAAAAKXgYDAMATQBhAHIAAADMCwwAQwBTAF8ATQBPAE4AVABIAF8AQQBQAFIAAABkAewLAwBB
AHAAcgAAAHgMDABDAFMAXwBNAE8ATgBUAEgAXwBNAEEAWQAAAKYaSAwDAE0AYQB5AAAAtAwNAEMA
UwBfAE0ATwBOAFQASABfAEoAVQBOAEUAAAAoDAQASgB1AG4AZQAAAABmpAwNAEMAUwBfAE0ATwBO
AFQASABfAEoAVQBMAFkAAAAsDQQASgB1AGwAeQAAABpW1AwMAEMAUwBfAE0ATwBOAFQASABfAEEA
VQBHAAAApRoADQMAQQB1AGcAAAA4DQ0AQwBTAF8ATQBPAE4AVABIAF8AUwBFAFAAVAAAAKgNBABT
AGUAcAB0AAAA/A1oDQwAQwBTAF8ATQBPAE4AVABIAF8ATwBDAFQAAAB8E+AMAwBPAGMAdAAAANgN
DABDAFMAXwBNAE8ATgBUAEgAXwBOAE8AVgAAAAEaDA0DAE4AbwB2AAAAtA4MAEMAUwBfAE0ATwBO
AFQASABfAEQARQBDAAAAIBWUDQMARABlAGMAAAB8DQsAbABzAGMAbwBuAHMAdAAuAGwAcwBzAAAA
gA4HAFYAXwBFAE0AUABUAFkAAAAgDgYAVgBfAE4AVQBMAEwAAAAacdAOCQBWAF8ASQBOAFQARQBH
AEUAUgAAAJwOBgBWAF8ATABPAE4ARwAAADQewA0IAFYAXwBTAEkATgBHAEwARQAAABp29A0IAFYA
XwBEAE8AVQBCAEwARQAAAAgaCA4KAFYAXwBDAFUAUgBSAEUATgBDAFkAAAATpTwOBgBWAF8ARABB
AFQARQAAAAwsUA4IAFYAXwBTAFQAUgBJAE4ARwAAAH3YQBAKAFYAXwBEAEkAUwBQAEEAVABDAEgA
AAAAGpwRBwBWAF8ARQBSAFIATwBSAAAAaA4JAFYAXwBCAE8ATwBMAEUAQQBOAAAAVA8JAFYAXwBW
AEEAUgBJAEEATgBUAAAAfA8KAFYAXwBJAFUATgBLAE4ATwBXAE4AAAAOABgPCABWAF8AVQBOAEkA
UwBUAFIAAAAcF+wOCwBWAF8AQwBMAEkARQBOAFQASABEAEwAAAAsDwoAVgBfAFQAWQBQAEUASQBO
AFMAVAAAALg5AA8HAFYAXwBMAFMATwBCAEoAAADoDwkAVgBfAFAAUgBPAEQATwBCAEoAAABADwcA
VgBfAEIAWQBSAEUARgAAAJgPBwBWAF8AQQBSAFIAQQBZAAAAbA8GAFYAXwBMAEkAUwBUAAAAAhok
EAkAVgBfAEQAWQBOAEEATQBJAEMAAAC8EgUATQBCAF8ATwBLAAAAHBELAE0AQgBfAE8ASwBDAEEA
TgBDAEUATAAAAMQPEwBNAEIAXwBBAEIATwBSAFQAUgBFAFQAUgBZAEkARwBOAE8AUgBFAAAAABAO
AE0AQgBfAFkARQBTAE4ATwBDAEEATgBDAEUATAAAAPwVnBIIAE0AQgBfAFkARQBTAAMAfAv4DwAA
TgBPAAAACBWQEA4ATQBCAF8AUgBFAFQAUgBZAEMAQQBOAEMARQBMAAAAAABkEAsATQBCAF8ASQBD
AE8ATgBTAFQATwBQAAAAiBEPAE0AQgBfAEkAQwBPAE4AUQBVAEUAUwBUAEkATwBOAAAAvBASAE0A
QgBfAEkAQwBPAE4ARQBYAEMATABBAE0AQQBUAEkATwBOAAAAAAD8EBIATQBCAF8ASQBDAE8ATgBJ
AE4ARgBPAFIATQBBAFQASQBPAE4AAAAAANwQDABNAEIAXwBBAFAAUABMAE0ATwBEAEEATAAAAAAA
YBENAE0AQgBfAEQARQBGAEIAVQBUAFQATwBOADEAAAA8EQ0ATQBCAF8ARABFAEYAQgBVAFQAVABP
AE4AMgAAALARDQBNAEIAXwBEAEUARgBCAFUAVABUAE8ATgAzAAAAcBEOAE0AQgBfAFMAWQBTAFQA
RQBNAE0ATwBEAEEATAAAAAAAyBEEAEkARABPAEsAAAAAAFwSCABJAEQAQwBBAE4AQwBFAEwAAAAA
AEASBwBJAEQAQQBCAE8AUgBUAAAA6BEHAEkARABSAEUAVABSAFkAAADYEQgASQBEAEkARwBOAE8A
UgBFAAAAAAAEEgUASQBEAFkARQBTAAAAYBMEAEkARABOAE8AAAAAAHgSCwBBAFQAVABSAF8ATgBP
AFIATQBBAEwAAAAkEg0AQQBUAFQAUgBfAFIARQBBAEQATwBOAEwAWQAAACgTCwBBAFQAVABSAF8A
SABJAEQARABFAE4AAADkFAsAQQBUAFQAUgBfAFMAWQBTAFQARQBNAAAA1BILAEEAVABUAFIAXwBW
AE8ATABVAE0ARQAAABQXDgBBAFQAVABSAF8ARABJAFIARQBDAFQATwBSAFkAAAAAAPASDABBAFQA
VABSAF8AQQBSAEMASABJAFYARQAAAAAARBMJAEEAVABUAFIAXwBNAE8ARABFAAAADBMLAEEAVABU
AFIAXwBIAEEATgBEAEwARQAAAIgUCgBBAFQAVABSAF8ASQBOAFAAVQBUAAAAAADMEwsAQQBUAFQA
UgBfAE8AVQBUAFAAVQBUAAAAfBMLAEEAVABUAFIAXwBSAEEATgBEAE8ATQAAAJwUCwBBAFQAVABS
AF8AQQBQAFAARQBOAEQAAAB0FAsAQQBUAFQAUgBfAEIASQBOAEEAUgBZAAAAqBMSAFMASABFAEwA
TABfAE4ATwBSAE0AQQBMAF8ARgBPAEMAVQBTAAAAAAC8FA8AUwBIAEUATABMAF8ATQBJAE4AXwBG
AE8AQwBVAFMAAADwEw8AUwBIAEUATABMAF8ATQBBAFgAXwBGAE8AQwBVAFMAAAAgFBUAUwBIAEUA
TABMAF8ATgBPAFIATQBBAEwAXwBOAE8AXwBGAE8AQwBVAFMAAABMFBIAUwBIAEUATABMAF8ATQBJ
AE4AXwBOAE8AXwBGAE8AQwBVAFMAAAAAAAwVEQBJAE0ARQBfAE4ATwBUAF8ASQBOAFMAVABBAEwA
TABFAEQAAAAMFgYASQBNAEUAXwBPAE4AAAAAANgVBwBJAE0ARQBfAE8ARgBGAAAAuBUMAEkATQBF
AF8ASABJAFIAQQBHAEEATgBBAAAAAAB0FREASQBNAEUAXwBLAEEAVABBAEsAQQBOAEEAXwBEAEIA
QwBTAAAAqBYRAEkATQBFAF8ASwBBAFQAQQBLAEEATgBBAF8AUwBCAEMAUwAAACgVCwBJAE0ARQBf
AEgAQQBOAEcARQBVAEwAAABQFRAASQBNAEUAXwBIAEEATgBKAEEAQwBPAE4AVgBFAFIAVAAAAAAA
mBUOAEkATQBFAF8AQQBMAFAASABBAF8ARABCAEMAUwAAAAAAxBYOAEkATQBFAF8AQQBMAFAASABB
AF8AUwBCAEMAUwAAAAAAQBYMAFMAQwBfAFUAUABQAEUAUgBDAEEAUwBFAAAAAAD4FQwAUwBDAF8A
TABPAFcARQBSAEMAQQBTAEUAAAAAAJwXDQBTAEMAXwBQAFIATwBQAEUAUgBDAEEAUwBFAAAArBcH
AFMAQwBfAFcASQBEAEUAAAAkFgkAUwBDAF8ATgBBAFIAUgBPAFcAAABcFgsAUwBDAF8ASwBBAFQA
QQBLAEEATgBBAAAAkBYLAFMAQwBfAEgASQBSAEEARwBBAE4AQQAAAIAWDwBDAFUAUgBSAEUATgBU
AEQAQQBUAEEAQgBBAFMARQAAADQZBQBFAE0AUABUAFkAAAC4FwgARABPAEMAVQBNAEUATgBUAAAA
AAAAGAoAQQBVAFQATwBSAEUATABPAEEARAAAAAAA8BYSAEcARQBUAFAAUgBPAEYASQBMAEUARABP
AEMAVQBNAEUATgBUAAAAAACMFw8AQwBhAGwAZQBuAGQAYQByAFAAcgBvAGYAaQBsAGUAAAA0FwwA
RQBSAFIATwBSAFIATwBVAFQASQBOAEUAAAAAAHQXHAAgACgAYwByAGUAYQB0AGkAbgBnACAAQwBh
AGwAZQBuAGQAYQByACAAUAByAG8AZgBpAGwAZQApAAAAAAAoGAgASQBUAEUATQBMAEkAUwBUAAAA
AADIFwUASQBUAEUATQBTAAAA5BcEAE4AQQBNAEUAAAAAABgZAwB0AG0AcAAAAAAaBABkAGkAcwBw
AAAAAACIGAoAUwBBAFYARQBUAE8ARABJAFMASwAAAAAAXBkKAFIARQBNAE8AVgBFAEkAVABFAE0A
AAAAALgaEAAkACQAUQB1AGUAcgB5AE8AcABlAG4AQQBnAGUAbgB0AAAAAABQGBAAJAAkAFEAdQBl
AHIAeQBTAGEAdgBlAEEAZwBlAG4AdAAAAAAAaBgJAFAAYQB0AGgAXwBJAG4AZgBvAAAApBgMAFEA
dQBlAHIAeQBfAFMAdAByAGkAbgBnAAAAAADMGAoASQBNAFAATwBSAFQAQQBOAEMARQAAAAAA8BgQ
AEQARQBMAEkAVgBFAFIAWQBQAFIASQBPAFIASQBUAFkAAAAAAAgZDgBEAEUATABJAFYARQBSAFkA
UgBFAFAATwBSAFQAAAAAAPgYAQBCAAAApBkEAEYATwBSAE0AAAAAALQZBABUAGEAcwBrAAAAAACA
GQoASQBtAHAAbwByAHQAYQBuAGMAZQAAAAAA2BkQAEQAZQBsAGkAdgBlAHIAeQBQAHIAaQBvAHIA
aQB0AHkAAAAAACAaDgBEAGUAbABpAHYAZQByAHkAUgBlAHAAbwByAHQAAAAAAIAaDwBDAE8ATQBQ
AFUAVABFAFcASQBUAEgARgBPAFIATQAAANQaBABTAEEAVgBFAAAAAABkGg8AVwBEAEUARgBBAFUA
TABUAE0AQQBJAEwATwBQAFQAAADwGhAAVwBFAE4AQQBCAEwARQBUAFIAQQBTAEgASQBDAE8ATgAA
AAAAPBoMAFcAQwBBAEwARwBSAEkARABUAFkAUABFAAAAAACcGgsAVwBFAE4AQQBCAEwARQBOAEEA
QgBTAAAAPBsQAFcARQBOAEEAQgBMAEUARgBBAFYATwBSAEkAVABFAFMAAAAAAFQbCgBXAEkAUwBG
AE8ATABEAEUAUgAxAAAAAAAMGwoAVwBJAFMARgBPAEwARABFAFIAMgAAAAAA//8KAFcASQBTAEYA
TwBMAEQARQBSADMAAAAAAP//CgBXAEkAUwBGAE8ATABEAEUAUgA0AAAAAAD//woAVwBJAFMARgBP
AEwARABFAFIANQAAAAAA//8KAFcASQBTAEYATwBMAEQARQBSADYAAAAAACQbCQBOAE8AVABFAFMA
TgBBAEIAMQAAAP//CQBuAGEAbQBlAHMALgBuAHMAZgAAAP//CQBTAEQAQQBUAEUAVABJAE0ARQAA
AP//CwBMAFMATABPAEMAQQBMAFQASQBNAEUAAAAFAPwPAAAAACX9Td4IAAAAnAA0ATwAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAA0AZgKjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAA0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAACAAQAGADYAPIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAWwAAACAAAAABAAAA+Br4GgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD4GvgaAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAAQAEAAAAAAAAQAAQA
nAIAACABAAAAAAAABAAAACQbABwAAAAAJBsAHAAAAAAAAAAAAAAAAHAbcBsAAAAAAAAAAAAAAADQ
G9AbAAAAAAAAAAAAAAAABBQTKe0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAA
AAAAAAAAAgDMAWgCAACcAgAAAgABAAAAAAASABQAAAAAAP//CQIAAAAAjQQAAAAA2AHMAQAAAAAA
AAYAAgAAAAkC2AEJAtgBCQKcAhkAEAAAADgFyAlUAQAAAAAAAAEAAADEGsQaAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBrEGgIUEyntLmkQv10A3QERhrcA
AAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAIAzAEsAwAAAAAAAAIAAQAAAAAAEgAUAAAA
AAD//wkCAAAAABIEAAAAAJwCzAEAAAAAAAAGAAMAAAAJApwCCQKcAgYIBggZAAgAEAAIBPgF8AAA
AAAAAAADAAAA+ANIG0gbSBsAAAAAAAAAAAAAAAAUGxQbAAAAAPgD+AMAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAACwAAAOQAAABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwABABQbAAAUAQkCAADYAQgAEACgBJAHdAEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAADAAAAPQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAQAPgFAAi0AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAOQIAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAQAAAA0AYAADACAAAAAAAAAQAAANQc1BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADUHNQcAAAAAAAAAAAAAAAACBQTKe0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABk
AAAAAAAAAAAAAAAAAAAAAgDMAcgFAADYAQAAAgABAAAAAAASABQAAAAAAP//CQIAAAAA8gQAAAAA
OAXMAQAAAAAAAAUAAgAAAAkCOAUJAjgFBggIABAAsAbABuQBAAAAAAAAAwAAAJAGxByQBpAGAAAA
AAAAAAAAAAAAAAAAAMQcxBwAAAAAoAagBgAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAsAAADnAgAA
EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAMAAQCgBgAAEAIAAAAAAAADAAEAxBwAABwCCQIBADgFAwAQAMAGsAdQAgAAAAAAAAMA
EACQB6AHXAIAABAAAAAQAAAAEAgAAIACAAAAAAAAAQAAAIgaiBoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgaiBoAAAAAARQTKe0uaRC/XQDdARGGtwAAAAAAAAAA
AAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAgDMAWAHAAA4BQAAAgABAAAAAAASABQAAAAAAP//CQIA
AAAAsgQAAAAA0AbMAQAAAAAAAAQAAQAAAAkC0AYJAtAGGQADABAAoAfAB2wCCQIgANAGAwAQALAH
6AugAgkCJACcAgMAEADAB8gKrAIJAigA2AEDABAA0AfgB7wCCQIsANgBAwAQAOAH6BDQAgkCMADY
AQMAEADwBwgL5AIJAjQA2AEDABAAAAigCAADCQI4ANgBAwAQAKAIKA4UAwkCPADYARAAAADwCAAA
PAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAALFBMp7S5pEL9dAN0BEYa3AAAAAAAAAAAAAAAAAAAAAGQAAAAAAAAAAAAAAAAA
AAACAMwBAAAAANAGAAACAAEAAAAAAAMAEACwCCgLJAMJAkAAEAgDABAAwAgIDnADCQJEABAIAwAQ
ANAIyAuIAwkCSAA4BQMAEADgCIgKmAMJAkwAOAUDABAAuAm4CqgDCQJQADgFEAAAAMgJAADQAwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAUUEyntLmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAIA
zAGACQAAEAgAAAIAAQAAAAAAEgAUAAAAAAD//wkCAAAAACgEAAAAAPAIzAEAAAAAAAAJAAUAAAAJ
AvAICQLwCAkK2AEGCAAAgQgDABAAiAqoCsADCQJUAPAIEAAAAAAAAAAEBAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMUEynt
LmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAIAzAFYCgAA8AgAAAIA
AQAAAAAAEgAUAAAAAAD//wkCAAAAAGUGAAAAAMgJzAEAAAAAAAAFAAIAAAAJAsgJCQLICQYIAwAQ
AJgKKAzoAwkCWADICQMAEACoCkgMHAQGAFwAAAADABAAuAooECwEAQBgAAAAAwAQAMgK6ApIBAAA
aAAAAAQAEADoCmgMhAQGAAAAAACwBKsBSQAAAAgAEgAAE80CBAAQAAgLSAu4BAYAAAAAAOwEqwFV
AAAACAASAGATzQIEABAAKAuIDPQEBgAAAAAAIAWrAUMAAAAIABIAwBPNAgQAEABIC4gLKAUGAAAA
AABcBasBRAAAAAgAEgAgFM0CBAAQAGgLCA1kBQYAAAAAAJwFqwFTAAAACAASAIAUzQIEABAAiAuo
C6QFBgAAAAAA3AWrAU4AAAAIABIA4BTNAgQAEACoC4gQ5AUGAAAAAAAcBqsBSgAAAAgAEgBAFc0C
BAAQAMgLyAwkBgYAAAAAAFAGqwFBAAAACAASAKAVzQIEABAA6AuIDVgGBgAAAAAAhAarAVIAAAAI
ABIAABbNAgQAEAAIDAgMjAYGAAAAAAC8BqsBTAAAAAgAEgBgFs0CBAAQACgMqA3EBgYAAAAAAPAG
qwFUAAAACAASAMAWzQIEABAASAzoDfgGBgAAAAAAKAerAVAAAAAIABIAIBfNAgQAEABoDOgMMAcG
AAAAAABcB6sBMQAAAAgAEgCAF80CBAAQAIgMyA1kBwYAAAAAAJAHqwEyAAAACAASAOAXzQIEABAA
qAyoDJgHBgAAAAAAxAerATMAAAAIABIAQBjNAgQAEADIDKgOzAcGAAAAAAD4B6sBNAAAAAgAEgCg
GM0CBAAQAOgMKA0ACAYAAAAAACwIqwE1AAAACAASAAAZzQIEABAACA3oDjQIBgAAAAAAWAirATAA
AAAIABIAYBnNAgQAEAAoDUgNYAgGAAAAAABcB6sBMQAAAAgAEgDAGc0CBAAQAEgNCBCQCAYAAAAA
AJAHqwEyAAAACAASACAazQIEABAAaA1oDbwIBgAAAAAAxAerATMAAAAIABIAgBrNAgQAEACIDQgP
6AgGAAAAAAD4B6sBNAAAAAgAEgDgGs0CBAAQAKgNSA8MCQYAAAAAACwIqwE1AAAACAASAEAbzQIE
ABAAyA1IDjAJBgAAAAAAXAmrATYAAAAIABIAoBvNAgQAEADoDagQZAkGAAAAAABYCKsBMAAAAAgA
EgAAHM0CBAAQAAgOaA6QCQYAAAAAAFwHqwExAAAACAASAGAczQIEABAAKA6IDrgJBgAAAAAA4Amr
AbYAAAAIABIAwBzNAgQAEABIDogR7AkGAAAAAAAMCqsBmAAAAAgAEgAgHc0CBAAQAGgO6A8YCgYA
AAAAADwKqwGgAAAACAASAIAdzQIEABAAiA7IDkgKBgAAAAAAcAqrAZAAAAAIABIA4B3NAgQAEACo
DmgPfAoGAAAAAACkCqsBuAAAAAgAEgBAHs0CBAAQAMgOKBKwCgYAAAAAANgKqwGsAAAACAASAKAe
zQIEABAA6A7oEuQKBgAAAAAAFAurAbIAAAAIABIAAB/NAgQAEAAIDygPIAsGAAAAAABAC6sBhAEA
AAgAEgBgH80CBAAQACgPSBJMCwYAAAAAAGwLqwGwAQAACAASAMAfzQIEABAASA+ID3gLBgAAAAAA
mAurAYQBAAAIABIAICDNAgQAEABoD6gPpAsGAAAAAADEC6sBlgEAAAgAEgCAIM0CBAAQAIgPSBPQ
CwYAAAAAAPALqwGPAQAACAASAOAgzQIEABAAqA/ID/wLBgAAAAAAHAyrAT0DAAAIABIAQCHNAgQA
EADID8gQLAwGAAAAAABMDKsBJQMAAAgAEgCgIc0CBAAQAOgPCBVcDAYAAAAAAHwMqwGJAQAACAAS
AAAizQIEABAACBBoEogMBgAAAAAABQAEDfgPAACoDKsBmAMAAAgAEgBgIs0CBAAQACgQSBC4DAYA
AAAAANgMqwGOAQAACAASAMAizQIEABAASBBoEOQMBgAAAAAABA2rAZABAAAIABIAICPNAgQAEABo
EOgREA0GAAAAAAAwDasBuQEAAAgAEgCAI80CBAAQAIgQaBFYDQEAAAAAAAAAAAAAAAAAAgAAAAAA
AAAEABAAqBAIEWwNAQAAAAAAAQAAAAAA8D8CAAAAAAAAAAQAEADIEEgRgA0BAAAAAAACAAAAAAAA
QAIAAAAAAAAABAAQAOgQCBKYDQEAAAAAAAMAAAAAAAhAAgAAAAAAAAAEABAACBGIEqwNAQAAAAAA
BAAAAAAAEEACAAAAAAAAAAQAEAAoESgRxA0BAAAAAAAFAAAAAAAUQAIAAAAAAAAABAAQAEgRqBHc
DQEAAAAAAAYAAAAAABhAAgAAAAAAAAAEABAAaBGIE/gNAQAAAAAABwAAAAAAHEACAAAAAAAAAAQA
EACIEcgRDA4BAAAAAAAIAAAAAAAgQAIAAAAAAAAABAAQAKgR6BckDgEAAAAAAAkAAAAAACJAAgAA
AAAAAAAEABAAyBHoFkAOAQAAAAAACgAAAAAAJEACAAAAAAAAAAQAEADoEcgSVA4BAAAAAAALAAAA
AAAmQAIAAAAAAAAABAAQAAgSaBVsDgEAAAAAAAwAAAAAAChAAgAAAAAAAAAEABAAKBIIFoQOAQAA
AAAADQAAAAAAKkACAAAAAAAAAAQAEABIEggToA4BAAAAAAAOAAAAAAAsQAIAAAAAAAAABAAQAGgS
SBe4DgEAAAAAACAAAAAAAEBAAgAAAAAAAAAEABAAiBIoE9QOAQAAAAAAIQAAAACAQEACAAAAAAAA
AAQAEACoEqgS8A4BAAAAAAAiAAAAAABBQAIAAAAAAAAABAAQAMgS6BMEDwEAAAAAACMAAAAAgEFA
AgAAAAAAAAAEABAA6BJoFBwPAQAAAAAAAEAAAAAAAAACAAAAAAAAAAQAEAAIE2gTMA8BAAAAAAAA
IAAAAAAAAAIAAAAAAAAABAAQACgTiBREDwEAAAAAAAAIAAAAAAAAAgAAAAAAAAAEABAASBNIFFgP
AQAAAAAAAAIAAAAAAAACAAAAAAAAAAQAEABoEwgUcA8BAAAAAAAAAAAAAAAAAAIAAAAAAAAABAAQ
AIgTqBOADwEAAAAAAAEAAAAAAPA/AgAAAAAAAAAEABAAqBPoFJwPAQAAAAAAAgAAAAAAAEACAAAA
AAAAAAQAEADIE8gTyA8BAAAAAAADAAAAAAAIQAIAAAAAAAAABAAQAOgTKBTsDwEAAAAAAAQAAAAA
ABBAAgAAAAAAAAAEABAACBRIFQQQAQAAAAAABQAAAAAAFEACAAAAAAAAAAQAEAAoFCgVKBABAAAA
AAAQAAAAAAAwQAIAAAAAAAAABAAQAEgUiBVEEAEAAAAAACAAAAAAAEBAAgAAAAAAAAAEABAAaBTI
FGgQAQAAAAAAMAAAAAAASEACAAAAAAAAAAQAEACIFCgWlBABAAAAAABAAAAAAABQQAIAAAAAAAAA
BAAQAKgUqBTAEAEAAAAAAAAAAAAAAAAAAgAAAAAAAAAEABAAyBRoFuAQAQAAAAAAAAAAAAAAAAAC
AAAAAAAAAAQAEADoFIgWABEBAAAAAAAAAQAAAABwQAIAAAAAAAAABAAQAAgVqBUgEQEAAAAAAAAC
AAAAAIBAAgAAAAAAAAAEABAAKBXoFUARAQAAAAAAABAAAAAAsEACAAAAAAAAAAQAEABIFagWZBEB
AAAAAAABAAAAAADwPwIAAAAAAAAABAAQAGgVyBV0EQEAAAAAAAIAAAAAAABAAgAAAAAAAAAEABAA
iBWoGIwRAQAAAAAAAwAAAAAACEACAAAAAAAAAAQAEACoFUgWoBEBAAAAAAAEAAAAAAAQQAIAAAAA
AAAABAAQAMgVyBa0EQEAAAAAAAUAAAAAABRAAgAAAAAAAAAEABAA6BWoF8wRAQAAAAAABgAAAAAA
GEACAAAAAAAAAAQAEAAIFggX3BEBAAAAAAAHAAAAAAAcQAIAAAAAAAAABAAQACgWSBjsEQEAAAAA
AAAAAAAAAAAAAgAAAAAAAAAEABAASBYAAAgSAQAAAAAAAQAAAAAA8D8CAAAAAAAAAAQAEABoFmgX
KBIBAAAAAAACAAAAAAAAQAIAAAAAAAAABAAQAIgWKBdEEgEAAAAAAAQAAAAAABBAAgAAAAAAAAAE
ABAAqBbIF2ASAQAAAAAACAAAAAAAIEACAAAAAAAAAAQAEADIFsgZfBIBAAAAAAAQAAAAAAAwQAIA
AAAAAAAABAAQAOgW6BmgEgEAAAAAACAAAAAAAEBAAgAAAAAAAAAEABAACBcIGsASAQAAAAAAAQAA
AAAA8D8CAAAAAAAAAAQAEAAoF4gX2BIBAAAAAAACAAAAAAAAQAIAAAAAAAAABAAQAEgXiBj0EgEA
AAAAAAEAAAAAAPA/AgAAAAAAAAAEABAAaBfIGBATAQAAAAAAAgAAAAAAAEACAAAAAAAAAAQAEACI
FwAALBMBAAAAAAAEAAAAAAAQQAIAAAAAAAAABAAQAKgXaBlIEwEAAAAAAAgAAAAAACBAAgAAAAAA
AAAEABAAyBcIGGQTAQAAAAAAIAAAAAAAQEACAAAAAAAAAAQAEADoFwAAgBMBAAAAAAABAAAAAADw
PwIAAAAAAAAABAAQAAgYaBisEwEAAAAAAAIAAAAAAABAAgAAAAAAAAAEABAAKBgoGNATAQAAAAAA
AwAAAAAACEACAAAAAAAAAAQAEABIGOgY9BMBAAAAAAAEAAAAAAAQQAIAAAAAAAAABAAQAGgYAAAk
FAEAAAAAAAYAAAAAABhAAgAAAAAAAAAEABAAiBgIGVAUAQAAAAAAAAAAAAAAAAACAAAAAAAAAAQA
EACoGAAAeBQBAAAAAAABAAAAAADwPwIAAAAAAAAABAAQAMgYSBmMFAEAAAAAAAIAAAAAAABAAgAA
AAAAAAAEABAA6BgAAKAUAQAAAAAABAAAAAAAEEACAAAAAAAAAAQAEAAIGSgZwBQBAAAAAAAFAAAA
AAAUQAIAAAAAAAAABAAQACgZAADoFAEAAAAAAAYAAAAAABhAAgAAAAAAAAAEABAASBmoGRAVAQAA
AAAABAAAAAAAEEACAAAAAAAAAAQAEABoGYgZLBUBAAAAAAAFAAAAAAAUQAIAAAAAAAAABAAQAIgZ
SBpUFQEAAAAAAAcAAAAAABxAAgAAAAAAAAAEABAAqBkoGngVAQAAAAAACAAAAAAAIEACAAAAAAAA
AAQAEADIGQAAnBUBAAAAAAABAAAAAADwPwIAAAAAAAAABAAQAOgZaBq8FQEAAAAAAAIAAAAAAABA
AgAAAAAAAAAEABAACBoAANwVAQAAAAAAAwAAAAAACEACAAAAAAAAAAQAEAAoGgAA/BUBAAAAAAAE
AAAAAAAQQAIAAAAAAAAABAAQAEgaAAAQFgEAAAAAAAgAAAAAACBAAgAAAAAAAAAEABAAaBoAACgW
AQAAAAAAEAAAAAAAMEACAAAAAAAAAAQAEAAAAAAARBYBAAAAAAAgAAAAAABAQAIAAAAAAAAAEQAQ
BQAAAABgFgkCqAQAAAAAAAAAAAAAAAAAAAAAAAAAAJwCFgC4GpQWRD8AABkAFgCUHKwWSuMAABkA
EgAUAAAAAADIFgmCAAAAAOgFAAAAAJwCzAEAAAAAAAAGAAMAAAAJAtgBCQKcAgYIhggZAA0AAAAA
AAAAGBdOAMsAGQAWAIgcHASoBwAAGQADAAIASBsAAHgXAAAQAAAAEQAQBXAbAByQFwAAfgQAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABQACAAAAAADcBQAAIAAAABYAAACgF6sDAAAZABYAxBvMF9nQAAAZ
ABIAFADQGwAA6BcKAAAAAACRBAAAAADYAcwBAAAAAAAABAACAAAACgAJAtgBBggZABYAAACMGDPo
AAAZABYAQByoGCg7AAAZABYAZBzQGBNPAAAZABYAWBz8GOUDAAAZABIAFAAAHAAAhBkAAAAAAACi
BAAAAADYAcwBAAAAAAAABQADAAAAAAAJAtgBAQABABIAFAAAAAAAqBkBAAAAAACUBAAAAADYAcwB
AAAAAAAABgAEAAAAAQAJAtgBAQgBCIEIGQAWAKwcuBlC9AAAGQAWAKAc3BkA2gAAGQAWAAAABBpC
QwAAGQAWAHwcJBpypgAAGQAWAAAAQBo1xgAAGQAWAAAAaBqB0QAAGQAWAAAAhBqC0QAAGQAWAAAA
oBqD0QAAGQAWAAAAvBqE0QAAGQAWAAAA2BqF0QAAGQAWALgc9BqG0QAAGQAWAAAAEBvRcgAAGQAD
AAIAAAAAAEAbAAAAAAAAEQAQBAAAAABYGwAA7gQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAZAwAA
AAAdAAAaKwAaLAAaNgAdGjkAW5AHK9AGJKYaOgBboAdLkActiBojpho8ACk0ASMaPgBbwAYGOn2E
FrU4GAAaPwBbsAdOwAZQrBqmGkAATsAGUbgag6UaQQAaQgAdGkYADAAAAAAaSABHwAeBxTgQAFvA
B0ugByzEGn30FosII6YaSQAUhbQ4DAAaSgCFExpLACkIBCMaTAAaTgALAAAQAAk6KQAaTwBLwAdT
CBuFJX2EALg4BAApCAQjGlEAW5gKS8AHUwgbhSWlGlMAHBpVABpWABaTfTgXv5uAgAYHGlcAHBpY
AB0aXAAMAAAAABpdAF4UG0v4Ay0kGyOlGl4AShQbNUgbSQAaXwBGSBtVWBsgCAAAk48DAwZKk5MG
SZN9sBe4RkgbVVgbIAgAAJOPBAMGSpOTBkmTfbwXuMM4CABGSBtRZBuDpRpgADdIG7f/GmIAR7gK
oDgBABwaZQBL+AMscBt9BBgjGmYAS/gDLHAbfSwYIxpnAEv4AyxwG31UGCMaaABL+AMscBt9bBgj
GmwAS/gDU6AbhSV9kAe4S/gDU6wbhSV93AW4xEv4A1O4G4UlffQYuMRL+ANTxBuFJX0MGbvEOCcA
Gm0AS/gDLHAbfRwZIxpuAEv4AyxwG304GSMabwBL+AMscBt9YBkjGnAAGnEAHRp7AEvAB1HEG330
FqUafABLwAcs0BuFhSMxGn4AR7gKOA0AGn8AKaAEIxqAADoRABqBAEvABywAHISEhCMxGoIAGoMA
HRqGAEvAB1E0HH2QB6UahwBLwAdRQBx9XAelGogAS8AHUUwcfcQHpRqKAEvAB1FYHH1YCKUaiwBL
wAdRZBx9WAilGo0AS8AHUXAcfVwHpRqOAEvAB1F8HH1cB6UajwBLwAdRiBx9XAelGpAAS8AHUZQc
fVwHpRqRAEvAB1GgHH1cB6UakgBLwAdRrBx9XAelGpQAS8AHUbgcfSgbpRqWAEvABywAHISEhCMx
GpcAHRqaAF2gBis4BUrEHJskphqcAF2QBgYcOA0AGp0AS6AGLtQcSZAGIRqeABqfAB0CAAAAAQAI
smIAvGUlhXwCAAAQAAAATwAAAHwCAAABAAEAAAACAGrGIvd7AwAAAAACALBsbQBNYyUAAAAAAP//
/wATAQAANwEAAAHtAAIX+mwATGMlABf6bADxhiXtAAINAE89TG90dXMgTm90ZXMAAA0ATz1Mb3R1
cyBOb3RlcwAAiABCVgQAMS4wAEJDAQADQkEBADBCTAIAdgJOTlAAXca7basAZci5xkmnmSwSTZne
I+59UOX0Jl+KDeHUBNWwI+FggdJdJGAXur7OasxQAlNOX6OqZyHYbEbkyDtFGFxbqruFH6ij5FSJ
zfo+KQBFTgQAi3EAAE1BCABXPs7BMoJEjYAAUFVSU0FGTwB7nUI/c3Dkr9qV7ll97pozOWTudPEe
ZlslkWQLXDEhpXVAO6IkZgUjObfF4IUATTciPgp8LjojVQUedAvNMGdkjPedLmsawSHnUCPbON0S
ASAAAMVsbQBMYyUAcBNtACdmJYUAAA0ATz1Mb3R1cyBOb3RlcwAAMQBDTj1Mb3R1cyBOb3RlcyBU
ZW1wbGF0ZSBEZXZlbG9wbWVudC9PPUxvdHVzIE5vdGVzAACIAEJWBAAxLjAAQkMBAANCQQEAMEJM
AgB2Ak5OUABJT7I2RKjbwTm2d/YnbifxR+5EV1HFwYYhYJS5tebxGhXEPv1r7lePODoJZ9Qp5Wsl
SFPFhL3qLf/oQQvmhfjSVRuNxFsa0kH2yAqeGQshAEVOBADvXgAATUEIAJi0FzwM15wNgABQVVJT
QUZPANnqZoCheUYDuV627e0APOqjmSe5bEF+VuuyOyhzgn/Q5adu4nknlYsqCjnu5EChgMj7RKnl
LbOBYhvS2buSyI4sevAUeNzXj0ZkZSFmXl6jCKw6onrV/FJ4mFZwjYGanuN6c9XYlDZAbdTuHc/w
UuFzQ55YwAbfJ+xswX2dQ5ApGEaL3cUM+8eo/OpiSVs5LiN7Ue25bc+7TSg4HLFBvlLB/CAGIZyS
59gAftYaK+ECBQAFADQAAAAAAAAAAAAAAAAAAAAAAAAAJFNjcmlwdExpYgAkU2NyaXB0TGliX08A
JFRJVExFACRGbGFncwAkUHVibGljQWNjZXNzAKqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6
NTooT3B0aW9ucyk6MDo3NApPcHRpb24gUHVibGljClVzZSAiT2JqZWN0VmFyaWFibGVzIgonKytM
b3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjU6KEZvcndhcmQpOjA6MQpEZWNs
YXJlIFN1YiBJbml0aWFsaXplCkRlY2xhcmUgU3ViIENyZWF0ZU5ld0RvYyhuRG9jVHlwZSBBcyBJ
bnRlZ2VyKQpEZWNsYXJlIFN1YiBDcmVhdGVNYWlsTWVtbyhwTm90ZSBBcyBOb3Rlc0RvY3VtZW50
KQpEZWNsYXJlIFN1YiBDcmVhdGVDYWxlbmRhckVudHJ5KHBOb3RlIEFzIE5vdGVzRG9jdW1lbnQp
CkRlY2xhcmUgU3ViIENyZWF0ZVRhc2socE5vdGUgQXMgTm90ZXNEb2N1bWVudCkKRGVjbGFyZSBG
dW5jdGlvbiBHZXRTZW5kTmFtZXMocE5vdGUgQXMgTm90ZXNEb2N1bWVudCkgQXMgVmFyaWFudApE
ZWNsYXJlIEZ1bmN0aW9uIEdldENvcHlOYW1lcyhwTm90ZSBBcyBOb3Rlc0RvY3VtZW50KSBBcyBW
YXJpYW50CkRlY2xhcmUgU3ViIEFkZEJvZHlUb05ld05vdGUocE5ld05vdGUgQXMgTm90ZXNEb2N1
bWVudCwgcFNvdXJjZU5vdGUgQXMgTm90ZXNEb2N1bWVudCkKCicrK0xvdHVzU2NyaXB0IERldmVs
b3BtZW50IEVudmlyb25tZW50OjI6NTooRGVjbGFyYXRpb25zKTowOjEwCkNvbnN0IE5FV19NRU1P
ID0gMApDb25zdCBORVdfQ0FMRU5EQVIgPSAxCkNvbnN0IE5FV19UQVNLID0gMgoKRGltIGJPa1Rv
Q29weSBBcyBJbnRlZ2VyCgoKCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50
OjI6MjpJbml0aWFsaXplOjE6MTAKU3ViIEluaXRpYWxpemUKICAgICAKRW5kIFN1YgonKytMb3R1
c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjI6Q3JlYXRlTmV3RG9jOjE6OApTdWIg
Q3JlYXRlTmV3RG9jKG5Eb2NUeXBlIEFzIEludGVnZXIpCiAgICAgCiAgICAgU2V0IHNlc3Npb24g
PSBOZXcgTm90ZXNTZXNzaW9uCiAgICAgU2V0IHdzID0gTmV3IE5vdGVzVUlXb3Jrc3BhY2UKICAg
ICBTZXQgZGIgPSBzZXNzaW9uLkN1cnJlbnREYXRhYmFzZQogICAgIAogICAgIGJPa1RvQ29weSA9
IFRydWUKICAgICAKICAgICAnaWYgdGhlcmUgaXMgYSBkb2N1bWVudCBjdXJyZW50bHkgb3Blbiwg
YW5kIGl0IGlzIGEgbmV3IGRvY3VtZW50LCB3ZSBjYW5ub3QgcHJvY2VlZAogICAgIFNldCB1aWRv
YyA9IHdzLkN1cnJlbnREb2N1bWVudAogICAgIElmIE5vdCh1aWRvYyBJcyBOb3RoaW5nKSBUaGVu
CiAgICAgICAgICBJZiB1aWRvYy5Jc05ld0RvYyBUaGVuCiAgICAgICAgICAgICAgIE1lc3NhZ2Vi
b3ggIlRoaXMgYWN0aW9uIGNhbm5vdCBiZSBleGVjdXRlZCBvbiBhIG5ldyBkb2N1bWVudC4iLDE2
LCJFcnJvciIKICAgICAgICAgICAgICAgRXhpdCBTdWIKICAgICAgICAgIEVuZCBJZgogICAgICAg
ICAgU2V0IG5vdGUgPSB1aWRvYy5Eb2N1bWVudCAgICAgICAgICAKICAgICBFbHNlCiAgICAgICAg
ICBTZXQgc2VsZWN0ZWRkb2NzID0gZGIuVW5wcm9jZXNzZWREb2N1bWVudHMKICAgICAgICAgIElm
IChzZWxlY3RlZGRvY3MuQ291bnQgPSAwKSBUaGVuIAogICAgICAgICAgICAgICBNZXNzYWdlYm94
ICJQbGVhc2Ugc2VsZWN0IGEgZG9jdW1lbnQgYmVmb3JlIGV4ZWN1dGluZyB0aGlzIGNvbW1hbmQu
IiwxNiwiRXJyb3IiCiAgICAgICAgICAgICAgIEV4aXQgU3ViCiAgICAgICAgICBFbmQgSWYKICAg
ICAgICAgIFNldCBub3RlID0gc2VsZWN0ZWRkb2NzLkdldEZpcnN0RG9jdW1lbnQKICAgICBFbmQg
SWYKICAgICAKICAgICAnIE1ha2Ugc3VyZSB0aGlzIGRvY3VtZW50IGlzIG5vdCBwcmV2ZW50ZWQg
ZnJvbSBiZWluZyBjb3BpZWQKICAgICBJZiAobm90ZS5+JEtlZXBQcml2YXRlKDApID0gIjEiKSBU
aGVuCiAgICAgICAgICBNZXNzYWdlYm94ICJUaGlzIGRvY3VtZW50IGlzIHByZXZlbnRlZCBmcm9t
IGJlaW5nIGNvcGllZC4gVGhlIGJvZHkgd2lsbCBub3QgYmUgY29waWVkIGludG8gdGhlIG5ldyBk
b2N1bWVudCBjcmVhdGVkLiIsMTYsIldhcm5pbmciCiAgICAgICAgICBiT2tUb0NvcHkgPSBGYWxz
ZSAgICAgICAgICAKICAgICBFbmQgSWYKICAgICAKICAgICBTZWxlY3QgQ2FzZSBuRG9jVHlwZQog
ICAgIENhc2UgTkVXX01FTU8KICAgICAgICAgIENhbGwgQ3JlYXRlTWFpbE1lbW8obm90ZSkKICAg
ICBDYXNlIE5FV19DQUxFTkRBUgogICAgICAgICAgQ2FsbCBDcmVhdGVDYWxlbmRhckVudHJ5KG5v
dGUpCiAgICAgQ2FzZSBORVdfVEFTSwogICAgICAgICAgQ2FsbCBDcmVhdGVUYXNrKG5vdGUpCiAg
ICAgRW5kIFNlbGVjdAogICAgIApFbmQgU3ViCicrK0xvdHVzU2NyaXB0IERldmVsb3BtZW50IEVu
dmlyb25tZW50OjI6MjpDcmVhdGVNYWlsTWVtbzoxOjgKU3ViIENyZWF0ZU1haWxNZW1vKHBOb3Rl
IEFzIE5vdGVzRG9jdW1lbnQpCiAgICAgCiAgICAgRGltIG1haWwgQXMgTm90ZXNEb2N1bWVudAog
ICAgIERpbSBydGl0ZW0gQXMgTm90ZXNSaWNoVGV4dEl0ZW0KICAgICAKICAgICBTZXQgbWFpbCA9
IE5ldyBOb3Rlc0RvY3VtZW50KGRiKQogICAgIAonc2V0L3JldHJpZXZlIHN0YW5kYXJkIG1haWwg
dmFsdWVzIHJlZ2FyZGxlc3Mgb2YgcE5vdGUgdHlwZQogICAgIG1haWwuRm9ybSA9ICJNZW1vIgog
ICAgIG1haWwuUHJpbmNpcGFsID0gT3duZXIKICAgICBtYWlsLnRtcFNlbmRUbyA9IEdldFNlbmRO
YW1lcyhwTm90ZSkKICAgICBtYWlsLlNlbmRUbyA9IEV2YWx1YXRlKCJAVHJpbShAVW5pcXVlKHRt
cFNlbmRUbykpIixtYWlsKQogICAgIG1haWwudG1wQ29weVRvID0gR2V0Q29weU5hbWVzKHBOb3Rl
KQogICAgIG1haWwuQ29weVRvID0gRXZhbHVhdGUoIkBUcmltKEBVbmlxdWUodG1wQ29weVRvKSki
LG1haWwpCiAgICAgCiAgICAgSWYgKHBOb3RlLk5vdGljZVR5cGUoMCkgPD4gIkoiKSBUaGVuIENh
bGwgQWRkQm9keVRvTmV3Tm90ZShtYWlsLHBOb3RlKQogICAgIAogICAgIENhbGwgbWFpbC5SZW1v
dmVJdGVtKCJ0bXBTZW5kVG8iKQogICAgIENhbGwgbWFpbC5SZW1vdmVJdGVtKCJ0bXBDb3B5VG8i
KQogICAgIAogICAgIAonc2V0L3JldHJpZXZlIG1haWwgdmFsdWVzIGRlcGVuZGluZyBvbiBwTm90
ZSB0eXBlCiAgICAgU2VsZWN0IENhc2UgcE5vdGUuRm9ybSgwKQogICAgIENhc2UgIk1lbW8iLCJS
ZXBseSIsIkFwcG9pbnRtZW50IiwiVGFzayIKICAgICAgICAgIG1haWwuU3ViamVjdCA9IHBOb3Rl
LlN1YmplY3QKICAgICBDYXNlICJOb3RpY2UiCiAgICAgICAgICBtYWlsLlN1YmplY3QgPSBwTm90
ZS5Ub3BpYwogICAgIENhc2UgRWxzZQogICAgICAgICAgbWFpbC5TdWJqZWN0ID0gcE5vdGUuU3Vi
amVjdAogICAgIEVuZCBTZWxlY3QKICAgICAKICAgICBtYWlsLkxvZ28gPSBzZXNzaW9uLkdldEVu
dmlyb25tZW50U3RyaW5nKCJEZWZhdWx0TG9nbyIsRmFsc2UpCiAgICAgbWFpbC50bXBuZXdkb2Mg
PSBUcnVlCiAgICAgQ2FsbCB3cy5FZGl0RG9jdW1lbnQoVHJ1ZSxtYWlsKQpFbmQgU3ViCicrK0xv
dHVzU2NyaXB0IERldmVsb3BtZW50IEVudmlyb25tZW50OjI6MjpDcmVhdGVDYWxlbmRhckVudHJ5
OjE6OApTdWIgQ3JlYXRlQ2FsZW5kYXJFbnRyeShwTm90ZSBBcyBOb3Rlc0RvY3VtZW50KQogICAg
IAogICAgIERpbSBlbnRyeSBBcyBOb3Rlc0RvY3VtZW50CiAgICAgRGltIHJ0aXRlbSBBcyBOb3Rl
c1JpY2hUZXh0SXRlbQogICAgIERpbSBzdGFydGR0IEFzIE5ldyBOb3Rlc0RhdGVUaW1lKCIiKQog
ICAgIERpbSBlbmRkdCBBcyBOZXcgTm90ZXNEYXRlVGltZSgiIikKICAgICBEaW0gdHJkciBBcyBO
b3Rlc0RhdGVSYW5nZQogICAgIERpbSBlbnRyeWl0ZW0gQXMgTm90ZXNJdGVtCiAgICAgCiAgICAg
RGltIHNGb3JtIEFzIFN0cmluZwogICAgIERpbSBuTWludXRlcyBBcyBJbnRlZ2VyCiAgICAgRGlt
IG5TZWNvbmRzIEFzIEludGVnZXIKICAgICAKICAgICBJZiAocHJvZmlsZSBJcyBOb3RoaW5nKSBU
aGVuIENhbGwgR2V0Q2FsZW5kYXJPd25lcgogICAgIAogICAgIFNldCBlbnRyeSA9IE5ldyBOb3Rl
c0RvY3VtZW50KGRiKQogICAgIAonYWRkIHN0YW5kYXJkIGVudHJ5IGl0ZW1zCiAgICAgZW50cnku
QXBwb2ludG1lbnRUeXBlID0gcHJvZmlsZS5DYWxFbnRyeVR5cGUoMCkKICAgICBlbnRyeS5Gb3Jt
ID0gIkFwcG9pbnRtZW50IgogICAgIGVudHJ5LlNlbmRUbyA9IEdldFNlbmROYW1lcyhwTm90ZSkK
ICAgICBlbnRyeS5Db3B5VG8gPSBHZXRDb3B5TmFtZXMocE5vdGUpCiAgICAgZW50cnkuQ2hhaXIg
PSBPd25lcgogICAgIGVudHJ5LlByaW5jaXBhbCA9IE93bmVyCiAgICAgZW50cnkudG1wT3duZXIg
PSBPd25lcgogICAgIGVudHJ5LkZyb20gPSBzZXNzaW9uLlVzZXJOYW1lCiAgICAgCiAgICAgCiAg
ICAgCiAgICAgSWYgKHBOb3RlLk5vdGljZVR5cGUoMCkgPD4gIkoiKSBUaGVuIENhbGwgQWRkQm9k
eVRvTmV3Tm90ZShlbnRyeSxwTm90ZSkgICAgICAgICAgCiAgICAgCidhZGQgZW50cnkgaXRlbXMg
ZGVwZW5kaW5nIHVwb24gcE5vdGUgdHlwZQogICAgIHNGb3JtID0gcE5vdGUuRm9ybSgwKQogICAg
IFNlbGVjdCBDYXNlIHNGb3JtCiAgICAgQ2FzZSAiTWVtbyIsIlJlcGx5IiwiVGFzayIsIlBlcnNv
bmFsIFN0YXRpb25lcnkiCiAgICAgICAgICBzdGFydGR0LlNldE5vdyAgICAgICAgICAKICAgICAg
ICAgIGVudHJ5LlN1YmplY3QgPSBwTm90ZS5TdWJqZWN0CidhZGQgdGhlIHN0YXJ0ZGF0ZXRpbWUs
IGVuZGRhdGV0aW1lLCB0aW1lcmFuZ2UsIGFuZCByZW1pbmRlciB0aW1lCiAgICAgICAgICBJZiAo
c0Zvcm0gPSAiVGFzayIpIFRoZW4KJ3RoaXMgaXMgYSB0YXNrCidmaXJzdCwgbG9vayBmb3IgYSBT
dGFydERhdGVUaW1lIGl0ZW0KICAgICAgICAgICAgICAgSWYgKHBOb3RlLlN0YXJ0RGF0ZVRpbWUo
MCkgPD4gIiIpIFRoZW4KICAgICAgICAgICAgICAgICAgICBTZXQgc3RhcnRpdGVtID0gcE5vdGUu
R2V0Rmlyc3RJdGVtKCJTdGFydERhdGVUaW1lIikgICAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICBTZXQgc3RhcnRkdCA9IE5ldyBOb3Rlc0RhdGVUaW1lKHN0YXJ0aXRlbS5EYXRlVGltZVZh
bHVlLkRhdGVPbmx5ICYgIiAiICYgc3RhcnRkdC5UaW1lT25seSkgICAgICAgICAgICAgICAgICAg
IAonaWYgd2UgZG9uJ3QgaGF2ZSBhIHN0YXJ0ZGF0ZSBpdGVtLCBsb29rIGZvciBhIGR1ZWRhdGUg
aXRlbSAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgIEVsc2VpZiAocE5vdGUuRHVl
RGF0ZVRpbWUoMCkgPD4gIiIpIFRoZW4KICAgICAgICAgICAgICAgICAgICBTZXQgc3RhcnRpdGVt
ID0gcE5vdGUuR2V0Rmlyc3RJdGVtKCJEdWVEYXRlVGltZSIpCiAgICAgICAgICAgICAgICAgICAg
U2V0IHN0YXJ0ZHQgPSBOZXcgTm90ZXNEYXRlVGltZShzdGFydGl0ZW0uRGF0ZVRpbWVWYWx1ZS5E
YXRlT25seSAmICIgIiAmIHN0YXJ0ZHQuVGltZU9ubHkpCiAgICAgICAgICAgICAgIEVuZCBJZgog
ICAgICAgICAgRW5kIElmCidzZXQgdGhlIHRpbWUgY29tcG9uZW50ICAgICAgICAgIAogICAgICAg
ICAgbk1pbnV0ZXMgPSBNaW51dGUoc3RhcnRkdC5MU0xvY2FsVGltZSkKICAgICAgICAgIG5TZWNv
bmRzID0gMCAtIFNlY29uZChzdGFydGR0LkxTTG9jYWxUaW1lKQogICAgICAgICAgCiAgICAgICAg
ICBJZiAobk1pbnV0ZXMgPiA0NSkgVGhlbiAgICAgICAgICAKICAgICAgICAgICAgICAgc3RhcnRk
dC5BZGp1c3RNaW51dGUoNjAgLSBuTWludXRlcykKICAgICAgICAgIEVsc2VpZiAobk1pbnV0ZXMg
PiAzMCkgVGhlbgogICAgICAgICAgICAgICBzdGFydGR0LkFkanVzdE1pbnV0ZSg0NSAtIG5NaW51
dGVzKQogICAgICAgICAgRWxzZWlmIChuTWludXRlcyA+IDE1KSBUaGVuCiAgICAgICAgICAgICAg
IHN0YXJ0ZHQuQWRqdXN0TWludXRlKDMwIC0gbk1pbnV0ZXMpCiAgICAgICAgICBFbHNlCiAgICAg
ICAgICAgICAgIHN0YXJ0ZHQuQWRqdXN0TWludXRlKDE1IC0gbk1pbnV0ZXMpCiAgICAgICAgICBF
bmQgSWYgICAgICAgICAgICAgICAKICAgICAgICAgIAogICAgICAgICAgc3RhcnRkdC5BZGp1c3RT
ZWNvbmQoblNlY29uZHMpCiAgICAgICAgICAKICAgICAgICAgIFNldCBlbnRyeS5TdGFydERhdGUg
PSBzdGFydGR0CiAgICAgICAgICBTZXQgZW50cnkuU3RhcnREYXRlVGltZSA9IHN0YXJ0ZHQKICAg
ICAgICAgIFNldCBlbnRyeS5SZW1pbmRlclRpbWUgPSBzdGFydGR0CiAgICAgICAgICAKICAgICAg
ICAgIFNldCBlbmRkdCA9IE5ldyBOb3Rlc0RhdGVUaW1lKHN0YXJ0ZHQuTFNMb2NhbFRpbWUpCiAg
ICAgICAgICBlbmRkdC5BZGp1c3RNaW51dGUocHJvZmlsZS5EZWZhdWx0RHVyYXRpb24oMCkpCiAg
ICAgICAgICAKICAgICAgICAgIFNldCB0cmRyID0gc2Vzc2lvbi5DcmVhdGVEYXRlUmFuZ2UKICAg
ICAgICAgIFNldCB0cmRyLlN0YXJ0RGF0ZVRpbWUgPSBzdGFydGR0CiAgICAgICAgICBTZXQgdHJk
ci5FbmREYXRlVGltZSA9IGVuZGR0CiAgICAgICAgICBTZXQgZW50cnkuVGltZVJhbmdlID0gdHJk
cgogICAgIENhc2UgIkFwcG9pbnRtZW50IiwiTm90aWNlIgogICAgICAgICAgSWYgKHNGb3JtID0g
IkFwcG9pbnRtZW50IikgVGhlbgogICAgICAgICAgICAgICBlbnRyeS5TdWJqZWN0ID0gcE5vdGUu
U3ViamVjdAogICAgICAgICAgRWxzZQogICAgICAgICAgICAgICBlbnRyeS5TdWJqZWN0ID0gcE5v
dGUuVG9waWMKICAgICAgICAgIEVuZCBJZgogICAgICAgICAgCidjb3B5IHRoZSBzdGFydGRhdGV0
aW1lLGVuZGRhdGV0aW1lLHRpbWVyYW5nZSwgYW5kIHJlbWluZGVyIHRpbWUKICAgICAgICAgIFNl
dCBlbnRyeWl0ZW0gPSBwTm90ZS5HZXRGaXJzdEl0ZW0oIlN0YXJ0RGF0ZVRpbWUiKSAgICAgICAg
ICAKICAgICAgICAgIElmIE5vdChlbnRyeWl0ZW0gSXMgTm90aGluZykgVGhlbgogICAgICAgICAg
ICAgICBDYWxsIGVudHJ5aXRlbS5Db3B5aXRlbVRvRG9jdW1lbnQoZW50cnksIlN0YXJ0RGF0ZSIp
CiAgICAgICAgICAgICAgIENhbGwgZW50cnlpdGVtLkNvcHlJdGVtVG9Eb2N1bWVudChlbnRyeSwi
U3RhcnREYXRlVGltZSIpCiAgICAgICAgICAgICAgIENhbGwgZW50cnlpdGVtLkNvcHlJdGVtVG9E
b2N1bWVudChlbnRyeSwiUmVtaW5kZXJUaW1lIikKICAgICAgICAgIEVuZCBJZgogICAgICAgICAg
CiAgICAgICAgICBTZXQgZW50cnlpdGVtID0gcE5vdGUuR2V0Rmlyc3RJdGVtKCJFbmREYXRlVGlt
ZSIpCiAgICAgICAgICBJZiBOb3QoZW50cnlpdGVtIElzIE5vdGhpbmcpIFRoZW4gQ2FsbCBlbnRy
eWl0ZW0uQ29weUl0ZW1Ub0RvY3VtZW50KGVudHJ5LCJFbmREYXRlVGltZSIpCiAgICAgICAgICAK
ICAgICAgICAgIFNldCBlbnRyeWl0ZW0gPSBwTm90ZS5HZXRGaXJzdEl0ZW0oIlRpbWVSYW5nZSIp
CiAgICAgICAgICBJZiBOb3QgKGVudHJ5aXRlbSBJcyBOb3RoaW5nKSBUaGVuIENhbGwgZW50cnlp
dGVtLkNvcHlJdGVtVG9Eb2N1bWVudChlbnRyeSwiVGltZVJhbmdlIikKICAgICBDYXNlIEVsc2UK
ICAgICAgICAgIHN0YXJ0ZHQuU2V0Tm93ICAgICAgICAgIAogICAgICAgICAgZW50cnkuU3ViamVj
dCA9IHBOb3RlLlN1YmplY3QKICAgICAgICAgIG5NaW51dGVzID0gTWludXRlKHN0YXJ0ZHQuTFNM
b2NhbFRpbWUpCiAgICAgICAgICBuU2Vjb25kcyA9IDAgLSBTZWNvbmQoc3RhcnRkdC5MU0xvY2Fs
VGltZSkKICAgICAgICAgIAogICAgICAgICAgSWYgKG5NaW51dGVzID4gNDUpIFRoZW4gICAgICAg
ICAgCiAgICAgICAgICAgICAgIHN0YXJ0ZHQuQWRqdXN0TWludXRlKDYwIC0gbk1pbnV0ZXMpCiAg
ICAgICAgICBFbHNlaWYgKG5NaW51dGVzID4gMzApIFRoZW4KICAgICAgICAgICAgICAgc3RhcnRk
dC5BZGp1c3RNaW51dGUoNDUgLSBuTWludXRlcykKICAgICAgICAgIEVsc2VpZiAobk1pbnV0ZXMg
PiAxNSkgVGhlbgogICAgICAgICAgICAgICBzdGFydGR0LkFkanVzdE1pbnV0ZSgzMCAtIG5NaW51
dGVzKQogICAgICAgICAgRWxzZQogICAgICAgICAgICAgICBzdGFydGR0LkFkanVzdE1pbnV0ZSgx
NSAtIG5NaW51dGVzKQogICAgICAgICAgRW5kIElmICAgICAgICAgICAgICAgCiAgICAgICAgICAK
ICAgICAgICAgIHN0YXJ0ZHQuQWRqdXN0U2Vjb25kKG5TZWNvbmRzKQogICAgICAgICAgCiAgICAg
ICAgICBTZXQgZW50cnkuU3RhcnREYXRlID0gc3RhcnRkdAogICAgICAgICAgU2V0IGVudHJ5LlN0
YXJ0RGF0ZVRpbWUgPSBzdGFydGR0CiAgICAgICAgICBTZXQgZW50cnkuUmVtaW5kZXJUaW1lID0g
c3RhcnRkdAogICAgICAgICAgCiAgICAgICAgICBTZXQgZW5kZHQgPSBOZXcgTm90ZXNEYXRlVGlt
ZShzdGFydGR0LkxTTG9jYWxUaW1lKQogICAgICAgICAgZW5kZHQuQWRqdXN0TWludXRlKHByb2Zp
bGUuRGVmYXVsdER1cmF0aW9uKDApKQogICAgICAgICAgCiAgICAgICAgICBTZXQgdHJkciA9IHNl
c3Npb24uQ3JlYXRlRGF0ZVJhbmdlCiAgICAgICAgICBTZXQgdHJkci5TdGFydERhdGVUaW1lID0g
c3RhcnRkdAogICAgICAgICAgU2V0IHRyZHIuRW5kRGF0ZVRpbWUgPSBlbmRkdAogICAgICAgICAg
U2V0IGVudHJ5LlRpbWVSYW5nZSA9IHRyZHIKICAgICBFbmQgU2VsZWN0CiAgICAgZW50cnkuRXhj
bHVkZUZyb21WaWV3ID0gIkQiCiAgICAgZW50cnkudG1wTmV3RG9jID0gVHJ1ZQogICAgIENhbGwg
d3MuRWRpdERvY3VtZW50KFRydWUsZW50cnkpCkVuZCBTdWIgICAKJysrTG90dXNTY3JpcHQgRGV2
ZWxvcG1lbnQgRW52aXJvbm1lbnQ6MjoyOkNyZWF0ZVRhc2s6MTo4ClN1YiBDcmVhdGVUYXNrKHBO
b3RlIEFzIE5vdGVzRG9jdW1lbnQpCiAgICAgCiAgICAgRGltIHRhc2sgQXMgTm90ZXNEb2N1bWVu
dAogICAgIERpbSBydGl0ZW0gQXMgTm90ZXNSaWNoVGV4dEl0ZW0KICAgICBEaW0gc1R5cGUgQXMg
U3RyaW5nCiAgICAgRGltIGR1ZWl0ZW0gQXMgTm90ZXNJdGVtCiAgICAgRGltIHRtcFNlbmRUbyBB
cyBWYXJpYW50CiAgICAgRGltIHRtcENvcHlUbyBBcyBWYXJpYW50CiAgICAgCiAgICAgU2V0IHRh
c2sgPSBOZXcgTm90ZXNEb2N1bWVudChkYikKICAgICAKJ2FkZCBzdGFuZGFyZCBpdGVtcwogICAg
IHRhc2suRm9ybSA9ICJUYXNrIgogICAgIHRhc2suQXNzaWduU3RhdGUgPSAwCiAgICAgdGFzay5P
cmdUYWJsZSA9ICJUMCIKICAgICAKICAgICBJZiAocE5vdGUuTm90aWNlVHlwZSgwKSA8PiAiSiIp
IFRoZW4gQ2FsbCBBZGRCb2R5VG9OZXdOb3RlKHRhc2sscE5vdGUpCidmb3IgdGFza3MsIHRoZSBj
YyA9IFNlbmRUbyArIENvcHlUbyAgICAgCiAgICAgdG1wU2VuZFRvID0gR2V0U2VuZE5hbWVzKHBO
b3RlKQogICAgIHRtcENvcHlUbyA9IEdldENvcHlOYW1lcyhwTm90ZSkKICAgICB0YXNrLnRtcENv
cHlUbzEgPSB0bXBTZW5kVG8KICAgICB0YXNrLnRtcENvcHlUbzIgPSB0bXBDb3B5VG8KICAgICB0
YXNrLkNvcHlUbyA9IEV2YWx1YXRlKCJAVHJpbSh0bXBDb3B5VG8xOnRtcENvcHlUbzIpIix0YXNr
KQogICAgIHRhc2suUmVtb3ZlSXRlbSAidG1wQ29weVRvMSIKICAgICB0YXNrLlJlbW92ZUl0ZW0g
InRtcENvcHlUbzIiCiAgICAgCiAgICAgdGFzay5+X1ZpZXdJY29uID0gMTY4CiAgICAgCidnZXQg
c3BlY2lmaWMgaXRlbXMgZnJvbSBwTm90ZSB0eXBlCiAgICAgc1R5cGUgPSBwTm90ZS5Gb3JtKDAp
CiAgICAgU2VsZWN0IENhc2Ugc1R5cGUKICAgICBDYXNlICJNZW1vIiwiUmVwbHkiCiAgICAgICAg
ICB0YXNrLlN1YmplY3QgPSBwTm90ZS5TdWJqZWN0CiAgICAgQ2FzZSAiQXBwb2ludG1lbnQiLCJO
b3RpY2UiCiAgICAgICAgICBJZiAoc1R5cGUgPSAiQXBwb2ludG1lbnQiKSBUaGVuCiAgICAgICAg
ICAgICAgIHRhc2suU3ViamVjdCA9IHBOb3RlLlN1YmplY3QKICAgICAgICAgIEVsc2UKICAgICAg
ICAgICAgICAgdGFza1N1YmplY3QgPSBwTm90ZS5Ub3BpYygwKQogICAgICAgICAgRW5kIElmCiAg
ICAgICAgICAKICAgICAgICAgIFNldCBkdWVpdGVtID0gcE5vdGUuR2V0Rmlyc3RJdGVtKCJTdGFy
dERhdGVUaW1lIikKICAgICAgICAgIENhbGwgZHVlaXRlbS5Db3B5SXRlbXRvRG9jdW1lbnQodGFz
aywiRHVlRGF0ZVRpbWUiKQogICAgIENhc2UgIlRhc2siCiAgICAgICAgICB0YXNrLlN1YmplY3Qg
PSBwTm90ZS5TdWJqZWN0CiAgICAgICAgICBJZiAocE5vdGUuU3RhcnREYXRlVGltZSgwKSA8PiAi
IikgVGhlbgogICAgICAgICAgICAgICBTZXQgZHVlaXRlbSA9IHBOb3RlLkdldEZpcnN0SXRlbSgi
U3RhcnREYXRlVGltZSIpCiAgICAgICAgICAgICAgIENhbGwgZHVlaXRlbS5Db3B5SXRlbVRvRG9j
dW1lbnQodGFzaywiU3RhcnREYXRlVGltZSIpCiAgICAgICAgICBFbmQgSWYKICAgICAgICAgIElm
IChwTm90ZS5EdWVEYXRlVGltZSgwKSA8PiAiIikgVGhlbgogICAgICAgICAgICAgICBTZXQgZHVl
aXRlbSA9IHBOb3RlLkdldEZpcnN0SXRlbSgiRHVlRGF0ZVRpbWUiKQogICAgICAgICAgICAgICBD
YWxsIGR1ZWl0ZW0uQ29weUl0ZW1Ub0RvY3VtZW50KHRhc2ssIkR1ZURhdGVUaW1lIikKICAgICAg
ICAgIEVuZCBJZgogICAgIENhc2UgRWxzZQonbm90IHN1cmUgd2hhdCB3ZSBoYXZlLCBzbyBhc3N1
bWUgc3ViamVjdCBpdGVtIGV4aXN0cywgYnV0IGRvbid0IHByZWZpbGwtaW4gYW55IGRhdGUgaW5m
bwogICAgICAgICAgdGFzay5TdWJqZWN0ID0gcE5vdGUuU3ViamVjdCAgICAgICAgIAogICAgIEVu
ZCBTZWxlY3QKICAgICB0YXNrLkV4Y2x1ZGVGcm9tVmlldyA9ICJEIgogICAgIHRhc2sudG1wbmV3
ZG9jID0gVHJ1ZQogICAgIENhbGwgd3MuRWRpdERvY3VtZW50KFRydWUsdGFzaykKRW5kIFN1Ygon
KytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjE6R2V0U2VuZE5hbWVzOjE6
OApGdW5jdGlvbiBHZXRTZW5kTmFtZXMocE5vdGUgQXMgTm90ZXNEb2N1bWVudCkgQXMgVmFyaWFu
dAogICAgIERpbSBzU2VuZEl0ZW0gQXMgU3RyaW5nCiAgICAgRGltIHZTZW5kTmFtZXMgQXMgVmFy
aWFudAogICAgIERpbSB2UmV0TmFtZXMoKSBBcyBWYXJpYW50CiAgICAgRGltIG5JdGVtcyBBcyBJ
bnRlZ2VyCiAgICAgRGltIHggQXMgSW50ZWdlcgogICAgIERpbSBuYW1Vc2VyIEFzIE5ldyBOb3Rl
c05hbWUoc2Vzc2lvbi5Vc2VyTmFtZSkKICAgICBEaW0gbmFtIEFzIE5vdGVzTmFtZQogICAgIAog
ICAgIFNlbGVjdCBDYXNlIHBOb3RlLkZvcm0oMCkKICAgICBDYXNlICJNZW1vIiwiUmVwbHkiCiAg
ICAgICAgICBzU2VuZEl0ZW0gPSAiU2VuZFRvIgogICAgIENhc2UgIkFwcG9pbnRtZW50IiwiTm90
aWNlIgogICAgICAgICAgc1NlbmRJdGVtID0gIlJlcXVpcmVkQXR0ZW5kZWVzIgogICAgIENhc2Ug
RWxzZQogICAgICAgICAgc1NlbmRJdGVtID0gIlNlbmRUbyIKICAgICBFbmQgU2VsZWN0CiAgICAg
CiAgICAgdlNlbmROYW1lcyA9IHBOb3RlLkdldEl0ZW1WYWx1ZShzU2VuZEl0ZW0pCiAgICAgCiAg
ICAgSWYgKHZTZW5kTmFtZXMoMCkgPSAiIikgQW5kIChVYm91bmQodlNlbmROYW1lcykgPSAwKSBU
aGVuCiAgICAgICAgICBuSXRlbXMgPSAxCiAgICAgRWxzZQogICAgICAgICAgbkl0ZW1zID0gVWJv
dW5kKHZTZW5kTmFtZXMpICsgMgogICAgIEVuZCBJZgogICAgIFJlZGltIHZSZXROYW1lcyhuSXRl
bXMpCiAgICAgCiAgICAgRm9yYWxsIG5hbWVzIEluIHZTZW5kTmFtZXMKJ21ha2Ugc3VyZSB3ZSBk
b24ndCBoYXZlIGEgYmxhbmsgdmFsdWUgJiB0aGUgbmFtZSA8PiBjdXJyZW50IHVzZXIgICAgICAg
ICAgCiAgICAgICAgICBJZiAobmFtZXMgPD4gIiIpIFRoZW4KICAgICAgICAgICAgICAgU2V0IG5h
bSA9IE5ldyBOb3Rlc05hbWUobmFtZXMpCiAgICAgICAgICAgICAgIElmIExjYXNlKG5hbS5Db21t
b24pIDw+IExjYXNlKG5hbVVzZXIuQ29tbW9uKSBUaGVuCiAgICAgICAgICAgICAgICAgICAgdlJl
dE5hbWVzKHgpID0gbmFtZXMKICAgICAgICAgICAgICAgICAgICB4ID0geCsxCiAgICAgICAgICAg
ICAgIEVuZCBJZgogICAgICAgICAgRW5kIElmCiAgICAgRW5kIEZvcmFsbAogICAgIAogICAgIElm
IChwTm90ZS5IYXNJdGVtKCJQcmluY2lwYWwiKSkgVGhlbgogICAgICAgICAgU2V0IG5hbSA9IE5l
dyBOb3Rlc05hbWUocE5vdGUuUHJpbmNpcGFsKDApKQogICAgICAgICAgSWYgTGNhc2UobmFtLkNv
bW1vbikgPD4gTGNhc2UobmFtVXNlci5Db21tb24pIFRoZW4KICAgICAgICAgICAgICAgSWYgKHBO
b3RlLkhhc0l0ZW0oIkZyb21Eb21haW4iKSkgVGhlbiAgICAgICAgICAKICAgICAgICAgICAgICAg
ICAgICB2UmV0TmFtZXMoeCkgPSBwTm90ZS5QcmluY2lwYWwoMCkgJiAiQCIgJiBwTm90ZS5Gcm9t
RG9tYWluKDApCiAgICAgICAgICAgICAgIEVsc2UKICAgICAgICAgICAgICAgICAgICB2UmV0TmFt
ZXMoeCkgPSBwTm90ZS5QcmluY2lwYWwoMCkKICAgICAgICAgICAgICAgRW5kIElmCiAgICAgICAg
ICBFbmQgSWYKICAgICBFbHNlCiAgICAgICAgICBTZXQgbmFtID0gTmV3IE5vdGVzTmFtZShwTm90
ZS5Gcm9tKDApKQogICAgICAgICAgSWYgTGNhc2UobmFtLkNvbW1vbikgPD4gTGNhc2UobmFtVXNl
ci5Db21tb24pIFRoZW4KICAgICAgICAgICAgICAgSWYgKHBOb3RlLkhhc0l0ZW0oIkZyb21Eb21h
aW4iKSkgVGhlbiAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICB2UmV0bmFtZXMoeCkgPSBw
Tm90ZS5Gcm9tKDApICYgIkAiICYgcE5vdGUuRnJvbURvbWFpbigwKQogICAgICAgICAgICAgICBF
bHNlCiAgICAgICAgICAgICAgICAgICAgdlJldE5hbWVzKHgpID0gcE5vdGUuRnJvbSgwKQogICAg
ICAgICAgICAgICBFbmQgSWYKICAgICAgICAgIEVuZCBJZgogICAgIEVuZCBJZgogICAgIAogICAg
IEdldFNlbmROYW1lcyA9IHZSZXROYW1lcwogICAgIApFbmQgRnVuY3Rpb24gIAonKytMb3R1c1Nj
cmlwdCBEZXZlbG9wbWVudCBFbnZpcm9ubWVudDoyOjE6R2V0Q29weU5hbWVzOjE6OApGdW5jdGlv
biBHZXRDb3B5TmFtZXMocE5vdGUgQXMgTm90ZXNEb2N1bWVudCkgQXMgVmFyaWFudAogICAgIERp
bSBzQ29weUl0ZW0gQXMgU3RyaW5nCiAgICAgRGltIHZDb3B5TmFtZXMgQXMgVmFyaWFudAogICAg
IERpbSB2UmV0bmFtZXMoKSBBcyBWYXJpYW50CiAgICAgRGltIHggQXMgSW50ZWdlcgogICAgIERp
bSBuSXRlbXMgQXMgSW50ZWdlcgogICAgIERpbSBuYW1Vc2VyIEFzIE5ldyBOb3Rlc05hbWUoc2Vz
c2lvbi5Vc2VyTmFtZSkKICAgICAKICAgICBTZWxlY3QgQ2FzZSBwTm90ZS5Gb3JtKDApCiAgICAg
Q2FzZSAiTWVtbyIsIlJlcGx5IgogICAgICAgICAgc0NvcHlJdGVtID0gIkNvcHlUbyIKICAgICBD
YXNlICJBcHBvaW50bWVudCIsIk5vdGljZSIKICAgICAgICAgIHNDb3B5SXRlbSA9ICJPcHRpb25h
bEF0dGVuZGVlcyIKICAgICBDYXNlIEVsc2UKICAgICAgICAgIHNDb3B5SXRlbSA9ICJDb3B5VG8i
CiAgICAgRW5kIFNlbGVjdAogICAgIAogICAgIHZDb3B5TmFtZXMgPSBwTm90ZS5HZXRJdGVtVmFs
dWUoc0NvcHlJdGVtKQogICAgIAogICAgIElmICh2Q29weU5hbWVzKDApID0gIiIpIEFuZCAoVWJv
dW5kKHZDb3B5TmFtZXMpID0gMCkgVGhlbgogICAgICAgICAgbkl0ZW1zID0gMQogICAgIEVsc2UK
ICAgICAgICAgIG5JdGVtcyA9IFVib3VuZCh2Q29weU5hbWVzKSArIDEKICAgICBFbmQgSWYKICAg
ICAKICAgICBSZWRpbSB2UmV0TmFtZXMobkl0ZW1zKQogICAgIAogICAgIEZvcmFsbCBuYW1lcyBJ
biB2Q29weU5hbWVzCiAgICAgICAgICBJZiAobmFtZXMgPD4gIiIpIFRoZW4KICAgICAgICAgICAg
ICAgU2V0IG5hbSA9IE5ldyBOb3Rlc05hbWUobmFtZXMpCiAgICAgICAgICAgICAgIElmIExjYXNl
KG5hbS5Db21tb24pIDw+IExjYXNlKG5hbVVzZXIuQ29tbW9uKSBUaGVuCiAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgdlJldE5hbWVzKHgpID0gbmFtZXMKICAgICAgICAg
ICAgICAgICAgICB4ID0geCsxCiAgICAgICAgICAgICAgIEVuZCBJZiAgICAgICAgICAgICAgIAog
ICAgICAgICAgRW5kIElmCiAgICAgRW5kIEZvcmFsbAogICAgIAogICAgIEdldENvcHlOYW1lcyA9
IHZSZXROYW1lcwpFbmQgRnVuY3Rpb24gIAonKytMb3R1c1NjcmlwdCBEZXZlbG9wbWVudCBFbnZp
cm9ubWVudDoyOjI6QWRkQm9keVRvTmV3Tm90ZToxOjgKU3ViIEFkZEJvZHlUb05ld05vdGUocE5l
d05vdGUgQXMgTm90ZXNEb2N1bWVudCwgcFNvdXJjZU5vdGUgQXMgTm90ZXNEb2N1bWVudCkKICAg
ICBEaW0gcnRpdGVtU291cmNlIEFzIE5vdGVzUmljaFRleHRJdGVtCiAgICAgRGltIHJ0aXRlbU5l
dyBBcyBOb3Rlc1JpY2hUZXh0SXRlbQogICAgIERpbSBkdGl0ZW0gQXMgTm90ZXNJdGVtCiAgICAg
CiAgICAgSWYgTm90KGJPa1RvQ29weSkgVGhlbiBFeGl0IFN1YgogICAgIAonZmlyc3QsIGdldCB0
aGUgYm9keSBmaWVsZCBvZiB0aGUgc291cmNlIG5vdGUKICAgICBTZXQgcnRpdGVtU291cmNlID0g
cFNvdXJjZU5vdGUuR2V0Rmlyc3RJdGVtKCJCb2R5IikKICAgICAKICAgICAKJ25vdywgY3JlYXRl
IHRoZSBuZXcgQm9keSBpdGVtCiAgICAgU2V0IHJ0aXRlbU5ldyA9IE5ldyBOb3Rlc1JpY2hUZXh0
SXRlbShwTmV3Tm90ZSwiQm9keSIpCiAgICAgcnRpdGVtTmV3LkFkZE5ld0xpbmUoMikKICAgICBy
dGl0ZW1OZXcuQXBwZW5kVGV4dCAiLS0tLS0tLS0tLS0tLS0tIgogICAgIHJ0aXRlbU5ldy5BZGRO
ZXdMaW5lKDEpCiAgICAgCiAgICAgCiAgICAgU2VsZWN0IENhc2UgcFNvdXJjZU5vdGUuRm9ybSgw
KQogICAgIENhc2UgIkFwcG9pbnRtZW50IiwiTm90aWNlIgogICAgICAgICAgSWYgKHBTb3VyY2VO
b3RlLlN0YXJ0RGF0ZVRpbWUoMCkgPD4gIiIpIFRoZW4KICAgICAgICAgICAgICAgU2V0IGR0aXRl
bSA9IHBTb3VyY2VOb3RlLkdldEZpcnN0SXRlbSgiU3RhcnREYXRlVGltZSIpICAgICAgICAgIAog
ICAgICAgICAgICAgICBDYWxsIHJ0aXRlbU5ldy5BcHBlbmRUZXh0KCJTdGFydDoiKQogICAgICAg
ICAgICAgICBydGl0ZW1OZXcuQWRkVGFiKDEpCiAgICAgICAgICAgICAgIHJ0aXRlbU5ldy5BcHBl
bmRUZXh0KGR0aXRlbS5WYWx1ZXMoMCkpCiAgICAgICAgICAgICAgIENhbGwgcnRpdGVtTmV3LkFk
ZE5ld0xpbmUoMSkKICAgICAgICAgIEVuZCBJZgogICAgICAgICAgSWYgKHBTb3VyY2VOb3RlLkVu
ZERhdGVUaW1lKDApIDw+ICIiKSBUaGVuCiAgICAgICAgICAgICAgIFNldCBkdGl0ZW0gPSBwU291
cmNlTm90ZS5HZXRGaXJzdEl0ZW0oIkVuZERhdGVUaW1lIikgICAgICAgICAgCiAgICAgICAgICAg
ICAgIENhbGwgcnRpdGVtTmV3LkFwcGVuZFRleHQoIkVuZDoiKQogICAgICAgICAgICAgICBydGl0
ZW1OZXcuQWRkVGFiKDEpCiAgICAgICAgICAgICAgIHJ0aXRlbU5ldy5BcHBlbmRUZXh0KGR0aXRl
bS5WYWx1ZXMoMCkpCiAgICAgICAgICAgICAgIENhbGwgcnRpdGVtTmV3LkFkZE5ld0xpbmUoMSkK
ICAgICAgICAgIEVuZCBJZgogICAgICAgICAgcnRpdGVtTmV3LkFkZE5ld0xpbmUoMikKICAgICBD
YXNlICJUYXNrIgogICAgICAgICAgSWYgKHBTb3VyY2VOb3RlLlN0YXJ0RGF0ZVRpbWUoMCkgPD4g
IiIpIFRoZW4KICAgICAgICAgICAgICAgU2V0IGR0aXRlbSA9IHBTb3VyY2VOb3RlLkdldEZpcnN0
SXRlbSgiU3RhcnREYXRlVGltZSIpICAgICAgICAgIAogICAgICAgICAgICAgICBDYWxsIHJ0aXRl
bU5ldy5BcHBlbmRUZXh0KCJTdGFydCBkYXRlOiIpCiAgICAgICAgICAgICAgIHJ0aXRlbU5ldy5B
ZGRUYWIoMSkKICAgICAgICAgICAgICAgcnRpdGVtTmV3LkFwcGVuZFRleHQoZHRpdGVtLlZhbHVl
cygwKSkKICAgICAgICAgICAgICAgQ2FsbCBydGl0ZW1OZXcuQWRkTmV3TGluZSgxKQogICAgICAg
ICAgRW5kIElmCiAgICAgICAgICBJZiAocFNvdXJjZU5vdGUuRHVlRGF0ZVRpbWUoMCkgPD4gIiIp
IFRoZW4KICAgICAgICAgICAgICAgU2V0IGR0aXRlbSA9IHBTb3VyY2VOb3RlLkdldEZpcnN0SXRl
bSgiRHVlRGF0ZVRpbWUiKSAgICAgICAgICAKICAgICAgICAgICAgICAgQ2FsbCBydGl0ZW1OZXcu
QXBwZW5kVGV4dCgiRHVlIGRhdGU6IikKICAgICAgICAgICAgICAgcnRpdGVtTmV3LkFkZFRhYigx
KQogICAgICAgICAgICAgICBydGl0ZW1OZXcuQXBwZW5kVGV4dChkdGl0ZW0uVmFsdWVzKDApKQog
ICAgICAgICAgICAgICBDYWxsIHJ0aXRlbU5ldy5BZGROZXdMaW5lKDEpCiAgICAgICAgICBFbmQg
SWYgICAgICAgICAgCiAgICAgICAgICBydGl0ZW1OZXcuQWRkTmV3TGluZSgyKQogICAgIEVuZCBT
ZWxlY3QKICAgICBJZiBOb3QocnRpdGVtU291cmNlIElzIE5vdGhpbmcpIFRoZW4gQ2FsbCBydGl0
ZW1OZXcuQXBwZW5kUlRJdGVtKHJ0aXRlbVNvdXJjZSkKRW5kIFN1YgABACwBTFNPQgMAFABlbgAA
BACfAEwQAgCEAMwWHBMYAAAABABsCGQTAAAAACQArAAYADgAAABAAlQAAAAAAAAADQAAABgAeBQA
AAAAUAdQBwAAAACwAHgUlAMQBwAAAADsApwFGABUBuQE5ARwB3AHAAAAAAAAAAAAAAAACAAAAIgH
bA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgCKgJQAlsD4gHVA8AAAAAsAuwCwAAAAAAAAAACgAA
AGQBZBNkAbwKAAAAAHgI+AmkDaQNKAJkEwAAAAAAAAAAxAzEDAAAAAAAAAAAmAeYB0QORA4AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAwD8DwAAAADEAggAKgAyAEEAOABDADkAMAA0AAAAAABsAAMATgBFAFcAAACAAAYARABFAEwA
RQBUAEUAAAAAAPAACgBJAE4ASQBUAEkAQQBMAEkAWgBFAAAAAACIAAkAVABFAFIATQBJAE4AQQBU
AEUAAADYAQYATwBCAEoARQBDAFQAAAAAAAgBAAAAAAAAPAEPAE8AYgBqAGUAYwB0AFYAYQByAGkA
YQBiAGwAZQBzAAAA0AAPAE8AQgBKAEUAQwBUAFYAQQBSAEkAQQBCAEwARQBTAAAAEAMMAEMAUgBF
AEEAVABFAE4ARQBXAEQATwBDAAAAcgAsAQgATgBEAE8AQwBUAFkAUABFAAAAVQC8AQ4AQwBSAEUA
QQBUAEUATQBBAEkATABNAEUATQBPAAAACABcAQUAUABOAE8AVABFAAAAcAENAE4ATwBUAEUAUwBE
AE8AQwBVAE0ARQBOAFQAAAD4AQYAJQBMAFMAWABCAEUAAAAAAJABDQBOAE8AVABFAFMARABBAFQA
QQBCAEEAUwBFAAAAGAITAEMAUgBFAEEAVABFAEMAQQBMAEUATgBEAEEAUgBFAE4AVABSAFkAAAC8
AwoAQwBSAEUAQQBUAEUAVABBAFMASwAAAJQNRAMMAEcARQBUAFMARQBOAEQATgBBAE0ARQBTAAAA
AABYAgwARwBFAFQAQwBPAFAAWQBOAEEATQBFAFMAAAAAAFgDEABBAEQARABCAE8ARABZAFQATwBO
AEUAVwBOAE8AVABFAAAAAAB0AggAUABOAEUAVwBOAE8AVABFAAAAAQCMAgsAUABTAE8AVQBSAEMA
RQBOAE8AVABFAAAArAIIAE4ARQBXAF8ATQBFAE0ATwAAAAAA3AIMAE4ARQBXAF8AQwBBAEwARQBO
AEQAQQBSAAAAAADwAggATgBFAFcAXwBUAEEAUwBLAAAAAABkAwkAQgBPAEsAVABPAEMATwBQAFkA
AAAIBQcAUwBFAFMAUwBJAE8ATgAAABwDDABOAE8AVABFAFMAUwBFAFMAUwBJAE8ATgAAABAAuAYC
AFcAUwAAAAAAmAMQAE4ATwBUAEUAUwBVAEkAVwBPAFIASwBTAFAAQQBDAEUAAACMBfgEBgAlAEwA
UwBYAFUASQAAAAAAiAMCAEQAQgAAAAAAxAQPAEMAVQBSAFIARQBOAFQARABBAFQAQQBCAEEAUwBF
AAAAPAQFAFUASQBEAE8AQwAAAEwEDwBDAFUAUgBSAEUATgBUAEQATwBDAFUATQBFAE4AVAAAANQD
CABJAFMATgBFAFcARABPAEMAAAAAAHwFMQBUAGgAaQBzACAAYQBjAHQAaQBvAG4AIABjAGEAbgBu
AG8AdAAgAGIAZQAgAGUAeABlAGMAdQB0AGUAZAAgAG8AbgAgAGEAIABuAGUAdwAgAGQAbwBjAHUA
bQBlAG4AdAAuAAAAdAQFAEUAcgByAG8AcgAAAFwEBABOAE8AVABFAAAAAADIBggARABPAEMAVQBN
AEUATgBUAAAAAACUBAwAUwBFAEwARQBDAFQARQBEAEQATwBDAFMAAAD8BqQFFABVAE4AUABSAE8A
QwBFAFMAUwBFAEQARABPAEMAVQBNAEUATgBUAFMAAAAAACQHFwBOAE8AVABFAFMARABPAEMAVQBN
AEUATgBUAEMATwBMAEwARQBDAFQASQBPAE4AAADcBgUAQwBPAFUATgBUAAAABAc3AFAAbABlAGEA
cwBlACAAcwBlAGwAZQBjAHQAIABhACAAZABvAGMAdQBtAGUAbgB0ACAAYgBlAGYAbwByAGUAIABl
AHgAZQBjAHUAdABpAG4AZwAgAHQAaABpAHMAIABjAG8AbQBtAGEAbgBkAC4AAADEBRAARwBFAFQA
RgBJAFIAUwBUAEQATwBDAFUATQBFAE4AVAAAAAEAeAcMACQASwBFAEUAUABQAFIASQBWAEEAVABF
AAAAAADMBQEAMQAAAKQGaABUAGgAaQBzACAAZABvAGMAdQBtAGUAbgB0ACAAaQBzACAAcAByAGUA
dgBlAG4AdABlAGQAIABmAHIAbwBtACAAYgBlAGkAbgBnACAAYwBvAHAAaQBlAGQALgAgAFQAaABl
ACAAYgBvAGQAeQAgAHcAaQBsAGwAIABuAG8AdAAgAGIAZQAgAGMAbwBwAGkAZQBkACAAaQBuAHQA
bwAgAHQAaABlACAAbgBlAHcAIABkAG8AYwB1AG0AZQBuAHQAIABjAHIAZQBhAHQAZQBkAC4AAAAA
ADwHBwBXAGEAcgBuAGkAbgBnAAAAFAcEAE0AQQBJAEwAAAAAALAHBgBSAFQASQBUAEUATQAAAAAA
VAgRAE4ATwBUAEUAUwBSAEkAQwBIAFQARQBYAFQASQBUAEUATQAAAGwIBABGAE8AUgBNAAAAwAA4
CAQATQBlAG0AbwAAAAAAZAcJAFAAUgBJAE4AQwBJAFAAQQBMAAAATAcFAE8AVwBOAEUAUgAAAIQI
CQBUAE0AUABTAEUATgBEAFQATwAAAMgHBgBTAEUATgBEAFQATwAAACgCFAgZAEAAVAByAGkAbQAo
AEAAVQBuAGkAcQB1AGUAKAB0AG0AcABTAGUAbgBkAFQAbwApACkAAADcBwkAVABNAFAAQwBPAFAA
WQBUAE8AAAAwCAYAQwBPAFAAWQBUAE8AAAAJAtAJGQBAAFQAcgBpAG0AKABAAFUAbgBpAHEAdQBl
ACgAdABtAHAAQwBvAHAAeQBUAG8AKQApAAAAsAgKAE4ATwBUAEkAQwBFAFQAWQBQAEUAAAAAAOgI
AQBKAAAAlAgKAFIARQBNAE8AVgBFAEkAVABFAE0AAAAAAGwKCQB0AG0AcABTAGUAbgBkAFQAbwAA
AGwJCQB0AG0AcABDAG8AcAB5AFQAbwAAANQIBQBSAGUAcABsAHkAAAD4CAsAQQBwAHAAbwBpAG4A
dABtAGUAbgB0AAAAwAgEAFQAYQBzAGsAAACUEFQJBwBTAFUAQgBKAEUAQwBUAAAACAkGAE4AbwB0
AGkAYwBlAAAAAAA4CQUAVABPAFAASQBDAAAAjAkEAEwATwBHAE8AAAAAAFQLFABHAEUAVABFAE4A
VgBJAFIATwBOAE0ARQBOAFQAUwBUAFIASQBOAEcAAABpEIQKCwBEAGUAZgBhAHUAbAB0AEwAbwBn
AG8AAADgCQkAVABNAFAATgBFAFcARABPAEMAAACwCQwARQBEAEkAVABEAE8AQwBVAE0ARQBOAFQA
AAC8CpwJBQBFAE4AVABSAFkAAADwCQcAUwBUAEEAUgBUAEQAVAAAABQKDQBOAE8AVABFAFMARABB
AFQARQBUAEkATQBFAAAALAoFAEUATgBEAEQAVAAAAEQKBABUAFIARABSAAAAGQBUCg4ATgBPAFQA
RQBTAEQAQQBUAEUAUgBBAE4ARwBFAAAA1A+0CwkARQBOAFQAUgBZAEkAVABFAE0AAADACgkATgBP
AFQARQBTAEkAVABFAE0AAACYCgUAUwBGAE8AUgBNAAAALAsIAE4ATQBJAE4AVQBUAEUAUwAAABkA
5AoIAE4AUwBFAEMATwBOAEQAUwAAABkARAwHAFAAUgBPAEYASQBMAEUAAAAUCxAARwBFAFQAQwBB
AEwARQBOAEQAQQBSAE8AVwBOAEUAUgAAABkABAsPAEEAUABQAE8ASQBOAFQATQBFAE4AVABUAFkA
UABFAAAAgAsMAEMAQQBMAEUATgBUAFIAWQBUAFkAUABFAAAAMBE8CwUAQwBIAEEASQBSAAAATAwI
AFQATQBQAE8AVwBOAEUAUgAAADARzAsEAEYAUgBPAE0AAAATKewLCABVAFMARQBSAE4AQQBNAEUA
AAAAAJQNEwBQAGUAcgBzAG8AbgBhAGwAIABTAHQAYQB0AGkAbwBuAGUAcgB5AAAAlAsGAFMARQBU
AE4ATwBXAAAAxAz4DA0AUwBUAEEAUgBUAEQAQQBUAEUAVABJAE0ARQAAAAwMCQBTAFQAQQBSAFQA
SQBUAEUATQAAAKwNDABHAEUAVABGAEkAUgBTAFQASQBUAEUATQAAAAAAuAwNAFMAdABhAHIAdABE
AGEAdABlAFQAaQBtAGUAAAAsDA0ARABBAFQARQBUAEkATQBFAFYAQQBMAFUARQAAAIAMCABEAEEA
VABFAE8ATgBMAFkAAAAAAGQMAQAgAAAAnAwIAFQASQBNAEUATwBOAEwAWQAAAAAAKBALAEQAVQBF
AEQAQQBUAEUAVABJAE0ARQAAADANCwBEAHUAZQBEAGEAdABlAFQAaQBtAGUAAADYDAsATABTAEwA
TwBDAEEATABUAEkATQBFAAAAeA0MAEEARABKAFUAUwBUAE0ASQBOAFUAVABFAAAAAADwDQwAQQBE
AEoAVQBTAFQAUwBFAEMATwBOAEQAAAABABANCQBTAFQAQQBSAFQARABBAFQARQAAAFQNDABSAEUA
TQBJAE4ARABFAFIAVABJAE0ARQAAAAYIpA4PAEQARQBGAEEAVQBMAFQARABVAFIAQQBUAEkATwBO
AAAA2A0PAEMAUgBFAEEAVABFAEQAQQBUAEUAUgBBAE4ARwBFAAAAEA4LAEUATgBEAEQAQQBUAEUA
VABJAE0ARQAAACwOCQBUAEkATQBFAFIAQQBOAEcARQAAAEQOEgBDAE8AUABZAEkAVABFAE0AVABP
AEQATwBDAFUATQBFAE4AVAAAAAAA5A4JAFMAdABhAHIAdABEAGEAdABlAAAAgA4MAFIAZQBtAGkA
bgBkAGUAcgBUAGkAbQBlAAAA6DRoDgsARQBuAGQARABhAHQAZQBUAGkAbQBlAAAAHA8JAFQAaQBt
AGUAUgBhAG4AZwBlAAAAcA4PAEUAWABDAEwAVQBEAEUARgBSAE8ATQBWAEkARQBXAAAAkA4BAEQA
AAD8EAQAVABBAFMASwAAAAIAAA8FAFMAVABZAFAARQAAAMAOBwBEAFUARQBJAFQARQBNAAAArA8L
AEEAUwBTAEkARwBOAFMAVABBAFQARQAAANgOCABPAFIARwBUAEEAQgBMAEUAAAAQBVwPAgBUADAA
AAAAAHgPCgBUAE0AUABDAE8AUABZAFQATwAxAAAAysAwEAoAVABNAFAAQwBPAFAAWQBUAE8AMgAA
AAAAlA8cAEAAVAByAGkAbQAoAHQAbQBwAEMAbwBwAHkAVABvADEAOgB0AG0AcABDAG8AcAB5AFQA
bwAyACkAAAAUAPwPCgB0AG0AcABDAG8AcAB5AFQAbwAxAAAAAADgDwoAdABtAHAAQwBvAHAAeQBU
AG8AMgAAABkAnBEJAF8AVgBJAEUAVwBJAEMATwBOAAAAyA8LAFQAQQBTAEsAUwBVAEIASgBFAEMA
VAAAABQQCQBTAFMARQBOAEQASQBUAEUATQAAAGgQCgBWAFMARQBOAEQATgBBAE0ARQBTAAMAKAP4
DwAAAAAAAMQQCQBWAFIARQBUAE4AQQBNAEUAUwAAAFQRBgBOAEkAVABFAE0AUwAAALQS1BABAFgA
AABEEAcATgBBAE0AVQBTAEUAUgAAAFwQCQBOAE8AVABFAFMATgBBAE0ARQAAABQRAwBOAEEATQAA
AHwQBgBTAGUAbgBkAFQAbwAAAAkCpBARAFIAZQBxAHUAaQByAGUAZABBAHQAdABlAG4AZABlAGUA
cwAAAFgSDABHAEUAVABJAFQARQBNAFYAQQBMAFUARQAAAAIAfBIFAE4AQQBNAEUAUwAAAOgQBgBD
AE8ATQBNAE8ATgAAABkAIBIHAEgAQQBTAEkAVABFAE0AAAAwEQkAUAByAGkAbgBjAGkAcABhAGwA
AAA4EQoARgByAG8AbQBEAG8AbQBhAGkAbgAAAPcCiBEBAEAAAAAQEgoARgBSAE8ATQBEAE8ATQBB
AEkATgAAAAAAbBEJAFMAQwBPAFAAWQBJAFQARQBNAAAA/BEKAFYAQwBPAFAAWQBOAEEATQBFAFMA
AAAJAMQRBgBDAG8AcAB5AFQAbwAAAAAA5BERAE8AcAB0AGkAbwBuAGEAbABBAHQAdABlAG4AZABl
AGUAcwAAAKQSDABSAFQASQBUAEUATQBTAE8AVQBSAEMARQAAAEcA//8JAFIAVABJAFQARQBNAE4A
RQBXAAAAPBIGAEQAVABJAFQARQBNAAAAQQDkEgQAQgBvAGQAeQAAAE4AyBIKAEEARABEAE4ARQBX
AEwASQBOAEUAAABHAP//CgBBAFAAUABFAE4ARABUAEUAWABUAAAAdACQEg8ALQAtAC0ALQAtAC0A
LQAtAC0ALQAtAC0ALQAtAC0AAAC4EgYAUwB0AGEAcgB0ADoAAAAaXP//BgBBAEQARABUAEEAQgAA
AH24//8GAFYAQQBMAFUARQBTAAAAS/j8EgQARQBuAGQAOgAAACy4//8LAFMAdABhAHIAdAAgAGQA
YQB0AGUAOgAAAP//CQBEAHUAZQAgAGQAYQB0AGUAOgAAAP//DABBAFAAUABFAE4ARABSAFQASQBU
AEUATQAAALgaBQD8DwAAAADAi1aaGAAAAAAAsAB4OvcCAAAAAAAAAAAIAAAAsAA8BDwAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEADsAjAH1AAAAAAAAAACAAAASAHECQAAAAAAAAAAAAAA
AAAAAABIAUgBAAAAAMQJxAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAACgAAABAAAAAQAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAwABAMQJAAD0AAEAAAAAABoAAABgAQAAAAAAABAABAAoArwKQAEAAAAAAAAEAAAACAzMFAAA
AAAAAAAAAAAAAGQQZBDMFMwUCAwIDAAAAAAAAAAAAAAAAAAAAAAAAAAARBREFAAAAAAEFBMp7S5p
EL9dAN0BEYa3AAAAAAAAAAAAAAAAAAAAAGQAAABgjoMCAAAAAAAAAAACAFgB9AEAACgCAAACAAEA
AAAAABIAFAAAAAAA//8JAgAAAACNBAAAAABkAVgBAAAAAAAABgACAAAACQJkAQkCZAEJAigCGQAQ
AAAAmAdkE3QBAAAAAAAAAQAAANQJ1AkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAANQJ1AkAAAAAAhQTKe0uaRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAYI6D
AgAAAAAAAAAAAgBYAbgCAAAAAAAAAgABAAAAAAASABQAAAAAAP//CQIAAAAAEgQAAAAAKAJYAQAA
AAAAAAYAAwAAAAkCKAIJAigCBggGCBkACAAQAJQDnAUMAQAAAAAAAAMAAACEA4ALAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAgAuAC4QDhAMAAAAAAAAAAKwKrAoAAAAAAAAAAAEAAAAMAAAAVgEAAAgA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAADAAEArAoAADABCQIAAGQBCAAQADwEEAeUAQAAAAAAAAsAAAAsBFQQlA2UDQAAAACEDVQQ
AAAAAAwPDA8AAAAAtAy0DCwELA8AAAAApAykDAAAAAAAAAAANA40DgEAAAATAAAAnAIAADAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAADAAEApAwcDzABCQIAAGQBCAAQAOQEVAbAAQAAAAAAAAgAAADUBOwSeBJ4EgAAAACYEpgSAAAA
AIgSiBIAAAAAWBJoEtQE7BIAAAAASBJIEgAAAAAAAAAAAAAAAAEAAAALAAAAKggAAEAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
AAEASBLsEjABCQIAAGQBBwAQAJwFAADcAQAAAAAAAAoAAAB8BZgUAAAAAAAAAAD8EkQTJBSYFAAA
AAAAAAAAAAAAAIwFjAV8BXwFHBM0FFQTVBMMEwwTAAAAAAEAAAAUAAAAWwoAAFgAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAEA
jAUAANwBAAAAAAAAAwABAPwSAAAwAQkCAQBkAQcAEABUBgAA/AEAAAAAAAAKAAAANAaQFQAAAAAA
AAAAYBVgFXAVgBUAAAAAAAAAADQGNAZEBkQGCBUIFRgVkBVQFVAVAAAAAAAAAAABAAAAEgAAAMEM
AABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAwABAEQGAAD8AQAAAAAAAAMAAQAIFQAAMAEJAgEAZAEIABAAEAcAABwCAAAAAAAA
BQAAAOwGzBUAAAAAzBXMFQAAAADsBuwG/Ab8BgAAAAAAAAAAvBW8FQAAAAAAAAAArBWsFQAAAAAA
AAAAAgAAABAAAAAIDgAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAQD8BgAARAIJAgAAZAEDAAEArBUAAFwCCQIBAGQBGQAZ
AAQAEAAwBwAAeAIBAAAAAAAAAAAAAAAAAAIAAAAAAAAABAAQAFAHeBSQAgEAAAAAAAEAAAAAAPA/
AgAAAAAAAAAEABAAcAcAALACAQAAAAAAAgAAAAAAAEACAAAAAAAAAAMAEAB4FAAAyAIBAAAAAAAd
AAQAGAYAAAMAQABgCFQP4AIJAgAAmAcQAAAAeAgAAPQCAAAAAAAABAAAAFAJhBEAAAAAAAAAAAAA
AACEEYQRXAxcDAAAAAD4D/gPAAAAAAAAAAAAAAAAAAAAAFAJUAkAAAAAARQTKe0uaRC/XQDdARGG
twAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAgBYASgIAABkAQAAAgABAAAAAAASABQA
AAAAAP//CQIAAAAAsgQAAAAAmAdYAQAAAAAAAAQAAQAAAAkCmAcJApgHGQAcAAQAOAUAAAMAQABA
CagJFAMAABoAWAFIAwAAAAAAABAAAAD4CfgJIAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACFRMp7S5pEL9dAN0BEYa3AAAA
AAAAAAAAAAAAAAAAAGQAAABgq8AAAAAAAAAAAAACAGwICAkAAJgHAAAKAAEAAAAAABIAFAAAAAAA
//8JAgAAAAAABgAAAAB4CGwIAAAAAAAABAABAAAACQJ4CAkCeAgZAB0ABAAoBgAAAwBAAHwJfAlc
AwkCAAAoAhEAEAVcDAAAaAMJAqgEAAAAAAAAAAAAAAAAAAAAAAAAAAAoAhwABABIBQAAAwBAAKgJ
bA+MAwAAFgCgCpwDWDMAABkAFgCoEsADpT4AABkAHQAEADgGAAADAEAAsAsAAFAECQIAAGQBFgDg
D2AERD8AABkAAwACAAAAAAB4BAAAAAAAABEAEAUAAAAAmAQJAhgEAAAAAAAAAAAAAAAAAAAAAAAA
AAD4CRAAAAC8CgAAyAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALFBMp7S5pEL9dAN0BEYa3AAAAAAAAAAAAAAAAAAAAAGQA
AABgjoMCAAAAAAAAAAACAFgBAAAAAHgIAAACAAEAAAAAABYA3Av8BNQHAAAZABYAlBCABXvtAAAZ
ABYAyAuoBYnyAAAZAAMAAgCACwAAvAYJAgAAZAEQAAAAxAwAAOAGAAAAAAAABAAAANwVnBYAAAAA
AAAAANwV3BUAAAAAAAAAADwWPBacFpwWAAAAAAwWDBYAAAAAAAAAAAAAAAAAAAAABhQTKe0uaRC/
XQDdARGGtwUUEyntLmkQv10A3QERhrdkAAAAYI6DAgAAAAAAAAAAAgBYAUwLAAD4CQAAAgABAAAA
AAASABQAAAAAAP//CQIAAAAASQUAAAAAvApYAQAAAAAAAAcAAwAAAAkCvAoJArwKCQpkAQYIAwAC
AAAAAADMBgkCBAC8ChYA6AsIB+UDAAAZABYAvA8oB3ZlAAAZABwABADgCQAAAwBAAFQPAABABwYA
FgB4EVAHN2sAABkAFgD8C2gHtw0AABkAFAAAACYAAAoWAEQMtAcTaQAAGQAWANQPzAeTDwAAGQAU
ACgAJgAAChYAmAwYCFHkAAAZABIAFABkEAAAPAgKAAAAAACRBAAAAABkAVgBAAAAAAAABAACAAAA
CgAJAmQBBggZABYAjAzECNYZAAAZABYAUAzsCKkGAAAZABYAyA/8CJ0DAAAZABIAFAD4DwAADAkG
CAAAAAC2BAAAAACYB1gBAAAAAAAABQADAAAABggJApgHBgiBCBYASBBYCWVoAAAZABYAAABwCUfB
AAAZAAMAAgC0DAAAkAkJAgAAZAEDAAIAhA0AAMwGCQIEALwKEAAAAKQNAAC0CQAAAAAAAAUAAAAc
EDARAAAAAAARABGsEKwQAAAAAAAAAAAAAAAAHBAcEAAAAAAAAAAA3BAwEQAAAAAAAAAAAAAAAAgU
EyntLmkQv10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAGCOgwIAAAAAAAAAAAIAWAFUDQAAvAoA
AAIAAQAAAAAAEgAUAAAAAAD//wkCAAAAAPIEAAAAAMQMWAEAAAAAAAAFAAIAAAAJAsQMCQLEDAYI
AwACAJQNPA+gCQkCCADEDAMAAgA0DgAA1AkJAgwAxAwQAAAARA4AAPQJAAAAAAAAAgAAALQR2BEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtBHYEQAAAAAAAAAAFhQTKe0u
aRC/XQDdARGGtwAAAAAAAAAAAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAgBYAQAAAADEDAAAAgAB
AAAAAAADAAIADA8AAOQJCQIQAKQNEAAAAGQTAAAwCgAAAAAAAAIAAAAIEmwWAAAAAAAAAAAAAAAA
AAAAAAgSCBIAAAAAAAAAAAAAAAAAAAAAbBZsFgAAAAAAAAAAAAAAAAUUEyntLmkQv10A3QERhrcA
AAAAAAAAAAAAAAAAAAAAZAAAAGCOgwIAAAAAAAAAAAIAWAHUDgAApA0AAAIAAQAAAAAAEgAUAAAA
AAD//wkCAAAAACgEAAAAAEQOWAEAAAAAAAAJAAUAAAAJAkQOCQJEDgkKZAEGCAAAgQgDAAIAHA8A
ABgKCQIUAEQOAwACACwPLA9ICgYAGAAAAAMAAgA8DwAAWAoBABwAAAADAAIAVBBUEHAKAQAeAAAA
HQAEAEgGAAADAEAAbA8AAIgKCQIAAGQBIQAEADQBAAAIAEAAAAAAAJwKAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA
AADECn3sAAAZABYAwBLoCvL/AAAZABYAAAAIC7QHAAAZABYA/BEYC+g0AAAZABYAAAAwC6sDAAAZ
AAUA2Ab4DwAAEQAQBYQRAABACwYApgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAUAKwQAACECwoA
AAAAAPkEAAAAAMQMWAEAAAAAAAADAAEAAAAKAAkCxAwWAJAWmAvNWwAAGQADAAIAAAAAALgLAAAg
AAAAEgAUAEQUAADQCwmCAAAAAI4EAAAAAGQBWAEAAAAAAAAFAAIAAAAJAkQOCQJkAQYIFgD8FBAM
0P8AABkAFgDMEjAMET8AABkAEQAQBdwQAABQDAYAbAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgBg
EWgMysAAABkAEQAQBAARMBGgDAAA7gQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAUADARAAC8DAoA
AAAAAPQEAAAAAMQMWAEAAAAAAAAFAAMAAAAKAAkCxAwBCIEIEgAUAAAAAADcDAoAAAAAAPMEAAAA
AMQMWAEAAAAAAAAFAAMAAAAKAAkCxAwBCIEIFgBsEfwMiWUAABkAFgAAABQN2G8AABkAFgDgEjQN
WmoAABkAEgAUAAAAAABYDQmCAAAAAL4EAAAAAJgHWAEAAAAAAAAEAAEAAAAJAqQNCQKYBxkAEQAQ
BNgR2BGYCwkCmgYAAAAAAAAAAAAAAAAAAAAAAAAAAMQMEQAQBAAAAAB8DQkCmwYAAAAAAAAAAAAA
AAAAAAAAAAAAAMQMFgC0EpgNu20AABkAEgAUAGwWAACwDQkCAAAAACkEAAAAAEQOWAEAAAAAAAAH
AAMAAAAJAkQOCQJEDgkKZAEGCBYAAABIDuSwAAAZAAMAAgBYEgAAdA4JAgAAZAEDAAIAaBJoEswG
CQIEALwKAwACAHgSAACEDgYACAAAAAMAAgCIEgAAlA4JAgwARA4DAAIAmBIAAFAHAAAQAAAAAwAC
AOwSAAC0BwAAIAAAABYAAACoDvjLAAAZABYAAADEDn09AAAZABYAAADoDhfSAAAZABYAAAAEDxTS
AAAZABQAUAA0AAAKFgAAAJgPBGgAABkAAwACAAAAAACwDwAAMAAAAAMAAgAME0QTzA8GAAAAAAAD
AAIAHBMAAOQPAAAIAAAAAwAKAEQTNBQAEAAgGAAAADATGQAOAAAAAQAQAAAgAAAAAAAAAAAAAAMA
AgBUEwAAGBABABwAAAADAAIAJBQAACwQAQAeAAAAEAAAAAAAAABIEAAAAAAAAAEAAACoFKgUAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgUqBQAAAAAAAAAAAAAAAAAAAAAAAAAABMUEyntLmkQ
v10A3QERhrcAAAAAAAAAAAAAAAAAAAAAZAAAAGCOgwIAAAAAAAAAAAIAWAH0EwAARA4AAAIAAQAA
AAAAEgAUAAAAAAD//wkCAAAAAGUGAAAAAGQTWAEAAAAAAAAFAAIAAAAJAmQTCQJkEwYIAwACADQU
mBQ0EAkCIABkEwMAAgCYFAAAYBAJAiQAZBMSABQAzBQAAKgQAAAAAAAAlQQAAAAAZAFYAQAAAAAA
AAQAAgAAAAAACQJkAQYIGQAZABkABAAAAAAAAADIEAEAAAAAADIEAAAAAAAAAgAAAAAAAAAFAAIA
AAAAAMgQAAAoAAAAEQAQBQAAAADYEAYAWAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAUAAAAAADs
EAEAAAAAAJIEAAAAAGQBWAEAAAAAAAAEAAIAAAABAAkCZAEGCBkAFgCgFTwRAOUAABkAAwACABgV
AABYEQYAAAAAAAMAAgAoFSgVcBEAAAgAAAADAAoAUBWQFQAQACAYAAAAPBUZAA4AAAABABAAACAA
AAAAAAAAAAAAAwACAGAVAAAsEAEAHAAAAAMAAgBwFQAAGBABAB4AAAADAAIAgBWAFTQQCQIgAGQT
BQACAJAVAADIEAAAKAAAAAMAAgAAAAAAYBAAAFgAAAAWAAAA2BAcDwAAGQADAAIAvBUAAMgRCQIA
ALwKAwACAMwVAADoEQkCBAC8CgMAAgAAAAAAABIJAggARA4SABQADBYAACQSCgAAAAAASgUAAAAA
vApYAQAAAAAAAAUAAwAAAAoACQK8CgEIgQgSABQAPBYAAEASCgAAAAAATwUAAAAAvApYAQAAAAAA
AAQAAgAAAAoACQK8CgYIGQASABQAnBYAAJQSCgAAAAAASwUAAAAAvApYAQAAAAAAAAQAAgAAAAoA
CQK8CgEIGQARABAEAAAAAKgSAAAdBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAAAfA3K8wAAGQAS
ABQAAAAAAAATCgAAAAAATAUAAAAAvApYAQAAAAAAAAUAAgAAAAoACQK8CgkKvAoEAPwPAAAAADoA
ABoDANKMAB0AABoaAB0aHgBbiAcrmAckphofAFtgCCt4CCSmGiAAW0AJS4gHLVAJI6YaIgBgAgAA
hKcCGiUAW3wJTmAIUIgJphomAEd8CYHFoDg1ABonAE58CVCUCTgTABooAH3YA5uOEH1ABJsGBxop
ABwaKgAaKwBbqAlOfAlQuAmmGiwAOkIAGi0AXsQJS0AJLdQJI6YaLgBOxAlQiAqFuDgTABovAH0M
BZuOEH1ABJsGBxowABwaMQAaMgBbqAlOxAlQlAqmGjMAGjYAS6gJU6AKhSV9yAW4OBkAGjcAfdAF
m44QfagGmwYHGjgAYAIAAIWnAho5ABo7AFcCAAAaPAAyfiAHsjgPADEaPQAp7AJbqAkjGzo1ABo+
ADJ+QAeyOA8AMRo/ACmUA1uoCSMbOhsAGkAAMn5gB7I4DwAxGkEAKTwEW6gJIxs6AQAxGkQAHRpL
AF6sCitkAVtACSSmGk4AS6wKUZALfRgHpRpPAEusClGcC0ewC6UaUABLrApRvAsp5ARdhAMjpRpR
AEusClHIC0qsCtTUC6UaUgBLrApR3AspnAVdhAMjpRpTAEusClHoC0qsCtT0C6UaVQBLhANT/AuF
JX00CLs4CgApVAZerApdhAMjGlcAS6wKLAgMfVgIIxpYAEusCiwIDH1wCCMaXABLhANTkAuFJRpd
ADJ9GAe4ORgAMn2ICLg5EAAyfZgIuDkIADJ9tAi4OBUAMRpeAEusClE4DEuEA1A4DKUbOjEAGl8A
Mn3YCLg4FQAxGmAAS6wKUTgMS4QDUEQMpRs6EQAxGmIAS6wKUTgMS4QDUDgMpRplAEusClFQDEuI
ByxcDH08CYUjpRpmAEusClGMDIKlGmcATmAIVJgMgl6sCicaaAAdGm4AXoQNK8QMfYQAJKYabwBe
lA0rxAx9hAAkphp3AEdUD4HFOAQAKWwPIxp5AF6kDCtkAVtACSSmGnwAS6QMUbwPS1QPU8gPhSWl
Gn0AS6QMUZALfZgIpRp+AEukDFHICynkBF0sBCOlGn8AS6QMUegLKZwFXSwEI6UagABLpAxR1A9H
sAulGoEAS6QMUZwLR7ALpRqCAEukDFHgD0ewC6UagwBLpAxR7A9LiAct+A8jpRqHAEssBFP8C4Ul
fTQIuzgKAClUBl6kDF0sBCMaigBeHA9LLARTkAuFJaUaiwBKHA8ajAAyfRgHsjkYADJ9iAiyORAA
Mn20CLI5CAAyfVgLsjgFAjEajQBLhA0sHBAjGo4AS6QMUTgMSywEUDgMpRqQAEocD320CLI4jwAa
kwBLLARTSBCFJX2EALs4NgAalABeVBBLLAQsZBB98AsjphqVAF6EDSvEDE5UEE+UEFCgEH1IDL9L
hA0trBAjv5skphs6RwAalwBLLART0BCFJX2EALs4MgAamABeVBBLLAQsZBB9hAwjphqZAF6EDSvE
DE5UEE+UEFCgEH1IDL9LhA0trBAjv5skphqaABqbABqdAGICHABLhA0t3BAjnAYplacCGp4AYgIe
AIVLhA0t3BAjnAYvrZWnAhqgAFgCHACOLbQ4FwAaoQBLhA0sABGOPFgCHACpiwIjGzpgABqiAFgC
HACOHrQ4FwAaowBLhA0sABGOLVgCHACpiwIjGzo8ABqkAFgCHACOD7Q4GQAapQBLhA0sABGOHlgC
HACpiwIjGqYAOhYAGqcAS4QNLAARjg9YAhwAqYsCIxqoABqqAEuEDSwwEVgCHgCLAiMarABLpAxR
YBFKhA2mGq0AS6QMUUgQSoQNphquAEukDFFsEUqEDaYasABelA0rxAxLhA0t3BAjm5skphqxAEuU
DSwAEUtUD1N4EYUmAQgAAJWLAiMaswBeNA5LiAcshBEjphq0AEs0Di60EUqEDSIatQBLNA4u2BFK
lA0iGrYAS6QMUfwRSjQOphs6WQIatwAyfZgIsjkIADJ92AiyOOQAMRq4AEocD32YCLI4FgAauQBL
pAxROAxLLARQOAylGroAOhMAGrsAS6QMUTgMSywEUEQMpRq8ABq/AF4MD0ssBCxkEH3wCyOmGsAA
SgwPgcWgODMAGsEASwwPLAgSSqQMfdwNIzEawgBLDA8sCBJKpAx98AsjMRrDAEsMDywIEkqkDH30
DSMxGsQAGsYAXgwPSywELGQQfRQOI6YaxwBKDA+BxaA4DgBLDA8sCBJKpAx9FA4jMRrJAF4MD0ss
BCxkEH0wDiOmGsoASgwPgcWgOA4ASwwPLAgSSqQMfTAOIzEbOmIBMRrMAEuEDSwcECMazQBLpAxR
OAxLLARQOAylGs4AYgIcAEuEDS3cECOcBimVpwIazwBiAh4AhUuEDS3cECOcBi+tlacCGtEAWAIc
AI4ttDgXABrSAEuEDSwAEY48WAIcAKmLAiMbOmAAGtMAWAIcAI4etDgXABrUAEuEDSwAEY4tWAIc
AKmLAiMbOjwAGtUAWAIcAI4PtDgZABrWAEuEDSwAEY4eWAIcAKmLAiMa1wA6FgAa2ABLhA0sABGO
D1gCHACpiwIjGtkAGtsAS4QNLDARWAIeAIsCIxrdAEukDFFgEUqEDaYa3gBLpAxRSBBKhA2mGt8A
S6QMUWwRSoQNphrhAF6UDSvEDEuEDS3cECObmySmGuIAS5QNLAARS1QPU3gRhSYBCAAAlYsCIxrk
AF40DkuIByyEESOmGuUASzQOLrQRSoQNIhrmAEs0Di7YEUqUDSIa5wBLpAxR/BFKNA6mGukAS6QM
UTwSfWwOpRrqAEukDFGMDIKlGusATmAIVJgMgl6kDCca7AAdGvcAXkgSK2QBW0AJJKYa+gBLSBJR
kAt9tAilGvsAS0gSUagShaUa/ABLSBJRtBJ93A6lGv4AS9QEU/wLhSV9NAi7OAoAKVQGXkgSXdQE
IxoAAV6IEinkBF3UBCOlGgEBXpgSKZwFXdQEI6UaAgFLSBJRwBJKiBKlGgMBS0gSUcwSSpgSpRoE
AUtIElHoC0pIEtTYEqUaBQFLSBIsCAx9YA8jGgYBS0gSLAgMfXwPIxoIAUtIElHgEpCoAKUaCwFe
aBJL1ARTkAuFJaUaDAFKaBIaDQEyfRgHsjkIADJ9iAiyOBUAMRoOAUtIElE4DEvUBFA4DKUbOg4B
Gg8BMn2YCLI5CAAyfdgIsjhcADEaEAFKaBJ9mAiyOBYAGhEBS0gSUTgMS9QEUDgMpRoSAToSABoT
AV7sEkvUBFNEDIUlpRoUARoWAV54EkvUBCxkEH3wCyOmGhcBS3gSLAgSSkgSfYQMIzEbOp8AGhgB
Mn20CLI4gwAxGhkBS0gSUTgMS9QEUDgMpRoaAUvUBFNIEIUlfYQAuzgiABobAV54EkvUBCxkEH3w
CyOmGhwBS3gSLAgSSkgSffALIzEaHQEaHgFL1ART0BCFJX2EALs4IgAaHwFeeBJL1AQsZBB9hAwj
phogAUt4EiwIEkpIEn2EDCMxGiEBGzoRADEaJAFLSBJROAxL1ARQOAylGiYBS0gSUTwSfWwOpRon
AUtIElGMDIKlGigBTmAIVJgMgl5IEicaKQEdGjEBXiQUK2QTS4gHLfgPIySmGjQBS4wFU5ALhSUa
NQEyfRgHuDkIADJ9iAi4OA8AMRo2AV78En1sEKUbOi0AGjcBMn2YCLg5CAAyfdgIuDgPADEaOAFe
/BJ9gBClGzoLADEaOgFe/BJ9bBClGj0BXgwTS4wFLEQUSvwSI6UaPwGFZQwTAX2EALhKDBOABjuF
ssQ4EAAaQAFiAhwAhqcCGkEBOhUAGkIBYgIcAEoME4AGO44CqKcCGkMBGkQBhVgCHABeHBNxHBMa
RgFKDBM1mBRkABpIAUaYFH2EALs4TAAaSQFeNBQrZBNGmBSbJKYaSgFLNBQtqBQjkwZJk0skFC2o
FCOTBkmTuzgdABpLAVgCHgBvHBNGmBSlGkwBYgIeAFgCHgCGqKcCGk0BGk4BGk8BN5gUnP8aUQFL
jAUszBR9ABEjOIoAGlIBXjQUK2QTS4wFU5wLhSYGCAAAmySmGlMBSzQULagUI5MGSZNLJBQtqBQj
kwZJk7s4TAAaVAFLjAUszBR9GBEjOCYAGlUBWAIeAG8cE0uMBVOcC4UlfTQRv0uMBVP8FIUlv6Ua
VgE6FgAaVwFYAh4AbxwTS4wFU5wLhSWlGlgBGlkBGloBOocAGlsBXjQUK2QTS4wFU+wPhSYGCAAA
mySmGlwBSzQULagUI5MGSZNLJBQtqBQjkwZJk7s4TAAaXQFLjAUszBR9GBEjOCYAGl4BWAIeAG8c
E0uMBVPsD4UlfTQRv0uMBVP8FIUlv6UaXwE6FgAaYAFYAh4AbxwTS4wFU+wPhSWlGmEBGmIBGmMB
GmUBXXwFShwTpRpnAR0abwFecBUrZBNLiAct+A8jJKYacQFLRAZTkAuFJRpyATJ9GAe4OQgAMn2I
CLg4DwAxGnMBXggVfYwRpRs6LQAadAEyfZgIuDkIADJ92Ai4OA8AMRp1AV4IFX2gEaUbOgsAMRp3
AV4IFX2MEaUaegFeGBVLRAYsRBRKCBUjpRp8AYVlGBUBfYQAuEoYFYAGO4WyxDgQABp9AWICHgCG
pwIafgE6FAAafwFiAh4AShgVgAY7hqinAhqAARqCAYVYAh4AXigVcSgVGoQBShgVNYAVZwAahQFG
gBV9hAC7OE8AGoYBXpAVK2QTRoAVmySmGocBTpAVVaAVIAgAAJMGSZNLcBUtqBQjkwZJk7s4HQAa
iQFYAhwAbygVRoAVpRqKAWICHABYAhwAhqinAhqLARqMARqNATeAFZn/Go8BXTQGSigVpRqQAR0a
lwFWAgAAoDgBABwamgFerBVL/AYsZBB9FBIjphqeAV68FSu8CknsBn0UEiSmGp8BS7wVLNwVjgKL
AiMaoAFLvBUsDBZ9XBIjGqEBS7wVLNwVhosCIxqkAUv8BlOQC4UlGqUBMn2YCLg5CAAyfdgIuDjV
ADEapgFL/AZTSBCFJX2EALs4TAAapwFezBVL/AYsZBB98AsjphqoAUu8FSwMFn2AEiMaqQFLvBUs
PBaGIxqqAUu8FSwMFkvMFS1sFiOFZAGbmyMaqwFLvBUs3BWGiwIjGqwBGq0BS/wGU5AWhSV9hAC7
OEwAGq4BXswVS/wGLGQQfRQOI6YarwFLvBUsDBZ9vBIjGrABS7wVLDwWhiMasQFLvBUsDBZLzBUt
bBYjhWQBm5sjGrIBS7wVLNwVhosCIxqzARq0AUu8FSzcFY4CiwIjGzrhABq1ATJ9tAi4ONUAMRq2
AUv8BlNIEIUlfYQAuzhMABq3AV7MFUv8BixkEH3wCyOmGrgBS7wVLAwWfcwSIxq5AUu8FSw8FoYj
GroBS7wVLAwWS8wVLWwWI4VkAZubIxq7AUu8FSzcFYaLAiMavAEavQFL/AZT0BCFJX2EALs4TAAa
vgFezBVL/AYsZBB9hAwjphq/AUu8FSwMFn3oEiMawAFLvBUsPBaGBABYAPgPAAAjGsEBS7wVLAwW
S8wVLWwWI4VkAZubIxrCAUu8FSzcFYaLAiMawwEaxAFLvBUs3BWOAosCIxs6AQAxGsYBSqwVgcWg
OAoAS7wVLJwWSqwVIxrHAR0HAIgAAAAAACYAAAAYAAUACQB0bXBTZW5kVG8AqwFeAQMABwAMAAUA
CTBTMEUAAAAmAAAAGAAFAAkAdG1wQ29weVRvAKsBXgEDAAcADAAFAAkwUzBFABAWNAAAACYABQAK
AHRtcENvcHlUbzEFAAoAdG1wQ29weVRvMh8CXgEDAAcADAAFAAkwUzBFAAIAAAABALCxYgC8ZSWF
fAIAABAAAABPAAAAfAIAAAEAAQAAAAIAasYi93sDAAAAAAIAsGxtAE1jJQAAAAAA////ABMBAAA3
AQAAAe0AAhf6bABMYyUAF/psAPGGJe0AAg0ATz1Mb3R1cyBOb3RlcwAADQBPPUxvdHVzIE5vdGVz
AACIAEJWBAAxLjAAQkMBAANCQQEAMEJMAgB2Ak5OUABdxrttqwBlyLnGSaeZLBJNmd4j7n1Q5fQm
X4oN4dQE1bAj4WCB0l0kYBe6vs5qzFACU05fo6pnIdhsRuTIO0UYXFuqu4UfqKPkVInN+j4pAEVO
BACLcQAATUEIAFc+zsEygkSNgABQVVJTQUZPAHudQj9zcOSv2pXuWX3umjM5ZO508R5mWyWRZAtc
MSGldUA7oiRmBSM5t8XghQBNNyI+CnwuOiNVBR50C80wZ2SM950uaxrBIedQI9s43RIBIAAAxWxt
AExjJQBwE20AJ2YlhQAADQBPPUxvdHVzIE5vdGVzAAAxAENOPUxvdHVzIE5vdGVzIFRlbXBsYXRl
IERldmVsb3BtZW50L089TG90dXMgTm90ZXMAAIgAQlYEADEuMABCQwEAA0JBAQAwQkwCAHYCTk5Q
AElPsjZEqNvBObZ39iduJ/FH7kRXUcXBhiFglLm15vEaFcQ+/WvuV484Ogln1CnlayVIU8WEveot
/+hBC+aF+NJVG43EWxrSQfbICp4ZCyEARU4EAO9eAABNQQgAmLQXPAzXnA2AAFBVUlNBRk8A2epm
gKF5RgO5Xrbt7QA86qOZJ7lsQX5W67I7KHOCf9Dlp27ieSeViyoKOe7kQKGAyPtEqeUts4FiG9LZ
u5LIjix68BR43NePRmRlIWZeXqMIp8xNNd9bM2xa67VUjDk4euE3SjkuXFQ8K12Bm1yIj+BF1Haq
JE6Q++PhUTN7SL1k3vVKO6efRRuHjJxfvHmgHi0TjDWUejKP+PuiGomsVcvLltADd7aLq1pcmkJ8
bh8FAAUANAAAAAAAAAAAAAAAAAAAAAAAAAAkU2NyaXB0TGliACRTY3JpcHRMaWJfTwAkVElUTEUA
JEZsYWdzACRQdWJsaWNBY2Nlc3MAqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqAQAACAAAAQBFAAIAHAUAAAAAAAAAAAAAAAAAAAAAAAAB
wAAABgEAAABcAwD6IAAAAHABAEgLTADPaCWFAAAGAAEAAAAGABQAAAX+/xoACQAAAyQkIwAKAAAE
JCQtAAkAAAQkJDYADAAABCQkQgAGAAEFJCRIAAUAAQAkJE0ADAAABiQkWQAGAAAFJCRfAAcAAAUk
JGYACgAUACQkcAAMAAAFJCR8AAwAAAUkJIgADwAUACQklwAEAAEFJCSbAAQAAQUkJJ8ABAABBSQk
owAHAAEFJCSqABYAAQUkJMAADAABBSQkzAAGAAEFJCTSAAYAAQUkJNgACwABBSQk4wAHAAEFJCTq
AAQAAQAkJO4ABQABACQk8wAIAAEAJCT7AA0AFAAkJAgBDQAUACQkFQENABQAJCQiAQUAAAUkJCcB
CgABBSQkMQEHAAAFJCQ4AQcAAAUkJD8BCQAABSQkSAEKAAgAJCRSAQoAAAUkJFwBDAAABSQkaAEN
AAAFJCR1AQkAAQUkJH4BCgABBSQkiAEEAAQAJCSMAQoAAQUkJJYBBAABBSQkmgEPAAEFJCSpARAA
AQUkJLkBDQABBSQkxgETAAEFJCTZAQgAAQUkJOEBCQABBSQk6gEKAAEFJCT0AQkAAQUkJP0BFAAB
BSQkEQIRAAEDJCQiAhQAAQMkJDYCDQABBSQkQwIHAAEFJCRKAhIAAQMkJFwCCQABBSQkZQIKAAEE
JCRvAgoAAQUkJHkCDgABBSQkhwIMAAEFJCSTAgoAAQQkJJ0CBQAEACQkogIFAAEDJCSnAgoAAAUk
JLECBwAABSQkJEZvbnRzJCRGb3JtUG9zdE9wZW5BY3Rpb24kVHlwZUljb25FeHBpcmVEYXRlUmVw
bHlEYXRlQ29tcG9zZWREYXRlJFRJVExFJElORk8kV0lORE9XVElUTEUkRmxhZ3MkU2NyaXB0JCRT
Y3JpcHRfTyQkU2NyaXB0TmFtZSQkRm9ybVNjcmlwdCQkJEZvcm1TY3JpcHRfT0Zyb21Mb2dvU2ln
bkVuY3J5cHREZWZhdWx0TWFpbFNhdmVPcHRpb25zJEtlZXBQcml2YXRlU2VuZFRvQ29weVRvQmxp
bmRDb3B5VG9TdWJqZWN0Qm9keSRCT0RZJEFDVElPTlMkU0NSSVBUT0JKXzIxJFNDUklQVE9CSl8y
MiRTQ1JJUFRPQkpfMjMkJFhNQiRVcGRhdGVkQnkkJFhNQl8yJCRYTUJfMyRMaWNlbnNlZSRTaWdu
YXR1cmUkU2NyaXB0TGliJFNjcmlwdExpYl9PJFB1YmxpY0FjY2Vzc1BSSU5DSVBBTFNFQ1VSRU1B
SUwkUkVGTWFpbEZvcm1hdEZvcm1Jbmhlcml0ZWRTZW5kVG9Jbmhlcml0ZWRSZXBseVRvSW5oZXJp
dGVkRnJvbUluaGVyaXRlZEZyb21Eb21haW5Gb3JtTmFtZVN3aXBlRnJvbUltcG9ydGFuY2VTZW5k
ZXJUYWdFeHBhbmRQZXJzb25hbEdyb3Vwc1ZhbGlkYXRpb25UZXN0aW5nQXR0YWNobWVudFZhbGlk
YXRpb25DbG9zaW5nRmllbGRzb2xkZnJvbXRtcEF0dGFjaG1lbnRTaXplc3RtcEFjdGlvblBvc3Rl
ZERhdGUkTWVzc2FnZUlEJE1zZ1RyYWNrRmxhZ3NSb3V0ZVNlcnZlcnNSb3V0ZVRpbWVzJE9yaWck
SG9wc0Zyb21Eb21haW5SZXBseVRvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqDBAEAhf9fAAEAAAoJSXQgaXMgZXF1YWxseSBzYWZlIHRvIGdp
dmUgZXh0ZW5zaW9ucyBhIGhpZ2ggdGFnIGFuZCBsZWF2ZSBHZW5lcmFsTmFtZSB1bnRhZ2dlZCwg
ZS5nLiAAhf8eAAQAAApUU1RJbmZvIDo6PSBTRVFVRU5DRSAggQKDBAEAhf+SAAQAAAp7ICAgICAg
ICAgWy4uLl0AICAgICAgdHNhICAgICAgICAgICAgICAgICAgIEdlbmVyYWxOYW1lICAgICAgICAg
IE9QVElPTkFMLAAgICAgICBleHRlbnNpb25zICAgICAgICAgICAgWzMwXSBJTVBMSUNJVCBFeHRl
bnNpb25zIE9QVElPTkFMAH2BAoMEAQCF/wgABAAACoECgwQBAIX/AwEEAAAKCVdvdWxkbid0IHRo
aXMgYmUgYmV0dGVyIHRoYW4gdGhyb3dpbmcgaW4gZXh0cmEgdGFncz8gIFRhZyBudW1iZXJzIGFi
b3ZlIDMwIHNob3VsZCBiZSBhdm9pZGVkIHdoZW5ldmVyIHBvc3NpYmxlLCBvZiBjb3Vyc2UsIGJl
Y2F1c2UgdGhleSBhcmUgbXVsdGktYnl0ZSB0YWdzLiAgT2YgY291cnNlLCBzaW5jZSBBY2N1cmFj
eSBpcyBhbiBvcHRpb25hbCBzZXF1ZW5jZSwgbGVhdmluZyBleHRlbnNpb25zIHVudGFnZ2VkIGRv
ZXNuJ3Qgd29yay4AgQKDBAEAhf8IAAQAAAqBAoMEAQCF/xUABAAACgkJVG9tIEdpbmRpbgAAgQK3
HKAFwSGpAwQAAABIAAAAAAAAAAAAAAAAAAAAgwQBAIECuipgDEgAuRoZAwEBDQkBAAAAAAAAACkA
AAAAAAAAAAAAAAAAAAAAAAAAgwQBAIX/RgABAQ0JRGVuaXMgUGlua2FzIDxEZW5pcy5QaW5rYXNA
YnVsbC5uZXQ+IG9uIDA0LzI4LzIwMDAgMDY6MTA6MjkgQU25EgAAAAAAAAAAAAAAAAAAAACBAoL/
RgACAAAAAAABAAAAyggAAKAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABAEAAAAAAACDBAIAhf8MAAEACwlUbzoJhf8nAAEAAAlKb2VyZyBTZWlkZWwgPHNlaWRlbEBt
YXotaGguZGU+AIECgv9GAAMAAAAAAAAAAADKCAAAoAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAGAQAAAAAAAIMEAwCF/wwAAQALCWNjOgmF/xkAAQAACWlldGYtcGtp
eEBpbWMub3JnAIX/CQABAAsJIACBAoL/RgAEAAAAAAAAAAAAyggAAKAFAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAEAAAAAAACDBAQAhf8RAAEACwlTdWJqZWN0OgkA
hf8eAAEAAAlSZTogdGltZS1zdGFtcC1kcmFmdC03gQKDBAEAhf8IAAEAAAqBAoMEAQCF/wgAAQAA
CYECgwQBAIX/CAABAAAKgQKDBAEAhf8PAAQAAApKb2VyZywAAIECgwQBAIX/wQAEAAAKVGhhbmtz
IGZvciB5b3VyIGNhcmVmdWwgd3JpdGluZy4gV2UgY2FtZSBmb3JtIGEgbWF4aW11bSB0YWdnaW5n
AHZlcnNpb24gKHdoaWNoIHdhcyBzYWZlKSB0byBhIG1pbmltdW0gb25lLiBJdCBpcyBoYXJkIHRv
IGRvIG1pbmltYWwAdGFnZ2luZyBieSB0aGlua2luZyB0byBhbGwgdGhlIHZhcmlvdXMgY29tYmlu
YXRpb25zLgAAgQKDBAEAhf8/AAQAAApZb3UgYXJlIHJpZ2h0LiBUaGFua3MgZm9yIHByb3ZpZGlu
ZyBhIGNoYW5nZSBwcm9wb3NhbC4AAIECgwQBAIX/DgAEAAAKRGVuaXMAgQKDBAEAhf/bBwQAAAo+
IERlbmlzLAA+AD4gbWF5YmUgdGhlIFRTVEluZm8gc3RydWN0dXJlIGhhcyBzb21lIGluY29udmVu
aWVuY2UgYmVjYXVzZSBvZiB0aGUgbWlzc2luZyB0YWdzAD4gbm93OgA+AD4gdGltZS1zdGFtcC1k
cmFmdC03OiBJTVBMSVpJVCB0YWdnaW5nAD4APiBUU1RJbmZvIDo6PSBTRVFVRU5DRSAgewA+ICAg
ICAgICAgWy4uLl0APiAgICAgIHRzYSAgICAgICAgICAgICAgICAgICAgICAgICAgR2VuZXJhbE5h
bWUgICAgICAgICAgT1BUSU9OQUwsAD4gICAgICBleHRlbnNpb25zICAgICAgICAgICAgICAgICAg
IFswXSBFeHRlbnNpb25zICAgICAgIE9QVElPTkFMAD4gfQA+AD4gWC41MDkgSU1QTElaSVQ6IFRh
Z2dpbmc6AD4APiAgICAgICBHZW5lcmFsTmFtZSA6Oj0gQ0hPSUNFIHsAPiAgICAgICAgICAgIG90
aGVyTmFtZSAgICAgICAgICAgICAgICAgICAgICAgWzBdICAgICBPdGhlck5hbWUsAD4gICAgICAg
ICAgICByZmM4MjJOYW1lICAgICAgICAgICAgICAgICAgICAgIFsxXSAgICAgSUE1U3RyaW5nLAA+
ICAgICAgICAgICAgZE5TTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICBbMl0gICAgIElBNVN0
cmluZywAPiAgICAgICAgICAgIHg0MDBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgWzNdICAg
ICBPUkFkZHJlc3MsAD4gICAgICAgICAgICBkaXJlY3RvcnlOYW1lICAgICAgICAgICAgICAgICAg
IFs0XSAgICAgTmFtZSwAPiAgICAgICAgICAgIGVkaVBhcnR5TmFtZSAgICAgICAgICAgICAgICAg
ICAgWzVdICAgICBFRElQYXJ0eU5hbWUsAD4gICAgICAgICAgICB1bmlmb3JtUmVzb3VyY2VJZGVu
dGlmaWVyICAgICAgIFs2XSAgICAgSUE1U3RyaW5nLAA+ICAgICAgICAgICAgaVBBZGRyZXNzICAg
ICAgICAgICAgICAgICAgICAgICBbN10gICAgIE9DVEVUIFNUUklORywAPiAgICAgICAgICAgIHJl
Z2lzdGVyZWRJRCAgICAgICAgICAgICAgICAgICAgWzhdICAgICBPQkpFQ1QgSURFTlRJRklFUn0A
PgA+ICAgICAgIE90aGVyTmFtZSA6Oj0gU0VRVUVOQ0UgewA+ICAgICAgICAgICAgdHlwZS1pZCAg
ICBPQkpFQ1QgSURFTlRJRklFUiwAPiAgICAgICAgICAgIHZhbHVlICAgICAgWzBdIEVYUExJQ0lU
IEFOWSBERUZJTkVEIEJZIHR5cGUtaWQgfQA+AD4gICAgRXh0ZW5zaW9ucyAgOjo9ICBTRVFVRU5D
RSBTSVpFICgxLi5NQVgpIE9GIEV4dGVuc2lvbgA+AD4gVGhlIHBhcnNlciBjYW4ndCBkaXRpbmd1
aXNoIGJldHdlZW4gdGhlICJHZW5lcmFsTmFtZSIgZmllbGQgYW5kICJbMF0APiBFeHRlbnNpb25z
IiBpbiBjYXNlIHRoYXQgdGhlIEdlbmVyYWxOYW1lIGNob2ljZSBpcyAiWzBdIE90aGVyTmFtZSIu
IFNpbmNlIGJvdGgAPiBPdGhlck5hbWUgYW5kIEV4dGVuc2lvbnMgYXJlIHNlcXVlbmNlcyB0aGUg
dGFnIHdpbGwgYmUgZW5jb2RlZCBpZGVudGljYWxseSBhbmQAPiBjYW4ndCBiZSB1c2VkIHRvIGRp
c3Rpbmd1aXNoIHRoZSB0d28gb3B0aW9uYWwgZW50cmllcy4gVGhleSBjb3VsZCBvbmx5AD4gZGlz
dGluZ3Vpc2hlZCBieSBjaGVja2luZyB0aGUgdGFnIG9mIHRoZSBjb250ZW50IG9mIHRoZSBzZXF1
ZW5jZS4gVGhhdCBpc24ndAA+IHZlcnkgY29udmluaWVudCBmb3IgaW1wbGVtZW50YXRpb25zLgA+
AD4gSSBzdWdnZXN0IGNoYW5naW5nIHRoZSB0YWdnaW5nIHRvOgA+AD4gVFNUSW5mbyA6Oj0gU0VR
VUVOQ0UgIHsAPiAgICAgWy4uLl0APiAgICAgIHRzYSAgICAgICAgICAgICAgICAgICAgICAgICAg
WzBdIEdlbmVyYWxOYW1lICAgICAgT1BUSU9OQUwsAD4gICAgICBleHRlbnNpb25zICAgICAgICAg
ICAgICAgICAgIFsxXSBFeHRlbnNpb25zICAgICAgIE9QVElPTkFMAD4gfQA+AD4gSm9yZwA+AD4g
LS0APiB0aW1lcHJvb2YgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmUgICs0OS00
MC03NjYyOS0xOTExAD4gRGV2ZWxvcG1lbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZh
eCAgICArNDktNDAtNzY2MjktNTUxAD4gSGFyYnVyZ2VyIFNjaGxv4XN0cmHhZSA2LTEyICAgICAg
ICAgICAgIACF/wgABAAACoX/IgAEAAAKbWFpbHRvOnNlaWRlbEB0aW1lcHJvb2YuZGWF/zMABAAA
CgA+IEQtMjEwNzkgSGFtYnVyZyAgICAgICAgICAgICAgICAgICAgICAgICAAhf8IAAQAAAqF/x8A
BAAACmh0dHA6Ly93d3cudGltZXByb29mLmRlAIX/CAABAAAJgQKDBAEAhf8IAAEAAAqBAoMEAQCF
/wgAAQAACgIAHAAcAENOPUQwMk1MMjM3L09VPTAyL09VPU0vTz1JQk1DTj1ENTFNVEEwNC9PVT0w
MS9PVT1HL089SUJNAAACACkITADPaCWFtAhMAM9oJYV2CEwAz2glhcAITADPaCWFqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoGCgAAAAD6IAAAQHgBAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////6qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqo=

--0__=KWPNC2qdL7b6kYK6eGdwdWnokw8Z7pB8fmiQkwiNoLSbFFVCv1HFRbhk--



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09742 for <[e-mail]>; Fri, 28 Apr 2000 03:34:09 -0700 (PDT)
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 MAA03914; Fri, 28 Apr 2000 12:38:58 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 12:39:01 +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]>, PKIX mailing group <[e-mail]>
Subject: Re: TSA draft V7
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael,

On the gfirst point I answered to quickly.

The idea is to return the relevant certificate in the certificates
field from the SignedData structure.

Here after is the complete fix:

If the certReq field is present and set to true, the TSA's public
key certificate that is referenced by the ESSCertID attribute in the 
response must be provided by the TSA in the certificates field from 
the SignedData structure in that response. That field may also
contain 
other certificates.

If the certReq field is missing, or if the certReq field is present
and set to false then the certificates field from the SignedData 
structure must not be present in the response.

Denis

 
> > A few more remarks:
> 
> > The draft says:
> 
> > "If the certReq field is present and set to true, the TSA's public key
> > certificate that is referenced by the ESSCertID attribute must be provided
> > by the TSA in the Certificate Values attribute and incorporated in the
> > response. The certificate Values attribute may also contain other
> > certificates.
> > If the certReq field is missing, or if the certReq field is present and set
> > to false then no Certificate Values attribute shall be present."
> 
> > Q1. "Certificate Values attribute". What is it? Was it meant to be the
> > signedData::Certificates field?
> 
> You are right. It is "Signing Certificate" instead of "Certificate
> Values". Good catch.
> 
> > Q2. If the certReq field is missing in the request, should it be up to the
> > TSA to decide whether to include the cert of not?
> 
> The text is pretty explicit on this. The TSA does not decide : No
> certificate sahll be present.
> 
> > Q3. somehow it seems more reasonable to default the certReq to TRUE. This
> > way TSA would be well-behaving with no extra efforts.
> 
> The answer should be as short as possible in the general case. If
> you really want the certificate back, then you have to ask for it.
> 
> > General comments:
> >
> > C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
> > I'd prefer "pkix" to be preserved as part of the name.
> 
> They come from two different arcs (SMIME and PKIX).
> 
> > C2. PKIXTSP is defined but never referenced.
> 
> The name is there so that *other* ASN 1 modules may reference it and
> use what is exported.
> 
> Denis
> 
> >
> > Regards
> >
> > M


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06015 for <[e-mail]>; Fri, 28 Apr 2000 03:05:37 -0700 (PDT)
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 MAA33114; Fri, 28 Apr 2000 12:10:26 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 12:10:29 +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: Joerg Seidel <[e-mail]>
CC: [e-mail]
Subject: Re: time-stamp-draft-7
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Joerg,

Thanks for your careful writing. We came form a maximum tagging
version (which was safe) to a minimum one. It is hard to do minimal
tagging by thinking to all the various combinations.

You are right. Thanks for providing a change proposal.

Denis
 
> Denis,
> 
> maybe the TSTInfo structure has some inconvenience because of the missing tags
> now:
> 
> time-stamp-draft-7: IMPLIZIT tagging
> 
> TSTInfo ::= SEQUENCE  {
>         [...]
>      tsa                          GeneralName          OPTIONAL,
>      extensions                   [0] Extensions       OPTIONAL
> }
> 
> X.509 IMPLIZIT: Tagging:
> 
>       GeneralName ::= CHOICE {
>            otherName                       [0]     OtherName,
>            rfc822Name                      [1]     IA5String,
>            dNSName                         [2]     IA5String,
>            x400Address                     [3]     ORAddress,
>            directoryName                   [4]     Name,
>            ediPartyName                    [5]     EDIPartyName,
>            uniformResourceIdentifier       [6]     IA5String,
>            iPAddress                       [7]     OCTET STRING,
>            registeredID                    [8]     OBJECT IDENTIFIER}
> 
>       OtherName ::= SEQUENCE {
>            type-id    OBJECT IDENTIFIER,
>            value      [0] EXPLICIT ANY DEFINED BY type-id }
> 
>    Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
> 
> The parser can't ditinguish between the "GeneralName" field and "[0]
> Extensions" in case that the GeneralName choice is "[0] OtherName". Since both
> OtherName and Extensions are sequences the tag will be encoded identically and
> can't be used to distinguish the two optional entries. They could only
> distinguished by checking the tag of the content of the sequence. That isn't
> very convinient for implementations.
> 
> I suggest changing the tagging to:
> 
> TSTInfo ::= SEQUENCE  {
>     [...]
>      tsa                          [0] GeneralName      OPTIONAL,
>      extensions                   [1] Extensions       OPTIONAL
> }
> 
> Jorg
> 
> --
> timeproof                               phone  [phone]
> Development                             fax    [phone]
> Harburger Schloßstraße 6-12             mailto:[e-mail]
> D-21079 Hamburg                         http://www.timeproof.de


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05797 for <[e-mail]>; Fri, 28 Apr 2000 03:01:34 -0700 (PDT)
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 MAA04002; Fri, 28 Apr 2000 12:06:14 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 12:06:17 +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: PKIX mailing group <[e-mail]>
Subject: Re: TSA draft V7
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> A few more remarks:
 
> The draft says:

> "If the certReq field is present and set to true, the TSA's public key
> certificate that is referenced by the ESSCertID attribute must be provided
> by the TSA in the Certificate Values attribute and incorporated in the
> response. The certificate Values attribute may also contain other
> certificates.
> If the certReq field is missing, or if the certReq field is present and set
> to false then no Certificate Values attribute shall be present."
 
> Q1. "Certificate Values attribute". What is it? Was it meant to be the
> signedData::Certificates field?

You are right. It is "Signing Certificate" instead of "Certificate
Values". Good catch.

> Q2. If the certReq field is missing in the request, should it be up to the
> TSA to decide whether to include the cert of not?

The text is pretty explicit on this. The TSA does not decide : No
certificate sahll be present.
 
> Q3. somehow it seems more reasonable to default the certReq to TRUE. This
> way TSA would be well-behaving with no extra efforts.

The answer should be as short as possible in the general case. If
you really want the certificate back, then you have to ask for it.

> General comments:
> 
> C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
> I'd prefer "pkix" to be preserved as part of the name.

They come from two different arcs (SMIME and PKIX).

> C2. PKIXTSP is defined but never referenced.

The name is there so that *other* ASN 1 modules may reference it and
use what is exported.

Denis

> 
> Regards
> 
> M


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02047 for <[e-mail]>; Fri, 28 Apr 2000 01:29:47 -0700 (PDT)
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 KAA06416; Fri, 28 Apr 2000 10:34:35 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 10:34:38 +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]>
CC: [e-mail]
Subject: Re: Permanent identifiers in QC
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

(snip)
 
> Anyway: If you change your name, you might WANT the consequence of
> loosing the relationship automatically detectable by an RP.

Yes, since Permanent identifiers are OPTIONAL.

Denis


Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26622 for <[e-mail]>; Fri, 28 Apr 2000 00:06:19 -0700 (PDT)
Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id <JAA08277> for <[e-mail]>; Fri, 28 Apr 2000 09:11:14 +0200 (MET DST)
Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id JAA08745; Fri, 28 Apr 2000 09:10:43 +0200 (MEST)
Message-ID: <[e-mail]>
Date: Fri, 28 Apr 2000 09:19:20 +0200
From: Joerg Seidel <[e-mail]>
Organization: timeproof
X-Mailer: Mozilla 4.5 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: time-stamp-draft-7
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Denis,

maybe the TSTInfo structure has some inconvenience because of the missing tags
now:

time-stamp-draft-7: IMPLIZIT tagging

TSTInfo ::= SEQUENCE  {
	[...]
     tsa                          GeneralName          OPTIONAL,
     extensions                   [0] Extensions       OPTIONAL
}

X.509 IMPLIZIT: Tagging:

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

The parser can't ditinguish between the "GeneralName" field and "[0]
Extensions" in case that the GeneralName choice is "[0] OtherName". Since both
OtherName and Extensions are sequences the tag will be encoded identically and
can't be used to distinguish the two optional entries. They could only
distinguished by checking the tag of the content of the sequence. That isn't
very convinient for implementations.

I suggest changing the tagging to:

TSTInfo ::= SEQUENCE  {
    [...]
     tsa                          [0] GeneralName      OPTIONAL,
     extensions                   [1] Extensions       OPTIONAL
}

Jorg

--
timeproof                               phone  [phone]
Development                             fax    [phone]
Harburger Schloßstraße 6-12             mailto:[e-mail]
D-21079 Hamburg                         http://www.timeproof.de


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 TAA10935 for <[e-mail]>; Thu, 27 Apr 2000 19:57: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 NAA05275; Fri, 28 Apr 2000 13:07:48 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <JZ1LTWMB>; Fri, 28 Apr 2000 13:02:15 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: PKIX mailing group <[e-mail]>
Cc: [e-mail]
Subject: TSA draft V7
Date: Fri, 28 Apr 2000 13:02:14 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

A few more remarks:
 
The draft says:
"If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID attribute must be provided
by the TSA in the Certificate Values attribute and incorporated in the
response. The certificate Values attribute may also contain other
certificates.
If the certReq field is missing, or if the certReq field is present and set
to false then no Certificate Values attribute shall be present."
 
Q1. "Certificate Values attribute". What is it? Was it meant to be the
signedData::Certificates field?
 
Q2. If the certReq field is missing in the request, should it be up to the
TSA to decide whether to include the cert of not?
 
Q3. somehow it seems more reasonable to default the certReq to TRUE. This
way TSA would be well-behaving with no extra efforts.
 

General comments:

C1. The draft uses both id-ad-timeStamping and id-pkix-ad-timestamping OIDs.
I'd prefer "pkix" to be preserved as part of the name.

C2. PKIXTSP is defined but never referenced.

Regards

M



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 SAA29572 for <[e-mail]>; Thu, 27 Apr 2000 18:30:50 -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 LAA03879; Fri, 28 Apr 2000 11:40:38 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <JZ1LTWJY>; Fri, 28 Apr 2000 11:35:05 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: [e-mail]
Cc: PKIX mailing group <[e-mail]>
Subject: TSA draft V7.0
Date: Fri, 28 Apr 2000 11:35:05 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Denis,
 
Something I've just noticed in the draft, which skipped my attention before:
 
The TSA draft defines how the AIA extension can be used in the TSA
certificate. 
***
A TSA's certificate MAY contain an Authority Information Access extension
[RFC2459] in order to convey the method of contacting the TSA. The
accessMethod field in this extension MUST contain the OID
id-ad-timestamping:
***
 
The definition actually contradicts to the 2459 profile which says:
 
***
The authority information access extension indicates how to access CA
information and services FOR THE ISSUER OF THE CERTIFICATE in which the
extension appears. Information and services may include on-line validation
services and CA policy data. 
****

Note the "FOR THE ISSUER OF THE CERTIFICATE" bit.

The content of the AIA extension does not depend on who the subject is. It
only depends on what information access services the CA has to offer. In
other words, a CA would most probably use the same AIA for a TSA cert and
for any other entity's certificate it generates .

The only possible situation I can think of when the definition given by the
TSA draft makes a tiny bit of sense is for self-signed TSA certificates. If
this is the case, the AIA would be presenting a set of protocols that can be
used to obtain timestamps. But then it must be clearly stated by the
document that only self-signed TSA certs can have that information in the
AIA extension. Still, it contradicts to the spirit of the 2459, which
defines the AIA as providing information about how to access the
certificate-issuing authority, but not the services offered by the subject
of the certificate.

The current definition in the TSA draft goes back to the very early version
of the draft. Probably, it is just me who is wrong, and there is something I
simply do not understand. Would like my concerns to be explained.

BTW, an alternative and in my opinion a better way of specifying the set of
URIs to obtain timestamps would probably be defining a proprietary extension
in TSA certificates. TsaAccessDescription ::= SEQUENCE SIZE (1..MAX) OF
GeneralName. Non-critical, with the id-ad-timestamping OID.

Best regards

M

 

 


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 NAA21119 for <[e-mail]>; Thu, 27 Apr 2000 13:58:10 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <20Y518G6>; Thu, 27 Apr 2000 17:02:35 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Peter Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 27 Apr 2000 17:02:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Peter,

> ----------
> From: 	Peter Williams[SMTP:[e-mail]]
> Sent: 	Thursday, April 20, 2000 11:01 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> We have seemingly cleared up or determined
> three technical points from the discussion. Do
> say if any description below is not
> correct - in your view.
> 
> (1) a CMP responder does not need to send any
> particular cert path to the subscriber, when
> returning the EE cert for EE acceptance. The UA
> should not assume presence of any particular
> certs, including the CA cert or any superior
> certs in the domain's trust network, in the 
> message field in discussion. Futhermore, any
> certs that are sent are in bag order.
 
Agreed.

Note, however, the distinction between the caPubs field in the initRep
message (Section 3.3.2) and the extraCerts field in PKIMessage (Section
3.1).  The initializing EE must receive its trust anchor(s) in some reliable
way.  If this has not happened by some other (out-of-band) means, then the
caPubs field is a convenient and reasonable place to do this.  Certs found
here (in bag order) are intended to be directly trusted as root certificates
and need not be validated prior to acceptance of the newly-issued EE
cert(s).  This implies that they are valid at the moment of creation of this
response message.  It also implies that there is no certificate path here
(there's no reason I can think of to have every CA in a path be a trust
anchor for a given EE).

It is the extraCerts field (again in bag order) that may contain various
"helpful" certs, including (partial) paths.  Such certificates carry no
particular assurance of validity (even at the moment of creation of this
response message) and SHOULD, like all other non-root certificates, be
validated by the EE immediately prior to use.

> (2) According to CMP designers, the UA does not
> need to verify the signature of the 
> EE certificate upon initial receipt (which
> in many enrollment circumstances will constitute the
> moment of making an acceptance determination.) Such
> UA does not therefore need any certificate
> paths or CRLs ( or othe status source) at that 
> point in time.
 
Agreed.

The newly-issued certificate may be assumed to be "mechanically valid", by
which I mean that the path from this certificate to the relevant root
certificate is valid according to the mechanical processing rules.  By
accepting the certificate, the EE is telling the CA that the contents of the
newly-issued certificate are acceptable (i.e., validity period is fine;
contained policies are fine; etc., etc.).  The EE need not check signatures,
ARLs for any intermediate CA certs, etc..

> (3) CMP's CRL retrieval service is not meant
> to be a PKIX operational protocol. It is not
> clear if a conforming CMP implementation and CA
> will provide this facility.
 
Agreed.

It is "not clear" because the relevant CMP messages are OPTIONAL (i.e.,
they're not included in the set of messages specified as mandatory for
conformance in Section 4).  These messages, or the PKIX operational protocol
messages, or any other means may be used by the EE to retrieve revocation
information.

Carlisle.

P.S., Good summary of the discussion thus far -- thanks!



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20757 for <[e-mail]>; Thu, 27 Apr 2000 13:46:26 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id WAA28187; Thu, 27 Apr 2000 22:51:13 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 27 Apr 2000 22:51:12 +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 WAA22219; Thu, 27 Apr 2000 22:51:08 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id WAA13929; Thu, 27 Apr 2000 22:51:08 +0200 (MET DST)
Date: Thu, 27 Apr 2000 22:51:08 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Permanent identifiers in QC
Cc: [e-mail]

> 
>  Peter> ...
>  Peter> In most cultures, you don't change names *VERY* often.
> 
> In a fair number of cultures, somewhat less than half the people
> change their name at least once during their lifetime.

Let's say: Most persons once. (depending who choose the name
of the other partner and so on). 


> 
> Also, in some countries (the USA for example), quite apart from that
> general rule, you're pretty much free to change your name if you
> wish.  In fact, when immigrants are naturalized they are specifically
> told that this may be a good time to consider changing their name.

Right, if I ever try to become French I can also do that change my
name to Pierre Dubois or Roch Lasilve :-)

Anyway: If you change your name, you might WANT the consequence of
loosing the relationship automatically detectable by an RP.

It might be interesting to consider a certificate that contains
a subject with the newname and an alternatesubject with the old name
and this cert could be used to show it to some relying party in order
to establis a link.

Also, for pseudonyms, CA could create a cert, so that the subject CAN
use it to show ist REAL identity, for example. 

 


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 LAA18728 for <[e-mail]>; Thu, 27 Apr 2000 11:16:54 -0700 (PDT)
Received: (qmail 3823 invoked from network); 27 Apr 2000 18:17:33 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 27 Apr 2000 18:17:33 -0000
Message-ID: <[e-mail]>
Date: Thu, 27 Apr 2000 19:26:01 +0100
From: Bruno Salgueiro <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: pt,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Permanent identifiers in QC
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi everyone.

  As I'm involved in the development of a PKI this topic interests me.
  I always thought that the main responsible for the attribution of a
cer-
tificate would be the Registration Authority. It is this entity which
will
verify an individual identity, allocate a DN from its namespace defined
by
the CA (or after the approval of the CA) and then deliver the
authorisation
tokens to retrieve the certificate. If you want, the CA can also be the
RA
but it is the role separation I'm interested in.

  But if you have n RAs for the same CA and if the CA doesn't know who
is
applying (it is trusting the RA to do so), how can we allocate an unique
identifier for each person? And if you could, how would you then issue
anonymous certificates? Remember that a certificate doesn't need to
assure
a name, might be a role, an account number, etc. So, sometimes it
doesn't
really matter the person itself, onle the proof of possesion of a token.
  Finally, I'm aware that attribute certificates are ideally used to
assure
a third party of an account number but as of today, if someone needs to
do
this, it will use regular certificates. And for account numbers, it
might
even be desirable not to associated them with a person when you're
buying
or presenting them as a ticket...

  I would really like to read some comments about this. Nevertheless,
and
no flames please, what the heck is QC???!??

Regards,

Paul Koning wrote:
> 
> >>>>> "Peter" == Peter Sylvester <[e-mail]> writes:
> 
>  >>  Would you explain how, when the name of that person changes ?
>  >>
>  >> > This type of control is something that typically will be
>  >> performed only in > case of problems, i.e. on rare occasions where
>  >> some efforts to investigate > change in names are a reasonable.
>  >>
>  >> It may be useful for day to day work.
> 
>  Peter> ...
>  Peter> In most cultures, you don't change names *VERY* often.
> 
> In a fair number of cultures, somewhat less than half the people
> change their name at least once during their lifetime.
> 
> Also, in some countries (the USA for example), quite apart from that
> general rule, you're pretty much free to change your name if you
> wish.  In fact, when immigrants are naturalized they are specifically
> told that this may be a good time to consider changing their name.
> 
>      paul

-- 
=======================================================
Bruno Salgueiro       (mailto:[e-mail])
                   
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

Esta mensagem foi assinada com certificado MULTIcert.
Para obter o certificado da Autoridade de Certificação
PILOTO MULTIcert dirija-se ao site
            http://www.sibs.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17821 for <[e-mail]>; Thu, 27 Apr 2000 10:19:39 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQimth10386; Thu, 27 Apr 2000 17:24:28 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA25142; Thu, 27 Apr 00 13:21:09 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA05027; Thu, 27 Apr 2000 13:24:27 -0400
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Date: Thu, 27 Apr 2000 13:24:27 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Permanent identifiers in QC
References: <[e-mail]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid

>>>>> "Peter" == Peter Sylvester <[e-mail]> writes:

 >>  Would you explain how, when the name of that person changes ?
 >> 
 >> > This type of control is something that typically will be
 >> performed only in > case of problems, i.e. on rare occasions where
 >> some efforts to investigate > change in names are a reasonable.
 >> 
 >> It may be useful for day to day work.

 Peter> ...
 Peter> In most cultures, you don't change names *VERY* often.

In a fair number of cultures, somewhat less than half the people
change their name at least once during their lifetime.

Also, in some countries (the USA for example), quite apart from that
general rule, you're pretty much free to change your name if you
wish.  In fact, when immigrants are naturalized they are specifically
told that this may be a good time to consider changing their name.

     paul


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17438 for <[e-mail]>; Thu, 27 Apr 2000 10:07:39 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA25438; Thu, 27 Apr 2000 19:12:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 27 Apr 2000 19:12:26 +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 TAA20956; Thu, 27 Apr 2000 19:12:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA13880; Thu, 27 Apr 2000 19:12:25 +0200 (MET DST)
Date: Thu, 27 Apr 2000 19:12:25 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Permanent identifiers in QC
Cc: [e-mail]

> 
> Would you explain how, when the name of that person changes ?
> 
> > This type of control is something that typically will be performed only in
> > case of problems, i.e. on rare occasions where some efforts to investigate
> > change in names are a reasonable.
> 
> It may be useful for day to day work.

Big Brother is watching You.

The simple desire to create unique identifiers to trace down people
has not yet resulted in a society where all indiviuals get a 
bar code tatoo just after birth. 

Sorry, we are living a a world where people can have more than
one passport, they can change names, and on all kinds of
official documents you need the name changed.

In most cultures, you don't change names *VERY* often. And the benefit
of finding out that you have not given a free gift twice to the
same person in 1 out 100000 cases does not really convincing
compared with all possible negative impacts. 
Sometimes, if you marry twice, it might be desirable to loose some
tracability.

trying to declare something as PERMANENT does not help anyway, because
in this case, some people will get multiple permanent identifiers
anyway for some more or less obvious reasons.


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15622 for <[e-mail]>; Thu, 27 Apr 2000 08:10:16 -0700 (PDT)
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 RAA22342; Thu, 27 Apr 2000 17:14:57 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 Apr 2000 17:14:59 +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: Stefan Santesson <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Permanent identifiers in QC
References: <03E49309E8F5D31183F7000629396ECCD657@TRUST>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefan,

Comments in line;

> Denis
> 
> Comment in-line;
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> > Subject: Re: Permanent identifiers in QC
> >
> >
> >
> > > Folks, I've been sort of off-line the last days.
> >
> > > So as caching up with this thread I think we need to decide
> > the progress of
> > > this issue.
> >
> > > I would just want to add an observation regarding NR and
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and
> > ensure that these
> > > certificates identifies the same person EVEN if some parts
> > of the DN is not
> > > matching.
> >
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> >
> 
> For non-repudiation, it will be possible to determine that two different
> DN:s refer to the same person without the use of "permanent identifiers".

Would you explain how, when the name of that person changes ?

> This type of control is something that typically will be performed only in
> case of problems, i.e. on rare occasions where some efforts to investigate
> change in names are a reasonable.

It may be useful for day to day work.

Denis

> /Stefan


Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15268 for <[e-mail]>; Thu, 27 Apr 2000 07:53:43 -0700 (PDT)
Received: by TRUST with Internet Mail Service (5.5.2650.21) id <JVYHA7BT>; Thu, 27 Apr 2000 16:58:45 +0200
Message-ID: <03E49309E8F5D31183F7000629396ECCD657@TRUST>
From: Stefan Santesson <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Thu, 27 Apr 2000 16:58:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Denis

Comment in-line;

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 26, 2000 10:27 AM
> To: Stefan Santesson
> Cc: Russ Housley; 'Stephen Kent'; '[e-mail]'
> Subject: Re: Permanent identifiers in QC
> 
> 
>  
> > Folks, I've been sort of off-line the last days.
>  
> > So as caching up with this thread I think we need to decide 
> the progress of
> > this issue.
>  
> > I would just want to add an observation regarding NR and 
> Authentication.
> > The issue is NOT whether permanent identifiers are of value for
> > Authentication or NR. What IS an issue is whether it is 
> relevant for NR to
> > be able to compare 2 names in 2 different certificates and 
> ensure that these
> > certificates identifies the same person EVEN if some parts 
> of the DN is not
> > matching.
> 
> For non-repudiation, the permanent identifier may be used to link
> different transactions to the same individual, even when the subject
> name of the individual changes. So it is relevant.
> 

For non-repudiation, it will be possible to determine that two different
DN:s refer to the same person without the use of "permanent identifiers".

This type of control is something that typically will be performed only in
case of problems, i.e. on rare occasions where some efforts to investigate
change in names are a reasonable.

/Stefan



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09721 for <[e-mail]>; Thu, 27 Apr 2000 03:47:34 -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 GAA26177; Thu, 27 Apr 2000 06:52:31 -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-07.txt
Date: Thu, 27 Apr 2000 06:52:27 -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-07.txt
	Pages		: 21
	Date		: 26-Apr-00
	
A time stamping service allows to prove that a datum existed before 
a particular time and can be used by a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR]). This document describes the format of a request sent to a 
Time Stamping Authority (TSA) and of the response that is returned.
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-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-time-stamp-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-time-stamp-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-time-stamp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-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 lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06442 for <[e-mail]>; Wed, 26 Apr 2000 01:23:14 -0700 (PDT)
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 KAA23524; Wed, 26 Apr 2000 10:27:25 +0200
Message-ID: <[e-mail]>
Date: Wed, 26 Apr 2000 10:27:26 +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: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Permanent identifiers in QC
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 
> Folks, I've been sort of off-line the last days.
 
> So as caching up with this thread I think we need to decide the progress of
> this issue.
 
> I would just want to add an observation regarding NR and Authentication.
> The issue is NOT whether permanent identifiers are of value for
> Authentication or NR. What IS an issue is whether it is relevant for NR to
> be able to compare 2 names in 2 different certificates and ensure that these
> certificates identifies the same person EVEN if some parts of the DN is not
> matching.

For non-repudiation, the permanent identifier may be used to link
different transactions to the same individual, even when the subject
name of the individual changes. So it is relevant.

> This particular aspect is only raised as a feature for access control (when
> an entity changes his certificate, or possesses several certificates with
> different DN). In the case of NR and legal signatures, the only issue is to
> establish the relation between a certificate and the individual key holder
> (regardless of other certificates). Here the current profile provides the
> necessary means.

No. See above.

> But....

Following the discussion on the serial Number and the Permanent
Identifier that took place on the PKIX mailing list and at the last
IETF meeting in Adelaïde, I am paying more and more attention to the
QC draft.

The document is defining the concept of "unmistakable identity". Now
that we have introduced the use of serialNumber, I wonder why such a
concept is still needed.

First, the wording "unmistakable identity" is not used in the
Directive, so this is the first reason why I wonder it is needed.

Second, let us recall, what RFC 2459 says:

   The subject field from a public key certificate identifies the 
   entity associated with the public key stored in the subject
public 
   key field.  The subject name may be carried in the subject field 
   and/or the subjectAltName extension.

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name
field.

The current specification (QC-03) mandates the use of the subject
field. In such a case, as defined *in RFC 2459*, the name is unique.
Moreover, it is unique not only at an instant of time, but during
the whole life of the CA. Note that ISO/ITU X.509 does not mandate
this and I guess this is where the problem comes from. The current
QC-03 document references *X.501* while it should reference RFC
2459. If we were *only* using the subjectAltName extension then such
a concept could be useful. But at the present time, we don't.

The chapter 2.4, called Uniqueness of names, should be deleted.

I would also propose the following rewording for section 3.1.2:

3.1.2 Subject

   The subject field MUST contain an X.500 distinguished name (DN).
   The subject field from a public key certificate identifies the 
   entity associated with the public key stored in the subject
public 
   key field. The DN MUST be unique for each subject entity
certified 
   by the one CA as defined by the issuer name field. 

   The subject field SHALL contain an appropriate subset of the
   following attributes:

      countryName;
      commonName;
      surname;
      givenName;
      pseudonym;
      serialNumber;
      organizationName;
      organizationalUnitName;
      stateOrProvinceName
      localityName and
      postalAddress.

   Of these attributes, the subject field SHALL include at least one
of
   the following:

      Choice   I:  commonName
      Choice  II:  givenName
      Choice III:  pseudonym

   The subject field MAY contain other attributes.

   Any other attributes that MAY be present in either the subject 
   alternative name extension or the subject directory attributes 
   extension MAY help to give a better human understanding of who 
   the individual really is, but uniqueness of the name is achieved 
   singly by the subject field. 

The countryName attribute value (... then continue with the current
text)

As a result of this, the wording "unmistakable identity" should be
deleted from the whole document. In this way, we will be able to
suppress ambiguous sentences, like in 3.1.2 :

"  Certificates compliant with this profile SHALL at the same time 
   specify a distinguished name and an unmistakable identity of the 
   subject (see 2.4 for definition of distinguished name and 
   unmistakable identity).

   Attributes stored in the subject field SHALL at least form a
   distinguished name of the subject, but they MAY also specify a
   complete unmistakable identity."


I reproduced below an extract from Annex I from the European
Directive on Electronic Signatures:

" Requirements for qualified certificates

Qualified certificates must contain:

(…)

(c)	the name of the signatory or a pseudonym, which shall be
identified as such;"


> Regardless of this I agree with Steve that this issue should be advanced on
> it's own and merged later if it's found relevant to do so.

Anyway, I am preparing some text to describe what a permanent
identifier is and in which OID arc it should be located. This should
be ready at the end of this week. In this way we will be able to
discuss whether the permanent identifier should be, for the time
being, an independent RFC that the QC draft could reference, or
whether it should be an RFC of its own.

Regards,

Denis

 
> I would therefore request the QC profile to be advanced in it's current
> shape (except for a minor noted update in the reference list).
> 
> Steve:
> How do we proceed.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Friday, April 14, 2000 4:36 PM
> > To: Stephen Kent
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Permanent identifiers in QC
> >
> >
> > I agree with Steve.  Note that the CAT Working Group has defined an
> > OTHER-NAME for Kerberos names.
> >
> > Russ
> >
> >
> > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > >Tom,
> > >
> > >I have no problems with the sorts of IDs you proposed in your ASN
> > >GeneralName Other-Name examples. They seem to be consistent with the
> > >arguments that Denis has made for such constructs. However,
> > before we add
> > >these to the updated part 1, I think we need more time to
> > explore the
> > >utility for these name forms.  The debate on the list shows
> > that there are
> > >widely diverse opinions about what such IDs are good for,
> > what scope is
> > >feasible/appropriate, etc.  I'd hesitant to hold up progress on the
> > >revision to 2459 to add this sort of facility which has been
> > proposed only
> > >recently.  That's why several folks have suggested a separate, small
> > >document whoch can be advanced separately, and merged into
> > 2459 if there
> > >is sufficient, consistent support.
> > >
> > >Steve
> >


Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.121.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02948 for <[e-mail]>; Tue, 25 Apr 2000 23:00:29 -0700 (PDT)
Received: from [38.29.129.250] (ip250.phoenix15.az.pub-ip.psi.net [38.29.129.250]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id XAA22171; Tue, 25 Apr 2000 23:05:13 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04310101b52c3635b091@[38.29.124.40]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 25 Apr 2000 23:05:02 -0700
To: [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: Negative Integers & ASN.1
Cc: [e-mail]
Content-Type: multipart/alternative; boundary="============_-1255393382==_ma============"

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

there is no specific primitive type for a negative integer. two's 
compliment encoding is used to represent either a positive, zero, or 
negative value.

from the encoding rules

8.3 Encoding of an integer value

8.3.1 The encoding of an integer value shall be primitive. The 
contents octets shall consist of one or more octets.

8.3.2 If the contents octets of an integer value encoding consist of 
more than one octet, then the bits of the first
octet and bit 8 of the second octet
a) shall not all be ones; and
b) shall not all be zero.
NOTE - These rules ensure that an integer value is always encoded in 
the smallest possible number of octets.

8.3.3 The contents octets shall be a two's complement binary number 
equal to the integer value, and consisting of bits 8 to 1 of the 
first octet, followed by bits 8 to 1 of the second octet, followed by 
bits 8 to 1 of each octet in turn up to and including the last octet 
of the contents octets.

NOTE - The value of a two' s complement binary number is derived by 
numbering the bits in the contents octets, starting with bit 1 of the 
last octet as bit zero and ending the numbering with bit 8 of the 
first octet. Each bit is assigned a numerical value of 2 N , where N 
is its position in the above numbering sequence. The value of the 
two' s complement binary number is obtained by summing the numerical 
values assigned to each bit for those bits which are set to one, 
excluding bit 8 of the first octet, and then reducing this value by 
the numerical value assigned to bit 8 of the first octet if that bit 
is set to one.

i assume you must be doing asn.1 encoding by hand; the tools out 
there handle this issue.

if your question was really about how to constrain the value of a 
type to be negative, there is notation to do that also

    hoyt


At 9:14 PM -0700 4/25/00, chandrasekaran natarajan wrote:
>hello,
>
>Thanks Mr.Peter Gutmann and Aram Perez for helping
>me out test my BER/DER Encoding..
>
>I have another doubt....Is there a standard Tag for
>Negative Numbers in ASN.1 and  in general can
>some one help me out on encoding Negative Integers.
>
>Thanks
>
>Chandar
>
>
>
>Send FREE April Fool's Greetings to your friends!
>http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

--============_-1255393382==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Negative Integers &amp;
ASN.1</title></head><body>
<div>there is no specific primitive type for a negative integer. two's
compliment encoding is used to represent either a positive, zero, or
negative value.</div>
<div><br></div>
<div>from the encoding rules</div>
<div><br></div>
<div><font face="Geneva" size="+1" color="#000000"><b>8.3 Encoding of
an integer value</b></font></div>
<div><font face="Geneva" size="+1" color="#000000"><b><br>
8.3.1</b> The encoding of an integer value shall be primitive. The
contents octets shall consist of one or more octets.</font></div>
<div><font face="Geneva" size="+1" color="#000000"><br>
<b>8.3.2</b> If the contents octets of an integer value encoding
consist of more than one octet, then the bits of the first<br>
octet and bit 8 of the second octet<br>
a) shall not all be ones; and<br>
b) shall not all be zero.<br>
</font><font face="Geneva" color="#000000">NOTE - These rules
ensure that an integer value is always encoded in the smallest
possible number of octets.</font></div>
<div><font face="Geneva" color="#000000"><br></font></div>
<div><font face="Geneva" size="+1" color="#000000"><b>8.3.3</b> The
contents octets shall be a two's complement binary number equal to
the integer value, and consisting of bits 8 to 1 of the first octet,
followed by bits 8 to 1 of the second octet, followed by bits 8 to 1
of each octet in turn up to and including the last octet of the
contents octets.</font></div>
<div><font face="Geneva" size="+1" color="#000000"><br></font></div>
<div><font face="Geneva" color="#000000">NOTE - The value of a
two' s complement binary number is derived by numbering the bits in
the contents octets, starting with bit 1 of the last octet as bit
zero and ending the numbering with bit 8 of the first octet. Each bit
is assigned a numerical value of 2<font size="-1"> N</font> , where N
is its position in the above numbering sequence. The value of the
two' s complement binary number is obtained by summing the
numerical values assigned to each bit for those bits which are set to
one, excluding bit 8 of the first octet, and then reducing this value
by the numerical value assigned to bit 8 of the first octet if that
bit is set to one.</font></div>
<div><br></div>
<div>i assume you must be doing asn.1 encoding by hand; the tools out
there handle this issue.</div>
<div><br></div>
<div>if your question was really about how to constrain the value of
a type to be negative, there is notation to do that also</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div>At 9:14 PM -0700 4/25/00, chandrasekaran natarajan wrote:</div>
<blockquote type="cite" cite>hello,<br>
<br>
Thanks Mr.Peter Gutmann and Aram Perez for helping<br>
me out test my BER/DER Encoding..<br>
<br>
I have another doubt....Is there a standard Tag for<br>
Negative Numbers in ASN.1 and&nbsp; in general can<br>
some one help me out on encoding Negative Integers.<br>
<br>
Thanks<br>
<br>
Chandar<br>
<br>
<br>
<br>
Send FREE April Fool's Greetings to your friends!<br>
http://www.whowhere.lycos.com/redirects/A<span
></span>merican_Greetings.rdct</blockquote>
<div><br></div>
</body>
</html>
--============_-1255393382==_ma============--


Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA01139 for <[e-mail]>; Tue, 25 Apr 2000 21:12:04 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Apr 25 21:16:05 2000
To: [e-mail]
Date: Tue, 25 Apr 2000 21:16:05 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: Negative Integers & ASN.1
X-Sender-Ip: 203.197.240.18
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 



Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA01015 for <[e-mail]>; Tue, 25 Apr 2000 21:11:12 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Apr 25 21:15:13 2000
To: [e-mail]
Date: Tue, 25 Apr 2000 21:15:13 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Expiredinmiddle: true
X-Mailer: MailCity Service
Subject: Negative Integers & ASN.1
X-Sender-Ip: 203.197.240.18
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 



Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA00995 for <[e-mail]>; Tue, 25 Apr 2000 21:11:02 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Apr 25 21:14:57 2000
To: [e-mail]
Date: Tue, 25 Apr 2000 21:14:57 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: Negative Integers & ASN.1
X-Sender-Ip: 203.197.240.18
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

Thanks Mr.Peter Gutmann and Aram Perez for helping
me out test my BER/DER Encoding..

I have another doubt....Is there a standard Tag for 
Negative Numbers in ASN.1 and  in general can 
some one help me out on encoding Negative Integers.

Thanks

Chandar 



Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from trust.addtrust.com ([212.28.197.133]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13197 for <[e-mail]>; Tue, 25 Apr 2000 15:52:49 -0700 (PDT)
Received: by trust.addtrust.com with Internet Mail Service (5.5.2650.21) id <J4DKQQAP>; Wed, 26 Apr 2000 00:57:38 +0200
Message-ID: <[e-mail]>
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Wed, 26 Apr 2000 00:57:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Folks, I've been sort of off-line the last days.

So as caching up with this thread I think we need to decide the progress of
this issue.

I would just want to add an observation regarding NR and Authentication.
The issue is NOT whether permanent identifiers are of value for
Authentication or NR. What IS an issue is whether it is relevant for NR to
be able to compare 2 names in 2 different certificates and ensure that these
certificates identifies the same person EVEN if some parts of the DN is not
matching.

This particular aspect is only raised as a feature for access control (when
an entity changes his certificate, or possesses several certificates with
different DN). In the case of NR and legal signatures, the only issue is to
establish the relation between a certificate and the individual key holder
(regardless of other certificates). Here the current profile provides the
necessary means.


But....

Regardless of this I agree with Steve that this issue should be advanced on
it's own and merged later if it's found relevant to do so.

I would therefore request the QC profile to be advanced in it's current
shape (except for a minor noted update in the reference list).

Steve:
How do we proceed.

/Stefan


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, April 14, 2000 4:36 PM
> To: Stephen Kent
> Cc: [e-mail]; [e-mail]
> Subject: Re: Permanent identifiers in QC
> 
> 
> I agree with Steve.  Note that the CAT Working Group has defined an 
> OTHER-NAME for Kerberos names.
> 
> Russ
> 
> 
> At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> >Tom,
> >
> >I have no problems with the sorts of IDs you proposed in your ASN 
> >GeneralName Other-Name examples. They seem to be consistent with the 
> >arguments that Denis has made for such constructs. However, 
> before we add 
> >these to the updated part 1, I think we need more time to 
> explore the 
> >utility for these name forms.  The debate on the list shows 
> that there are 
> >widely diverse opinions about what such IDs are good for, 
> what scope is 
> >feasible/appropriate, etc.  I'd hesitant to hold up progress on the 
> >revision to 2459 to add this sort of facility which has been 
> proposed only 
> >recently.  That's why several folks have suggested a separate, small 
> >document whoch can be advanced separately, and merged into 
> 2459 if there 
> >is sufficient, consistent support.
> >
> >Steve
> 


Received: from mm-pop.kddcom.co.jp (mm-pop.kddcom.co.jp [210.142.34.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12563 for <[e-mail]>; Mon, 24 Apr 2000 17:41:36 -0700 (PDT)
Received: from kddcom.co.jp (100036.kddcom.co.jp [210.174.100.36]) by mm-pop.kddcom.co.jp (8.9.3/3.7W) with ESMTP id JAA14470 for <[e-mail]>; Tue, 25 Apr 2000 09:46:16 +0900 (JST)
Message-ID: <[e-mail]>
Date: Tue, 25 Apr 2000 09:45:49 +0900
From: Akihiro Takahashi <[e-mail]>
Organization: KCOM MilliCent Project  =?iso-2022-jp?B?RGVwdC4bJEIhIRsoQjAzLTMyNDMtMTE=?=25
X-Mailer: Mozilla 4.7 [ja] (Win98; I)
X-Accept-Language: ja
MIME-Version: 1.0
To: pkix ML <[e-mail]>
Subject: CA process
References: <[e-mail]>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

Dear Sirs,

Now we are try to make a study for CA business operation procedure
in detail. Is there any mailing list for CA business? Or does anyone
suggest me for how to study it. Cause we would like to start CA 
business in Japan!


"David P. Kemp" wrote:
> 
> > From: Peter Williams <[e-mail]>
> >
> > Does a CA who sends such certificates to a user
> > bear responsibility for the current, individual reliability
> > of any certificate is sends? I.e.
> > can one assume that the subscriber's CA has just checked the
> > certs' non-revoked status, or the provider's contiuing
> > accreditation certificate status, under the CA domain's or
> > another regulators governing policy, prior to inducing others
> > to use or rely on those certificates.
> >
> > Surely, by virtue of supplying CA certifificates to a subscriber
> > at such a critical juncture one is performing an authoritative,
> > legal introduction to the entites bound to the public keys?
> 
> Surely, one is not.  The bag-o'-certs is *nothing* more than a
> pile of information that may save the subscriber the effort of
> looking them up in a directory or elsewhere.  It is entirely
> up to the subscriber to choose a trust anchor and validate all
> certs from that anchor.  If one or more provided certs cannot
> be so validated, I don't see how they can be regarded as
> "introduced" or "considered reliable by a TTP-grade CA".
> 
> What, precisely, is a subscriber supposed to do with intermediate
> (non-self-signed) certificates which have been "introduced" by a CA?
> 
> Dave


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08720 for <[e-mail]>; Mon, 24 Apr 2000 12:17:12 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA26478; Mon, 24 Apr 2000 12:21:44 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <2XT0KVDT>; Mon, 24 Apr 2000 12:20:50 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Salz, Rich'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: importing from rfc2560
Date: Mon, 24 Apr 2000 12:20:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Rich,

Correct.  I discovered this myself while writing the OCSPX I-D.  I got
together with Russ during Adelaide to resolve this.  He allocated the
following OID:

id-mod-ocsp OBJECT IDENTIFIER ::= { id-mod 14 }

where

id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }    -- modules

and

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

It'll find its way into RFC2560 in due course.

Mike





> -----Original Message-----
> From: Salz, Rich [mailto:[e-mail]]
> Sent: Monday, April 24, 2000 10:36 AM
> To: '[e-mail]'
> Subject: importing from rfc2560
> 
> 
> I'm a neophyte at writing ASN.1, but there doesn't seem to be 
> an OID for me
> to use if I want to import something from OCSP, RFC2560.  Correct?
> 


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06915 for <[e-mail]>; Mon, 24 Apr 2000 10:30:52 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP for <[e-mail]> id 4914115531; Mon, 24 Apr 2000 13:34:56 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 0A3B77C0E8 for <[e-mail]>; Mon, 24 Apr 2000 13:34:56 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <2YFW3T9J>; Mon, 24 Apr 2000 13:36:01 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: importing from rfc2560
Date: Mon, 24 Apr 2000 13:36:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I'm a neophyte at writing ASN.1, but there doesn't seem to be an OID for me
to use if I want to import something from OCSP, RFC2560.  Correct?


Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24981 for <[e-mail]>; Sun, 23 Apr 2000 07:43:30 -0700 (PDT)
Received: by MARS with Internet Mail Service (5.5.2650.21) id <2JTDNDGV>; Sun, 23 Apr 2000 10:47:25 -0400
Message-ID: <D92EE22C97C3D311855E005004E0CBF00336D7@MARS>
From: Aram Perez <[e-mail]>
To: [e-mail]
Subject: RE: Testing BER/DER Encoding
Date: Sun, 23 Apr 2000 10:47:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: chandrasekaran natarajan [mailto:[e-mail]]
> Sent: Saturday, April 22, 2000 3:19 PM
> To: [e-mail]
> Subject: Testing BER/DER Encoding
> 
> 
> hello,
> Please Let me know how to check my BER/DER
> Encodings is correct or not. Is there  a
> tool available for checking the users' BER/DER
> is correct

Check out http://members.xoom.com/Aram_Perez/BERViewer.htm

and http://www.oss.com/products/syntax1.html.

Regards,
Aram Perez


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 NAA03855 for <[e-mail]>; Sat, 22 Apr 2000 13:32:55 -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 IAA06928; Sun, 23 Apr 2000 08:37:17 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95643583713574>; Sun, 23 Apr 2000 08:37:17 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  Testing BER/DER Encoding
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sun, 23 Apr 2000 08:37:17 (NZST)
Message-ID: <[e-mail]>

"chandrasekaran natarajan" <[e-mail]> writes:

>Please Let me know how to check my BER/DER Encodings is correct or not. Is 
>there  a tool available for checking the users' BER/DER is correct

Look for dumpasn1, available from http://www.cs.auckland.ac.nz/~pgut001/.

Peter.



Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA03257 for <[e-mail]>; Sat, 22 Apr 2000 12:15:14 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat Apr 22 12:18:55 2000
To: [e-mail]
Date: Sat, 22 Apr 2000 12:18:55 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: Testing BER/DER Encoding
X-Sender-Ip: 203.197.240.51
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,
Please Let me know how to check my BER/DER
Encodings is correct or not. Is there  a
tool available for checking the users' BER/DER
is correct


Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06180 for <[e-mail]>; Fri, 21 Apr 2000 09:48:05 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA24879; Fri, 21 Apr 2000 18:52:25 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 21 Apr 2000 18:52:25 +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 SAA29168; Fri, 21 Apr 2000 18:52:23 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA11644; Fri, 21 Apr 2000 18:52:23 +0200 (MET DST)
Date: Fri, 21 Apr 2000 18:52:23 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Missing Protocol ?
Cc: [e-mail]

> > > From: Denis Pinkas <[e-mail]>
> > >
> > > I see no reason for this. AAs (Attributes Authorities) are not the
> > > same like RAs (Registration Authorities).
> > > The response comes from the RA, not an AA. In any case the use of
> > > AAs is not mandated.
> > 
> > It's a question of assurance.  If you trust a directory, you don't need
> > signed attributes.  I lean towards end-to-end security whenever
> > possible, and therefore prefer the RA to sign attributes rather than
> > having the directory dish out unprotected information.  If the
> > authoritative RA database is available online, there is little reason
> > to prefer signed over unsigned.  But as soon as the information is
> > replicated, cached, passed along, or otherwise distributed, the RA's
> > signature becomes helpful.  When the RA signs attributes, it becomes,
> > by definition, an AA.
> 
> Certainly not. Using AC mandates a very precise data structure. So
> it is not because the answer is signed that the RA becomes an AA.
This has nothing to do with the content of the AC. It may be someone
else that the original RA, that creates the AC, but that's probably
not the slightly more difficult situation both of you had in mind.
 
It was discussed that an attrib cert could be appropriate vehicle to carry
a statement of the kind:

  We, the 'issuer' declare (sign) that  'holder' has been registered
  and we have stored the following 'attributes'.
  
Attributes are defined by oids, the CPS of the RA would define the semantics.
the requester can make a request without knowing the schema of the data.

It seems thus possible to me that the RA information can be represented
in an attrib cert.

If so, what does this tell us about the RA caracteristique of being an AA.
I don't care. 

> Note that the RA may respond without any signature and that the
> security may be provided using, e.g. TLS.

What you are saying here is very strange: A judge does not just want
to read a data base, but wants to create a verifiable decision.

There is not just 'one security'. The security of the transport of the
information is something else than the security of the objects. 

There is also the engagement / guarantee implied by the signature of the RA. 

It may be required that the requests/responses need to be archived
The certificate owner may have the right that the RA prooves exactly to whom the
information have been given, and why. There may be strict privacy laws, and
just standard security/audit rules, etc. 
This may mean that the transaction result may need to stored encrypted,
etc.  

It may be also useful to have a reponse: "We, the RA declare that YOU, the requester,
has asked at date X to obtain information about certuser XXXX, we delivered the
following information at date Y to You, you are already the 4711th one, we have
registered the transaction under id 123465." 

Now you can select your favorite more or less secure query protocol
or/and data format, e.g.:
LDAP, CMP++, CMC++ OCSP-Y-NOT, SCVP++, BERT++, DVCS, SNMP, DAP, YASSQPI, 
XML-DIGSIG/XER, POLICE/BLOCKS, JUDGE/SMIME, ... 

> Anyway the intent is not to place that information in multiple
> untrusted Directories, but to query one server (ain the same way
> this is done for OCSP). The idea is to allow to locally store that
> information in some data base that could be queried using LDAP.

This is an implementation detail of the RA. You could have:

'select * from RABASE where certhash=XXXXXXX and serialnumber=1234'

Why does all that need to be online with a direct response. Before handing out
these information, a human intervention may be required, or the information
may not be available online. someone might need to open a safe and get the
required archive cd. 

 cat cdrom/XXXXXXX/1234 | sign+-crypt+log ... 

Thus you should consider to make the transaction transport independant
(mail, http, blocks, pigeons + paper copy).   

P


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03640 for <[e-mail]>; Fri, 21 Apr 2000 07:19:47 -0700 (PDT)
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 QAA26738; Fri, 21 Apr 2000 16:24:05 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Apr 2000 16:24: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: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Missing Protocol ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
> > From: Denis Pinkas <[e-mail]>
> >
> > I see no reason for this. AAs (Attributes Authorities) are not the
> > same like RAs (Registration Authorities).
> > The response comes from the RA, not an AA. In any case the use of
> > AAs is not mandated.
> 
> It's a question of assurance.  If you trust a directory, you don't need
> signed attributes.  I lean towards end-to-end security whenever
> possible, and therefore prefer the RA to sign attributes rather than
> having the directory dish out unprotected information.  If the
> authoritative RA database is available online, there is little reason
> to prefer signed over unsigned.  But as soon as the information is
> replicated, cached, passed along, or otherwise distributed, the RA's
> signature becomes helpful.  When the RA signs attributes, it becomes,
> by definition, an AA.

Certainly not. Using AC mandates a very precise data structure. So
it is not because the answer is signed that the RA becomes an AA.
Note that the RA may respond without any signature and that the
security may be provided using, e.g. TLS.

Anyway the intent is not to place that information in multiple
untrusted Directories, but to query one server (ain the same way
this is done for OCSP). The idea is to allow to locally store that
information in some data base that could be queried using LDAP. 

Regards,

Denis

> Regards,
> Dave


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 GAA03067 for <[e-mail]>; Fri, 21 Apr 2000 06:46:33 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA15269 for <[e-mail]>; Fri, 21 Apr 2000 09:48:34 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 21 Apr 2000 09:50:00 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Missing Protocol ?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WxCwg+L7wotBd6v5yiN0WQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Denis Pinkas <[e-mail]>
> 
> I see no reason for this. AAs (Attributes Authorities) are not the
> same like RAs (Registration Authorities).
> The response comes from the RA, not an AA. In any case the use of
> AAs is not mandated.

It's a question of assurance.  If you trust a directory, you don't need
signed attributes.  I lean towards end-to-end security whenever
possible, and therefore prefer the RA to sign attributes rather than
having the directory dish out unprotected information.  If the
authoritative RA database is available online, there is little reason
to prefer signed over unsigned.  But as soon as the information is
replicated, cached, passed along, or otherwise distributed, the RA's
signature becomes helpful.  When the RA signs attributes, it becomes,
by definition, an AA.

Regards,
Dave




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 GAA02674 for <[e-mail]>; Fri, 21 Apr 2000 06:30:47 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA12204 for <[e-mail]>; Fri, 21 Apr 2000 09:32:48 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 21 Apr 2000 09:34:14 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vPx5LDvtuJg3bnB45dFS2Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Agree with all 3.  However, a CPS may require acceptance
actions that are not required by the CMP technical
specification.

If the CPS requires the EE's UA to validate EE's certificate
as a condition of acceptance, the UA will need sufficient
information from some source to perform the validation.
CMP, or PKIX operational protocols, or offline operations
could provide that information.

It's up to an accrediting body, not the IETF, to determine
if all accreditable CPSs must require (2).

Dave



> From: Peter Williams <[e-mail]>
> 
> Alex,
> 
> We have seemingly cleared up or determined
> three technical points from the discussion. Do
> say if any description below is not
> correct - in your view.
> 
> (1) a CMP responder does not need to send any
> particular cert path to the subscriber, when
> returning the EE cert for EE acceptance. The UA
> should not assume presence of any particular
> certs, including the CA cert or any superior
> certs in the domain's trust network, in the 
> message field in discussion. Futhermore, any
> certs that are sent are in bag order.
> 
> (2) According to CMP designers, the UA does not
> need to verify the signature of the 
> EE certificate upon initial receipt (which
> in many enrollment circumstances will constitute the
> moment of making an acceptance determination.) Such
> UA does not therefore need any certificate
> paths or CRLs ( or othe status source) at that 
> point in time.
> 
> (3) CMP's CRL retrieval service is not meant
> to be a PKIX operational protocol. It is not
> clear if a conforming CMP implementation and CA
> will provide this facility.
> 
> Peter.



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 GAA02370 for <[e-mail]>; Fri, 21 Apr 2000 06:17:11 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA10355 for <[e-mail]>; Fri, 21 Apr 2000 09:19:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 21 Apr 2000 09:20:32 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 43Yhi3wdMg2aLTieCdn/fg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Hi Peter,

I believe there is an issue of "best commercial practices"
here.  If a building contractor presented a forged paper license
or misappropriated the identity of a legitimately licensed
contractor, I'm 100% certain that is a misrepresentation of
fact.  If the contractor presented a legitimate license, within
its printed validity interval but which had been suspended/revoked,
a "90% misrepresentation" has occurred.  The homeowner
has a 10% responsibility to check references, the BBB, and the
contractor's professional association, but I suspect a judge
would not penalize the homeowner too severely for not having
done so.

But accepted practice is for police officers to verify the
putative validity of plates and drivers licenses with a radio
call.  And accepted practice for PKIX clients should be to
validate certificates before relying upon them.  If that is
true, there is fault with the CA for misrepresentation, and
fault (at least 50%) with the subscriber for lack of due diligence.
The CA is not blameless, and can be punished (given a black
mark on the compliance audit, or de-certified) by a regulating
body.  But, IMO, the only damages the subscriber suffers is
the fact that subscriber's certificate will not be accepted
by RPs.  The CA is responsible for promises made to deliver
a valid certificate and business lost as a result of failure
to deliver what was promised.  But at the moment of delivery,
(again IMO, IANAL!) the subscriber assumes nearly all the
responsibility for not properly validating the cert as part
of acceptance.

Regards,
Dave


> From: Peter Williams <[e-mail]>
> To: "'David P. Kemp'" <[e-mail]>, [e-mail]
> Subject: RE: What is the order of certificates in a certificate chain?
> Date: Thu, 20 Apr 2000 19:57:30 -0700
> 
> Hi David:
> 
> Consider the following reasoning:-
> 
> A CA, in the PKIX model, may be accredited - something
> that is signaled via the issuance of a cross-certificate
> or similar.
> 
> If a (trusted) CA quotes such a cross-certificate during
> certificate application procedures, it is
> essentially representing the validity of the underlying
> accreditation. A CA which quoted a revoked
> accreditation cross-certificate would
> be likely acting in a manner which is a mis-representation
> of fact, surely.
> 
> If a building contractor came to your house,
> presented an official and legally-recognised
> paper license to do electrical work, and you subsequently 
> determine that the license had been revoked in
> the license registry prior to presentation of the
> paper during contract negotiation, would you not feel a 
> simple mis-representation had occured?
> 
> Could a regulator not punish that contractor for
> not suspending licensed work - and/or falsely
> imputing a licensed standing?
> 
> I would think that a best practices Internet CA has 
> a simple professional if not a legal duty to ensure that
> it does not provide false information to a subscriber 
> during CMP; especially information that might prejudice 
> the determination of that subscriber when establishing 
> the initial accuracy of a certificate that will bind 
> him/her at NR grade of proof - following formal 
> acceptance of that certificate.



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15521 for <[e-mail]>; Fri, 21 Apr 2000 00:10:14 -0700 (PDT)
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 JAA31798; Fri, 21 Apr 2000 09:14:27 +0200
Message-ID: <[e-mail]>
Date: Fri, 21 Apr 2000 09:14:29 +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: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Missing Protocol ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

Let me comment and rephrase what you say.

> Denis,
> 
> If the information is NOT in a public key certificate, and the
> information IS to be provided electronically instead of using methods
> from the 60's, then the question is how to provide it.

Correct.

> I'm with Bob and Peter: the directory is the answer and no new
> protocol is needed.  

LDAP (no the directory) is one answer. Then a schema and the
definition of attributes is needed.

> If there are attributes defined for passport
> number/validity, bank account number, optically-scanned document, etc,
> then those attributes can be stored in the directory either in unsigned
> normal form 

This is/was the only case I considered.

> or in signed attribute certificates.

I see no reason for this. AAs (Attributes Authorities) are not the
same like RAs (Registration Authorities).
The response comes from the RA, not an AA. In any case the use of
AAs is not mandated.

> No matter how new attribute certificates are, they are more mature than
> this undefined 'missing protocol'.  It would be most productive to use
> ACs and/or directories as is, and focus energy on establishing the catalog
> of attribute definitions.

I agree that we could work on the catalog of attribute definitions.
The only problem I see is that the requester only knows the class of
information he is looking at, while LDAP provides very precise
attributes. This attributes loosely match the classes that are
requested. If we can provide a way for getting this loose mapping,
then we are close to a solution. :-)

Regards,

Denis

 
> Dave
> 
> > From: Denis Pinkas <[e-mail]>
> >
> > Attribute Certificates are quite new and new [not] frequently used (if
> > used). As stated above, the problem does not directly relate to
> > Attribute Certificates.
> >
> > > - There are methods/protocols to "publish" certificates, or to give
> > >   controlled and secured access to them.
> >
> > Yes, but the information that is needed is NOT in the certificate.
> >
> > > > As a bottom line: if a protocol is not going to be used frequently, and we
> > > > can get by without it for occasional need, do we need the protocol at all?
> >
> > When we will have a significant deployment of a world-wide PKI, this
> > protocol will be more and more useful/needed. We are trying to
> > anticipate the needs.
> >
> > Regards,
> >
> > Denis
> >
> > > I think we don't need a new one.
> > >
> > > Peter


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA29359 for <[e-mail]>; Thu, 20 Apr 2000 20:00:24 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <JCS1AAV4>; Thu, 20 Apr 2000 20:01:16 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Alex Deacon'" <[e-mail]>, PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 20 Apr 2000 20:01:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

Alex,

We have seemingly cleared up or determined
three technical points from the discussion. Do
say if any description below is not
correct - in your view.

(1) a CMP responder does not need to send any
particular cert path to the subscriber, when
returning the EE cert for EE acceptance. The UA
should not assume presence of any particular
certs, including the CA cert or any superior
certs in the domain's trust network, in the 
message field in discussion. Futhermore, any
certs that are sent are in bag order.

(2) According to CMP designers, the UA does not
need to verify the signature of the 
EE certificate upon initial receipt (which
in many enrollment circumstances will constitute the
moment of making an acceptance determination.) Such
UA does not therefore need any certificate
paths or CRLs ( or othe status source) at that 
point in time.

(3) CMP's CRL retrieval service is not meant
to be a PKIX operational protocol. It is not
clear if a conforming CMP implementation and CA
will provide this facility.

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 4:40 PM
To: 'Peter Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?


Hi Peter, 

"Registering user agents" should not make any assumptions as to the contents
of the various cert bags in use today.  A CA (or RA) may choose to include
what it beleives to be a set useful certificates that the client will need
to perform proper chain validation.  In some cases, such as CMS, CRL's may
also be conveyed. 

However the CA or RA makes no assersitions as to the reliability/validity of
these objects.  From what I understand of the classic X.509 model, it is
always up to the client to determine the validity certs.   A client may
choose to utilize the certs provided in these cert bags, however it may also
decide to drop them on the floor and use other methods for cert (and crl)
discovery such as LDAP and other methods of certificate validation such as
OCSP.  I would guess that the pki policy under which these clients operate
would influence these kind of decisions....

Alex

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 12:12 PM
To: 'Alex Deacon'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?


Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?


Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?


Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?



I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[e-mail]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?


If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28841 for <[e-mail]>; Thu, 20 Apr 2000 19:56:39 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <JCS1AAVP>; Thu, 20 Apr 2000 19:57:31 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: What is the order of certificates in a certificate chain?
Date: Thu, 20 Apr 2000 19:57:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

Hi David:

Consider the following reasoning:-

A CA, in the PKIX model, may be accredited - something
that is signaled via the issuance of a cross-certificate
or similar.

If a (trusted) CA quotes such a cross-certificate during
certificate application procedures, it is
essentially representing the validity of the underlying
accreditation. A CA which quoted a revoked
accreditation cross-certificate would
be likely acting in a manner which is a mis-representation
of fact, surely.

If a building contractor came to your house,
presented an official and legally-recognised
paper license to do electrical work, and you subsequently 
determine that the license had been revoked in
the license registry prior to presentation of the
paper during contract negotiation, would you not feel a 
simple mis-representation had occured?

Could a regulator not punish that contractor for
not suspending licensed work - and/or falsely
imputing a licensed standing?

I would think that a best practices Internet CA has 
a simple professional if not a legal duty to ensure that
it does not provide false information to a subscriber 
during CMP; especially information that might prejudice 
the determination of that subscriber when establishing 
the initial accuracy of a certificate that will bind 
him/her at NR grade of proof - following formal 
acceptance of that certificate.

----

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Thursday, April 20, 2000 8:32 AM
To: [e-mail]
Subject: RE: What is the order of certificates in a certificate chain?



> From: Peter Williams <[e-mail]>
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?


Surely, one is not.  The bag-o'-certs is *nothing* more than a
pile of information that may save the subscriber the effort of
looking them up in a directory or elsewhere.  It is entirely
up to the subscriber to choose a trust anchor and validate all
certs from that anchor.  If one or more provided certs cannot
be so validated, I don't see how they can be regarded as
"introduced" or "considered reliable by a TTP-grade CA".

What, precisely, is a subscriber supposed to do with intermediate
(non-self-signed) certificates which have been "introduced" by a CA?

Dave


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 LAA06329 for <[e-mail]>; Thu, 20 Apr 2000 11:31:15 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA12974 for <[e-mail]>; Thu, 20 Apr 2000 14:33:17 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 20 Apr 2000 14:34:38 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Missing Protocol ?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 7uCdwWMBViBl6dXsVZ1aXw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Denis,

If the information is NOT in a public key certificate, and the
information IS to be provided electronically instead of using methods
from the 60's, then the question is how to provide it.

I'm with Bob and Peter: the directory is the answer and no new
protocol is needed.  If there are attributes defined for passport
number/validity, bank account number, optically-scanned document, etc,
then those attributes can be stored in the directory either in unsigned
normal form or in signed attribute certificates.

No matter how new attribute certificates are, they are more mature than
this undefined 'missing protocol'.  It would be most productive to use
ACs and/or directories as is, and focus energy on establishing the catalog
of attribute definitions.

Dave



> From: Denis Pinkas <[e-mail]>
>
> Attribute Certificates are quite new and new [not] frequently used (if
> used). As stated above, the problem does not directly relate to
> Attribute Certificates.
> 
> > - There are methods/protocols to "publish" certificates, or to give
> >   controlled and secured access to them.
> 
> Yes, but the information that is needed is NOT in the certificate.
> 
> > > As a bottom line: if a protocol is not going to be used frequently, and we
> > > can get by without it for occasional need, do we need the protocol at all?
> 
> When we will have a significant deployment of a world-wide PKI, this
> protocol will be more and more useful/needed. We are trying to
> anticipate the needs.
> 
> Regards,
> 
> Denis
>  
> > I think we don't need a new one.
> > 
> > Peter





Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04901 for <[e-mail]>; Thu, 20 Apr 2000 09:40:55 -0700 (PDT)
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 SAA20070; Thu, 20 Apr 2000 18:44:56 +0200
Message-ID: <[e-mail]>
Date: Thu, 20 Apr 2000 18:44:58 +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]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Missing Protocol ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael and Peter,

I use this E-mail to comment on your answers.

> > I am not sure that the problem the proposed protocol is addressing is the
> > real problem.
> 
> I realised that Denis and I had been talking about two different things.
> So be it.
> 
> It seems that the interest it to 'publish' some attributes that are
> kept by the RA/CA....

Correct.

> > I do not think that the protocol will be something of a frequent use: If an
> > entity can not be uniquely and unambiguously identified without some extra
> > 'with-the-beard' information, that information should be present in the
> > entity's certificate. 

Two arguments: 
1) The European Directive explicitly allows for the use of a
pseudonym. 
2) There is no requirement at all that the information that is
present in the certificate allows to identify unambiguously the
person.

> > You do not want to reach out and ask an RA for extra
> > details about the entity every time you deal with that entity. It is just
> > going to be a pain. Therefore, I do not think we have a real requirement
> > here. Passing it over to the "unique ID" thread :)
> 
> ... a passport number, its validity date, my bank account number, etc. are
> not necessarily available in the ID cert, but they can be made available
> in one or more attribute certs, for example.
> 
> I had in mind a completely unstructured set of scanned copies of
> paper documents, 

Yes, this is a good example.

> but even that could be encapsulated in an attribute cert.

I do not think so. None of that information needs to be in an
Attribute Certificate. That information is useful for Public Key
certificates and does not relate to Attribute Certificates.

> > I am not convinced that the protocol is necessary for infrequent use either:
> > When a judge or police, or anybody else needs more information about the
> > entity, an RA can be contacted directly. You do not really need a protocol.
> 'contact directly' means what? ...
> 
> > A judge, police etc can do it by phone, by fax, by email or by face to face.
> > As they do it now, conveniently and simple enough.

Everything can be done slowly by the communication means from the
60's. :-) We are trying to use faster techniques for the millenium.
:-)

> This is the bottom line of the question. To replace existing methods, for example:
> 
> - An RA can always issue an attribute cert for all the attributes that they
>   store, be it just as a convenient way to fix the content of its user data base,
>   or be it to inform the user about what has been stored about him.

Attribute Certificates are quite new and new frequently used (if
used). As stated above, the problem does not directly relate to
Attribute Certificates.

> - There are methods/protocols to "publish" certificates, or to give
>   controlled and secured access to them.

Yes, but the information that is needed is NOT in the certificate.

> > As a bottom line: if a protocol is not going to be used frequently, and we
> > can get by without it for occasional need, do we need the protocol at all?

When we will have a significant deployment of a world-wide PKI, this
protocol will be more and more useful/needed. We are trying to
anticipate the needs.

Regards,

Denis
 
> I think we don't need a new one.
> 
> Peter
>


Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03768 for <[e-mail]>; Thu, 20 Apr 2000 08:37:44 -0700 (PDT)
Received: (from godslord@localhost) by venus.initech.com (8.9.3/8.9.3) id AAA22550 for [e-mail]; Fri, 21 Apr 2000 00:40:22 +0900 (KST)
Date: Fri, 21 Apr 2000 00:40:22 +0900
From: "Kwon, YongChul" <[e-mail]>
To: [e-mail]
Subject: Re: about Basic constraints
Message-ID: <[e-mail]>
References: <000d01bfaad6$d1e17440$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <000d01bfaad6$d1e17440$[e-mail]>; from [e-mail]
Organization: Initech, Inc

Sorry, I found what I want in RFC-2459 and its son. :-)



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 IAA03488 for <[e-mail]>; Thu, 20 Apr 2000 08:28:33 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA00851 for <[e-mail]>; Thu, 20 Apr 2000 11:30:35 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 20 Apr 2000 11:31:57 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: qxX23CU7+wX1zAuK2pSJZw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Peter Williams <[e-mail]>
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?


Surely, one is not.  The bag-o'-certs is *nothing* more than a
pile of information that may save the subscriber the effort of
looking them up in a directory or elsewhere.  It is entirely
up to the subscriber to choose a trust anchor and validate all
certs from that anchor.  If one or more provided certs cannot
be so validated, I don't see how they can be regarded as
"introduced" or "considered reliable by a TTP-grade CA".

What, precisely, is a subscriber supposed to do with intermediate
(non-self-signed) certificates which have been "introduced" by a CA?

Dave



Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02640 for <[e-mail]>; Thu, 20 Apr 2000 07:43:03 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id XAA22341 for <[e-mail]>; Thu, 20 Apr 2000 23:45:40 +0900 (KST)
Reply-To: <[e-mail]>
From: "Kwon, YongChul" <[e-mail]>
To: <[e-mail]>
Subject: about Basic constraints
Date: Thu, 20 Apr 2000 23:43:40 +0900
Message-ID: <000d01bfaad6$d1e17440$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id HAA02642

I'm afraid of asking this so-old question, but it's really confusing. :-(

Let's assume some scinario

CA A certificate contains basic constraints of pathlen 1.
CA B have a certificate issued by CA A and it contains no basic 
constraints. If basic constraints doesn't appear, It can issue CA
certificates which can be used to signing CA certificate(able 
to sign CA certificate) again and again.

Then I have a question, in a certain certificate validation chain
basic constraints of sub CA just overide the parent's?

Thanks a lot.

---------------
Kwon, YongChul([e-mail])
Institute of Researching Security Technology 
    of  Initiative Technology, Inc.


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 DAA28576 for <[e-mail]>; Thu, 20 Apr 2000 03:47:31 -0700 (PDT)
From: [e-mail]
Received: from joshua.isode.com by woozle.isode.com (local) with ESMTP; Thu, 20 Apr 2000 11:50:53 +0100
X-Mailer: exmh version 2.0.3
To: [e-mail]
cc: [e-mail]
Subject: Re: processing Name in certificate 
In-reply-to: Your message of "Thu, 20 Apr 2000 17:48:05 +0900." <000601bfaaa5$25a10aa0$[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Apr 2000 11:49:38 +0100
Message-ID: <[e-mail]>

"Kwon, YongChul" writes:
>When converting Name(DN) in certificate to LDAP DN,
>
>What is the order of Name?

It's easy to see why you're confused, and you're certainly not alone
on this, as there are differing external orders of representation of
DNs around.

However, you need to know that the sequence of RDNs in the
certificate's ASN.1 encoding of Name is unambiguous; the Name
represents a path through a (putative) hierarchy, with the first
member of the sequence is the most significant, and the last the least
significant.

X.509 Certificates are defined (surprise!) by the X.509 standard,
which does not explicitly spell out the order, because it is defined
in X.501, referenced as normative by X.509, and hence further
definition would be redundant in X.509.  Since RFC 2459 (and other
profiles issued by the PKIX group) profiles the use of X.509
certificates, the X.501 definition applies there too in the absence of
any statement to the contrary.

Given that this internal ordering is well-defined, the issue becomes
one of external presentation and ensuring that whatever ordering you
use is mapped correctly onto the internal ASN.1 encoded order.

An LDAP DN string, defined by RFC 1779, is encoded in the reverse
order (least significant first), and passes across the LDAP protocol
in this order UNLESS it has been encoded in a certificate or some
similar object whose value is an binary ASN.1 encoding of a DN.


>if Name in certificate stored in order likes "C L ST O OU ...",
>
>Should it be converted in LDAP DN likes "...OU O ST L C"?

Yes.

>or just same order in RDN sequence?

No.

>or It's free for implementer?( I really don't want that. :-( )

No, it's well-defined.  Just confusing.

David.

[e-mail]











Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22241 for <[e-mail]>; Thu, 20 Apr 2000 01:47:30 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id RAA17926 for <[e-mail]>; Thu, 20 Apr 2000 17:50:05 +0900 (KST)
Reply-To: <[e-mail]>
From: "Kwon, YongChul" <[e-mail]>
To: <[e-mail]>
Subject: processing Name in certificate
Date: Thu, 20 Apr 2000 17:48:05 +0900
Message-ID: <000601bfaaa5$25a10aa0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id BAA22243

When converting Name(DN) in certificate to LDAP DN,

What is the order of Name?

if Name in certificate stored in order likes "C L ST O OU ...",

Should it be converted in LDAP DN likes "...OU O ST L C"?

or just same order in RDN sequence?

or It's free for implementer?( I really don't want that. :-( )

Thanks a lot!

---------------
Kwon, YongChul([e-mail])
Institute of Researching Security Technology 
    of  Initiative Technology, Inc.


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19179 for <[e-mail]>; Thu, 20 Apr 2000 01:07:40 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA21626; Thu, 20 Apr 2000 10:11:50 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 20 Apr 2000 10:11: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 KAA22396; Thu, 20 Apr 2000 10:11:49 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA11141; Thu, 20 Apr 2000 10:11:49 +0200 (MET DST)
Date: Thu, 20 Apr 2000 10:11:49 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Missing Protocol ?
Cc: [e-mail], [e-mail]

> I am not sure that the problem the proposed protocol is addressing is the
> real problem.

I realised that Denis and I had been talking about two different things. 
So be it. 

It seems that the interest it to 'publish' some attributes that are
kept by the RA/CA....

> 
> I do not think that the protocol will be something of a frequent use: If an
> entity can not be uniquely and unambiguously identified without some extra
> 'with-the-beard' information, that information should be present in the
> entity's certificate. You do not want to reach out and ask an RA for extra
> details about the entity every time you deal with that entity. It is just
> going to be a pain. Therefore, I do not think we have a real requirement
> here. Passing it over to the "unique ID" thread :)

... a passport number, its validity date, my bank account number, etc. are
not necessarily available in the ID cert, but they can be made available
in one or more attribute certs, for example. 

I had in mind a completely unstructured set of scanned copies of
paper documents, but even that could be encapsulated in an attribute cert.
 
 
> I am not convinced that the protocol is necessary for infrequent use either:
> When a judge or police, or anybody else needs more information about the
> entity, an RA can be contacted directly. You do not really need a protocol.
'contact directly' means what? ...

> A judge, police etc can do it by phone, by fax, by email or by face to face.
> As they do it now, conveniently and simple enough. 

This is the bottom line of the question. To replace existing methods, for example:

- An RA can always issue an attribute cert for all the attributes that they
  store, be it just as a convenient way to fix the content of its user data base,
  or be it to inform the user about what has been stored about him.

- There are methods/protocols to "publish" certificates, or to give
  controlled and secured access to them.

> 
> As a bottom line: if a protocol is not going to be used frequently, and we
> can get by without it for occasional need, do we need the protocol at all?

I think we don't need a new one. 

Peter
 


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 SAA20812 for <[e-mail]>; Wed, 19 Apr 2000 18:49:31 -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 LAA14607; Thu, 20 Apr 2000 11:58:29 +1000
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <J2V56JK6>; Thu, 20 Apr 2000 11:53:11 +1000
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], xme <[e-mail]>
Subject: RE: Missing Protocol ?
Date: Thu, 20 Apr 2000 11:53:09 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I am not sure that the problem the proposed protocol is addressing is the
real problem.

I do not think that the protocol will be something of a frequent use: If an
entity can not be uniquely and unambiguously identified without some extra
'with-the-beard' information, that information should be present in the
entity's certificate. You do not want to reach out and ask an RA for extra
details about the entity every time you deal with that entity. It is just
going to be a pain. Therefore, I do not think we have a real requirement
here. Passing it over to the "unique ID" thread :)

I am not convinced that the protocol is necessary for infrequent use either:
When a judge or police, or anybody else needs more information about the
entity, an RA can be contacted directly. You do not really need a protocol.
A judge, police etc can do it by phone, by fax, by email or by face to face.
As they do it now, conveniently and simple enough. 

As a bottom line: if a protocol is not going to be used frequently, and we
can get by without it for occasional need, do we need the protocol at all?

Regards
Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 19, 2000 11:15 PM
> To: Peter Sylvester
> Cc: [e-mail]
> Subject: Re: Missing Protocol ?
> 
> 
> Peter,
> 
> <snip>
> 
> > - NOTHING is added to the protocol.
> >   The request is 'validate public key certificate':
> >  'Tell me why you think this cert is good'.
> 
> This NOT the question. 
> 
> >   Please explain why you think you ask for something else?
> 
> You give a certificate reference and you would ONLY like to know
> some (or all) the registration information that was provided at the
> time of registration.
> 
> <snip>
> 
> > Are you asking for a service that send the document or the 
> signatures
> > to a server, and depending on the signature, the server returns
> > some information about it:
> > 
> > "Please tell me what you think about these signature and provide as
> >  much information as you may want to give me."
> 
> No. See the question above.
> 
> > I can't resist: 'vsd' in dvcs is one vehicle to ask this question.
> 
> I can't resist either: DVCS is NOT the right vehicule for this.
> 
> Regards,
> 
> Denis
> 


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11327 for <[e-mail]>; Wed, 19 Apr 2000 16:44:17 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id QAA02678; Wed, 19 Apr 2000 16:40:36 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <2XT0J4GW>; Wed, 19 Apr 2000 16:39:44 -0700
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'Peter Williams'" <[e-mail]>, PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:39:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Peter, 

"Registering user agents" should not make any assumptions as to the contents
of the various cert bags in use today.  A CA (or RA) may choose to include
what it beleives to be a set useful certificates that the client will need
to perform proper chain validation.  In some cases, such as CMS, CRL's may
also be conveyed. 

However the CA or RA makes no assersitions as to the reliability/validity of
these objects.  From what I understand of the classic X.509 model, it is
always up to the client to determine the validity certs.   A client may
choose to utilize the certs provided in these cert bags, however it may also
decide to drop them on the floor and use other methods for cert (and crl)
discovery such as LDAP and other methods of certificate validation such as
OCSP.  I would guess that the pki policy under which these clients operate
would influence these kind of decisions....

Alex

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 12:12 PM
To: 'Alex Deacon'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?


Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?


Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?


Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?



I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[e-mail]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?


If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11053 for <[e-mail]>; Wed, 19 Apr 2000 16:34:37 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <JCSD07FN>; Wed, 19 Apr 2000 16:35:27 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>, "'Alex Deacon'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:35:20 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

Hi Carlisle:

Its always fun to consider the interaction of technical
specification, the role of technical compliance, and the 
policy rules which govern how technology operations
MUST function. Let us address this topic a little more
for the case of validating EE certificates during certificate
acceptance.

One of the things that many reference CPSs require, and Santosh'
and Warwick's (http://www.ietf.org/rfc/rfc2527.txt 4.4) work on CPS 
disclosures highlights,is the notion of "certificate acceptance" by 
subscribers. 

Acceptance is the point where the good work of the CA 
(via CMP or PKCS or Cisco's protocols) in registering and certifying 
public keys (and other data) is checked by the subscriber. This is done
normally PRIOR to publication of the certificatein a repository that then
perform the initial and then ongoing certificate 
management.  Various legal obligations may be passed at the moment 
of acceptance; it is an important step in the legal protocol. Generally, one
 is not authorized to use or rely on the certificate as a 
subscriber - until one has accepted it. 

Certificate acceptance is *specifically* relevant to 
the protocol message under discussion, I would suggest; it is 
the generalization of what CMP is enforcing when the
EE UA accepts/processes the cert response msg. The content
of that response is the specfiic question.

The rules for acceptance of the EE cert are policy-based, of course.

https://www.verisign.com/repository/CPS1.2/CPSCH7.HTM#_toc361807047
specifies one such policy rule system, into which a particular 
configuration of CMP would presumbably have to fit. It is not CMP
that drives policy design; policy drives how CMP is used
to satisfy the technology-independent/protocol-independent
policy rules.

In general, "reasonable acceptance" require a susbcriber validate 
the certificate upon initial receipt - after all, its
signature may fail verification, or the data contained
within may be erroneous, or, you just change your
mind about binding yourself to the CA's legal agreement.
In policy-cases such as VeriSign, furthermore, **only
upon** acceptance may the next phase of CMP go ahead
wherein the certificate is published to the primary
and official respository by the CA's CMP instance.

Now, my claim is, surely with very significant
relevance, that the only way to validate an EE cert 
at the moment of acceptance, is to traverse some trust 
chain upto a trust-anchor.

If I understand CMP and the conversation here,
it is understood that the pubKeys data element will
communicate those certified keys that the EE needs to validate
its own key, during acceptance and/or at later
points of time.

>From you mail, it is now implied that the same
EE UA may be required - at the point of acceptance
(namely processing the CMP Response) - 
to obtain CRLs from one or more CAs via CMP, so that
it can indeed validate the certificate it
has just been sent for acceptance, and
(as necessary) confirm the supporting
cerificate chain as required by such
as VeriSign's policy.

https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM#_toc361807054
(see 8.2 for discussion of confirmation, and validation)

At this point, we have one further
techno/policy question. In supplying the
certs necessary for EE cert validation at
the point of acceptance, whose nature largely
**determines** the outcome of acceptance,
what liability does the CA have for
inducing that outcome?... particularly
if it supplies compromised CA certs 
which are revoked or no longer
in good standing in an accreditation
registry?

Peter.

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 1:17 PM
To: 'Alex Deacon'; 'Peter Williams'
Cc: PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?


Hi Peter,

Good to hear from you again!

I apologize in advance if I appear unsympathetic to your line of
questioning, but I'm afraid it seems a little bit irrelevant to me.  In most
environments, prudence dictates that you check the validity of a certificate
just prior to using it (i.e., relying upon it), not upon first receipt of
it.  Therefore, in your emphatically fictitious example (!), even if
Verisign wished to attest to the reliability (in some sense) of the supplied
cert path, who is to say that this path is still reliable 10 minutes later
when the newly-initialized EE wants to perform some other action?  (A new
CRL might have been published by then listing one or more of these certs as
revoked, or the relevant OCSP responder might give a negative answer due to
a notification of key compromise.)

I can't think of any way in the spec. for the CA to perform "an
authoritative, legal introduction to the entites bound to the public keys",
as you put it.  Nor do I really think there should be.  The purpose of the
supplied bag of certs is to provide helpful information to the EE (e.g.,
"here are the CAs between you and the trust anchor", or "here are the keys
of some other entities that may be useful" (such as a time stamp server, or
an OCSP responder, or whatever)).  When the EE needs to rely on these keys,
it should get the relevant CRLs/ARLs, or contact the relevant responder,
etc., just as it would for any other certs.

Note that CMP does define a CRL request message and a CRL announcement
message that may be used for EE discovery of revocation information, but not
much explanation or detail is given on these messages.  This is primarily
because such functions are more properly the domain of the PKIX operational
protocols, which are specified separately.

Carlisle.


> ----------
> From: 	Peter Williams[SMTP:[e-mail]]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> Some issues:
> 
> Should implementors assume that there are "any
> particular certificates in the caPubs field" - or should
> one assume it may be a "random" bag of any certs
> the CA chooses to send?
> 
> As far as the normative CMP spec is concerned, a registering 
> UA can make no assumption as to the certs that a CA
> populated in caPubs. One cannot build
> a "conforming UA" to expect "a subscriber's 'cert path' up
> a trust hierarchy" for example - as neither all 
> CMP conforming implementations nor
> the Certification domains to which the CMP module provides
> service may provide this optional, highly policy-specific 
> construct.
> 
> Now, consider the other side of the coin.  Assume
> a CA's configuration of a CMP implementation chooses to
> send a given set of certificates - out of which one can form 
> a "trust path",  where the CA's policy defines what a "path" 
> is for use in policy-compliant "certificate validation".
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?
> 
> 
> Scenario:
> 
> Lets take a scenario, mostly real - which flexes
> the 2459 and CMP model according to these issue
> to see if it all really works when we get out of the 
> realm of paper architectures:
> 
> I enroll for a VeriSign class 1 cert as a subcriber,
> for the (fictional?) "US govt interoperable" type of 
> key certification service.
> 
> Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
> 1000 other (otherwise) equivalent providers of certs - is because 
> US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
> (FICTIONALLY) recognises Class 3 organizational certs for ... some
> important,
> high-value G2B application.
> 
> Now I assume that a VeriSign-policy specific CMP registration response
> would send me, in bag order, at least the various
> non-PCA intermediate CA certs from VeriSign's trust hierachy,
> plus the cross-certificate issued by US gov to
> the VeriSign Class 3 PCA. After all, this is what I really
> need.
> 
> If VeriSign does send me such an authoritative cross-certificate, can I 
> assume its (a) valid and (b) the recognition (accreditation)
> status of VeriSign Class 3 PCA domain, before US govt, is
> in good standing at that moment? 
> 
> Do I need to check revocation status of the cert before making
> such a judgement, in counterpoint?
> 
> Similarly, if VeriSign (my choice of TTP provider) sends me a 
> subordinate CA certificate that corresponds to a non-VeriSign 
> operator (British Telecommunications, say) is that an implied
> representation that the operator is in current compliance with 
> VeriSign's CPS/policy, and I can rely upon that implicit signal?
> 
> 
> Summary of questions:
> 
> Surely, to summarize, 
> 
> (A) A TTP-grade CA would only send a 
> critically-important certificate that is "reliable" - characteried 
> by actual and current compliance with policy, accreditation, and similar
>  programs that denote an operators trust standing in the eyes of auditors
> and similar independents?
> 
> (B) To check such certificates for reliablity, would one
> need access to the various CRLs, or similar status
> sources. Should CMP be supplying these, too? Or, do
> we assume the registering UA will do a (not CMP-specified)
> action to collect and process those CRLs before completing
> the registration process, and formally "accepting" the supplied
> subscriber (EE) certificate and the ancillary caPubs or
> other similar information needed to validate that certificate?
> 
> Peter.
> 
> -----Original Message-----
> From: Alex Deacon [mailto:[e-mail]]
> Sent: Wednesday, April 19, 2000 11:05 AM
> To: 'Christopher Williams'; PKIX Mailing List
> Subject: RE: What is the order of certificates in a certificate chain?
> 
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> -----Original Message-----
> From: Christopher Williams [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.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 NAA08514 for <[e-mail]>; Wed, 19 Apr 2000 13:13:27 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <20Y5DDA8>; Wed, 19 Apr 2000 16:17:11 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Alex Deacon'" <[e-mail]>, "'Peter Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 16:17:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Peter,

Good to hear from you again!

I apologize in advance if I appear unsympathetic to your line of
questioning, but I'm afraid it seems a little bit irrelevant to me.  In most
environments, prudence dictates that you check the validity of a certificate
just prior to using it (i.e., relying upon it), not upon first receipt of
it.  Therefore, in your emphatically fictitious example (!), even if
Verisign wished to attest to the reliability (in some sense) of the supplied
cert path, who is to say that this path is still reliable 10 minutes later
when the newly-initialized EE wants to perform some other action?  (A new
CRL might have been published by then listing one or more of these certs as
revoked, or the relevant OCSP responder might give a negative answer due to
a notification of key compromise.)

I can't think of any way in the spec. for the CA to perform "an
authoritative, legal introduction to the entites bound to the public keys",
as you put it.  Nor do I really think there should be.  The purpose of the
supplied bag of certs is to provide helpful information to the EE (e.g.,
"here are the CAs between you and the trust anchor", or "here are the keys
of some other entities that may be useful" (such as a time stamp server, or
an OCSP responder, or whatever)).  When the EE needs to rely on these keys,
it should get the relevant CRLs/ARLs, or contact the relevant responder,
etc., just as it would for any other certs.

Note that CMP does define a CRL request message and a CRL announcement
message that may be used for EE discovery of revocation information, but not
much explanation or detail is given on these messages.  This is primarily
because such functions are more properly the domain of the PKIX operational
protocols, which are specified separately.

Carlisle.


> ----------
> From: 	Peter Williams[SMTP:[e-mail]]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> Some issues:
> 
> Should implementors assume that there are "any
> particular certificates in the caPubs field" - or should
> one assume it may be a "random" bag of any certs
> the CA chooses to send?
> 
> As far as the normative CMP spec is concerned, a registering 
> UA can make no assumption as to the certs that a CA
> populated in caPubs. One cannot build
> a "conforming UA" to expect "a subscriber's 'cert path' up
> a trust hierarchy" for example - as neither all 
> CMP conforming implementations nor
> the Certification domains to which the CMP module provides
> service may provide this optional, highly policy-specific 
> construct.
> 
> Now, consider the other side of the coin.  Assume
> a CA's configuration of a CMP implementation chooses to
> send a given set of certificates - out of which one can form 
> a "trust path",  where the CA's policy defines what a "path" 
> is for use in policy-compliant "certificate validation".
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?
> 
> 
> Scenario:
> 
> Lets take a scenario, mostly real - which flexes
> the 2459 and CMP model according to these issue
> to see if it all really works when we get out of the 
> realm of paper architectures:
> 
> I enroll for a VeriSign class 1 cert as a subcriber,
> for the (fictional?) "US govt interoperable" type of 
> key certification service.
> 
> Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
> 1000 other (otherwise) equivalent providers of certs - is because 
> US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
> (FICTIONALLY) recognises Class 3 organizational certs for ... some
> important,
> high-value G2B application.
> 
> Now I assume that a VeriSign-policy specific CMP registration response
> would send me, in bag order, at least the various
> non-PCA intermediate CA certs from VeriSign's trust hierachy,
> plus the cross-certificate issued by US gov to
> the VeriSign Class 3 PCA. After all, this is what I really
> need.
> 
> If VeriSign does send me such an authoritative cross-certificate, can I 
> assume its (a) valid and (b) the recognition (accreditation)
> status of VeriSign Class 3 PCA domain, before US govt, is
> in good standing at that moment? 
> 
> Do I need to check revocation status of the cert before making
> such a judgement, in counterpoint?
> 
> Similarly, if VeriSign (my choice of TTP provider) sends me a 
> subordinate CA certificate that corresponds to a non-VeriSign 
> operator (British Telecommunications, say) is that an implied
> representation that the operator is in current compliance with 
> VeriSign's CPS/policy, and I can rely upon that implicit signal?
> 
> 
> Summary of questions:
> 
> Surely, to summarize, 
> 
> (A) A TTP-grade CA would only send a 
> critically-important certificate that is "reliable" - characteried 
> by actual and current compliance with policy, accreditation, and similar
>  programs that denote an operators trust standing in the eyes of auditors
> and similar independents?
> 
> (B) To check such certificates for reliablity, would one
> need access to the various CRLs, or similar status
> sources. Should CMP be supplying these, too? Or, do
> we assume the registering UA will do a (not CMP-specified)
> action to collect and process those CRLs before completing
> the registration process, and formally "accepting" the supplied
> subscriber (EE) certificate and the ancillary caPubs or
> other similar information needed to validate that certificate?
> 
> Peter.
> 
> -----Original Message-----
> From: Alex Deacon [mailto:[e-mail]]
> Sent: Wednesday, April 19, 2000 11:05 AM
> To: 'Christopher Williams'; PKIX Mailing List
> Subject: RE: What is the order of certificates in a certificate chain?
> 
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> -----Original Message-----
> From: Christopher Williams [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07497 for <[e-mail]>; Wed, 19 Apr 2000 12:11:32 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <JCSD0553>; Wed, 19 Apr 2000 12:12:22 -0700
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Alex Deacon'" <[e-mail]>, PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 12:12:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"

Alex,

Some issues:

Should implementors assume that there are "any
particular certificates in the caPubs field" - or should
one assume it may be a "random" bag of any certs
the CA chooses to send?

As far as the normative CMP spec is concerned, a registering 
UA can make no assumption as to the certs that a CA
populated in caPubs. One cannot build
a "conforming UA" to expect "a subscriber's 'cert path' up
a trust hierarchy" for example - as neither all 
CMP conforming implementations nor
the Certification domains to which the CMP module provides
service may provide this optional, highly policy-specific 
construct.

Now, consider the other side of the coin.  Assume
a CA's configuration of a CMP implementation chooses to
send a given set of certificates - out of which one can form 
a "trust path",  where the CA's policy defines what a "path" 
is for use in policy-compliant "certificate validation".

Does a CA who sends such certificates to a user
bear responsibility for the current, individual reliability
of any certificate is sends? I.e.
can one assume that the subscriber's CA has just checked the 
certs' non-revoked status, or the provider's contiuing
accreditation certificate status, under the CA domain's or 
another regulators governing policy, prior to inducing others 
to use or rely on those certificates.

Surely, by virtue of supplying CA certifificates to a subscriber
at such a critical juncture one is performing an authoritative,
legal introduction to the entites bound to the public keys?


Scenario:

Lets take a scenario, mostly real - which flexes
the 2459 and CMP model according to these issue
to see if it all really works when we get out of the 
realm of paper architectures:

I enroll for a VeriSign class 1 cert as a subcriber,
for the (fictional?) "US govt interoperable" type of 
key certification service.

Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
1000 other (otherwise) equivalent providers of certs - is because 
US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
(FICTIONALLY) recognises Class 3 organizational certs for ... some
important,
high-value G2B application.

Now I assume that a VeriSign-policy specific CMP registration response
would send me, in bag order, at least the various
non-PCA intermediate CA certs from VeriSign's trust hierachy,
plus the cross-certificate issued by US gov to
the VeriSign Class 3 PCA. After all, this is what I really
need.

If VeriSign does send me such an authoritative cross-certificate, can I 
assume its (a) valid and (b) the recognition (accreditation)
status of VeriSign Class 3 PCA domain, before US govt, is
in good standing at that moment? 

Do I need to check revocation status of the cert before making
such a judgement, in counterpoint?

Similarly, if VeriSign (my choice of TTP provider) sends me a 
subordinate CA certificate that corresponds to a non-VeriSign 
operator (British Telecommunications, say) is that an implied
representation that the operator is in current compliance with 
VeriSign's CPS/policy, and I can rely upon that implicit signal?


Summary of questions:

Surely, to summarize, 

(A) A TTP-grade CA would only send a 
critically-important certificate that is "reliable" - characteried 
by actual and current compliance with policy, accreditation, and similar
 programs that denote an operators trust standing in the eyes of auditors
and similar independents?

(B) To check such certificates for reliablity, would one
need access to the various CRLs, or similar status
sources. Should CMP be supplying these, too? Or, do
we assume the registering UA will do a (not CMP-specified)
action to collect and process those CRLs before completing
the registration process, and formally "accepting" the supplied
subscriber (EE) certificate and the ancillary caPubs or
other similar information needed to validate that certificate?

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[e-mail]]
Sent: Wednesday, April 19, 2000 11:05 AM
To: 'Christopher Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?



I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[e-mail]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?


If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.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 LAA06850 for <[e-mail]>; Wed, 19 Apr 2000 11:38:17 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <20Y5DBWJ>; Wed, 19 Apr 2000 14:42:00 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>, "'Alex Deacon'" <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 14:40:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

Alex is right:  no order should be assumed.  See, for example, the note
explicitly stating this in the last sentence of Section 3.1.  This lack of
constraint on cert order should be assumed to apply in all similar fields
(e.g., caPubs).  I guess I didn't think this needed to be repeated
throughout the document because people would already be familiar with this
practice from S/MIME (CMS) and elsewhere.

Carlisle.


> ----------
> From: 	Alex Deacon[SMTP:[e-mail]]
> Sent: 	Wednesday, April 19, 2000 2:05 PM
> To: 	'Christopher Williams'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> -----Original Message-----
> From: Christopher Williams [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
> 


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06117 for <[e-mail]>; Wed, 19 Apr 2000 11:02:07 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA18347; Wed, 19 Apr 2000 11:06:10 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <2XT0JQ7L>; Wed, 19 Apr 2000 11:05:18 -0700
Message-ID: <[e-mail]>
From: Alex Deacon <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>, PKIX Mailing List <[e-mail]>
Subject: RE: What is the order of certificates in a certificate chain?
Date: Wed, 19 Apr 2000 11:05:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

I dont think any order should be assumed.  Your code should handle cert
chains included in a registration response message a "bag of certs".
Making assumptions as to the order of certs in structures designed to hold
cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is probably
a bad idea and will only cause interop problems down the line.

Alex

-----Original Message-----
From: Christopher Williams [mailto:[e-mail]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?


If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01608 for <[e-mail]>; Wed, 19 Apr 2000 06:11:14 -0700 (PDT)
Received: from bull.net (itinerant6.frpq.bull.fr [129.184.8.53]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA35224; Wed, 19 Apr 2000 15:15:15 +0200
Message-ID: <[e-mail]>
Date: Wed, 19 Apr 2000 15:15:17 +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]>
CC: [e-mail]
Subject: Re: Missing Protocol ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

<snip>

> - NOTHING is added to the protocol.
>   The request is 'validate public key certificate':
>  'Tell me why you think this cert is good'.

This NOT the question. 

>   Please explain why you think you ask for something else?

You give a certificate reference and you would ONLY like to know
some (or all) the registration information that was provided at the
time of registration.

<snip>

> Are you asking for a service that send the document or the signatures
> to a server, and depending on the signature, the server returns
> some information about it:
> 
> "Please tell me what you think about these signature and provide as
>  much information as you may want to give me."

No. See the question above.

> I can't resist: 'vsd' in dvcs is one vehicle to ask this question.

I can't resist either: DVCS is NOT the right vehicule for this.

Regards,

Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00635 for <[e-mail]>; Wed, 19 Apr 2000 05:07:31 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA04267; Wed, 19 Apr 2000 14:11:37 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 19 Apr 2000 14:11:37 +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 OAA17871; Wed, 19 Apr 2000 14:11:35 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA10764; Wed, 19 Apr 2000 14:11:35 +0200 (MET DST)
Date: Wed, 19 Apr 2000 14:11:35 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Missing Protocol ?
Cc: [e-mail]

> Bob,
> 
> I appreciate you sense of humour, at the very end of this E-mail,
> when you say: "But afer all, isn't what DIRECTORIES are for? Why do
> we need a new protocol??? The answer is LDAP.  What was the
> question??

The purpose of a directory is to provide information,
and it is explicitely tolerated that the information can be slightly
wrong and inaccurate. 

> 
> Before discussing the technical solution(s), the thread is
> discussing very validly the purpose and the goal of that (missing ?)
> protocol. Since the information that might be released will not
> match exactly with the arguments from the request (i.e. you cannot
> ask specically for an attribute) I am not convinced that LDAP would
> be the best choice. In addition, up to now, RAs do not need to
> support a Directory or structure the information they have so that
> it can be placed in a Directory.

That's not the real point: You seem to want a possibility to access
to a remote service that is akind of RA archive. The answers from this
service will be used by some RP (a juge). The answers are statements
that itsself need to be verifiable (using a signature), and re-verfiable
in case the process is reviewed. 

> 
> The other arguments you raise in your E-mail, as well as the
> examples provided by Robert Moskowitz, illustrate the topic very
> well.
> 
> Peter Sylvester while advocating for the use of DVCS was saying: "
> Since my current favorite is dvcs, I start with this: The request
> would be a for a 'verify public key certificate'. The response would
> not contain the certificate chain, or maybe it would, it can contain
> all kinds of certificates, etc, just ONE of the certEtcToken
> elements would be the signedData object created by the RA ".
> 
> The request we need has nothing to do with 'verify public key
> certificate'. DVCS is already embrassing too many purposes. It would
> not be a good idea to add one more purpose in the same shell.

- NOTHING is added to the protocol. 
  The request is 'validate public key certificate': 
 'Tell me why you think this cert is good'. 
  Please explain why you think you ask for something else?

  The distinction of what is expected to be returned and 
  what is returned is made in an application context of both
  the requester and the responder. 

- What purpose do you think is 'too much'? You can also say:
  TCP is too complicated because you can do too many things
  with it, or HTTP is too generic, you can too many things with it,
  and to many protocols are encapsulated in http, or email is
  embracing too many applications, or S/MIME is embracing too
  many features, or cmp/cmc are too big, etc.  
  The purpose of horizontal protocol layer is to become usable
  by many applications. 

> 
> Note that the request is mainly intended to be used by adjudicators
> or plaintiffs, but nothing prevents anyone to send a request.
Sometimes there are means to address denial of service attacks.

> However, a server may well refuse to provide a response. So any RP
> could make a request. It will always be up to the RA to decide
> which, if any, information will be released.
Is this different from any other cleint/server protocol that uses
some sort of authentication/authorisation mecanism? 

> 
> Let us now add a refinment about the construct of the request.
You are not going to add too many purposes I hope :-)

> Information may be released (or not) depending upon not only who the
> requestor is, but also depending upon what kind of information is
> provided. For example, if I can prove that a document was both
> signed by myself and another party, I could perhaps legitimately ask
> more information about that other party. Providing this "proof" as
> part of the (authenticated) request might be valuable. Note that
> this can be done without providing the actual content of what was
> signed, thus respecting some privacy.

Are you asking for a service that send the document or the signatures
to a server, and depending on the signature, the server returns
some information about it: 

"Please tell me what you think about these signature and provide as
 much information as you may want to give me."

I can't resist: 'vsd' in dvcs is one vehicle to ask this question.

Anyway, you are not making a refinement but asking for two
different context:

- In the first case, a judge wants to obtain from the
  RA the whole set of justifications to be used to issue a certificate.
  The RA does not make any judgement about WHY this information is
  requested, independant of the certificate usage in an actual signature.

- In the second case, the requester presents an actual usage of 
  one or more certs, i.e., a signed document. I 

Thus, you are already through 3/4 of the dvcs features to request and
obtain secrity statement about documents and certificates/assertions.
(I assume that you accept the usefulness of timestamping).

Your example is not well-chosen, I can sign all kinds of documents,
and this doesn't per-se give me the right to get information about
other entities. You might have a case on countersignatures upon
a document that you have signed first, and you want to know who
has actually 'accepted' counter-signed your data. Anyway, this
is application dependant, and not a part of the infrastructure
protocol.
 
Have fun
Peter Sylvester


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA23927 for <[e-mail]>; Wed, 19 Apr 2000 02:44:05 -0700 (PDT)
Received: from bull.net (itinerant6.frpq.bull.fr [129.184.8.53]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA16196; Wed, 19 Apr 2000 11:48:06 +0200
Message-ID: <[e-mail]>
Date: Wed, 19 Apr 2000 11:48:08 +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: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Missing Protocol ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob,

I appreciate you sense of humour, at the very end of this E-mail,
when you say: "But afer all, isn't what DIRECTORIES are for? Why do
we need a new protocol??? The answer is LDAP.  What was the
question??

Before discussing the technical solution(s), the thread is
discussing very validly the purpose and the goal of that (missing ?)
protocol. Since the information that might be released will not
match exactly with the arguments from the request (i.e. you cannot
ask specically for an attribute) I am not convinced that LDAP would
be the best choice. In addition, up to now, RAs do not need to
support a Directory or structure the information they have so that
it can be placed in a Directory.

The other arguments you raise in your E-mail, as well as the
examples provided by Robert Moskowitz, illustrate the topic very
well.

Peter Sylvester while advocating for the use of DVCS was saying: "
Since my current favorite is dvcs, I start with this: The request
would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain
all kinds of certificates, etc, just ONE of the certEtcToken
elements would be the signedData object created by the RA ".

The request we need has nothing to do with 'verify public key
certificate'. DVCS is already embrassing too many purposes. It would
not be a good idea to add one more purpose in the same shell.

Note that the request is mainly intended to be used by adjudicators
or plaintiffs, but nothing prevents anyone to send a request.
However, a server may well refuse to provide a response. So any RP
could make a request. It will always be up to the RA to decide
which, if any, information will be released.

Let us now add a refinment about the construct of the request.
Information may be released (or not) depending upon not only who the
requestor is, but also depending upon what kind of information is
provided. For example, if I can prove that a document was both
signed by myself and another party, I could perhaps legitimately ask
more information about that other party. Providing this "proof" as
part of the (authenticated) request might be valuable. Note that
this can be done without providing the actual content of what was
signed, thus respecting some privacy.
 
Regards,

Denis

 
> Tom,
> 
> You're right, the potential sticking point is the privacy issue.
> 
> But privacy comes in several flavors, and there is also some
> concern for cluttering up certificate with information that may
> not always be required.
> 
> I don't think we need to come to the complexity of a German wine
> label (auslese cabinette, green capsule, with silver stripes) to solve this.
> 
> Consider the telephone company's policy.  My number can be listed,
> unpublished, or unlisted.  If it is listed, I may or may not list an address,
> and if I do it doesn't have to be my real address -- it could be a forwarding
> service, or just a ZIP code.  (In the LA area, it costs extra to have your
> phone be unlisted, but it costs nothing to have a phony  address. So
> hundreds of people just list their names as Joe Doakes, 90210.
> 
> If my listing it is merely unpublished, you can ask for it.
> 
> If it is unlisted, only law enforcement, and maybe other emergency
> services can get it, but I don't know if it requires a warrant in that case.
> 
> Same with the Tom Smith-with-the-beard.  Tom may not choose to list his
> hirsuteness or glabrousness, but he probably would have no problem with
> telling anyone who asks.
> 
> His social security number might be a different story, but even then
> he is unlikely to defend that to the death, as too many people already
> have access to it. But he might require that such usage be audited, and
> that he have the right to know who asked for it, just as credit checks
> must be reported upon request.
> 
> If he is under the Witness Protection program, he is going to strenuously
> resist giving anyone his real name, birth date, etc.
> 
> But afer all, isn't what DIRECTORIES are for?
> 
> Why do we need a new protocol???
> 
> The answer is LDAP.  What was the question??
> 
> Bob
> 
> >>> <[e-mail]> 04/17/00 10:25AM >>>
>      Some comments.  I think we can get a lot of this into certificates or
> CMP responses, if we don't try for a "universal solution".  If liability is
> at issue, even one of the ID's should do the trick.  The only problem I see
> is a privacy problem.  If something shouldn't be in a certificate, which
> RP's should be allowed to get it?  If ordinary unprivileged RP's are
> allowed to get it, why (other than certificate lifetime considerations)
> shouldn't it be in the certificate?
> 
>           Tom Gindin
> 
> Al Arsenault <[e-mail]> on 04/17/2000 11:19:08 AM
> 
> To:   Denis Pinkas <[e-mail]>
> cc:   ietf-pkix <[e-mail]>
> Subject:  Re: Missing Protocol ?
> 
> Now that I understand better what you're getting at with this stuff  :-)
> 
> Denis Pinkas wrote:
> >
> > Since I launched this thread, I am following the various exchanges.
> > I pick this one to comment.
> >
> > > Thierry,
> > >
> > >         I'm not sure that there is a solution for this problem that
> doesn't
> > > involve knowledge external to the PKI.
> >
> > Since the knowledge is not external to PKI, the problem may be
> > considered by the PKIX WG.
> >
> > >         Suppose that the fondest dreams of the early X.500 designers
> had come
> > > true, and every item (to include person) in the known universe had a
> > > globally unique name.  Even in that case, if you are working with one
> > > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
> need
> > > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > > out-of-band what his globally-unique name is, or at least enough
> > > disambiguating information to let you accurately pick it out from the
> > > entries in the global directory.  Otherwise, you'll never know which is
> > > which.
> > >
> > >         The same type of information can be passed to you "out-of-band"
> in the
> > > current situation; when you first begin working with the right "Jim
> > > Jones of GM", he can provide you his certificate directly, or give you
> > > enough disambiguating information to make sure you find it somewhere
> > > else.  If he doesn't, you're not going to work securely.
> > >
> > >         (All of this is a long way of saying that we're really
> wandering here.
> > > I'm not convinced that it is possible to define a technical - by which
> I
> > > mean "machine-processable" - protocol that is guaranteed to find you
> the
> > > right certificate if you don't have enough information from other
> > > contexts.)
> >
> > When dealing with signatures, it is the other way around. You have a
> > certificate, that may even contain a pseudonym. When it does not
> > contain a pseudonym, the question is still: who indeed is that
> > person (e.g. Jim Jones 22) ? This person may be liable for a
> > contract worth 10.000 $ and the requester would like to get the home
> > address of the signer.
> >
> > The information that was obtained at the time of registration (and
> > that is NOT contained in the certificate) may help.
> >
> > The problem is that this registration information varies from one CA
> > to another and we are not going to standardize it easily. Is it
> > really a problem ?
> >
> > We could standardize the request and very loosely standardize the
> > response. The request is easy to standardize: "I want more
> > registration information on the certificate holder that has the
> > following serial number". Depending both, on who the requester is
> > and the certificate policy of the CA, more or less (even none)
> > information will be released to the requester. We could thus
> > standardize the response without mandating any component to be
> > returned. In any case, it would be better than paper.
> >
> > Thoughts ?
> >
> > Denis
> >
> >
> >
> 
> More "questions" than "thoughts":
> 
> 1.  Is the set of information that might reasonably be requested
> sufficiently bounded as to be specifiable in a protocol?  Off the top of
> my head, depending on the circumstances, I might ask for:
> 
>      - passport number/nationality
>      - employee ID number
>      - mail stop/address
>      - phone number
>      - driver's license number
>      - SSN/other identity number
>      - physically descriptive information (no, I'm not kidding here.  I
> used to have a roommate named Tom Smith.  He worked in an office with
> another Tom Smith.  The middle names and even the generational qualifier
> were the same.  So when you called, you asked for 'the Tom Smith with a
> beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
> The guy with the beard was threatened with mayhem if he ever shaved while
> working in that office.:-)
>      - a whole bunch of other stuff
> 
> [Tom Gindin] Most of your list, up to (not including) physically
> descriptive information, has perfectly well-defined formats in our domain
> already - and IMO we should start with those.  The ones I have been trying
> to profile for an OTHER-NAME format to go into certificates are Employee ID
> number, SSN or other nationwide government ID number, CA-assigned ID
> number, and Passport, Driver's license, or other government agency ID
> number.  Maybe we should include phone number (distinguished between work
> and home) as long as there's a separate place for extension number at work.
> How would we do mail stop/address - perhaps with an X.400 Physical Delivery
> Address?  Of course, most people have different work and home mail
> addresses too.
> 
> If this is going to be meaningful to software and hardware, we'll have to
> quantify/limit the list of acceptable information somehow.
> 
> [Tom Gindin] Yes, we need to keep the list down.  However, I don't think
> that means empty.  For the four ID types, I have only three syntaxes and
> two of them are effectively subsets of the other.
> 
> 2.  Do you envision the response being anything that a machine might
> parse and act upon, or only a general form for returning information for
> human consumption/decision?
> 
> 3.  If we can get past 1., do you picture this being a new protocol, or an
> extension to CMP/CMC?
> 
> Thanks,
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> [phone]


Received: from mail.pentasecurity.com (IDENT:root@[211.40.20.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09143 for <[e-mail]>; Tue, 18 Apr 2000 21:25:30 -0700 (PDT)
Received: from myiq98 (ns.pentasecurity.com.20.40.211.in-addr.arpa [211.40.20.130] (may be forged)) by mail.pentasecurity.com (8.9.3/8.9.3) with SMTP id NAA10530 for <[e-mail]>; Wed, 19 Apr 2000 13:40:48 +0900
From: =?ks_c_5601-1987?B?waS8urHV?= <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 19 Apr 2000 13:29:39 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
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.6700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id VAA09146

auth 99220e68 subscribe ietf-pkix \
=?ks_c_5601-1987?B?waS8urHV?= <[e-mail]>


Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04997 for <[e-mail]>; Tue, 18 Apr 2000 08:34:21 -0700 (PDT)
Received: from darxstar ([62.252.200.84]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000418153829.JDTE381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Tue, 18 Apr 2000 16:38:29 +0100
Message-ID: <003401bfa94c$827f6960$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: What is the order of certificates in a certificate chain?
Date: Tue, 18 Apr 2000 16:41:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

If, for example, a CA provides a certificate chain in an initialization
response, in which order should it add the certificates?  Its own
certificate first or root CA certificate first?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04765 for <[e-mail]>; Tue, 18 Apr 2000 08:30:39 -0700 (PDT)
Received: from darxstar ([62.252.200.84]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000418153445.JDQK381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Tue, 18 Apr 2000 16:34:45 +0100
Message-ID: <001a01bfa94b$fd07a040$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: thisMessage POP (again) - spec is contradictory
Date: Tue, 18 Apr 2000 16:36:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Sorry to bring this up again, but the spec is still muddled on this issue.

RFC2510bis, section 3.28 says:

"...proof of possession of the private decryption key may be demonstrated
   in one of three ways.

      1) By the inclusion of the private key (encrypted) in the
         CertRequest (in the PKIArchiveOptions control structure)."

This suggests that POP is implicit, because the EE is asking the CA to
archive the private key and providing the private key in an ArchiveOptions
control.  The CA can decrypt the private key in the ArchiveOptions control
and match it against the public key in the CertTemplate.

Appendix D then says:

"POPOPrivKey ::= CHOICE {
    thisMessage       [0] BIT STRING,
-- **********
-- * the type of "thisMessage" was mistakenly given as BIT STRING in
-- * RFC 2511; it should have been "EncryptedValue" (in accordance with
-- * Section 3.2.2 of this specification).  Therefore, this document makes
-- * the behavioral clarification of specifying that the contents of
-- * "thisMessage" MUST be encoded as an EncryptedValue and then wrapped
-- * in a BIT STRING.  This allows the necessary conveyance and protection
-- * of the private key while maintaining bits-on-the-wire compatibility
-- * with RFC 2511.
-- **********
    subsequentMessage [1] SubsequentMessage,
    dhMAC             [2] BIT STRING }"

These instructions are not compatible:

1. They tell you to do two different things - stick the private key in an
ArchiveOptions control OR in an EncryptedValue.
2. If the certificate request contains an ArchiveOptions control, the
contents of the thisMessage BIT STRING are redundant.

The implicit POP is somewhat more elegant.  Encoding an EncryptedValue as a
BIT STRING is a bit of a kludge.

The contradicitory instructions can be reconciled as follows:
If an ArchiveOptions control is included in the certificate request,
implicit POP MAY be indicated by setting thisMessage to an empty BIT STRING.
If thisMessage is empty, an ArchiveOptions control MUST be included in the
certificate request.

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03169 for <[e-mail]>; Tue, 18 Apr 2000 06:30:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA13988; Tue, 18 Apr 2000 15:30:49 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 18 Apr 2000 15:30:49 +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 PAA13782; Tue, 18 Apr 2000 15:30:48 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA10391; Tue, 18 Apr 2000 15:30:47 +0200 (MET DST)
Date: Tue, 18 Apr 2000 15:30:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Missing Protocol ?
Cc: [e-mail], [e-mail]

> 
>      Some comments.  I think we can get a lot of this into certificates or
> CMP responses, if we don't try for a "universal solution".  If liability is
> at issue, even one of the ID's should do the trick.  The only problem I see
> is a privacy problem.  If something shouldn't be in a certificate, which
> RP's should be allowed to get it?  If ordinary unprivileged RP's are
> allowed to get it, why (other than certificate lifetime considerations)
> shouldn't it be in the certificate?
> 
'Ordinary' i.e., non-authorised RPs are NOT allowed to access to such data.




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01664 for <[e-mail]>; Tue, 18 Apr 2000 04:45:10 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA11901; Tue, 18 Apr 2000 13:46:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 18 Apr 2000 13:46:34 +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 NAA13523; Tue, 18 Apr 2000 13:46:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA10366; Tue, 18 Apr 2000 13:46:31 +0200 (MET DST)
Date: Tue, 18 Apr 2000 13:46:31 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Missing Protocol ?
Cc: [e-mail]

> 
> Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.
> 
> This fits well within perceived uses of the genm and genp of CMP.  If it is 
> a request from Jon Q, the CA can decide what to respond.  If genm contains 
> a warrant, well then...
> 

- An RA collects the justifications and at the moment when it demands the certificate,
  it creates a time stamped document containing the data in whatever way and stores it
  wherever this should be, indexed by one or all the certificates it is related to.
  The document may even contain the certificates. 

- An authorised RP may asks someone (else) to return this document. The
  server should return a statement saying that 'the RA had used the data xxx to
  issue the certificate, or in other words: The server decides that the cert is/was
  valid because of of the existence of that document content.  

There are obviously several ways to implement this with some of the protocols
that exist. Since my current favorite is dvcs, I start with this:

The request would be a for a 'verify public key certificate'. The response would
not contain the certificate chain, or maybe it would, it can contain all kinds
of certificates, etc, just ONE of the certEtcToken elements would be the
signedData object created by the RA. 

CMP or CMC are similar good candidates. 

Peter Sylvester


 


Received: from mta02-svc.server.ntlworld.com (mta2-win.server.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA00778 for <[e-mail]>; Tue, 18 Apr 2000 04:20:11 -0700 (PDT)
Received: from darxstar ([62.252.196.242]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000418122419.NYDM10065.mta02-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Tue, 18 Apr 2000 12:24:19 +0000
Message-ID: <001801bfa928$ffcb1af0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Original PKI message general info / Nested message message body
Date: Tue, 18 Apr 2000 12:25:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

RFC 2510bis adds the OrigPKIMessage general info type which allows an
intermediate party (an RA presumably) to embed a message from the EE within
the header of a second message from the RA; the CA can then recover the
original message.  This appears to fulfill exactly the same function as the
nested message PKIBody type.  One of these appears to be redundant; which
one?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



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 NAA09066 for <[e-mail]>; Mon, 17 Apr 2000 13:50:38 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 17 Apr 2000 14:50:15 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 17 Apr 2000 14:49:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Missing Protocol ?
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 NAA09067

Tom,

You're right, the potential sticking point is the privacy issue.

But privacy comes in several flavors, and there is also some 
concern for cluttering up certificate with information that may 
not always be required.

I don't think we need to come to the complexity of a German wine 
label (auslese cabinette, green capsule, with silver stripes) to solve this.

Consider the telephone company's policy.  My number can be listed, 
unpublished, or unlisted.  If it is listed, I may or may not list an address,
and if I do it doesn't have to be my real address -- it could be a forwarding 
service, or just a ZIP code.  (In the LA area, it costs extra to have your 
phone be unlisted, but it costs nothing to have a phony  address. So 
hundreds of people just list their names as Joe Doakes, 90210.

If my listing it is merely unpublished, you can ask for it. 

If it is unlisted, only law enforcement, and maybe other emergency 
services can get it, but I don't know if it requires a warrant in that case.

Same with the Tom Smith-with-the-beard.  Tom may not choose to list his 
hirsuteness or glabrousness, but he probably would have no problem with 
telling anyone who asks.  

His social security number might be a different story, but even then 
he is unlikely to defend that to the death, as too many people already 
have access to it. But he might require that such usage be audited, and 
that he have the right to know who asked for it, just as credit checks 
must be reported upon request.

If he is under the Witness Protection program, he is going to strenuously 
resist giving anyone his real name, birth date, etc.

But afer all, isn't what DIRECTORIES are for?

Why do we need a new protocol???

The answer is LDAP.  What was the question??

Bob



>>> <[e-mail]> 04/17/00 10:25AM >>>
     Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <[e-mail]> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <[e-mail]>
cc:   ietf-pkix <[e-mail]>
Subject:  Re: Missing Protocol ?



Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that
doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> >         Suppose that the fondest dreams of the early X.500 designers
had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band"
in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really
wandering here.
> > I'm not convinced that it is possible to define a technical - by which
I
> > mean "machine-processable" - protocol that is guaranteed to find you
the
> > right certificate if you don't have enough information from other
> > contexts.)
>
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
>
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
>
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
>
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
>
> Thoughts ?
>
> Denis
>
>
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

     - passport number/nationality
     - employee ID number
     - mail stop/address
     - phone number
     - driver's license number
     - SSN/other identity number
     - physically descriptive information (no, I'm not kidding here.  I
used to have a roommate named Tom Smith.  He worked in an office with
another Tom Smith.  The middle names and even the generational qualifier
were the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
The guy with the beard was threatened with mayhem if he ever shaved while
working in that office.:-)
     - a whole bunch of other stuff

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

If this is going to be meaningful to software and hardware, we'll have to
quantify/limit the list of acceptable information somehow.

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or an
extension to CMP/CMC?

Thanks,


Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
[phone]




Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06543 for <[e-mail]>; Mon, 17 Apr 2000 11:07:10 -0700 (PDT)
From: [e-mail]
Received: from e3.ny.us.ibm.com (s3 [10.0.3.103]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id MAA33942 for <[e-mail]>; Mon, 17 Apr 2000 12:25:05 -0400
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 MAA69762; Mon, 17 Apr 2000 12:23:49 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA172456; Mon, 17 Apr 2000 12:25:19 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568C4.005A3444 ; Mon, 17 Apr 2000 12:25:16 -0400
X-Lotus-FromDomain: IBMUS
To: Al Arsenault <[e-mail]>
cc: Denis Pinkas <[e-mail]>, ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 12:25:09 -0400
Subject: Re: Missing Protocol ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Some comments.  I think we can get a lot of this into certificates or
CMP responses, if we don't try for a "universal solution".  If liability is
at issue, even one of the ID's should do the trick.  The only problem I see
is a privacy problem.  If something shouldn't be in a certificate, which
RP's should be allowed to get it?  If ordinary unprivileged RP's are
allowed to get it, why (other than certificate lifetime considerations)
shouldn't it be in the certificate?

          Tom Gindin

Al Arsenault <[e-mail]> on 04/17/2000 11:19:08 AM

To:   Denis Pinkas <[e-mail]>
cc:   ietf-pkix <[e-mail]>
Subject:  Re: Missing Protocol ?



Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
>
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
>
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that
doesn't
> > involve knowledge external to the PKI.
>
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
>
> >         Suppose that the fondest dreams of the early X.500 designers
had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you
need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band"
in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really
wandering here.
> > I'm not convinced that it is possible to define a technical - by which
I
> > mean "machine-processable" - protocol that is guaranteed to find you
the
> > right certificate if you don't have enough information from other
> > contexts.)
>
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
>
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
>
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
>
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
>
> Thoughts ?
>
> Denis
>
>
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

     - passport number/nationality
     - employee ID number
     - mail stop/address
     - phone number
     - driver's license number
     - SSN/other identity number
     - physically descriptive information (no, I'm not kidding here.  I
used to have a roommate named Tom Smith.  He worked in an office with
another Tom Smith.  The middle names and even the generational qualifier
were the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you wanted.
The guy with the beard was threatened with mayhem if he ever shaved while
working in that office.:-)
     - a whole bunch of other stuff

[Tom Gindin] Most of your list, up to (not including) physically
descriptive information, has perfectly well-defined formats in our domain
already - and IMO we should start with those.  The ones I have been trying
to profile for an OTHER-NAME format to go into certificates are Employee ID
number, SSN or other nationwide government ID number, CA-assigned ID
number, and Passport, Driver's license, or other government agency ID
number.  Maybe we should include phone number (distinguished between work
and home) as long as there's a separate place for extension number at work.
How would we do mail stop/address - perhaps with an X.400 Physical Delivery
Address?  Of course, most people have different work and home mail
addresses too.

If this is going to be meaningful to software and hardware, we'll have to
quantify/limit the list of acceptable information somehow.

[Tom Gindin] Yes, we need to keep the list down.  However, I don't think
that means empty.  For the four ID types, I have only three syntaxes and
two of them are effectively subsets of the other.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or an
extension to CMP/CMC?

Thanks,


Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
[phone]




Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA05159 for <[e-mail]>; Mon, 17 Apr 2000 09:39:14 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Mon, 17 Apr 2000 12:46:05 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 17 Apr 2000 12:43:01 -0400
To: Denis Pinkas <[e-mail]>, Al Arsenault <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: Missing Protocol ?
Cc: ietf-pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:01 PM 4/17/2000 +0200, Denis Pinkas wrote:

>We could standardize the request and very loosely standardize the
>response. The request is easy to standardize: "I want more
>registration information on the certificate holder that has the
>following serial number". Depending both, on who the requester is
>and the certificate policy of the CA, more or less (even none)
>information will be released to the requester. We could thus
>standardize the response without mandating any component to be
>returned. In any case, it would be better than paper.

Sure, Denis.  Particularly since I've currently got my mind warpped around CMP.

This fits well within perceived uses of the genm and genp of CMP.  If it is 
a request from Jon Q, the CA can decide what to respond.  If genm contains 
a warrant, well then...

We have the basics here to build up requests for archived data.

I have been talking to some US university people that want anonymous certs 
for their library system.  A student might use their student cert for such 
a library cert.  A resident might use their DMV cert to get one.

But what if a proper authority needed to know who is cert holder 
3458923?  If the requester was the librarian, the response might be:  "A 
resident (non-student) of the State".  If it was a  law-type with a warrant 
it might be "Student ID-3456"; then let them deal with the school admin to 
learn more....



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04297 for <[e-mail]>; Mon, 17 Apr 2000 08:54:51 -0700 (PDT)
Received: from bull.net (itinerant6.frpq.bull.fr [129.184.8.53]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA26638; Mon, 17 Apr 2000 17:58:36 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 17:57:14 +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]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: Missing Protocol ?
References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
> Now that I understand better what you're getting at with this stuff  :-)
> 
> Denis Pinkas wrote:
> >
> > Since I launched this thread, I am following the various exchanges.
> > I pick this one to comment.
> >
> > > Thierry,
> > >
> > >         I'm not sure that there is a solution for this problem that doesn't
> > > involve knowledge external to the PKI.
> >
> > Since the knowledge is not external to PKI, the problem may be
> > considered by the PKIX WG.
> >
> > >         Suppose that the fondest dreams of the early X.500 designers had come
> > > true, and every item (to include person) in the known universe had a
> > > globally unique name.  Even in that case, if you are working with one
> > > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> > > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > > out-of-band what his globally-unique name is, or at least enough
> > > disambiguating information to let you accurately pick it out from the
> > > entries in the global directory.  Otherwise, you'll never know which is
> > > which.
> > >
> > >         The same type of information can be passed to you "out-of-band" in the
> > > current situation; when you first begin working with the right "Jim
> > > Jones of GM", he can provide you his certificate directly, or give you
> > > enough disambiguating information to make sure you find it somewhere
> > > else.  If he doesn't, you're not going to work securely.
> > >
> > >         (All of this is a long way of saying that we're really wandering here.
> > > I'm not convinced that it is possible to define a technical - by which I
> > > mean "machine-processable" - protocol that is guaranteed to find you the
> > > right certificate if you don't have enough information from other
> > > contexts.)
> >
> > When dealing with signatures, it is the other way around. You have a
> > certificate, that may even contain a pseudonym. When it does not
> > contain a pseudonym, the question is still: who indeed is that
> > person (e.g. Jim Jones 22) ? This person may be liable for a
> > contract worth 10.000 $ and the requester would like to get the home
> > address of the signer.
> >
> > The information that was obtained at the time of registration (and
> > that is NOT contained in the certificate) may help.
> >
> > The problem is that this registration information varies from one CA
> > to another and we are not going to standardize it easily. Is it
> > really a problem ?
> >
> > We could standardize the request and very loosely standardize the
> > response. The request is easy to standardize: "I want more
> > registration information on the certificate holder that has the
> > following serial number". Depending both, on who the requester is
> > and the certificate policy of the CA, more or less (even none)
> > information will be released to the requester. We could thus
> > standardize the response without mandating any component to be
> > returned. In any case, it would be better than paper.
> >
> > Thoughts ?
> >
> > Denis
> >
> >
> >
> 
> More "questions" than "thoughts":
> 
> 1.  Is the set of information that might reasonably be requested
> sufficiently bounded as to be specifiable in a protocol?  Off the top of
> my head, depending on the circumstances, I might ask for:
> 
>         - passport number/nationality
>         - employee ID number
>         - mail stop/address
>         - phone number
>         - driver's license number
>         - SSN/other identity number
>         - physically descriptive information (no, I'm not kidding here.  

I am not sure that you *directly* ask for this. This is what you may
*receive*. The request would use some category of information. It
would be up to the RA/CA to return whatever information matches with
these categories.

> I used
> to have a roommate named Tom Smith.  He worked in an office with another
> Tom Smith.  The middle names and even the generational qualifier were
> the same.  So when you called, you asked for 'the Tom Smith with a
> beard' or 'the clean-shaven Tom Smith', depending on which one you
> wanted. The guy with the beard was threatened with mayhem if he ever
> shaved while working in that office.:-)
>         - a whole bunch of other stuff
> 
> If this is going to be meaningful to software and hardware, we'll have
> to quantify/limit the list of acceptable information somehow.

The request may be sent by a computer, e.g. acting on behalf of a
person. The response might need to be read by a human being to be
understable.


> 2.  Do you envision the response being anything that a machine might
> parse and act upon, or only a general form for returning information for
> human consumption/decision?

The later.

> 3.  If we can get past 1., do you picture this being a new protocol, or
> an extension to CMP/CMC?

I have no preference at all, ... as long as we have that protocol.

Regards,

Denis

> 
> Thanks,
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> [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 IAA03609 for <[e-mail]>; Mon, 17 Apr 2000 08:16:53 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Mon, 17 Apr 2000 08:20:56 -0700
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 11:19:08 -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: Denis Pinkas <[e-mail]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Missing Protocol ?
References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Now that I understand better what you're getting at with this stuff  :-)

Denis Pinkas wrote:
> 
> Since I launched this thread, I am following the various exchanges.
> I pick this one to comment.
> 
> > Thierry,
> >
> >         I'm not sure that there is a solution for this problem that doesn't
> > involve knowledge external to the PKI.
> 
> Since the knowledge is not external to PKI, the problem may be
> considered by the PKIX WG.
> 
> >         Suppose that the fondest dreams of the early X.500 designers had come
> > true, and every item (to include person) in the known universe had a
> > globally unique name.  Even in that case, if you are working with one
> > "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> > to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> > out-of-band what his globally-unique name is, or at least enough
> > disambiguating information to let you accurately pick it out from the
> > entries in the global directory.  Otherwise, you'll never know which is
> > which.
> >
> >         The same type of information can be passed to you "out-of-band" in the
> > current situation; when you first begin working with the right "Jim
> > Jones of GM", he can provide you his certificate directly, or give you
> > enough disambiguating information to make sure you find it somewhere
> > else.  If he doesn't, you're not going to work securely.
> >
> >         (All of this is a long way of saying that we're really wandering here.
> > I'm not convinced that it is possible to define a technical - by which I
> > mean "machine-processable" - protocol that is guaranteed to find you the
> > right certificate if you don't have enough information from other
> > contexts.)
> 
> When dealing with signatures, it is the other way around. You have a
> certificate, that may even contain a pseudonym. When it does not
> contain a pseudonym, the question is still: who indeed is that
> person (e.g. Jim Jones 22) ? This person may be liable for a
> contract worth 10.000 $ and the requester would like to get the home
> address of the signer.
> 
> The information that was obtained at the time of registration (and
> that is NOT contained in the certificate) may help.
> 
> The problem is that this registration information varies from one CA
> to another and we are not going to standardize it easily. Is it
> really a problem ?
> 
> We could standardize the request and very loosely standardize the
> response. The request is easy to standardize: "I want more
> registration information on the certificate holder that has the
> following serial number". Depending both, on who the requester is
> and the certificate policy of the CA, more or less (even none)
> information will be released to the requester. We could thus
> standardize the response without mandating any component to be
> returned. In any case, it would be better than paper.
> 
> Thoughts ?
> 
> Denis
> 
> 
>

More "questions" than "thoughts":

1.  Is the set of information that might reasonably be requested
sufficiently bounded as to be specifiable in a protocol?  Off the top of
my head, depending on the circumstances, I might ask for:

	- passport number/nationality
	- employee ID number
	- mail stop/address
	- phone number
	- driver's license number
	- SSN/other identity number
	- physically descriptive information (no, I'm not kidding here.  I used
to have a roommate named Tom Smith.  He worked in an office with another
Tom Smith.  The middle names and even the generational qualifier were
the same.  So when you called, you asked for 'the Tom Smith with a
beard' or 'the clean-shaven Tom Smith', depending on which one you
wanted. The guy with the beard was threatened with mayhem if he ever
shaved while working in that office.:-)
	- a whole bunch of other stuff

If this is going to be meaningful to software and hardware, we'll have
to quantify/limit the list of acceptable information somehow.

2.  Do you envision the response being anything that a machine might
parse and act upon, or only a general form for returning information for
human consumption/decision?

3.  If we can get past 1., do you picture this being a new protocol, or
an extension to CMP/CMC?

Thanks,


Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
[phone]


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03185 for <[e-mail]>; Mon, 17 Apr 2000 07:59:00 -0700 (PDT)
Received: from bull.net (itinerant6.frpq.bull.fr [129.184.8.53]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA18354; Mon, 17 Apr 2000 17:02:43 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 17:01:28 +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]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Missing Protocol ?
References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Since I launched this thread, I am following the various exchanges.
I pick this one to comment.

> Thierry,
> 
>         I'm not sure that there is a solution for this problem that doesn't
> involve knowledge external to the PKI.

Since the knowledge is not external to PKI, the problem may be
considered by the PKIX WG. 

>         Suppose that the fondest dreams of the early X.500 designers had come
> true, and every item (to include person) in the known universe had a
> globally unique name.  Even in that case, if you are working with one
> "Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
> to distinguish them, then YOUR "Jim Jones of GM" has to tell you
> out-of-band what his globally-unique name is, or at least enough
> disambiguating information to let you accurately pick it out from the
> entries in the global directory.  Otherwise, you'll never know which is
> which.
> 
>         The same type of information can be passed to you "out-of-band" in the
> current situation; when you first begin working with the right "Jim
> Jones of GM", he can provide you his certificate directly, or give you
> enough disambiguating information to make sure you find it somewhere
> else.  If he doesn't, you're not going to work securely.
> 
>         (All of this is a long way of saying that we're really wandering here.
> I'm not convinced that it is possible to define a technical - by which I
> mean "machine-processable" - protocol that is guaranteed to find you the
> right certificate if you don't have enough information from other
> contexts.)

When dealing with signatures, it is the other way around. You have a
certificate, that may even contain a pseudonym. When it does not
contain a pseudonym, the question is still: who indeed is that
person (e.g. Jim Jones 22) ? This person may be liable for a
contract worth 10.000 $ and the requester would like to get the home
address of the signer.

The information that was obtained at the time of registration (and
that is NOT contained in the certificate) may help.

The problem is that this registration information varies from one CA
to another and we are not going to standardize it easily. Is it
really a problem ? 

We could standardize the request and very loosely standardize the
response. The request is easy to standardize: "I want more
registration information on the certificate holder that has the
following serial number". Depending both, on who the requester is
and the certificate policy of the CA, more or less (even none)
information will be released to the requester. We could thus
standardize the response without mandating any component to be
returned. In any case, it would be better than paper.

Thoughts ?

Denis

  



 










> 
> 
> 
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.
> P.O. Box 6530
> Ellicott City, MD 21042-0530
> [phone]
> 
> Thierry Van Doninck wrote:
> >
> > Roger,
> >
> > Yes,
> >
> > But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
> > Therefor a relying party might not know wether the certified party can be allowed to perform a certain
> > action. A certificate received by a RP might not contain sufficient information to authenticate
> > the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)
> >
> > I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ),
> > but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)
> >
> > Thierry Van Doninck
> > eMail : [e-mail]
> >
> > ryounglove%lucent.com@Internet
> > 14/04/2000 21:14
> > To:     egerck%nma.com@Internet
> > cc:     ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)
> >
> > Subject:        Re: Missing Protocol ?
> >
> > I agree with both Dave and Ed, however I do not believe that a new WG is
> > needed. The individual identity (carbon or silicon life form) that is
> > certified with a digital certificate is the responsibility of the PKI which
> > is issuing the cert. The Certificate Policy written by that PKI operator
> > supplies the requirements for identification authentication. The CA CPS
> > states how the CP requirements are met. It is the Relying Parties
> > responsibility to properly evaluate the validity of a certificate that they
> > receive. When both the CP OID and the CPS OID is included in the cert it
> > becomes easy to evaluate the validity.
> > At 01:41 PM 4/14/2000 , you wrote:
> > >Dave:
> > >
> > >Yes and to your final paragraph.  A new WG would be needed -- otherwise
> > >this WG would need to backtrack so much that nothing would be left ;-)
> > >OTOH, with a new WG then what this WG has done might be a *component*
> > >in a bigger frame, and a useful one.
> > >
> > >Cheers,
> > >
> > >Ed Gerck
> > >
> > >"David P. Kemp" wrote:
> > >
> > > > > From: Denis Pinkas <[e-mail]>
> > > > > > From: Ed Gerck
> > > > > > Here, in PKIX, the main purpose of a CA is also to bind a public
> > > key to the name
> > > > > > contained in the certificate and thus assure third parties that
> > > some measure of care
> > > > > > was taken to ensure that this binding is valid for both -- i.e.,
> > > name and key. However,
> > > > > > the issue whether a user's DN actually corresponds to identity
> > > credentials that are
> > > > > > *globally* linked to a person, or to a local alias or, simply to an
> > > e-mail address -- and
> > > > > > how such association was verified --   is  outside the scope of
> > > PKIX and depends
> > > > > > on each CA's CPS.
> > > > >
> > > > > I am not sure that this is really outside the scope of PKIX. If some
> > > > > judge would like to make the difference between John Smith 22 and
> > > > > John Smith 23, what can he do ? Nothing that has been standardized
> > > > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > > > should ? What kind of solution ? Being able to get back (when
> > > > > appropriate) the registration information (sometimes called the
> > > > > credentials) that has been registered at the time of registration by
> > > > > the RA. I do not think that it may be practical to get that
> > > > > information by paper and in a different format for every CA in the
> > > > > world. A protocol (and a schema) might be useful.
> > > > >
> > > > > Denis
> > > >
> > > > Denis,
> > > >
> > > > As long as CPSs are different, the "big identity in the sky" (the
> > > > information about a subject which makes John Smith 22 different from
> > > > John Smith 23) will be different, and outside the scope of PKIX.  If
> > > > the judge has access to a certain body of information:  employment and
> > > > credit history, property ownership and tax records, utility bills, etc,
> > > > and the CA has used any of that information to establish identity, then
> > > > the certificate may be useful to the judge.  If the CA uses only email
> > > > address to establish "identity", the certificate will be useless to a
> > > > judge dealing in non-electronic matters.  I don't see how PKIX could
> > > > consider in-scope an effort to develop a schema for the universe
> > > > of information which could constitute a human identity.
> > > >
> > > > Dave
> >
> > ---
> > TTFN
> > Roger W. Younglove, CISSP
> > Sr. Network Security Consultant
> > NetworkCare® Security Services
> > 100 Galleria Officentre, Ste. 200
> > Southfield, MI 48034
> > Numeric page: 888.935.6755
> > E-mail page:
> > [e-mail]
> > eFax number: 413.425.5368
> > www.lucent.com/netcare


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 GAA01649 for <[e-mail]>; Mon, 17 Apr 2000 06:24:38 -0700 (PDT)
Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <[e-mail]>; Mon, 17 Apr 2000 06:28:41 -0700
Message-ID: <[e-mail]>
Date: Mon, 17 Apr 2000 09:26:52 -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: Thierry Van Doninck <[e-mail]>
CC: ietf-pkix <[e-mail]>
Subject: Re: Missing Protocol ?
References: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Thierry,

	I'm not sure that there is a solution for this problem that doesn't
involve knowledge external to the PKI. 

	Suppose that the fondest dreams of the early X.500 designers had come
true, and every item (to include person) in the known universe had a
globally unique name.  Even in that case, if you are working with one
"Jim Jones of GM" and not with any other "Jim Jones of GM", and you need
to distinguish them, then YOUR "Jim Jones of GM" has to tell you
out-of-band what his globally-unique name is, or at least enough
disambiguating information to let you accurately pick it out from the
entries in the global directory.  Otherwise, you'll never know which is
which.

	The same type of information can be passed to you "out-of-band" in the
current situation; when you first begin working with the right "Jim
Jones of GM", he can provide you his certificate directly, or give you
enough disambiguating information to make sure you find it somewhere
else.  If he doesn't, you're not going to work securely.  

	(All of this is a long way of saying that we're really wandering here. 
I'm not convinced that it is possible to define a technical - by which I
mean "machine-processable" - protocol that is guaranteed to find you the
right certificate if you don't have enough information from other
contexts.)

			

Al Arsenault
Chief Security Architect
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042-0530
[phone]

Thierry Van Doninck wrote:
> 
> Roger,
> 
> Yes,
> 
> But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
> Therefor a relying party might not know wether the certified party can be allowed to perform a certain
> action. A certificate received by a RP might not contain sufficient information to authenticate
> the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)
> 
> I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ),
> but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)
> 
> Thierry Van Doninck
> eMail : [e-mail]
> 
> ryounglove%lucent.com@Internet
> 14/04/2000 21:14
> To:     egerck%nma.com@Internet
> cc:     ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)
> 
> Subject:        Re: Missing Protocol ?
> 
> I agree with both Dave and Ed, however I do not believe that a new WG is
> needed. The individual identity (carbon or silicon life form) that is
> certified with a digital certificate is the responsibility of the PKI which
> is issuing the cert. The Certificate Policy written by that PKI operator
> supplies the requirements for identification authentication. The CA CPS
> states how the CP requirements are met. It is the Relying Parties
> responsibility to properly evaluate the validity of a certificate that they
> receive. When both the CP OID and the CPS OID is included in the cert it
> becomes easy to evaluate the validity.
> At 01:41 PM 4/14/2000 , you wrote:
> >Dave:
> >
> >Yes and to your final paragraph.  A new WG would be needed -- otherwise
> >this WG would need to backtrack so much that nothing would be left ;-)
> >OTOH, with a new WG then what this WG has done might be a *component*
> >in a bigger frame, and a useful one.
> >
> >Cheers,
> >
> >Ed Gerck
> >
> >"David P. Kemp" wrote:
> >
> > > > From: Denis Pinkas <[e-mail]>
> > > > > From: Ed Gerck
> > > > > Here, in PKIX, the main purpose of a CA is also to bind a public
> > key to the name
> > > > > contained in the certificate and thus assure third parties that
> > some measure of care
> > > > > was taken to ensure that this binding is valid for both -- i.e.,
> > name and key. However,
> > > > > the issue whether a user's DN actually corresponds to identity
> > credentials that are
> > > > > *globally* linked to a person, or to a local alias or, simply to an
> > e-mail address -- and
> > > > > how such association was verified --   is  outside the scope of
> > PKIX and depends
> > > > > on each CA's CPS.
> > > >
> > > > I am not sure that this is really outside the scope of PKIX. If some
> > > > judge would like to make the difference between John Smith 22 and
> > > > John Smith 23, what can he do ? Nothing that has been standardized
> > > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > > should ? What kind of solution ? Being able to get back (when
> > > > appropriate) the registration information (sometimes called the
> > > > credentials) that has been registered at the time of registration by
> > > > the RA. I do not think that it may be practical to get that
> > > > information by paper and in a different format for every CA in the
> > > > world. A protocol (and a schema) might be useful.
> > > >
> > > > Denis
> > >
> > > Denis,
> > >
> > > As long as CPSs are different, the "big identity in the sky" (the
> > > information about a subject which makes John Smith 22 different from
> > > John Smith 23) will be different, and outside the scope of PKIX.  If
> > > the judge has access to a certain body of information:  employment and
> > > credit history, property ownership and tax records, utility bills, etc,
> > > and the CA has used any of that information to establish identity, then
> > > the certificate may be useful to the judge.  If the CA uses only email
> > > address to establish "identity", the certificate will be useless to a
> > > judge dealing in non-electronic matters.  I don't see how PKIX could
> > > consider in-scope an effort to develop a schema for the universe
> > > of information which could constitute a human identity.
> > >
> > > Dave
> 
> ---
> TTFN
> Roger W. Younglove, CISSP
> Sr. Network Security Consultant
> NetworkCare® Security Services
> 100 Galleria Officentre, Ste. 200
> Southfield, MI 48034
> Numeric page: 888.935.6755
> E-mail page:
> [e-mail]
> eFax number: 413.425.5368
> www.lucent.com/netcare


Received: from spdl113_tr0.dexia.be (hstcentd.dexia.be [193.91.97.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA23049 for <[e-mail]>; Mon, 17 Apr 2000 00:15:52 -0700 (PDT)
Date: 17 Apr 2000 09:13:05 +0200
From: Thierry Van Doninck <[e-mail]>
To: ietf-pkix <[e-mail]>
Subject: Re: Missing Protocol ?
Message-Id: <0F61838FAB9810EF*/c=be/admd=publilink/prmd=gkbccb/o=notes/s=SY064/@MHS>
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 AAA23050

Roger,

Yes,

But knowing if a certificate is valid might and trustworthy might still not tell you who it is.
Therefor a relying party might not know wether the certified party can be allowed to perform a certain 
action. A certificate received by a RP might not contain sufficient information to authenticate 
the person behind it. (I know it is a Jim Jones working at GM., but which Jim Jones is it ?)

I as a RP can check that it is valid, I have every confidence that it is valid (after having read the Cp and CPS :-( ), 
but I still cannot USE it, because it does not tell me who is being certified. (Is it my business partner or not ?)

Thierry Van Doninck
eMail : [e-mail]






ryounglove%lucent.com@Internet
14/04/2000 21:14
To:	egerck%nma.com@Internet
cc:	ietf-pkix%imc.org@Internet (bcc: Thierry Van Doninck/GKBCCB)

Subject:	Re: Missing Protocol ?

I agree with both Dave and Ed, however I do not believe that a new WG is 
needed. The individual identity (carbon or silicon life form) that is 
certified with a digital certificate is the responsibility of the PKI which 
is issuing the cert. The Certificate Policy written by that PKI operator 
supplies the requirements for identification authentication. The CA CPS 
states how the CP requirements are met. It is the Relying Parties 
responsibility to properly evaluate the validity of a certificate that they 
receive. When both the CP OID and the CPS OID is included in the cert it 
becomes easy to evaluate the validity.
At 01:41 PM 4/14/2000 , you wrote:
>Dave:
>
>Yes and to your final paragraph.  A new WG would be needed -- otherwise
>this WG would need to backtrack so much that nothing would be left ;-)
>OTOH, with a new WG then what this WG has done might be a *component*
>in a bigger frame, and a useful one.
>
>Cheers,
>
>Ed Gerck
>
>"David P. Kemp" wrote:
>
> > > From: Denis Pinkas <[e-mail]>
> > > > From: Ed Gerck
> > > > Here, in PKIX, the main purpose of a CA is also to bind a public 
> key to the name
> > > > contained in the certificate and thus assure third parties that 
> some measure of care
> > > > was taken to ensure that this binding is valid for both -- i.e., 
> name and key. However,
> > > > the issue whether a user's DN actually corresponds to identity 
> credentials that are
> > > > *globally* linked to a person, or to a local alias or, simply to an 
> e-mail address -- and
> > > > how such association was verified --   is  outside the scope of 
> PKIX and depends
> > > > on each CA's CPS.
> > >
> > > I am not sure that this is really outside the scope of PKIX. If some
> > > judge would like to make the difference between John Smith 22 and
> > > John Smith 23, what can he do ? Nothing that has been standardized
> > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > should ? What kind of solution ? Being able to get back (when
> > > appropriate) the registration information (sometimes called the
> > > credentials) that has been registered at the time of registration by
> > > the RA. I do not think that it may be practical to get that
> > > information by paper and in a different format for every CA in the
> > > world. A protocol (and a schema) might be useful.
> > >
> > > Denis
> >
> > Denis,
> >
> > As long as CPSs are different, the "big identity in the sky" (the
> > information about a subject which makes John Smith 22 different from
> > John Smith 23) will be different, and outside the scope of PKIX.  If
> > the judge has access to a certain body of information:  employment and
> > credit history, property ownership and tax records, utility bills, etc,
> > and the CA has used any of that information to establish identity, then
> > the certificate may be useful to the judge.  If the CA uses only email
> > address to establish "identity", the certificate will be useless to a
> > judge dealing in non-electronic matters.  I don't see how PKIX could
> > consider in-scope an effort to develop a schema for the universe
> > of information which could constitute a human identity.
> >
> > Dave

---
TTFN
Roger W. Younglove, CISSP
Sr. Network Security Consultant
NetworkCare® Security Services
100 Galleria Officentre, Ste. 200
Southfield, MI 48034
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare





Received: from connfax.fin.gc.ca (mail3.fin.gc.ca [198.103.53.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA25033 for <[e-mail]>; Sun, 16 Apr 2000 17:17:02 -0700 (PDT)
From: [e-mail]
Received: by connfax.fin.gc.ca with Internet Mail Service (5.5.2448.0) id <20MLMYXF>; Sun, 16 Apr 2000 20:21:27 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: pki product report
Date: Sun, 16 Apr 2000 20:21:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

	You may wish to search the Federal Register in the United States
under notices published by the US Patent and Trademark Office in 1999. (My
apologies for not being able to be more specific as to the publication
date.) I recall they published a very interesting table comparing PKI
products in relation to a procurement "sole source" justification. 
	
	> -----Original Message-----
	> From:	Gao Yuhang [SMTP:[e-mail]]
	> Sent:	Thursday, April 13, 2000 6:11 PM
	> To:	pki_ietf list
	> Subject:	pki product report
	> 
	> 	Please excuse for off-topic. But can anyonehelp me to find
	> reports on current PKI products,with explanations and
comparisions, such
	> as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate
Server?
	> 
	> Thanks,
	> Hazel
	>  ______________________________________________
	>   Miss Yuhang Gao
	>   Network Center, Computer Dept.
	>   Southeast University,
	>   Nanjing, Jiangsu,
	>   P.R.China
	>   210096


Received: from ukslms52.cai.com (ukslms52.cai.com [130.119.248.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07102 for <[e-mail]>; Fri, 14 Apr 2000 15:45:41 -0700 (PDT)
Received: by ukslms52.cai.com with Internet Mail Service (5.5.2650.21) id <2860CMLF>; Fri, 14 Apr 2000 23:49:21 +0100
Message-ID: <[e-mail]>
From: "McMahon, Piers" <[e-mail]>
To: Gao Yuhang <[e-mail]>, pki_ietf list <[e-mail]>
Subject: RE: pki product report
Date: Fri, 14 Apr 2000 23:50:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

There are a couple of reasonably up-to-date and comprehensive (but unfortunately, 
not free) reports from industry analysts.  These cover PKI business drivers, technology,
standards (including various assertions about PKIX take-up), deployment, and the specific 
commercial solutions you ask about.    For example:
  http://www.itresearch.com/alfatst4.nsf/UNITABS/W20448
  http://www.radicati.com/tocs/toc_2000pki.htm

I have seen a number of other surveys of PKI(X) implementations (whether free and/or 
commercial software) on the net, but I don't know a *recent* one.  Hopefully some list members 
may have suggestions.

If you want to do any comparisons yourself, there are also some general information sites, 
groups, frameworks, and certification programs related to PKI & conformance / interoperability 
testing.   Some of these may help you with your functional and other criteria  ... e.g.
   http://csrc.nist.gov/pki/twg/welcome.html
   http://www.opengroup.org/publications/catalog/g801.htm
   http://www.icsa.net/html/communities/pki/
   http://www.pkiforum.org/About/index.htm
  etc


> -----Original Message-----
> From:	Gao Yuhang [SMTP:[e-mail]]
> Sent:	Thursday, April 13, 2000 6:11 PM
> To:	pki_ietf list
> Subject:	pki product report
> 
> 	Please excuse for off-topic. But can anyonehelp me to find
> reports on current PKI products,with explanations and comparisions, such
> as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate Server?
> 
> Thanks,
> Hazel
>  ______________________________________________
>   Miss Yuhang Gao
>   Network Center, Computer Dept.
>   Southeast University,
>   Nanjing, Jiangsu,
>   P.R.China
>   210096


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 NAA05520 for <[e-mail]>; Fri, 14 Apr 2000 13:36:39 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA12984 for <[e-mail]>; Fri, 14 Apr 2000 16:38:53 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 14 Apr 2000 16:39:46 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Missing Protocol ?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 19QHSrf6k2/V4c2P+E82DA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Oh, well in that case, why don't we just use GeneralName:registeredID
and be done with it.

Both OIDs and DistinguishedNames are supposed to have Naming
Authorities which maintain registries and delegate the responsibility
to maintain subordinate registries.  But only OIDs seem to actually
follow the model :-(.  The only way to get an OID arc under US(840) is
to get it from ANSI.  There is no corresponding discipline in
establishing DNs beginning with, e.g., C=US, and until every cert
issuer agrees that there should be, there will be no global DNs.

Dave



> From: [e-mail]
> To: "David P. Kemp" <[e-mail]>
> cc: [e-mail]
> Date: Fri, 14 Apr 2000 16:06:03 -0400
> 
>      I don't think that anyone is proposing "an effort to develop a schema
> for the universe of information which could constitute a human identity".
> At least I hope not :-(
>      What I, at least, am proposing is a mechanism by which identifiers
> which were assigned by a known identified organization can be represented
> in a GeneralName, in such a way that an RP can tell who is the assignment
> authority for the identifier.  The cases where the assignment authority is
> a government agency or the issuing CA are of special importance.  Some may
> consider this out of scope for PKIX, but it is certainly not more complex
> or unworkable than the existing DN arrangement.
>      The fields that would actually be used in this way are likely to
> include things like employee identifications.  "John Smith who has been
> General Motors employee 356789" is a much more definitive identifier than
> "John Smith" or even "John Edward Smith from Michigan who works for GM".
> 
>           Tom Gindin



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 NAA04986 for <[e-mail]>; Fri, 14 Apr 2000 13:02:33 -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 QAA214900; Fri, 14 Apr 2000 16:04:50 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id QAA72840; Fri, 14 Apr 2000 16:06:20 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568C1.006E6E66 ; Fri, 14 Apr 2000 16:06:12 -0400
X-Lotus-FromDomain: IBMUS
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 14 Apr 2000 16:06:03 -0400
Subject: Re: Missing Protocol ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I don't think that anyone is proposing "an effort to develop a schema
for the universe of information which could constitute a human identity".
At least I hope not :-(
     What I, at least, am proposing is a mechanism by which identifiers
which were assigned by a known identified organization can be represented
in a GeneralName, in such a way that an RP can tell who is the assignment
authority for the identifier.  The cases where the assignment authority is
a government agency or the issuing CA are of special importance.  Some may
consider this out of scope for PKIX, but it is certainly not more complex
or unworkable than the existing DN arrangement.
     The fields that would actually be used in this way are likely to
include things like employee identifications.  "John Smith who has been
General Motors employee 356789" is a much more definitive identifier than
"John Smith" or even "John Edward Smith from Michigan who works for GM".

          Tom Gindin

"David P. Kemp" <[e-mail]> on 04/14/2000 01:25:23 PM

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

To:   [e-mail]
cc:
Subject:  Re: Missing Protocol ?




> From: Denis Pinkas <[e-mail]>
> > From: Ed Gerck
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to
the name
> > contained in the certificate and thus assure third parties that some
measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name
and key. However,
> > the issue whether a user's DN actually corresponds to identity
credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an
e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX
and depends
> > on each CA's CPS.
>
> I am not sure that this is really outside the scope of PKIX. If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.
>
> Denis


Denis,

As long as CPSs are different, the "big identity in the sky" (the
information about a subject which makes John Smith 22 different from
John Smith 23) will be different, and outside the scope of PKIX.  If
the judge has access to a certain body of information:  employment and
credit history, property ownership and tax records, utility bills, etc,
and the CA has used any of that information to establish identity, then
the certificate may be useful to the judge.  If the CA uses only email
address to establish "identity", the certificate will be useless to a
judge dealing in non-electronic matters.  I don't see how PKIX could
consider in-scope an effort to develop a schema for the universe
of information which could constitute a human identity.

Dave




Received: from dtctxexch3.ins.com ([208.164.93.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04146 for <[e-mail]>; Fri, 14 Apr 2000 12:10:10 -0700 (PDT)
Received: from youngl-r (PPPa3-ResaleDetroit1-5R1021.saturn.bbn.com [4.16.42.206]) by dtctxexch3.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2RR3KLNT; Fri, 14 Apr 2000 14:13:56 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 14 Apr 2000 14:35:42 -0400
To: Ed Gerck <[e-mail]>
From: Roger Younglove <[e-mail]>
Subject: Re: Missing Protocol ?
Cc: [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
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA04147

I agree with both Dave and Ed, however I do not believe that a new WG is 
needed. The individual identity (carbon or silicon life form) that is 
certified with a digital certificate is the responsibility of the PKI which 
is issuing the cert. The Certificate Policy written by that PKI operator 
supplies the requirements for identification authentication. The CA CPS 
states how the CP requirements are met. It is the Relying Parties 
responsibility to properly evaluate the validity of a certificate that they 
receive. When both the CP OID and the CPS OID is included in the cert it 
becomes easy to evaluate the validity.
At 01:41 PM 4/14/2000 , you wrote:
>Dave:
>
>Yes and to your final paragraph.  A new WG would be needed -- otherwise
>this WG would need to backtrack so much that nothing would be left ;-)
>OTOH, with a new WG then what this WG has done might be a *component*
>in a bigger frame, and a useful one.
>
>Cheers,
>
>Ed Gerck
>
>"David P. Kemp" wrote:
>
> > > From: Denis Pinkas <[e-mail]>
> > > > From: Ed Gerck
> > > > Here, in PKIX, the main purpose of a CA is also to bind a public 
> key to the name
> > > > contained in the certificate and thus assure third parties that 
> some measure of care
> > > > was taken to ensure that this binding is valid for both -- i.e., 
> name and key. However,
> > > > the issue whether a user's DN actually corresponds to identity 
> credentials that are
> > > > *globally* linked to a person, or to a local alias or, simply to an 
> e-mail address -- and
> > > > how such association was verified --   is  outside the scope of 
> PKIX and depends
> > > > on each CA's CPS.
> > >
> > > I am not sure that this is really outside the scope of PKIX. If some
> > > judge would like to make the difference between John Smith 22 and
> > > John Smith 23, what can he do ? Nothing that has been standardized
> > > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > > should ? What kind of solution ? Being able to get back (when
> > > appropriate) the registration information (sometimes called the
> > > credentials) that has been registered at the time of registration by
> > > the RA. I do not think that it may be practical to get that
> > > information by paper and in a different format for every CA in the
> > > world. A protocol (and a schema) might be useful.
> > >
> > > Denis
> >
> > Denis,
> >
> > As long as CPSs are different, the "big identity in the sky" (the
> > information about a subject which makes John Smith 22 different from
> > John Smith 23) will be different, and outside the scope of PKIX.  If
> > the judge has access to a certain body of information:  employment and
> > credit history, property ownership and tax records, utility bills, etc,
> > and the CA has used any of that information to establish identity, then
> > the certificate may be useful to the judge.  If the CA uses only email
> > address to establish "identity", the certificate will be useless to a
> > judge dealing in non-electronic matters.  I don't see how PKIX could
> > consider in-scope an effort to develop a schema for the universe
> > of information which could constitute a human identity.
> >
> > Dave

---
TTFN
Roger W. Younglove, CISSP
Sr. Network Security Consultant
NetworkCare® Security Services
100 Galleria Officentre, Ste. 200
Southfield, MI 48034
Numeric page: 888.935.6755
E-mail page:
[e-mail]
eFax number: 413.425.5368
www.lucent.com/netcare



Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA03156 for <[e-mail]>; Fri, 14 Apr 2000 11:09:24 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Fri, 14 Apr 2000 14:15:41 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 14 Apr 2000 14:00:46 -0400
To: Anders Rundgren <[e-mail]>, "Heimberg, Jim" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: Global unique identifier
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <01BFA565.7B6108E0@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 04:29 PM 4/13/2000 +0200, Anders Rundgren wrote:

>There are very few global standards for this, but CAs usually have 
>restricted geographic coverage.

Usually????

SInce most CAs deployed today are within businesses.

And many businesses are global.

And some of these businesses are planning on central CAs with regional RAs....

You should see General Motor's  DN's (unless they changed them from 6 
months ago).  Of course GM DOES have at least one  CA in each country, but 
they are all rooted in c=US.

In the long run, most certificates are going to be issued by private CAs 
for business use.  DNs will reflect business needs, and there will be only 
lip service to national boundaries.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02571 for <[e-mail]>; Fri, 14 Apr 2000 10:38:47 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 14 Apr 2000 10:41:23 -0700 (PDT)
Date: Fri, 14 Apr 2000 10:41:33 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: Missing Protocol ?
To: "David P. Kemp" <[e-mail]>, "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <[e-mail]>

Dave:

Yes and to your final paragraph.  A new WG would be needed -- otherwise
this WG would need to backtrack so much that nothing would be left ;-)
OTOH, with a new WG then what this WG has done might be a *component*
in a bigger frame, and a useful one.

Cheers,

Ed Gerck

"David P. Kemp" wrote:

> > From: Denis Pinkas <[e-mail]>
> > > From: Ed Gerck
> > > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > > contained in the certificate and thus assure third parties that some measure of care
> > > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > > the issue whether a user's DN actually corresponds to identity credentials that are
> > > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > > how such association was verified --   is  outside the scope of PKIX and depends
> > > on each CA's CPS.
> >
> > I am not sure that this is really outside the scope of PKIX. If some
> > judge would like to make the difference between John Smith 22 and
> > John Smith 23, what can he do ? Nothing that has been standardized
> > today. :-(  In PKIX we currently do not offer any solution. Maybe we
> > should ? What kind of solution ? Being able to get back (when
> > appropriate) the registration information (sometimes called the
> > credentials) that has been registered at the time of registration by
> > the RA. I do not think that it may be practical to get that
> > information by paper and in a different format for every CA in the
> > world. A protocol (and a schema) might be useful.
> >
> > Denis
>
> Denis,
>
> As long as CPSs are different, the "big identity in the sky" (the
> information about a subject which makes John Smith 22 different from
> John Smith 23) will be different, and outside the scope of PKIX.  If
> the judge has access to a certain body of information:  employment and
> credit history, property ownership and tax records, utility bills, etc,
> and the CA has used any of that information to establish identity, then
> the certificate may be useful to the judge.  If the CA uses only email
> address to establish "identity", the certificate will be useless to a
> judge dealing in non-electronic matters.  I don't see how PKIX could
> consider in-scope an effort to develop a schema for the universe
> of information which could constitute a human identity.
>
> Dave



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 KAA02166 for <[e-mail]>; Fri, 14 Apr 2000 10:22:17 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA04644 for <[e-mail]>; Fri, 14 Apr 2000 13:24:31 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 14 Apr 2000 13:25:23 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Missing Protocol ?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: rzgxm05PeNUjejNXza7Vcw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: Denis Pinkas <[e-mail]>
> > From: Ed Gerck
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > contained in the certificate and thus assure third parties that some measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > the issue whether a user's DN actually corresponds to identity credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX and depends
> > on each CA's CPS.
> 
> I am not sure that this is really outside the scope of PKIX. If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.
> 
> Denis


Denis,

As long as CPSs are different, the "big identity in the sky" (the
information about a subject which makes John Smith 22 different from
John Smith 23) will be different, and outside the scope of PKIX.  If
the judge has access to a certain body of information:  employment and
credit history, property ownership and tax records, utility bills, etc,
and the CA has used any of that information to establish identity, then
the certificate may be useful to the judge.  If the CA uses only email
address to establish "identity", the certificate will be useless to a
judge dealing in non-electronic matters.  I don't see how PKIX could
consider in-scope an effort to develop a schema for the universe
of information which could constitute a human identity.

Dave



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01738 for <[e-mail]>; Fri, 14 Apr 2000 10:07:27 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 14 Apr 2000 10:08:54 -0700 (PDT)
Date: Fri, 14 Apr 2000 10:08:00 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: Global unique identifier
To: "Heimberg, Jim" <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <[e-mail]>

"Heimberg, Jim" wrote:

> No, they would not choose different CAs, but the Registration Authority
> would be required to add a suffix in order to make the DN different such as
> Jim Jones1, Jim Jones2, etc.

This does not work for several reasons. First, the CA usually doubles as
a RA.  Second, who gets #1? Third, the Jim Joneses can ask,  why should
I accept and live with a protocol that forces a name change in order to
cope with what the protocol intends to *represent*? Further, of course,
it would not match their driver's license, for example -- which is at least
less demanding on how people's names are given.  Not last and not
least, someone can be rightully called "Jim Jones1" in many countries
and that someone would then conflict with the first Jim Jones in line
at that CA.  Finally,  then all CAs should name *everyone* with a
an appended "1" -- just in case someone else comes in with that
same name and we don't have to change the first one's DN ;-)


Cheers,

Ed Gerck



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01434 for <[e-mail]>; Fri, 14 Apr 2000 09:59:03 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Fri, 14 Apr 2000 09:58:44 -0700 (PDT)
Date: Fri, 14 Apr 2000 09:58:54 -0700
From: Ed Gerck <[e-mail]>
Subject: Yes, Re: Missing Protocol ?
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <[e-mail]> <[e-mail]> <[e-mail]>

Denis Pinkas wrote:


> There is one point in your E-mail I would like to comment.
>
> > Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> > contained in the certificate and thus assure third parties that some measure of care
> > was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> > the issue whether a user's DN actually corresponds to identity credentials that are
> > *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> > how such association was verified --   is  outside the scope of PKIX and depends
> > on each CA's CPS.
>
> I am not sure that this is really outside the scope of PKIX.

By your comment below, I think we both agree that indeed it IS (present tense)
outside the scope of PKIX and depends on each CA's CPS -- you write "what
can he do ? Nothing that has been standardized today. :-(  In PKIX we currently
do not offer any solution".

That was my point exactly.  Now, should we (in the future) offer it ? -- as
you also ask:

> If some
> judge would like to make the difference between John Smith 22 and
> John Smith 23, what can he do ? Nothing that has been standardized
> today. :-(  In PKIX we currently do not offer any solution. Maybe we
> should ? What kind of solution ? Being able to get back (when
> appropriate) the registration information (sometimes called the
> credentials) that has been registered at the time of registration by
> the RA. I do not think that it may be practical to get that
> information by paper and in a different format for every CA in the
> world. A protocol (and a schema) might be useful.

I like your approach and asking this question (going back to the
credentials) was at the root of my approach to non-repudiation
last fall. Non-repudiation (as I see it) is a necessary functionality
insofar as it can be used to negate that which might be false (e.g.
a wrong credential) -- not only doing "timestamping"and then
calling that the end-all be-all of non-repudiation (which, BTW,
is not what Tom Ginding says in his RFC for time-stamped non-
repudiation but it is how it stands today because there is no such
protocol).

So, Yes. The missing protocol thus exists IMO and is called non-repudiation
with all its bells and whistles.  In short, the ability to query the validity
of records, not just take them at their face value.

Now, whether this WG charter supports this discussion, I am not sure.
There were some voices last fall (including the WG's co-chair) against
moving any further in this direction than saying "this will be defined
by each CA's CPS".

Comments?

Cheers,

Ed Gerck



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 HAA29193 for <[e-mail]>; Fri, 14 Apr 2000 07:41:27 -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 KAA24337; Fri, 14 Apr 2000 10:45:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b51cdf2742b1@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 14 Apr 2000 10:44:52 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: minutes & slides
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

I will clarify the minutes to note that the editor of the minutes 
[me] is raising the question about whether the protocol in question 
is within scope.

Steve


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 HAA29001 for <[e-mail]>; Fri, 14 Apr 2000 07:39:07 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au (dial06.spyrus.com [207.212.34.126]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA16896; Fri, 14 Apr 2000 07:38:22 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 14 Apr 2000 10:36:05 -0400
To: Stephen Kent <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Permanent identifiers in QC
Cc: [e-mail], [e-mail]
In-Reply-To: <v04220806b51bbb4ae3ce@[171.78.30.107]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I agree with Steve.  Note that the CAT Working Group has defined an 
OTHER-NAME for Kerberos names.

Russ


At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
>Tom,
>
>I have no problems with the sorts of IDs you proposed in your ASN 
>GeneralName Other-Name examples. They seem to be consistent with the 
>arguments that Denis has made for such constructs. However, before we add 
>these to the updated part 1, I think we need more time to explore the 
>utility for these name forms.  The debate on the list shows that there are 
>widely diverse opinions about what such IDs are good for, what scope is 
>feasible/appropriate, etc.  I'd hesitant to hold up progress on the 
>revision to 2459 to add this sort of facility which has been proposed only 
>recently.  That's why several folks have suggested a separate, small 
>document whoch can be advanced separately, and merged into 2459 if there 
>is sufficient, consistent support.
>
>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 HAA28426 for <[e-mail]>; Fri, 14 Apr 2000 07:09:30 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 14 Apr 2000 08:12:42 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 14 Apr 2000 08:12:32 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Global unique identifier
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 HAA28427

Let's remember that the original purpose of X.509 was to 
allow authentication of a user to the directory ITSELF. Since
the DN in the directory was the controlling index used to look up 
all the other stuff, it by definition had to be unique in that directory.
Otherwise the directory would have been a relational database.

Then the PKI community came along and said, "Oh, that's nice" and
appropriated the syntax of X.509 without ever bothering to define the
semantics of what a DN really meant in their new context.

There was sort of a vague hope that a DN would actually be meaningful, 
despite the experience of many deployed directories to the contrary --
directory administrators set up directories for their own convenience, and 
sometimes for the convenience of the larger organization, but hardly
ever for the convenience of external users who might be inclined
to actually RELY on the DN.

So the DN in a directory is primarily Distinguished, i.e., unique within that
directory; and only secondarily, if at all, useful as an actual Name. Case
in point, my own DN or NetWare "context": 
bjueneman.nsrd.prv.novell.

Now there 's a name a mother could really grow to love! But it is unique, at least
within Novell's directory.

Well, 'sez some, how about using a subjectAltName? Good idea, bad execution,
at least so far: subjectAltName=[e-mail]. From the standpoint 
of providing human recognizable information, that's even worse -- it doesn't even
provide a hint to anyone where I work, or in what organization. I guess it's
better than [e-mail], but not by much.

You say that you'd like to have a name that more or less corresponds to
the name I am known by in social circles (no, not that name, the polite one)?
Or you'd like to have something that corresponds to my business card, or maybe 
a residential address, in case you want to send the sheriff after me?

Then put yet another subjectAltName in the certificate, this time a REAL one,
e.g., c=US, o="Novell, Inc." ou="Network Security Department", 
title="Security Architect", cN="Robert R. Jueneman"

Or even more informatively:, if backwards by conventional envelope 
addressing conventions:
c=US, o="Novell, Inc." ou="Network Security Department", s=Utah, l=Provo,
steetAddress="1800 South Novell Place", 
title="Security Architect", cN="Robert R. Jueneman"

Of course, it might have been nice to label these subjectAltNames
more informatively, as a hint to applications that have to display them, e.g.,
rfc822Name=..., organizationalPersonName=..., residentialPersonName=...
but I guess it's too late for that now. "Syntax first, semantics later, if
at all" is our motto, right, boys?

Oh well, maybe we'll get it right eventually. Son of son of 2459, maybe?
Sounds like a Russian patronymic, or maybe an SPKI reference. :-)

Bob


>>> Ed Gerck <[e-mail]> 04/14/00 12:08AM >>>


"Ramsay, Ron" wrote:

> Ed,
>
> I think we all know about the shortcomings of DNs and, as far as X.509 is
> concerned, I don't think we're going to see The Global Directory(TM).

not with that technology, but X.500 is not the end-all be-all of database
development -- new paradigms may always appear.

> My point, and I don't think you answered it, is that a CA can get it names
> from anywhere, the moon perhaps, and there may be clashes in the 'global'
> name space. But, as long as they are unique in all the DNs which have been
> associated with the CA's DN by a certificate, they will be a unique
> identifier for that CA.

We may agree that you are postulating the answer to your question -- so, no
wonder you get it. What you are saying is equivalent to "if names are unique
in a CA, then they are unique in that CA".

Now, let's try a real-world case, where two "Jim Jones" want to get a certificate
from Verisign -- why would the second one need to accept a different DN? More
probably, rather than being forced to accept a different DN he would look for a
different CA, which is of course not acceptable commercially for the first cert vendor.

The bottom line? Semantically, the CA certificate refers to a name; however it does
not denote it. Therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
local matter (local to the CA and its CPS) even if X.500 global directories were used
(X.509v3, Section 11.2). Of course, if the US INS accepts (rather, "uses") UK birth
certificates in order to issue residence permits to the US, this does not mean that the
INS is declaring that such birth certificates are valid in the UK. So, the eventual use
by a CA of a DN supplied by a X.500 directory does not mean that the CA is
declaring that such DN is global -- or, globally unique.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified -- is outside the scope of PKIX and depends
on each CA's CPS.

Cheers,

Ed Gerck





Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA26371 for <[e-mail]>; Fri, 14 Apr 2000 05:00:16 -0700 (PDT)
Received: by mystic1.trustcenter.de; id OAA26933; Fri, 14 Apr 2000 14:02:18 +0200
Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma026925; Fri, 14 Apr 00 14:02:17 +0200
Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id OAA15698; Fri, 14 Apr 2000 14:03:31 +0200 (MET DST)
Message-Id: <3.0.5.32.20000414140331.00c3b690@callisto>
X-Sender: jbr@callisto
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 14 Apr 2000 14:03:31 +0200
To: Volker Hammer <[e-mail]>, "PKIX Mailing List" <[e-mail]>
From: Juergen Brauckmann <[e-mail]>
Subject: Re: Encoding of  "dc" in DNs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id FAA26372

At 18:05 13.04.00 +0200, Volker Hammer wrote:
>Hi,
>
>we use the "dc"-Attribute (domain component) to build distinguished names
in multinational enterprises.
>
>We need to decide how the "dc"-attribute should be encoded in
implementations of the subject distinguished name and issuer dn within
certificates as well as for X.500 directory information tree distinguished
names. RFC2247 (X.500 OID DomainComponent) tells "IA5 string". Some CA
products use "printableString", which is in accordance with recommendation
of "DirectoryString" in X.500 ff. But the latter is only a recommendation
and not enforced, so IA5 string seems to be correct.
>

DC is defined as type "IA5String" in RFC2247. 

"DirectoryString" is an own type which is used in components of DNs. But
not all DN-Components need to be of type DirectoryString. domainComponent
is *not* of type DirectoryString, but of type IA5String, so it is
definitely an error to encode a DC as a PrintableString.

>* Will interop problems in clients arise when using "the other" encoding
(client expects IA5 but find 
>printableString and vice versa)

That depends, of course... . 

Regards,
   Juergen Brauckmann
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[e-mail]
20097 Hamburg 		    http://www.trustcenter.de	


Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25927 for <[e-mail]>; Fri, 14 Apr 2000 04:37:50 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 2318"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Fri, 14 Apr 2000 07:41:36 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <GZXJAPSN>; Fri, 14 Apr 2000 07:41:35 -0400
Content-return: allowed
Date: Fri, 14 Apr 2000 07:41:34 -0400
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: Global unique identifier
To: "'Ed Gerck'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

No, they would not choose different CAs, but the Registration Authority
would be required to add a suffix in order to make the DN different such as
Jim Jones1, Jim Jones2, etc.

Subject: Re: Global unique identifier

Denis Pinkas wrote:

> > Denis,
> >         I am not sure I understand why the DN would not be globally
unique.
>
> This was the ISO dream in the 90's.  :- )
>
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.

Yes, and according to X.509, it may not even be unique within
*the same* CA.  Or, would the Jim Jones have all to choose different CAs?

More on this  in http://www.mcg.org.br/certover.pdf

Cheers,

Ed Gerck


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24388 for <[e-mail]>; Fri, 14 Apr 2000 03:44:33 -0700 (PDT)
Received: from bull.net (itinerant6.frpq.bull.fr [129.184.8.53]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16010; Fri, 14 Apr 2000 12:48:11 +0200
Message-ID: <[e-mail]>
Date: Fri, 14 Apr 2000 12:48:14 +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: Ed Gerck <[e-mail]>
CC: [e-mail]
Subject: Missing Protocol ?
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ed,

Your message was sent to the "Global unique identifier" thread.
Since I am adressing a different topic, I changed the  name of that
thread.

<snip>

There is one point in your E-mail I would like to comment.

> Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
> contained in the certificate and thus assure third parties that some measure of care
> was taken to ensure that this binding is valid for both -- i.e., name and key. However,
> the issue whether a user's DN actually corresponds to identity credentials that are
> *globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
> how such association was verified --   is  outside the scope of PKIX and depends
> on each CA's CPS.

I am not sure that this is really outside the scope of PKIX. If some
judge would like to make the difference between John Smith 22 and
John Smith 23, what can he do ? Nothing that has been standardized
today. :-(  In PKIX we currently do not offer any solution. Maybe we
should ? What kind of solution ? Being able to get back (when
appropriate) the registration information (sometimes called the
credentials) that has been registered at the time of registration by
the RA. I do not think that it may be practical to get that
information by paper and in a different format for every CA in the
world. A protocol (and a schema) might be useful.

Denis


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA19864 for <[e-mail]>; Fri, 14 Apr 2000 02:59:13 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA11533; Fri, 14 Apr 2000 12:02:53 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 14 Apr 2000 12:02:53 +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 MAA29094; Fri, 14 Apr 2000 12:02:50 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA08742; Fri, 14 Apr 2000 12:02:50 +0200 (MET DST)
Date: Fri, 14 Apr 2000 12:02:50 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: minutes & slides
Cc: [e-mail]

> 
> >  >
> >  > DVCS  (P. Sylvester-EdelWeb)
> >  > This is the current version of the document that began as a notary
> >  > protocol from Adams & Zuccherato, and then became the data
> >  > certification service protocols, before editorial responsibility
> >  > shifted. Motivation for this protocol is to support a central
> >  > infrastructure for document security management, e.g., in an intranet
> >  > or extranet environment, or for other long term secure document
> >  > management. The protocol is designed to enable delegation of
> >  > signature verification, notarization, and even certificate use
> >  > controls to a server (vs. and end system). The presentation included
> >  > a number of scenarios motivating the need for the protocol and its
> >  > features. The question arises whether the complex document management
> >  > system features described here is really an infrastructure component
> >  > within the purview of this WG or it is more of an application? (See
> >  > slides for more details.)
> >
> >This question does NOT arise:
> >
> >  >From goals and milestones of the working group:
> >
> >Dec 99 : Complete data certification document
> >
> >The question was: Are 31 pages too complicated to read for people
> >(just 10 pages more than in time stamping).
> >
> >I would not be surprised if someone thinks that
> >31 are definetely not enough to describe a 'complex' protocol.
> 
> If the protocol has become very complex because it attempts to embody 
> features needed to support a rather complete document management 
> scenario, then it may have crossed the boundary from infrastructure 
> protocol to application protocol.  The WG will have to decide on this 
> issue, after reviewing the document.

The question is worth to be discussed in PKIX, and I believe that dvcs
is also woth to be discussed in the smime group, be it for the simple
reason that it uses cms documents,

but here we are talking about minutes of a meeting.

I have made a presentation, and asked some questions (see slides), 
and there was a question from the audience, if I remember it
correctly, please feel free to correct me if I am wrong. 



Received: from hags6104.IS.SHELL.COM (nl01.shell.nl [134.146.4.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA10652 for <[e-mail]>; Thu, 13 Apr 2000 23:53:24 -0700 (PDT)
Received: by hags6104.sipm.shell.nl with Internet Mail Service (5.5.2448.0) id <248MBXJB>; Fri, 14 Apr 2000 08:56:23 +0200
Message-ID: <91F077611570D211B0B40008C7244B330380A1A4@LDMS6001>
From: "Lunow, Pauwl PB SSI-GPCS" <[e-mail]>
To: [e-mail]
Subject: unsubscribe
Date: Fri, 14 Apr 2000 08:55:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"

unsubscribe


Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA07796 for <[e-mail]>; Thu, 13 Apr 2000 23:04:32 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.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, 13 Apr 2000 23:08:17 -0700 (PDT)
Date: Thu, 13 Apr 2000 23:08:26 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: Global unique identifier
To: "Ramsay, Ron" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <[e-mail]>

"Ramsay, Ron" wrote:

> Ed,
>
> I think we all know about the shortcomings of DNs and, as far as X.509 is
> concerned, I don't think we're going to see The Global Directory(TM).

not with that technology, but X.500 is not the end-all be-all of database
development -- new paradigms may always appear.

> My point, and I don't think you answered it, is that a CA can get it names
> from anywhere, the moon perhaps, and there may be clashes in the 'global'
> name space. But, as long as they are unique in all the DNs which have been
> associated with the CA's DN by a certificate, they will be a unique
> identifier for that CA.

We may agree that you are postulating the answer to your question -- so, no
wonder you get it.  What you are saying is equivalent to "if names are unique
in a CA, then they are unique in that CA".

Now, let's try a real-world case, where two "Jim Jones" want to get a certificate
from Verisign -- why would the second one need to accept a different DN?  More
probably, rather than being forced to accept a different DN he would look for a
different CA, which is of course not acceptable commercially for the first cert vendor.

The bottom line?  Semantically, the CA certificate refers to a name; however it does
not denote it.  Therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
local matter (local to the CA and its CPS) even if X.500 global directories were used
(X.509v3, Section 11.2). Of course, if the US INS accepts (rather, "uses") UK birth
certificates in order to issue residence permits to the US, this does not mean that the
INS is declaring that such birth certificates are valid in the UK. So, the eventual use
by a CA of a DN supplied by a X.500 directory does not mean that the CA is
declaring that such DN is global -- or, globally unique.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified --   is  outside the scope of PKIX and depends
on each CA's CPS.

Cheers,

Ed Gerck




Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02740 for <[e-mail]>; Thu, 13 Apr 2000 21:14:48 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <23MVX263>; Fri, 14 Apr 2000 14:20:41 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Ed Gerck <[e-mail]>
Cc: [e-mail]
Subject: RE: Global unique identifier
Date: Fri, 14 Apr 2000 14:21:13 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ed,

I think we all know about the shortcomings of DNs and, as far as X.509 is
concerned, I don't think we're going to see The Global Directory(TM).

My point, and I don't think you answered it, is that a CA can get it names
from anywhere, the moon perhaps, and there may be clashes in the 'global'
name space. But, as long as they are unique in all the DNs which have been
associated with the CA's DN by a certificate, they will be a unique
identifier for that CA.

Jim Heimberg's message was:

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

I'm simply saying that the 'domain' is not something like: All DNs; or: All
DNs under o=Ace Industry,c=US. I'm saying that the domain is: All DNs in
certificates issued by the CA.

Ron.

-----Original Message-----
From: Ed Gerck [mailto:[e-mail]]
Sent: Friday, 14 April 2000 12:56
To: Ramsay, Ron
Cc: [e-mail]; Anders Rundgren; 'Denis Pinkas'; 'Heimberg, Jim'
Subject: Re: Global unique identifier




"Ramsay, Ron" wrote:

> But surely the domain of the CA is the totality of subject DNs in all
> certificates issued by the CA. For two DNs to be the same in the CAs
domain
> they must each be the subject DN of a certificate naming the CA as issuer.

 Section 11.2 of X.509v3, "Management of certificates", states that the
certificate
 allows an association between a name called "unique distinguished name" or
DN
 for the user and  the user's public-key: "A  certificate  associates  the
public key
 and unique distinguished name of the user it describes.", while Section 7
explains
 that such DNs are essential to the security design of X.509:
"Authentication relies
 on each user possessing a unique distinguished name." But, how are such DNs
 assigned? Where are they unique? The DN is  denoted by a NA (Naming
Authority)
 and accepted by a CA (Certification Authority) as unique within the CA's
domain,
 where the CA can double as a NA. It is interesting to  note that the same
user can
 have different DNs in different CAs, or can use the same DN in different
CAs even
 if it is not the first one to use it in a CA -- so different DNs for
different CAs do not
 necessarily mean different users and vice-versa. Further, a DN does not
have to
 contain the user's real-world name or location. Thus, semantically, the CA
 certificate refers to a name; however it does not denote it.

(in http://www.mcg.org.br/cert.htm)

Cheers,

Ed Gerck




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 TAA23891 for <[e-mail]>; Thu, 13 Apr 2000 19:57:40 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) 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, 13 Apr 2000 19:56:49 -0700 (PDT)
Date: Thu, 13 Apr 2000 19:56:23 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: Global unique identifier
To: "Ramsay, Ron" <[e-mail]>
Cc: [e-mail], Anders Rundgren <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Heimberg, Jim'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <[e-mail]>

"Ramsay, Ron" wrote:

> But surely the domain of the CA is the totality of subject DNs in all
> certificates issued by the CA. For two DNs to be the same in the CAs domain
> they must each be the subject DN of a certificate naming the CA as issuer.

 Section 11.2 of X.509v3, "Management of certificates", states that the certificate
 allows an association between a name called "unique distinguished name" or DN
 for the user and  the user's public-key: "A  certificate  associates  the public key
 and unique distinguished name of the user it describes.", while Section 7 explains
 that such DNs are essential to the security design of X.509: "Authentication relies
 on each user possessing a unique distinguished name." But, how are such DNs
 assigned? Where are they unique? The DN is  denoted by a NA (Naming Authority)
 and accepted by a CA (Certification Authority) as unique within the CA's domain,
 where the CA can double as a NA. It is interesting to  note that the same user can
 have different DNs in different CAs, or can use the same DN in different CAs even
 if it is not the first one to use it in a CA -- so different DNs for different CAs do not
 necessarily mean different users and vice-versa. Further, a DN does not have to
 contain the user's real-world name or location. Thus, semantically, the CA
 certificate refers to a name; however it does not denote it.

(in http://www.mcg.org.br/cert.htm)

Cheers,

Ed Gerck





Received: from njnet.edu.cn (carnation.njnet.edu.cn [202.112.23.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23812 for <[e-mail]>; Thu, 13 Apr 2000 19:57:17 -0700 (PDT)
Received: from river ([202.112.25.78]) by njnet.edu.cn (8.9.3/8.9.3) with SMTP id LAA27524 for <[e-mail]>; Fri, 14 Apr 2000 11:00:38 +0800 (CST)
Date: Fri, 14 Apr 2000 01:11:25 +0800
From: Gao Yuhang <[e-mail]>
To: pki_ietf list <[e-mail]>
Subject: pki product report
Message-Id: <38F5FFBD262.A40EYHGAO@carnation>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.24.13

	Please excuse for off-topic. But can anyonehelp me to find
reports on current PKI products,with explanations and comparisions, such
as Baltimore's UniCERT, Netscape's CMS, Microsoft's Certifcate Server?

Thanks,
Hazel
 ______________________________________________
  Miss Yuhang Gao
  Network Center, Computer Dept.
  Southeast University,
  Nanjing, Jiangsu,
  P.R.China
  210096


Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [210.163.32.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA18235 for <[e-mail]>; Thu, 13 Apr 2000 19:16:35 -0700 (PDT)
Received: from mail1.noc.ntt.com (mail1-gw.noc.ntt.com) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id LAA09223 for <[e-mail]>; Fri, 14 Apr 2000 11:20:20 +0900 (JST)
Received: from zakulero by mail1.noc.ntt.com (8.9.3/3.7W) id LAA06842; Fri, 14 Apr 2000 11:20:17 +0900 (JST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5-J (32)
Date: Fri, 14 Apr 2000 11:21:11 +0900
To: [e-mail]
From: Takuya INOUE <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

subscribe
  ___\____ ----------------------------------------
 |        |      NTT Communications Corporation 
 | <>  <> | (( ))      Advanced Business Works
 |   __   | //             Takuya INOUE
 |________|//    [e-mail]
TEL:[phone]    Fax:[phone]
           ----------------------------------------


Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06176 for <[e-mail]>; Thu, 13 Apr 2000 18:03:52 -0700 (PDT)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <23MVXHZ7>; Fri, 14 Apr 2000 11:09:40 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail]
Cc: Anders Rundgren <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Heimberg, Jim'" <[e-mail]>
Subject: RE: Global unique identifier
Date: Fri, 14 Apr 2000 11:10:21 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

But surely the domain of the CA is the totality of subject DNs in all
certificates issued by the CA. For two DNs to be the same in the CAs domain
they must each be the subject DN of a certificate naming the CA as issuer.

There is still a uniqueness problem which is to distinguish between two John
Smiths. For this the CA would require a DN disambiguator.

Ron.

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]]
Sent: Thursday, 13 April 2000 22:21
To: 'Denis Pinkas'; 'Heimberg, Jim'
Cc: [e-mail]
Subject: RE: Global unique identifier


Jim,
You are absolutely right that DNs should be globally unique within their
domain. 
The only problem is that we do not have any means (or do we?) to specify (in
a certificate) a domain 
which may be internal (NULL) to the CA or external (hopefully centrally
registered like IPs, OIDs etc.).   
Anders
----------
From:  Heimberg, Jim [SMTP:[e-mail]]
Sent:  Thursday, April 13, 2000 14:13
To:  'Denis Pinkas'; Anders Rundgren
Cc:  [e-mail]
Subject:  RE: Global unique identifier

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [e-mail]
Subject: Global unique identifier


Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis
 

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders


Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01170; Thu, 13 Apr 2000 14:54:24 -0700 (PDT)
From: [e-mail]
Subject: Warning: PKIX Freeware Library may be withdrawn
To: [e-mail], [e-mail]
X-Mailer: Lotus Notes Build V502_11031999  November 3, 1999
Message-ID: <[e-mail]>
Date: Thu, 13 Apr 2000 17:57:48 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/13/2000 06:01:06 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

I thought I should alert people to a situation evolving concerning the PKIX
Freeware Library that was jointly written by Iris, Lotus, and IBM. The
source code for all but the crypto has been available on
http://web.mit.edu/pfl for domestic distribution and on
http://www.foobar.com/jonah for worldwide distribution for some time. It
excludes crypto functions that are available separately from Cylink.

Included in the PKIX Freeware Library code is some crypto interface code
originally developed by Intel and adapted to this use. Intel recently
announced publicly that they are releasing for free distribution a large
body of crypto interface code that includes a newer version of that
interface. But there are indications that they are also going to declare
the version used by PKIX to no longer be freely distributable.

If that happens, we will be required to pull the code from all posting
sites under our control. I thought I should let people know in case this
affects their plans to embed this code in other products.

The PKIX Freeware Library could be adapted to use the new versions of the
Intel crypto interfaces, or more likely could replace them with direct
interfaces to the Cylink code. But I am not aware of anyone planning to do
that work. If anyone does so, I hope they will post it so that others can
take advantage of it.

     --Charlie Kaufman
     ([e-mail])

Disclaimer: Opinions expressed may not even by mine by the time you read
them, and certainly do not represent those of any other legal entity. It's
also possible that this message is not from me at all, but rather was
forged.



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29150 for <[e-mail]>; Thu, 13 Apr 2000 13:06:12 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.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, 13 Apr 2000 12:48:49 -0700 (PDT)
Date: Thu, 13 Apr 2000 12:48:32 -0700
From: Ed Gerck <[e-mail]>
Subject: Re: Global unique identifier
To: Denis Pinkas <[e-mail]>
Cc: "Heimberg, Jim" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References:  <[e-mail]> <[e-mail]>

Denis Pinkas wrote:

> > Denis,
> >         I am not sure I understand why the DN would not be globally unique.
>
> This was the ISO dream in the 90's.  :- )
>
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.

Yes, and according to X.509, it may not even be unique within
*the same* CA.  Or, would the Jim Jones have all to choose different CAs?

More on this  in http://www.mcg.org.br/certover.pdf

Cheers,

Ed Gerck



Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27582 for <[e-mail]>; Thu, 13 Apr 2000 11:46:06 -0700 (PDT)
Received: from kiel (kiel.antech.de [194.45.12.66]) by rom.antech.de (8.9.3/8.9.3) with SMTP id UAA20931 for <@rom.antech.de:[e-mail]>; Thu, 13 Apr 2000 20:50:04 +0200
Received: from Vigenere.secorvo.de (p3E9BBE3A.dip0.t-ipconnect.de [62.155.190.58]) by kiel (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA23935 for <[e-mail]>; Thu, 13 Apr 2000 20:49:03 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 13 Apr 2000 18:05:05 +0200
To: "PKIX Mailing List" <[e-mail]>
From: Volker Hammer <[e-mail]>
Subject: Encoding of  "dc" in DNs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

we use the "dc"-Attribute (domain component) to build distinguished names in multinational enterprises.

We need to decide how the "dc"-attribute should be encoded in implementations of the subject distinguished name and issuer dn within certificates as well as for X.500 directory information tree distinguished names. RFC2247 (X.500 OID DomainComponent) tells "IA5 string". Some CA products use "printableString", which is in accordance with recommendation of "DirectoryString" in X.500 ff. But the latter is only a recommendation and not enforced, so IA5 string seems to be correct.

Questions:

* Will interop problems in clients arise when using "the other" encoding (client expects IA5 but find printableString and vice versa)

* Products using printableString: will this be corrected in accordance to RFC2247?

* Other recommendations from the list?

Thanks in advance,
Volker Hammer.
--------------------------------------------------------
Dr.-Ing. Volker Hammer
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. [phone], Fax [phone]
E-Mail [e-mail], http://www.secorvo.de
--------------------------------------------------------
PGP-Fingerprint    3C9C AD64 AC6B 64CC  FA6B AE8D 2A5D 462D


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 LAA26627 for <[e-mail]>; Thu, 13 Apr 2000 11:00:34 -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 OAA27690; Thu, 13 Apr 2000 14:02:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220806b51bbb4ae3ce@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 13 Apr 2000 14:02:59 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Permanent identifiers in QC
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tom,

I have no problems with the sorts of IDs you proposed in your ASN 
GeneralName Other-Name examples. They seem to be consistent with the 
arguments that Denis has made for such constructs. However, before we 
add these to the updated part 1, I think we need more time to explore 
the utility for these name forms.  The debate on the list shows that 
there are widely diverse opinions about what such IDs are good for, 
what scope is feasible/appropriate, etc.  I'd hesitant to hold up 
progress on the revision to 2459 to add this sort of facility which 
has been proposed only recently.  That's why several folks have 
suggested a separate, small document whoch can be advanced 
separately, and merged into 2459 if there is sufficient, consistent 
support.

Steve


Received: from comp200.usertrust.com (ip71.reverse.usertrust.com [209.210.188.71] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26004 for <[e-mail]>; Thu, 13 Apr 2000 10:38:46 -0700 (PDT)
Received: by ip71.reverse.usertrust.com with Internet Mail Service (5.5.2650.21) id <H6LFRLBY>; Thu, 13 Apr 2000 10:54:36 -0600
Message-ID: <[e-mail]>
From: Ken Allen <[e-mail]>
To: [e-mail]
Subject: testing
Date: Thu, 13 Apr 2000 10:54:36 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"


Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA25253 for <[e-mail]>; Thu, 13 Apr 2000 10:03:23 -0700 (PDT)
Message-ID: <[e-mail]>
From: Paul Halliden <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 18:08:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

<snip>

>Actually I don't understand how tax authorities can separate 
>the two Delta Companies
>if there are no naming conventions.

Quite simple - In this country (UK) the tax man allocates his own account
number to each.  If both Deltas are actually the same company, it soon
complains when it gets two tax bills.  The tax man can use a mass of
information that exists in the real world to establish whether there really
is one or two and adjust its account numbering scheme accordingly.  The
point is that in real life there are plenty of name collisions which can be
resolved in a given domain provided that domain has control over its naming
convention.

Paul Halliden


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 KAA25026 for <[e-mail]>; Thu, 13 Apr 2000 10:00:47 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 13 Apr 2000 11:04:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Thu, 13 Apr 2000 11:03:55 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Global unique identifier
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_4B128B10.4120CB0C"

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.

--=_4B128B10.4120CB0C
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

That's why most countries use a taxpayer ID.  Even though they aren't =
guaranteed to always be unique across time and space, they reduce the =
possibility that the combination of name and number is not unique to a =
level that is negligible.  Not zero, perhaps, but negligible.

DON'T assume, however, that CAs have restricted geographic coverage, for =
that certainly isn't so.  Europe isn't like the US, and vice versa. We =
fell into that trap within the NADF about 8 years ago, when we assumed =
that monopoly telephone carriers (remember those?)  had territories that =
corresponded to geopolitical boundaries.  Turns out that wasn't true even =
then, and  most certainly isn't now.

I'm sure that VeriSign would be willing to sell you a certificate =
regardless of where you live/reside/are domiciled/are a citizen of/vote/own=
 a second residence/are currently travelling/etc.  For that matter, so =
would we.

Bob

>>> Anders Rundgren <[e-mail]> 04/13/00 08:29AM >>>
Denis,

<snip>

>A CA can nominate the Delta Company from country FR, but another CA
>can nominate another Delta Company from the same country. There
>cannot be an ambiguity on the country name, because the way country
>names are used is well described. For any other level, the
>interpretation is free. Thus there is no way to make sure that the
>two Delta companies are the same, since there is no naming authority
>telling how "Delta Company" should be interpreted or undertsood.

This is perfectly valid in regions where no registration system exists.  =
In country SE
this has been solved in the same way as for persons.  Permanent unique =
IDs.

Actually I don't understand how tax authorities can separate the two Delta =
Companies
if there are no naming conventions.

There are very few global standards for this, but CAs usually have =
restricted geographic coverage.

<snip>

Anders

--=_4B128B10.4120CB0C
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.2614.3401" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV><FONT size=3D1>That's why most countries use a taxpayer ID.&nbsp; =
Even though=20
they aren't guaranteed to always be unique across time and space, they =
reduce=20
the possibility that the combination of name and number is not unique to a =
level=20
that is negligible.&nbsp; Not zero, perhaps, but negligible.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>DON'T assume, however, that CAs have restricted =
geographic=20
coverage, for that certainly isn't so.&nbsp; Europe isn't like the US, and =
vice=20
versa. We fell into that trap within the NADF about 8 years ago, when we =
assumed=20
that monopoly telephone carriers (remember those?)&nbsp; had territories =
that=20
corresponded to geopolitical boundaries.&nbsp; Turns out that wasn't true =
even=20
then, and&nbsp; most certainly isn't now.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>I'm sure that VeriSign would be willing to sell you =
a=20
certificate regardless of where you live/reside/are domiciled/are a =
citizen=20
of/vote/own a second residence/are currently travelling/etc.&nbsp; For =
that=20
matter, so would we.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D1>Bob</FONT><BR><BR>&gt;&gt;&gt; Anders Rundgren=20
&lt;[e-mail]&gt; 04/13/00 08:29AM=20
&gt;&gt;&gt;<BR>Denis,<BR><BR>&lt;snip&gt;<BR><BR>&gt;A CA can nominate =
the=20
Delta Company from country FR, but another CA<BR>&gt;can nominate another =
Delta=20
Company from the same country. There<BR>&gt;cannot be an ambiguity on =
the=20
country name, because the way country<BR>&gt;names are used is well =
described.=20
For any other level, the<BR>&gt;interpretation is free. Thus there is no =
way to=20
make sure that the<BR>&gt;two Delta companies are the same, since there is =
no=20
naming authority<BR>&gt;telling how "Delta Company" should be interpreted =
or=20
undertsood.<BR><BR>This is perfectly valid in regions where no registration=
=20
system exists.&nbsp; In country SE<BR>this has been solved in the same way =
as=20
for persons.&nbsp; Permanent unique IDs.<BR><BR>Actually I don't understand=
 how=20
tax authorities can separate the two Delta Companies<BR>if there are no =
naming=20
conventions.<BR><BR>There are very few global standards for this, but =
CAs=20
usually have restricted geographic=20
coverage.<BR><BR>&lt;snip&gt;<BR><BR>Anders<BR><BR><BR></DIV></BODY></HTML>=


--=_4B128B10.4120CB0C--


Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24268 for <[e-mail]>; Thu, 13 Apr 2000 09:20:19 -0700 (PDT)
Received: from bull.net (itinerant3.frpq.bull.fr [129.184.8.57]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA27370; Thu, 13 Apr 2000 18:23:39 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Apr 2000 18:23:42 +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: Janus Liebregts <[e-mail]>
CC: "Heimberg, Jim" <[e-mail]>, [e-mail], "Valkenburg, Peter" <[e-mail]>
Subject: Re: Global unique identifier
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Denis Pinkas wrote:
> >
> > > Denis,
> > >         I am not sure I understand why the DN would not be globally unique.
> >
> > This was the ISO dream in the 90's.  :- )
> 
> This is still our dream in the Netherlands. In our policy we only
> certify DN's which are stored in our ldap-DIT:
> http://ldap.surfnet.nl:8888/ The DN's certificates are stored in their
> ldap-entries.

You give water to Anders's mill. :-)

In your case you would say that the naming authority is something
like: "Netherlands ldap-DIT".

Introducing that component as a part of the DN may allow you to have
that uniqueness. However ... the syntax of the name would be
correct, but the semantics would not change, ... unless in the CP
policy (which is not easily universally machine processable) you
state that the presence of that component implies that the name that
follows it is unique for the Netherlands.

Anders was looking, I guess, for generic way to express that
uniqueness (i.e. not using the CP). There would be various solutions
for that, including an extension to the DN syntax.

Regards,

Denis 

> For the c=nl we can guarantee names are unique, in a european effort we
> try to couple national ldap-infrastructures see:
> http://www.terena.nl/task-forces/ http://www.dante.net
> 
> on a local base we think about delegating the c=nl, o=... to the dutch
> Chamber of Commerce and the c=nl, l=... to the ministry responsible for
> the dutch localities.
> 
> I think naming is a policy matter.
> 
> Janus Liebregts
> SURFnet
> The Netherlands
> 
> >
> > A CA can nominate the Delta Company from country FR, but another CA
> > can nominate another Delta Company from the same country. There
> > cannot be an ambiguity on the country name, because the way country
> > names are used is well described. For any other level, the
> > interpretation is free. Thus there is no way to make sure that the
> > two Delta companies are the same, since there is no naming authority
> > telling how "Delta Company" should be interpreted or undertsood.
> >
> > > If it is unique within its domain, there should not be duplication of
> > > domains and thus it becomes globally unique.
> >
> > No. As explained above, unique within the CA domain does not mean
> > universally unique across all CAs.
> >
> > > Please let me know if there is some reason that this is not true.
> >
> > Done.
> >
> > Regards,
> >
> > Denis


Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22610 for <[e-mail]>; Thu, 13 Apr 2000 07:40:41 -0700 (PDT)
Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 12fkqm-0006np-00; Thu, 13 Apr 2000 16:44:08 +0200
Received: from surfnet.nl (janus1.sec.nl [192.87.109.32]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.7) with ESMTP id QAA24884; Thu, 13 Apr 2000 16:44:08 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 13 Apr 2000 16:44:08 +0200
From: Janus Liebregts <[e-mail]>
Organization: SURFnet bv
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: "Heimberg, Jim" <[e-mail]>, [e-mail], "Valkenburg, Peter" <[e-mail]>
Subject: Re: Global unique identifier
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> > Denis,
> >         I am not sure I understand why the DN would not be globally unique.
> 
> This was the ISO dream in the 90's.  :- )

This is still our dream in the Netherlands. In our policy we only
certify DN's which are stored in our ldap-DIT:
http://ldap.surfnet.nl:8888/ The DN's certificates are stored in their
ldap-entries.
For the c=nl we can guarantee names are unique, in a european effort we
try to couple national ldap-infrastructures see:
http://www.terena.nl/task-forces/ http://www.dante.net

on a local base we think about delegating the c=nl, o=... to the dutch
Chamber of Commerce and the c=nl, l=... to the ministry responsible for
the dutch localities.

I think naming is a policy matter. 

Janus Liebregts
SURFnet
The Netherlands

> 
> A CA can nominate the Delta Company from country FR, but another CA
> can nominate another Delta Company from the same country. There
> cannot be an ambiguity on the country name, because the way country
> names are used is well described. For any other level, the
> interpretation is free. Thus there is no way to make sure that the
> two Delta companies are the same, since there is no naming authority
> telling how "Delta Company" should be interpreted or undertsood.
> 
> > If it is unique within its domain, there should not be duplication of
> > domains and thus it becomes globally unique.
> 
> No. As explained above, unique within the CA domain does not mean
> universally unique across all CAs.
> 
> > Please let me know if there is some reason that this is not true.
> 
> Done.
> 
> Regards,
> 
> Denis
> 
> > Jim
> >
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 12, 2000 9:04 AM
> > To: Anders Rundgren
> > Cc: [e-mail]
> > Subject: Global unique identifier
> >
> > Anders,
> >
> > In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
> > each subject entity certified by the one CA as defined by the issuer
> > name field". There is no requirement to make the DN unique across
> > multiple CAs.
> >
> > Adding this requirement would either break RFC 2459 or build
> > something very different. Today, when a DN is used, it is a DN from
> > a given CA. Each CA may build its own tree of names. A sequence of
> > relative names forming a distinguished name from CA 1 and the same
> > sequence of names forming the same distinguished name from a CA 2 do
> > not necessarilly need to point to the same entity. So the name of
> > the CA has to be used in addition to every DN in order to make the
> > difference. In other words, if two DNs from two different CAs are
> > identical, this does not mean that the two entities are necessarilly
> > identical. This was supposed to be true, ten years ago, when the
> > Directory (with a capital D) was defined, but this is no more the
> > case today.
> >
> > Now let us make the assumption that we introduce an explicit naming
> > domain information (or naming authority information) in some form of
> > name. Note that this topic does not apply only to the permanent
> > identifier but could apply as well to the DN: this is why it should
> > be discussed on a different thread.
> >
> > As a conclusion, this particular aspect should be discussed on a
> > separate thread (I have called it "Global unique identifier" but you
> > may use any other name you prefer, as long as it is not "permanent
> > identifier").
> >
> > Denis
> >
> >
> > > Denis,
> > > <snip>
> > > >Please, do not make the story more complicated than requested. The
> > > >permanent identifier is a name of the subject, unique within the
> > > >issuer domain, that is not reused over time for another subject. The
> > > >name is only unique within the issuer domain (i.e. CA). Making the
> > > >name unique across different CAs would break the current PKIX model.
> > >
> > > The requirement stated by Tom is very valid (I have raised it on this list
> > a countless number of times)
> > > and applies 100% to what is supposed to be happening any old day here in
> > Sweden.
> > > I.e. a number of competing CAs issue certificates to a Naming Domain they
> > do not govern themselves.
> > > These identity certificates are supposed to be totally interchangeable as
> > their physical counterparts
> > > have been the last 30 years or so.  By the use of a permanent ID and
> > (implicit) naming domain.
> > >
> > > I.e. any improvement or addition to QC must address the naming domain
> > question as well.
> > > Or as Tom prefers.  The naming authority.
> > >
> > > Anders


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22261 for <[e-mail]>; Thu, 13 Apr 2000 07:27:16 -0700 (PDT)
Received: from HYDRA ([195.198.186.97]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id QAA32492; Thu, 13 Apr 2000 16:33:14 +0200
Received: by HYDRA with Microsoft Mail id <01BFA565.7B6108E0@HYDRA>; Thu, 13 Apr 2000 16:29:46 +0200
Message-ID: <01BFA565.7B6108E0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "Heimberg, Jim" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 16:29:45 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

<snip>

>A CA can nominate the Delta Company from country FR, but another CA
>can nominate another Delta Company from the same country. There
>cannot be an ambiguity on the country name, because the way country
>names are used is well described. For any other level, the
>interpretation is free. Thus there is no way to make sure that the
>two Delta companies are the same, since there is no naming authority
>telling how "Delta Company" should be interpreted or undertsood.

This is perfectly valid in regions where no registration system exists.  In country SE
this has been solved in the same way as for persons.  Permanent unique IDs.

Actually I don't understand how tax authorities can separate the two Delta Companies
if there are no naming conventions.

There are very few global standards for this, but CAs usually have restricted geographic coverage.

<snip>

Anders




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 HAA22102 for <[e-mail]>; Thu, 13 Apr 2000 07:26:13 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id RAA19830 for <[e-mail]>; Thu, 13 Apr 2000 17:32:32 +0300
Date: Thu, 13 Apr 2000 17:29:49 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-new-part1-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello ietf-pkix!

  id-ce-holdInstructionCode and id-ce-instructionCode are aliases also.

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




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 HAA21829 for <[e-mail]>; Thu, 13 Apr 2000 07:25:06 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id RAA15614 for <[e-mail]>; Thu, 13 Apr 2000 17:31:25 +0300
Date: Thu, 13 Apr 2000 17:28:42 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-new-part1-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello ietf-pkix!

  I've also found three aliases for a same OID in
  draft-ietf-pkix-new-part1-01.txt:

id-ce-cRLReason
id-ce-cRLReasons
id-ce-reasonCode
  
  

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




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 HAA21688; Thu, 13 Apr 2000 07:22:15 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id RAA24796; Thu, 13 Apr 2000 17:28:34 +0300
Date: Thu, 13 Apr 2000 17:25:51 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: id-ct-compressedData vs id-ct-publishCert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello!

  id-ct-compressedData from draft-ietf-smime-compression-00.txt and
  id-ct-publishCert from draft-ietf-smime-certdist-04.txt has same OID

  In draft-ietf-smime-compression-00.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 3

  In draft-ietf-smime-certdist-04.txt, it is defined as

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 3

  which is same. I've found it confusing; I would like go get a solution
  from the authors of drafts above mentioned.


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




Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21146 for <[e-mail]>; Thu, 13 Apr 2000 06:57:10 -0700 (PDT)
Received: from bull.net (itinerant3.frpq.bull.fr [129.184.8.57]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA40112; Thu, 13 Apr 2000 16:00:37 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Apr 2000 16:00:39 +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: "Heimberg, Jim" <[e-mail]>
CC: [e-mail]
Subject: Re: Global unique identifier
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Denis,
>         I am not sure I understand why the DN would not be globally unique.

This was the ISO dream in the 90's.  :- ) 

A CA can nominate the Delta Company from country FR, but another CA
can nominate another Delta Company from the same country. There
cannot be an ambiguity on the country name, because the way country
names are used is well described. For any other level, the
interpretation is free. Thus there is no way to make sure that the
two Delta companies are the same, since there is no naming authority
telling how "Delta Company" should be interpreted or undertsood.

> If it is unique within its domain, there should not be duplication of
> domains and thus it becomes globally unique.  

No. As explained above, unique within the CA domain does not mean
universally unique across all CAs.

> Please let me know if there is some reason that this is not true.

Done. 

Regards,

Denis

> Jim
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 12, 2000 9:04 AM
> To: Anders Rundgren
> Cc: [e-mail]
> Subject: Global unique identifier
> 
> Anders,
> 
> In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
> each subject entity certified by the one CA as defined by the issuer
> name field". There is no requirement to make the DN unique across
> multiple CAs.
> 
> Adding this requirement would either break RFC 2459 or build
> something very different. Today, when a DN is used, it is a DN from
> a given CA. Each CA may build its own tree of names. A sequence of
> relative names forming a distinguished name from CA 1 and the same
> sequence of names forming the same distinguished name from a CA 2 do
> not necessarilly need to point to the same entity. So the name of
> the CA has to be used in addition to every DN in order to make the
> difference. In other words, if two DNs from two different CAs are
> identical, this does not mean that the two entities are necessarilly
> identical. This was supposed to be true, ten years ago, when the
> Directory (with a capital D) was defined, but this is no more the
> case today.
> 
> Now let us make the assumption that we introduce an explicit naming
> domain information (or naming authority information) in some form of
> name. Note that this topic does not apply only to the permanent
> identifier but could apply as well to the DN: this is why it should
> be discussed on a different thread.
> 
> As a conclusion, this particular aspect should be discussed on a
> separate thread (I have called it "Global unique identifier" but you
> may use any other name you prefer, as long as it is not "permanent
> identifier").
> 
> Denis
> 
> 
> > Denis,
> > <snip>
> > >Please, do not make the story more complicated than requested. The
> > >permanent identifier is a name of the subject, unique within the
> > >issuer domain, that is not reused over time for another subject. The
> > >name is only unique within the issuer domain (i.e. CA). Making the
> > >name unique across different CAs would break the current PKIX model.
> >
> > The requirement stated by Tom is very valid (I have raised it on this list
> a countless number of times)
> > and applies 100% to what is supposed to be happening any old day here in
> Sweden.
> > I.e. a number of competing CAs issue certificates to a Naming Domain they
> do not govern themselves.
> > These identity certificates are supposed to be totally interchangeable as
> their physical counterparts
> > have been the last 30 years or so.  By the use of a permanent ID and
> (implicit) naming domain.
> >
> > I.e. any improvement or addition to QC must address the naming domain
> question as well.
> > Or as Tom prefers.  The naming authority.
> >
> > Anders


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 GAA20705; Thu, 13 Apr 2000 06:44:25 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id QAA01818; Thu, 13 Apr 2000 16:50:24 +0300
Date: Thu, 13 Apr 2000 16:47:40 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/17)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Subject: duplicate aliases of the same OID in draft-ietf-pkix-new-part1-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello!

  I've found duplicate aliases of the same OID in
  draft-ietf-pkix-new-part1-01.txt

  sha-1WithRSAEncryption (section 7.2.1) and sha1WithRSAEncryption
  (elsewhere).

  The first variant was also found in rfc2632, rfc2633 (along with the
  second variant).

  Second variant was also found in draft-ietf-smime-certdist-04.txt,
  draft-ietf-smime-examples-03.txt and rfc2633.

  There are also numerous duplicate OID aliases, for example
  PKCS#9-relaeted; they are different in PKIX documents, S/MIME
  documents and PKCS#9 itself.
  
  I've found it writing my ASN.1 code to work with S/MIME messages and
  X.509 certificates. Having multiple names of a same OIDS is much worse
  than having one, I think both workgroups should take care of that.
  
-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA18311 for <[e-mail]>; Thu, 13 Apr 2000 05:19:08 -0700 (PDT)
Received: from HYDRA ([195.198.186.97]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id OAA19117; Thu, 13 Apr 2000 14:24:49 +0200
Received: by HYDRA with Microsoft Mail id <01BFA553.8B3F6700@HYDRA>; Thu, 13 Apr 2000 14:21:22 +0200
Message-ID: <01BFA553.8B3F6700@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Heimberg, Jim'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Global unique identifier
Date: Thu, 13 Apr 2000 14:21:21 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Jim,
You are absolutely right that DNs should be globally unique within their domain. 
The only problem is that we do not have any means (or do we?) to specify (in a certificate) a domain 
which may be internal (NULL) to the CA or external (hopefully centrally registered like IPs, OIDs etc.).   
Anders
----------
From:  Heimberg, Jim [SMTP:[e-mail]]
Sent:  Thursday, April 13, 2000 14:13
To:  'Denis Pinkas'; Anders Rundgren
Cc:  [e-mail]
Subject:  RE: Global unique identifier

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [e-mail]
Subject: Global unique identifier


Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis
 

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders



Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16998 for <[e-mail]>; Thu, 13 Apr 2000 05:09:11 -0700 (PDT)
Received: from gscex01.gsc.gte.com ("port 3433"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Thu, 13 Apr 2000 08:12:43 -0400 (EDT)
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <GZXJAA3X>; Thu, 13 Apr 2000 08:12:42 -0400
Content-return: allowed
Date: Thu, 13 Apr 2000 08:12:40 -0400
From: "Heimberg, Jim" <[e-mail]>
Subject: RE: Global unique identifier
To: "'Denis Pinkas'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

Denis,
	I am not sure I understand why the DN would not be globally unique.
If it is unique within its domain, there should not be duplication of
domains and thus it becomes globally unique.  Please let me know if there is
some reason that this is not true.
Jim

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, April 12, 2000 9:04 AM
To: Anders Rundgren
Cc: [e-mail]
Subject: Global unique identifier


Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis
 

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list
a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in
Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they
do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as
their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and
(implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain
question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders


Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA02292 for <[e-mail]>; Thu, 13 Apr 2000 00:32:24 -0700 (PDT)
Received: from nma.com (adsl-63-204-17-82.dsl.snfc21.pacbell.net) by mta5.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, 13 Apr 2000 00:35:31 -0700 (PDT)
Date: Thu, 13 Apr 2000 00:35:27 -0700
From: Ed Gerck <[e-mail]>
Subject: Newsletter on Internet voting, privacy and security issues
To: "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en

List:

I would like to extend an invitation to the PKIX list to read "The 
Bell" -- the first newsletter entirely dedicated to Internet voting and 
collaborative decision-making in Internet protocols (including the use 
of digital certificates and the resulting security/privacy concerns from
potentially non-anonymous voting). Electronic and hard copy subscriptions 
are available at www.thebell.net.

Safevote [1] is sponsoring the newsletter as an open forum.  Regarding 
the name "The Bell", the idea was to use the image of a bell because 
mission bells were used in colonial California for telling time, 
announcing events, and for passing on news from one city to another. 
This newsletter intends to serve similar purposes and is also a public 
service open and free for all who may want it.

With monthly 16-page issues, the "The Bell" will focus on privacy, 
security and technology used in Internet voting. 

In Internet tradition, the newsletter is available free over the 
Internet (PDF format), or at an annual cost of $30 for first class 
mail delivery in hard copy.   The first issue contains an extensive 
marketing study of the year 2000 U.S. public elections market - a 
study that will be serialized in upcoming issues.  It also includes 
an article on today's public voting systems used in the United States 
by election expert Roy G. Saltman and an essay by myself outlining the
need for a strong separation between identification and authentication
in order to ensure fair Internet voting protocols.

Internet voting and its potential impact on society will increasingly
call upon us to understand and keep abreast of the latest developments 
in various fields of work. As a developer in this market, I see a 
widening gap between the 100-year-old voting technologies in use today 
and what Internet voting needs to take into account. The Bell is 
dedicated to help fill this gap -- perhaps with your help as well.

Cheers,

Ed Gerck

[1] Safevote (www.safevote.com) is a founding member of the Internet 
Voting Technology Alliance (www.ivta.org) and develops OEM (Original 
Equipment Manufacturer) systems for Internet voting, polling, public 
elections, bidding, consensus assessment and other Internet decision-
making applications. The Bell is edited at Safevote. The May 2000 issue 
is now available at the "The Bell" Web site, www.thebell.net


Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [210.163.32.53]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26070 for <[e-mail]>; Wed, 12 Apr 2000 22:39:47 -0700 (PDT)
Received: from mail1.noc.ntt.com (mail1-gw.noc.ntt.com) by mail1.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id OAA08043; Thu, 13 Apr 2000 14:43:26 +0900 (JST)
Received: from zakulero by mail1.noc.ntt.com (8.9.3/3.7W) id OAA27339; Thu, 13 Apr 2000 14:43:26 +0900 (JST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5-J (32)
Date: Thu, 13 Apr 2000 14:44:21 +0900
To: [e-mail], [e-mail], [e-mail]
From: Takuya INOUE <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

subscribe




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 PAA21917; Wed, 12 Apr 2000 15:45:16 -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 SAA07770; Wed, 12 Apr 2000 18:48:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220812b51aac226d0c@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <v0422081cb51948169128@[171.78.30.107]> <v0422081cb51948169128@[171.78.30.107]> <[e-mail]>
Date: Wed, 12 Apr 2000 18:42:10 -0400
To: Paul Hoffman / IMC <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: document status portion of the minutes, from Warwick
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Paul,

You're right.  We'll fix the document status part of the minutes.

Steve


Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21368 for <[e-mail]>; Wed, 12 Apr 2000 15:24:56 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Wed, 12 Apr 2000 15:29:13 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: document status portion of the minutes, from Warwick
In-Reply-To: <v04220810b51aa2c63a11@[171.78.30.107]>
References: <v0422081cb51948169128@[171.78.30.107]> <v0422081cb51948169128@[171.78.30.107]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:02 PM 4/12/00 -0400, Stephen Kent wrote:
>ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
>         - Finished - will be folded into Revised Part 1

This doesn't match what we agreed to in the meeting, as is reflected in 
Steve's minutes. The words from the minutes are "There was prior agreement 
to move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to remove 
section 7 and combine it with the ECDSA document to create a new PKIX 
document, devoted to algorithms."

--Paul Hoffman, Director
--Internet Mail Consortium



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 PAA20846 for <[e-mail]>; Wed, 12 Apr 2000 15:05:21 -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 SAA05244 for <[e-mail]>; Wed, 12 Apr 2000 18:08:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220810b51aa2c63a11@[171.78.30.107]>
In-Reply-To: <v0422081cb51948169128@[171.78.30.107]>
References: <v0422081cb51948169128@[171.78.30.107]>
Date: Wed, 12 Apr 2000 18:02:20 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: document status portion of the minutes, from Warwick
Content-Type: multipart/alternative; boundary="============_-1256545091==_ma============"

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

PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)
- Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
- Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
- Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
- Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
- Approved as Proposed Standard
OCSP (RFC 2560)
- Approved as Proposed Standard
CMP (RFC 2510)
- Approved as Proposed Standard
CRMF (RFC 2511)
-Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
	- Approved as Informational RFC
CMC (draft-ietf-pkix-cmc-05.txt)
- Approved to Proposed - In RFC Editor processing
Diffie-Hellman POP (draft-ietf-pkix-dhpop-02.txt)
	- In the AD's hands?

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-01.txt)
ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
	- Finished - will be folded into Revised Part 1
Revised CMP (draft-ietf-pkix-rfc2510bis.00)
Qualified Certificates (draft-ietf-pkix-qc-03.txt)
	- WG Last Call pending closure
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-06.txt)
	- Approved by WG - ready for forwarding to IESG
Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)
Attribute Certificate Profile for Authorization 
(draft-ietf-pkix-ac509prof-02.txt)
Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)
DCS (draft-ietf-pkix-dcs-04.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-02.txt)
OCSP Extensions (draft-ietf-pkix-ocspx.txt) - posted on IMC site
CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)
CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

--============_-1256545091==_ma============
Content-Type: text/enriched; charset="us-ascii"

<fontfamily><param>Courier_New</param><bigger>PKIX COMPLETED DOCUMENTS


PKIX Cert/CRL Profile (RFC 2459)

- Approved as Proposed Standard

KEA Algorithms for Profile (RFC 2528)

- Approved as Informational RFC

HTTP/FTP Operations (RFC 2585) 

- Approved as Proposed Standard

LDAP V2 Operational Protocols (RFC 2559)

- Approved as Proposed Standard

LDAP V2 Schema (RFC 2587)

- Approved as Proposed Standard

OCSP (RFC 2560)

- Approved as Proposed Standard

CMP (RFC 2510)

- Approved as Proposed Standard

CRMF (RFC 2511)

-Approved as Proposed Standard

Certificate Policy/Practices Guideline (RFC 2527)

	- Approved as Informational RFC

CMC (draft-ietf-pkix-cmc-05.txt)

- Approved to Proposed - In RFC Editor processing

Diffie-Hellman POP (draft-ietf-pkix-dhpop-02.txt)

	- In the AD's hands?


PKIX WORK IN PROGRESS


Revised Profile (draft-ietf-pkix-new-part1-01.txt)

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)

	- Finished - will be folded into Revised Part 1

Revised CMP (draft-ietf-pkix-rfc2510bis.00)

Qualified Certificates (draft-ietf-pkix-qc-03.txt)

	- WG Last Call pending closure

PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)

Time Stamp (draft-ietf-pkix-time-stamp-06.txt)

	- Approved by WG - ready for forwarding to IESG

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization
(draft-ietf-pkix-ac509prof-02.txt)

Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-04.txt)

Simple Certificate Validation Protocol (SCVP)
(draft-ietf-pkix-scvp-02.txt) 

OCSP Extensions (draft-ietf-pkix-ocspx.txt) - posted on IMC site

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)
</bigger></fontfamily>

--============_-1256545091==_ma============--


Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18779; Wed, 12 Apr 2000 13:36:35 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Wed, 12 Apr 2000 13:40:53 -0700
To: "Christopher Williams" <[e-mail]>, "PKIX Mailing List" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Format of error text
In-Reply-To: <001301bfa4b0$3bc30860$0100a8c0@darxstar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:53 PM 4/12/00 +0100, Christopher Williams wrote:
>The specification states:
>
>"-- text encoded as UTF-8 String [RFC2279] (note:  each UTF8String
>   -- SHOULD include an RFC 1766 language tag to indicate the
>   -- language of the contained text -- see [RFC2482] for details)"
>
>Does this mean something like the following:
>
>"<en-uk> Unexpected PKI message"?

The actual octets in the UTF-8 string would be:

f3a081a5 f3a081ae f3a080ad f3a081b5 f3a081ab 
556e6578   ....................Unex
70656374 65642050 4b49206d 65737361 6765                pected PKI message

Having said this, I think that the SHOULD in the above section is probably 
overstated. I say this as someone who previously lobbied for language 
tagging. The general feeling about language tags these days is that they 
are only needed for machine processing, such as text-to-speech synthesizers 
and spelling checkers. It might be good if draft-ietf-pkix-rfc2510bis 
changed this from a SHOULD to a MAY.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18198; Wed, 12 Apr 2000 13:23:53 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJM7DD>; Wed, 12 Apr 2000 16:27:03 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'SMIME WG'" <[e-mail]>, [e-mail]
Subject: SNACC ASN.1 Freeware Release & Mail List
Date: Wed, 12 Apr 2000 16:27:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
delivered an enhanced version of the freeware SNACC v1.3 rev 0.07 Abstract
Syntax Notation.1 (ASN.1) Compiler and Library.  In past releases, VDA
enhanced the C++ version of the SNACC library to implement the Distinguished
Encoding Rules (DER).  In the new release, VDA enhanced the C and C++
versions of the SNACC library to support PrintableString, TeletexString,
NumericString, IA5String, 
VisibileString, BMPString, UniversalString and UTF8String character string
types.  We added an optional function to SNACC that can be used to convert
ASN.1 OCTET STRINGs to single- or multi-byte character strings (as
appropriate).  This is needed to support the RFC 2459 PKIX requirements.
The SNACC enhancement is completely optional and does not impact existing
code that uses SNACC.  The SNACC library decodes an object as it always has.
If the application/library needs the ASN.1 OCTET STRINGs converted to
character strings, then it calls the new SNACC function/class to perform the
conversion.  If an application/library does not need the ASN.1 OCTET STRINGs
converted, then it does not need to call the conversion function/classes and
can use the SNACC-generated structures/classes as always.  

The VDA-enhanced SNACC compiler and C++ library is available along with the
S/MIME Freeware Library (SFL)
<http://www.armadillo.huntsville.al.us/software/smime> that uses SNACC to
implement the S/MIME v3 set of specifications.  The snacc1_6VDA.zip file
contains the SNACC v1.3 rev 0.07 ASN.1 Compiler and C++ Library source code
compilable for Unix and MS Windows NT/95/98/2000.   

The VDA-enhanced SNACC C library is available along with the freeware
Certificate Management Library (CML)
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html)> that
uses SNACC to implement the 1997 X.509 Recommendation and RFC 2459.  The
CML17sr.tar.Z file includes the source code for the CML and VDA-enhanced
SNACC C library compilable for Unix and MS Windows NT/95/98/2000. 

We plan to consolidate the enhancements made by VDA to the C and C++
versions of the SNACC source code into a single baseline that can be
delivered in a single tar/zip file.

In the new release, we also corrected a bug in the DEC_LOAD_ANYBUF macro.
We changed "bytesDecoded" to "bytesDecodedXX" to avoid conflict other SNACC
uses of the "bytesDecoded" variable.  We also enhanced the AsnOid method so
that it accepts a dynamic number of components within an object identifier. 

SNACC implements the majority of ASN.1 encoding/decoding rules.  SNACC does
not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to be
used to produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note that
many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1
syntax modules which can be directly compiled using SNACC.

The SNACC ASN.1 library is totally unencumbered as stated in the SFL Public
License.  All source code for the VDA-enhanced SNACC software is being
provided at no cost and with no financial limitations regarding its use and
distribution.  Organizations can use the VDA-enhanced SNACC software without
paying any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established a SNACC web page
<http://www.imc.org/imc-snacc/>.  The IMC has also established a SNACC mail
list which is used to: distribute information regarding SNACC releases;
discuss SNACC-related issues; and provide a means for SNACC users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-snacc mail list is at the IMC web site listed above.

VDA welcomes all feedback regarding the VDA-enhanced SNACC software.  If
bugs are reported, then VDA will investigate each reported bug and, if
required, will produce a patch or an updated release of the software to
repair the bug.  We recommend that comments should be sent to the imc-snacc
mail list.  We will respond to all messages on that list.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 



Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17947 for <[e-mail]>; Wed, 12 Apr 2000 13:20:32 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id <GFRJM7CH>; Wed, 12 Apr 2000 16:23:42 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: v1.7 Certificate Management Library & Mail List 
Date: Wed, 12 Apr 2000 16:23:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

J. G. Van Dyke and Associates (VDA), a Wang Government Services Company, has
delivered the freeware Version 1.7 Certificate Management Library (CML)
software and Application Programming Interface (API).  An enhanced version
of the SNACC ASN.1 C library has been delivered with the v1.7 CML.  The v1.7
CML and enhanced SNACC source code is available from the Fortezza
Developer's CML Page
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html>.  

The CML implements the 1997 X.509 certification path processing rules and
meets SDN.706 requirements.  It (optionally) provides local cache management
functions and (optionally) obtains data objects using LDAP v2.  It can
(optionally) be used in conjunction with the v1.31 Certificate Path
Development Library (CPDL) developed by CygnaCom Solutions 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 Digital Signature Algorithm (DSA) and
RSA.   

The v1.7 CML includes the following enhancements (compared with the v1.6 CML
release):

1) Tested with the SNACC C++ library, Crypto Token Interface Libraries
(CTIL) and LibCert Dynamically Linked Libraries (DLL) delivered with the
v1.6 S/MIME Freeware Library (SFL) available from the Fortezza Developer's
S/MIME Page <http://www.armadillo.huntsville.al.us/software/smime>.

2) Enhanced CML API and software to add function to validate generic signed
data (using SIGNED macro).

3) Added functionality to set LDAP settings, trusted certificates, and a
validated public key cache on a per session basis.

4) Fixed uninitialized pointer problem on Extended Key Usage extensions, and
the freeing of the Extended Key Usage extension.

5) Fixed memory leak in freeing of a EncObject_LL.

6) Fixed memory leak in asn-any.c (line 175).

7) Fixed memory leaks in  CMU_GetDistPts().

8) Added the UID attribute to SNACC library.

9) Enhanced the CMU_FilterRemoteCertsList() function to perform certificate
filtering after LDAP retrieval.

10) Enhanced the setting of the CRL/ARL type in the CML provided callback
function, and set correctly the location flag in the CML provided callback.

11) Corrected the CRL Issuing Distribution Point processing logic.

12) Enhanced CML to automatically search the directory using LDAP for a
current certificate or CRL when the local CRL or Certificate has expired, if
the application has specified "search until found".

13) Tested CML with C and C++ versions of SNACC ASN.1 library that have been
enhanced to support PrintableString, TeletexString, NumericString,
IA5String, VisibileString, BMPString, UniversalString and UTF8String
character string types.  An optional function was added to SNACC to convert
ASN.1 OCTET STRINGs to single- or multi-byte character strings (as
appropriate).  The C version of the enhanced SNACC library is included in
the CML17sr.tar.Z file.  The C++ version of the enhanced SNACC library is
available with the SFL.


The following v1.7 CML files are available from the Fortezza Developer's CML
Page:
CMLv17win.zip: Windows DLLs 
CML17so.tar.Z: Solaris Libraries 
CML17sr.tar.Z: Source for CML and SNACC C library, includes Windows project
files 
CMv1_7api.doc, CMv1_7api.pdf: MS Word and Adobe PDF versions of v1.7 CML API
document
cml17data.zip: test certs used to test the CML 
readme.txt: Instructions for installing and using the CML

VDA welcomes all feedback regarding the CML software and documents.  If bugs
are reported, then VDA 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.  VDA 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.7 CML uses the VDA-enhanced SNACC v1.3 ASN.1 Library to encode/decode
objects.  VDA has successfully tested the v1.7 CML with the SNACC and CTIL
DLLs delivered in conjunction with the v1.6 SFL.  Source code for the
VDA-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.7 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 CML17sr.tar.Z file includes the CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

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 Internet Mail Consortium (IMC) has established a CML web page
<http://www.imc.org/imc-cml/>.  The IMC has also established a CML mail list
which is used to: distribute information regarding CML releases; discuss
CML-related issues; and provide a means for 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.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc;
a Wang Government Services Company
[e-mail]
============================================ 


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 MAA17215 for <[e-mail]>; Wed, 12 Apr 2000 12:46:01 -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 PAA17615; Wed, 12 Apr 2000 15:49:28 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b51a82bdb336@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 12 Apr 2000 15:47:26 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: minutes & slides
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Peter,

>  > Time Stamping Protocol  (D. Pinkas-Bull)
>  > In addition to minor fixes and syntax changes to simplify the ASN.1,
>  > some changes were made to accommodate requests from an ISO committee
>  > that is also working on time stamping and wanted both protocols to be
>  > closely aligned. The changes made in TSP accommodated most but not
>  > all of the requests. A news version of the document will be issued
>  > soon, while we await a response from ISO re the current set of
>  > changes. (See slides for more details.)
>
>The changes made to the protocol also include ASN.1 changes with
>the goal to MINIMISE the encoding length (getting rid of unnecessary
>tagging).

I'll update the minutes accordingly.

>  >
>  > DVCS  (P. Sylvester-EdelWeb)
>  > This is the current version of the document that began as a notary
>  > protocol from Adams & Zuccherato, and then became the data
>  > certification service protocols, before editorial responsibility
>  > shifted. Motivation for this protocol is to support a central
>  > infrastructure for document security management, e.g., in an intranet
>  > or extranet environment, or for other long term secure document
>  > management. The protocol is designed to enable delegation of
>  > signature verification, notarization, and even certificate use
>  > controls to a server (vs. and end system). The presentation included
>  > a number of scenarios motivating the need for the protocol and its
>  > features. The question arises whether the complex document management
>  > system features described here is really an infrastructure component
>  > within the purview of this WG or it is more of an application? (See
>  > slides for more details.)
>
>This question does NOT arise:
>
>  >From goals and milestones of the working group:
>
>Dec 99 : Complete data certification document
>
>The question was: Are 31 pages too complicated to read for people
>(just 10 pages more than in time stamping).
>
>I would not be surprised if someone thinks that
>31 are definetely not enough to describe a 'complex' protocol.

If the protocol has become very complex because it attempts to embody 
features needed to support a rather complete document management 
scenario, then it may have crossed the boundary from infrastructure 
protocol to application protocol.  The WG will have to decide on this 
issue, after reviewing the document.


Steve



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 LAA16177 for <[e-mail]>; Wed, 12 Apr 2000 11:57:33 -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 OAA63698; Wed, 12 Apr 2000 14:59:40 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA162240; Wed, 12 Apr 2000 15:01:09 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568BF.006879A1 ; Wed, 12 Apr 2000 15:01:08 -0400
X-Lotus-FromDomain: IBMUS
To: "Christopher Williams" <[e-mail]>
cc: "PKIX Mailing List" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2000 15:01:03 -0400
Subject: Re: Getting CA capabilities
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     Actually, there's one more reason I can think of.  A CA's software can
be upgraded between versions, adding new capabilities (perhaps support for
a new digest algorithm) and its certificate would not usually change.  So
for a variety of reasons, a messaging interface is better than a
certificate for capabilities.  If a non-messaging interface were used,
something that might work would be an AIA value pointing at the URI where
capabilities could be downloaded or checked.
     However, for extensibility reasons, the list of capabilities returned
should probably be a set or sequence of object ID's rather than a bit
string.
     On your other issue, since HMAC-SHA1 is already mandatory to implement
in RFC 2510 and is the only MAC algorithm which is, why rule out the use by
bilateral agreement of other algorithms?  In practice, will clients which
are intended to be used with multiple vendors' server dare to use anything
else by default?


          Tom Gindin




Received: from mta02-svc.server.ntlworld.com (mta2-win.server.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15607 for <[e-mail]>; Wed, 12 Apr 2000 11:46:21 -0700 (PDT)
Received: from darxstar ([62.252.196.109]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000412195003.IHVB10065.mta02-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Wed, 12 Apr 2000 19:50:03 +0000
Message-ID: <001401bfa4b0$3dcc1ed0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Key generation parameters response
Date: Wed, 12 Apr 2000 19:51:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

One of the GeneralInfo types in the PKIX specification is a key generation
parameters response.  Exactly what would be the key generation parameters
for, say, RSA, DSA and Diffie-Hellman?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from mta02-svc.server.ntlworld.com (mta2-win.server.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15576 for <[e-mail]>; Wed, 12 Apr 2000 11:46:18 -0700 (PDT)
Received: from darxstar ([62.252.196.109]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000412195000.IHVA10065.mta02-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Wed, 12 Apr 2000 19:50:00 +0000
Message-ID: <001301bfa4b0$3bc30860$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Format of error text
Date: Wed, 12 Apr 2000 17:53:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

The specification states:

"-- text encoded as UTF-8 String [RFC2279] (note:  each UTF8String 
  -- SHOULD include an RFC 1766 language tag to indicate the 
  -- language of the contained text -- see [RFC2482] for details)"

Does this mean something like the following:

"<en-uk> Unexpected PKI message"?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15436 for <[e-mail]>; Wed, 12 Apr 2000 11:44:06 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA10565; Wed, 12 Apr 2000 20:47:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 12 Apr 2000 20:47:43 +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 UAA21544; Wed, 12 Apr 2000 20:47:42 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA08104; Wed, 12 Apr 2000 20:47:42 +0200 (MET DST)
Date: Wed, 12 Apr 2000 20:47:42 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: minutes & slides

> Time Stamping Protocol  (D. Pinkas-Bull)
> In addition to minor fixes and syntax changes to simplify the ASN.1, 
> some changes were made to accommodate requests from an ISO committee 
> that is also working on time stamping and wanted both protocols to be 
> closely aligned. The changes made in TSP accommodated most but not 
> all of the requests. A news version of the document will be issued 
> soon, while we await a response from ISO re the current set of 
> changes. (See slides for more details.)

The changes made to the protocol also include ASN.1 changes with
the goal to MINIMISE the encoding length (getting rid of unnecessary
tagging). 

> 
> DVCS  (P. Sylvester-EdelWeb)
> This is the current version of the document that began as a notary 
> protocol from Adams & Zuccherato, and then became the data 
> certification service protocols, before editorial responsibility 
> shifted. Motivation for this protocol is to support a central 
> infrastructure for document security management, e.g., in an intranet 
> or extranet environment, or for other long term secure document 
> management. The protocol is designed to enable delegation of 
> signature verification, notarization, and even certificate use 
> controls to a server (vs. and end system). The presentation included 
> a number of scenarios motivating the need for the protocol and its 
> features. The question arises whether the complex document management 
> system features described here is really an infrastructure component 
> within the purview of this WG or it is more of an application? (See 
> slides for more details.)

This question does NOT arise: 

>From goals and milestones of the working group: 

Dec 99 : Complete data certification document

The question was: Are 31 pages too complicated to read for people
(just 10 pages more than in time stamping).
 
I would not be surprised if someone thinks that
31 are definetely not enough to describe a 'complex' protocol.


> SCVP
> OCSPX
One WG member mentioned thanked the presentators for giving
two slightly differing presentations for a subset of a more
general service that is already described in another document
(namely DVCS). 

This doesn't mean that I am in favour or not of what is supposed to
be proposed by SCVP or OCSPX ... or CERTDIST, ...


Regards
Peter


Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11482 for <[e-mail]>; Wed, 12 Apr 2000 09:09:47 -0700 (PDT)
Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA27879; Wed, 12 Apr 2000 12:13:23 -0400 (EDT)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA23003; Wed, 12 Apr 2000 12:13:14 -0400 (EDT)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub1.mitre.org with SMTP id 3155296; Wed, 12 Apr 2000 12:13:00 EST
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2000 12:15:45 -0400
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.61 [en]C-19990607M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christopher Williams <[e-mail]>
CC: PKIX Mailing List <[e-mail]>
Subject: Re: Global unique identifier
References: <[e-mail]> <003401bfa498$022d9830$0100a8c0@darxstar>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Williams wrote:
> 
> There aren't many details about a person that can be assumed to be constant
> (not even his / her name).  Certainly not his subject name as that
> presumably changes when the person changes job.  The US has a social
> security number; other countries have similar schemes (I have a unique
> National Insurance number).  If there are privacy issues surrounding the use
> of these values, use a SHA-1 hash of the value instead.

Since the number of possible values is limited (e.g., 10**9 for U.S.
Social Security Number), it is feasible to precompute the hashes for all
possibilities and do a lookup.  So privacy is minimal.  On the other
hand, few people believe the SSN is very private these days.

Sam Schaen
MITRE Corp.



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10992 for <[e-mail]>; Wed, 12 Apr 2000 08:58:35 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQikps12146; Wed, 12 Apr 2000 16:02:11 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA11842; Wed, 12 Apr 00 11:58:57 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA07399; Wed, 12 Apr 2000 12:02:10 -0400
Date: Wed, 12 Apr 2000 12:02:10 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail]
Subject: Re: Global unique identifier
References: <[e-mail]> <003401bfa498$022d9830$0100a8c0@darxstar>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Christopher" == Christopher Williams <[e-mail]> writes:

 Christopher> There aren't many details about a person that can be
 Christopher> assumed to be constant (not even his / her name).
 Christopher> Certainly not his subject name as that presumably
 Christopher> changes when the person changes job.  The US has a
 Christopher> social security number; other countries have similar
 Christopher> schemes...

Just to repeat what has been said before:

a. The US SSN is *not* a globally unique identifier.  It is an "almost 
always unique identifier".

b. The US SSN is not necessarily constant for a given person.  There
are conditions under which a person can obtain a new SSN.  Given the
increased use of the SSN for dubious purposes (e.g., for insurance ID
numbers, student ID numbers, and other things of questionable
legality) the incentive for SSN abuse is increasing dramatically.
This in turn will cause the rate of SSN change to increase (since SSN
abuse is one of the recognized grounds for getting a new one).  (FYA,
having an SSN that contains the string "666" is another.)

	paul


Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10638 for <[e-mail]>; Wed, 12 Apr 2000 08:52:54 -0700 (PDT)
Received: from darxstar ([62.252.202.32]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000412155632.BSKZ381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Wed, 12 Apr 2000 16:56:32 +0100
Message-ID: <003401bfa498$022d9830$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
References: <[e-mail]>
Subject: Re: Global unique identifier
Date: Wed, 12 Apr 2000 16:58:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

There aren't many details about a person that can be assumed to be constant
(not even his / her name).  Certainly not his subject name as that
presumably changes when the person changes job.  The US has a social
security number; other countries have similar schemes (I have a unique
National Insurance number).  If there are privacy issues surrounding the use
of these values, use a SHA-1 hash of the value instead.



Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10276 for <[e-mail]>; Wed, 12 Apr 2000 08:44:31 -0700 (PDT)
Received: from darxstar ([62.252.202.32]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000412154808.BSDW381.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Wed, 12 Apr 2000 16:48:08 +0100
Message-ID: <001c01bfa496$d58472a0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
References: <006301bfa2d1$d5a220a0$0100a8c0@darxstar> <[e-mail]>
Subject: Re: Getting CA capabilities
Date: Wed, 12 Apr 2000 16:49:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Having thought about it, the Authority Information Access extension is not
the correct place for CA capability information:

1. It's a kludge
2. It's part of a separate (if related) specification; the PKIX
specification is where the issue needs to be addressed.
3. As Robert Moskovitz pointed out, you might not get the CA certificate
until the initialization response.  The initialization request can contain a
request for a server-generated encryption key.

Having the capabilities expressed in a policy document is also not the place
for it.  A human can read the document, but a machine cannot.  I know you
can express policies with ObjectIdentifiers, but this requires a client to
have intimate knowledge of the server - a hypothetical universal PKIX client
program could not understand this information.

With the current specification we can ask a CA what key types it supports
(i.e. we can tell from this if DSA is supported), but we can't ask whether
that CA will generate a DSA key on our behalf and then store it for us.
It's not really an error to ask a CA which doesn't support key generation to
generate a key if you don't know about it in advance, but presumably the CA
has to return something like badRequest.

I think a new GeneralInfo type should be devised.  The value could be a BIT
STRING whose contents indicate a mask of capabilities, e.g. bit 1 could mean
"supports key generation", bit 2 means "supports key archival and recovery",
etc.

Beyond the required capabilities of a compliant information, a lot of the
PKIX specification is pretty esoteric and may actually never be encountered
in a real world implementation.  A method of exchanging capability
information would save implementors from having to code for every
eventuality.

On the subject of making implementors' lives easier, is there any chance of
specifying SHA-1 / HMAC-SHA-1 as the ONLY permissible algorithms for a
password based MAC?  I know the aim of the specification is that it should
be as general as possible, but sometimes it's good to be strict.

----- Original Message -----
From: Robert Moskowitz <[e-mail]>
To: Oscar Jacobsson <[e-mail]>; Christopher Williams
<[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Sent: 11 April 2000 13:39
Subject: Re: Getting CA capabilities


> At 01:44 PM 4/11/2000 +0200, Oscar Jacobsson wrote:
> >Christopher Williams wrote:
> > > There does not seem to be any way for an EE to obtain details of
certain CA
> > > capabilities, e.g. whether the CA supports key generation, whether the
CA
> > > supports key archival and retrieval, etc. unless the EE has intimate
> > > knowledge of the CA.  Should the EE's client software be able to
obtain
> > > programmatically details about the server software's capabilities?  Is
this
> > > a possible GeneralInfo type?
> >
> >Would this not be best handled via the Authority Information Access
> >extension? RFC 2459 sure does make it sound like a prime candidate for
> >distributing such information:
> >
> >"The authority information access extension indicates how to access CA
> >information and services for the issuer of the certificate in which
> >the extension appears. Information and services may include on-line
> >validation services and CA policy data."
>
> But that is after the fact.  In CMP, you do not get the CA's cert until
you
> get your Initialization Response.
>
> As I pointed out to Chris in private, CMP has an out-of-band I&A process
> for IR's shared secret.  During this process, all CA policy can be handed
> to the EE.
>
> Interestingly, if you were to want to use a QC cert to sign a CP in place
> of the out-of-band I&A and IR, then you DO need a programatic way for the
> EE to get the policy.
>
> To this extent, I do not believe we KNOW all the items and values that
> would be expressed in a policy.  Or at least I have not seen any such
> document.  So for an EE programmer to deal with this, we first need to
> define what IS configurable policy, or at least those policy items that
> impact EE behaviour.
>
>
>
> Robert Moskowitz
> ICSA
> Security Interest EMail: [e-mail]
>
>



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 IAA09195 for <[e-mail]>; Wed, 12 Apr 2000 08:13:11 -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 LAA186864; Wed, 12 Apr 2000 11:15:01 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA271928; Wed, 12 Apr 2000 11:16:27 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568BF.0053E5CE ; Wed, 12 Apr 2000 11:16:23 -0400
X-Lotus-FromDomain: IBMUS
To: Robert Moskowitz <[e-mail]>
cc: Anders Rundgren <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2000 11:16:18 -0400
Subject: RE: Global unique identifier
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Robert Moskowitz <[e-mail]> on 04/12/2000 10:42:00 AM

To:   Anders Rundgren <[e-mail]>, "'Denis Pinkas'"
      <[e-mail]>
cc:   "[e-mail]" <[e-mail]>
Subject:  RE: Global unique identifier



At 03:29 PM 4/12/2000 +0200, Anders Rundgren wrote:

>Essentially only one per country at maximum.   Companies etc. and
commercial
>issuers like VerySign will use CA-specific naming domains I suppose?

No.  Get real.

A GUI would perforce be the IssuerName concatenated with the SubjectName.

[Tom Gindin]   A pre-existing GUI would not have to be based on the
IssuerName, nor would it necessarily contain the entire subject name.  It
could be (in the USA) a Social Security number (country + ID value) or an
employee ID (organization + ID value) - although Social Security numbers
might get banned by privacy legislation.  Only if the CA itself assigned
the GUI would the IssuerName be a mandatory component.

I can even seen problems there, wtih WTO or WIPO hving to deal with suits
and counter suits between CAs that use the same name.  At least with DNS we
stopped the independent root efforts.

[Tom Gindin]   Identical DN's for independent issuers would cause very
severe problems with the current standards, starting with CMS SignerInfo.
These proposals would not introduce any new limitations in that respect.

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]




Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07815 for <[e-mail]>; Wed, 12 Apr 2000 07:38:49 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Wed, 12 Apr 2000 10:44:43 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 12 Apr 2000 10:42:00 -0400
To: Anders Rundgren <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: RE: Global unique identifier
Cc: "[e-mail]" <[e-mail]>
In-Reply-To: <01BFA493.D9985490@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 03:29 PM 4/12/2000 +0200, Anders Rundgren wrote:

>Essentially only one per country at maximum.   Companies etc. and commercial
>issuers like VerySign will use CA-specific naming domains I suppose?

No.  Get real.

A GUI would perforce be the IssuerName concatenated with the SubjectName.

I can even seen problems there, wtih WTO or WIPO hving to deal with suits 
and counter suits between CAs that use the same name.  At least with DNS we 
stopped the independent root efforts.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06236 for <[e-mail]>; Wed, 12 Apr 2000 06:26:49 -0700 (PDT)
Received: from HYDRA ([195.198.186.97]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id PAA07661; Wed, 12 Apr 2000 15:32:40 +0200
Received: by HYDRA with Microsoft Mail id <01BFA493.D9985490@HYDRA>; Wed, 12 Apr 2000 15:29:10 +0200
Message-ID: <01BFA493.D9985490@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Global unique identifier
Date: Wed, 12 Apr 2000 15:29:08 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,

>In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
>each subject entity certified by the one CA as defined by the issuer
>name field". There is no requirement to make the DN unique across
>multiple CAs. 

Agreed, and I think the definition is OK.

>Adding this requirement would either break RFC 2459 or build
>something very different. Today, when a DN is used, it is a DN from
>a given CA.

Unless they conform to an "external naming/identification scheme".  But that does not
break 2459, it just extends it.

<snip>

>Now let us make the assumption that we introduce an explicit naming
>domain information (or naming authority information) in some form of
>name. Note that this topic does not apply only to the permanent
>identifier but could apply as well to the DN: this is why it should
>be discussed on a different thread. 

I definitely agree that this apply to the entire DN.

>As a conclusion, this particular aspect should be discussed on a
>separate thread (I have called it "Global unique identifier" but you
>may use any other name you prefer, as long as it is not "permanent
>identifier").

New tread? Nema problema!  Regarding global unique identifier I would prefer
that the external naming domains where registered centrally as they will be few.

Essentially only one per country at maximum.   Companies etc. and commercial
issuers like VerySign will use CA-specific naming domains I suppose?

Anders
,



Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05605 for <[e-mail]>; Wed, 12 Apr 2000 06:00:08 -0700 (PDT)
Received: from bull.net (bi109.frpq.bull.fr [129.184.8.51]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA32272; Wed, 12 Apr 2000 15:03:40 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2000 15:03:42 +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: Anders Rundgren <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Global unique identifier
References: <01BFA47E.605D6030@HYDRA>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anders,

In RFC 2459 paragraph 4.1.2.6 we have : "The DN MUST be unique for
each subject entity certified by the one CA as defined by the issuer
name field". There is no requirement to make the DN unique across
multiple CAs. 

Adding this requirement would either break RFC 2459 or build
something very different. Today, when a DN is used, it is a DN from
a given CA. Each CA may build its own tree of names. A sequence of
relative names forming a distinguished name from CA 1 and the same
sequence of names forming the same distinguished name from a CA 2 do
not necessarilly need to point to the same entity. So the name of
the CA has to be used in addition to every DN in order to make the
difference. In other words, if two DNs from two different CAs are
identical, this does not mean that the two entities are necessarilly
identical. This was supposed to be true, ten years ago, when the
Directory (with a capital D) was defined, but this is no more the
case today.

Now let us make the assumption that we introduce an explicit naming
domain information (or naming authority information) in some form of
name. Note that this topic does not apply only to the permanent
identifier but could apply as well to the DN: this is why it should
be discussed on a different thread. 

As a conclusion, this particular aspect should be discussed on a
separate thread (I have called it "Global unique identifier" but you
may use any other name you prefer, as long as it is not "permanent
identifier").

Denis
 

> Denis,
> <snip>
> >Please, do not make the story more complicated than requested. The
> >permanent identifier is a name of the subject, unique within the
> >issuer domain, that is not reused over time for another subject. The
> >name is only unique within the issuer domain (i.e. CA). Making the
> >name unique across different CAs would break the current PKIX model.
> 
> The requirement stated by Tom is very valid (I have raised it on this list a countless number of times)
> and applies 100% to what is supposed to be happening any old day here in Sweden.
> I.e. a number of competing CAs issue certificates to a Naming Domain they do not govern themselves.
> These identity certificates are supposed to be totally interchangeable as their physical counterparts
> have been the last 30 years or so.  By the use of a permanent ID and (implicit) naming domain.
> 
> I.e. any improvement or addition to QC must address the naming domain question as well.
> Or as Tom prefers.  The naming authority.
> 
> Anders


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02748 for <[e-mail]>; Wed, 12 Apr 2000 03:53:24 -0700 (PDT)
Received: from HYDRA ([195.198.186.97]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id MAA25736; Wed, 12 Apr 2000 12:58:55 +0200
Received: by HYDRA with Microsoft Mail id <01BFA47E.605D6030@HYDRA>; Wed, 12 Apr 2000 12:55:27 +0200
Message-ID: <01BFA47E.605D6030@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Stephen Kent <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Permanent identifiers in QC
Date: Wed, 12 Apr 2000 12:55:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Denis,
<snip>
>Please, do not make the story more complicated than requested. The
>permanent identifier is a name of the subject, unique within the
>issuer domain, that is not reused over time for another subject. The
>name is only unique within the issuer domain (i.e. CA). Making the
>name unique across different CAs would break the current PKIX model. 

The requirement stated by Tom is very valid (I have raised it on this list a countless number of times)
and applies 100% to what is supposed to be happening any old day here in Sweden. 
I.e. a number of competing CAs issue certificates to a Naming Domain they do not govern themselves.
These identity certificates are supposed to be totally interchangeable as their physical counterparts
have been the last 30 years or so.  By the use of a permanent ID and (implicit) naming domain.

I.e. any improvement or addition to QC must address the naming domain question as well.
Or as Tom prefers.  The naming authority. 

Anders




Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01727 for <[e-mail]>; Wed, 12 Apr 2000 03:28:21 -0700 (PDT)
Received: from bull.net (bi109.frpq.bull.fr [129.184.8.51]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA26784; Wed, 12 Apr 2000 12:31:45 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 Apr 2000 12:31:47 +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: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Permanent identifiers in QC
References: <[e-mail]> <v04220817b519321a66f9@[171.78.30.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve, Anders, Stefan, Tom, Russ, and the WG, 

I will use the response from Steve to comment and add a few things
captured in other E-mails.

Mike said: " I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  <
snip>  That is the task of other WGs. " 

Russ said something similar: "If some Internet application needs a
permanent identifier, then the needy application should specify it".

The right answer has been given by Steve: " ... if there is a need
for such forms of IDs, and if they span multiple applications, then
we could reasonably define them in PKIX."

So the basic question is whether there is a need for such form of
permanent ID. Some arguments were raised whether the need was for
acces control purposes only or also for non-repudiation purposes. No
one is disputing that it is usefull for access control purposes. I
would like to mention that this OPTIONAL feature MAY also be usefull
for non-repudiation purposes. A non repudiation service may be used
in the context of a transaction. It may be usefull to be able to
relate different transactions to the same individual, *even when the
name (i.e. DN) of the individual changes*. The current DN cannot be
used for such a purpose. A permanent identifier allows to support
that feature. 

At the meeting we said, as Stefan reported: " the decision whether
or not to include this name form in QC should be taken to the list".
This is correct (and not reflected in the draft minutes just
received). :-(

A basic question is whether the permanent identifier should be
described in the son of RFC 2459 or in QC. Let us forget the
technical aspect for a moment and face the procedural aspect. Let us
suppose that it is not defined in QC, but in the son of RFC 2459.
Since QC refers to RFC 2459, not the son of RFC 2459, even if it is
described there it will not apply, i.e. it will not be a possible
feature of QC. 

We should include it in QC now, because there is a need to define
what is (or what is not) a QC within a couple of months. If this is
not included, it will not be possible to people to issue QCs with
permanent identifiers, even if the feature is described in another
separate document. Otherwise it would mean that in order to conform
to the European Directive, you would have to consult two separate
RFCs, which would be a little odd or bizare.

Now I would like to come back to the technical aspect. Stefan said:
 
" 1) Adding this name form would add confusion to the QC
specification since it would overlap use of serialNumber in the DN." 

If we are not careful with the text defining what a serial Number
is, Stefan is right when he says that some confusion might be
possible. But is it easy to fix it. The permanent identifier can
include ANY attribute. Currently the definition of serialNumber
mandates its use only in the DN. We could extend the definition (as
I have proposed) and its meaning when it is included either in the
DN or in the permanent identifier.


> Tom,
> 
> >      I do not understand why permanent identifiers would be much less
> >useful in a non-repudiation situation than in an access control situation.
> >A third-party verifier is just as interested in distinguishing between two
> >individuals named "John Smith" to decide whether the subject of the
> >certificate used to sign a document in the past is the same person as the
> >relying party claims it is as an access control system would be in whether
> >the certificate subject is the owner of account "jsmith".  It is true that
> >transaction volumes for NR verification would probably be low enough that
> >manual techniques like checking what identification was presented to the CA
> >or RA could be used in the absence of a permanent identifier, and that the
> >verifier might wind up having to check the CA's records anyway, especially
> >if certification masquerade is claimed.  However, access control systems
> >may not think that a permanent ID match from a cross-certified CA is
> >absolute proof of identity either, and might prefer storing specific
> >certificate ID's.
> 
> I understand your point that under some circumstances it may be
> desirable to be able to determine if two different certs, involved in
> signing two different objects, are the same individual.  But that
> certainly is an extension of the basic non-repudiation service, which
> focuses on whether a given signature for a signed object is valid,
> relative to a set of rules re certificate issuance, path validation,
> revocation, etc.  

I do not see this as an extension. One way to look at the problem is
to consider at a broad level the difference between the DN and the
permanent identifier.

The permanent identifier is basically "machine processable" while
the DN is mainly "human processable". The permanent identifier does
not necessarilly allow a human being to identify directly the
individual, e.g. a social security number for an individual or an
employee number (associated with a company name) for an employee.

The DN allows a better direct identification (if a pseudonym is not
used and if there are no homonyms). The serialNumber when used in
conjunction with a DN does not allow a better identification, it
only allows to differentiate between two homonyms, i.e. John Smith
22 and John Smith 41. Some "other (undefined) means" are needed to
tell which John Smith you are looking for.

Let me present two simple scenarios which explain how the permanent
identifier might be used in the context of non-repudiation.

1) The first time a transaction is being received by a transaction
system, the DN is looked at in conjunction with some "other means"
(maybe using some human intelligence). If it is found acceptable,
then the permanent identifier can be used to link future
transactions from the same individual, even if the DN changes.

2) When a user registers to a transaction system, it presents his
certificate. Once the certificate is accepted, then the permanent
identifier is used to accept and link subsequent transactions, even
if the DN changes. 
 
> We probably ought not add features to QC certs to
> address increasingly more complex scenarios, vs. the general case NR
> scenarios that the QC document editor has established as the scope of
> that effort.  


> For example, Denis's proposal does not ensure that one
> can compare the IDs in the new name form when they are issued under
> two different CAs. I can imagine applications where that might be an
> important feature, but that does not mean that we ought to define a
> construct for supporting such a facility.

Please, do not make the story more complicated than requested. The
permanent identifier is a name of the subject, unique within the
issuer domain, that is not reused over time for another subject. The
name is only unique within the issuer domain (i.e. CA). Making the
name unique across different CAs would break the current PKIX model. 

Denis

> In another example, the PKIX WG was treated to an impressive
> presentation in Adelaide on a protocol suite that supports very
> complex document management applications. It probably subsumes the
> functions of SCVP, OCSP, and maybe parts of CMP!  However, that
> protocol is probably too elaborate and too focused on a specific
> application context to match the WG charter of standardizing generic,
> infrastructure services and data formats.
> 
> Steve


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 RAA29184 for <[e-mail]>; Tue, 11 Apr 2000 17:10:16 -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 UAA72774; Tue, 11 Apr 2000 20:12:20 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id UAA76480; Tue, 11 Apr 2000 20:13:33 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568BF.00013C6F ; Tue, 11 Apr 2000 20:13:30 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2000 20:13:25 -0400
Subject: Re: Permanent identifiers in QC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I am responding to some of your replies below.  However, if an
OTHER-NAME is more appropriate for this purpose than a QC statement, the
following ASN.1 definitions for such an OTHER-NAME might make it clear what
I am suggesting:

authorityAssignedID OTHER-NAME ::= { AuthorityAssignedID IDENTIFIED BY
                    id-pkix-authorityAssignedID }
AuthorityAssignedID ::= SEQUENCE   {
     authority GeneralName,
     ID        DirectoryString
     }

CAAssignedID OTHER-NAME ::= { IssuerAssignedID IDENTIFIED BY
                    id-pkix-CAAssignedID }
IssuerAssignedID    ::= DirectoryString

     National identities can easily be represented by an
authorityAssignedID with the authority specified by a DN containing only a
country attribute.
     The first of these two forms has quite general use, and the only
application the second is specific to is the CA itself.

          Tom Gindin

Stephen Kent <[e-mail]> on 04/11/2000 04:01:23 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [e-mail]
Subject:  Re: Permanent identifiers in QC



Tom,

>      I do not understand why permanent identifiers would be much less
>useful in a non-repudiation situation than in an access control situation.
>A third-party verifier is just as interested in distinguishing between two
>individuals named "John Smith" to decide whether the subject of the
>certificate used to sign a document in the past is the same person as the
>relying party claims it is as an access control system would be in whether
>the certificate subject is the owner of account "jsmith".  It is true that
>transaction volumes for NR verification would probably be low enough that
>manual techniques like checking what identification was presented to the
CA
>or RA could be used in the absence of a permanent identifier, and that the
>verifier might wind up having to check the CA's records anyway, especially
>if certification masquerade is claimed.  However, access control systems
>may not think that a permanent ID match from a cross-certified CA is
>absolute proof of identity either, and might prefer storing specific
>certificate ID's.

I understand your point that under some circumstances it may be
desirable to be able to determine if two different certs, involved in
signing two different objects, are the same individual.  But that
certainly is an extension of the basic non-repudiation service, which
focuses on whether a given signature for a signed object is valid,
relative to a set of rules re certificate issuance, path validation,
revocation, etc.  We probably ought not add features to QC certs to
address increasingly more complex scenarios, vs. the general case NR
scenarios that the QC document editor has established as the scope of
that effort.  For example, Denis's proposal does not ensure that one
can compare the IDs in the new name form when they are issued under
two different CAs. I can imagine applications where that might be an
important feature, but that does not mean that we ought to define a
construct for supporting such a facility.

[Tom Gindin] My major point is that this facility is no more beyond the
core scope of NR than beyond that of authentication.  If Denis' proposal is
the one in his posting of March 15, it covers one of the three cases I
proposed in my postings of March 30-31 - the case I described as
id-qcs-CALocal.  The  proposed identifier assignment authority is more
general and would enable comparisons for equality across CA's.  The
heuristic is: two such identities match if both the authorities and the
identifiers match, and do not match otherwise.  The issuer name does not
enter into the comparison in this case.  In the special case where the
issuer is defined to be the assignment authority (which I assigned its own
semantics identifier), the identities cannot be compared across CA's.

In another example, the PKIX WG was treated to an impressive
presentation in Adelaide on a protocol suite that supports very
complex document management applications. It probably subsumes the
functions of SCVP, OCSP, and maybe parts of CMP!  However, that
protocol is probably too elaborate and too focused on a specific
application context to match the WG charter of standardizing generic,
infrastructure services and data formats.

[Tom Gindin] A requirement for a name form consisting of an assignment
authority and an identifier seems to be fairly general.  It has come up
both in the QC discussions and for access control.

Steve




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 OAA27176 for <[e-mail]>; Tue, 11 Apr 2000 14:31:20 -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 RAA03712 for <[e-mail]>; Tue, 11 Apr 2000 17:34:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422081cb51948169128@[171.78.30.107]>
Date: Tue, 11 Apr 2000 17:26:15 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: minutes & slides
Content-Type: multipart/alternative; boundary="============_-1256633534==_ma============"

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

Folks,

Below is a draft of the meeting minutes.  I'm awaiting Warwick's 
document status inputs, but otherwise the minutes are complete and 
ready for comments, prior to submission to the IETF Secretariat.

As for slides, I have sets from Polk, Turner, Malpani, and Santesson. 
Stil missing are slides from:

P. Sylvester-EdelWeb
M. Myers-VeriSign
S. Farrell-SSE
D. Pinkas-Bull

Steve
-----

PKIX WG Meeting 3/29-00
Edited by Steve Kent (WG co-chair)

The PKIX WG met once during the 47th IETF and a total of 
approximately ??? individuals participated in this meeting.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX COMPLETED DOCUMENTS

<GET INPUT FROM WARWICK>


PKIX WORK IN PROGRESS


<GET INPUT FROM WARWICK>


ACTIVE PROJECTS:


Revisions to RFC 2459 & ECDSA (T. Polk-NIST)
New document published on 3/10/00, to fix errors, align with latest 
X.509 revisions, etc.  Major changes to certificate path validation 
are included, especially a detailed CRL processing section. ASN.1 
appendix was updated too. Authors still need to include some better 
examples. Suggestion made to remove the 1997 ASN.1 syntax, vs. the 
1988 syntax, to avoid inconsistencies. There was prior agreement to 
move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to 
remove section 7 and combine it with the ECDSA document to create a 
new PKIX document, devoted to algorithms. The authors plan to submit 
both documents for WG last call by the end of April. (See slides for 
more details.)

Qualified Certificates  (S. Santesson-AddTrust)
This ID has completed WG last call. A major debate arose with regard 
to use of the SerialNumber attribute as a means of differentiating 
between otherwise identical DNs, vs. using it as a unique ID 
irrespective of the rest of the DN. This is an example of a larger 
issue, i.e., situations where a subset of the DN is sufficient to 
uniquely identify a subject.  There is no general syntactic mechanism 
to specify what subset of a DN might exhibit this property, although 
one might convey this information via certificate policy or other 
means. Denis Pinkas responded with slides suggesting the need for a 
mechanism to solve a subtly different problem, i.e., defining a 
permanent identifier for a subject, even when the directory name 
changes, e.g., due to marriage, divorce, change of address, 
intra-organizational change, etc. Proposal is to create new name 
type, a new OID under OtherName, which is expressly used for this 
purpose, as an alternate subject name. This name form will be 
composed of DN attributes. No constraints would be imposed on the 
name form.  The uniqueness of the new name form is not global, but 
local to the issuer. Denis would like to add this to the QC document, 
but it was observed that the advertised benefits for permanent IDs 
apply outside of the QC context, e.g., for intra-organizational 
access control. A proposal was made to progress this as a separate, 
small document, which can be merged into the QC document or into 2459 
in the future, if there is suitable support.  The motivation here is 
to not derail the progress of the QC document. (See slides for more 
details.)

PKIX Roadmap  (S. Turner-IECA)
This document has been updated to version 5, which includes revisions 
to the POP and Key Usage sections. The author plans to include the 
recent debate on qualified certificates (see above). The suggestion 
is made to issue this document as an Informational RFC once the QC 
and revised part 1 documents are approved for publication as RFCs. 
The Informational RFC will be updated periodically to track the 
evolution of PKIX documents. (See slides for more details.)

Time Stamping Protocol  (D. Pinkas-Bull)
In addition to minor fixes and syntax changes to simplify the ASN.1, 
some changes were made to accommodate requests from an ISO committee 
that is also working on time stamping and wanted both protocols to be 
closely aligned. The changes made in TSP accommodated most but not 
all of the requests. A news version of the document will be issued 
soon, while we await a response from ISO re the current set of 
changes. (See slides for more details.)

DVCS  (P. Sylvester-EdelWeb)
This is the current version of the document that began as a notary 
protocol from Adams & Zuccherato, and then became the data 
certification service protocols, before editorial responsibility 
shifted. Motivation for this protocol is to support a central 
infrastructure for document security management, e.g., in an intranet 
or extranet environment, or for other long term secure document 
management. The protocol is designed to enable delegation of 
signature verification, notarization, and even certificate use 
controls to a server (vs. and end system). The presentation included 
a number of scenarios motivating the need for the protocol and its 
features. The question arises whether the complex document management 
system features described here is really an infrastructure component 
within the purview of this WG or it is more of an application? (See 
slides for more details.)

OCSP Extensions  (M. Myers-VeriSign)
The document has been significantly reduced in size, consistent with 
a reduced scope definition.  The newly defined scope includes: 
delegated path validation, validation path discovery, trusted point 
specification, and extended status replies. There was some discussion 
about possible ambiguity with regard to path validation, i.e., it is 
important that the server produce the same validation result as a 
local, RFC 2459-compliant implementation. A brief list of additional 
requirements was presented. A WG member noted that OCSP requires 
inclusion of the hash of parts of the issuer's certificate, which 
says that OCSPX cannot perform complete path validation for a client. 
Another WG member requested that the list be polled to determine if 
delegated path validation is a required facility to be provided by a 
PKIX work product. (See slides for more details.)


SCVP  (A. Malpani-ValiCert)
This presentation began with a review of OCSP and its rationale. 
Specifically, OCSP assumes that the client has constructed a 
validation chain and is just asking the server to check the status of 
each certificate in the chain. The motivation for SCVP is to offload 
path construction and validation to a server, as a response to 
customer requests, e.g., for limited processing environments or 
anywhere the client does not want to implement the complex task of 
path generation and validation. Unlike OCSPX, there is no presumption 
that the client has other than the target certificate available as a 
starting point for path validation. Here too one must verify that 
remote validation is a needed service. (See slides for more details.)

A small group will generate a requirements document to characterize 
the motivations for remote validation services, to define the 
requirements for such services, and to compare the candidate 
protocols relative to these requirements.  The group members will 
include the authors of the competing protocols and a WG co-chair.

Attribute Certificates (S. Farrell-SSE)
Small changes have been made to this document to maintain synch with 
the latest X.509 documents, plus minor fixes. Plan is to issue a new 
draft and move quickly to WG last call.


OTHER TOPICS


PKI Disclosure Statements (S. Santesson & M. Baum-VeriSign)
A section of the ABA ISC has proposed a new form of document to be 
issued by a CA.  The PKI Disclosure Statement (PDS) is not a 
replacement for a CP or CPS. Rather the PDS is intended to address 
certain consumer disclosure legal requirements for which a CP or CPS 
is inappropriate. The set of data to be included is small and well 
defined.  It might be represented in XML, although this is not an 
explicit requirement.

Mobile Credentials (S. Farrell-Baltimore)
Desire to provide a standard protocol for downloading/uploading 
credentials, e.g., for systems that have limited local storage.  This 
issue has been raised in the WAP forum, but it might be well pursued 
in the IETF, maybe in PKIX.

--============_-1256633534==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,


Below is a draft of the meeting minutes.  I'm awaiting Warwick's
document status inputs, but otherwise the minutes are complete and
ready for comments, prior to submission to the IETF Secretariat.


As for slides, I have sets from Polk, Turner, Malpani, and Santesson. 
Stil missing are slides from:


<bigger>P. Sylvester-EdelWeb

M. Myers-VeriSign

S. Farrell-SSE

D. Pinkas-Bull


Steve

-----


<fontfamily><param>Courier_New</param>PKIX WG Meeting 3/29-00 

Edited by Steve Kent (WG co-chair)


The PKIX WG met once during the 47th IETF and a total of approximately
??? individuals participated in this meeting. 


The meeting began with a review of the status of all of the WG
document, 

presented by Warwick Ford, WG co-chair. The following text summarizes
the 

status of the documents:


PKIX COMPLETED DOCUMENTS


<<GET INPUT FROM WARWICK>



PKIX WORK IN PROGRESS



<<GET INPUT FROM WARWICK>



ACTIVE PROJECTS:



Revisions to RFC 2459 & ECDSA (T. Polk-NIST)

New document published on 3/10/00, to fix errors, align with latest
X.509 revisions, etc.  Major changes to certificate path validation are
included, especially a detailed CRL processing section. ASN.1 appendix
was updated too. Authors still need to include some better examples.
Suggestion made to remove the 1997 ASN.1 syntax, vs. the 1988 syntax,
to avoid inconsistencies. There was prior agreement to move the ECDSA
algorithm into Part 1, but this is probably a bad idea due to the
changing algorithm landscape. Instead, the proposal is to remove
section 7 and combine it with the ECDSA document to create a new PKIX
document, devoted to algorithms. The authors plan to submit both
documents for WG last call by the end of April. (See slides for more
details.)


Qualified Certificates  (S. Santesson-AddTrust)

This ID has completed WG last call. A major debate arose with regard to
use of the SerialNumber attribute as a means of differentiating between
otherwise identical DNs, vs. using it as a unique ID irrespective of
the rest of the DN. This is an example of a larger issue, i.e.,
situations where a subset of the DN is sufficient to uniquely identify
a subject.  There is no general syntactic mechanism to specify what
subset of a DN might exhibit this property, although one might convey
this information via certificate policy or other means. Denis Pinkas
responded with slides suggesting the need for a mechanism to solve a
subtly different problem, i.e., defining a permanent identifier for a
subject, even when the directory name changes, e.g., due to marriage,
divorce, change of address, intra-organizational change, etc. Proposal
is to create new name type, a new OID under OtherName, which is
expressly used for this purpose, as an alternate subject name. This
name form will be composed of DN attributes. No constraints would be
imposed on the name form.  The uniqueness of the new name form is not
global, but local to the issuer. Denis would like to add this to the QC
document, but it was observed that the advertised benefits for
permanent IDs apply outside of the QC context, e.g., for
intra-organizational access control. A proposal was made to progress
this as a separate, small document, which can be merged into the QC
document or into 2459 in the future, if there is suitable support.  The
motivation here is to not derail the progress of the QC document. (See
slides for more details.)


PKIX Roadmap  (S. Turner-IECA)

This document has been updated to version 5, which includes revisions
to the POP and Key Usage sections. The author plans to include the
recent debate on qualified certificates (see above). The suggestion is
made to issue this document as an Informational RFC once the QC and
revised part 1 documents are approved for publication as RFCs.  The
Informational RFC will be updated periodically to track the evolution
of PKIX documents. (See slides for more details.)


Time Stamping Protocol  (D. Pinkas-Bull)

In addition to minor fixes and syntax changes to simplify the ASN.1,
some changes were made to accommodate requests from an ISO committee
that is also working on time stamping and wanted both protocols to be
closely aligned. The changes made in TSP accommodated most but not all
of the requests. A news version of the document will be issued soon,
while we await a response from ISO re the current set of changes. (See
slides for more details.)


DVCS  (P. Sylvester-EdelWeb)

This is the current version of the document that began as a notary
protocol from Adams & Zuccherato, and then became the data
certification service protocols, before editorial responsibility
shifted. Motivation for this protocol is to support a central
infrastructure for document security management, e.g., in an intranet
or extranet environment, or for other long term secure document
management. The protocol is designed to enable delegation of signature
verification, notarization, and even certificate use controls to a
server (vs. and end system). The presentation included a number of
scenarios motivating the need for the protocol and its features. The
question arises whether the complex document management system features
described here is really an infrastructure component within the purview
of this WG or it is more of an application? (See slides for more
details.)


OCSP Extensions  (M. Myers-VeriSign)

The document has been significantly reduced in size, consistent with a
reduced scope definition.  The newly defined scope includes: delegated
path validation, validation path discovery, trusted point
specification, and extended status replies. There was some discussion
about possible ambiguity with regard to path validation, i.e., it is
important that the server produce the same validation result as a
local, RFC 2459-compliant implementation. A brief list of additional
requirements was presented. A WG member noted that OCSP requires
inclusion of the hash of parts of the issuer's certificate, which says
that OCSPX cannot perform complete path validation for a client.
Another WG member requested that the list be polled to determine if
delegated path validation is a required facility to be provided by a
PKIX work product. (See slides for more details.)



SCVP  (A. Malpani-ValiCert)

This presentation began with a review of OCSP and its rationale. 
Specifically, OCSP assumes that the client has constructed a validation
chain and is just asking the server to check the status of each
certificate in the chain. The motivation for SCVP is to offload path
construction and validation to a server, as a response to customer
requests, e.g., for limited processing environments or anywhere the
client does not want to implement the complex task of path generation
and validation. Unlike OCSPX, there is no presumption that the client
has other than the target certificate available as a starting point for
path validation. Here too one must verify that remote validation is a
needed service. (See slides for more details.)


A small group will generate a requirements document to characterize the
motivations for remote validation services, to define the requirements
for such services, and to compare the candidate protocols relative to
these requirements.  The group members will include the authors of the
competing protocols and a WG co-chair. 


Attribute Certificates (S. Farrell-SSE)

Small changes have been made to this document to maintain synch with
the latest X.509 documents, plus minor fixes. Plan is to issue a new
draft and move quickly to WG last call.



OTHER TOPICS



PKI Disclosure Statements (S. Santesson & M. Baum-VeriSign)

A section of the ABA ISC has proposed a new form of document to be
issued by a CA.  The PKI Disclosure Statement (PDS) is not a
replacement for a CP or CPS. Rather the PDS is intended to address
certain consumer disclosure legal requirements for which a CP or CPS is
inappropriate. The set of data to be included is small and well
defined.  It might be represented in XML, although this is not an
explicit requirement.


Mobile Credentials (S. Farrell-Baltimore)

Desire to provide a standard protocol for downloading/uploading
credentials, e.g., for systems that have limited local storage.  This
issue has been raised in the WAP forum, but it might be well pursued in
the IETF, maybe in PKIX.
</fontfamily></bigger>

--============_-1256633534==_ma============--


Received: from futuna.netreach.net ([e-mail] [207.106.22.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26126 for <[e-mail]>; Tue, 11 Apr 2000 13:25:21 -0700 (PDT)
Received: (qmail 10821 invoked from network); 11 Apr 2000 20:28:53 -0000
Received: from mail.troemner.com (HELO delbert.corecom.com) (207.29.201.234) by futuna.netreach.net with SMTP; 11 Apr 2000 20:28:53 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail2.netreach.net (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 11 Apr 2000 16:31:20 -0400
To: [e-mail]
From: TISC Program Committee <[e-mail]>
Subject: A Complimentary Afternoon of Events
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

A Complimentary Afternoon of Events for Internet Professionals

The Internet Security Conference (TISC) is fast approaching.
This year's conference will be held April 24-28 in San Jose
at the Fairmont Hotel.  During full-day and half-day workshops
and a two-day symposium, TISC will address some of the most
pressing security matters facing the Internet today:
Healthcare & Security, VPNs, PKI, Single Sign-on, IPsec,
Biometrics, Intrusion Detection, Network Forensics, Evidence
Gathering, Windows 2000 security, and more.

To register to attend TISC, call [phone] or visit
https://secure.mactivity.com/tisc/registration.html

On Wednesday, April 26, TISC will offer a complementary
afternoon of events for all Internet professionals:

12:45 - 1:00	Presentation of the TISC CLUE AWARD
		to Marcus Ranum, CTO, Network Flight Recorder
		(http://tisc.corecom.com/faculty.html#ranum)

1:00 - 1:30	Keynote Address: Cultural Issues in Internet Security
		Marcus Ranum, CTO, Network Flight Recorder

1:30 - 3:00	Internet Security Product Showcase
		Complimentary refreshments and intimate demonstrations
		by over 40 public and private companies who are leading
		the way in Internet security

3:10 - 4:30	CTO Roundtable: Securing the Network Infrastructure
		CTOs discuss "hardening up" the network infrastructure to
		make it more survivable in real networking environments.
		  Moderator:	Steve Wadlow, Jerboa, Inc.
		  Panelists:	Nicko van Someren, CTO, nCipher
				Chini Krishnan, CTO, Valicert
				Clifford Neuman, CTO, CyberSafe
				Chris Klaus, CTO, ISS
				Charles Williams, CTO, Cylink

Learn more and register to attend this free afternoon of events
by visiting http://tisc.corecom.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 NAA25672 for <[e-mail]>; Tue, 11 Apr 2000 13:01:46 -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 QAA21849; Tue, 11 Apr 2000 16:05:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220817b519321a66f9@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 11 Apr 2000 16:01:23 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Permanent identifiers in QC
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tom,

>      I do not understand why permanent identifiers would be much less
>useful in a non-repudiation situation than in an access control situation.
>A third-party verifier is just as interested in distinguishing between two
>individuals named "John Smith" to decide whether the subject of the
>certificate used to sign a document in the past is the same person as the
>relying party claims it is as an access control system would be in whether
>the certificate subject is the owner of account "jsmith".  It is true that
>transaction volumes for NR verification would probably be low enough that
>manual techniques like checking what identification was presented to the CA
>or RA could be used in the absence of a permanent identifier, and that the
>verifier might wind up having to check the CA's records anyway, especially
>if certification masquerade is claimed.  However, access control systems
>may not think that a permanent ID match from a cross-certified CA is
>absolute proof of identity either, and might prefer storing specific
>certificate ID's.

I understand your point that under some circumstances it may be 
desirable to be able to determine if two different certs, involved in 
signing two different objects, are the same individual.  But that 
certainly is an extension of the basic non-repudiation service, which 
focuses on whether a given signature for a signed object is valid, 
relative to a set of rules re certificate issuance, path validation, 
revocation, etc.  We probably ought not add features to QC certs to 
address increasingly more complex scenarios, vs. the general case NR 
scenarios that the QC document editor has established as the scope of 
that effort.  For example, Denis's proposal does not ensure that one 
can compare the IDs in the new name form when they are issued under 
two different CAs. I can imagine applications where that might be an 
important feature, but that does not mean that we ought to define a 
construct for supporting such a facility.

In another example, the PKIX WG was treated to an impressive 
presentation in Adelaide on a protocol suite that supports very 
complex document management applications. It probably subsumes the 
functions of SCVP, OCSP, and maybe parts of CMP!  However, that 
protocol is probably too elaborate and too focused on a specific 
application context to match the WG charter of standardizing generic, 
infrastructure services and data formats.


Steve



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 LAA23960 for <[e-mail]>; Tue, 11 Apr 2000 11:09:28 -0700 (PDT)
From: [e-mail]
Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA402076; Tue, 11 Apr 2000 14:11:28 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id OAA270030; Tue, 11 Apr 2000 14:12:56 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568BE.00640EBE ; Tue, 11 Apr 2000 14:12:53 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: "Anders Rundgren" <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2000 14:12:47 -0400
Subject: Re: Permanent identifiers in QC
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I do not understand why permanent identifiers would be much less
useful in a non-repudiation situation than in an access control situation.
A third-party verifier is just as interested in distinguishing between two
individuals named "John Smith" to decide whether the subject of the
certificate used to sign a document in the past is the same person as the
relying party claims it is as an access control system would be in whether
the certificate subject is the owner of account "jsmith".  It is true that
transaction volumes for NR verification would probably be low enough that
manual techniques like checking what identification was presented to the CA
or RA could be used in the absence of a permanent identifier, and that the
verifier might wind up having to check the CA's records anyway, especially
if certification masquerade is claimed.  However, access control systems
may not think that a permanent ID match from a cross-certified CA is
absolute proof of identity either, and might prefer storing specific
certificate ID's.

          Tom Gindin

Stephen Kent <[e-mail]> on 04/10/2000 07:06:29 PM

To:   "Anders Rundgren" <[e-mail]>
cc:   "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject:  Re: Permanent identifiers in QC



Anders & Dave,

The scenario Dave provided is an access control example.  It is
broader than what Denis suggested in his presentation, and thus is
not what I was referring to, but it is still valid.

The emphasis on signatures verified using QC certificates has been on
their use in non-repudiable transactions.  In such cases, access
control may or may not be an issue.

Steve




Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA15208 for <[e-mail]>; Tue, 11 Apr 2000 05:42:10 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Tue, 11 Apr 2000 08:47:51 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 11 Apr 2000 08:39:58 -0400
To: Oscar Jacobsson <[e-mail]>, Christopher Williams <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: Getting CA capabilities
Cc: PKIX Mailing List <[e-mail]>
In-Reply-To: <[e-mail]>
References: <006301bfa2d1$d5a220a0$0100a8c0@darxstar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:44 PM 4/11/2000 +0200, Oscar Jacobsson wrote:
>Christopher Williams wrote:
> > There does not seem to be any way for an EE to obtain details of certain CA
> > capabilities, e.g. whether the CA supports key generation, whether the CA
> > supports key archival and retrieval, etc. unless the EE has intimate
> > knowledge of the CA.  Should the EE's client software be able to obtain
> > programmatically details about the server software's capabilities?  Is this
> > a possible GeneralInfo type?
>
>Would this not be best handled via the Authority Information Access
>extension? RFC 2459 sure does make it sound like a prime candidate for
>distributing such information:
>
>"The authority information access extension indicates how to access CA
>information and services for the issuer of the certificate in which
>the extension appears. Information and services may include on-line
>validation services and CA policy data."

But that is after the fact.  In CMP, you do not get the CA's cert until you 
get your Initialization Response.

As I pointed out to Chris in private, CMP has an out-of-band I&A process 
for IR's shared secret.  During this process, all CA policy can be handed 
to the EE.

Interestingly, if you were to want to use a QC cert to sign a CP in place 
of the out-of-band I&A and IR, then you DO need a programatic way for the 
EE to get the policy.

To this extent, I do not believe we KNOW all the items and values that 
would be expressed in a policy.  Or at least I have not seen any such 
document.  So for an EE programmer to deal with this, we first need to 
define what IS configurable policy, or at least those policy items that 
impact EE behaviour.



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from ns.celocom.se ([e-mail] [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13967 for <[e-mail]>; Tue, 11 Apr 2000 04:41:36 -0700 (PDT)
Received: by ns.celocom.se; id NAA29718; Tue, 11 Apr 2000 13:44:58 +0200 (CEST)
Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma029656; Tue, 11 Apr 00 13:44:33 +0200
Received: from celocom.com (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id NAA13968; Tue, 11 Apr 2000 13:44:31 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 Apr 2000 13:44:52 +0200
From: Oscar Jacobsson <[e-mail]>
Organization: Celo Communications AB
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christopher Williams <[e-mail]>
CC: PKIX Mailing List <[e-mail]>
Subject: Re: Getting CA capabilities
References: <006301bfa2d1$d5a220a0$0100a8c0@darxstar>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Williams wrote:
> There does not seem to be any way for an EE to obtain details of certain CA
> capabilities, e.g. whether the CA supports key generation, whether the CA
> supports key archival and retrieval, etc. unless the EE has intimate
> knowledge of the CA.  Should the EE's client software be able to obtain
> programmatically details about the server software's capabilities?  Is this
> a possible GeneralInfo type?

Would this not be best handled via the Authority Information Access
extension? RFC 2459 sure does make it sound like a prime candidate for
distributing such information:

"The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which
the extension appears. Information and services may include on-line
validation services and CA policy data."

//oscar


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 QAA24656 for <[e-mail]>; Mon, 10 Apr 2000 16:09:18 -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 TAA15568; Mon, 10 Apr 2000 19:12:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b5180dff67ce@[171.78.30.107]>
In-Reply-To: <000401bfa327$ed0f05e0$[e-mail]>
References: <000401bfa327$ed0f05e0$[e-mail]>
Date: Mon, 10 Apr 2000 19:06:29 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Permanent identifiers in QC
Cc: "David P. Kemp" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders & Dave,

The scenario Dave provided is an access control example.  It is 
broader than what Denis suggested in his presentation, and thus is 
not what I was referring to, but it is still valid.

The emphasis on signatures verified using QC certificates has been on 
their use in non-repudiable transactions.  In such cases, access 
control may or may not be an issue.

Steve


Received: from mclean4-mail.usae.bah.com ([156.80.5.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20813 for <[e-mail]>; Mon, 10 Apr 2000 12:09:01 -0700 (PDT)
Received: from bah.com ([216.192.224.35]) by mclean4-mail.usae.bah.com (Netscape Messaging Server 3.61)  with ESMTP id AAA1120; Mon, 10 Apr 2000 15:06:50 -0400
Message-ID: <[e-mail]>
Date: Mon, 10 Apr 2000 15:05:20 -0400
From: "Snow Katrina" <[e-mail]>
Organization: BAH
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD   (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Carlisle Adams <[e-mail]>
CC: "'Christopher Williams'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Can anybody generate a PKI message?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe

Carlisle Adams wrote:
> 
> Hi Chris,
> 
> Recall that IETF does not do interoperability testing within its official
> working groups.  Therefore, your message is somewhat inappropriate for the
> PKIX mailing list.  Rather, it should be sent to the ca-talk mailing list
> ([e-mail]), which was created explicitly for the purpose of
> facilitating interoperability testing for RFC 2510/2511.
> 
> Have you gotten in touch with Bob yet regarding joining the ca-talk list and
> future CMP interop bake-offs?
> 
> Carlisle.
> 
> > ----------
> > From:         Christopher Williams[SMTP:[e-mail]]
> > Sent:         Friday, April 07, 2000 10:54 AM
> > To:   PKIX Mailing List
> > Subject:      Can anybody generate a PKI message?
> >
> > Given an initial authentication key of, say, "b45t4r0-zx9?" and a
> > reference
> > value of, say, 0x269421C0, can anybody generate an initialization request
> > message containing a request for a signing key certificate with POP of a
> > signing key and protected by a password-based MAC, preferably using SHA-1
> > as
> > the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do
> > so
> > and mail it to me, I would be seriously grateful as I would like to be
> > able
> > to debug my implementations of PBM and POP against a real-world example.
> >
> > Thanks in advance,
> >
> > Chris Williams.
> >


Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19236 for <[e-mail]>; Mon, 10 Apr 2000 11:01:22 -0700 (PDT)
Received: from mega (t5o69p1.telia.com [213.64.110.1]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id UAA31316; Mon, 10 Apr 2000 20:06:42 +0200
Message-ID: <000401bfa327$ed0f05e0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: Re: Permanent identifiers in QC
Date: Mon, 10 Apr 2000 21:04:05 +0100
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 LAA19237

David,

>Perhaps Steve meant access control in a broader sense than you mean it.


Could be.

>When a human views an authenticated identity, it might be solely for
>the purpose of being able to say "yeah, that's nice".  And a machine
>might capture an authenticated identity solely for tracking or audit
>purposes.


That is indeed a possible scenario but I does not appear to be main-stream.

>But for the applications you mention, there is a decision made on the
>basis of the authenticated identity: the bank grants access to a
>particular account, the authority grants access to a particular
>citizen's records.  Do you have in mind any scenario where an identity
>is authenticated but not used to mediate access to a resource?

Not really, in most cases a digital signature is supposed to initiate something
which in the end has to do with access to resources so access control in a wider
perspective in in my opionion not a marginal application, but THE application.
At least seen from a commercial point of view.

Anders




>Dave
>
>
>
>> From: "Anders Rundgren" <[e-mail]>
>> To: <[e-mail]>, "Stephen Kent" <[e-mail]>
>> Subject: Re: Permanent identifiers in QC
>> Date: Sun, 9 Apr 2000 17:32:07 +0100
>> 
>> >Looking over this thread, and recalling Denis's presentation in Adelaide, I 
>agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, 
>the motivations cited by Denis for his proposal are access control based and 
>thus NOT suitable for inclusion >in the QC document. Also, since there is still 
>disagreement over other motivations for such identifiers, and their form in QCs, 
>I think >it unwise to incluide them in the QC document at this late date. Thus I 
>believe that we are ready to proceed with the QC document.
>> 
>> Steve, you are right that it may be best to proceed with the QC document, but 
>you are definitely wrong when you
>> say that permanent IDs only apply to access control.  They apply to ANY 
>situation where the identity of the signer,
>> authenticator etc has to be verified on-line.  From Internet-banking to 
>authority-to-citizen communication.  At least if
>> TTPs are used as CAs for client certficates.
>> 
>> <snip>
>> 
>> Anders
>> 
>> 
>> 
>> 
>> 
>*******************************************************************************
>> This confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>> 
>*******************************************************************************



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 KAA18249 for <[e-mail]>; Mon, 10 Apr 2000 10:12:28 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA14549 for <[e-mail]>; Mon, 10 Apr 2000 13:14:49 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by roadblock.missi.ncsc.mil with ESMTP id NAA14545 for <[e-mail]>; Mon, 10 Apr 2000 13:14:49 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.57.72]) by missi.ncsc.mil (8.8.8/8.8.8) with SMTP id NAA00632 for <[e-mail]>; Mon, 10 Apr 2000 13:15:42 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 10 Apr 2000 13:15:21 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Permanent identifiers in QC
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: z+bdVsvEqWocXiL+KvwBLA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Anders,

Perhaps Steve meant access control in a broader sense than you mean it.

When a human views an authenticated identity, it might be solely for
the purpose of being able to say "yeah, that's nice".  And a machine
might capture an authenticated identity solely for tracking or audit
purposes.

But for the applications you mention, there is a decision made on the
basis of the authenticated identity: the bank grants access to a
particular account, the authority grants access to a particular
citizen's records.  Do you have in mind any scenario where an identity
is authenticated but not used to mediate access to a resource?

Dave



> From: "Anders Rundgren" <[e-mail]>
> To: <[e-mail]>, "Stephen Kent" <[e-mail]>
> Subject: Re: Permanent identifiers in QC
> Date: Sun, 9 Apr 2000 17:32:07 +0100
> 
> >Looking over this thread, and recalling Denis's presentation in Adelaide, I 
agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, 
the motivations cited by Denis for his proposal are access control based and 
thus NOT suitable for inclusion >in the QC document. Also, since there is still 
disagreement over other motivations for such identifiers, and their form in QCs, 
I think >it unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.
> 
> Steve, you are right that it may be best to proceed with the QC document, but 
you are definitely wrong when you
> say that permanent IDs only apply to access control.  They apply to ANY 
situation where the identity of the signer,
> authenticator etc has to be verified on-line.  From Internet-banking to 
authority-to-citizen communication.  At least if
> TTPs are used as CAs for client certficates.
> 
> <snip>
> 
> Anders
> 
> 
> 
> 
> 
*******************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
*******************************************************************************



Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16633 for <[e-mail]>; Mon, 10 Apr 2000 08:57:54 -0700 (PDT)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id PAA72542; Mon, 10 Apr 2000 15:43:39 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 10 Apr 2000 12:13:37 -0400
To: "Christopher Williams" <[e-mail]>, "PKIX Mailing List" <[e-mail]>
From: Ari Kermaier <[e-mail]>
Subject: Re: Questionable fields in PKIX structures
In-Reply-To: <006401bfa2d1$d86bc7f0$0100a8c0@darxstar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Christopher, the following is my understanding of the spec for the fields 
you mentioned.

   -- Ari Kermaier

>PKIMessage.extraCerts

In a PKIMessage whose MessageBody content is a CertRepMessage certification 
response, if the CA is not a root CA, it may include additional 
certificates along with the EE's certificate that complete the verification 
chain.

>PKIHeader.freeText

A CA server might send a message in the freeText field for a human-operated 
client (e.g., a web browser) to display to the person, for example "Your 
certificates will be sent to you by email within the next 30 minutes".

>CertReqMsg.regInfo

Might contain information from the EE client to the CA server needed to 
issue the certificate e.g., the email address to which the certificate 
should be mailed, the client's credit card number, etc.

>RevDetails.crlEntryDetails

RFC 2459 Section 5.3 CRL Entry Extensions talks about this field. For 
example, it might contain a reason code explaining the revocation, the date 
the certificate became invalid, etc.

>CertResponse.rspInfo

Similar to CertReqMsg.regInfo, the rspInfo field may be used by the CA 
server to convey additional issuance info to the EE client needed for 
receiving/installing the certificate.



Received: from mta02-svc.server.ntlworld.com (mta2-win.server.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08030 for <[e-mail]>; Mon, 10 Apr 2000 02:42:10 -0700 (PDT)
Received: from darxstar ([62.252.196.7]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000410104542.GLUM10065.mta02-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Mon, 10 Apr 2000 10:45:42 +0000
Message-ID: <006401bfa2d1$d86bc7f0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Questionable fields in PKIX structures
Date: Mon, 10 Apr 2000 10:46:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300

There are a number of structures in the PKIX specification which have fields
whose purpose in most unclear.  In many cases, I can write routines (indeed
have written routines) to access them, but I can't fathom what they'd be
used for.  If anybody can give an explanation of the purpose of the
following fields (and possibly an example of how they might be used in a
real world scenario) I would be very grateful:

PKIMessage.extraCerts
PKIHeader.freeText
CertReqMsg.regInfo
RevDetails.crlEntryDetails
CertResponse.rspInfo

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from mta02-svc.server.ntlworld.com (mta2-win.server.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08018 for <[e-mail]>; Mon, 10 Apr 2000 02:42:06 -0700 (PDT)
Received: from darxstar ([62.252.196.7]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000410104537.GLUK10065.mta02-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Mon, 10 Apr 2000 10:45:37 +0000
Message-ID: <006301bfa2d1$d5a220a0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Getting CA capabilities
Date: Mon, 10 Apr 2000 10:34:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300

There does not seem to be any way for an EE to obtain details of certain CA
capabilities, e.g. whether the CA supports key generation, whether the CA
supports key archival and retrieval, etc. unless the EE has intimate
knowledge of the CA.  Should the EE's client software be able to obtain
programmatically details about the server software's capabilities?  Is this
a possible GeneralInfo type?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00924 for <[e-mail]>; Sun, 9 Apr 2000 07:28:56 -0700 (PDT)
Received: from mega (t2o69p100.telia.com [62.20.144.220]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id QAA19114; Sun, 9 Apr 2000 16:34:45 +0200
Message-ID: <003301bfa241$266b1870$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Subject: Re: Permanent identifiers in QC
Date: Sun, 9 Apr 2000 17:32:07 +0100
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 HAA00925

<snip>

>Looking over this thread, and recalling Denis's presentation in Adelaide, I agree with Stefan that IF we were to adopt a permanent >ID name type in PKIX, the motivations cited by Denis for his proposal are access control based and thus NOT suitable for inclusion >in the QC document. Also, since there is still disagreement over other motivations for such identifiers, and their form in QCs, I think >it unwise to incluide them in the QC document at this late date. Thus I believe that we are ready to proceed with the QC document.

Steve, you are right that it may be best to proceed with the QC document, but you are definitely wrong when you
say that permanent IDs only apply to access control.  They apply to ANY situation where the identity of the signer,
authenticator etc has to be verified on-line.  From Internet-banking to authority-to-citizen communication.  At least if
TTPs are used as CAs for client certficates.

<snip>

Anders




Received: from relay2.sion.com ([e-mail] [200.43.36.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05480 for <[e-mail]>; Sat, 8 Apr 2000 13:38:18 -0700 (PDT)
Received: from PROXY (smtp.sion.com [200.43.36.110]) by relay2.sion.com (8.9.3/8.9.3) with ESMTP id RAA17618 for <[e-mail]>; Sat, 8 Apr 2000 17:56:40 -0300
Received: from intranet - 200.43.37.94 by sion.net with Microsoft SMTPSVC; Sat, 8 Apr 2000 17:38:24 -0300
From: "PortalProfesional.com" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Sat, 08 Apr 2000 17:40:08 -0300
Subject: LEAME, ES IMPORTANTE - www.portalprofesional.com
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Priority: 1
Message-ID: <[e-mail]>

Muchas Preguntas:
- Estas Buscando Empleo?
- Tienes empleo pero quieres uno mejor?
- No sabes donde dejar tu Curriculum?
- Eres Profesional o a punto de egresar?
- Ud es una Empresa y necesita hacer publicidad?
- Necesitas EMAIL Gratis?
- Necesitas Pagina Web Gratis?
- Ud es una Consultora o Empresa y necesita publicar sus Busquedas Laborales?
- Nunca encuentras lo que buscas en Internet?

UNA SOLA RESPUESTA: www.portalprofesional.com


VISITANOS. No te vas a arrepentir!
ICQ: 64451825
www.portalprofesional.com.ar





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 OAA13105 for <[e-mail]>; Fri, 7 Apr 2000 14:12:46 -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 RAA16316 for <[e-mail]>; Fri, 7 Apr 2000 17:15:59 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220815b513fdfc0bff@[171.78.30.107]>
In-Reply-To: <03E49309E8F5D31183F7000629396ECCD61C@TRUST>
References: <03E49309E8F5D31183F7000629396ECCD61C@TRUST>
Date: Fri, 7 Apr 2000 17:16:48 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Permanent identifiers in QC
Content-Type: multipart/alternative; boundary="============_-1256980272==_ma============"

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

Folks,

I have worked my way through most of the 1600+ messages that arrived 
during the two weeks I was in vacation in NZ prior to the IETF 
meetings (when I chose not to read mail), plus a week in Australia 
w/o e-mail access (where I was, for various reasons, not able to read 
mail).

Looking over this thread, and recalling Denis's presentation in 
Adelaide, I agree with Stefan that IF we were to adopt a permanent ID 
name type in PKIX, the motivations cited by Denis for his proposal 
are access control based and thus NOT suitable for inclusion in the 
QC document.  Also, since there is still disagreement over other 
motivations for such identifiers, and their form in QCs, I think it 
unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.

Mike and Russ argue that the creation of new name forms based on a 
perceived semantic requirement is outside the scope of PKIX, i.e., it 
should be an application-specific profile created by the appropriate 
WG. I am sympathetic to these observations, but I also agree that if 
there is a need for such forms of IDs, and if they span multiple 
applications, then we could reasonably define them in PKIX.  It's 
clear that there is not general agreement on this point for now, and 
that leads me to say that we ought not put a new name form into the 
updated 2459 that is now in progress. However, i do not object to 
Denis writing a brief I-D describing the proposed new name form, and 
the motivations for it, and having that progress as a separate work 
item.  If it turns out that there is substantial support for this, 
both in the WG and in implementations, then we could merge it into 
2459 at a future date.

Comments?

Steve

--============_-1256980272==_ma============
Content-Type: text/enriched; charset="us-ascii"

Folks,


I have worked my way through most of the 1600+ messages that arrived
during the two weeks I was in vacation in NZ prior to the IETF meetings
(when I <underline>chose not</underline> to read mail), plus a week in
Australia w/o e-mail access (where I was, for various reasons,
<underline>not able</underline> to read mail).


Looking over this thread, and recalling Denis's presentation in
Adelaide, I agree with Stefan that IF we were to adopt a permanent ID
name type in PKIX, the motivations cited by Denis for his proposal are
access control based and thus NOT suitable for inclusion in the QC
document.  Also, since there is still disagreement over other
motivations for such identifiers, and their form in QCs, I think it
unwise to incluide them in the QC document at this late date. Thus I
believe that we are ready to proceed with the QC document.


Mike and Russ argue that the creation of new name forms based on a
perceived semantic requirement is outside the scope of PKIX, i.e., it
should be an application-specific profile created by the appropriate
WG. I am sympathetic to these observations, but I also agree that if
there is a need for such forms of IDs, and if they span multiple
applications, then we could reasonably define them in PKIX.  It's clear
that there is not general agreement on this point for now, and that
leads me to say that we ought not put a new name form into the updated
2459 that is now in progress. However, i do not object to Denis writing
a brief I-D describing the proposed new name form, and the motivations
for it, and having that progress as a separate work item.  If it turns
out that there is substantial support for this, both in the WG and in
implementations, then we could merge it into 2459 at a future date.


Comments?


Steve

--============_-1256980272==_ma============--


Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA09424 for <[e-mail]>; Fri, 7 Apr 2000 10:30:51 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Fri, 07 Apr 2000 13:35:54 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 07 Apr 2000 13:33:50 -0400
To: "PKIX Mailing List" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: CMP Interop Testing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

This is a call to anyone who is actively developing CMP (RFC 2510 & 2511, 
well now ID 2510bis):

Now that the dust has settled a bit around 2510bis, it is time to restart 
Interop testing.

The testing will be virtual, and the mailing list that will be supporting 
the testing work is [e-mail].  We hope to start the testing the 
first week of May.  If you wish to participate in the testing, please send 
an email to me at [e-mail].

Testing will be in small units over a series of sessions, allowing code 
corrections and new players.  Times will be slotted to allow for global 
testing (though it is not expected that any time will work for all time 
zones, a group of times will hopefully cover).

The first session will focus on IR/RR over TCP (a new TCP/HTTP draft will 
be out early next week, I was promised).  Details for the testing are 
starting now.

The goal is to have made significant progress by Pittsburg and to be 
finished by San Diego.

Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from homebase.htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA08970 for <[e-mail]>; Fri, 7 Apr 2000 10:17:30 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by homebase.htt-consult.com ; Fri, 07 Apr 2000 13:22:32 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 07 Apr 2000 13:20:03 -0400
To: "Christopher Williams" <[e-mail]>, "PKIX Mailing List" <[e-mail]>
From: Robert Moskowitz <[e-mail]>
Subject: Re: OIDs of MACing algorithms
In-Reply-To: <003701bf9e1a$43154930$0100a8c0@darxstar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:43 AM 4/4/2000 +0100, Christopher Williams wrote:
>Does anybody know the algorithm identifiers for MACing algorithms such as
>DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
>based MAC?

Buried in Senario B2 it says for IR the manditory is HMAC-SHA1:

PasswordBasedMac:
   {1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
     parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;


A few others have missed this piece of information.


Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08238 for <[e-mail]>; Fri, 7 Apr 2000 09:44:20 -0700 (PDT)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id QAA57109 for <[e-mail]>; Fri, 7 Apr 2000 16:29:53 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 07 Apr 2000 13:00:22 -0400
To: [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: RFC 2511 (CRMF) OID question
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

In RFC 2511 Section 7, the following definition is presented for using
name-value pairs as a registration control:
-----------------------------------
    id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
    --with syntax OCTET STRING
-----------------------------------

In Appendix C, the following definition is given, which appears to
introduce an OID conflict:
-----------------------------------
id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
-----------------------------------

And in Appendix B.1, the following definition appears to introduce an
ambiguity regarding the definition of the UTF8Pairs type
(UTF8String or OCTET STRING ?):
-----------------------------------
    When regInfo is used to convey one or more name-value pairs (via id-
    regInfo-utf8Pairs), the first and subsequent pairs SHALL be
    structured as follows:

       [name?value][%name?value]*%

    This string is then encoded into an OCTET STRING and placed into the
    regInfo SEQUENCE.
-----------------------------------

Can anyone clarify this for me?

Ari Kermaier <[e-mail]>



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 IAA06996 for <[e-mail]>; Fri, 7 Apr 2000 08:33:41 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT96XC>; Fri, 7 Apr 2000 11:36:23 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Can anybody generate a PKI message?
Date: Fri, 7 Apr 2000 11:36:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

Recall that IETF does not do interoperability testing within its official
working groups.  Therefore, your message is somewhat inappropriate for the
PKIX mailing list.  Rather, it should be sent to the ca-talk mailing list
([e-mail]), which was created explicitly for the purpose of
facilitating interoperability testing for RFC 2510/2511.

Have you gotten in touch with Bob yet regarding joining the ca-talk list and
future CMP interop bake-offs?

Carlisle.


> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Friday, April 07, 2000 10:54 AM
> To: 	PKIX Mailing List
> Subject: 	Can anybody generate a PKI message?
> 
> Given an initial authentication key of, say, "b45t4r0-zx9?" and a
> reference
> value of, say, 0x269421C0, can anybody generate an initialization request
> message containing a request for a signing key certificate with POP of a
> signing key and protected by a password-based MAC, preferably using SHA-1
> as
> the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do
> so
> and mail it to me, I would be seriously grateful as I would like to be
> able
> to debug my implementations of PBM and POP against a real-world example.
> 
> Thanks in advance,
> 
> Chris Williams.
> 


Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06252 for <[e-mail]>; Fri, 7 Apr 2000 07:54:42 -0700 (PDT)
Received: from darxstar ([62.252.196.216]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000407145753.JWZ274.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Fri, 7 Apr 2000 15:57:53 +0100
Message-ID: <000e01bfa0a1$f53233b0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Can anybody generate a PKI message?
Date: Fri, 7 Apr 2000 15:54:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Given an initial authentication key of, say, "b45t4r0-zx9?" and a reference
value of, say, 0x269421C0, can anybody generate an initialization request
message containing a request for a signing key certificate with POP of a
signing key and protected by a password-based MAC, preferably using SHA-1 as
the OWF and HMAC-SHA-1 as the MACing algorithm?  If anybody is able to do so
and mail it to me, I would be seriously grateful as I would like to be able
to debug my implementations of PBM and POP against a real-world example.

Thanks in advance,

Chris Williams.



Received: from exch1.rhbnc.ac.uk (exch1.rhbnc.ac.uk [134.219.200.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10221 for <[e-mail]>; Thu, 6 Apr 2000 15:25:13 -0700 (PDT)
Received: by exch1.rhbnc.ac.uk with Internet Mail Service (5.5.2650.21) id <HQMJ9QRK>; Thu, 6 Apr 2000 23:24:42 +0100
Message-ID: <[e-mail]>
From: Borselius N <[e-mail]>
To: "'Maxim Masiutin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Incorporaion of PGP Certificates into X.509v3 Certificates.
Date: Thu, 6 Apr 2000 23:24:41 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Maxim,

If I understand it correctly you are storing signed PGP keys within an X.509
extension. I suppose it makes sense for compatibility reasons but does look
a bit awkward at a first look, to store signed information along with the
signature itself (that's how PGP certs are constructed) within a X.509
field.

I am not fully clued up with PGP, (so please excuse my possibly silly
questions). I know PGP does encoding differently from other apps such as
S/MIME but does PGP use any of the same algorithms that are specified RFC
2459? And would it be possible to separate the information stored in a PGP
certificate (such as public key, owner identity, signature, algorithm ...)?

Cheers,
Niklas



-----Original Message-----
From: Maxim Masiutin [mailto:[e-mail]]
Sent: 03 April 2000 11:58
To: [e-mail]
Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.


Hello!

   I tried to submit "Incorporaion of PGP Certificates into X.509v3
   Certificates" draft, but it was IETF meeting. I post my draft here
   until IETF will be ready to accept new drafts. You comments are very
   welcome.

Internet Draft                                      M. Masiutin
                                                    RITLABS
April 3, 2000
expires in six months


   Incorporaion of PGP Certificates into X.509v3 Certificates.

   Copyright 2000 by The Internet Society. All Rights Reserved.

--- snip


Received: from eagle.verisign.com ([208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07630 for <[e-mail]>; Thu, 6 Apr 2000 13:02:44 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA18216; Thu, 6 Apr 2000 13:02:58 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <2A9K2DNQ>; Thu, 6 Apr 2000 13:02:08 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Russ Housley <[e-mail]>, [e-mail]
Subject: RE: Permanent identifiers in QC
Date: Thu, 6 Apr 2000 13:02:08 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

I agree with Russ.  I see no reason for PKIX to establish requirements
governing or defining the notion of a permanent identifier.  We establish
means by which entity identification values can be bound to a public key.
We do not establish requirements on specific instances.  That is the task of
other WGs.  

Mike


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, March 31, 2000 11:52 PM
> To: [e-mail]
> Subject: Re: Permanent identifiers in QC
> 
> 
> I cannot see any reason for PKIX to specify a permanent identifier.
> 
> In my view, it is the job of PKIX (in the son-of-RFC2459 
> document and the 
> companion QC document) to specify the means to bind an 
> identity to a public 
> key.  This does not include specifying new methods of specifying an 
> identity.  If some Internet application needs a permanent 
> identifier, then 
> the needy application should specify it.  Once it is 
> specified, it can be 
> used in certificates, just like all of the other name forms that are 
> already supported.
> 
> Russ
> 
> 
> At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
> >The PKIX meeting in Adelaide raised only 1 issue related to 
> the QC draft.
> >
> >This issue is whether we should include a new name form in the
> >subjectAltName extension holding  a permanent identifier.
> >
> >The permanent identifier would then be a name of the 
> subject, unique within
> >the issuers domain, that is not reused over time for another subject.
> >
> >The reason to include such a name form would be that the use 
> of serialNumber
> >in DN, or directoryName in subjectAltName extension, does 
> not explicitly
> >define this property by itself, unless seen in the light of 
> a defined policy
> >etc.
> >
> >Chair Stephen Kent decided that the decision whether or not 
> to include this
> >name form in QC should be taken to the list.
> >
> >My observation in regards to this is:
> >
> >1) Adding this name form would add confusion to the QC 
> specification since
> >it would overlap use of serialNumber in the DN.
> >
> >2) Use of DN attributes covers all needs related to 
> identification of the
> >subject, and that's all we need to support electronic 
> signatures, at least
> >as seen from the EU-directive. And as far I know, this goes 
> for any other
> >legal system.
> >
> >3) Use of DN in combination with either implicit knowledge, 
> use of Directory
> >name in the subjectAltname ext, use of a related policy 
> identifier or use of
> >information in the qcStatements extension also provide 
> support for use of
> >permanent identifiers identified as such.
> >
> >4) In each and every case raised in favor of this new name 
> form, the benefit
> >relates to access control rather than electronic signatures.
> >
> >5) This is a new input to the discussion, which before 
> adoption must be
> >reviewed by the community over some time.
> >
> >Observation 4 makes this whole discussion outside the scope 
> of QC and in
> >combination with the other observations, I would request 
> that the QC is
> >moved forward to proposed standard without this new name form.
> >
> >If PKIX at a later stage would find that a permanent 
> identifier solution, as
> >discussed here, is of general value, then this can be moved 
> forward as a
> >separate item. At that time we would also know if it should 
> be merged with
> >RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> >/Stefan
> 


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 GAA02011 for <[e-mail]>; Thu, 6 Apr 2000 06:56:43 -0700 (PDT)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <GWDT9RXK>; Thu, 6 Apr 2000 09:59:21 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Christopher Williams'" <[e-mail]>
Cc: PKIX Mailing List <[e-mail]>
Subject: RE: Certificate confirmation
Date: Thu, 6 Apr 2000 09:59:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi Chris,

> ----------
> From: 	Christopher Williams[SMTP:[e-mail]]
> Sent: 	Thursday, April 06, 2000 9:35 AM
> To: 	PKIX Mailing List
> Subject: 	Certificate confirmation
> 
> In the first version of RFC 2510, POP of an encryption key could be
> established by decrypting a certificate sent by a CA and using the
> symmetric
> key used to encrypt it as the input to a password-based MAC used to
> protect
> a subsequent PKIConfirm message.
> 
> The second version adds the certificate confirmation message which
> incorporates a hash of the certificate.  This will effectively prove POP
> of
> an encryption key if the certificate was encrypted.  Does the protocol
> still
> expect the confirmation message to be protected by a password-based MAC
> which has the symmetric key used to encrypt the certificate as its input?
 
No, this is no longer expected, but it is certainly permissible.  The MAC
based on this key is no longer needed to do POP, but the message still
requires some form of integrity.  So, you can do a MAC based on this key, or
a MAC based on some other shared password, or a signature, or whatever (as
long as it is clear to the receiver what you're doing and which key you're
using).

Carlisle.



Received: from mta03-svc.ntlworld.com (mta3-win.server.ntlworld.com [62.253.162.43]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01296 for <[e-mail]>; Thu, 6 Apr 2000 06:30:40 -0700 (PDT)
Received: from darxstar ([62.252.200.113]) by mta03-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000406133347.OXEK290.mta03-svc.ntlworld.com@darxstar> for <[e-mail]>; Thu, 6 Apr 2000 14:33:47 +0100
Message-ID: <000d01bf9fcd$09ee0890$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Certificate confirmation
Date: Thu, 6 Apr 2000 14:35:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

In the first version of RFC 2510, POP of an encryption key could be
established by decrypting a certificate sent by a CA and using the symmetric
key used to encrypt it as the input to a password-based MAC used to protect
a subsequent PKIConfirm message.

The second version adds the certificate confirmation message which
incorporates a hash of the certificate.  This will effectively prove POP of
an encryption key if the certificate was encrypted.  Does the protocol still
expect the confirmation message to be protected by a password-based MAC
which has the symmetric key used to encrypt the certificate as its input?

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com



Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00294 for <[e-mail]>; Thu, 6 Apr 2000 05:23:33 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id VAA15484; Thu, 6 Apr 2000 21:24:56 +0900 (KST)
Reply-To: <[e-mail]>
From: "±Ç¿ëö" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OIDs of MACing algorithms
Date: Thu, 6 Apr 2000 21:22:31 +0900
Message-ID: <000001bf9fc2$c84ca040$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, 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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id FAA00295

>  hello,
> Check out for OID's in  this site...
> 
>  www.alvestrand.no/objectid

	sorry. I have already known the site. 

	but it doesn't have. :-(


Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA21784 for <[e-mail]>; Thu, 6 Apr 2000 02:40:37 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Apr  6 02:42:15 2000
To: [e-mail]
Date: Thu, 06 Apr 2000 02:42:15 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
Cc: [e-mail]
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: RE: OIDs of MACing algorithms
X-Sender-Ip: 203.197.240.226
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

 hello,

Check out for OID's in  this site...

 www.alvestrand.no/objectid

chandar
--

On Thu, 6 Apr 2000 09:06:33    1G?kC6 wrote:
>> PKCS#5 might be what you're looking for. Check out 
>> www.rsasecurity.com/rsalabs 
>> - Tolga
>> >>> "Christopher Williams" <[e-mail]> 4/4/00 
>> 3:43:38 >>>
>> Does anybody know the algorithm identifiers for MACing 
>> algorithms such as
>> DES-MAC, Triple-DES-MAC, etc. that might be used as the basis 
>> of a password based MAC?
>
>	Thanks christopher! That's what I want to ask! :-)
>	Tolga, I read the PKCS#5 but it doesn't help me.
>
>	It specify PBE, but we just want to know the OID of DES-MAC and
>	Triple-DES-MAC in FIPS-113. 
>
>	I guess if the OID exsists, it may be under 1.3.14.3.2.(it's algorithms)
>	and 1.3.14.3.2.10 is desMAC we can use it but PKCS#11 specifies
>	3-DES-MAC doesn't require parameter and there is no way to specify
>	the key length if we use desMAC oid(that's why I looking for the OID of
>	3-DES-MAC :-( ).
>
>	I hope that the new PKCS#11 release contains the OIDs but I couldn't
>	download it from RSA ftp - it was shutdowned in these 2 days :-(.
>
>	Does any body knows it?
>
>	Thanks!
>


Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08489 for <[e-mail]>; Wed, 5 Apr 2000 17:07:31 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.9.3/8.9.3) with SMTP id JAA18513; Thu, 6 Apr 2000 09:08:55 +0900 (KST)
Reply-To: <[e-mail]>
From: "±Ç¿ëö" <[e-mail]>
To: "'Tolga Acar'" <[e-mail]>, <[e-mail]>
Subject: RE: OIDs of MACing algorithms
Date: Thu, 6 Apr 2000 09:06:33 +0900
Message-ID: <001701bf9f5b$f877bbe0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id RAA08490

> PKCS#5 might be what you're looking for. Check out 
> www.rsasecurity.com/rsalabs 
> - Tolga
> >>> "Christopher Williams" <[e-mail]> 4/4/00 
> 3:43:38 >>>
> Does anybody know the algorithm identifiers for MACing 
> algorithms such as
> DES-MAC, Triple-DES-MAC, etc. that might be used as the basis 
> of a password based MAC?

	Thanks christopher! That's what I want to ask! :-)
	Tolga, I read the PKCS#5 but it doesn't help me.

	It specify PBE, but we just want to know the OID of DES-MAC and
	Triple-DES-MAC in FIPS-113. 

	I guess if the OID exsists, it may be under 1.3.14.3.2.(it's algorithms)
	and 1.3.14.3.2.10 is desMAC we can use it but PKCS#11 specifies
	3-DES-MAC doesn't require parameter and there is no way to specify
	the key length if we use desMAC oid(that's why I looking for the OID of
	3-DES-MAC :-( ).

	I hope that the new PKCS#11 release contains the OIDs but I couldn't
	download it from RSA ftp - it was shutdowned in these 2 days :-(.

	Does any body knows it?

	Thanks!


Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07595 for <[e-mail]>; Wed, 5 Apr 2000 16:05:43 -0700 (PDT)
Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id WAA48192 for <[e-mail]>; Wed, 5 Apr 2000 22:50:47 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 05 Apr 2000 19:21:30 -0400
To: :
From: Ari Kermaier <[e-mail]>
Subject: RFC 2511 (CRMF) OID question
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

In RFC 2511 Section 7, the following definition is presented for using
name-value pairs as a registration control:
-----------------------------------
    id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
    --with syntax OCTET STRING
-----------------------------------

In Appendix C, the following definition is given, which appears to
introduce an OID conflict:
-----------------------------------
id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
-----------------------------------

And in Appendix B.1, the following definition appears to introduce an
ambiguity regarding the definition of the UTF8Pairs type
(UTF8String or OCTET STRING ?):
-----------------------------------
    When regInfo is used to convey one or more name-value pairs (via id-
    regInfo-utf8Pairs), the first and subsequent pairs SHALL be
    structured as follows:

       [name?value][%name?value]*%

    This string is then encoded into an OCTET STRING and placed into the
    regInfo SEQUENCE.
-----------------------------------

Can anyone clarify this for me?

Ari Kermaier <[e-mail]>




Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06562 for <[e-mail]>; Wed, 5 Apr 2000 14:54:49 -0700 (PDT)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA33572 for <[e-mail]>; Wed, 5 Apr 2000 17:57:52 -0400
Received: from mrspeel.watson.ibm.com (mrspeel.watson.ibm.com [9.2.75.89]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id RAA11454 for <[e-mail]>; Wed, 5 Apr 2000 17:57:51 -0400
Received: by mrspeel.watson.ibm.com (Postfix, from userid 1170) id 347FE84F0; Wed,  5 Apr 2000 17:59:09 -0400 (EDT)
To: [e-mail]
Subject: cRLDistributionPoints errors
From: Peter Gutmann <[e-mail]>
Sender: Peter Gutmann <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed,  5 Apr 2000 17:59:09 -0400 (EDT)

Currently there are two mutually incompatible interpretations of
cRLDistributionPoints floating around.  The reason for this is that the use of
GeneralNames is causing confusion among implementors, with the result that
we're seeing certs with either of the following two formatting options:

  SEQUENCE {
    OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
    OCTET STRING, encapsulates {
        SEQUENCE {
          SEQUENCE {
            [0] {
              [0] {
                [2] 'wibble'
                }
              }
            }
          }
        }
    }

  SEQUENCE {
    OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
    OCTET STRING, encapsulates {
        SEQUENCE {
          SEQUENCE {
            [0] {
              [0] {
                SEQUENCE {
                  [2] 'wibble'
                  }
                }
              }
            }
          }
        }
    }

(I've deleted the CA's URL's :-).  Note the extra SEQUENCE in the second one,
which IMHO is wrong:

   fullName [0] GeneralNames
-> fullName [0] IMPLICIT SEQUENCE OF GeneralName
-> fullName [0] GeneralName

(ie the SEQUENCE gets eaten by the parent tag).  Here's what happens when you
feed these to some common software:

                 IE4             IE5         Netscape
Implicit tag     OK              OK             OK
Explicit tag     OK              X              OK

I suspect that NS4 and IE4 are ignoring the extension, which is why they don't
complain about the explicit tagging, while IE5, which doesn't ignore it, is
rejecting it.

It looks like we're stuck with both forms for the forseeable future (does
anyone know which software is generating the broken form?  I get sent these
things by my spies, but since they're often from obscure CA's I can't figure
out what the originating application is).  If it'd possible to get some idea of
how widespread this is it's possible to determine whether you can say "It's
busted, go away" or whether you have to add yet another nondeterministic
parsing kludge to your ASN.1 parser to handle it.

Peter.



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 GAA29183 for <[e-mail]>; Wed, 5 Apr 2000 06:36:32 -0700 (PDT)
Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A201DC00E2; Wed, 05 Apr 2000 15:39:13 +0200
Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Mi, 05 Apr 2000 15:39:48 +0100
From: "Peter Lipp" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Cert Path Validation Bug in pkix-new-part1-00
Date: Wed, 5 Apr 2000 15:39:44 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.36ECA9D6--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <[e-mail]>

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.36ECA9D6--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I just try to study the path validation and stumbled over the section that
has been discussed in a thread with this subject a month ago.

The section currently reads:

  (e) If the subjectPublicKeyInfo field of the certificate contains
      an algorithm field with non-null parameters, assign the parameters
      to the working_public_key_parameters variable.

      If the subjectPublicKeyInfo field of the certificate contains an
      algorithm field with null parameters or parameters are omitted,
      compare the certificate subjectPublicKey algorithm to the
      working_public_key_algorithm.  If the certificate subjectPublicKey
      algorithm and the working_public_key_algorithm are different, set
      the working_public_key_parameters to null.

for me this is mildly confusing, and <<probably>> contradictory to what I
understood was the outcome of the thread. My understanding of that outcome
could be

  (e)	If the certificate subjectPublicKey algorithm and the
	working_public_key_algorithm are different, set the
	working_public_key_parameters to null.

	Otherwise (if the certificate subjectPublicKey algorithm
	and the working_public_key_algorithm are the same), if the
	subjectPublicKeyInfo field of the certificate contains an
	algorithm field where parameters have not been omitted,
	assign these parameters to the working_public_key_parameters
	variable.

If I misunderstood things - I beg for enlightenment

Peter




----IAIK.SMIME.MAPPER.36ECA9D6--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC
QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m
ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO
VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ
QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy
ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV
BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ
xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk
PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX
yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w
LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR
BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh
dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw
QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC
2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq
FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr
oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9
ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi
KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy
2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB
VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X
DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP
MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk
Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H
WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv
Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO
RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg
ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI
AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk
SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q
SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT
FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL
CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE
6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n
vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx
2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7
rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t
sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu
dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8
lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx
CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P
TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g
UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U
UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG
A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ
MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j
ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F
VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk
fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x
LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R
X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV
Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB
AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE
tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3
DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s
hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI
7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af
EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s
PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ
xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG
BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD
VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H
UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg
Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh
dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg
VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew
HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx
JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL
Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu
ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG
9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX
ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6
Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25
sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu
YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB
hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA
MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF
Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD
ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9
l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q
19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6
ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M
HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG
BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV
BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1
OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT
BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog
VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig
QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u
czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H
UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw
DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a
SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy
qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg
o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B
2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1
2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj
MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE
AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP
hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C
uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64
vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL
CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq
E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw
ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME
R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS
QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w
CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wMDA0MDUxMzM5NDhaMCMGCSqGSIb3DQEJBDEWBBSSQMnwPvjtjfff
9tL9vXQbrN1IUzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN
BgkqhkiG9w0BAQEFAASBgFRDe6DGO6lxKEY6TK0Ql+FlrBQP1V+2r/4lcPCzlFzP
y7mcuLIRilMeZ4ITbQ5mlmcgQLhI96HyYasA5yN/nZ6e08cytuzkWWUOG698oOMC
uX4CJtJaFB5+4TZyfj/gMMIdn3FFHpLBN8pujh77tMsjqDDg3nTETgeR1dYyQ+kL
AAAAAAAA
----IAIK.SMIME.MAPPER.36ECA9D6----



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 NAA04043 for <[e-mail]>; Tue, 4 Apr 2000 13:03:23 -0700 (PDT)
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id QAA28121; Tue, 4 Apr 2000 16:06:14 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Tue, 04 Apr 2000 16:06:05 -0400
To: "Ozols, Maris" <[e-mail]>, [e-mail]
From: "David A. Cooper" <[e-mail]>
Subject: Re: Cert Path Validation in pkix-new-part1
In-Reply-To: <[e-mail] ce.gov.au>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_7864357==_.ALT"

--=====================_7864357==_.ALT
Content-Type: text/plain; charset="us-ascii"

Maris,

I understand your concern with the possibility that a CA could use policy mapping to issue certificates under policies that it was not "authorized" to use. However, I do not believe that the problem is a great as you suggest.

Using your example, the policy tree created by the path processing algorithm would look something like this (although the P-HIGH at Level 1 would be deleted):

Level 0:        any-policy
                 /       \
                /         \
Level 1:   P-HIGH        P-LOW
                            |
                            |
Level 2:                 P-LOW
                         /     \
                        /       \
Level 3:            P-LOW     P-HIGH

As you suggest, in this scenario an end-entity could be issued a certificate under the policy P-HIGH. However, I believe that a relying party accepting such a certificate path would treat the path as if it had been accepted under the policy specified at Level 1 (P-LOW in this case). The reason for this is that the policies at Level 1 are the policies of the relying party's domain and thus, presumably, the policies that the relying party understands. In general, the relying party should not expect to be familiar with the policies that appear further down in the tree, as these policies may have been introduced as a result of policy mapping. So, while CA2 may succeed in issuing certificates under a policy that CA1 did not authorize it to use, this does not result in CA2's end-entities being granted any additional privileges.

It should also be noted that the main reason for the change in the algorithm was to properly address issues of transitive trust. For example, suppose that Company A makes widgets and buys parts from Company B. In order to enable secure communication/purchasing/design sharing/etc., Company A and Company B cross-certify their CAs. Since Companies A and B are trading partners, each company trusts the other to properly issue certificates under its own policies. By cross-certifying, the relying parties at Company B can validate the certificates of employees at Company A. However, Company A also has a trading partner relationship with Company B's competitor, Company C. So Company A and Company B are cross-certified.

While Company A trusts Company C to issue certificates properly, Company B does not. In fact, Company B wants to ensure that its employees (acting as relying parties) will not validate any certificates issued by Company C no matter what the certificates that Company C issues look like.

In this scenario, Company B will issue a cross-certificate to Company A under policy P-A with policy mapping P-A --> P-B and with policy mapping inhibited. Similarly, Company A will issue a cross-certificate to Company C under policy P-B, with policy mapping P-B --> P-C. Using the new path processing algorithm, Company B's relying parties will reject all certificates issued by Company C. Using the old path processing algorithm, on the other hand, it would have been possible for Company C to get its certificates accepted by Company B's relying parties by issuing certificates under either policy P-B or P-A.


At 03:26 PM 4/4/00 +0930, Ozols, Maris wrote:
>Hi,
>
>I have a question about pkix-new-part1.
>
>My understanding is that a major reason for the new-part1 was to deal with
>certificates that validated under RFC2459, when they really ought not to
>have. It seems that policy mappings can still be used to introduce cert
>policies in validated certificates which might have been thought excluded.  
>
>Consider the following scenario. CA1 holds (is subject of) a cert with cert
>policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child CA
>within the same security domain) with a cert that only includes {P-LOW}. CA1
>does not want CA2 to issue valid certificates with {P-HIGH} (perhaps because
>they are linked to access control over which CA2 has no authority).
>
>Then, provided that policy mappings are still permitted at this level, CA2
>could issue a self-certificate (maybe when doing a rekey) with the policy
>mapping {(P-LOW --> P-HIGH), (P-LOW --> P-LOW)}. Then CA2 may issue
>certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2 could
>certifiy another CA3 (which is also not permitted to issue P-HIGH certs)
>with the same mapping, and thus enabling CA3 to issue certs with P-HIGH. 
>
>Is inhibitPolicyMapping the only way of avoiding such abuse (given the new
>algorithm)? Note that this might not always be a viable option, as you may
>wish to allow legitimate policy mappings from CA2. Consider the case where
>CA2 is primarily involved with the external relations/e-commerce of your
>organisation, and thus may need to have extensive flexibility to
>cross-certify into commercial and business-partner PKI's. However CA2 is
>considered too exposed to be permitted to issue P-HIGH certificates (which
>are only intended for internal use). 
>
>It might be a preferable to consider an algorithm such that when issuers
>explicitly omit cert policies down the chain (as CA1 did for P-HIGH to CA2)
>that these be tracked in the algorithm as an excluded set which can't be
>mapped into. Is this an option worth pursuing? Alternatively, maybe there
>should be some words to explain that the cert policies extension in a CAs
>certificate provides little control over a CA, if it is still permitted
>policy mapping. More generally, it would be nice to have some guidance on
>how cert policies and other associated extensions can achieve a given
>outcome. I think that at the moment the 2459 (and new-part1) explanations of
>the intended semantics of cert policies for end-entity certs is simple and
>well-defined, but this is not the case for cert policies in CA certificates.
>
>Maris


--=====================_7864357==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Maris,<br>
<br>
I understand your concern with the possibility that a CA could use policy
mapping to issue certificates under policies that it was not
&quot;authorized&quot; to use. However, I do not believe that the problem
is a great as you suggest.<br>
<br>
Using your example, the policy tree created by the path processing
algorithm would look something like this (although the P-HIGH at Level 1
would be deleted):<br>
<br>
<tt>Level 0:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; any-policy<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<br>
Level 1:&nbsp;&nbsp; P-HIGH&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW<br>
&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;
|<br>
&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;
|<br>
Level
2:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW<br>
&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; \<br>
&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; \<br>
Level
3:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P-LOW&nbsp;&nbsp;&nbsp;&nbsp; P-HIGH<br>
<br>
</tt>As you suggest, in this scenario an end-entity could be issued a
certificate under the policy P-HIGH. However, I believe that a relying
party accepting such a certificate path would treat the path as if it had
been accepted under the policy specified at Level 1 (P-LOW in this case).
The reason for this is that the policies at Level 1 are the policies of
the relying party's domain and thus, presumably, the policies that the
relying party understands. In general, the relying party should not
expect to be familiar with the policies that appear further down in the
tree, as these policies may have been introduced as a result of policy
mapping. So, while CA2 may succeed in issuing certificates under a policy
that CA1 did not authorize it to use, this does not result in CA2's
end-entities being granted any additional privileges.<br>
<br>
It should also be noted that the main reason for the change in the
algorithm was to properly address issues of transitive trust. For
example, suppose that Company A makes widgets and buys parts from Company
B. In order to enable secure communication/purchasing/design
sharing/etc., Company A and Company B cross-certify their CAs. Since
Companies A and B are trading partners, each company trusts the other to
properly issue certificates under its own policies. By cross-certifying,
the relying parties at Company B can validate the certificates of
employees at Company A. However, Company A also has a trading partner
relationship with Company B's competitor, Company C. So Company A and
Company B are cross-certified.<br>
<br>
While Company A trusts Company C to issue certificates properly, Company
B does not. In fact, Company B wants to ensure that its employees (acting
as relying parties) will not validate any certificates issued by Company
C no matter what the certificates that Company C issues look like.<br>
<br>
In this scenario, Company B will issue a cross-certificate to Company A
under policy P-A with policy mapping P-A --&gt; P-B and with policy
mapping inhibited. Similarly, Company A will issue a cross-certificate to
Company C under policy P-B, with policy mapping P-B --&gt; P-C. Using the
new path processing algorithm, Company B's relying parties will reject
all certificates issued by Company C. Using the old path processing
algorithm, on the other hand, it would have been possible for Company C
to get its certificates accepted by Company B's relying parties by
issuing certificates under either policy P-B or P-A.<br>
<br>
<br>
At 03:26 PM 4/4/00 +0930, Ozols, Maris wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I have a question about pkix-new-part1.<br>
<br>
My understanding is that a major reason for the new-part1 was to deal
with<br>
certificates that validated under RFC2459, when they really ought not
to<br>
have. It seems that policy mappings can still be used to introduce
cert<br>
policies in validated certificates which might have been thought
excluded.&nbsp; <br>
<br>
Consider the following scenario. CA1 holds (is subject of) a cert with
cert<br>
policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child
CA<br>
within the same security domain) with a cert that only includes {P-LOW}.
CA1<br>
does not want CA2 to issue valid certificates with {P-HIGH} (perhaps
because<br>
they are linked to access control over which CA2 has no authority).<br>
<br>
Then, provided that policy mappings are still permitted at this level,
CA2<br>
could issue a self-certificate (maybe when doing a rekey) with the
policy<br>
mapping {(P-LOW --&gt; P-HIGH), (P-LOW --&gt; P-LOW)}. Then CA2 may
issue<br>
certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2
could<br>
certifiy another CA3 (which is also not permitted to issue P-HIGH
certs)<br>
with the same mapping, and thus enabling CA3 to issue certs with P-HIGH.
<br>
<br>
Is inhibitPolicyMapping the only way of avoiding such abuse (given the
new<br>
algorithm)? Note that this might not always be a viable option, as you
may<br>
wish to allow legitimate policy mappings from CA2. Consider the case
where<br>
CA2 is primarily involved with the external relations/e-commerce of
your<br>
organisation, and thus may need to have extensive flexibility to<br>
cross-certify into commercial and business-partner PKI's. However CA2
is<br>
considered too exposed to be permitted to issue P-HIGH certificates
(which<br>
are only intended for internal use). <br>
<br>
It might be a preferable to consider an algorithm such that when
issuers<br>
explicitly omit cert policies down the chain (as CA1 did for P-HIGH to
CA2)<br>
that these be tracked in the algorithm as an excluded set which can't
be<br>
mapped into. Is this an option worth pursuing? Alternatively, maybe
there<br>
should be some words to explain that the cert policies extension in a
CAs<br>
certificate provides little control over a CA, if it is still
permitted<br>
policy mapping. More generally, it would be nice to have some guidance
on<br>
how cert policies and other associated extensions can achieve a
given<br>
outcome. I think that at the moment the 2459 (and new-part1) explanations
of<br>
the intended semantics of cert policies for end-entity certs is simple
and<br>
well-defined, but this is not the case for cert policies in CA
certificates.<br>
<br>
Maris<br>
</blockquote><br>
</html>

--=====================_7864357==_.ALT--



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 HAA28413 for <[e-mail]>; Tue, 4 Apr 2000 07:54:16 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 04 Apr 2000 08:56:37 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 04 Apr 2000 08:56:24 -0600
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: OIDs of MACing algorithms
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 HAA28414

PKCS#5 might be what you're looking for. Check out www.rsasecurity.com/rsalabs 

- Tolga

>>> "Christopher Williams" <[e-mail]> 4/4/00 3:43:38 >>>
Does anybody know the algorithm identifiers for MACing algorithms such as
DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
based MAC?

Cheers




Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26122 for <[e-mail]>; Tue, 4 Apr 2000 06:49:07 -0700 (PDT)
Received: from dharter (d224-183.dial.mistral.co.uk [195.184.224.183]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2H3FDT88; Tue, 4 Apr 2000 07:00:41 -0700
From: "Darren Harter" <[e-mail]>
To: <[e-mail]>
Cc: "'Hans Schupp'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Tue, 4 Apr 2000 14:49:53 +0100
Message-ID: <000201bf9e3c$adf23020$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

John,

Thanks for this.  I'm sure they'll be a few on the list, thinking "I didn't
know OCTET STRINGs could do that!"  Segmenting of OCTET STRINGs is certainly
a feature I wasn't aware of - it's good to know that even after 10 years of
ASN.1 the language can still turn around and bite me on the butt.

Kind regards,

Darren

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 04 April 2000 14:22
To: Darren Harter
Cc: 'Hans Schupp'; [e-mail]; [e-mail]
Subject: RE: ASN.1 , Constructed Encoding



Daren Hunter wrote:

>Given this, the IA5String that we are discussing is slightly
>strange as the three encodings that contain the 'test1', '@',
>and 'rsa.com' parts collectively form the 'DATA' part of the
>encoding for a single IA5String - I think we're probably in
>agreement up to this point.  These parts should fall under
>the specific rules for encoding the value of IA5Strings.  If the
>IA5String rules state that the component parts should be encoded
>as OCTET STRINGs, then you are right and 04 tags should be used
>for the component parts.  However, if the rules for IA5String
>say that the component parts should be encoded as IA5Strings
>(using the above definition), then IMHO you are wrong, and 16
> tags should be used.


X680 (or rather ISO/IEC 8825-1) says:

"Each character string type shall be encoded as if it had been declared
[UNIVERSAL x] IMPLICIT OCTET STRING"

This means that encoding a character string is a two-part process:

1) take the sequence of octets that makes up the character
string value and encode it as an OCTET STRING.

3) replace the tag of the OCTET STRING encoding with the tag for
"UNIVERSAL x".

The section that defines character string encoding doesn't mention
segmenting the string into substrings using constructed encoding -
that option comes from the OCTET STRING encoding in step 1, so it
must follow the rules for segmenting OCTET STRINGS, which says
explicitly when referring to segmented encodings that "In particular,
the tags in the contents octets are always universal class, number 4".


One interesting "feature" of this is that, since the segmentation
happens at the OCTET STRING level, the segment breaks may occur in the
middle of a character code if the codeset is a multi-byte one.

John



Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25140 for <[e-mail]>; Tue, 4 Apr 2000 06:16:28 -0700 (PDT)
From: [e-mail]
Subject: RE: ASN.1 , Constructed Encoding
To: "Darren Harter" <[e-mail]>
Cc: "'Hans Schupp'" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.2c  February 2, 2000
Message-ID: <[e-mail]>
Date: Tue, 4 Apr 2000 09:21:46 -0400
X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 04/04/2000 09:22:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Daren Hunter wrote:

>Given this, the IA5String that we are discussing is slightly
>strange as the three encodings that contain the 'test1', '@',
>and 'rsa.com' parts collectively form the 'DATA' part of the
>encoding for a single IA5String - I think we're probably in
>agreement up to this point.  These parts should fall under
>the specific rules for encoding the value of IA5Strings.  If the
>IA5String rules state that the component parts should be encoded
>as OCTET STRINGs, then you are right and 04 tags should be used
>for the component parts.  However, if the rules for IA5String
>say that the component parts should be encoded as IA5Strings
>(using the above definition), then IMHO you are wrong, and 16
> tags should be used.


X680 (or rather ISO/IEC 8825-1) says:

"Each character string type shall be encoded as if it had been declared
[UNIVERSAL x] IMPLICIT OCTET STRING"

This means that encoding a character string is a two-part process:

1) take the sequence of octets that makes up the character
string value and encode it as an OCTET STRING.

3) replace the tag of the OCTET STRING encoding with the tag for
"UNIVERSAL x".

The section that defines character string encoding doesn't mention
segmenting the string into substrings using constructed encoding -
that option comes from the OCTET STRING encoding in step 1, so it
must follow the rules for segmenting OCTET STRINGS, which says
explicitly when referring to segmented encodings that "In particular,
the tags in the contents octets are always universal class, number 4".


One interesting "feature" of this is that, since the segmentation
happens at the OCTET STRING level, the segment breaks may occur in the
middle of a character code if the codeset is a multi-byte one.

John




Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16456 for <[e-mail]>; Tue, 4 Apr 2000 03:16:35 -0700 (PDT)
Received: from dharter (d224-17.dial.mistral.co.uk [195.184.224.17]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2H3FDTVC; Tue, 4 Apr 2000 03:28:06 -0700
From: "Darren Harter" <[e-mail]>
To: "'Hans Schupp'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Tue, 4 Apr 2000 11:13:27 +0100
Message-ID: <000401bf9e1f$10d1e870$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

Hans,

No need to appologise, your English is perfectly clear.  I think we are
probably both correct but about different things, and our discussion may
have been at slightly cross perposes.  Let me try and explain.
Unfortunately, I don't have a copy of X.690 to hand here, but my
understanding is that for all standard ASN.1 types there can be three and
only three forms of encoding.  Let's take BOOLEAN as an example, go back to
first principles and gain some common ground:

Type1:	BOOLEAN

This encodes as 01 01 'DATA' where DATA is 0 for false, and non-zero for
true (always FF in DER).  Where the leading 01 is the boolean tag
([UNIVERSAL 1]) and the second 01 is the length.

Type2:	<Tag> IMPLICIT BOOLEAN

Let's consider the case where tag is [0] - i.e [0] IMPLICIT BOOLEAN.  When
the IMPLICIT keyword is present, the normal tag is replaced by the indicated
tag and the encoding in this case becomes 80 01 'DATA' where the 'DATA' and
01 have exactly the same meaning as in Type 1.

Type3:	<Tag> EXPLICIT BOOLEAN

Let's again consider the case where tag is [0] - i.e. [0] EXPLICIT BOOLEAN.
When the EXPLICIT keyword is present, the normal tag is retained in the
encoding and the indicated tag is prepended.  The encoding therefore becomes
A0 03 01 01 'DATA'.  Essentially, the original encoding from Type 1 becomes
the 'Value' part of an outer encoding.  In this case the outer tag is 'A0'
not '80' as its 'DATA' contains an ASN.1 encoding (01 01 FF) and therefore
has to be flagged as constructed.  EXPLICITly encoded types are always
flagged as constructed.

As far as I am aware, these are the rules for the 'encoding of a tagged
value'.

Following the above rules for a Type 2 definition of IA5String of [UNIVERSAL
22] IMPLICIT OCTET STRING, the normal tag for OCTET STRING (04) would not
appear in the encoding of an IA5String, but the 'DATA' part of the encoding
will be formed according to the rules for OCTET STRINGs - i.e. I arbitrary
stream of 8-bit words.

Given this, the IA5String that we are discussing is slightly strange as the
three encodings that contain the 'test1', '@', and 'rsa.com' parts
collectively form the 'DATA' part of the encoding for a single IA5String - I
think we're probably in agreement up to this point.  These parts should fall
under the specific rules for encoding the value of IA5Strings.  If the
IA5String rules state that the component parts should be encoded as OCTET
STRINGs, then you are right and 04 tags should be used for the component
parts.  However, if the rules for IA5String say that the component parts
should be encoded as IA5Strings (using the above definition), then IMHO you
are wrong, and 16 tags should be used.

In your version of the encoding we have a ASN.1 equal to:

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF OCTET STRING

whereas in my version we have

ConstructedIA5String ::= [UNIVERSAL 22] IMPLICIT SEQUENCE OF IA5String
IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING

With IMPLICIT exchanged for EXPLICIT in my other example.

What is important for this discussion is what the 'DATA' encoding rules for
IA5String say.

Can anybody post an appropriate paragraph from X.680/X.690 that describes
the internal 'DATA' encoding of IA5String?

Kind regards,

Darren

-----Original Message-----
From: Hans Schupp [mailto:[e-mail]]
Sent: 03 April 2000 17:35
To: Darren Harter
Cc: [e-mail]; [e-mail]
Subject: Re: ASN.1 , Constructed Encoding


Darren Harter wrote:

> The IMPLICIT keywords forces the encoding of OCTET STRING, but not
> its tag.  So in the case of IA5String, it is indeed 0x36 when
> constructed (or part of an explicit encoding) and 0x16 when not
> constructed (and not part of an explicit encoding).

Agree. But this is no contradiction to my posting.

> If the definition was
>   IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
> instead of
>   IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
> you would get the following:
>
> 36 1B 04 19
>                 36 07 04 05 test1
>                 36 03 04 01 @
>                 36 09 04 07 rsa.com

No, definitely not.
Please read carefully X.690 paragraph 8.14 ("Encoding of a tagged
value"). You will find, that the encoding of a tagged value is done by
taking the encoding of the base type (OCTET STRING in our discussion)
and adding the explicit tag in front of it.

So the example string encoded as
  [UNIVERSAL 16] EXPLICIT OCTET STRING
becomes
  36 15 04 13
              04 05 test1
              04 01 @
              04 07 rsa.com

The respective is valid for implicit tagging: the base encoding is
modified by throwing away the original tag and using the new one instead
(while preseving the "constructed" bit).
Please have a look at paragraph 8.14.3 for exact wording.

> Because it is IMPLICIT the three contained strings fall back to
> their default (unconstructed) tags on 0x16, but the outer
> (constructed) tag stays a 0x36.  The explicit OCTET STRING tags
> of 0x04 disappear in this case.
>
> The original poster's encoding was correct as
>
> 36 13
>         16 05 test1
>         16 01 @
>         16 07 rsa.com

No. I still stay with my original argument.

The example we use here has great resemblance with the example used in
paragraph 8.20.6 of X.690. That one supports my point of view.

> You are correct in that the only leagal X.690 encoding of this is
> in a single non-constructed IA5String with the following encoding:
>
> 16 0D [e-mail]

I'm sorry, if my English isn't good enough to make myself clear.
I didn't mean to say _that_, but the following:
Even though the encoding is done in three chunks (which is perfectly
valid in BER, but not in DER), the logical string that is expressed by
this encoding is the same as "[e-mail]" encoded in one chunk.

Best regards,
Hans Schupp

PS: I refer to X.690 (1994 E) aka ISO/IEC 8825-1: 1995 (E)




Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11051 for <[e-mail]>; Tue, 4 Apr 2000 02:38:41 -0700 (PDT)
Received: from darxstar ([62.252.196.117]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000404094136.BGJQ274.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Tue, 4 Apr 2000 10:41:36 +0100
Message-ID: <003701bf9e1a$43154930$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: OIDs of MACing algorithms
Date: Tue, 4 Apr 2000 10:43:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Does anybody know the algorithm identifiers for MACing algorithms such as
DES-MAC, Triple-DES-MAC, etc. that might be used as the basis of a password
based MAC?

Cheers



Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10709 for <[e-mail]>; Tue, 4 Apr 2000 02:25:45 -0700 (PDT)
X-Envelope-Sender-Is: [e-mail] (at relayer david.siemens.de)
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.0/8.10.0) with ESMTP id e349Sfm21202 for <[e-mail]>; Tue, 4 Apr 2000 11:28:41 +0200 (MET DST)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail1.siemens.de (8.10.0/8.10.0) with ESMTP id e349Sel07130 for <[e-mail]>; Tue, 4 Apr 2000 11:28:40 +0200 (MET DST)
Received: from mchp.siemens.de ([e-mail] [139.23.204.82]) by mail-k.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id LAA07994 for <[e-mail]>; Tue, 4 Apr 2000 11:28:39 +0200 (MET DST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 04 Apr 2000 12:19:03 +0200
From: Markus Heintel <[e-mail]>
Organization: Siemens AG
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe


Received: from mta01-svc.server.ntlworld.com (mta1-win.server.ntlworld.com [62.253.162.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08996 for <[e-mail]>; Tue, 4 Apr 2000 01:56:39 -0700 (PDT)
Received: from darxstar ([62.252.196.117]) by mta01-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000404085928.BFSV274.mta01-svc.server.ntlworld.com@darxstar> for <[e-mail]>; Tue, 4 Apr 2000 09:59:28 +0100
Message-ID: <003001bf9e14$605bb2a0$0100a8c0@darxstar>
From: "Christopher Williams" <[e-mail]>
To: "PKIX Mailing List" <[e-mail]>
Subject: Purpose of caPubs field
Date: Tue, 4 Apr 2000 09:43:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Can anybody tell me what is the prupose of the caPubs field in the PKIX
CertRepMessage structure?

Thanks.



Received: from digger1.defence.gov.au ([e-mail] [203.5.217.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA28631 for <[e-mail]>; Mon, 3 Apr 2000 23:00:49 -0700 (PDT)
Received: by digger1.defence.gov.au; id PAA23636; Tue, 4 Apr 2000 15:33:32 +0930
Received: from dsto-ms2.dsto.defence.gov.au(131.185.2.150) by digger1.defence.gov.au via smap (V4.2) id xmab23499; Tue, 4 Apr 00 15:33:10 +0930
Received: from muttley.dsto.defence.gov.au (unverified [131.185.2.1]) by dsto-ms2.dsto.defence.gov.au (Integralis SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 04 Apr 2000 15:28:35 +0930
Received: from fang.dsto.defence.gov.au (fang.dsto.defence.gov.au [131.185.2.5]) by muttley.dsto.defence.gov.au (8.9.3/8.9.3/8.9.3.LMD.990513) with ESMTP id PAA04052 for <[e-mail]>; Tue, 4 Apr 2000 15:26:23 +0930 (CST)
Received: from salex003.dsto.defence.gov.au (salex003.dsto.defence.gov.au [131.185.2.11]) by fang.dsto.defence.gov.au (8.9.3/8.9.3/8.9.3.LMD.990513) with ESMTP id PAA19913 for <[e-mail]>; Tue, 4 Apr 2000 15:26:23 +0930 (CST)
Received: by salex003.dsto.defence.gov.au with Internet Mail Service (5.5.2650.21) id <21DTBHKZ>; Tue, 4 Apr 2000 15:26:31 +0930
Message-Id: <[e-mail]>
From: "Ozols, Maris" <[e-mail]>
To: [e-mail]
Subject:  Cert Path Validation in pkix-new-part1
Date: Tue, 4 Apr 2000 15:26:35 +0930 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I have a question about pkix-new-part1.

My understanding is that a major reason for the new-part1 was to deal with
certificates that validated under RFC2459, when they really ought not to
have. It seems that policy mappings can still be used to introduce cert
policies in validated certificates which might have been thought excluded.  

Consider the following scenario. CA1 holds (is subject of) a cert with cert
policies {P-HIGH, P-LOW}, which then certifies CA2 (perhaps a child CA
within the same security domain) with a cert that only includes {P-LOW}. CA1
does not want CA2 to issue valid certificates with {P-HIGH} (perhaps because
they are linked to access control over which CA2 has no authority).

Then, provided that policy mappings are still permitted at this level, CA2
could issue a self-certificate (maybe when doing a rekey) with the policy
mapping {(P-LOW --> P-HIGH), (P-LOW --> P-LOW)}. Then CA2 may issue
certificates with the policy P-HIGH (and/or P-LOW). Alternatively, CA2 could
certifiy another CA3 (which is also not permitted to issue P-HIGH certs)
with the same mapping, and thus enabling CA3 to issue certs with P-HIGH. 

Is inhibitPolicyMapping the only way of avoiding such abuse (given the new
algorithm)? Note that this might not always be a viable option, as you may
wish to allow legitimate policy mappings from CA2. Consider the case where
CA2 is primarily involved with the external relations/e-commerce of your
organisation, and thus may need to have extensive flexibility to
cross-certify into commercial and business-partner PKI's. However CA2 is
considered too exposed to be permitted to issue P-HIGH certificates (which
are only intended for internal use). 

It might be a preferable to consider an algorithm such that when issuers
explicitly omit cert policies down the chain (as CA1 did for P-HIGH to CA2)
that these be tracked in the algorithm as an excluded set which can't be
mapped into. Is this an option worth pursuing? Alternatively, maybe there
should be some words to explain that the cert policies extension in a CAs
certificate provides little control over a CA, if it is still permitted
policy mapping. More generally, it would be nice to have some guidance on
how cert policies and other associated extensions can achieve a given
outcome. I think that at the moment the 2459 (and new-part1) explanations of
the intended semantics of cert policies for end-entity certs is simple and
well-defined, but this is not the case for cert policies in CA certificates.

Maris



Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20686 for <[e-mail]>; Mon, 3 Apr 2000 21:15:06 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.9.3/8.9.3) with ESMTP id OAA31138 for <[e-mail]>; Tue, 4 Apr 2000 14:17:54 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.1.1 10/15/1999
To: [e-mail]
Subject: ASN.1 Clarification for Son of RFC2459
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 04 Apr 2000 14:17:53 +1000
From: Dean Povey <[e-mail]>

Hi all,

The new Certificate and CRL profile contains an appendix giving some 
implementation guidance with respect to ASN.1.  I would also like to add a 
paragraph here explaining the encoding of BIT STRING, particularly as it 
relates to the KeyUsage extension which is sometimes encoded incorrectly 
according to DER rules (I've made this mistake myself).  

The DER rules for BIT STRING (in addition to the BER rules) from X.690 are:

1. Must use primitive encoding.

2. Unused bits in the final octet string must be zero

However there is a third rule which is often forgotten (in particular it 
is not mentioned in the layman's guide published by RSA labs).

3. Where X.680 21.7 Applies (I'll get to that in a moment), the bitstring 
shall have all trailing zero bits removed before it is encoded.

x.680 21.7 refers to the use of a NamedBitList, in other words where the 
definition also gives some symbolic names to bits.  Note this then applies 
to KeyUsage extension, which is:

KeyUsage ::= BIT STRING {
        digitalSignature     (0),
        nonRepudiation       (1),
        keyEncipherment      (2),
        dataEncipherment     (3),
        keyAgreement         (4),
        keyCertSign          (5),
        cRLSign              (6),
        encipherOnly         (7),
        decipherOnly         (8) }

So in the case of KeyUsage if you do not set decipherOnly the bit string 
should be encoded in a single octet.

NB: I _think_ the following examples are correct :-)

e.g: digitalSignature | nonRepudiation

03 02 06 C0

e.g: decipherOnly

03 03 07 00 80


The first example is sometimes wrongly encoded:

03 02 07 C0 00

Which is correct for BER, but not for DER.

Is there any thoughts about whether it is sensible to add a statement 
about this to Son of RFC2459?

Also another comment, The End-Entity certificate example in Son of RFC 
2459 D.3 has the some of the SEQUENCEs BER encoded, which I don't believe is correct.

Cheers.

-- 
Dean Povey,         | e-m: [e-mail]     | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  [phone]       |  security.dstc.edu.au/ 
Security Unit, DSTC | fax: [phone]       | Oscar - C++ PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24228 for <[e-mail]>; Mon, 3 Apr 2000 12:21:07 -0700 (PDT)
Received: from mega (t3o69p76.telia.com [62.20.145.76]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id VAA24751; Mon, 3 Apr 2000 21:26:25 +0200
Message-ID: <005601bf9db2$e2924700$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re:  Permanent identifiers in QC
Date: Mon, 3 Apr 2000 22:23:40 +0100
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 MAA24229

Tom,

>     But I don't think you answered my questions.  Why is "the serial
>number in the subject DN was assigned by the following naming authority"
>not a valid QC statement?  Also, why are "the serial number in the subject
>DN represents a national identity number" or "the serial number in the
>subject DN was assigned locally by the issuer" not valid QC statements?

I agree that these look like valid QC statements but I doubt that they
are universal enough.   If you need "the serial number + organization in the
subject DN is a permanent ID within the local CA domain" you run into
problems.   We do need some kind of extension but it should be parameterized
to cover different naming schemes.  IMO at least.

Anders
<snip>




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 JAA21953 for <[e-mail]>; Mon, 3 Apr 2000 09:49:35 -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 MAA74082; Mon, 3 Apr 2000 12:50:28 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id MAA152398; Mon, 3 Apr 2000 12:51:55 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B6.005C9EFD ; Mon, 3 Apr 2000 12:51:40 -0400
X-Lotus-FromDomain: IBMUS
To: "Darren Harter" <[e-mail]>
cc: "'Hans Schupp'" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 3 Apr 2000 12:51:32 -0400
Subject: RE: ASN.1 , Constructed Encoding
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     I thought, as you did, that the sensible encoding would have an inner
tag of 0x16 for IA5String.  Unfortunately for this viewpoint, X.690 section
8.20.5.4 gives a VisibleString example with an inner tag of 0x04 rather
than 0x1A.  For that matter, so does X.209 section 23.5.4.
     I'm sorry to have been wrong in the first place, but I hope this
clears up a misconception that I am sure was shared by more than just the
two of us.

          Tom Gindin

"Darren Harter" <[e-mail]> on 04/03/2000 11:51:49 AM

To:   "'Hans Schupp'" <[e-mail]>
cc:   <[e-mail]>, <[e-mail]>
Subject:  RE: ASN.1 , Constructed Encoding



Hans,

[UNIVERSAL X] IMPLICIT OCTET STRING always gets a tag encoded as (in
binary)
001X XXXX where XXXXX is the X in the [UNIVERSAL X].  The IMPLICIT keywords
forces the encoding of OCTET STRING, but not its tag.  So in the case of
IA5String, it is indeed 0x36 when constructed (or part of an explicit
encoding) and 0x16 when not constructed (and not part of an explicit
encoding).

If the definition was IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
instead of IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING you would get
the following:

36 1B 04 19
          36 07 04 05 test1
          36 03 04 01 @
          36 09 04 07 rsa.com

Because it is IMPLICIT the three contained strings fall back to their
default (unconstructed) tags on 0x16, but the outer (constructed) tag stays
a 0x36.  The explicit OCTET STRING tags of 0x04 disappear in this case.

The original poster's encoding was correct as

36 13
     16 05 test1
     16 01 @
     16 07 rsa.com

You are correct in that the only leagal X.690 encoding of this is in a
single non-constructed IA5String with the following encoding:

16 0D [e-mail]

Hope this all helps,

Darren

---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.

Tel: [phone]
Fax: [phone]
Cell:     [phone]

Mail: <mailto:[e-mail]>
Web: <http://www.entegrity.com>

---------------------------------------------------------------------
Visit us on Stand No 654 at Infosecurity 2000 and enter our
FREE competition to WIN A HALF CASE OF CHAMPAGNE!

11-13 April in the National Hall, Olympia Exhibition Centre, London
---------------------------------------------------------------------




-----Original Message-----
From: Hans Schupp [mailto:[e-mail]]
Sent: 03 April 2000 16:08
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: ASN.1 , Constructed Encoding


[e-mail] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)


> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp







Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21496 for <[e-mail]>; Mon, 3 Apr 2000 09:32:58 -0700 (PDT)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA01358; Mon, 3 Apr 2000 18:35:15 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 03 Apr 2000 18:35:15 +0200
From: Hans Schupp <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.7 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Darren Harter <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: ASN.1 , Constructed Encoding
References: <000401bf9d84$87e292c0$[e-mail]>
Content-Type: multipart/mixed; boundary="------------E14A830606770A8F8F917484"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------E14A830606770A8F8F917484
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Darren Harter wrote:

> The IMPLICIT keywords forces the encoding of OCTET STRING, but not
> its tag.  So in the case of IA5String, it is indeed 0x36 when
> constructed (or part of an explicit encoding) and 0x16 when not
> constructed (and not part of an explicit encoding).

Agree. But this is no contradiction to my posting.

> If the definition was 
>   IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
> instead of 
>   IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
> you would get the following:
> 
> 36 1B 04 19
>                 36 07 04 05 test1
>                 36 03 04 01 @
>                 36 09 04 07 rsa.com

No, definitely not.
Please read carefully X.690 paragraph 8.14 ("Encoding of a tagged
value"). You will find, that the encoding of a tagged value is done by
taking the encoding of the base type (OCTET STRING in our discussion)
and adding the explicit tag in front of it.

So the example string encoded as 
  [UNIVERSAL 16] EXPLICIT OCTET STRING
becomes
  36 15 04 13
              04 05 test1
              04 01 @
              04 07 rsa.com

The respective is valid for implicit tagging: the base encoding is
modified by throwing away the original tag and using the new one instead
(while preseving the "constructed" bit).
Please have a look at paragraph 8.14.3 for exact wording.

> Because it is IMPLICIT the three contained strings fall back to
> their default (unconstructed) tags on 0x16, but the outer
> (constructed) tag stays a 0x36.  The explicit OCTET STRING tags
> of 0x04 disappear in this case.
> 
> The original poster's encoding was correct as
> 
> 36 13
>         16 05 test1
>         16 01 @
>         16 07 rsa.com

No. I still stay with my original argument.

The example we use here has great resemblance with the example used in
paragraph 8.20.6 of X.690. That one supports my point of view.

> You are correct in that the only leagal X.690 encoding of this is
> in a single non-constructed IA5String with the following encoding:
> 
> 16 0D [e-mail]

I'm sorry, if my English isn't good enough to make myself clear.
I didn't mean to say _that_, but the following:
Even though the encoding is done in three chunks (which is perfectly
valid in BER, but not in DER), the logical string that is expressed by
this encoding is the same as "[e-mail]" encoded in one chunk.

Best regards,
Hans Schupp

PS: I refer to X.690 (1994 E) aka ISO/IEC 8825-1: 1995 (E)
--------------E14A830606770A8F8F917484
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;Landwehrstr. 50a=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------E14A830606770A8F8F917484--



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20535 for <[e-mail]>; Mon, 3 Apr 2000 08:50:28 -0700 (PDT)
Received: from dharter (d224-110.dial.mistral.co.uk [195.184.224.110]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HZCVT5TN; Mon, 3 Apr 2000 09:01:45 -0700
From: "Darren Harter" <[e-mail]>
To: "'Hans Schupp'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: ASN.1 , Constructed Encoding
Date: Mon, 3 Apr 2000 16:51:49 +0100
Message-ID: <000401bf9d84$87e292c0$[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
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <[e-mail]>

Hans,

[UNIVERSAL X] IMPLICIT OCTET STRING always gets a tag encoded as (in binary)
001X XXXX where XXXXX is the X in the [UNIVERSAL X].  The IMPLICIT keywords
forces the encoding of OCTET STRING, but not its tag.  So in the case of
IA5String, it is indeed 0x36 when constructed (or part of an explicit
encoding) and 0x16 when not constructed (and not part of an explicit
encoding).

If the definition was IA5String ::= [UNIVERSAL 22] EXPLICIT OCTET STRING,
instead of IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING you would get
the following:

36 1B 04 19
		36 07 04 05 test1
		36 03 04 01 @
		36 09 04 07 rsa.com

Because it is IMPLICIT the three contained strings fall back to their
default (unconstructed) tags on 0x16, but the outer (constructed) tag stays
a 0x36.  The explicit OCTET STRING tags of 0x04 disappear in this case.

The original poster's encoding was correct as

36 13
	16 05 test1
	16 01 @
	16 07 rsa.com

You are correct in that the only leagal X.690 encoding of this is in a
single non-constructed IA5String with the following encoding:

16 0D [e-mail]

Hope this all helps,

Darren

---------------------------------------------------------------------
Darren Harter B.Sc. (Hons) MBCS CEng
European Professional Services Group,
Entegrity Solutions Corp.

Tel:	[phone]
Fax:	[phone]
Cell:	[phone]

Mail: <mailto:[e-mail]>
Web: <http://www.entegrity.com>

---------------------------------------------------------------------
Visit us on Stand No 654 at Infosecurity 2000 and enter our
FREE competition to WIN A HALF CASE OF CHAMPAGNE!

11-13 April in the National Hall, Olympia Exhibition Centre, London
---------------------------------------------------------------------




-----Original Message-----
From: Hans Schupp [mailto:[e-mail]]
Sent: 03 April 2000 16:08
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: ASN.1 , Constructed Encoding


[e-mail] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)


> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp




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 IAA19652 for <[e-mail]>; Mon, 3 Apr 2000 08:20:15 -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 LAA343966; Mon, 3 Apr 2000 11:21:39 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id LAA110542; Mon, 3 Apr 2000 11:23:06 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B6.0054825D ; Mon, 3 Apr 2000 11:23:03 -0400
X-Lotus-FromDomain: IBMUS
To: "Stefan Santesson" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 3 Apr 2000 11:22:57 -0400
Subject: Re: SV: SV: Permanent identifiers in QC
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 IAA19653

     But I don't think you answered my questions.  Why is "the serial
number in the subject DN was assigned by the following naming authority"
not a valid QC statement?  Also, why are "the serial number in the subject
DN represents a national identity number" or "the serial number in the
subject DN was assigned locally by the issuer" not valid QC statements?
     These are certainly "defined statements related to Qualified
Certificates", and there is no other place for them in the certificate.  If
qcStatements are restricted purely to statements of policy, why is not the
extension redundant with the existing policy extension?  The present
solution does NOT provide for statements of this sort to go into the
certificate except insofar as an OTHER-NAME could be defined outside the
profile, and to say that it does so "as far as it ought to" is to say that
there should be no standard way of putting them in.  Note that Russ
Housley, at least, is opposed to putting any new name forms into either
profile.
     Your example of the qualifying information is, in fact, a case of
either "assigned by the following naming authority" or "represents a
national identity number".  If these features are to be made widely
interoperable, the object identifiers should be in one of the common
profiles.  I agree that we should move forward, but with this feature
rather than without it.

          Tom Gindin

"Stefan Santesson" <[e-mail]> on 04/03/2000 07:49:16 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[e-mail]>
Subject:  SV: SV: Permanent identifiers in QC



Tom,

I support your concerns.

I believe though that what the present solution already handles the issues
that you are addressing. At least as far as it ought to.

The qcStatemsnts extension are there to express policy statements. The
predefined statement is there to express that the certificate follows
syntax
and semantics of the QC profile. The optional qualifying information may
hold information that the certificate further adopts to a certain ID-scheme
(such as a specific Italian ID-scheme).

I don't think we should expand that feature beyond that.

What I think we should do know is to move this forward.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]]
> Skickat: den 1 april 2000 09:14
> Till: Stefan Santesson
> Kopia: [e-mail]
> Ämne: Re: SV: Permanent identifiers in QC
>
>
>      I take your point about duplicating the serial number using the
> two-name form I proposed for
> id-qcs-identifierAssignmentAuthority, and I
> hereby withdraw that suggestion.
>      However, assuming that adding name information in the
> qcStatements
> extension contradicts the purpose of that extension, I still
> do not see why
> the one-name version of id-qcs-identifierAssignmentAuthority,
> in which the
> only name in the extension is the name of the identifier assignment
> authority, contradicts the purpose of the extension.  The
> draft's current
> definition says about the name component: "The
> NameRegistrationAuthorities
> component, if present, SHALL contain a name of one or more name
> registration authorities, responsible for registration of
> attributes or
> names associated with the subject."  Why does the assigner of a serial
> number not fit into this definition of a registration authority?
>      Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
> semantics of an existing attribute in a DN within the
> certificate.  How
> does that contradict the statement that a semantics ID "may define
> semantics for all, or for a subgroup of all present attributes and/or
> names"?  Perhaps it would be more in keeping with the spirit
> of the profile
> if there were two different OID's for each of these three
> semantics, one to
> interpret subject name serial numbers and one to interpret subject
> alternate name serial numbers, but that is not a reason not
> to have the
> feature available.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[e-mail]> on 03/31/2000 06:45:54 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
>       <[e-mail]>
> cc:   <[e-mail]>
> Subject:  SV: Permanent identifiers in QC
>
>
>
> Tom,
>
> Using this extension to contain subject name information
> would break the
> intent of this extension.
>
> /Stefan
>
> > -----Ursprungligt meddelande-----
> > Från: [e-mail] [mailto:[e-mail]]
> > Skickat: den 31 mars 2000 09:10
> > Till: Stefan Santesson
> > Kopia: [e-mail]
> > Ämne: Re: Permanent identifiers in QC
> >
> >
> >      I have a counter-proposal.  Given the profile defined for
> > serialNumber, and the definition of SemanticsInformation in
> > draft section
> > 3.2.5.1, a semanticsIdentifier known as
> > id-qcs-identifierAssignmentAuthority should be assigned with
> > the following
> > rules of interpretation: either one or two name registration
> > authorities
> > must be present, and the first one present shall be
> interpreted as the
> > authority governing the name space, while the second
> > (optional) one may
> > contain the serial number or other unique identifier; if
> > there is only one
> > name registration authority present, the unique identifier is
> > assumed to be
> > the serial number attribute of the subject name if there is a
> > serial number
> > attribute in it, and the first serial number attribute
> > encountered in the
> > subject alternate name if there is none in the subject
> name.  Another
> > semanticsIdentifier known as id-qcs-CALocal should be
> > assigned to identify
> > serial numbers assigned locally within the CA.  Optionally, a
> > semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> > assigned with the rule that when one searches for the serial
> > number in the
> > subject name and subject alternate name in the same way as
> > for identifier
> > assignment authorities with only one name registration
> authority, the
> > serial number shall be interpreted as being assigned by the
> > country given
> > in the DN where the serial number is found.
> >
> >           Tom Gindin
> >
> >
> > "Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM
> >
> > To:   <[e-mail]>
> > cc:
> > Subject:  Permanent identifiers in QC
> >
> >
> >
> > The PKIX meeting in Adelaide raised only 1 issue related to
> > the QC draft.
> >
> > This issue is whether we should include a new name form in the
> > subjectAltName extension holding  a permanent identifier.
> >
> > The permanent identifier would then be a name of the subject,
> > unique within
> > the issuers domain, that is not reused over time for
> another subject.
> >
> > The reason to include such a name form would be that the use of
> > serialNumber in DN, or directoryName in subjectAltName
> > extension, does not
> > explicitly define this property by itself, unless seen in the
> > light of a
> > defined policy etc.
> >
> > Chair Stephen Kent decided that the decision whether or not
> > to include this
> > name form in QC should be taken to the list.
> >
> > My observation in regards to this is:
> >
> > 1) Adding this name form would add confusion to the QC
> > specification since
> > it would overlap use of serialNumber in the DN.
> >
> > [Tom Gindin]   Why would this cause confusion if the name
> > form itself had
> > the same syntax as a DN, and the identity were in the serialNumber
> > attribute of that name?
> >
> > 2) Use of DN attributes covers all needs related to
> > identification of the
> > subject, and that's all we need to support electronic
> > signatures, at least
> > as seen from the EU-directive. And as far I know, this goes
> > for any other
> > legal system.
> >
> > [Tom Gindin]   This does not cover the joint specification of
> > an ID and an
> > assignment authority.  A single ID field with quasi-arbitrary values
> > similar to a serial number has meaning primarily within the
> > scope of its
> > assignment authority.
> >
> > 3) Use of DN in combination with either implicit knowledge, use of
> > Directory name in the subjectAltname ext, use of a related policy
> > identifier or use of information in the qcStatements
> > extension also provide
> > support for use of permanent identifiers identified as such.
> >
> > [Tom Gindin]   No rule for implicit knowledge which would permit an
> > arbitrary RP to recognize a permanent identifier and its assignment
> > authority within a DN (whether subject name or alt name)
> has yet been
> > received with favor.  However, it should be possible to do
> > this using the
> > semanticsIdentifier.
> >
> > 4) In each and every case raised in favor of this new name form, the
> > benefit relates to access control rather than electronic signatures.
> >
> > [Tom Gindin]   Allowing organizations to assign permanent
> > identifiers of
> > this type (most usually, but not necesarily, to employees)
> > has roughly the
> > same impact on signatures as on access control.  If it is
> > assumed that the
> > identity number is assigned by a governmental or quasi-governmental
> > authority, then the serial number is sufficient because my
> > above arguments
> > for assignment authority become irrelevant.
> >
> > 5) This is a new input to the discussion, which before
> > adoption must be
> > reviewed by the community over some time.
> >
> > [Tom Gindin]   It has been under discussion for months.
> >
> > Observation 4 makes this whole discussion outside the scope
> > of QC and in
> > combination with the other observations, I would request that
> > the QC is
> > moved forward to proposed standard without this new name form.
> >
> > [Tom Gindin]   If QC requires that the serial number be
> > assigned either by
> > a governmental or quasi-governmental authority as a permanent
> > identifier or
> > by the CA as a tiebreaker, and that the certificate itself contain
> > somewhere an indicator of whether the name is a permanent
> > identifier or a
> > tiebreaker, then this name form would not be relevant to
> > QC's.  Otherwise
> > it would.
> >
> > If PKIX at a later stage would find that a permanent
> > identifier solution,
> > as discussed here, is of general value, then this can be
> > moved forward as a
> > separate item. At that time we would also know if it should
> > be merged with
> > RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> > /Stefan
> >
>
>
>






Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19200 for <[e-mail]>; Mon, 3 Apr 2000 08:06:31 -0700 (PDT)
Received: from secude.com (ip27.secude.com [141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id RAA17811; Mon, 3 Apr 2000 17:08:09 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 03 Apr 2000 17:08:09 +0200
From: Hans Schupp <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.7 [de] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: ASN.1 , Constructed Encoding
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------357AC187ABCE6F8B37C4A970"

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------357AC187ABCE6F8B37C4A970
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[e-mail] wrote

>      The 0x20 bit of the tag byte (or the tag first byte when the
> tag value is 31 or above) means "constructed".  Thus a constructed
> IA5 string will have an outer tag of 0x36 and an inner tag of 0x16,

Wrong.
At least if one sticks to X.690, where the encoding of ASN.1 character
strings is defined. There it says, that each character string is encoded
as if it were defined [UNIVERSAL x] IMPLICIT OCTET STRING
This results in the inner tag being 0x04!

> a constructed octet string will have an outer tag of 0x24 and an
> inner tag of 0x04, and a constructed bit string with definition
> [2] IMPLICIT BIT STRING would have an outer tag of 0xA2 and an inner
> tag of 0x03 while a primitive with that definition would have a tag
> of 0x82.

Correct. :-)


> 36 13
>      16 05 74 65 73 74 31
>      16 01 40
>      16 07 72 73 61 2e 63 6f 6d

Given the above argument, this encoding is not correct. It should be
36 13
      04 05 74 65 73 74 31
      04 01 40
      04 07 72 73 61 2e 63 6f 6d

> And also please let me know  If there is any delimeter for
> words apart from @.

The '@' character is no delimiter here. The string can be divided at
arbitrary places (i.e. the character at this position doesn't mean
anything).
Logically, the whole thing is still one string, it is only the encoding,
that is split into several parts.

Hope it helps,
Hans Schupp
--------------357AC187ABCE6F8B37C4A970
Content-Type: text/x-vcard; charset=us-ascii;
 name="schupp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für Hans Schupp
Content-Disposition: attachment;
 filename="schupp.vcf"

begin:vcard 
n:Schupp;Hans
tel;cell:(+49) 177 / 2452088 (private)
tel;fax:(+49) 6151 / 82897 - 26
tel;work:(+49) 6151 / 82897 - 37
x-mozilla-html:FALSE
url:http://www.secude.com
org:<hr size=1><p align=right><b><font color=green>SECUDE</font></b> <i>Sicherheitstechnologie<br>Informationssysteme GmbH<br><font color=green>e-security for e-business</font></i>
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;Landwehrstr. 50a=0D=0A;Darmstadt;;D-64293;Germany
fn:Hans Schupp
end:vcard

--------------357AC187ABCE6F8B37C4A970--



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 HAA18672 for <[e-mail]>; Mon, 3 Apr 2000 07:50:13 -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 KAA111876; Mon, 3 Apr 2000 10:51:33 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA138690; Mon, 3 Apr 2000 10:53:00 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B6.0051BEBC ; Mon, 3 Apr 2000 10:52:52 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 3 Apr 2000 10:51:59 -0400
Subject: Re: ASN.1 , Constructed Encoding
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     The 0x20 bit of the tag byte (or the tag first byte when the tag value
is 31 or above) means "constructed".  Thus a constructed IA5 string will
have an outer tag of 0x36 and an inner tag of 0x16, a constructed octet
string will have an outer tag of 0x24 and an inner tag of 0x04, and a
constructed bit string with definition [2] IMPLICIT BIT STRING would have
an outer tag of 0xA2 and an inner tag of 0x03 while a primitive with that
definition would have a tag of 0x82.
     Maybe somebody else can answer you about word delimiters, since I'm
not sure what you mean.  An IA5String can contain many different non-text
characters which you could interpret as word delimiters, including space,
period (which is in your example), and many more.

          Tom Gindin


"chandrasekaran natarajan" <[e-mail]> on 04/03/2000
10:11:36 AM

Please respond to [e-mail]

To:   [e-mail]
cc:
Subject:  ASN.1 , Constructied Encoding



hello,

can any one clear my doubts regarding ASN.1 constructed encoding . Its as
follows

Given a IA5String  value "[e-mail]" and constructed
encoding as

36 13
     16 05 74 65 73 74 31
     16 01 40
     16 07 72 73 61 2e 63 6f 6d

can some one let me know how the first entry 36 is
got ? Is it a Implementor Defined Tag or has it been
Standardised for IA5Strings with Constructed encoding.

And also please let me know  If there is any delimeter for
words apart from @.

Thanks

chandar




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 HAA18573 for <[e-mail]>; Mon, 3 Apr 2000 07:48:33 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com.au ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA28463 for <[e-mail]>; Mon, 3 Apr 2000 07:50:54 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sat, 01 Apr 2000 02:51:46 -0500
To: <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Permanent identifiers in QC
In-Reply-To: <03E49309E8F5D31183F7000629396ECCD61C@TRUST>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I cannot see any reason for PKIX to specify a permanent identifier.

In my view, it is the job of PKIX (in the son-of-RFC2459 document and the 
companion QC document) to specify the means to bind an identity to a public 
key.  This does not include specifying new methods of specifying an 
identity.  If some Internet application needs a permanent identifier, then 
the needy application should specify it.  Once it is specified, it can be 
used in certificates, just like all of the other name forms that are 
already supported.

Russ


At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
>The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.
>
>This issue is whether we should include a new name form in the
>subjectAltName extension holding  a permanent identifier.
>
>The permanent identifier would then be a name of the subject, unique within
>the issuers domain, that is not reused over time for another subject.
>
>The reason to include such a name form would be that the use of serialNumber
>in DN, or directoryName in subjectAltName extension, does not explicitly
>define this property by itself, unless seen in the light of a defined policy
>etc.
>
>Chair Stephen Kent decided that the decision whether or not to include this
>name form in QC should be taken to the list.
>
>My observation in regards to this is:
>
>1) Adding this name form would add confusion to the QC specification since
>it would overlap use of serialNumber in the DN.
>
>2) Use of DN attributes covers all needs related to identification of the
>subject, and that's all we need to support electronic signatures, at least
>as seen from the EU-directive. And as far I know, this goes for any other
>legal system.
>
>3) Use of DN in combination with either implicit knowledge, use of Directory
>name in the subjectAltname ext, use of a related policy identifier or use of
>information in the qcStatements extension also provide support for use of
>permanent identifiers identified as such.
>
>4) In each and every case raised in favor of this new name form, the benefit
>relates to access control rather than electronic signatures.
>
>5) This is a new input to the discussion, which before adoption must be
>reviewed by the community over some time.
>
>Observation 4 makes this whole discussion outside the scope of QC and in
>combination with the other observations, I would request that the QC is
>moved forward to proposed standard without this new name form.
>
>If PKIX at a later stage would find that a permanent identifier solution, as
>discussed here, is of general value, then this can be moved forward as a
>separate item. At that time we would also know if it should be merged with
>RFC 2459 or the QC profile, if merged at all.
>
>
>
>/Stefan



Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17916 for <[e-mail]>; Mon, 3 Apr 2000 07:20:08 -0700 (PDT)
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Apr  3 07:11:36 2000
To: [e-mail]
Date: Mon, 03 Apr 2000 07:11:36 -0700
From: "chandrasekaran natarajan" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
Reply-To: [e-mail]
X-Mailer: MailCity Service
Subject: ASN.1 , Constructied Encoding 
X-Sender-Ip: 203.197.240.30
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit

hello,

can any one clear my doubts regarding ASN.1 constructed encoding . Its as follows 

Given a IA5String  value "[e-mail]" and constructed
encoding as

36 13
     16 05 74 65 73 74 31
     16 01 40
     16 07 72 73 61 2e 63 6f 6d

can some one let me know how the first entry 36 is 
got ? Is it a Implementor Defined Tag or has it been
Standardised for IA5Strings with Constructed encoding.

And also please let me know  If there is any delimeter for
words apart from @.

Thanks

chandar


Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA17332 for <[e-mail]>; Mon, 3 Apr 2000 06:41:41 -0700 (PDT)
From: [e-mail]
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA46440 for <[e-mail]>; Mon, 3 Apr 2000 09:36:01 -0500
Received: from d54mta05.raleigh.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id JAA27170 for <[e-mail]>; Mon, 3 Apr 2000 09:44:24 -0400
Received: by d54mta05.raleigh.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 852568B6.004B7931 ; Mon, 3 Apr 2000 09:44:22 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 3 Apr 2000 09:44:16 -0400
Subject: Re: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

unsubscribe




Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15746 for <[e-mail]>; Mon, 3 Apr 2000 05:24:33 -0700 (PDT)
Received: from santesson (par-c45-003-vty165.as.wcom.net [195.232.67.165]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id OAA19364; Mon, 3 Apr 2000 14:26:16 +0200
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: SV: SV: Permanent identifiers in QC
Date: Mon, 3 Apr 2000 21:19:16 +0930
Message-ID: <000001bf9d67$88285480$3d0cfea9@santesson>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

Tom,

I support your concerns.

I believe though that what the present solution already handles the issues
that you are addressing. At least as far as it ought to.

The qcStatemsnts extension are there to express policy statements. The
predefined statement is there to express that the certificate follows syntax
and semantics of the QC profile. The optional qualifying information may
hold information that the certificate further adopts to a certain ID-scheme
(such as a specific Italian ID-scheme).

I don't think we should expand that feature beyond that.

What I think we should do know is to move this forward.

/Stefan

> -----Ursprungligt meddelande-----
> Från: [e-mail] [mailto:[e-mail]]
> Skickat: den 1 april 2000 09:14
> Till: Stefan Santesson
> Kopia: [e-mail]
> Ämne: Re: SV: Permanent identifiers in QC
>
>
>      I take your point about duplicating the serial number using the
> two-name form I proposed for
> id-qcs-identifierAssignmentAuthority, and I
> hereby withdraw that suggestion.
>      However, assuming that adding name information in the
> qcStatements
> extension contradicts the purpose of that extension, I still
> do not see why
> the one-name version of id-qcs-identifierAssignmentAuthority,
> in which the
> only name in the extension is the name of the identifier assignment
> authority, contradicts the purpose of the extension.  The
> draft's current
> definition says about the name component: "The
> NameRegistrationAuthorities
> component, if present, SHALL contain a name of one or more name
> registration authorities, responsible for registration of
> attributes or
> names associated with the subject."  Why does the assigner of a serial
> number not fit into this definition of a registration authority?
>      Equally, id-qcs-nationalIdentifier and id-qcs-CALocal define the
> semantics of an existing attribute in a DN within the
> certificate.  How
> does that contradict the statement that a semantics ID "may define
> semantics for all, or for a subgroup of all present attributes and/or
> names"?  Perhaps it would be more in keeping with the spirit
> of the profile
> if there were two different OID's for each of these three
> semantics, one to
> interpret subject name serial numbers and one to interpret subject
> alternate name serial numbers, but that is not a reason not
> to have the
> feature available.
>
>           Tom Gindin
>
>
> "Stefan Santesson" <[e-mail]> on 03/31/2000 06:45:54 AM
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stefan Santesson'"
>       <[e-mail]>
> cc:   <[e-mail]>
> Subject:  SV: Permanent identifiers in QC
>
>
>
> Tom,
>
> Using this extension to contain subject name information
> would break the
> intent of this extension.
>
> /Stefan
>
> > -----Ursprungligt meddelande-----
> > Från: [e-mail] [mailto:[e-mail]]
> > Skickat: den 31 mars 2000 09:10
> > Till: Stefan Santesson
> > Kopia: [e-mail]
> > Ämne: Re: Permanent identifiers in QC
> >
> >
> >      I have a counter-proposal.  Given the profile defined for
> > serialNumber, and the definition of SemanticsInformation in
> > draft section
> > 3.2.5.1, a semanticsIdentifier known as
> > id-qcs-identifierAssignmentAuthority should be assigned with
> > the following
> > rules of interpretation: either one or two name registration
> > authorities
> > must be present, and the first one present shall be
> interpreted as the
> > authority governing the name space, while the second
> > (optional) one may
> > contain the serial number or other unique identifier; if
> > there is only one
> > name registration authority present, the unique identifier is
> > assumed to be
> > the serial number attribute of the subject name if there is a
> > serial number
> > attribute in it, and the first serial number attribute
> > encountered in the
> > subject alternate name if there is none in the subject
> name.  Another
> > semanticsIdentifier known as id-qcs-CALocal should be
> > assigned to identify
> > serial numbers assigned locally within the CA.  Optionally, a
> > semanticsIdentifier known as id-qcs-nationalIdentifier might also be
> > assigned with the rule that when one searches for the serial
> > number in the
> > subject name and subject alternate name in the same way as
> > for identifier
> > assignment authorities with only one name registration
> authority, the
> > serial number shall be interpreted as being assigned by the
> > country given
> > in the DN where the serial number is found.
> >
> >           Tom Gindin
> >
> >
> > "Stefan Santesson" <[e-mail]> on 03/30/2000 01:49:44 AM
> >
> > To:   <[e-mail]>
> > cc:
> > Subject:  Permanent identifiers in QC
> >
> >
> >
> > The PKIX meeting in Adelaide raised only 1 issue related to
> > the QC draft.
> >
> > This issue is whether we should include a new name form in the
> > subjectAltName extension holding  a permanent identifier.
> >
> > The permanent identifier would then be a name of the subject,
> > unique within
> > the issuers domain, that is not reused over time for
> another subject.
> >
> > The reason to include such a name form would be that the use of
> > serialNumber in DN, or directoryName in subjectAltName
> > extension, does not
> > explicitly define this property by itself, unless seen in the
> > light of a
> > defined policy etc.
> >
> > Chair Stephen Kent decided that the decision whether or not
> > to include this
> > name form in QC should be taken to the list.
> >
> > My observation in regards to this is:
> >
> > 1) Adding this name form would add confusion to the QC
> > specification since
> > it would overlap use of serialNumber in the DN.
> >
> > [Tom Gindin]   Why would this cause confusion if the name
> > form itself had
> > the same syntax as a DN, and the identity were in the serialNumber
> > attribute of that name?
> >
> > 2) Use of DN attributes covers all needs related to
> > identification of the
> > subject, and that's all we need to support electronic
> > signatures, at least
> > as seen from the EU-directive. And as far I know, this goes
> > for any other
> > legal system.
> >
> > [Tom Gindin]   This does not cover the joint specification of
> > an ID and an
> > assignment authority.  A single ID field with quasi-arbitrary values
> > similar to a serial number has meaning primarily within the
> > scope of its
> > assignment authority.
> >
> > 3) Use of DN in combination with either implicit knowledge, use of
> > Directory name in the subjectAltname ext, use of a related policy
> > identifier or use of information in the qcStatements
> > extension also provide
> > support for use of permanent identifiers identified as such.
> >
> > [Tom Gindin]   No rule for implicit knowledge which would permit an
> > arbitrary RP to recognize a permanent identifier and its assignment
> > authority within a DN (whether subject name or alt name)
> has yet been
> > received with favor.  However, it should be possible to do
> > this using the
> > semanticsIdentifier.
> >
> > 4) In each and every case raised in favor of this new name form, the
> > benefit relates to access control rather than electronic signatures.
> >
> > [Tom Gindin]   Allowing organizations to assign permanent
> > identifiers of
> > this type (most usually, but not necesarily, to employees)
> > has roughly the
> > same impact on signatures as on access control.  If it is
> > assumed that the
> > identity number is assigned by a governmental or quasi-governmental
> > authority, then the serial number is sufficient because my
> > above arguments
> > for assignment authority become irrelevant.
> >
> > 5) This is a new input to the discussion, which before
> > adoption must be
> > reviewed by the community over some time.
> >
> > [Tom Gindin]   It has been under discussion for months.
> >
> > Observation 4 makes this whole discussion outside the scope
> > of QC and in
> > combination with the other observations, I would request that
> > the QC is
> > moved forward to proposed standard without this new name form.
> >
> > [Tom Gindin]   If QC requires that the serial number be
> > assigned either by
> > a governmental or quasi-governmental authority as a permanent
> > identifier or
> > by the CA as a tiebreaker, and that the certificate itself contain
> > somewhere an indicator of whether the name is a permanent
> > identifier or a
> > tiebreaker, then this name form would not be relevant to
> > QC's.  Otherwise
> > it would.
> >
> > If PKIX at a later stage would find that a permanent
> > identifier solution,
> > as discussed here, is of general value, then this can be
> > moved forward as a
> > separate item. At that time we would also know if it should
> > be merged with
> > RFC 2459 or the QC profile, if merged at all.
> >
> >
> >
> > /Stefan
> >
>
>
>



Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA14570 for <[e-mail]>; Mon, 3 Apr 2000 04:08:27 -0700 (PDT)
Received: from abstracon.se (d212-151-33-241.swipnet.se [212.151.33.241])  by mb04.swip.net (8.8.8/8.8.8) with ESMTP  id NAA11387 for <[e-mail]>;  Mon, 3 Apr 2000 13:11:17 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Mon, 03 Apr 2000 13:12:34 +0200
From: Arne Nilsson <[e-mail]>
Reply-To: [e-mail]
Organization: Abstracon
X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
X-Accept-Language: sv,en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

unsubscribe



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 DAA14112 for <[e-mail]>; Mon, 3 Apr 2000 03:55:20 -0700 (PDT)
Received: from ritlabs250.mldnet.com (max [212.56.194.250]) by gate.ritlabs.com (8.8.8/8.8.8) with ESMTP id OAA16348 for <[e-mail]>; Mon, 3 Apr 2000 14:00:44 +0300
Date: Mon, 3 Apr 2000 13:58:04 +0300
From: Maxim Masiutin <[e-mail]>
X-Mailer: The Bat! (v1.42 Beta/10)
Organization: RIT Research Labs
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Incorporaion of PGP Certificates into X.509v3 Certificates.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello!

   I tried to submit "Incorporaion of PGP Certificates into X.509v3
   Certificates" draft, but it was IETF meeting. I post my draft here
   until IETF will be ready to accept new drafts. You comments are very
   welcome.

Internet Draft                                      M. Masiutin
                                                    RITLABS
April 3, 2000
expires in six months


   Incorporaion of PGP Certificates into X.509v3 Certificates.

   Copyright 2000 by The Internet Society. All Rights Reserved.


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts. Internet-Drafts are draft
   documents valid for a maximum of six months and may be updated,
   replaced, or obsoleted by other documents at any time. It is
   inappropriate to use Internet-Drafts as reference material or to cite
   them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   There were currently no described provisions to convert from an
   X.509v3 certificate to a PGP Certificate and vice versa because of
   format of data being signed differ in these two standards. This
   document defines a new X.509v3 certificate extension called pgpKey
   that holds a verbatim PGP Certificate, making such conversion
   possible.

   This draft is being discussed on the "[e-mail]" mailing
   list. To join the list, send a message to <[e-mail]>
   with the single word "subscribe" in the body of the message. Also,
   there is a Web site for the mailing list at
   <http://www.imc.org/ietf-pkix>.


Definitions, Abbreviations, and Symbols

   UserID

     Data that is intended to represent the name and email address of
     the key holder.

   KeyMaterial
  
     Public key material, i.e. data used as a key in encryption and/or
     signature checking operation.

   PubKey

     KeyMaterial and one or more associated user UserIDs.

   PGPCert

     Also referred as Transferable PGP Certificate. Signed PubKey; after
     each UserID, zero or more signatures (certifications) follow.

   X509Cert

     X.509v3 certificate, as defined in [X509] secion 4.

   X509NativeCert

     X.509v3 certificate, without PGPKey extension.
   
   X509PGPCert

     X.509v3 certificate, with PGPKey extension.

   S/MIME

     Secure/Multipurpose Internet Mail Extensions
     
   PGP/MIME

     Pretty Good Privacy/Multipurpose Internet Mail Extensions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD].

   The key words starting with X509- are defined in [X509] without X509-
   prefix.

     
Introduction

   There are currently two actively proposed methods for providing
   security services for e-mail: S/MIME and PGP/MIME. Both methods
   are based on RFC's that have IETF standards track status.

   PGP/MIME is based on [OpenPGP] message and certificate formats that
   were derived from [PGPOld] formats. These formats were created from
   scratch, and use simple binary encoding. [PGPOld] defines [RSA],
   [IDEA] and [MD5] algorithms as mandatory. OpenPGP makes these
   algorithms optional.

   S/MIME was originally developed by RSA Data Security, Inc. It is
   based on the [CMS] data format for the messages, and the [X509]
   format for certificates. [CMS] is a successor of [PKCS7]. [PKCS7] is
   based on the [ASN1] DER format for data.

   Of course, having two protocols that do the same thing is much worse
   than having one. Although they offer similar services to users, the
   two protocols have very different formats. Further, and more
   important to users, they have different formats for their
   certificates. This means that not only can users of one protocol not
   communicate with the users of the other, they also cannot share
   authentication certificates.

   This document defines a combined format of certificates. It also
   proposes a solution for applications that support both S/MIME and
   PGP/MIME.

   Applications that support both S/MIME and PGP/MIME get a possibility
   to have a single repository that keeps not only X509NativeCerts but
   also X509PGPCerts converted from PGPCerts. No separate
   [OpenPGP]-compatible public keyrings is needed in that case, thus
   such keyrings as well as single PGPCerts may be imported from and
   exported to that repository. There is no need of two different user
   interfaces for X509Cert repository and [OpenPGP]-keyring. Users of
   such applications may not even know the differences between S/MIME
   and PGP/MIME, X509Cert and PGPCert.


Implementing this specification
   
   Implementation of this specification must be done in such manner that
   it should not contradict with provisions of [OpenPGP], [X509] and
   [ESS].


Certificate Extension

   This document defines a new X509Cert extension called pgpKey that
   holds a verbatim PGPCert. Same KeyMaterial and keyholder's data is
   packed in X509Cert and PGPCert, but different packing methods are
   used, to conform both [OpenPGP] and [X509] standards.

   Defined extension is in full conformance with X509-Extension and MUST
   be non-critical. As each extension includes an associated object
   identifier (OID) and an [ASN1] structure, pgpKey extension has the
   following [ASN1] definition:

   id-ce-pgpKey OBJECT IDENTIFIER  ::= {??????????}

   pgpKey  ::= SEQUENCE {
     pgpKeyContents        pgpKeyContentsChoice
   }

   pgpKeyContentsChoice  ::= CHOICE
     pgpKeySingleVersion     [0] OCTET STRING
     pgpKeyAlternative       [1] pgpKeyAlternativeVersions }

   pgpKeyAlternativeVersions  ::= SEQUENCE
     pgpKeySignV3           OCTET STRING,
     pgpKeySignV4           OCTET STRING}

   If an OpenPGP certificate is available in two versions, [PGPOld]
   (for compatibility with old applications) and [OpenPGP] (allowing
   signature extensions), pgpKeyAlternative should be choosen. Otherwise,
   pgpKeySingleVersion should be choosen.


Data Being Certified

   There are some restrictions on X509-subject structure for
   X509PGPCert. X509-subject MUST contain a single DistinguishedName in
   an X509-RDNSequence. X509-RelativeDistinguishedName MUST contain a
   single occurrence of type X509-emailAddress, X509-id-at-name, and
   X509-id-at-commonName, which are defines in [X509]. Value of
   X509-emailAddress MUST match X509-subjectAltName extension. No UTF-8
   strings are allowed. No characters that require quoting in [RFC822]
   e-mail address are allowed by this specification, although there are
   no restrictions on format of other data containded in
   X509-RelativeDistinguishedName. Value of X509-emailAddress MUST match
   X509-id-at-commonName. Incorporated OpenPGP certificate MUST have at
   least one UserID packet bound to the same public key which is packed
   into X509-SubjectPublicKeyInfo. Although OpenPGP format makes no
   restriction on contents of UserID packet (chapter 5.11 of [OpenPGP]),
   this specification does define, in a form of [ABNF]-like notation

   User-ID = X509-id-at-name " <" X509-emailAddress ">"

   Contents of UserID of incorporated PGPCert MUST be formed by a rule
   described above. This UserID must be associated with the same
   KeyMaterial as in X509-SubjectPublicKeyInfo, and signed by the same
   issuer's key. Issuer's key is identified by AuthorityKeyIdentifier
   extension. Other UserIDs may also exist in an incorporated PGPcert.


Choosing between pgpKeySingleVersion and pgpKeyAlternativeVersions

   When pgpKey extension is assembled for a new X509Cert certificate
   that is created along with a new PGPCert, and it is possible to
   produce a PGPCert readable by [PGPOld]-applications,
   pgpKeyAlternativeVersions should be choosen. PubKey should be signed
   using Version 3 and Version 4 OpenPGP Signature Packets, resulting
   two PGPCerts. This can be done, for example, by a certification
   authority using data presented in a certification request, or by an
   end-user application that generates a self-signed certificate.

   When pgpKey certificate extension is created from an existing
   PGPCert, or when it is unable to produce a PGPCert readable by
   [PGPOld]-applications (e.g. [RSA] algorithm is unavailable or
   undesirable), pgpKeySingleVersion should be choosen. Such PgpCert
   should be put inside OCTET STRING of pgpKeySingleVersion, regardless
   versions of signature packets used. Unnecessary or untrusted UserIDs
   and/or signatures may be stripped. This can be done, for example, by
   an applications that support both S/MIME, PGP/MIME, when a user
   imports a PGPCert taken from a PGP keyserver into a X509Cert
   repository of his/her e-mail client.


pgpKeyAlternative

   pgpKeyAlternative holds two versions of OpenPGP certificate, one of
   which MUST be in full conformance with [PGPOld], other SHOULD contain
   OpenPGP Signature Packets Version 4 with possible subpackets.

   As [RSA] algorithm is mandatory by [PGPOld], pgpKeyAlternative may
   only occur in X509Certs that use [RSA] public keys, i.e.
   signatureAlgorithm must be [RSA]-based. Examples are [RSA]-based
   signature algorithm identifiers ([ASN1] OIDS) are
   md2WithRSAEncryption, md5WithRSAEncryption and sha1WithRSAEncryption
   (see Security Issues chapter).

   KeyMaterial, associated UserIDs, signing keys, and all other data,
   such as number of UserIDs and signatures, as well as order of packets
   above mentioned, used to produce a PGPCert for pgpKeySignV3 MUST also
   be used without a change or addition to produce a PGPCert for
   pgpKeySignV4. OpenPGP certificate of pgpKeySignV4 may contain
   signature subpacket(s) that are not allowed by version 3 of OpenPGP
   Signature Packet Format.

   To produce a valid pgpKeyAlternative, [RSA] KeyMaterial and
   associated User IDs should be:

   1) signed using PGP Signature Packet Version 3 as defined in Section
   5.2.2 of [OpenPGP] by means of algorithms required by [PGPOld] ([RSA]
   and [MD5]) making it readable by [PGPOld]-applications. Resulting
   PGPCert should be put inside OCTET STRING of pgpKeySignV3.

   2) signed using OpenPGP Signature Packet Version 4 with all possible
   subpackets as defined in Section 5.2.3 of [OpenPGP], making it
   readable by [OpenPGP]-applications. The same [RSA] KeyMaterial as for
   previous step should be used to produce a signature, but a different
   hashing method is allowed. Resulting OpenPGP certificate should put
   be inside OCTET STRING of pgpKeySignV4.


Converting from existing PgpCert
   
   Primary KeyMaterial and primary UserID of a given PgpCert are used to
   form the X509-subject and X509-subjectPublicKeyInfo members of
   X509-TBSCertificate. An application may display a dialog of choices,
   allowing user to select which UserID is primary. An application
   should also validate signatures of UserIDs. Selected UserId is
   parsed, according to [RFC822], to extract a user name and an e-mail
   address. If it was unable to extract a valid e-mail address, an
   application shouldn't convert given PgpCerts. Extracted data should
   be used to produce a valid X509-subject structure, as defined in
   "Data Being Certified" chapter.

   If it was unable to extract a valid user name, but an e-mail was
   extracted, an application should copy this e-mail string to all
   fields containing user name that are mandatory by this document or
   may be mandatory by other documents.


Security Considerations

   All security considerations from [OpenPGP], [X509] and [ESS] apply to
   applications that use procedures described in this document. Security
   rules for X509PGPCert are the same as for a pair of a separate
   PGPCert and a separate X509NativeCert.

   As md2WithRSAEncryption is referred in this document, it SHOULD not
   be used. As about md5WithRSAEncryption and sha1WithRSAEncryption, the
   [MD5] hash algorithm has been found to have weaknesses
   (pseudo-collisions in the compress function) that make some people
   deprecate its use. They consider the [SHA1] algorithm better.


References

   [ASN1]

      CCITT Recommendation X.208: Specification of Abstract Syntax
      Notation One (ASN.1), 1988.

   [SHA1]

     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.


   [IDEA]

     Lai, X, "On the design and security of block ciphers", ETH Series
     in Information Processing, J.L. Massey (editor), Vol. 1,
     Hartung-Gorre Verlag Knostanz, Technische Hochschule (Zurich), 1992

   [MD5]

     The MD5 Message-Digest Algorithm. R. Rivest. April 1992. RFC1321.

   [RSA]

     PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski,
     J. Staddon. October 1998. RFC2437.

   [RFC2234]

     Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P.
     Overell. November 1997. RFC2234.
   

   [RFC822]

     Standard for the format of ARPA Internet text messages. D. Crocker.
     13 August 1982. STD0011, RFC882.

   [PGPOld]

     PGP Message Exchange Formats. D. Atkins, W. Stallings & P.
     Zimmermann. August 1996. RFC1991.

   [OpenPGP]

     OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R.
     Thayer. November 1998. RFC2440.

   [X509]

     Internet X.509 Public Key Infrastructure Certificate and CRL
     Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999.
     RFC2459.

   [CMS]
   
     Cryptographic Message Syntax. R. Housley. June 1999. RFC2630.

   [MUSTSHOULD]
   
     Key words for use in RFCs to Indicate Requirement Levels. S.
     Bradner. March 1997. BCP0014, RFC2119.
     
   [ESS]

     Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June
     1999. RFC2634.

   [PKCS7]

     PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski.
     March 1998. RFC2315.

   

Author's Address

   Maxim Masiutin
   RITLABS S.R.L.
   180 Stefan cel Mare
   Chisinau MD2004
   Republic of Moldova
   [e-mail]
   fax: [phone]


Full Copyright Statement

Copyright (C) The Internet Society 2000.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   

-- 
Max Masyutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/




Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10641 for <[e-mail]>; Mon, 3 Apr 2000 03:03:59 -0700 (PDT)
Received: by relay1.trustworks.com (8.8.5/1.5) id OAA08282; Mon, 3 Apr 2000 14:06:56 +0400 (MSD)
Message-Id: <[e-mail]>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma008249; Mon, 3 Apr 00 14:06:23 +0400
From: "Valery Smyslov" <[e-mail]>
Organization: TWS
To: [e-mail]
Date: Mon, 3 Apr 2000 14:06:15 +0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Certificate path processing
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12b)

Hi,

I have a couple of questions regarding path processing. draft-ietf-
pkix-new-part1-01.txt states, that end entity may directly trust not 
only top CA in the hierarchy, but instead, some subordinate CA (for 
example, CA of end enity's own domain) and that it makes no 
difference to path validation algorithm. However, it seems to may 
make difference to path validation results. Consider the following 
example. Let's have CA hierarchy with top CA and two subordinate CA. 
Top CA imposes some constraints on first subordinate (for example, 
name constraint) while this subordinate imposes no constraints on its 
"son". In this situation, if end entity uses top CA or first 
subordinate as root CA, this constraints will be taken into 
consideration, while if it uses second subordinate CA as root CA - 
won't. Is it correct?
And another question: if end entity directly trusts some intermediate 
certificate in the path, does it means, that it may trust all 
certificates in the path, not only certificates below directly 
trusted, but also including certificates above it, up to the top? If 
the answer is "yes", it seems that the abovementioned possible 
difference in path validation results is incorrect. Am I wrong?

Thanks,
Valera.



Received: from center.kisa.or.kr (ns.kisa.or.kr [203.233.150.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11057 for <[e-mail]>; Sun, 2 Apr 2000 16:41:13 -0700 (PDT)
Received: from kisa.or.kr ([172.16.2.81]) by center.kisa.or.kr (8.9.3/8.9.3) with ESMTP id IAA15734 for <[e-mail]>; Mon, 3 Apr 2000 08:38:35 +0900 (KST)
Message-ID: <[e-mail]>
Date: Mon, 03 Apr 2000 08:47:50 +0900
From: JeeyeonKim <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from ix2.sinectis.com.ar (IDENT:[e-mail] [200.16.183.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21614 for <[e-mail]>; Sun, 2 Apr 2000 08:49:35 -0700 (PDT)
Received: from compaq (modem18-cisco12.capfed1.sinectis.com.ar [216.244.199.18]) by ix2.sinectis.com.ar (8.9.3/8.9.1) with SMTP id MAA24829; Sun, 2 Apr 2000 12:56:12 -0300
Message-ID: <002601bf9cb9$d6bda9a0$12c7f4d8@compaq>
From: "Nadir Asef" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: unsubscribe
Date: Sun, 2 Apr 2000 12:40:47 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01BF9CA0.AB69C7C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

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

unsubscribe

------=_NextPart_000_0023_01BF9CA0.AB69C7C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV>unsubscribe</DIV></DIV></BODY></HTML>

------=_NextPart_000_0023_01BF9CA0.AB69C7C0--



Received: from ix2.sinectis.com.ar (IDENT:[e-mail] [200.16.183.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21364 for <[e-mail]>; Sun, 2 Apr 2000 08:47:33 -0700 (PDT)
Received: from compaq (modem18-cisco12.capfed1.sinectis.com.ar [216.244.199.18]) by ix2.sinectis.com.ar (8.9.3/8.9.1) with SMTP id MAA24760; Sun, 2 Apr 2000 12:54:07 -0300
Message-ID: <001801bf9cb9$8d3e0cc0$12c7f4d8@compaq>
From: "Felix Nadir Asef" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: unsubscribe
Date: Sun, 2 Apr 2000 12:34:46 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BF9C9F.D49DAEA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

This is a multi-part message in MIME format.

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

unsubscribe

------=_NextPart_000_0015_01BF9C9F.D49DAEA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>unsubscribe</DIV></BODY></HTML>

------=_NextPart_000_0015_01BF9C9F.D49DAEA0--



Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23542 for <[e-mail]>; Sat, 1 Apr 2000 11:11:37 -0800 (PST)
Received: from small (d212-151-56-91.swipnet.se [212.151.56.91])  by mb04.swip.net (8.8.8/8.8.8) with SMTP  id VAA11333;  Sat, 1 Apr 2000 21:14:09 +0200 (MET DST)
Received: by localhost with Microsoft MAPI; Sat, 1 Apr 2000 21:13:17 +0200
Message-ID: <[e-mail]>
From: Erik Andersen <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'500 list'" <[e-mail]>
Cc: "'Blake Greenlee'" <[e-mail]>, "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: X.509 approved - see ITU-T press release
Date: Sat, 1 Apr 2000 21:12:02 +0200
Organization: Andersen's L-Service
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Sharon,

Congratulation. I just do not understand why your name was not mentioned in the press release.

Erik Andersen
CEN/ISSS/WS-DIR Chairman
Mobile: [phone]
E-mail;  [e-mail]
Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm


-----Original Message-----
From:	Sharon Boeyen [SMTP:[e-mail]]
Sent:	31. marts 2000 18:43
To:	'[e-mail]'; '[e-mail]'; '500 list'
Cc:	'Blake Greenlee'; 'Hoyt Kesterson'
Subject:	RE: X.509 approved - see ITU-T press release

FYI:

http://www.itu.int/ITU-T/itu-t_news/sg7_x509_press.htm



Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01007 for <[e-mail]>; Sat, 1 Apr 2000 00:11:04 -0800 (PST)
Received: from [38.29.123.214] (ip214.phoenix11.az.pub-ip.psi.net [38.29.123.214]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id AAA16569; Sat, 1 Apr 2000 00:12:57 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04310100b50b5b1f88c0@[38.29.123.180]>
Date: Sat, 1 Apr 2000 01:12:47 -0700
To: OSI Directory List <[e-mail]>, [e-mail], ABA Information Security Committee <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: no trees were hurt in the making of this revision
Content-Type: text/plain; charset="us-ascii"

In 1988 a magazine reported the publishing of the CCITT (now ITU) 1988 recommendations as "forests fall as CCITT moves to publish".

Only electrons will perish as a result of my telling you that since we found a few asn.1 errors, we decided to produce a corrected version of X.509/9594-8.

you can find the replacement text in word 8 and pdf formats at 

  ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV2.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV2.pdf


this text is unofficial until iso approves it. iso will begin a final amendment ballot soon. the ballot period lasts for two months.

note that when the text is approved and available for purchase, it will be removed from this server.

  hoyt