From keyprov-bounces@ietf.org Thu Nov 01 06:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXfq-0001UH-Up; Thu, 01 Nov 2007 06:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InXfp-0001PU-DL for keyprov@ietf.org; Thu, 01 Nov 2007 06:53:17 -0400 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InXfd-0003aQ-Lr for keyprov@ietf.org; Thu, 01 Nov 2007 06:53:12 -0400 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 49A2625ED54; Thu, 1 Nov 2007 11:52:48 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 33ML73D3; Thu, 1 Nov 2007 11:58:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [keyprov] PSKC phone conference meeting Minutes 28/10/07 Date: Thu, 1 Nov 2007 11:54:00 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA246B@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyprov] PSKC phone conference meeting Minutes 28/10/07 Thread-Index: AcgcdYJoObidqSrrQJyZceJaRw15sQ== From: "Philip Hoyer" To: , "Hallam-Baker, Phillip" , "Pei, Mingliang" , "CHANG Shuh" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1228016790==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1228016790== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81C75.98EC2EF4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81C75.98EC2EF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: Philip Hoyer, Ming Pei, Shuh Chang. Apologies: Phillip Hallam Baker =20 Discussed new version of the PSKC schema that Ming prepared for new version of DSKPP. =20 =20 1) Missing URIs, what do we do. Philip proposed adding the one we know. We need to agree at least on HOTP. Should we define URI in the PSKC document or somewhere else? Agree to define in PSKC. Ming to send email to Siddhart and David M'Raihi and Phillip Hallam Baker to ask if URI should be defined in PSKC or other specs. 2) Agreed via emails and reaffirmed that all attributes should be capital - Ming to do changes and distribute new schema to the list 3) Remove AlgorithmIdentifier (OATH legacy structure) not needed anymore with move to URIs 4) How do we distinguish between HOTP counter and HOTP time based? Is URI enough? Thinking is yes. ASlo mentioned that time based will have mandatory data elements such as 'TIME_INTERVAL' 5) What about usageType should they be in the data elements? Current thinking is to keep as explicit XML type. 6) Ming to do schema changes and reflect changes in the document. Including the examples. 7) Philip mentioned about concerns from RSA about using PKCS5 and xmlenc, Shuh, Ming to compose email with cons to spark discussion 8) What about using xmlenc encryptionmethod and xmlenc encrypted value? Agreed to take into consideration but defer to next revision. 9) Ming to think about PIN transfer proposal, Philip would like to add to this rev. 10) We use next call to decide when to release new rev. =20 Philip =20 =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C81C75.98EC2EF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees:

Philip Hoyer, Ming Pei, Shuh = Chang.

Apologies: Phillip Hallam = Baker

 

Discussed new version of the PSKC schema that = Ming prepared for new version of DSKPP.

 

 

1)       = Missing URIs, what do we do. Philip proposed adding the one we know. We need to = agree at least on HOTP. Should we define URI in the PSKC document or somewhere = else? Agree to define in PSKC. Ming to send email to Siddhart and David = M’Raihi and Phillip Hallam Baker to ask if URI should be defined in PSKC or = other specs.

2)       = Agreed via emails and reaffirmed that all attributes should be capital – = Ming to do changes and distribute new schema to the = list

3)       = Remove AlgorithmIdentifier (OATH legacy structure) not needed anymore with move = to URIs

4)       = How do we distinguish between HOTP counter and HOTP time based? Is URI = enough? Thinking is yes. ASlo mentioned that time based will have mandatory data elements such as = ‘TIME_INTERVAL’

5)       = What about usageType should they be in the data elements? Current thinking is = to keep as explicit XML type.

6)       = Ming to do schema changes and reflect changes in the document. Including the = examples.

7)       = Philip mentioned about concerns from RSA about using PKCS5 and xmlenc, Shuh, = Ming to compose email with cons to spark discussion

8)       = What about using xmlenc encryptionmethod and xmlenc encrypted value? Agreed = to take into consideration but defer to next = revision.

9)       = Ming to think about PIN transfer proposal, Philip would like to add to this = rev.

10)   = We use next call to decide when to release new = rev.

 

Philip

 

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C81C75.98EC2EF4-- --===============1228016790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1228016790==-- From keyprov-bounces@ietf.org Fri Nov 02 16:02:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2iY-0004SY-S5; Fri, 02 Nov 2007 16:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2iX-0004MC-LI for keyprov@ietf.org; Fri, 02 Nov 2007 16:02:09 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io2iG-0004gj-KA for keyprov@ietf.org; Fri, 02 Nov 2007 16:02:00 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lA2JvId8024780; Fri, 2 Nov 2007 12:57:18 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Nov 2007 20:00:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C81D8B.165103E3" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Nov 2007 13:00:59 -0700 Message-ID: <2788466ED3E31C418E9ACC5C31661557084F35@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Algorithm Identifiers Interim Drafts Thread-Index: AcgdiSmj1SywMiV6SKeP06GcO9kMJg== From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 02 Nov 2007 20:00:59.0676 (UTC) FILETIME=[1697B5C0:01C81D8B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 06f60f0744e48a3e4358b40a71e32d86 Cc: housley@vigilsec.com Subject: [KEYPROV] Algorithm Identifiers Interim Drafts X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C81D8B.165103E3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C81D8B.165103E3" ------_=_NextPart_002_01C81D8B.165103E3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Organizing these has taken more time than I expected. I have still not = got round to entering the identifiers Russ sent me for the ECC = algorithms into the database.=20 =20 I thought best to prove that I can extract data first. =20 So far I don't have references for the OTP algorithms. What I need for = each is: =20 1) Document where the algorithm is defined 2) Document(s) where identifiers are assigned (if different) 3) Identifiers assigned =20 =20 The source for the tool is an XML flat file and it spits out XMLRFC = format. =20 The formatting is pretty rough at the moment. =20 =20 To do list: =20 1) Modify the new tool to create references for all REF/ID pairs 2) Add sections listing algorithms by identifier type (e.g. all IPSEC, = all OID, all URI, ...) 3) Add means of tracking algorithm status, e.g. DEPRECATED 4) Add in Deprecated algorithms referenced in existing IETF/W3C specs =20 5) Add in the OASIS WS-* and SAML identifiers =20 ------_=_NextPart_002_01C81D8B.165103E3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Organizing these has = taken more time than I expected. I have still not got round to entering = the identifiers Russ sent me for the ECC algorithms into the database. =
=0A=
 
=0A=
I thought best to prove that I can = extract data first.
=0A=
 
=0A=
So far I don't have references for the = OTP algorithms. What I need for each is:
=0A=
 
=0A=
1) Document where the algorithm is = defined
=0A=
2) Document(s) where identifiers are = assigned (if different)
=0A=
3) Identifiers assigned
=0A=
 
=0A=
 
=0A=
The source for the tool is an XML = flat file and it spits out XMLRFC format.
=0A=
 
=0A=
The formatting is pretty rough at the = moment.
=0A=
 
=0A=
 
=0A=
To do list:
=0A=
 
=0A=
1) Modify the new tool to create = references for all REF/ID pairs
=0A=
2) Add sections listing algorithms by = identifier type (e.g. all IPSEC, all OID, all URI, ...)
=0A=
3) Add means of tracking algorithm = status, e.g. DEPRECATED
=0A=
4) Add in Deprecated algorithms = referenced in existing IETF/W3C specs
=0A=
 
=0A=
5) Add in the OASIS WS-* and = SAML identifiers
=0A=
 
------_=_NextPart_002_01C81D8B.165103E3-- ------_=_NextPart_001_01C81D8B.165103E3 Content-Type: text/html; name="draft-hallambaker-algorithm-identifiers.html" Content-Transfer-Encoding: base64 Content-Description: draft-hallambaker-algorithm-identifiers.html Content-Disposition: attachment; filename="draft-hallambaker-algorithm-identifiers.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+Q3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gSWRlbnRpZmllcnM8L3Rp dGxlPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJDcnlwdG9n cmFwaGljIEFsZ29yaXRobSBJZGVudGlmaWVycyI+CjxtZXRhIG5hbWU9ImtleXdvcmRzIiBjb250 ZW50PSJDcnlwdG9ncmFwaGljIEFsZ29yaXRobSwgRW5jcnlwdGlvbiwgRGlnaXRhbCBTaWduYXR1 cmUsIElkZW50aWZpZXIiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9InhtbDJyZmMg djEuMzIgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5bGUgdHlwZT0ndGV4dC9jc3Mn PjwhLS0KICAgICAgICBib2R5IHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiB2ZXJkYW5h LCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsKICAgICAgICAgICAgICAg IGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOwog ICAgICAgICAgICAgICAgbWFyZ2luOiAyZW07CiAgICAgICAgfQogICAgICAgIGgxLCBoMiwgaDMs IGg0LCBoNSwgaDYgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IGhlbHZldGljYSwgbW9u YWNvLCAiTVMgU2FucyBTZXJpZiIsIGFyaWFsLCBzYW5zLXNlcmlmOwogICAgICAgICAgICAgICAg Zm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsKICAgICAgICB9CiAgICAgICAg aDEgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IHRleHQtYWxp Z246IHJpZ2h0OyB9CiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsgYmFja2dyb3VuZC1jb2xvcjog dHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgdGQuUkZDYnVnIHsKICAgICAgICAgICAgICAgIGZvbnQt c2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwogICAgICAgICAgICAgICAgd2lk dGg6IDMwcHg7IGhlaWdodDogMzBweDsgcGFkZGluZy10b3A6IDJweDsKICAgICAgICAgICAgICAg IHRleHQtYWxpZ246IGp1c3RpZnk7IHZlcnRpY2FsLWFsaWduOiBtaWRkbGU7CiAgICAgICAgICAg ICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOwogICAgICAgIH0KICAgICAgICB0ZC5SRkNidWcg c3Bhbi5SRkMgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWws IGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7 CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgY29sb3I6ICM2NjY7CiAgICAgICAg fQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgewogICAgICAgICAgICAgICAgZm9udC1m YW1pbHk6IGNoYXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRp Y2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogbm9y bWFsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGNvbG9yOiAjRkZGOwogICAgICAgIH0KCiAgICAgICAg dGFibGUuVE9DYnVnIHsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVweDsgfQogICAgICAgIHRkLlRP Q2J1ZyB7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBjZW50ZXI7IHdpZHRoOiAzMHB4OyBo ZWlnaHQ6IDE1cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xv cjogIzkwMDsKICAgICAgICB9CiAgICAgICAgdGQuVE9DYnVnIGEgewogICAgICAgICAgICAgICAg Zm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsg Zm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7CiAgICAgICAgICAgICAg ICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7CiAgICAgICAgfQoK ICAgICAgICB0ZC5oZWFkZXIgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IGFyaWFsLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogeC1zbWFsbDsKICAgICAgICAgICAgICAg IHZlcnRpY2FsLWFsaWduOiB0b3A7IHdpZHRoOiAzMyU7CiAgICAgICAgICAgICAgICBjb2xvcjog I0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzY2NjsKICAgICAgICB9CiAgICAgICAgdGQuYXV0aG9y IHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFsbDsgbWFyZ2luLWxlZnQ6IDRl bTsgfQogICAgICAgIHRkLmF1dGhvci10ZXh0IHsgZm9udC1zaXplOiB4LXNtYWxsOyB9CgogICAg ICAgIC8qIGluZm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0dHA6Ly93d3cubWFkYWJvdXRz dHlsZS5jb20vdG9vbHRpcDIuaHRtbCAqLwogICAgICAgIGEuaW5mbyB7CiAgICAgICAgICAgICAg ICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICAgICAgICBwb3NpdGlvbjogcmVsYXRp dmU7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAgICAgICAgICAgIHRleHQtZGVj b3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgYS5pbmZvOmhvdmVyIHsKICAgICAgICAg ICAgICAgIHotaW5kZXg6IDI1OwogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91 bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIGEuaW5mbyBzcGFuIHsgZGlzcGxheTog bm9uZTsgfQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8gewogICAgICAgICAgICAgICAg LyogVGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qgb24gOmhvdmVyIHN0YXRlLiAqLwogICAgICAg ICAgICAgICAgZGlzcGxheTogYmxvY2s7CiAgICAgICAgICAgICAgICBwb3NpdGlvbjogYWJzb2x1 dGU7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsZXI7CiAgICAgICAgICAgICAgICB0 b3A6IDJlbTsgbGVmdDogLTVlbTsgd2lkdGg6IDE1ZW07CiAgICAgICAgICAgICAgICBwYWRkaW5n OiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7CiAgICAgICAgICAgICAgICBjb2xvcjogIzkw MDsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGxl ZnQ7CiAgICAgICAgfQoKICAgICAgICBhIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0KICAgICAgICBh OmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0K ICAgICAgICBhOnZpc2l0ZWQgeyBjb2xvcjogIzYzMzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7IH0KICAgICAgICBhOmFjdGl2ZSAgeyBjb2xvcjogIzYzMzsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgcCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1hcmdpbi1y aWdodDogMmVtOyB9CiAgICAgICAgcC5jb3B5cmlnaHQgeyBmb250LXNpemU6IHgtc21hbGw7IH0K ICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0OiBib2xkOyBtYXJn aW4tbGVmdDogM2VtOyB9CiAgICAgICAgdGFibGUudG9jIHsgbWFyZ2luOiAwIDAgMCAzZW07IHBh ZGRpbmc6IDA7IGJvcmRlcjogMDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9CiAgICAgICAg dGQudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6IGJvbGQ7IHZlcnRpY2FsLWFs aWduOiB0ZXh0LXRvcDsgfQoKICAgICAgICBvbC50ZXh0IHsgbWFyZ2luLWxlZnQ6IDJlbTsgbWFy Z2luLXJpZ2h0OiAyZW07IH0KICAgICAgICB1bC50ZXh0IHsgbWFyZ2luLWxlZnQ6IDJlbTsgbWFy Z2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBsaSAgICAgIHsgbWFyZ2luLWxlZnQ6IDNlbTsgfQoK ICAgICAgICAvKiBSRkMtMjYyOSA8c3Bhbng+cyBhbmQgPGFydHdvcms+cy4gKi8KICAgICAgICBl bSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7IH0KICAgICAgICBzdHJvbmcgeyBmb250LXdlaWdo dDogYm9sZDsgfQogICAgICAgIGRmbiAgICB7IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXN0eWxl OiBub3JtYWw7IH0KICAgICAgICBjaXRlICAgeyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXN0 eWxlOiBub3JtYWw7IH0KICAgICAgICB0dCAgICAgeyBjb2xvcjogIzAzNjsgfQogICAgICAgIHR0 LCBwcmUsIHByZSBkZm4sIHByZSBlbSwgcHJlIGNpdGUsIHByZSBzcGFuIHsKICAgICAgICAgICAg ICAgIGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciLCBDb3VyaWVyLCBtb25vc3BhY2U7IGZvbnQt c2l6ZTogc21hbGw7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAgICAgICAgICAgICAgICB0ZXh0 LWFsaWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogIzAwMDsg YmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9CiAgICAgICAgcHJlIGRmbiAgeyBjb2xv cjogIzkwMDsgfQogICAgICAgIHByZSBlbSAgIHsgY29sb3I6ICM2NkY7IGJhY2tncm91bmQtY29s b3I6ICNGRkM7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IH0KICAgICAgICBwcmUgLmtleSB7IGNvbG9y OiAjMzNDOyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIHByZSAuaWQgIHsgY29sb3I6ICM5 MDA7IH0KICAgICAgICBwcmUgLnN0ciB7IGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAj Q0ZGOyB9CiAgICAgICAgcHJlIC52YWwgeyBjb2xvcjogIzA2NjsgfQogICAgICAgIHByZSAucmVw IHsgY29sb3I6ICM5MDk7IH0KICAgICAgICBwcmUgLm90aCB7IGNvbG9yOiAjMDAwOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkNGOyB9CiAgICAgICAgcHJlIC5lcnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkNDOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDx0ZXh0dGFibGU+cy4gKi8KICAgICAgICB0YWJs ZS5hbGwsIHRhYmxlLmZ1bGwsIHRhYmxlLmhlYWRlcnMsIHRhYmxlLm5vbmUgewogICAgICAgICAg ICAgICAgZm9udC1zaXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2VudGVyOyBib3JkZXItd2lkdGg6 IDJweDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0b3A7IGJvcmRlci1jb2xsYXBz ZTogY29sbGFwc2U7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCB7IGJv cmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7IH0KICAgICAgICB0YWJsZS5o ZWFkZXJzLCB0YWJsZS5ub25lIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9CiAgICAgICAgdGggewog ICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRlci1jb2xvcjogYmxhY2s7CiAg ICAgICAgICAgICAgICBib3JkZXItd2lkdGg6IDJweCAycHggM3B4IDJweDsKICAgICAgICB9CiAg ICAgICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsg fQogICAgICAgIHRhYmxlLmhlYWRlcnMgdGggeyBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBzb2xp ZCBub25lOyB9CiAgICAgICAgdGFibGUubm9uZSB0aCB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQog ICAgICAgIHRhYmxlLmFsbCB0ZCB7CiAgICAgICAgICAgICAgICBib3JkZXItc3R5bGU6IHNvbGlk OyBib3JkZXItY29sb3I6ICMzMzM7CiAgICAgICAgICAgICAgICBib3JkZXItd2lkdGg6IDFweCAy cHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmZ1bGwgdGQsIHRhYmxlLmhlYWRlcnMgdGQsIHRh YmxlLm5vbmUgdGQgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KCiAgICAgICAgaHIgeyBoZWlnaHQ6 IDFweDsgfQogICAgICAgIGhyLmluc2VydCB7CiAgICAgICAgICAgICAgICB3aWR0aDogODAlOyBi b3JkZXItc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDogMDsKICAgICAgICAgICAgICAgIGNvbG9y OiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAgIH0KLS0+PC9zdHlsZT4KPC9o ZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iNjYlIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3 aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjEiPgo8 dHI+PHRkIGNsYXNzPSJoZWFkZXIiPkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2U8L3Rk Pjx0ZCBjbGFzcz0iaGVhZGVyIj5QLiBIYWxsYW0tQmFrZXI8L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImhlYWRlciI+SW50ZXJuZXQtRHJhZnQ8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5WZXJpU2ln biBJbmM8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+SW50ZW5kZWQgc3RhdHVzOiBJ bmZvcm1hdGlvbmFsPC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Tm92ZW1iZXIgMSwgMjAwNzwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5FeHBpcmVzOiBNYXkgNCwgMjAwODwvdGQ+PHRk IGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PC90cj4KPC90YWJsZT48L3RkPjwvdHI+PC90YWJs ZT4KPGgxPjxiciAvPkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIElkZW50aWZpZXJzPGJyIC8+ZHJh ZnQtaGFsbGFtYmFrZXItYWxnb3JpdGhtLWlkZW50aWZpZXJzLTAwPC9oMT4KCjxoMz5TdGF0dXMg b2YgdGhpcyBNZW1vPC9oMz4KPHA+CkJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwK ZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueSBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhl ciBJUFIgY2xhaW1zIG9mIHdoaWNoCmhlIG9yIHNoZSBpcyBhd2FyZSBoYXZlIGJlZW4gb3Igd2ls bCBiZSBkaXNjbG9zZWQsCmFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMgYXdhcmUg d2lsbCBiZSBkaXNjbG9zZWQsCmluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uJm5ic3A7NiBvZiBC Q1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwpUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLgpOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNv IGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMKSW50ZXJuZXQtRHJhZnRzLjwvcD4KPHA+ CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g b2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBv dGhlciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEgaHJl Zj0naHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Jz5odHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQ8L2E+LjwvcD4KPHA+ClRoZSBsaXN0IG9m IEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKPGEg aHJlZj0naHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCc+aHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbDwvYT4uPC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGly ZSBvbiBNYXkgNCwgMjAwOC48L3A+Cgo8aDM+Q29weXJpZ2h0IE5vdGljZTwvaDM+CjxwPgpDb3B5 cmlnaHQgJmNvcHk7IFRoZSBJRVRGIFRydXN0ICgyMDA3KS48L3A+Cgo8aDM+QWJzdHJhY3Q8L2gz PgoKPHA+CgkJUHJlZmVycmVkIGlkZW50aWZpZXJzIGZvciBjcnlwdG9ncmFwaGljIGFsZ29yaXRo bXMgY3VycmVudGx5IGluIHVzZSBpbiBJbnRlcm5ldCBzdGFuZGFyZHMuCiAgICAgIAo8L3A+PGEg bmFtZT0idG9jIj48L2E+PGJyIC8+PGhyIC8+CjxoMz5UYWJsZSBvZiBDb250ZW50czwvaDM+Cjxw IGNsYXNzPSJ0b2MiPgo8YSBocmVmPSIjYW5jaG9yMSI+MS48L2E+Jm5ic3A7CkludHJvZHVjdGlv bjxiciAvPgo8YSBocmVmPSIjYW5jaG9yMiI+Mi48L2E+Jm5ic3A7ClVua2V5ZWQgQWxnb3JpdGht czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMyI+Mi4xLjwv YT4mbmJzcDsKRGlnZXN0IEFsZ29yaXRobXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjIuMS4xLjwvYT4mbmJz cDsKU0hBMjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSIjYW5jaG9yNSI+Mi4xLjIuPC9hPiZuYnNwOwpSSVBFTUQtMTYwPGJyIC8+ CjxhIGhyZWY9IiNhbmNob3I2Ij4zLjwvYT4mbmJzcDsKU3ltbWV0cmljIEFsZ29yaXRobXM8YnIg Lz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjciPjMuMS48L2E+Jm5i c3A7CkVuY3J5cHRpb24gQWxnb3JpdGhtczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yOCI+My4xLjEuPC9hPiZuYnNw OwpCbG9jayBDaXBoZXJzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I5Ij4z LjEuMS4xLjwvYT4mbmJzcDsKVHJpcGxlIERhdGEgRW5jcnlwdGlvbiBBbGdvcml0aG08YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjEwIj4zLjEuMS4yLjwvYT4mbmJzcDsKQWR2 YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTEiPjMuMS4yLjwvYT4mbmJz cDsKIFN0cmVhbSBDaXBoZXJzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3Ix MiI+My4xLjIuMS48L2E+Jm5ic3A7ClJDNDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjYW5jaG9yMTMiPjMuMi48L2E+Jm5ic3A7Ck1lc3NhZ2UgQXV0aGVudGljYXRpb24g Q29kZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PGEgaHJlZj0iI2FuY2hvcjE0Ij4zLjIuMS48L2E+Jm5ic3A7CkhNQUM8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE1Ij4zLjMuPC9hPiZuYnNwOwpPbmUg VGltZSBQYXNzd29yZDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yMTYiPjMuNC48L2E+Jm5ic3A7CkNvbWJpbmF0aW9uIE1vZGVzPGJyIC8+CjxhIGhyZWY9IiNh bmNob3IxNyI+NC48L2E+Jm5ic3A7CkFzeW1tZXRyaWMgQWxnb3JpdGhtczxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTgiPjQuMS48L2E+Jm5ic3A7CktleSBB Z3JlZW1lbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE5Ij40LjEuMS48L2E+Jm5ic3A7CkRpZmZpZS1IZWxsbWFu PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3IyMCI+NC4xLjIuPC9hPiZuYnNwOwpSU0E8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjIxIj40LjIuPC9hPiZuYnNwOwpTaWduYXR1cmU8 YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjIyIj40LjIuMS48L2E+Jm5ic3A7ClJTQTxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjMiPjQuMy48L2E+Jm5ic3A7CkVuY3J5cHRpb248 YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjI0Ij40LjMuMS48L2E+Jm5ic3A7ClJTQTxiciAvPgo8YSBocmVmPSIjYW5j aG9yMjUiPjUuPC9hPiZuYnNwOwpYTUwgVHJhbmZvcm1hdGlvbjxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjYiPjUuMS48L2E+Jm5ic3A7CkNhbm9uaWNhbGl6 YXRpb248YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjI3Ij42LjwvYT4mbmJzcDsKRW5jb2Rpbmc8YnIg Lz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI4Ij42LjEuPC9hPiZu YnNwOwpCaW5hcnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI5Ij42LjEuMS48L2E+Jm5ic3A7CkJhc2UgNjQ8YnIg Lz4KPGEgaHJlZj0iI2FuY2hvcjMwIj43LjwvYT4mbmJzcDsKU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjMxIj44LjwvYT4mbmJzcDsKSUFOQSBDb25zaWRlcmF0 aW9uczxiciAvPgo8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj45LjwvYT4mbmJzcDsKTm9ybWF0 aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJlZj0iI3JmYy5hdXRob3JzIj4mIzE2Nzs8L2E+Jm5i c3A7CkF1dGhvcidzIEFkZHJlc3M8YnIgLz4KPGEgaHJlZj0iI3JmYy5jb3B5cmlnaHQiPiYjMTY3 OzwvYT4mbmJzcDsKSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50 czxiciAvPgo8L3A+CjxiciBjbGVhcj0iYWxsIiAvPgoKPGEgbmFtZT0iYW5jaG9yMSI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEiPjwvYT48aDM+MS4mbmJzcDsKSW50cm9kdWN0aW9uPC9o Mz4KCjxhIG5hbWU9ImFuY2hvcjIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yIj48L2E+ PGgzPjIuJm5ic3A7ClVua2V5ZWQgQWxnb3JpdGhtczwvaDM+Cgo8YSBuYW1lPSJhbmNob3IzIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMi4xIj48L2E+PGgzPjIuMS4mbmJzcDsKRGlnZXN0 IEFsZ29yaXRobXM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yNCI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjIuMS4xIj48L2E+PGgzPjIuMS4xLiZuYnNwOwpTSEEyPC9oMz4KCjxwPlN0YW5kYXJk cyBEb2N1bWVudDogRklQUz8/Pwo8L3A+CjxwPgpbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4bWxk c2lnLWNvcmU6IFhNTC1TaWduYXR1cmUgU3ludGF4IGFuZCBQcm9jZXNzaW5nXQoKPC9wPgo8cD4K SWRlbnRpZmllcjoKCiBbU0hBMjU2XQogW2xlbmd0aCA9MjU2XQogW3VyaSA9aHR0cDovL3d3dy53 My5vcmcvMjAwMS8wNC94bWxlbmMjc2hhMjU2XQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbU0hB NTEyXQogW2xlbmd0aCA9NTEyXQogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxl bmMjc2hhNTEyXQoKPC9wPgo8cD4KW0lkZW50aWZpZXJzIGRlZmluZWQgaW4gOiBdCgo8L3A+Cjxw PgpJZGVudGlmaWVyOgoKIFtETlNTRUMgQ29kZT0yXQogW2xlbmd0aCA9MjU2XQoKPC9wPgo8YSBu YW1lPSJhbmNob3I1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMi4xLjIiPjwvYT48aDM+ Mi4xLjIuJm5ic3A7ClJJUEVNRC0xNjA8L2gzPgoKPHA+CltJZGVudGlmaWVycyBkZWZpbmVkIGlu IHhtbGRzaWctY29yZTogWE1MLVNpZ25hdHVyZSBTeW50YXggYW5kIFByb2Nlc3NpbmddCgo8L3A+ CjxwPgpJZGVudGlmaWVyOgoKIFt1cmkgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5j I3JpcGVtZDE2MF0KCjwvcD4KPGEgbmFtZT0iYW5jaG9yNiI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjMiPjwvYT48aDM+My4mbmJzcDsKU3ltbWV0cmljIEFsZ29yaXRobXM8L2gzPgoKPGEg bmFtZT0iYW5jaG9yNyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMSI+PC9hPjxoMz4z LjEuJm5ic3A7CkVuY3J5cHRpb24gQWxnb3JpdGhtczwvaDM+Cgo8YSBuYW1lPSJhbmNob3I4Ij48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xLjEiPjwvYT48aDM+My4xLjEuJm5ic3A7CkJs b2NrIENpcGhlcnM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yOSI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjMuMS4xLjEiPjwvYT48aDM+My4xLjEuMS4mbmJzcDsKVHJpcGxlIERhdGEgRW5jcnlw dGlvbiBBbGdvcml0aG08L2gzPgoKPHA+QWxpYXM6IFRyaXBsZSBERVMKPC9wPgo8cD5TdGFuZGFy ZHMgRG9jdW1lbnQ6IDgwMC02Nwo8L3A+CjxwPlN0YW5kYXJkcyBEb2N1bWVudDogWDkuNTIKPC9w Pgo8cD4KW0lkZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZW5jLWNvcmU6IFhNTCBFbmNyeXB0aW9u IFN5bnRheCBhbmQgUHJvY2Vzc2luZ10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW01vZGUgPWNi Y10KIFt1cmkgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3RyaXBsZWRlcy1jYmNd Cgo8L3A+CjxwPgpJZGVudGlmaWVyOgoKIFtNb2RlID1rd10KIFt1cmkgPWh0dHA6Ly93d3cudzMu b3JnLzIwMDEvMDQveG1sZW5jI2t3LXRyaXBsZWRlc10KCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTAi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEuMS4yIj48L2E+PGgzPjMuMS4xLjIuJm5i c3A7CkFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQ8L2gzPgoKPHA+U3RhbmRhcmRzIERvY3Vt ZW50OiBGSVBTIDE5Nwo8L3A+CjxwPgpbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4bWxlbmMtY29y ZTogWE1MIEVuY3J5cHRpb24gU3ludGF4IGFuZCBQcm9jZXNzaW5nXQoKPC9wPgo8cD4KSWRlbnRp ZmllcjoKCiBbbGVuZ3RoID0xMjhdCiBbTW9kZSA9Y2JjXQogW3VyaSA9aHR0cDovL3d3dy53My5v cmcvMjAwMS8wNC94bWxlbmMjYWVzMTI4LWNiY10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW2xl bmd0aCA9MTkyXQogW01vZGUgPWNiY10KIFt1cmkgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQv eG1sZW5jI2FlczE5Mi1jYmNdCgo8L3A+CjxwPgpJZGVudGlmaWVyOgoKIFtsZW5ndGggPTI1Nl0K IFtNb2RlID1jYmNdCiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMy NTYtY2JjXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbbGVuZ3RoID0xMjhdCiBbTW9kZSA9a3dd CiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy1hZXMxMjhdCgo8L3A+ CjxwPgpJZGVudGlmaWVyOgoKIFtsZW5ndGggPTE5Ml0KIFtNb2RlID1rd10KIFt1cmkgPWh0dHA6 Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczE5Ml0KCjwvcD4KPHA+CklkZW50aWZp ZXI6CgogW2xlbmd0aCA9MjU2XQogW01vZGUgPWt3XQogW3VyaSA9aHR0cDovL3d3dy53My5vcmcv MjAwMS8wNC94bWxlbmMja3ctYWVzMjU2XQoKPC9wPgo8YSBuYW1lPSJhbmNob3IxMSI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMS4yIj48L2E+PGgzPjMuMS4yLiZuYnNwOwogU3RyZWFt IENpcGhlcnM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yMTIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi4zLjEuMi4xIj48L2E+PGgzPjMuMS4yLjEuJm5ic3A7ClJDNDwvaDM+Cgo8YSBuYW1lPSJh bmNob3IxMyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMiI+PC9hPjxoMz4zLjIuJm5i c3A7Ck1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yMTQi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjIuMSI+PC9hPjxoMz4zLjIuMS4mbmJzcDsK SE1BQzwvaDM+Cgo8cD5TdGFuZGFyZHMgRG9jdW1lbnQ6IFJGQzIxMDQKPC9wPgo8cD4KW0lkZW50 aWZpZXJzIGRlZmluZWQgaW4geG1sZHNpZy1jb3JlOiBYTUwtU2lnbmF0dXJlIFN5bnRheCBhbmQg UHJvY2Vzc2luZ10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW01vZGUgPVNIQTFdCiBbdXJpID1o dHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjaG1hYy1zaGExXQoKPC9wPgo8YSBuYW1l PSJhbmNob3IxNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMyI+PC9hPjxoMz4zLjMu Jm5ic3A7Ck9uZSBUaW1lIFBhc3N3b3JkPC9oMz4KCjxwPk5vIGFsZ29yaXRobXMgcmVnaXN0ZXJl ZCB5ZXQuCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi4zLjQiPjwvYT48aDM+My40LiZuYnNwOwpDb21iaW5hdGlvbiBNb2RlczwvaDM+Cgo8cD5ObyBh bGdvcml0aG1zIHJlZ2lzdGVyZWQgeWV0Lgo8L3A+CjxhIG5hbWU9ImFuY2hvcjE3Ij48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uNCI+PC9hPjxoMz40LiZuYnNwOwpBc3ltbWV0cmljIEFsZ29y aXRobXM8L2gzPgoKPGEgbmFtZT0iYW5jaG9yMTgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi40LjEiPjwvYT48aDM+NC4xLiZuYnNwOwpLZXkgQWdyZWVtZW50PC9oMz4KCjxhIG5hbWU9ImFu Y2hvcjE5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4xLjEiPjwvYT48aDM+NC4xLjEu Jm5ic3A7CkRpZmZpZS1IZWxsbWFuPC9oMz4KCjxwPlN0YW5kYXJkcyBEb2N1bWVudDogUkZDMjYz MQo8L3A+CjxwPlN0YW5kYXJkcyBEb2N1bWVudDogWDkuNDIKPC9wPgo8cD4KW0lkZW50aWZpZXJz IGRlZmluZWQgaW4geG1sZW5jLWNvcmU6IFhNTCBFbmNyeXB0aW9uIFN5bnRheCBhbmQgUHJvY2Vz c2luZ10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAw MS8wNC94bWxlbmMjZGhdCgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIwIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNC4xLjIiPjwvYT48aDM+NC4xLjIuJm5ic3A7ClJTQTwvaDM+Cgo8cD5TdGFu ZGFyZHMgRG9jdW1lbnQ6IFJGQzI0MzcKPC9wPgo8cD4KW0lkZW50aWZpZXJzIGRlZmluZWQgaW4g eG1sZHNpZy1jb3JlOiBYTUwtU2lnbmF0dXJlIFN5bnRheCBhbmQgUHJvY2Vzc2luZ10KCjwvcD4K PHA+CklkZW50aWZpZXI6CgogW01vZGUgPVNIQTFdCiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8y MDAwLzA5L3htbGRzaWcjcnNhLXNoYTFdCgo8L3A+CjxwPgpbSWRlbnRpZmllcnMgZGVmaW5lZCBp biB4bWxlbmMtY29yZTogWE1MIEVuY3J5cHRpb24gU3ludGF4IGFuZCBQcm9jZXNzaW5nXQoKPC9w Pgo8cD4KSWRlbnRpZmllcjoKCiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu YyNyc2EtMV81XQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbdXJpID1odHRwOi8vd3d3LnczLm9y Zy8yMDAxLzA0L3htbGVuYyNyc2Etb2FlcC1tZ2YxcF0KCjwvcD4KPHA+CltJZGVudGlmaWVycyBk ZWZpbmVkIGluIDogXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbRE5TU0VDIENvZGU9NV0KIFtN b2RlID1zaGExXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbRE5TU0VDIENvZGU9MV0KIFtNb2Rl ID1tZDVdCgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNC4yIj48L2E+PGgzPjQuMi4mbmJzcDsKU2lnbmF0dXJlPC9oMz4KCjxhIG5hbWU9ImFuY2hv cjIyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4yLjEiPjwvYT48aDM+NC4yLjEuJm5i c3A7ClJTQTwvaDM+Cgo8cD5TdGFuZGFyZHMgRG9jdW1lbnQ6IFJGQzI0MzcKPC9wPgo8cD4KW0lk ZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZHNpZy1jb3JlOiBYTUwtU2lnbmF0dXJlIFN5bnRheCBh bmQgUHJvY2Vzc2luZ10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW01vZGUgPVNIQTFdCiBbdXJp ID1odHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTFdCgo8L3A+CjxwPgpb SWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4bWxlbmMtY29yZTogWE1MIEVuY3J5cHRpb24gU3ludGF4 IGFuZCBQcm9jZXNzaW5nXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBbdXJpID1odHRwOi8vd3d3 LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyc2EtMV81XQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBb dXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyc2Etb2FlcC1tZ2YxcF0KCjwv cD4KPHA+CltJZGVudGlmaWVycyBkZWZpbmVkIGluIDogXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoK CiBbRE5TU0VDIENvZGU9NV0KIFtNb2RlID1zaGExXQoKPC9wPgo8cD4KSWRlbnRpZmllcjoKCiBb RE5TU0VDIENvZGU9MV0KIFtNb2RlID1tZDVdCgo8L3A+CjxhIG5hbWU9ImFuY2hvcjIzIj48L2E+ PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4zIj48L2E+PGgzPjQuMy4mbmJzcDsKRW5jcnlwdGlv bjwvaDM+Cgo8YSBuYW1lPSJhbmNob3IyNCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQu My4xIj48L2E+PGgzPjQuMy4xLiZuYnNwOwpSU0E8L2gzPgoKPHA+U3RhbmRhcmRzIERvY3VtZW50 OiBSRkMyNDM3CjwvcD4KPHA+CltJZGVudGlmaWVycyBkZWZpbmVkIGluIHhtbGRzaWctY29yZTog WE1MLVNpZ25hdHVyZSBTeW50YXggYW5kIFByb2Nlc3NpbmddCgo8L3A+CjxwPgpJZGVudGlmaWVy OgoKIFtNb2RlID1TSEExXQogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2ln I3JzYS1zaGExXQoKPC9wPgo8cD4KW0lkZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZW5jLWNvcmU6 IFhNTCBFbmNyeXB0aW9uIFN5bnRheCBhbmQgUHJvY2Vzc2luZ10KCjwvcD4KPHA+CklkZW50aWZp ZXI6CgogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjcnNhLTFfNV0KCjwv cD4KPHA+CklkZW50aWZpZXI6CgogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxl bmMjcnNhLW9hZXAtbWdmMXBdCgo8L3A+CjxwPgpbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiA6IF0K CjwvcD4KPHA+CklkZW50aWZpZXI6CgogW0ROU1NFQyBDb2RlPTVdCiBbTW9kZSA9c2hhMV0KCjwv cD4KPHA+CklkZW50aWZpZXI6CgogW0ROU1NFQyBDb2RlPTFdCiBbTW9kZSA9bWQ1XQoKPC9wPgo8 YSBuYW1lPSJhbmNob3IyNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUiPjwvYT48aDM+ NS4mbmJzcDsKWE1MIFRyYW5mb3JtYXRpb248L2gzPgoKPGEgbmFtZT0iYW5jaG9yMjYiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi41LjEiPjwvYT48aDM+NS4xLiZuYnNwOwpDYW5vbmljYWxp emF0aW9uPC9oMz4KCjxwPk5vIGFsZ29yaXRobXMgcmVnaXN0ZXJlZCB5ZXQuCjwvcD4KPGEgbmFt ZT0iYW5jaG9yMjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42Ij48L2E+PGgzPjYuJm5i c3A7CkVuY29kaW5nPC9oMz4KCjxhIG5hbWU9ImFuY2hvcjI4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNi4xIj48L2E+PGgzPjYuMS4mbmJzcDsKQmluYXJ5PC9oMz4KCjxhIG5hbWU9ImFu Y2hvcjI5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNi4xLjEiPjwvYT48aDM+Ni4xLjEu Jm5ic3A7CkJhc2UgNjQ8L2gzPgoKPHA+U3RhbmRhcmRzIERvY3VtZW50OiBCYXNlNjQKPC9wPgo8 cD4KW0lkZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZHNpZy1jb3JlOiBYTUwtU2lnbmF0dXJlIFN5 bnRheCBhbmQgUHJvY2Vzc2luZ10KCjwvcD4KPHA+CklkZW50aWZpZXI6CgogW3VyaSA9aHR0cDov L3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2Jhc2U2NF0KCjwvcD4KPGEgbmFtZT0iYW5jaG9y MzAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43Ij48L2E+PGgzPjcuJm5ic3A7ClNlY3Vy aXR5IENvbnNpZGVyYXRpb25zPC9oMz4KCjxwPgoJCVRCUwoJICAKPC9wPgo8YSBuYW1lPSJhbmNo b3IzMSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjgiPjwvYT48aDM+OC4mbmJzcDsKSUFO QSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD4KCSAgICBUQlMKICAgICAgCjwvcD4KPGEgbmFtZT0i cmZjLnJlZmVyZW5jZXMxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjkuJm5ic3A7Tm9ybWF0aXZlIFJlZmVyZW5jZXM8 L2gzPgo8dGFibGUgd2lkdGg9Ijk5JSIgYm9yZGVyPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSI4MDAtNjciPls4MDAtNjddPC9hPjwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZsZHF1bztSZWNvbW1lbmRhdGlvbiBmb3IgdGhlIFRyaXBs ZSBEYXRhIEVuY3J5cHRpb24gQWxnb3JpdGhtIChUREVBKSBCbG9jayBDaXBoZXIsJnJkcXVvOyBN YXkmbmJzcDsyMDA0LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGln bj0idG9wIj48YSBuYW1lPSJDU09SIj5bQ1NPUl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+JmxkcXVvO0NyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIE9iamVjdCBSZWdpc3RyYXRpb24u JnJkcXVvOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w Ij48YSBuYW1lPSJGSVBTIDE5NyI+W0ZJUFMgMTk3XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij4mbGRxdW87QWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCAoQUVTKSwmcmRxdW87 IE5vdmVtYmVyJm5ic3A7MjAwMS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjEwNCI+W1JGQzIxMDRdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPiZsZHF1bztITUFDOiBLZXllZC1IYXNoaW5nIGZvciBNZXNzYWdl IEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgRmVicnVhcnkmbmJzcDsxOTk3LjwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkMyMTE5Ij5b UkZDMjExOV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+PGEgaHJlZj0ibWFpbHRv OnNvYkBoYXJ2YXJkLmVkdSI+QnJhZG5lciwgUy48L2E+LCAmbGRxdW87PGEgaHJlZj0iZnRwOi8v ZnRwLmlzaS5lZHUvaW4tbm90ZXMvcmZjMjExOS50eHQiPktleSB3b3JkcyBmb3IgdXNlIGluIFJG Q3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzPC9hPiwmcmRxdW87IEJDUCZuYnNwOzE0 LCBSRkMmbmJzcDsyMTE5LCBNYXJjaCZuYnNwOzE5OTcgKDxhIGhyZWY9ImZ0cDovL2Z0cC5pc2ku ZWR1L2luLW5vdGVzL3JmYzIxMTkudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJl c291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjExOS5odG1sIj5IVE1MPC9hPiwgPGEgaHJl Zj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjExOS54bWwiPlhN TDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w Ij48YSBuYW1lPSJSRkMyNDM3Ij5bUkZDMjQzN108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+JmxkcXVvO1BLQ1MgIzE6IFJTQSBDcnlwdG9ncmFwaHkgU3BlY2lmaWNhdGlvbnMgVmVy c2lvbiAyLjAsJnJkcXVvOyBPY3RvYmVyJm5ic3A7MTk5OC48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjU2MCI+W1JGQzI1NjBd PC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzptbXllcnNA dmVyaXNpZ24uY29tIj5NeWVycywgTS48L2E+LCA8YSBocmVmPSJtYWlsdG86cmFua25leUBlcm9s cy5jb20iPkFua25leSwgUi48L2E+LCA8YSBocmVmPSJtYWlsdG86YW1iYXJpc2hAdmFsaWNlcnQu Y29tIj5NYWxwYW5pLCBBLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpnYWxwZXJpbkBteWNmby5jb20i PkdhbHBlcmluLCBTLjwvYT4sIGFuZCA8YSBocmVmPSJtYWlsdG86Y2FkYW1zQGVudHJ1c3QuY29t Ij5DLiBBZGFtczwvYT4sICZsZHF1bzs8YSBocmVmPSJmdHA6Ly9mdHAuaXNpLmVkdS9pbi1ub3Rl cy9yZmMyNTYwLnR4dCI+WC41MDkgSW50ZXJuZXQgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSBP bmxpbmUgQ2VydGlmaWNhdGUgU3RhdHVzIFByb3RvY29sIC0gT0NTUDwvYT4sJnJkcXVvOyBSRkMm bmJzcDsyNTYwLCBKdW5lJm5ic3A7MTk5OS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhv ci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjYzMSI+W1JGQzI2MzFdPC9hPjwvdGQ+ Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZsZHF1bztEaWZmaWUtSGVsbG1hbiBLZXkgQWdyZWVt ZW50IE1ldGhvZCwmcmRxdW87IEp1bmUmbmJzcDsxOTk5LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0MDM0Ij5bUkZDNDAzNF08 L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+JmxkcXVvOy4mcmRxdW87PC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzQ1 MDkiPltSRkM0NTA5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbGRxdW87LiZy ZHF1bzs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+ PGEgbmFtZT0iUkZDNDg2OCI+W1JGQzQ4NjhdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZsZHF1bztVc2luZyBITUFDLVNIQS0yNTYsIEhNQUMtU0hBLTM4NCwgYW5kIEhNQUMtU0hB LTUxMiB3aXRoIElQc2VjLiZyZHF1bzs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10 ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iWDkuNDIiPltYOS40Ml08L2E+PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+JmxkcXVvO0FncmVlbWVudCBvZiBTeW1tZXRyaWMgS2V5cyBVc2lu ZyBEaXNjcmV0ZSBMb2dhcml0aG0gQ3J5cHRvZ3JhcGh5LiZyZHF1bzs8L3RkPjwvdHI+Cjx0cj48 dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iWDkuNTIiPltYOS41 Ml08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+JmxkcXVvO1RyaXBsZSBEYXRhIEVu Y3J5cHRpb24gQWxnb3JpdGhtIE1vZGVzIG9mIE9wZXJhdGlvbiwmcmRxdW87IDE5OTguPC90ZD48 L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlhN TC1DMTQiPltYTUwtQzE0XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbGRxdW87 WE1MIENhbm9uaWNhbGl6YXRpb24uJnJkcXVvOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJYTUwtWEMxNCI+W1hNTC1YQzE0XTwvYT48 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbGRxdW87RXhjbHVzaXZlIFhNTCBDYW5vbmlj YWxpemF0aW9uLiZyZHF1bzs8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0ieG1sZHNpZy1jb3JlIj5beG1sZHNpZy1jb3JlXTwvYT48L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbGRxdW87WE1MLVNpZ25hdHVyZSBTeW50YXggYW5k IFByb2Nlc3NpbmcsJnJkcXVvOyBGZWJydWFyeSZuYnNwOzIwMDIuPC90ZD48L3RyPgo8dHI+PHRk IGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9InhtbGVuYy1jb3JlIj5b eG1sZW5jLWNvcmVdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZsZHF1bztYTUwg RW5jcnlwdGlvbiBTeW50YXggYW5kIFByb2Nlc3NpbmcuJnJkcXVvOzwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJ4cGF0aCI+W3hwYXRo XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbGRxdW87WE1MIFBhdGggTGFuZ3Vh Z2UgKFhQYXRoKSBWZXJzaW9uIDEuMCwmcmRxdW87IE5vdmVtYmVyJm5ic3A7MTk5OS48L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0ieHNs dCI+W3hzbHRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZsZHF1bztYU0wgVHJh bnNmb3JtYXRpb25zIChYU0xUKSBWZXJzaW9uIDEuMCwmcmRxdW87IE5vdmVtYmVyJm5ic3A7MTYu PC90ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFtZT0icmZjLmF1dGhvcnMiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+QXV0 aG9yJ3MgQWRkcmVzczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJz cDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5QaGlsbGlwIEhhbGxhbS1CYWtlcjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPlZlcmlTaWduIEluYzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y IiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PjxhIGhyZWY9Im1haWx0bzpwYmFrZXJAdmVyaXNpZ24uY29tIj5wYmFrZXJAdmVyaXNpZ24uY29t PC9hPjwvdGQ+PC90cj4KPC90YWJsZT4KPGEgbmFtZT0icmZjLmNvcHlyaWdodCI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxo Mz5GdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQ8L2gzPgo8cCBjbGFzcz0nY29weXJpZ2h0Jz4KQ29w eXJpZ2h0ICZjb3B5OyBUaGUgSUVURiBUcnVzdCAoMjAwNykuPC9wPgo8cCBjbGFzcz0nY29weXJp Z2h0Jz4KVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsCmxpY2Vuc2VzIGFu ZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCZuYnNwOzc4LAphbmQgZXhjZXB0IGFzIHNl dCBmb3J0aCB0aGVyZWluLAp0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy48L3A+ CjxwIGNsYXNzPSdjb3B5cmlnaHQnPgpUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQKb24gYW4gJmxkcXVvO0FTIElTJnJkcXVvOyBi YXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLApUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNF TlRTCk9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRI RSBJRVRGIFRSVVNUCkFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVND TEFJTSBBTEwgV0FSUkFOVElFUywKRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5P VCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUClRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9O IEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWQpJTVBMSUVEIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUgpQVVJQ T1NFLjwvcD4KPGgzPkludGVsbGVjdHVhbCBQcm9wZXJ0eTwvaDM+CjxwIGNsYXNzPSdjb3B5cmln aHQnPgpUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y IHNjb3BlIG9mIGFueQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0 cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQKdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5CmRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9yIHRo ZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UKdW5kZXIgc3VjaCByaWdodHMgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQKcmVwcmVzZW50IHRoYXQgaXQgaGFz IG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkKc3VjaCByaWdodHMu CkluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0bwpyaWdodHMgaW4g UkZDIGRvY3VtZW50cyBjYW4gYmUgZm91bmQgaW4gQkNQJm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5 LjwvcD4KPHAgY2xhc3M9J2NvcHlyaWdodCc+CkNvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFk ZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CmFzc3VyYW5jZXMgb2YgbGljZW5zZXMg dG8gYmUgbWFkZSBhdmFpbGFibGUsCm9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRv IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvcgpwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvcgp1c2VycyBvZiB0aGlzIHNw ZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIKcmVw b3NpdG9yeSBhdCA8YSBocmVmPSdodHRwOi8vd3d3LmlldGYub3JnL2lwcic+aHR0cDovL3d3dy5p ZXRmLm9yZy9pcHI8L2E+LjwvcD4KPHAgY2xhc3M9J2NvcHlyaWdodCc+ClRoZSBJRVRGIGludml0 ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbgphbnkgY29w eXJpZ2h0cywKcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLApvciBvdGhlcgpwcm9wcmll dGFyeSByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJl ZAp0byBpbXBsZW1lbnQgdGhpcyBzdGFuZGFyZC4KUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0 aW9uIHRvIHRoZSBJRVRGIGF0IDxhIGhyZWY9J21haWx0bzppZXRmLWlwckBpZXRmLm9yZyc+aWV0 Zi1pcHJAaWV0Zi5vcmc8L2E+LjwvcD4KPGgzPkFja25vd2xlZGdtZW50PC9oMz4KPHAgY2xhc3M9 J2NvcHlyaWdodCc+CkZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3Zp ZGVkIGJ5CnRoZSBJRVRGIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkgKElBU0EpLjwv cD4KPC9ib2R5PjwvaHRtbD4KCg== ------_=_NextPart_001_01C81D8B.165103E3 Content-Type: text/plain; name="draft-hallambaker-algorithm-identifiers.txt" Content-Transfer-Encoding: base64 Content-Description: draft-hallambaker-algorithm-identifiers.txt Content-Disposition: attachment; filename="draft-hallambaker-algorithm-identifiers.txt" CgoKSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgICAgICAgICAg ICAgUC4gSGFsbGFtLUJha2VyCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFZlcmlTaWduIEluYwpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDEsIDIwMDcKRXhwaXJl czogTWF5IDQsIDIwMDgKCgogICAgICAgICAgICAgICAgICBDcnlwdG9ncmFwaGljIEFsZ29yaXRo bSBJZGVudGlmaWVycwogICAgICAgICAgICAgICBkcmFmdC1oYWxsYW1iYWtlci1hbGdvcml0aG0t aWRlbnRpZmllcnMtMDAKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhp cyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQogICBhcHBs aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBh d2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2gg aGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFu Y2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAo SUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdAogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nl c3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgog ICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFj Y2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA0LCAyMDA4LgoKQ29weXJpZ2h0IE5vdGlj ZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuCgpBYnN0cmFjdAoKICAg UHJlZmVycmVkIGlkZW50aWZpZXJzIGZvciBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgY3VycmVu dGx5IGluIHVzZQogICBpbiBJbnRlcm5ldCBzdGFuZGFyZHMuCgoKCgoKCgoKCkhhbGxhbS1CYWtl ciAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDQsIDIwMDggICAgICAgICAgICAgICAgICBbUGFn ZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICBDcnlwdG9ncmFwaGljIEFsZ29yaXRobSBJZGVudGlm aWVycyAgICAgTm92ZW1iZXIgMjAwNwoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9k dWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDMKICAgMi4gIFVua2V5ZWQgQWxnb3JpdGhtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzCiAgICAgMi4xLiAgRGlnZXN0IEFsZ29yaXRobXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAgICAgMi4xLjEuICBTSEEyICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgICAg IDIuMS4yLiAgUklQRU1ELTE2MCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzCiAgIDMuICBTeW1tZXRyaWMgQWxnb3JpdGhtcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAgIDMuMS4gIEVuY3J5cHRpb24gQWxnb3JpdGht cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgICAgIDMuMS4xLiAg QmxvY2sgQ2lwaGVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAz CiAgICAgICAgIDMuMS4xLjEuICBUcmlwbGUgRGF0YSBFbmNyeXB0aW9uIEFsZ29yaXRobSAgLiAu IC4gLiAuIC4gLiAuIC4gMwogICAgICAgICAzLjEuMS4yLiAgQWR2YW5jZWQgRW5jcnlwdGlvbiBT dGFuZGFyZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgICAgIDMuMS4yLiAgU3RyZWFtIENp cGhlcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgICAgICAg IDMuMS4yLjEuICBSQzQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNAogICAgIDMuMi4gIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgICAgIDMuMi4xLiAgSE1BQyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgICAgMy4zLiAgT25lIFRp bWUgUGFzc3dvcmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQog ICAgIDMuNC4gIENvbWJpbmF0aW9uIE1vZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDUKICAgNC4gIEFzeW1tZXRyaWMgQWxnb3JpdGhtcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgICAgNC4xLiAgS2V5IEFncmVlbWVudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICAgICAgNC4x LjEuICBEaWZmaWUtSGVsbG1hbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDUKICAgICAgIDQuMS4yLiAgUlNBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1CiAgICAgNC4yLiAgU2lnbmF0dXJlIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgogICAgICAgNC4yLjEuICBSU0Eg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYKICAg ICA0LjMuICBFbmNyeXB0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA2CiAgICAgICA0LjMuMS4gIFJTQSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgogICA1LiAgWE1MIFRyYW5mb3JtYXRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcKICAgICA1LjEuICBD YW5vbmljYWxpemF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA3CiAgIDYuICBFbmNvZGluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNwogICAgIDYuMS4gIEJpbmFyeSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcKICAgICAgIDYuMS4xLiAgQmFzZSA2 NCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIDcu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNwogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcKICAgOS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIEF1dGhvcidzIEFk ZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g OAogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4g LiAuIC4gLiAuIC4gLiAuIDkKCgoKCgoKCgoKCgoKCgoKSGFsbGFtLUJha2VyICAgICAgICAgICAg ICAgRXhwaXJlcyBNYXkgNCwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJu ZXQtRHJhZnQgICAgIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIElkZW50aWZpZXJzICAgICBOb3Zl bWJlciAyMDA3CgoKMS4gIEludHJvZHVjdGlvbgoKCjIuICBVbmtleWVkIEFsZ29yaXRobXMKCjIu MS4gIERpZ2VzdCBBbGdvcml0aG1zCgoyLjEuMS4gIFNIQTIKCiAgIFN0YW5kYXJkcyBEb2N1bWVu dDogRklQUz8/PwoKICAgW0lkZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZHNpZy1jb3JlOiBYTUwt U2lnbmF0dXJlIFN5bnRheCBhbmQKICAgUHJvY2Vzc2luZ10KCiAgIElkZW50aWZpZXI6IFtTSEEy NTZdIFtsZW5ndGggPTI1Nl0gW3VyaQogICA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxl bmMjc2hhMjU2XQoKICAgSWRlbnRpZmllcjogW1NIQTUxMl0gW2xlbmd0aCA9NTEyXSBbdXJpCiAg ID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNzaGE1MTJdCgogICBbSWRlbnRpZmll cnMgZGVmaW5lZCBpbiA6IF0KCiAgIElkZW50aWZpZXI6IFtETlNTRUMgQ29kZT0yXSBbbGVuZ3Ro ID0yNTZdCgoyLjEuMi4gIFJJUEVNRC0xNjAKCiAgIFtJZGVudGlmaWVycyBkZWZpbmVkIGluIHht bGRzaWctY29yZTogWE1MLVNpZ25hdHVyZSBTeW50YXggYW5kCiAgIFByb2Nlc3NpbmddCgogICBJ ZGVudGlmaWVyOiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyaXBlbWQx NjBdCgoKMy4gIFN5bW1ldHJpYyBBbGdvcml0aG1zCgozLjEuICBFbmNyeXB0aW9uIEFsZ29yaXRo bXMKCjMuMS4xLiAgQmxvY2sgQ2lwaGVycwoKMy4xLjEuMS4gIFRyaXBsZSBEYXRhIEVuY3J5cHRp b24gQWxnb3JpdGhtCgogICBBbGlhczogVHJpcGxlIERFUwoKICAgU3RhbmRhcmRzIERvY3VtZW50 OiA4MDAtNjcKCiAgIFN0YW5kYXJkcyBEb2N1bWVudDogWDkuNTIKCiAgIFtJZGVudGlmaWVycyBk ZWZpbmVkIGluIHhtbGVuYy1jb3JlOiBYTUwgRW5jcnlwdGlvbiBTeW50YXggYW5kCiAgIFByb2Nl c3NpbmddCgoKCkhhbGxhbS1CYWtlciAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDQsIDIwMDgg ICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICBDcnlwdG9ncmFw aGljIEFsZ29yaXRobSBJZGVudGlmaWVycyAgICAgTm92ZW1iZXIgMjAwNwoKCiAgIElkZW50aWZp ZXI6IFtNb2RlID1jYmNdIFt1cmkKICAgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5j I3RyaXBsZWRlcy1jYmNdCgogICBJZGVudGlmaWVyOiBbTW9kZSA9a3ddIFt1cmkKICAgPWh0dHA6 Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LXRyaXBsZWRlc10KCjMuMS4xLjIuICBBZHZh bmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJkCgogICBTdGFuZGFyZHMgRG9jdW1lbnQ6IEZJUFMgMTk3 CgogICBbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4bWxlbmMtY29yZTogWE1MIEVuY3J5cHRpb24g U3ludGF4IGFuZAogICBQcm9jZXNzaW5nXQoKICAgSWRlbnRpZmllcjogW2xlbmd0aCA9MTI4XSBb TW9kZSA9Y2JjXSBbdXJpCiAgID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMx MjgtY2JjXQoKICAgSWRlbnRpZmllcjogW2xlbmd0aCA9MTkyXSBbTW9kZSA9Y2JjXSBbdXJpCiAg ID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMxOTItY2JjXQoKICAgSWRlbnRp ZmllcjogW2xlbmd0aCA9MjU2XSBbTW9kZSA9Y2JjXSBbdXJpCiAgID1odHRwOi8vd3d3LnczLm9y Zy8yMDAxLzA0L3htbGVuYyNhZXMyNTYtY2JjXQoKICAgSWRlbnRpZmllcjogW2xlbmd0aCA9MTI4 XSBbTW9kZSA9a3ddIFt1cmkKICAgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3 LWFlczEyOF0KCiAgIElkZW50aWZpZXI6IFtsZW5ndGggPTE5Ml0gW01vZGUgPWt3XSBbdXJpCiAg ID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy1hZXMxOTJdCgogICBJZGVudGlm aWVyOiBbbGVuZ3RoID0yNTZdIFtNb2RlID1rd10gW3VyaQogICA9aHR0cDovL3d3dy53My5vcmcv MjAwMS8wNC94bWxlbmMja3ctYWVzMjU2XQoKMy4xLjIuICAgU3RyZWFtIENpcGhlcnMKCjMuMS4y LjEuICBSQzQKCjMuMi4gIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMKCjMuMi4xLiAgSE1B QwoKICAgU3RhbmRhcmRzIERvY3VtZW50OiBSRkMyMTA0CgogICBbSWRlbnRpZmllcnMgZGVmaW5l ZCBpbiB4bWxkc2lnLWNvcmU6IFhNTC1TaWduYXR1cmUgU3ludGF4IGFuZAogICBQcm9jZXNzaW5n XQoKICAgSWRlbnRpZmllcjogW01vZGUgPVNIQTFdIFt1cmkKICAgPWh0dHA6Ly93d3cudzMub3Jn LzIwMDAvMDkveG1sZHNpZyNobWFjLXNoYTFdCgoKCgoKSGFsbGFtLUJha2VyICAgICAgICAgICAg ICAgRXhwaXJlcyBNYXkgNCwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJu ZXQtRHJhZnQgICAgIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIElkZW50aWZpZXJzICAgICBOb3Zl bWJlciAyMDA3CgoKMy4zLiAgT25lIFRpbWUgUGFzc3dvcmQKCiAgIE5vIGFsZ29yaXRobXMgcmVn aXN0ZXJlZCB5ZXQuCgozLjQuICBDb21iaW5hdGlvbiBNb2RlcwoKICAgTm8gYWxnb3JpdGhtcyBy ZWdpc3RlcmVkIHlldC4KCgo0LiAgQXN5bW1ldHJpYyBBbGdvcml0aG1zCgo0LjEuICBLZXkgQWdy ZWVtZW50Cgo0LjEuMS4gIERpZmZpZS1IZWxsbWFuCgogICBTdGFuZGFyZHMgRG9jdW1lbnQ6IFJG QzI2MzEKCiAgIFN0YW5kYXJkcyBEb2N1bWVudDogWDkuNDIKCiAgIFtJZGVudGlmaWVycyBkZWZp bmVkIGluIHhtbGVuYy1jb3JlOiBYTUwgRW5jcnlwdGlvbiBTeW50YXggYW5kCiAgIFByb2Nlc3Np bmddCgogICBJZGVudGlmaWVyOiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu YyNkaF0KCjQuMS4yLiAgUlNBCgogICBTdGFuZGFyZHMgRG9jdW1lbnQ6IFJGQzI0MzcKCiAgIFtJ ZGVudGlmaWVycyBkZWZpbmVkIGluIHhtbGRzaWctY29yZTogWE1MLVNpZ25hdHVyZSBTeW50YXgg YW5kCiAgIFByb2Nlc3NpbmddCgogICBJZGVudGlmaWVyOiBbTW9kZSA9U0hBMV0gW3VyaQogICA9 aHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExXQoKICAgW0lkZW50aWZp ZXJzIGRlZmluZWQgaW4geG1sZW5jLWNvcmU6IFhNTCBFbmNyeXB0aW9uIFN5bnRheCBhbmQKICAg UHJvY2Vzc2luZ10KCiAgIElkZW50aWZpZXI6IFt1cmkgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEv MDQveG1sZW5jI3JzYS0xXzVdCgogICBJZGVudGlmaWVyOiBbdXJpID1odHRwOi8vd3d3LnczLm9y Zy8yMDAxLzA0L3htbGVuYyNyc2Etb2FlcC1tZ2YxcF0KCiAgIFtJZGVudGlmaWVycyBkZWZpbmVk IGluIDogXQoKICAgSWRlbnRpZmllcjogW0ROU1NFQyBDb2RlPTVdIFtNb2RlID1zaGExXQoKICAg SWRlbnRpZmllcjogW0ROU1NFQyBDb2RlPTFdIFtNb2RlID1tZDVdCgoKCgoKSGFsbGFtLUJha2Vy ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNCwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl IDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgIENyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIElkZW50aWZp ZXJzICAgICBOb3ZlbWJlciAyMDA3CgoKNC4yLiAgU2lnbmF0dXJlCgo0LjIuMS4gIFJTQQoKICAg U3RhbmRhcmRzIERvY3VtZW50OiBSRkMyNDM3CgogICBbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4 bWxkc2lnLWNvcmU6IFhNTC1TaWduYXR1cmUgU3ludGF4IGFuZAogICBQcm9jZXNzaW5nXQoKICAg SWRlbnRpZmllcjogW01vZGUgPVNIQTFdIFt1cmkKICAgPWh0dHA6Ly93d3cudzMub3JnLzIwMDAv MDkveG1sZHNpZyNyc2Etc2hhMV0KCiAgIFtJZGVudGlmaWVycyBkZWZpbmVkIGluIHhtbGVuYy1j b3JlOiBYTUwgRW5jcnlwdGlvbiBTeW50YXggYW5kCiAgIFByb2Nlc3NpbmddCgogICBJZGVudGlm aWVyOiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNyc2EtMV81XQoKICAg SWRlbnRpZmllcjogW3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjcnNhLW9h ZXAtbWdmMXBdCgogICBbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiA6IF0KCiAgIElkZW50aWZpZXI6 IFtETlNTRUMgQ29kZT01XSBbTW9kZSA9c2hhMV0KCiAgIElkZW50aWZpZXI6IFtETlNTRUMgQ29k ZT0xXSBbTW9kZSA9bWQ1XQoKNC4zLiAgRW5jcnlwdGlvbgoKNC4zLjEuICBSU0EKCiAgIFN0YW5k YXJkcyBEb2N1bWVudDogUkZDMjQzNwoKICAgW0lkZW50aWZpZXJzIGRlZmluZWQgaW4geG1sZHNp Zy1jb3JlOiBYTUwtU2lnbmF0dXJlIFN5bnRheCBhbmQKICAgUHJvY2Vzc2luZ10KCiAgIElkZW50 aWZpZXI6IFtNb2RlID1TSEExXSBbdXJpCiAgID1odHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjcnNhLXNoYTFdCgogICBbSWRlbnRpZmllcnMgZGVmaW5lZCBpbiB4bWxlbmMtY29yZTog WE1MIEVuY3J5cHRpb24gU3ludGF4IGFuZAogICBQcm9jZXNzaW5nXQoKICAgSWRlbnRpZmllcjog W3VyaSA9aHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjcnNhLTFfNV0KCiAgIElkZW50 aWZpZXI6IFt1cmkgPWh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3JzYS1vYWVwLW1n ZjFwXQoKICAgW0lkZW50aWZpZXJzIGRlZmluZWQgaW4gOiBdCgogICBJZGVudGlmaWVyOiBbRE5T U0VDIENvZGU9NV0gW01vZGUgPXNoYTFdCgoKCgpIYWxsYW0tQmFrZXIgICAgICAgICAgICAgICBF eHBpcmVzIE1heSA0LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1E cmFmdCAgICAgQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gSWRlbnRpZmllcnMgICAgIE5vdmVtYmVy IDIwMDcKCgogICBJZGVudGlmaWVyOiBbRE5TU0VDIENvZGU9MV0gW01vZGUgPW1kNV0KCgo1LiAg WE1MIFRyYW5mb3JtYXRpb24KCjUuMS4gIENhbm9uaWNhbGl6YXRpb24KCiAgIE5vIGFsZ29yaXRo bXMgcmVnaXN0ZXJlZCB5ZXQuCgoKNi4gIEVuY29kaW5nCgo2LjEuICBCaW5hcnkKCjYuMS4xLiAg QmFzZSA2NAoKICAgU3RhbmRhcmRzIERvY3VtZW50OiBCYXNlNjQKCiAgIFtJZGVudGlmaWVycyBk ZWZpbmVkIGluIHhtbGRzaWctY29yZTogWE1MLVNpZ25hdHVyZSBTeW50YXggYW5kCiAgIFByb2Nl c3NpbmddCgogICBJZGVudGlmaWVyOiBbdXJpID1odHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjYmFzZTY0XQoKCjcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVEJTCgoKOC4g IElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRCUwoKCjkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgWzgwMC02N10gICAiUmVjb21tZW5kYXRpb24gZm9yIHRoZSBUcmlwbGUgRGF0YSBFbmNyeXB0 aW9uIEFsZ29yaXRobQogICAgICAgICAgICAgIChUREVBKSBCbG9jayBDaXBoZXIiLCBNYXkgMjAw NC4KCiAgIFtDU09SXSAgICAgIkNyeXB0b2dyYXBoaWMgQWxnb3JpdGhtIE9iamVjdCBSZWdpc3Ry YXRpb24iLgoKICAgW0ZJUFMgMTk3XQogICAgICAgICAgICAgICJBZHZhbmNlZCBFbmNyeXB0aW9u IFN0YW5kYXJkIChBRVMpIiwgTm92ZW1iZXIgMjAwMS4KCiAgIFtSRkMyMTA0XSAgIkhNQUM6IEtl eWVkLUhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb24iLAogICAgICAgICAgICAgIEZl YnJ1YXJ5IDE5OTcuCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQoKCgpIYWxsYW0tQmFrZXIgICAgICAgICAgICAgICBFeHBp cmVzIE1heSA0LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFm dCAgICAgQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG0gSWRlbnRpZmllcnMgICAgIE5vdmVtYmVyIDIw MDcKCgogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks IE1hcmNoIDE5OTcuCgogICBbUkZDMjQzN10gICJQS0NTICMxOiBSU0EgQ3J5cHRvZ3JhcGh5IFNw ZWNpZmljYXRpb25zIFZlcnNpb24gMi4wIiwKICAgICAgICAgICAgICBPY3RvYmVyIDE5OTguCgog ICBbUkZDMjU2MF0gIE15ZXJzLCBNLiwgQW5rbmV5LCBSLiwgTWFscGFuaSwgQS4sIEdhbHBlcmlu LCBTLiwgYW5kIEMuCiAgICAgICAgICAgICAgQWRhbXMsICJYLjUwOSBJbnRlcm5ldCBQdWJsaWMg S2V5IEluZnJhc3RydWN0dXJlIE9ubGluZQogICAgICAgICAgICAgIENlcnRpZmljYXRlIFN0YXR1 cyBQcm90b2NvbCAtIE9DU1AiLCBSRkMgMjU2MCwgSnVuZSAxOTk5LgoKICAgW1JGQzI2MzFdICAi RGlmZmllLUhlbGxtYW4gS2V5IEFncmVlbWVudCBNZXRob2QiLCBKdW5lIDE5OTkuCgogICBbUkZD NDAzNF0gICIiLgoKICAgW1JGQzQ1MDldICAiIi4KCiAgIFtSRkM0ODY4XSAgIlVzaW5nIEhNQUMt U0hBLTI1NiwgSE1BQy1TSEEtMzg0LCBhbmQgSE1BQy1TSEEtNTEyIHdpdGgKICAgICAgICAgICAg ICBJUHNlYyIuCgogICBbWDkuNDJdICAgICJBZ3JlZW1lbnQgb2YgU3ltbWV0cmljIEtleXMgVXNp bmcgRGlzY3JldGUgTG9nYXJpdGhtCiAgICAgICAgICAgICAgQ3J5cHRvZ3JhcGh5Ii4KCiAgIFtY OS41Ml0gICAgIlRyaXBsZSBEYXRhIEVuY3J5cHRpb24gQWxnb3JpdGhtIE1vZGVzIG9mIE9wZXJh dGlvbiIsCiAgICAgICAgICAgICAgMTk5OC4KCiAgIFtYTUwtQzE0XSAgIlhNTCBDYW5vbmljYWxp emF0aW9uIi4KCiAgIFtYTUwtWEMxNF0KICAgICAgICAgICAgICAiRXhjbHVzaXZlIFhNTCBDYW5v bmljYWxpemF0aW9uIi4KCiAgIFt4bWxkc2lnLWNvcmVdCiAgICAgICAgICAgICAgIlhNTC1TaWdu YXR1cmUgU3ludGF4IGFuZCBQcm9jZXNzaW5nIiwgRmVicnVhcnkgMjAwMi4KCiAgIFt4bWxlbmMt Y29yZV0KICAgICAgICAgICAgICAiWE1MIEVuY3J5cHRpb24gU3ludGF4IGFuZCBQcm9jZXNzaW5n Ii4KCiAgIFt4cGF0aF0gICAgIlhNTCBQYXRoIExhbmd1YWdlIChYUGF0aCkgVmVyc2lvbiAxLjAi LCBOb3ZlbWJlciAxOTk5LgoKICAgW3hzbHRdICAgICAiWFNMIFRyYW5zZm9ybWF0aW9ucyAoWFNM VCkgVmVyc2lvbiAxLjAiLCBOb3ZlbWJlciAxNi4KCgpBdXRob3IncyBBZGRyZXNzCgogICBQaGls bGlwIEhhbGxhbS1CYWtlcgogICBWZXJpU2lnbiBJbmMKCiAgIEVtYWlsOiBwYmFrZXJAdmVyaXNp Z24uY29tCgoKCgoKSGFsbGFtLUJha2VyICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNCwgMjAw OCAgICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgIENyeXB0b2dy YXBoaWMgQWxnb3JpdGhtIElkZW50aWZpZXJzICAgICBOb3ZlbWJlciAyMDA3CgoKRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4K CiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQg cmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKICAg VGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHBy b3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9S R0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFO WSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQKICAgVEhFIElOVEVS TkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MKICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFO VFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G UklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCgpJbnRlbGxlY3R1 YWwgUHJvcGVydHkKCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55CiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMg b3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bwogICBwZXJ0YWluIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluCiAg IHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBz dWNoIHJpZ2h0cwogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBp dCByZXByZXNlbnQgdGhhdCBpdCBoYXMKICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRv IGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uCiAgIG9uIHRoZSBwcm9jZWR1 cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUKICAgZm91 bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1h ZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQogICBhc3N1cmFuY2VzIG9mIGxpY2Vu c2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuCiAgIGF0dGVtcHQg bWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz ZSBvZgogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMg b2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9u LWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuCgogICBU aGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRl bnRpb24gYW55CiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywg b3Igb3RoZXIgcHJvcHJpZXRhcnkKICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kg dGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50CiAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQKICAgaWV0Zi1pcHJAaWV0 Zi5vcmcuCgoKQWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1 bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRoZSBJRVRGCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQg QWN0aXZpdHkgKElBU0EpLgoKCgoKCkhhbGxhbS1CYWtlciAgICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDQsIDIwMDggICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCgo= ------_=_NextPart_001_01C81D8B.165103E3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C81D8B.165103E3-- From keyprov-bounces@ietf.org Mon Nov 05 04:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioy7z-0002MX-6n; Mon, 05 Nov 2007 04:20:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioy7x-0002Ih-Vb for keyprov@ietf.org; Mon, 05 Nov 2007 04:20:13 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ioy7w-0001eO-Eh for keyprov@ietf.org; Mon, 05 Nov 2007 04:20:13 -0500 Received: (qmail invoked by alias); 05 Nov 2007 09:20:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp037) with SMTP; 05 Nov 2007 10:20:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19+5OlE5tB+bGMtI43llHQCwijoQCuaiHMy7lTLAJ xxUxbnJP6NrqWR Message-ID: <472EE04B.9020904@gmx.net> Date: Mon, 05 Nov 2007 10:20:11 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [KEYPROV] [Fwd: I-D Action:draft-hallambaker-algorithm-identifiers-00.txt] X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org FYI -------- Original Message -------- Subject: I-D Action:draft-hallambaker-algorithm-identifiers-00.txt Date: Sun, 04 Nov 2007 22:20:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cryptographic Algorithm Identifiers Author(s) : P. Hallam-Baker Filename : draft-hallambaker-algorithm-identifiers-00.txt Pages : 9 Date : 2007-11-04 Preferred identifiers for cryptographic algorithms currently in use in Internet standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hallambaker-algorithm-identifiers-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hallambaker-algorithm-identifiers-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hallambaker-algorithm-identifiers-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 08 15:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqE2G-0004uf-L2; Thu, 08 Nov 2007 15:31:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqE2F-0004nh-Jo for keyprov@ietf.org; Thu, 08 Nov 2007 15:31:31 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqE2E-00044m-GJ for keyprov@ietf.org; Thu, 08 Nov 2007 15:31:31 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA8KVPNT016365; Thu, 8 Nov 2007 15:31:25 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Thu, 8 Nov 2007 15:31:25 -0500 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA8KVLT4029061; Thu, 8 Nov 2007 15:31:22 -0500 (EST) Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id lA8KVGuS021613; Thu, 8 Nov 2007 15:31:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Date: Thu, 8 Nov 2007 15:31:15 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D23AB0B@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23FB@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMAQ13Z+Q References: <1190365090.79.0.72059660846.issue28@http://www.tschofenig.priv.at><5BFE9E473DBFC24CA87F18F29B3F0AC4758281@sur-corp-ex-02.corp.ad.activcard.com><017630AA6DF2DF4EBC1DD4454F8EE2970CE9B017@rsana-ex-hq1.NA.RSA.NET> <5BFE9E473DBFC24CA87F18F29B3F0AC4FA23FB@sur-corp-ex-02.corp.ad.activcard.com> From: "Doherty, Andrea" To: "Philip Hoyer" , "KEYPROV Roundup Issue Tracker" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: "Bajaj, Siddharth" , "M'Raihi, David" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Philip, Thank you for your proposal. Here are a few comments: 1. By do you mean "PIN is enabled"? Is the reverse true, that indicates = PINless operation from a server's point of view?=20 2. Instead of , providing a PINUsageModeType would be more extensible and implementable: 3. Anders brought to my attention that a local PIN is needed instead of a server PIN in some scenarios. The device issuer, in this case, would also have a PIN policy that could differ from the policy of a server PIN. Anders provided the following example, which is taken from another standardization effort in the workings ("PKI for Web 2.0"): // The following is sent down to the client by the issuer: // Request a key without PIN protection. // Request a set of keys with PIN protection. // The specified policy disallows 11122 but accepts 11223 // 654321 would not be accepted either (sequence) // The next element is optional and is a way of grouping PINs // so that the user either only has to specify a single PIN // for a set of keys, or one unique PIN per key. Your thoughts? Andrea=20 -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Thursday, October 18, 2007 6:16 AM To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Andrea, You are right I have not addressed the Pin policy issue. I would like to though.=20 Since you seem to have a good idea of the requirements would you be able to help? I suggest we create a new type called PINPolicy that contains the data required to be submitted. So currently PIN usage I can think of is: -KEY_ACCESS_CHECK (this check the pin on the device to allow access to a key for algorithms) -USED_IN_ALGO (used during calculation) When you talk though about length I already have that in the part of the PIN 'key' see below NEW-> Credential Issuer MyFirstTokenInitialPIN WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D <-NEW Also when we talk about server verified pins in otps are we not really talking about the otp algo or usage here? I was wondering hence if our usage element for the otp key should be augmented to contain and optional What do you think? Philip -----Original Message----- From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 Sent: Thursday, October 18, 2007 1:28 AM To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Philip, This looks ok except that a more complex PIN policy is needed (refer to this comment I made to the previous version of the PSKC draft, Section 5.1.7: "Recommend that you allow for a more complex PIN policy, esp., (a) how the PIN is to be used in the OTP calculation (e.g., concatenated vs. XOR's with the token code) and (b) PIN length. " This doesn't seem to have been addressed yet based on feedback to my review (see attached) and example below. What is the status of this? =20 Andrea -----Original Message----- From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Friday, September 28, 2007 11:48 AM To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to a clientviaPSKC? Gentlemen, Since PSKC will be used also to bulk provision from manufacturing to a validation server and some of these devices do have a PIN pad there is the concept of an initial PIN. Since we have not yet defined how this initial PIN is transmitted in the PSKC spec I would like to put forward a proposal for inclusion in the spec for specifying the transmission of PINs. The PIN is effectively another shared secret hence I propose to treat it as a key in itself. This has the advantage that we can leverage the Usage part of the schema that can define things like length and format (alphanumeric etc). we also can set an expiry etc. It also leverages the fact that the PIN itself will be encrypted in transport in the same manner as other key material. I hence propose to extend the KeyAlgorithmType with a new type called 'userPIN' (inline with the name used in the access rules element already present) As an example a KeyContainer with a non encrypted HOTP key and a 4 digit numeric PIN (please note that the value and valuedigest are just copy and paste) ( I put the new section with NEW-> and <-NEW lines before and after): Token Manufacturer 98765432187 01/01/2008 Credential Issuer NEW-> <-NEW MyFirstToken WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D NEW-> Credential Issuer MyFirstTokenInitialPIN WldjTHZwRm9YTkhBRytseDMrUnc=3D WldjTHZwRm9YTkhBRytseDM=3D <-NEW Comments are welcome, Philip -----Original Message----- From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, September 21, 2007 9:58 AM To: keyprov@ietf.org Subject: [KEYPROV] [issue28] How to transfer initial PIN to a client viaPSKC? New submission from Mingliang Pei : PSKC provies support about carrying PIN usage policy. When PIN is used, how do=20 you actually transfer the initial PIN using PSKC? Should PIN be treated as=20 another credential, for example? ---------- assignedto: mpei messages: 71 nosy: keyprov, mpei priority: critical status: chatting title: How to transfer initial PIN to a client via PSKC? _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Nov 12 20:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irktj-0005OO-V2; Mon, 12 Nov 2007 20:49:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irkti-0005KC-AL for keyprov@ietf.org; Mon, 12 Nov 2007 20:49:02 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irkte-00053C-SU for keyprov@ietf.org; Mon, 12 Nov 2007 20:49:00 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAD1iEua016931; Mon, 12 Nov 2007 17:44:14 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 17:48:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Date: Mon, 12 Nov 2007 17:48:06 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9577460@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <017630AA6DF2DF4EBC1DD4454F8EE2970D23AB0B@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMAQ13Z+QAMedW/A= From: "Pei, Mingliang" To: "Doherty, Andrea" , "Philip Hoyer" , "KEYPROV Roundup Issue Tracker" , X-OriginalArrivalTime: 13 Nov 2007 01:48:07.0987 (UTC) FILETIME=[3D5D4030:01C82597] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: "M'Raihi, David" , "Bajaj, Siddharth" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I have chatted with Philip / Salah about my comments this afternoon while I was almost done my reply of this email. I sent it anyway now for broad review. Our meeting minutes from Philip later will contain other proposed changes in our discussion. 1. A PIN is associated with a key; we need to define a better way to associate with them when we carry PIN in a separate Key type. - The current proposal assumes that all keys in the same "Device" type will associate to the PIN credential in the same Device. - This has a limitation for "PREPEND" case where a device may have multiple keys, and each key has its own PIN as part of server authentication. 2. There is use case when a PIN is per device, instead of per key, for the "Local" access usage.=20 So I prefer defining PIN credential inside DeviceType, and refered by KeyType by an attribute or element, and DeviceType. 3. PIN policy is fine to have its own type. The AccessRule and PINUsageModeType should combine to be a PIN usage policy. If we are treating PIN as a separate credential, it is more consistent to make PIN usage policy part of Usage, I think. Thanks, - Ming =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, November 08, 2007 12:31 PM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Philip, >=20 > Thank you for your proposal. Here are a few comments: >=20 > 1. By do you mean "PIN is=20 > enabled"? Is the reverse true, that userPIN=3D"false"/> indicates PINless operation from a server's=20 > point of view?=20 >=20 > 2. Instead of , providing=20 > a PINUsageModeType would be more extensible and implementable: > > > > > > > >=20 > 3. Anders brought to my attention that a local PIN is needed=20 > instead of a server PIN in some scenarios. The device=20 > issuer, in this case, would also have a PIN policy that could=20 > differ from the policy of a server PIN. Anders provided the=20 > following example, which is taken from another=20 > standardization effort in the workings ("PKI for Web 2.0"): >=20 > // The following is sent down to the client by the issuer: >=20 > >=20 > // Request a key without PIN protection. >=20 > > > > > >=20 > // Request a set of keys with PIN protection. > // The specified policy disallows 11122 but accepts 11223 //=20 > 654321 would not be accepted either (sequence) >=20 > PatternRestrictions=3D"three-in-a-row sequences"> >=20 > // The next element is optional and is a way of grouping PINs=20 > // so that the user either only has to specify a single PIN=20 > // for a set of keys, or one unique PIN per key. >=20 > >=20 > > > > > > > > > > >=20 > >=20 > >=20 > >=20 > Your thoughts? > Andrea=20 >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Thursday, October 18, 2007 6:16 AM > To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Andrea, > You are right I have not addressed the Pin policy issue. >=20 > I would like to though.=20 >=20 > Since you seem to have a good idea of the requirements would=20 > you be able to help? >=20 > I suggest we create a new type called PINPolicy that contains=20 > the data required to be submitted. >=20 > So currently PIN usage I can think of is: > -KEY_ACCESS_CHECK (this check the pin on the device to allow=20 > access to a key for algorithms) -USED_IN_ALGO (used during=20 > calculation) >=20 > When you talk though about length I already have that in the=20 > part of the PIN 'key' see below >=20 > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW >=20 > Also when we talk about server verified pins in otps are we=20 > not really talking about the otp algo or usage here? >=20 > I was wondering hence if our usage element for the otp key=20 > should be augmented to contain and optional >=20 > >=20 > What do you think? >=20 > Philip >=20 >=20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com] > Sent: Thursday, October 18, 2007 1:28 AM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Philip, > This looks ok except that a more complex PIN policy is needed=20 > (refer to this comment I made to the previous version of the=20 > PSKC draft, Section > 5.1.7: > "Recommend that you allow for a more complex PIN policy,=20 > esp., (a) how the PIN is to be used in the OTP calculation=20 > (e.g., concatenated vs. > XOR's with the token code) and (b) PIN length. " >=20 > This doesn't seem to have been addressed yet based on=20 > feedback to my review (see attached) and example below. What=20 > is the status of this? =20 > Andrea >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Friday, September 28, 2007 11:48 AM > To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Gentlemen, > Since PSKC will be used also to bulk provision from=20 > manufacturing to a validation server and some of these=20 > devices do have a PIN pad there is the concept of an initial PIN. >=20 > Since we have not yet defined how this initial PIN is=20 > transmitted in the PSKC spec I would like to put forward a=20 > proposal for inclusion in the spec for specifying the=20 > transmission of PINs. >=20 > The PIN is effectively another shared secret hence I propose=20 > to treat it as a key in itself. >=20 > This has the advantage that we can leverage the Usage part of=20 > the schema that can define things like length and format=20 > (alphanumeric etc). we also can set an expiry etc. It also=20 > leverages the fact that the PIN itself will be encrypted in=20 > transport in the same manner as other key material. >=20 > I hence propose to extend the KeyAlgorithmType with a new=20 > type called 'userPIN' (inline with the name used in the=20 > access rules element already > present) >=20 >=20 > As an example a KeyContainer with a non encrypted HOTP key=20 > and a 4 digit numeric PIN (please note that the value and=20 > valuedigest are just copy and paste) ( I put the new section=20 > with NEW-> and <-NEW lines before and > after): >=20 > > xmlns=3D"urn:ietf:params:xml:ns:keyprov:container" > xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo" > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container" > .\keyprov_pskc_schema_v1.1.xsd" version=3D"1.1"> > > > > > Token Manufacturer > 98765432187 > 01/01/2008 > > > Credential Issuer > > > > NEW-> > > <-NEW > MyFirstToken > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW > > >=20 > Comments are welcome, >=20 > Philip >=20 > -----Original Message----- > From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, September 21, 2007 9:58 AM > To: keyprov@ietf.org > Subject: [KEYPROV] [issue28] How to transfer initial PIN to a=20 > client viaPSKC? >=20 >=20 > New submission from Mingliang Pei : >=20 > PSKC provies support about carrying PIN usage policy. When=20 > PIN is used, > how do=20 > you actually transfer the initial PIN using PSKC? Should PIN=20 > be treated > as=20 > another credential, for example? >=20 > ---------- > assignedto: mpei > messages: 71 > nosy: keyprov, mpei > priority: critical > status: chatting > title: How to transfer initial PIN to a client via PSKC? >=20 > _________________________________________________________ > KEYPROV Roundup Issue Tracker > > _________________________________________________________ >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 13 07:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruYQ-0006DT-9x; Tue, 13 Nov 2007 07:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruYO-0006Cd-Hn for keyprov@ietf.org; Tue, 13 Nov 2007 07:07:40 -0500 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IruYH-0007JH-Ur for keyprov@ietf.org; Tue, 13 Nov 2007 07:07:40 -0500 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id E174425ED5F; Tue, 13 Nov 2007 13:07:28 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WKH9YNZ9; Tue, 13 Nov 2007 13:13:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Nov 2007 13:08:14 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA24DA@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSKC] Conference call minutes 11/12/07 Thread-Index: Acgl7d5aif7hCgznRAiUSun09RkNMw== From: "Philip Hoyer" To: , "Salah Machani" , "CHANG Shuh" , , "Hallam-Baker, Phillip" X-Spam-Score: 0.0 (/) X-Scan-Signature: ceb20e3ccfd90d068e2ad6c8a4781b53 Cc: keyprov@ietf.org Subject: [KEYPROV] [PSKC] Conference call minutes 11/12/07 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108524502==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0108524502== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C825EE.08061F36" This is a multi-part message in MIME format. ------_=_NextPart_001_01C825EE.08061F36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: Ming Pei, Salah Machhani, Philip Hoyer =20 * Discussion about PIN provisioning , [Ming] PIN is a credential but to which key does it belong? Do we need to build correlation between to key and pin. Current Philip proposal allows only one PIN per device. Ming proposed put PIN within key. But what happens if we only need to transmit PINs and no key value? Create PIN schema object that uses UsageType replaces access rules and can be set at Device and key level. Philip raises that this is a lot of work. So create a PinPolicy that refers to a key via the keyed hence the PinPolicy element can be embedded in the Key object. Philip to draft new proposal email to list. * Discussed Magnus's email about use of xmlemc: Salah is worried that now a document would be 3 levels deep: DSKPP->PSKC->XMLENC. Is XMLEnc only used for defining container keys? Ming has concern about importing the whole XMLEnc schema. We need to see an example container document. Also discussed that spec would need to have a mandatory modes for interoperability in temrs of XMLenc supported encryption methods (PBE, symmetric key etc) * Philip asked if everyone is happy with URI being attribute or should it be an element. Element normally provides more readability Ming will do a check. * Philip noted that example in 10.1 in spec sent out by Ming has a digest even if un-encrypted-> Ming to change.=20 * Ming brought up that we should indicate more explicitly if a data element is encrypted. Defer that until we decided on use of xmlenc for value part. Current thought if value does not use xmlenc then we should explicitly mention encryption with an optional encrypted=3D"true" attribute in the data element. * Submission of new draft - Ming to check last submission date. The following is a proposal of changes for next submission: * URI - element or attribute * Corrected example * PinPolicy - possibly? * Authors would like to bring xmlenc discussion to IETF meeting so we need examples * Need to star compiling list of open issues for IETF. (Philip currently unable to attend but will assist Ming in creation of slides for IETF meeting) * Ming to add missing Time based HOTP Data names eg 'TIME_DRIFT' * Authors decided that more discussions are needed hence another meeting is scheduled for Wed 14th of November same time as Monday meeting. Philip to send out meeting maker. =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C825EE.08061F36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees: Ming Pei, Salah Machhani, = Philip Hoyer

 

  • Discussion about PIN provisioning , [Ming] PIN is a credential but to which key does it = belong? Do we need to build correlation between to key and pin. Current = Philip proposal allows only one PIN per device. Ming proposed put PIN = within key. But what happens if we only need to transmit PINs and no key value? = Create PIN schema object that uses UsageType replaces access rules and can = be set at Device and key level. Philip raises that this is a lot of work. = So create a PinPolicy that refers to a key via the keyed hence the = PinPolicy element can be embedded in the Key object. Philip to draft new = proposal email to list.
  • Discussed = Magnus’s email about use of xmlemc: Salah is worried that now a document = would be 3 levels deep: DSKPP->PSKC->XMLENC. Is XMLEnc only used for = defining container keys? Ming has concern about importing the whole XMLEnc = schema. We need to see an example container document. Also discussed that = spec would need to have a mandatory modes for interoperability in temrs = of XMLenc supported encryption methods (PBE, symmetric key = etc)
  • Philip = asked if everyone is happy with URI being attribute or should it be an = element. Element normally provides more readability Ming will do a = check.
  • Philip = noted that example in 10.1 in spec sent out by Ming has a digest even if un-encrypted-> Ming to change.
  • Ming = brought up that we should indicate more explicitly if a data element is encrypted. = Defer that until we decided on use of xmlenc for value part. Current = thought if value does not use xmlenc then we should explicitly mention = encryption with an optional encrypted=3D”true” attribute in the = data element.
  • Submission of new draft – Ming to check last submission date. The following is = a proposal of changes for next = submission:
    • URI = – element or attribute
    • Corrected = example
    • PinPolicy – possibly?
  • Authors = would like to bring xmlenc discussion to IETF meeting so we need = examples
  • Need to = star compiling list of open issues for IETF. (Philip currently unable to = attend but will assist Ming in creation of slides for IETF = meeting)
  • Ming to = add missing Time based HOTP Data names eg = ‘TIME_DRIFT’
  • Authors = decided that more discussions are needed hence another meeting is scheduled for = Wed 14th of November same time as Monday meeting. Philip to send out meeting = maker.

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C825EE.08061F36-- --===============0108524502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0108524502==-- From keyprov-bounces@ietf.org Tue Nov 13 14:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1jZ-0004Oh-S1; Tue, 13 Nov 2007 14:47:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1jY-0004KP-0C for keyprov@ietf.org; Tue, 13 Nov 2007 14:47:40 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is1jX-0005By-9r for keyprov@ietf.org; Tue, 13 Nov 2007 14:47:39 -0500 Received: (qmail 5186 invoked from network); 13 Nov 2007 20:47:37 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 13 Nov 2007 20:47:37 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org From: Andrea Doherty Date: Tue, 13 Nov 2007 19:25:03 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1194981903.42.0.0705989312594.issue32@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [KEYPROV] [issue32] Define Implementation Requirements for conformance X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : Which variant(s) is (are) the MUSTs for the client? for the server? Same questions pertain to client authentication mechanisms, DSKPP-PRF=20 realization(s), encryptiong of the pseudorandom nonces sent from the client. Also define whether each Appendix is informational or normative. ---------- messages: 75 nosy: andrea, keyprov priority: critical status: unread title: Define Implementation Requirements for conformance _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 13 15:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is20H-0007Ow-TS; Tue, 13 Nov 2007 15:04:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is20G-0007LX-L1 for keyprov@ietf.org; Tue, 13 Nov 2007 15:04:56 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is20F-0005tI-T7 for keyprov@ietf.org; Tue, 13 Nov 2007 15:04:56 -0500 Received: (qmail 19947 invoked from network); 13 Nov 2007 21:04:54 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 13 Nov 2007 21:04:54 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org From: Andrea Doherty Date: Tue, 13 Nov 2007 19:42:20 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1194982940.61.0.664990948003.issue32@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [KEYPROV] [issue32] Define Implementation Requirements for conformance X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Per comments received from Sean Turner and Hannes, we should specify what a= re=20 MUSTs for conformance to the document, and which Annexes are informational = and=20 which normative. As Hannes noted, this will aid in making the document eas= ier=20 for implementers to consume. Here are Sean's specific questions, which I t= hink=20 encapsulate all the conformance areas: 1 Which variant(s) is(are) the MUSTs for the client? for the server? Does someone claiming conformance to this document need to support 4, 2, and 1-pass or can they claim conformance for just 4, 2, or 1-pass? 2 (sec 4.3.1) Which of the 3 client authentication mechanism is the MUST and which are the SHOULDs for the client? for the server? 3 (sec 4.5.1) What is the MUST DSKPP-PRF for the client? for the server? The last sentence points to Annex E for realizations of the DSKPP-PRF but it is unclear whether the appendix is normative and which realization is required. 4 (sec 4.7) What is the MUST algorithm for encryption of the pseudorandom Nonces sent from the client? 5 Are Annexes A-E information or normative? Please indicate as much. To each point above, here are my comments. Do you agree? 1=2E Variants that are MUSTS for the client are 4-pass or 2-pass (not sure = if its=20 ok to state it this way though), and for the server are 4-pass and 2-pass. 2=2E The MAC is a MUST, the cert is a MAY. 3=2E The appendix is normative, and the two realizations therein are MUSTs = for=20 implementation. 4=2E The MUST algorithm in sec 4.7 is XOR. I think it was clear enough. 5=2E Some Annexes have been moved. There are only now Appendix A (Integrat= ion=20 with P11) and B (Example of DSKPP-PRF Realizations). IMO Appendix A is=20 Informative and B is Normative. ---------- assignedto: -> andrea status: unread -> chatting _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 13 15:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is259-0006kO-9G; Tue, 13 Nov 2007 15:09:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is258-0006ao-75 for keyprov@ietf.org; Tue, 13 Nov 2007 15:09:58 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is257-00060w-HV for keyprov@ietf.org; Tue, 13 Nov 2007 15:09:57 -0500 Received: (qmail 3456 invoked from network); 13 Nov 2007 21:09:56 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 13 Nov 2007 21:09:56 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org From: Andrea Doherty Date: Tue, 13 Nov 2007 19:47:22 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1194983242.58.0.727043421243.issue33@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [KEYPROV] [issue33] Are use cases involving non-authenticated and non-protected transport layer required? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : Should DSKPP support the following use cases: 1=2E Non-protected Transport Layer (Sec 3.9 of Oct 29, 2007 I-D) 2=2E Non-authenticated Transport Layer (Sec 3.10 of Oct 29, 2007 I-D) Assuming a secure transport layer removed complexity from the document. ---------- assignedto: andrea messages: 78 nosy: andrea, keyprov priority: wish status: unread title: Are use cases involving non-authenticated and non-protected transpor= t layer required? _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 11:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishtq-00048j-TH; Thu, 15 Nov 2007 11:49:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishtm-00047O-O4 for keyprov@ietf.org; Thu, 15 Nov 2007 11:49:02 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ishtm-0005ud-1E for keyprov@ietf.org; Thu, 15 Nov 2007 11:49:02 -0500 Received: (qmail 3648 invoked from network); 15 Nov 2007 17:49:00 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 15 Nov 2007 17:49:00 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Thu, 15 Nov 2007 16:26:21 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195143981.63.0.439236696465.issue10@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [KEYPROV] [issue10] Do we need to provide SOAP binding and where if so? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: The question of expressing DSKPP using WSDL 2.0, and thereby including SOAP=20 binding in the core DSKPP document, was raised with the Apps AD. Hannes=20 summarized their comment, which was based on RFC 3205 (BCP 56) as follows: WSDL Usage: Lisa and Chris do not see WSDL as something being=20 useful. In fact, I haven't found a person who argued in favor of WSDL.=20 Hence, I believe we should avoid it. While the value of WSDL usage is controversial, e.g., BCP 56 is probably ou= t-of- date, the decision is to continue expressing DSKPP using XML, and keep the = SOAP=20 binding description in a separate document (see draft-doherty-keyprov-ct-ki= p-ws- 00). ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 12:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isi5J-00062h-D9; Thu, 15 Nov 2007 12:00:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isi5H-00062M-Bc for keyprov@ietf.org; Thu, 15 Nov 2007 12:00:55 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isi5G-0006Ze-Sv for keyprov@ietf.org; Thu, 15 Nov 2007 12:00:55 -0500 Received: (qmail 12112 invoked from network); 15 Nov 2007 18:00:53 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 15 Nov 2007 18:00:51 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org From: Andrea Doherty Date: Thu, 15 Nov 2007 16:38:13 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195144693.89.0.659466505327.issue27@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [KEYPROV] [issue27] DSKPP: K_MAC in Four-Pass X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: Salah Machani replaced K_AUTH with K_MAC and K_MAC=E2=80=99s in four-pass f= or server=20 authentication and key confirmation in this version of the draft: draft-iet= f- keyprov-dskpp-01.txt. ---------- assignedto: -> andrea status: unread -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 12:06:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiAg-0007gs-81; Thu, 15 Nov 2007 12:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiAe-0007fD-Oq for keyprov@ietf.org; Thu, 15 Nov 2007 12:06:28 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsiAZ-000650-An for keyprov@ietf.org; Thu, 15 Nov 2007 12:06:28 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id lAFH6MXb001328 for ; Thu, 15 Nov 2007 12:06:22 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id lAFH6JEm161318 for ; Thu, 15 Nov 2007 10:06:20 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lAFH6Hdn025991 for ; Thu, 15 Nov 2007 10:06:18 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lAFH6G1i025828; Thu, 15 Nov 2007 10:06:16 -0700 In-Reply-To: <1195143981.63.0.439236696465.issue10@http://www.tschofenig.priv.at> References: <1195143981.63.0.439236696465.issue10@http://www.tschofenig.priv.at> Subject: Re: [KEYPROV] [issue10] Do we need to provide SOAP binding and where if so? X-KeepSent: F42020A6:FD58FDC7-86257394:005DA5D9; type=4; name=$KeepSent To: KEYPROV Roundup Issue Tracker X-Mailer: Lotus Notes Release 8.0 August 02, 2007 Message-ID: From: Anthony Nadalin Date: Thu, 15 Nov 2007 11:04:50 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 11/15/2007 10:06:16 MIME-Version: 1.0 X-Spam-Score: -1.4 (-) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0264257888==" Errors-To: keyprov-bounces@ietf.org --===============0264257888== Content-type: multipart/related; Boundary="0__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349" --0__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349 Content-type: multipart/alternative; Boundary="1__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349" --1__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable So why is WSDL not useful, it describes a interface and why wouldn't a = SOAP binding be useful to implement that interface ? Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 |------------> | From: | |------------> >--------------------------------------------------------------------= --------------------------------------------------------------------| |Andrea Doherty = | >--------------------------------------------------------------------= --------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------= --------------------------------------------------------------------| |keyprov@ietf.org, mpei@verisign.com = | >--------------------------------------------------------------------= --------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------= --------------------------------------------------------------------| |11/15/2007 10:58 AM = | >--------------------------------------------------------------------= --------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------= --------------------------------------------------------------------| |[KEYPROV] [issue10] Do we need to provide SOAP binding and where if = so? | >--------------------------------------------------------------------= --------------------------------------------------------------------| Andrea Doherty added the comment: The question of expressing DSKPP using WSDL 2.0, and thereby including = SOAP binding in the core DSKPP document, was raised with the Apps AD. Hannes= summarized their comment, which was based on RFC 3205 (BCP 56) as follo= ws: WSDL Usage: Lisa and Chris do not see WSDL as something being useful. In fact, I haven't found a person who argued in favor of WSDL. Hence, I believe we should avoid it. While the value of WSDL usage is controversial, e.g., BCP 56 is probabl= y out-of- date, the decision is to continue expressing DSKPP using XML, and keep = the SOAP binding description in a separate document (see draft-doherty-keyprov-ct-kip-ws- 00). ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov = --1__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

So why is WSDL not useful, it describes a interface and why wouldn't= a SOAP binding be useful to implement that interface ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

3D"InactiveAndrea Doherty ---11= /15/2007 10:58:23 AM---Andrea Doherty <adoherty@rsa.com> added th= e comment:

=
3D=
From:		= 3D""
Andrea Doherty <hannes.tschofenig@gmx.net>
3D=
To:
keyprov@ietf.org, mpei@verisign.com
3D=
Date:		= 3D""
11/15/2007 10:58 AM
3D=
Subject:		3D""
[KEYPROV] [issue10] Do we need to provide SOAP binding= and where if so?





Andrea Doherty <adoherty@rsa.com> added the comment:

The question of expressing DSKPP using WSDL 2.0, and thereby including = SOAP
binding in the core DSKPP document, was raised with the Apps AD. Hannes=
summarized their comment, which was based on RFC 3205 (BCP 56) as follo= ws:

WSDL Usage: Lisa and Chris do not see WSDL as something being
useful. In fact, I haven't found a person who argued in favor of WSDL. =
Hence, I believe we should avoid it.

While the value of WSDL usage is controversial, e.g., BCP 56 is probabl= y out-of-
date, the decision is to continue expressing DSKPP using XML, and keep = the SOAP
binding description in a separate document (see draft-doherty-keyprov-c= t-kip-ws-
00).

----------
status: chatting -> done-cbb

_________________________________________________________
KEYPROV Roundup Issue Tracker <hannes.tschofenig@gmx.net>
<http://www.tschofenig.priv.at:8080/keyprov/issue10>
_________________________________________________________

_______________________________________________
KEYPROV mailing list
KEYPROV@ietf.org
htt= ps://www1.ietf.org/mailman/listinfo/keyprov

= --1__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349-- --0__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=09BBF907DFCE23498f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=09BBF907DFCE23498f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBF907DFCE23498f9e8a93df938690918c09BBF907DFCE2349-- --===============0264257888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0264257888==-- From keyprov-bounces@ietf.org Thu Nov 15 12:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsirM-0001M0-QK; Thu, 15 Nov 2007 12:50:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsirL-0001Jl-Hp for keyprov@ietf.org; Thu, 15 Nov 2007 12:50:35 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsirI-0008GX-EL for keyprov@ietf.org; Thu, 15 Nov 2007 12:50:35 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAFHoUUc022765; Thu, 15 Nov 2007 12:50:30 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Thu, 15 Nov 2007 12:50:30 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAFHo3Tj014451; Thu, 15 Nov 2007 12:50:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] [issue10] Do we need to provide SOAP binding and whereif so? Date: Thu, 15 Nov 2007 12:47:05 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D3055BA@rsana-ex-hq1.NA.RSA.NET> In-reply-to: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue10] Do we need to provide SOAP binding and whereif so? Thread-Index: AcgnqgSBv+4fMynqTYmUjiD5bmUmCAAArEtA References: <1195143981.63.0.439236696465.issue10@http://www.tschofenig.priv.at> From: "Doherty, Andrea" To: "Anthony Nadalin" , "KEYPROV Roundup Issue Tracker" X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __EMBEDDED_IMG 0, __EXTRA_MPART_TYPE_1 0, __EXTRA_MPART_TYPE_N1 0, __GIF_ATTACHED 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -0.4 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: keyprov@ietf.org X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795202728==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1795202728== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C827AF.8986AB01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C827AF.8986AB01 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C827AF.8986AB01" ------_=_NextPart_002_01C827AF.8986AB01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it is useful. That said, the issue is a bit complicated, esp. as it stems from BCP 56. Although you may have seen it already, check out the email exchange on the KEYPROV mailing list on this issue (dated 9/30/07 - 10/9/07). For example, here are two excerpts from the exchange; Chris Newman said, I largely support BCP 56 and as an IESG member I consider it my duty and within=20 my authority to enforce that BCP using my best judgment. However, some of the=20 advice it gives could be updated to make it better and it could use advice in=20 additional areas -- I would support an effort to revise it, although the present HTTP WG proposal may not be the right place to do that work. I'm uncomfortable when my best technical judgment disagrees with common practice=20 and am unlikely to use my IESG authority to permanently block forward progress=20 on a document in that case. However, when I'm aware of a BCP rule and agree=20 with it, I consider it my duty at a minimum to verify the community considered=20 the rule and had explicit community rough consensus to violate it. Phillip Hallam-Baker: Web Services is a standards based architecture with broad industry-wide support. Keith's RFC was written in 2002 before the Web Services architecture was developed. There is clearly a conflict between the views being advance here and established practice for the design and implementation of Web Services based specifications. It is not helpful here if the IETF is going to insist on a separate definition of Web Services specifications that is not in sync with where the Web Services world is. Either the BCP56 view is right in which case we need the proponents of this view to be talking to the wider Web Services world (OASIS, W3C) and arriving at a consensus position or the BCP56 view is obsolete and needs to be updated. In either case this is an issue that the IAB needs to address. BCP56 is their work product, I believe. They need to be maintaining it. In particular the idea that WSDL is somehow dispensible as a component in the Web Services architecture is not a widely held position within the Web Services world.=20 -- Andrea ________________________________ From: Anthony Nadalin [mailto:drsecure@us.ibm.com]=20 Sent: Thursday, November 15, 2007 12:05 PM To: KEYPROV Roundup Issue Tracker Cc: keyprov@ietf.org Subject: Re: [KEYPROV] [issue10] Do we need to provide SOAP binding and whereif so? So why is WSDL not useful, it describes a interface and why wouldn't a SOAP binding be useful to implement that interface ? Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 Andrea Doherty ---11/15/2007 10:58:23 AM---Andrea Doherty added the comment: =20 From: =20 Andrea Doherty =09 To: =20 keyprov@ietf.org, mpei@verisign.com=09 Date: =20 11/15/2007 10:58 AM=09 Subject: =20 [KEYPROV] [issue10] Do we need to provide SOAP binding and where if so?=09 ________________________________ Andrea Doherty added the comment: The question of expressing DSKPP using WSDL 2.0, and thereby including SOAP=20 binding in the core DSKPP document, was raised with the Apps AD. Hannes=20 summarized their comment, which was based on RFC 3205 (BCP 56) as follows: WSDL Usage: Lisa and Chris do not see WSDL as something being=20 useful. In fact, I haven't found a person who argued in favor of WSDL.=20 Hence, I believe we should avoid it. While the value of WSDL usage is controversial, e.g., BCP 56 is probably out-of- date, the decision is to continue expressing DSKPP using XML, and keep the SOAP=20 binding description in a separate document (see draft-doherty-keyprov-ct-kip-ws- 00). ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_002_01C827AF.8986AB01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think it is useful.  That said, the = issue is a=20 bit complicated, esp. as it stems from BCP 56.  Although you may = have seen=20 it already, check out the email=20 exchange on the KEYPROV mailing list on this issue (dated 9/30/07 -=20 10/9/07).  For example, here are two excerpts from the=20 exchange;

Chris Newman said,

I largely support BCP 56 and as = an IESG=20 member I consider it my duty and within
my authority to enforce that BCP using my best judgment. = However, some of=20 the
advice it gives could = be updated=20 to make it better and it could use advice in
additional areas -- I would support an effort to revise it, = although the=20
present HTTP WG proposal = may not be=20 the right place to do that work. I'm
uncomfortable when my best technical judgment disagrees with = common=20 practice
and am unlikely = to use my=20 IESG authority to permanently block forward progress
on a document in that case. However, when = I'm aware of=20 a BCP rule and agree
with = it, I=20 consider it my duty at a minimum to verify the community considered=20
the rule and had explicit = community=20 rough consensus to violate it.

Phillip=20 Hallam-Baker:

Web Services is a standards based = architecture with broad industry-wide support. Keith's RFC was written = in 2002=20 before the Web Services architecture was developed. There is clearly a = conflict=20 between the views being advance here and established practice for the = design and=20 implementation of Web Services based specifications.

It is not helpful here if the = IETF is going=20 to insist on a separate definition of Web Services specifications that = is not in=20 sync with where the Web Services world is.

Either the BCP56 view is right in = which case=20 we need the proponents of this view to be talking to the wider Web = Services=20 world (OASIS, W3C) and arriving at a consensus position or the BCP56 = view is=20 obsolete and needs to be updated.

In either case this is an issue = that the IAB=20 needs to address. BCP56 is their work product, I believe. They need to = be=20 maintaining it.

In particular the idea that = WSDL is=20 somehow dispensible as a component in the Web Services architecture is = not a=20 widely held position within the Web Services world.

--=20 Andrea


From: Anthony Nadalin=20 [mailto:drsecure@us.ibm.com]
Sent: Thursday, November 15, = 2007 12:05=20 PM
To: KEYPROV Roundup Issue Tracker
Cc:=20 keyprov@ietf.org
Subject: Re: [KEYPROV] [issue10] Do we need = to=20 provide SOAP binding and whereif so?

So why is WSDL not useful, it describes a interface and why wouldn't = a SOAP=20 binding be useful to implement that interface ?

Anthony Nadalin | = Work=20 512.838.0085 | Cell 512.289.4122

3D"Inactive added the comment:"=20 src=3D"cid:629512617@15112007-08A3" width=3D16 border=3D0>Andrea=20 Doherty ---11/15/2007 10:58:23 AM---Andrea Doherty = <adoherty@rsa.com>=20 added the comment:

3D""
From:		 3D""
Andrea Doherty=20 <hannes.tschofenig@gmx.net>
3D""
To:		 3D""
keyprov@ietf.org,=20 mpei@verisign.com
3D""
Date:		 3D""
11/15/2007 10:58 = AM
3D""
Subject:		 3D""
[KEYPROV] [issue10] Do we = need to=20 provide SOAP binding and where if = so?





Andrea Doherty <adoherty@rsa.com> added the=20 comment:

The question of expressing DSKPP using WSDL 2.0, and = thereby=20 including SOAP
binding in the core DSKPP document, was raised with = the Apps=20 AD. Hannes
summarized their comment, which was based on RFC 3205 = (BCP 56) as=20 follows:

WSDL Usage: Lisa and Chris do not see WSDL as something = being=20
useful. In fact, I haven't found a person who argued in favor of = WSDL.=20
Hence, I believe we should avoid it.

While the value of WSDL = usage is=20 controversial, e.g., BCP 56 is probably out-of-
date, the decision is = to=20 continue expressing DSKPP using XML, and keep the SOAP
binding = description=20 in a separate document (see=20 draft-doherty-keyprov-ct-kip-ws-
00).

----------
status: = chatting=20 ->=20 done-cbb

_________________________________________________________=
KEYPROV=20 Roundup Issue Tracker = <hannes.tschofenig@gmx.net>
<http://www.tschof= enig.com:8080/keyprov/issue10>
_______________________= __________________________________

_______________________________= ________________
KEYPROV=20 mailing list
KEYPROV@ietf.org
https://www1.ietf= .org/mailman/listinfo/keyprov

------_=_NextPart_002_01C827AF.8986AB01-- ------_=_NextPart_001_01C827AF.8986AB01 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <629512617@15112007-08A3> Content-Description: graycol.gif Content-Location: graycol.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C827AF.8986AB01 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <629512617@15112007-08AA> Content-Description: ecblank.gif Content-Location: ecblank.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C827AF.8986AB01-- --===============1795202728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1795202728==-- From keyprov-bounces@ietf.org Thu Nov 15 17:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsnB8-0000Hu-RP; Thu, 15 Nov 2007 17:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsnB7-0000HQ-DR for keyprov@ietf.org; Thu, 15 Nov 2007 17:27:17 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsnB3-0000tg-PA for keyprov@ietf.org; Thu, 15 Nov 2007 17:27:17 -0500 Received: (qmail 14042 invoked from network); 15 Nov 2007 23:27:11 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 15 Nov 2007 23:27:10 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Thu, 15 Nov 2007 22:04:32 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195164272.14.0.613833367074.issue11@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.8 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [KEYPROV] [issue11] Is special keyprov HTTP header definition required? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Andrea Doherty added the comment: According to discussions with Applications Area Director, we are doing fine=20 with the usage of XML and the registration of a new mime type. As mentioned in early message, a special KEYPROV HTTP header definition is=20 neither required nor defined in DSKPP, and so this issue is done. ---------- status: chatting -> done-cbb _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 17:57:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isne8-0003B8-04; Thu, 15 Nov 2007 17:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isne6-00039C-Kq for keyprov@ietf.org; Thu, 15 Nov 2007 17:57:14 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isne2-0001th-Kk for keyprov@ietf.org; Thu, 15 Nov 2007 17:57:14 -0500 Received: (qmail 5597 invoked from network); 15 Nov 2007 23:57:09 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 15 Nov 2007 23:57:09 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Thu, 15 Nov 2007 22:34:31 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195166071.14.0.0818184132455.issue34@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [KEYPROV] [issue34] Authentication Code Format X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : After some discussion on the mailing list, it appears that the current way = of=20 defining the Authentication Code (AUTHCODE) is too specific for DSKPP, and = that=20 it would be better to make the code more extensible/flexible for the=20 application. Currently, the document (see Section 5.3.3) specifies the for= mat=20 of AUTHCODE to be: AUTHCODE =3D passwordLen || identifier || password || checksum Two alternative proposals are: (1) Use TLV for the format of AUTHCODE E.g. Tag =3D 0x01 =3D password Tag =3D 0x02 =3D identifier Tag =3D 0x03 =3D checksum and then use one (or two) byte(s) to indicate the length of the V(alue)=20 field? (2) AuthCode =3D Code (unformatted) The spec always asks for an ID and code. ID field will be placed in Clien= tID=20 element and Code is used to generate hash data for the AuthenticationData. = It=20 is up to a service vendor how they will pass ID and code together or separa= tely=20 to its end users and how they will choose to input to a client. ---------- assignedto: mpei messages: 83 nosy: andrea, keyprov, mpei priority: critical status: chatting title: Authentication Code Format _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 18:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isnir-0007tU-1X; Thu, 15 Nov 2007 18:02:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isniq-0007su-6h for keyprov@ietf.org; Thu, 15 Nov 2007 18:02:08 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isnin-00023a-IE for keyprov@ietf.org; Thu, 15 Nov 2007 18:02:08 -0500 Received: (qmail 13920 invoked from network); 16 Nov 2007 00:02:04 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 16 Nov 2007 00:02:04 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Thu, 15 Nov 2007 22:39:25 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195166365.79.0.00149359395795.issue35@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [KEYPROV] [issue35] Schema Refinement X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : Two possibilities for refinement: 1=2E Change elementDefault=3Dunqualified to qualified As noted by Anders Rundgren, the using "unqualified" is uncommon these d= ays,=20 and not as clear. He also noted that the elementDefault=3D"qualified" does= not=20 introduce any problems at all; you just use a blank prefix in an instance=20 document. Looks better than today and functions perfectly. You can add=20 prefixes to really see where things belong. That SAML doesn't have it is=20 probably because it is an old design and the 2.0 people didn't want to chan= ge=20 this. 2=2E Remove use of schemaLocation in instance documents Anders noted that these are not found in PSKC or DS. ---------- assignedto: mpei messages: 84 nosy: andrea, keyprov, mpei priority: feature status: chatting title: Schema Refinement _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 18:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isnly-0002AQ-Co; Thu, 15 Nov 2007 18:05:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isnlv-00026U-N0 for keyprov@ietf.org; Thu, 15 Nov 2007 18:05:19 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isnlt-00029k-9d for keyprov@ietf.org; Thu, 15 Nov 2007 18:05:19 -0500 Received: (qmail 19496 invoked from network); 16 Nov 2007 00:05:15 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 16 Nov 2007 00:05:14 +0100 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, keyprov@ietf.org From: Andrea Doherty Date: Thu, 15 Nov 2007 22:42:36 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195166556.29.0.923097715411.issue36@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [KEYPROV] [issue36] App Review of HTTP definition X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : Changes recommended per BCP 56 was for there to be: 1=2E New port number defined for DSKPP since the usage is different from or= dinary=20 HTTP web browsing 2=2E Define a new URI scheme (DSKPP currently uses the HTTP/HTTPS scheme, w= hich=20 does not appear to be inline with BCP 56). Should these recommendations be adopted? ---------- assignedto: hannes messages: 85 nosy: andrea, hannes, keyprov priority: critical status: chatting title: App Review of HTTP definition _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 15 18:40:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoK0-0004cN-51; Thu, 15 Nov 2007 18:40:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoJy-0004ak-Kp for keyprov@ietf.org; Thu, 15 Nov 2007 18:40:30 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsoJy-0006HB-1U for keyprov@ietf.org; Thu, 15 Nov 2007 18:40:30 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAFNeTbK026900 for ; Thu, 15 Nov 2007 18:40:29 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Thu, 15 Nov 2007 18:40:29 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAFNeH4V013401 for ; Thu, 15 Nov 2007 18:40:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C827DF.5AA76DF1" Date: Thu, 15 Nov 2007 18:29:22 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D36AFB8@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Summary of discussion Thread-Index: Acgm9+G3CEqeFW8VQw6QwTfnnzcadQA5OczQ From: "Doherty, Andrea" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Subject: [KEYPROV] Summary of discussion X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C827DF.5AA76DF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mingliang Pei, Salah Machani, and I met via phone to discuss open issues. Our plan is to continue on Tuesday Nov 20 at 1PM ET (if interested in participating, please let me know and I'll forward call-in info). In summary, we discussed the issues in the attached spreadsheet (this is a roll-up of what is in the Issue Tracker). In particular, we focused on DSKPP and agreed that Issue #8, #10, #11, #14 were closed. We also discussed the AuthenticationData element, particularly the format of the Authentication Code. A new issue (#34) was added to the tracker. Not listed specifically is the issue of Client Authentication. Not only the format of the Authentication Code, but how is it utilized, and protected. For example, the draft includes mention of signature-based authentication data and HMAC(AuthCode), but not plaintext. There is a proposal on the one hand to remove the signature form, and a proposal on the other hand to keep the signature form and add a plaintext form. To resolve the issue, the point was raised that Section 5.3 does not adequately describe the use case for "Client Authentication" nor for "User Authentication", nor even for these relative to each and to "Device Authentication". Taking a step back, then, Ming agreed to take a stab at enhancing the section to better describe the use case. Andrea P.S. Note that Issues #32-#36 in the Issue Tracker are new. Inputs for these came directly out of exchanges on the mailing list, and are important to consider for resubmission of the document. <>=20 ------_=_NextPart_001_01C827DF.5AA76DF1 Content-Type: application/vnd.ms-excel; name="Issues Nov15 2007.xls" Content-Transfer-Encoding: base64 Content-Description: Issues Nov15 2007.xls Content-Disposition: attachment; filename="Issues Nov15 2007.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKQAAAAAAAAAA EAAAKwAAAAEAAAD+////AAAAACoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFANIfzQfJwAAABgMAAOEAAgCwBMEAAgAAAOIAAABcAHAACAAAYWRvaGVydHkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQIA AQCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIA4AF4AF0b2Bg4AAAAAAAB AFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAABMQAaAMgAAAD/f5ABAAAAAAB/ BQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAB/BQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAA AAB/BQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAB/BQFBAHIAaQBhAGwAMQAaAKAAAAD/f5AB AAAAAAB/BQFBAHIAaQBhAGwAMQAaAMgAAAA/AJABAAAAAgB/BQFBAHIAaQBhAGwAMQAaANwAAQAJ ALwCAAAAAgB/BQFBAHIAaQBhAGwAMQAaAMgABAAMAJABAAABAAB/BQFBAHIAaQBhAGwAMQAaAMgA BAAkAJABAAABAAB/BQFBAHIAaQBhAGwAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCke BCEABgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAuMDBf KTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMjMC4w MFwpHgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7XygiJCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7 XyhAXykeBC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJfKTtfKEBfKR4E PwAsADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/ Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBfKTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/ P18pO18oQF8pHgQVAKQAEAAAIlllcyI7IlllcyI7Ik5vIh4EGgClABUAACJUcnVlIjsiVHJ1ZSI7 IkZhbHNlIh4EFACmAA8AACJPbiI7Ik9uIjsiT2ZmIh4EXQCnACwAAVsAJACsIC0AMgBdAFwAIAAj ACwAIwAjADAALgAwADAAXwApADsAWwBSAGUAZABdAFwAKABbACQArCAtADIAXQBcACAAIwAsACMA IwAwAC4AMAAwAFwAKQDgABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAA AAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQA AgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA 9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAA APX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAA AAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAAEAIAAAAAAAAAAAAAAAwCDg ABQAAQArAPX/IAAA+AAAAAAAAAAAwCDgABQAAQApAPX/IAAA+AAAAAAAAAAAwCDgABQAAQAsAPX/ IAAA+AAAAAAAAAAAwCDgABQAAQAqAPX/IAAA+AAAAAAAAAAAwCDgABQACQAAAPT/AAAA9AAAAAAA AAAAwCDgABQACAAAAPT/AAAA9AAAAAAAAAAAwCDgABQAAQAJAPX/IAAA+AAAAAAAAAAAwCDgABQA AAAAAAEAIgAAEAAAAAAAAAAAwCDgABQAAAAAAAEAKAAAEAAAAAAAAAAAwCDgABQAAAAAAAEAIgAA cBURQCBAIAAEKyDgABQAAAAAAAEAKAAAcBERQCBAIAAEKyDgABQAAAAAAAEAKAAAcFERQCBAIAAE KyDgABQAAAAAAAEAIgAAcBURQCBAIAAECSDgABQAAAAAAAEAKAAAcBERQCBAIAAECSDgABQAAAAA AAEAKAAAcFERQCBAIAAECSDgABQABwAAAAEAIgAAeBVVQCBAIAAEICDgABQABwAAAAEAIgAAeBFV QCBAIAAEICDgABQABwAAAAEAKgAAeBFVQCBAIAAEICDgABQABwAAAAEAKgAAeFFVQCBAIAAEICDg ABQAAAAAAAEAIgAAcBUQQCAAIAAEnw/gABQAAAAAAAkAKAAAcBEQQCAAIAAEnw/gABQAAAAAAAEA KAAAcFEQQCAAIAAEnw/gABQAAAAAAAEAIgAAcBURQCBAIAAEnw/gABQAAAAAAAEAKAAAcBERQCBA IAAEnw/gABQAAAAAAAEAKAAAcFERQCBAIAAEnw/gABQABgAAAAEAKAAAeBERQCBAIAAEnw/gABQA AAAAAAEAIgAAcBUBQCBAAAAEnw/gABQAAAAAAAEAKAAAcFEBQCBAAAAEnw/gABQAAAAAAAEAIgAA cBURQCBAIAAEHyDgABQAAAAAAAEAKAAAcBERQCBAIAAEHyDgABQAAAAAAAEAKAAAcFERQCBAIAAE HyDgABQAAAAAAAEAIgAAcBUBQCBAAAAEKyDgABQAAAAAAAEAIgAAcBURQCBAIAAEiQ/gABQAAAAA AAEAKAAAcBEBQCBAAAAEKyDgABQAAAAAAAEAKAAAcBERQCBAIAAEiQ/gABQAAAAAAAkAKAAAcBER QCBAIAAEiQ/gABQAAAAAAAEAKAAAcFEBQCBAAAAEKyDgABQAAAAAAAEAKAAAcBEBQCBAAAAEnw/g ABQAAAAAAAEAIgAAcBUQQCAAIAAECSDgABQAAAAAAAEAKAAAcBEQQCAAIAAECSDgABQAAAAAAAEA KAAAcFEQQCAAIAAECSDgABQAAAAAAAEAIgAAcBVRQCBAIAAEHyDgABQAAAAAAAEAKAAAcBFRQCBA IAAEHyDgABQAAAAAAAEAKAAAcFFRQCBAIAAEHyDgABQAAAAAAAEAIgAAcBUQQCAAIAAEKyDgABQA AAAAAAEAKAAAcBEQQCAAIAAEKyDgABQAAAAAAAkAKgAAcBEQQCAAIAAEnw/gABQAAAAAAAEAKgAA cBERQCBAIAAECSDgABQAAAAAAAEAKgAAcBERQCBAIAAEKyDgABQAAAAAAAkAKgAAcBERQCBAIAAE nw/gABQAAAAAAAkAKgAAcBERQCBAIAAEHyDgABQAAAAAAAEAKgAAcBEQQCAAIAAECSDgABQAAAAA AAEAKgAAcBERQCBAIAAEiQ/gABQAAAAAAAEAKgAAcBEQQCAAIAAEKyDgABQAAAAAAAEAKgAAcBEB QCBAAAAEKyDgABQAAAAAAAkAKgAAcBEBQCBAAAAEnw/gABQAAAAAAAkAKgAAcBFRQCBAIAAEHyDg ABQAAAAAAAEAKgAAEAAAAAAAAAAAwCDgABQAAAAAAAkAIgAAcBEQQCAAIAAEnw/gABQAAAAAAAEA KgAAcBERQCBAIAAEnw/gABQAAAAAAAEAKgAAcBERQCBAIAAEHyDgABQAAAAAAAEAIgAAcBERQCBA IAAEiQ/gABQAAAAAAAEAKgAAcBEBQCBAAAAEnw/gABQAAAAAAAEAKgAAcBFRQCBAIAAEHyDgABQA AAAAAAEAIgAAcBERQCBAIAAECSDgABQAAAAAAAEAIgAAcBERQCBAIAAEKyDgABQAAAAAAAEAIgAA cBERQCBAIAAEnw/gABQAAAAAAAEAIgAAcBERQCBAIAAEHyDgABQAAAAAAAEAIgAAcBEQQCAAIAAE CSDgABQAAAAAAAkAIgAAcBERQCBAIAAEiQ/gABQAAAAAAAEAIgAAcBEQQCAAIAAEKyDgABQAAAAA AAEAIgAAcBEBQCBAAAAEKyDgABQAAAAAAAEAIgAAcBEBQCBAAAAEnw/gABQAAAAAAAEAIgAAcBFR QCBAIAAEHyDgABQAAAAAAAkAIgAAcBERQCBAIAAEnw/gABQAAAAAAAEAKAAAcFEQQCAAIAAEiQ+T AgQAEIAD/5MCBAARgAb/kwIEABKABP+TAgQAE4AH/5MCBAAUgAn/kwIEABWACP+TAgQAAIAA/5MC BAAWgAX/YAECAAAAhQAOAGkYAAAAAAYASXNzdWVzjAAEAAEAAQCuAQQAAQABBBcACAABAAAAAAAA ABgAGwAgAAABCwAAAAEAAAAAAAAHOwAAAAAAAAAA/wDBAQgAwQEAACK+AQD8AHkKyAAAAD8AAAAC AABJRAYAAFN0YXR1cwgAAFByaW9yaXR5BQAAT3duZXIFAABUaXRsZQQAAEl0ZW0FAABEU0tQUAcA AEZlYXR1cmUGAABDbG9zZWRDAABDaGFuZ2UgZWxlbWVudCBuYW1lcyB0byByZWZsZWN0IEtFWVBS T1YgYW5kIHJlcXVlc3QvcmVzcG9uc2Ugc3R5bGUuNQAAU2hvdWxkIFRva2VuSUQgYW5kIEtleUlE IGJlIHN0cmluZyBpbnN0ZWFkIG9mIGJpbmFyeT8JAABBbGlnbm1lbnRCAABEaWZmZXJlbnQgYXBw cm9hY2hlcyB1c2VkIHRvIHJlZmVyIHRvIGFsZ29yaXRobXMgaW4gRFNLUFAgYW5kIFBTS0NVAABS ZWZlciB0byBFbmNyeXB0aW9uIEFsZ29yaXRobSBmcm9tIENsaWVudEhlbGxvIGZvciB0aGUgU3Vw cG9ydGVkRW5jcnlwdGlvbkFsZ29yaXRobXM/CAAAQ3JpdGljYWwEAABXaXNoQgAAU2hhbGwgd2Ug c3VwcG9ydCBhbiBvcHRpb24gZm9yIG90aGVyIHJlc3BvbnNlIGNoYW5uZWwgc3VjaCBhcyBTTVM/ MAAASG93IHRvIHJlZmVyIHRvIEhPVFAgYW5kIFNlY3VySUQgT1RQIGFsZ29yaXRobXM/GAAAQ29t bWVudCAoYXMgb2YgMTEvMTMvMDcpbQAARG9jdW1lbnQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVu IFN1cHBvcnRlZEtleUludGlhbGl6YXRpb25NZXRob2QgYW5kIEVuY3J5cHRpb25NZXRob2QgaW4g YSByZXNwb25zZSBtZXNzYWdlLgQAAE9wZW4LAABJbi1wcm9ncmVzczMAAERvIHdlIG5lZWQgdG8g cHJvdmlkZSBTT0FQIGJpbmRpbmcgYW5kIHdoZXJlIGlmIHNvPzMAAElzIHNwZWNpYWwga2V5cHJv diBIVFRQIGhlYWRlciBkZWZpbml0aW9uIHJlcXVpcmVkPwMAAC0tLUEAAFNob3VsZCB3ZSB1c2Ug c3Ryb25nbHkgdHlwZWQgbWVzc2FnZSBvciBhbnkgdHlwZSBmb3IgZmxleGliaWxpdHk/UAAAU2hh bGwgd2UgZXhwbGljaXRseSBkb2N1bWVudCBob3cgdG8gY29uc3RydWN0IEF1dGhlbnRpY2F0aW9u Q29kZSBvdmVyIEhUVFAgY2FzZT9hAABTaGFsbCB3ZSBhdXRoZW50aWNhdGlvbiBJRCBpbiBhIHNl cGFyYXRlIGZpZWxkIG9yIHRoZSBzYW1lIHZhbHVlIGluIHBhcnQgb2YgYXV0aGVudGljYXRpb24g dmFsdWU/BAAAUFNLQycAAEFkZCBzdXBwb3J0IG9mIG5vbi1IT1RQIE9UUCBhbGdvcml0aG1zPxgA AENoYW5nZSBTdGF0dXMgdG8gQ2xvc2VkPzEAAENsYXJpZnkgaG93IHRvIGluZGljYXRlIEhPVFAg dGltZS1iYXNlZCBhbGdvcml0aG03AABTaGFsbCB3ZSB1c2Ugc3Ryb25nIHR5cGVkIGFsZ29yaXRo bSBjb25maWd1cmF0aW9uIGRhdGE/XQAAQ2xhcmlmeSB0aGUga2V5IGdlbmVyYXRpb24gZm9yIEhN QUMgdmFsdWUgb2YgYSBzZWNyZXQgZGF0YSB3aGVuIGEgUEJFIGlzIHVzZWQgZm9yIGVuY3J5cHRp b24uDAAAUGhpbGlwIEhveWVyDgAAQW5kcmVhIERvaGVydHkNAABNaW5nbGlhbmcgUGVpXwAARGVm aW5lIGNvbW1vbmx5IHVzZWQgZGF0YSB0eXBlIGZvciBrZXlwcm92IGluIGEgY29tbW9uIHNjaGVt YSBmaWxlIGZvciBEU0tQUCBhbmQgUFNLQyB0byBzaGFyZS4PAABTdGlsbCByZXF1aXJlZD9VAABU aGlzIGl0ZW0gaXMgbm8gbG9uZ2VyIHZpc2libGUgaW4gdGhlIElzc3VlciBUcmFja2VyIGxpc3Qs IGFzIGl0IHdhcyBtYXJrZWQgUmVzb2x2ZWQuMAAAQ2hhbmdlIHR5cGUgbmFtZSBEaWdlc3RBbGdv cml0aG0gdG8gTUFDQWxnb3JpdGhtXwAAU2hhbGwgd2UgZXhwbGljaXRseSBhZGQgYW4gYXR0cmli dXRlIGluIERhdGFUeXBlIHRvIGluZGljYXRlIHdoZXRoZXIgYW4gYXR0cmlidXRlIGlzIGVuY3J5 cHRlZD9DAABTaGFsbCB3ZSB1c2Ugd29yZCAiS2V5IiBpbiBYTUwgdHlwZSBuYW1lcyB0byByZXBs YWNlIHdvcmQgIlNlY3JldCI/MQAASW50ZXJhY3Rpb24gYmV0d2VlbiBEU0tQUCBhbmQgVXNlciBB dXRoZW50aWNhdGlvbjsAAFJlZ2lzdGVyIFBTS0MgY29udGFpbmVyIFVSSSBhbmQgcmVmZXIgdG8g dGhpcyBpbiBEU0tQUCBzcGVjEgAAS19NQUMgaW4gRm91ci1QYXNzMQAASG93IHRvIHRyYW5zZmVy IGluaXRpYWwgUElOIHRvIGEgY2xpZW50IHZpYSBQU0tDPzUAAFNob3VsZCBTZXJpYWxObyBiZSBk ZWZpbmVkIGFzIGJhc2U2NEJpbmFyeSBvciBzdHJpbmc/IwAAQWxsb3cgbW9yZSBjb21wbGV4IFBJ TiB1c2FnZSBwb2xpY3lWAABDb25zaXN0ZW50IGRlZmluaXRpb24gYWJvdXQgSURzIGJldHdlZW4g S2V5cHJvdiBhbmQgUFNLQzogVG9rZW5JRCwgRGV2aWNlSUQsIGFuZCBLZXlJRCsAAFN5bmMgT1RQ QWxnb3JpdGhtSWRlbnRpZmllclR5cGUgd2l0aCBzY2hlbWFCAABDb25zaWRlciB0byBhZGQgb2Jq ZWN0IGRpYWdyYW0gaW4gRFNLUFAgZm9yIHJlbGF0aW9uc2hpcHMgYW1vbmdJRHM4AABXb3JrIG9u IGNsYXJpZmljYXRpb25zIGFuZCB1cGRhdGVzIGZvciBjb21tZW50cyByZWNlaXZlZDIAAERlZmlu ZSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudHMgZm9yIGNvbmZvcm1hbmNlLgAARXJyb3Igb2Nj dXJyZWQgZHVyaW5nIGVudHJ5OyAzMSBkb2VzIG5vdCBleGlzdFUAAEFyZSB1c2UgY2FzZXMgaW52 b2x2aW5nIG5vbi1hdXRoZW50aWNhdGVkIGFuZCBub24tcHJvdGVjdGVkIHRyYW5zcG9ydCBsYXll ciByZXF1aXJlZD8oAABDaGFuZ2UgU3RhdHVzIHRvIENsb3NlZCBpbiBJc3N1ZSBUcmFja2VyAwAA TmV3AQAAPxkAAEF1dGhlbnRpY2F0aW9uQ29kZSBGb3JtYXQRAABIYW5uZXMgVHNjaG9mZW5pZx0A AEFwcCBSZXZpZXcgb2YgSFRUUCBEZWZpbml0aW9uEQAAU2NoZW1hIFJlZmluZW1lbnT/AEIACACV DQAADAAAANcNAABOAAAAGQ8AAJABAACdEAAAFAMAAB4SAACVBAAAtBMAACsGAACCFQAA+QcAAG0X AADkCQAAYwgVAGMIAAAAAAAAAAAAABUAAAAAAAAATgoAAAAJCBAAAAYQANIfzQfJwAAABgMAAAsC GAAAAAAAAAAAACYAAAAIGwAAMyoAAN0sAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx 0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDBBBQA IwAgAAAmQyYiQXJpYWwsQm9sZCImMTJLRVlQUk9WIElzc3VlcxUAJgAjAAAmTEFuZHJlYSBEb2hl cnR5JkNQYWdlICZQIG9mICZOJlImRIMAAgAAAIQAAgAAAE0AkgEAAFwAXAByAHMAYQBuAGEALQBw AHMALQBoAHEAMQBcAEgAUQAtAEMAUwA0AEwAYQBzAGUAcgAAAAAAAAAAAAAAAAABBAAE3AC0ABNX AQACAAEA6gpvCGQAAQAPAFgCAQABAAAAAwAAAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4BAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAlyMUAAACAAACBAMBAAAA/wAAAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChACIAAQBkAAEAAQABAAAA WAIAAAAAAAAAAOA/AAAAAAAA4D8BAFUAAgAIAH0ADAAAAAAAJAYXAAIAAAB9AAwAAQABAAAKFwAC AAAAfQAMAAIAAgBtChcAAgAAAH0ADAADAAMAAApJAAIAAAB9AAwABAAEANsJSQACAAAAfQAMAAUA BQAAJxgAAgAAAH0ADAAGAAYA2yUYAAIAAACQABsABAAEBggASXRlbQBTdGF0dXMAUHJpb3JpdHkA dAgcAHQIAAAAAAAAAAAAAAcADAALAAoACQAIAAcABgAAAg4AAAAAACYAAAAAAAcAAAAIAhAAAAAA AAcAHAIAAAAAQAEPMAgCEAABAAAABwANAgAAAAAAAQ8QCAIQAAIAAAAHAIQDAAAAAEABDwAIAhAA AwAAAAcAKgMAAAAAQAEPAAgCEAAEAAAABwCEAwAAAABAAQ8ACAIQAAUAAAAHAKMCAAAAAEABDwAI AhAABgAAAAcASAMAAAAAQAEPAAgCEAAHAAAABwBnAgAAAABAAQ8ACAIQAAgAAAAHANACAAAAAEAB DwAIAhAACQAAAAcA/QIAAAAAQAEPAAgCEAAKAAAABwCTAwAAAABAAQ8ACAIQAAsAAAAHAJMDAAAA AEABDwAIAhAADAAAAAcAkwMAAAAAQAEPAAgCEAANAAAABwCTAwAAAABAAQ8ACAIQAA4AAAAHACoD AAAAAEABDwAIAhAADwAAAAcA/QIAAAAAQAEPAAgCEAAQAAAABwAqAwAAAABAAQ8ACAIQABEAAAAH AO4CAAAAAEABDwAIAhAAEgAAAAcA3wIAAAAAQAEPAAgCEAATAAAABwB2AgAAAABAAQ8ACAIQABQA AAAHAJQCAAAAAEABDwAIAhAAFQAAAAcAlAIAAAAAQAEPAAgCEAAWAAAABwB2AgAAAABAAQ8ACAIQ ABcAAAAHALICAAAAAEABDwAIAhAAGAAAAAcA3wIAAAAAQAEPAAgCEAAZAAAABwDQAgAAAABAAQ8A CAIQABoAAAAHALICAAAAAEABDwAIAhAAGwAAAAcAhQIAAAAAQAEPAAgCEAAcAAAABwCFAgAAAABA AQ8ACAIQAB0AAAAHAHYCAAAAAEABDwAIAhAAHgAAAAcAdgIAAAAAQAEPAAgCEAAfAAAABwB2AgAA AABAAQ8A/QAKAAAAAAAfAAAAAAD9AAoAAAABACAABQAAAP0ACgAAAAIAIAACAAAA/QAKAAAAAwAh AAEAAAD9AAoAAAAEACEAAwAAAP0ACgAAAAUAIQAEAAAA/QAKAAAABgAiABIAAAB+AgoAAQAAACMA AAA/QP0ACgABAAEASgAYAAAA/QAKAAEAAgBKABgAAAD9AAoAAQADAEoAGAAAAP0ACgABAAQAPgAY AAAA/QAKAAEABQAkABgAAAD9AAoAAQAGACUANgAAAH4CCgACAAAAHAAAACJA/QAKAAIAAQBQAAsA AAD9AAoAAgACAFAABwAAAP0ACgACAAMAPwAUAAAA/QAKAAIABAA/ACMAAAD9AAoAAgAFAB0AEwAA AAECBgACAAYAHgB+AgoAAwAAABwAAAA+QP0ACgADAAEAUAALAAAA/QAKAAMAAgBQAA4AAAD9AAoA AwADAD8AFQAAAP0ACgADAAQAPwAkAAAA/QAKAAMABQAdAC8AAAABAgYAAwAGAB4AfgIKAAQAAAAZ AAAANED9AAoABAABAFEACwAAAP0ACgAEAAIAUQAHAAAA/QAKAAQAAwBAABUAAAD9AAoABAAEAEAA IgAAAP0ACgAEAAUAGgAlAAAA/QAKAAQABgAbACYAAAB+AgoABQAAACYAAAAYQP0ACgAFAAEAUgAL AAAA/QAKAAUAAgBaABgAAAD9AAoABQADAEsACAAAAP0ACgAFAAQAQQAYAAAA/QAKAAUABQAnAA0A AAABAgYABQAGACgAfgIKAAYAAAAmAAAACED9AAoABgABAFIACwAAAP0ACgAGAAIAUgAOAAAA/QAK AAYAAwBLAAgAAAD9AAoABgAEAEEAGAAAAP0ACgAGAAUAKQAxAAAA/QAKAAYABgAoACcAAAB+AgoA BwAAACwAAAAgQP0ACgAHAAEAUwALAAAA/QAKAAcAAgBTAA4AAAD9AAoABwADAEwACAAAAP0ACgAH AAQAQgAYAAAA/QAKAAcABQAtABEAAAABAgYABwAGAC4AfgIKAAgAAAAsAAAAN0D9AAoACAABAFMA CwAAAP0ACgAIAAIAUwAOAAAA/QAKAAgAAwBMAAgAAAD9AAoACAAEAEIAGAAAAP0ACgAIAAUALQAq AAAAAQIGAAgABgAuAH4CCgAJAAAAJgAAABRA/QAKAAkAAQBSAAsAAAD9AAoACQACAFIADwAAAP0A CgAJAAMASwAIAAAA/QAKAAkABABBABgAAAD9AAoACQAFACcADAAAAAECBgAJAAYAKAB+AgoACgAA ADYAAIBAQP0ACgAKAAEAVAAGAAAA/QAKAAoAAgBUADoAAAD9AAoACgADAEQAOQAAAP0ACgAKAAQA QwAjAAAA/QAKAAoABQA3ADcAAAABAgYACgAGADgAfgIKAAsAAAAwAAAAQED9AAoACwABAE0ABgAA AP0ACgALAAIAVQAOAAAA/QAKAAsAAwBNADkAAAD9AAoACwAEAEQAIwAAAP0ACgALAAUAMwA1AAAA AQIGAAsABgA4AH4CCgAMAAAAMAAAAEFA/QAKAAwAAQBNAAYAAAD9AAoADAACAFUADgAAAP0ACgAM AAMATQA5AAAA/QAKAAwABABEACQAAAD9AAoADAAFADIAOwAAAAECBgAMAAYAOAB+AgoADQAAADAA AABCQP0ACgANAAEATQAGAAAA/QAKAA0AAgBVAA4AAAD9AAoADQADAE0AOQAAAP0ACgANAAQARAA8 AAAA/QAKAA0ABQAyAD0AAAABAgYADQAGAFsAfgIKAA4AAAAwAACAQUD9AAoADgABAE0ABgAAAP0A CgAOAAIATQAHAAAA/QAKAA4AAwBNADkAAAD9AAoADgAEAEQAJAAAAP0ACgAOAAUAMgA+AAAAAQIG AA4ABgAeAH4CCgAPAAAALAAAACZA/QAKAA8AAQBTAAYAAAD9AAoADwACAFMABwAAAP0ACgAPAAMA TAAVAAAA/QAKAA8ABABBABgAAAD9AAoADwAFAC0AFwAAAAECBgAPAAYALgB+AgoAEAAAACwAAAAs QP0ACgAQAAEAUwAGAAAA/QAKABAAAgBTAA4AAAD9AAoAEAADAEwACAAAAP0ACgAQAAQAQQAYAAAA /QAKABAABQAtABsAAAABAgYAEAAGAC4AfgIKABEAAAAsAAAAOkD9AAoAEQABAFMABgAAAP0ACgAR AAIAUwAOAAAA/QAKABEAAwBMAAgAAAD9AAoAEQAEAEEAGAAAAP0ACgARAAUALQArAAAA/QAKABEA BgAuADgAAAB+AgoAEgAAACYAAAAAQP0ACgASAAEAUgAGAAAA/QAKABIAAgBSAA4AAAD9AAoAEgAD AEsACAAAAP0ACgASAAQAQQAYAAAA/QAKABIABQAnACwAAAD9AAoAEgAGACgAJwAAAH4CCgATAAAA JgAAABBA/QAKABMAAQBSAAYAAAD9AAoAEwACAFIADgAAAP0ACgATAAMASwAIAAAA/QAKABMABABB ABgAAAD9AAoAEwAFACcACgAAAAECBgATAAYAKAB+AgoAFAAAACYAAAAoQP0ACgAUAAEAUgAGAAAA /QAKABQAAgBSAA4AAAD9AAoAFAADAEsACAAAAP0ACgAUAAQAQQAYAAAA/QAKABQABQAnABkAAAAB AgYAFAAGACgAfgIKABUAAAAmAAAAKkD9AAoAFQABAFIABgAAAP0ACgAVAAIAUgAOAAAA/QAKABUA AwBLAAgAAAD9AAoAFQAEAEEAGAAAAP0ACgAVAAUAJwAaAAAAAQIGABUABgAoAH4CCgAWAAAALAAA ADtA/QAKABYAAQBTAAYAAAD9AAoAFgACAFMADgAAAP0ACgAWAAMATAAIAAAA/QAKABYABABCABgA AAD9AAoAFgAFAC0ALQAAAAECBgAWAAYALgB+AgoAFwAAACYAAADwP/0ACgAXAAEAUgAGAAAA/QAK ABcAAgBSAAcAAAD9AAoAFwADAEsACAAAAP0ACgAXAAQAQQAYAAAA/QAKABcABQAnAAkAAAABAgYA FwAGACgAfgIKABgAAAAmAAAAHED9AAoAGAABAFIABgAAAP0ACgAYAAIAUgAHAAAA/QAKABgAAwBL AAgAAAD9AAoAGAAEAEEAGAAAAP0ACgAYAAUAJwAQAAAAAQIGABgABgAoAH4CCgAZAAAALAAAACRA /QAKABkAAQBTAAYAAAD9AAoAGQACAFMABwAAAP0ACgAZAAMATAAIAAAA/QAKABkABABCABgAAAD9 AAoAGQAFAC0AFgAAAAECBgAZAAYALgB+AgoAGgAAACwAAAA1QP0ACgAaAAEAUwAGAAAA/QAKABoA AgBTAAcAAAD9AAoAGgADAEwACAAAAP0ACgAaAAQAQgAYAAAA/QAKABoABQAtADMAAAD9AAoAGgAG AC4AJwAAAH4CCgAbAAAAPAAAAC5A/QAKABsAAQBWABwAAAD9AAoAGwACAFYADgAAAP0ACgAbAAMA RQAVAAAA/QAKABsABABFACQAAAD9AAoAGwAFAD0AHQAAAP0ACgAbAAYAGwAeAAAAfgIKABwAAAAZ AAAAOED9AAoAHAABAFEAHAAAAP0ACgAcAAIAUQAOAAAA/QAKABwAAwBAABUAAAD9AAoAHAAEAEAA JAAAAP0ACgAcAAUAGgAoAAAA/QAKABwABgAbAB4AAAB+AgoAHQAAABwAAAA8QP0ACgAdAAEAUAAc AAAA/QAKAB0AAgBQAA4AAAD9AAoAHQADAD8AFQAAAP0ACgAdAAQAPwAkAAAA/QAKAB0ABQAdAC4A AAABAgYAHQAGAB4AfgIKAB4AAAAcAAAAPUD9AAoAHgABAFAAHAAAAP0ACgAeAAIAUAAOAAAA/QAK AB4AAwA/ABUAAAD9AAoAHgAEAD8AJAAAAP0ACgAeAAUAHQAwAAAAAQIGAB4ABgAeAH4CCgAfAAAA HAAAADBA/QAKAB8AAQBQABwAAAD9AAoAHwACAFAABwAAAP0ACgAfAAMAPwAVAAAA/QAKAB8ABAA/ ACQAAAD9AAoAHwAFAB0AHwAAAAECBgAfAAYAHgDXAEQAZA4AAGwCYgBiAF4AXgBiAF4AYgBeAF4A XgBeAF4AXgBeAF4AXgBeAGIAYgBeAF4AXgBeAF4AXgBeAGIAYgBiAF4AXgAIAhAAIAAAAAcAdgIA AAAAQAEPAAgCEAAhAAAABwAqAwAAAABAAQ8ACAIQACIAAAAHACoDAAAAAEABDwAIAhAAIwAAAAcA lAIAAAAAQAEPAAgCEAAkAAAABwCjAgAAAABAAQ8gCAIQACUAAAAHAA4BAAAAAAABDxB+AgoAIAAA ABkAAAAxQP0ACgAgAAEAUQAcAAAA/QAKACAAAgBRAAcAAAD9AAoAIAADAEAAFQAAAP0ACgAgAAQA QAAkAAAA/QAKACAABQAaACAAAAD9AAoAIAAGABsAHgAAAH4CCgAhAAAALwAAADNA/QAKACEAAQBX ABwAAAD9AAoAIQACAFcABwAAAP0ACgAhAAMARgAVAAAA/QAKACEABABGACQAAAD9AAoAIQAFADEA IQAAAP0ACgAhAAYANAAeAAAAfgIKACIAAAAvAAAAOUD9AAoAIgABAFcAHAAAAP0ACgAiAAIAVwAP AAAA/QAKACIAAwBGABUAAAD9AAoAIgAEAEYAJAAAAP0ACgAiAAUAMQApAAAA/QAKACIABgA0AB4A AAB+AgoAIwAAACoAAAAyQP0ACgAjAAEAWAAcAAAA/QAKACMAAgBYAA4AAAD9AAoAIwADAE4ACAAA AP0ACgAjAAQARwAYAAAA/QAKACMABQA1ADIAAAD9AAoAIwAGACsAJwAAAH4CCgAkAAAAOQAAADZA /QAKACQAAQBZABwAAAD9AAoAJAACAFkADgAAAP0ACgAkAAMATwAIAAAA/QAKACQABABIABgAAAD9 AAoAJAAFADoANAAAAP0ACgAkAAYAOwAnAAAA1wAQAGICAABkAGIAYgBiAGIAYgA+AhIAvgcAAAAA QAAAAAAAAAAAAAAAQQAKAAAAAQABAEAAAgAdAA8AAwAAAAAAAAEAAAAAAAAAHQAPAAIJAAUAAAAB AAkACQAFBe8ABgAFADcAAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAvAAAAAgAAAABAAAASAAAAAQAAABQAAAACAAAAGQAAAAS AAAAeAAAAAsAAACQAAAADAAAAJwAAAANAAAAqAAAABMAAAC0AAAAAgAAAOQEAAAeAAAADAAAAGFk b2hlcnR5AAAAAB4AAAAMAAAAYWRvaGVydHkAAAAAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAA AICGtUUsJsgBQAAAAICK61kQJsgBQAAAAICHCZTcJ8gBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3V nC4bEJOXCAArLPmuMAAAAAQBAAAJAAAAAQAAAFAAAAAPAAAAWAAAABcAAABwAAAACwAAAHgAAAAQ AAAAgAAAABMAAACIAAAAFgAAAJAAAAANAAAAmAAAAAwAAADDAAAAAgAAAOQEAAAeAAAAEAAAAEVN QyBDb3Jwb3JhdGlvbgADAAAAxB8LAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAA AAIAAAAHAAAASXNzdWVzABQAAABJc3N1ZXMhUHJpbnRfVGl0bGVzAAwQAAAEAAAAHgAAAAsAAABX b3Jrc2hlZXRzAAMAAAABAAAAHgAAAA0AAABOYW1lZCBSYW5nZXMAAwAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZ AAAAGgAAABsAAAAcAAAAHQAAAB4AAAD+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAAP7/ ///9/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAA AAAAAAAAAAAAAICrZGndJ8gB/v///wAAAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASS0AAAAAAAAFAFMAdQBtAG0AYQBy AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEA AAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAAAAEAAAAAAA AAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA AAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAHwAAAAAQAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAA AAAAAAAAAAAAkA9YWt8nyAEsAAAAgAEAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJLQAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAA AAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAfAEAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZAAAA GgAAABsAAAAcAAAAHQAAAB4AAAD+//////////////////////////////////////////////// //////////7////9/////v////7///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////wEAAAACAAAAAwAAAAQAAAAFAAAA/v////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rkgBAAAEAQAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAAcAAAAAsA AAB4AAAAEAAAAIAAAAATAAAAiAAAABYAAACQAAAADQAAAJgAAAAMAAAAwwAAAAIAAADkBAAAHgAA ABAAAABFTUMgQ29ycG9yYXRpb24AAwAAAMQfCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAB4QAAACAAAABwAAAElzc3VlcwAUAAAASXNzdWVzIVByaW50X1RpdGxlcwAMEAAABAAAAB4A AAALAAAAV29ya3NoZWV0cwADAAAAAQAAAB4AAAANAAAATmFtZWQgUmFuZ2VzAAMAAAABAAAAADQA AAADAAAAAAAAACAAAAABAAAAJAAAAAAAAIAsAAAAAAAAAAIAAACwBAAAEwAAAAkEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA= ------_=_NextPart_001_01C827DF.5AA76DF1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C827DF.5AA76DF1-- From keyprov-bounces@ietf.org Fri Nov 16 11:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3z3-000210-MC; Fri, 16 Nov 2007 11:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It39S-0007AN-O5; Fri, 16 Nov 2007 10:30:39 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It39P-0003cZ-Np; Fri, 16 Nov 2007 10:30:38 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 824574F159; Fri, 16 Nov 2007 10:30:34 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It39N-0001bS-Vh; Fri, 16 Nov 2007 16:30:33 +0100 Date: Fri, 16 Nov 2007 16:30:33 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net Message-ID: <20071116153033.GF28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-Mailman-Approved-At: Fri, 16 Nov 2007 11:23:53 -0500 Cc: keyprov@ietf.org, apps-review@ietf.org Subject: [KEYPROV] Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a review of draft-ietf-keyprov-dskpp-01. It occasionally strays into the PSKC draft; however, I haven't fully read that document. Specific observations on the HTTP binding: - In 12.2.4, the spec says "Persistent connections as defined in HTTP/1.1 are assumed, but not required." Taken literally, I don't know what "assumed, but not required" means. - The HTTP binding does not indicate whether it fully defines the behavior of the HTTP server that is appearing as part of the transactions, or whether the DSKPP server is identified by either a specific URI and/or Host. Please clarify that in the HTTP binding part. (4.3 -- and other places -- suggest that the DSKPP server is indeed identified by a specific URI, which would be just fine.) - In 12.2.4, instead of talking about "POST operations", maybe say "DSKPP requests are mapped to HTTP requests with the POST method". - For the 4-step protocol, it's probably worth calling out here how the different messages are bound together, as they may be transported through different connections. In particular, KeyProvServerHello is bound to the preceding KeyProvClientHello by being transmitted in the corresponding HTTP response; KeyProvServerHello MUST have a sessionId attribute, and the sesionId on the subsequent KeyProvClientNonce MUST be identical. KeyProServerFinished is then once again bound to the rest through HTTP (and possibly through a sessionID). - The HTTP binding does not cover content negotiation. I'd suggest: "HTTP requests MAY include an HTTP Accept header field. This header field SHOULD have the value application/vnd.ietf.keyprov.dskpp+xml. The Accept header MAY include additional content types defined by future versions of this protocol." (The server is allowed to downgrade [6.2.3], so if a future version uses a different content type, that should be in the client's request, along with the current one, *if* the client is willing to downgrade.) - The examples in 12.2.8 don't match the requirements from 12.2.3. - 12.2.7 is extremely fuzzy as to when the server-side initialization message may be sent. As long as that's indeed in response to a specific user request with the appropriate Accept header (e.g., to a specific DSKPP server URL), the use of the 200 code seems fine. However, please clarify that using a 200 code combined with the DSKPP content type is *not* an appropriate means to trigger protocol initialization during a browsing session where the user's request was directed to some other resource. (In that case, some 40x code might be much more appropriate.) - It's not clear how one-step DSKPP would work over HTTP. What kind of request does the client send to trigger that? If that isn't intended to run over HTTP, please clarify. - In 12.2.3, the spec says: "HTTP proxies MUST NOT cache responses carrying DSKPP messages. For this reason, the following holds:" That's a conformance requirement on HTTP proxies; don't do that. Instead: "In order to avoid caching of responses carrying DSKPP messages by proxies, the following holds:" (Also, note that POST invalidates cached entities.) - In 12.2.5, "If the type of a DSKPP request cannot be determined, the DSKPP responder MUST return a 400 response." What precisely is meant by "type cannot be determined"? (Example?) Reviewing BCP56, I would suspect that there might be slight differences of opinion on whether DSKPP should have a port and URI scheme of its own. However, given that the protocol binding (with the above clarifications) will be layered rather cleanly on HTTP, and won't confuse URI-based addressing, I fail to see the benefit of allocating a separate port and/or URI scheme. This binding looks like it is implementable on top of a conventional Web server, which would suggest sticking to port 80 and http (or port 443 and https). Beyond that point, I do not see any significant disagreements between the guidance in BCP56 and this draft. Various other observations while going through the document... - -00 included schema fragments in section 4.9. These are gone in the corresponding sections in -01, making review of the schema for consistency with the human-readable text significantly harder. I'd recommend resurrecting the schema fragements in future iterations of the draft for ease of review. While dropping the schema fragments, *any* human-readable documentation for types such as AbstractRequestType type has been lost. - Please say early on in the spec what name space prefixes are used in XML snippets throughout the document, and what they mean. - What's the order relation for the various Version attributes? Are they treated as decimal numbers, as strings, as a dot-separated pairs of two integers? Is "01.00" the same as "1.0"? - Trying to assemble the overall XML schema to validate some of the examples... * DSKPP imports the schema from PSKC, which in turn imports a schema for the urn:ietf:params:xml:ns:keyprov:logo namespace, which apparently isn't available anywhere. * The DSKPP and PSKC drafts use inconsistent namespaces for PSKC, urn:ietf:params:xml:ns:keyprov:container vs urn:ietf:params:xml:ns:keyprov:1.0:container * The DSKPP schema uses an extension construct like this one repeatedly (DeviceIdentifierDataType, KeyContainerType, PayloadType, KeyProvTriggerType): In conjunction with use of elementFormDefault="unqualified", that unfortunately leads to a non-deterministic content model, as DeviceId is not actually in the target namespace. One possible fix is to move away from elementFormDefault="unqualified". (PSKC uses "qualified" anyway.) - StatusCode is one out of a closed list of strings. For extensibility, it might be worth using URIs/URNs instead of text strings here, and defining StatusCode to be of type anyURI. - Same for PlatformType. - ProtocolVariantsType uses elements to identify supported protocol variants. I wonder if having an extension point in the schema for future variants might be useful. Also, why not use an URI-based extensibility pattern? - In 11.3.3, ds:KeyInfoType is used for Payloads, and "only those choices of the ds:KeyInfoType that identify a symmetric key are allowed". Does a ds:RetrievalMethod that points to a ds:KeyName elsewhere possibly identify a symmetric key? Please be clearer about which parts of ds:KeyInfo you use here. - Same in 11.2.3 for public keys. - IdentifierType is limited to a maximum 128 characters in the schema, yet that limitation is nowhere found in the normative text. - PSKC uses strings for algorithm identifiers, DSKPP uses URIs. Why the inconsistency? (I'd prefer URIs, for consistency with XML Signature, XML Encryption, and neighboring specs.) - In section 6.2.2, the normative text defines , , , as "a series of URIs..." -- that's actually not true, as each of these elements includes a sequence of container elements that in turn contain the URIs. Please be precise when describing XML structures. - In section 6.2.2.2, the text about 4 and 2 pass DSKPP seems confused: If the ProtocolVariantsType is not used, then the DSKPP server will proceed with ordinary 4-pass DSKPP. However, it does not support 4-pass DSKPP, then the server MUST find a suitable two-pass variant or else the protocol run will fail. I believe it's supposed to say "if no protocol variants are indicated, then the server will proceed with ordinary 4 pass, or maybe with 2 pass", or something like that. Please phrase this more clearly. (Incidentally, what does it mean that the *type* is not used?) - In 6.2.2.4, "An AuthenticationCode MAY or MAY NOT contain alphanumeric characters.." -- excuse me? - same section, "A DSKPP client MAY contain Authentication Data consisting of signed data of client Nonce with a client certificate's private key." I believe this is supposed to describe a public key signature of the client Nonce. - same section, "The element of ... have the following meaning" -- make that "elements" - same section, a lot of discussion that "certificate itself is typically sufficient"; "DeviceID, KeyID, and/or nonce provided in the element ougth to be sufficient to identify the requester". What's probably meant is that ClientID can be omitted if the requester can be identified otherwise. If so, please say that. - The security considerations are somewhat inconsistent in their attacker model. In some cases, a man in the middle is assumed to have the capability to bypass TLS protection (e.g., 14.2.2); in other sections transport security is presented as a solution to concerns about the integrity of protocol exchanges (e.g., 14.2.4). It would contribute to the clarity of the security considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on. - While I've not worked this through fully, it appears that an active attacker can manipulate the SupportedKeyTypes and KeyType elements in the ClientHello and KeyProvServerHello messages, without the protocol failing, if both device and server support multiple key types with mutually interchangeable key material. That might lead to an inconsistent state, or possibly to the use of weak keys. It might be useful to use the negotiated algorithm value as input into the MAC derivation mechanism. - Finally, on yet another editorial note, the namespace in the schema and the one in the IANA considerations section are inconsistent. Regards, -- Thomas Roessler, W3C _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 16 11:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3z3-00024v-Qz; Fri, 16 Nov 2007 11:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3iR-0003bp-FA; Fri, 16 Nov 2007 11:06:47 -0500 Received: from homer.w3.org ([128.30.52.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3iR-0005dN-01; Fri, 16 Nov 2007 11:06:47 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D9D1B4F159; Fri, 16 Nov 2007 11:06:45 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It3iP-0001f9-BM; Fri, 16 Nov 2007 17:06:45 +0100 Date: Fri, 16 Nov 2007 17:06:45 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org Message-ID: <20071116160645.GH28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org References: <20071116153033.GF28302@raktajino.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071116153033.GF28302@raktajino.does-not-exist.org> User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Fri, 16 Nov 2007 11:23:53 -0500 Cc: Subject: [KEYPROV] Re: Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org On 2007-11-16 16:30:33 +0100, Thomas Roessler wrote: > Reviewing BCP56, I would suspect that there might be slight > differences of opinion on whether DSKPP should have a port and URI > scheme of its own. However, given that the protocol binding (with > the above clarifications) will be layered rather cleanly on HTTP, > and won't confuse URI-based addressing, I fail to see the benefit of > allocating a separate port and/or URI scheme. This binding looks > like it is implementable on top of a conventional Web server, which > would suggest sticking to port 80 and http (or port 443 and https). > Beyond that point, I do not see any significant disagreements > between the guidance in BCP56 and this draft. ... and reviewing the old discussion on apps-review (which I meant to do before sending the review, but didn't), the disagreement might in fact be not so slight. So, apologies. See in particular: http://www1.ietf.org/mail-archive/web/apps-review/current/msg00085.html So, there are a number of criteria on the table here: - BCP56 mainly talks about expected server implementation and network filtering. In terms of server implementation, DSKPP sounds as though it could be implemented on top of an existing HTTP server; from my review, the layering is reasonably clean. Yes, there is separate code, but not in a way that's significantly different from any Web app. The possible arguments in favor of new methods don't sound like they apply (POST should be just fine), which leaves questions about network administrators and "different data sets" as the remaining ones. I don't understand what the "different data sets" criterion is even supposed to mean, and can't speak to the network administrators. - In Chris' message (URL above), he writes: > Unless the primary client for your protocol is a web browser, I > would strongly encourage registering a separate port. There is indeed some indication in the specification that the protocol might at the very least be triggered through a traditional Web browser. Besides that, any exchanges beyond a possible trigger message seem to involve dereferencing a URI with POST as the method anyway, so the port is configurable at that point, if the deployer so desires. That, to me, suggests strongly that Chris' argument doesn't really apply to the spec at hand. To the more general statement that "At this point it's inevitable we'll end up with intrusive firewalls on port 80 that will break anything beyond stock browser-based HTTP", I'd notice that POST with some XML content type and some XML content is totally within the realm of "stock browser-based HTTP" today. http://www.w3.org/TR/XMLHttpRequest/ So, in summary, I don't see convincing reasons to urge the DSKPP group to move this away from port 80. Cheers, -- Thomas Roessler, W3C _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 16 11:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3z3-000210-MC; Fri, 16 Nov 2007 11:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It39S-0007AN-O5; Fri, 16 Nov 2007 10:30:39 -0500 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It39P-0003cZ-Np; Fri, 16 Nov 2007 10:30:38 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 824574F159; Fri, 16 Nov 2007 10:30:34 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It39N-0001bS-Vh; Fri, 16 Nov 2007 16:30:33 +0100 Date: Fri, 16 Nov 2007 16:30:33 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net Message-ID: <20071116153033.GF28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-Mailman-Approved-At: Fri, 16 Nov 2007 11:23:53 -0500 Cc: keyprov@ietf.org, apps-review@ietf.org Subject: [KEYPROV] Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a review of draft-ietf-keyprov-dskpp-01. It occasionally strays into the PSKC draft; however, I haven't fully read that document. Specific observations on the HTTP binding: - In 12.2.4, the spec says "Persistent connections as defined in HTTP/1.1 are assumed, but not required." Taken literally, I don't know what "assumed, but not required" means. - The HTTP binding does not indicate whether it fully defines the behavior of the HTTP server that is appearing as part of the transactions, or whether the DSKPP server is identified by either a specific URI and/or Host. Please clarify that in the HTTP binding part. (4.3 -- and other places -- suggest that the DSKPP server is indeed identified by a specific URI, which would be just fine.) - In 12.2.4, instead of talking about "POST operations", maybe say "DSKPP requests are mapped to HTTP requests with the POST method". - For the 4-step protocol, it's probably worth calling out here how the different messages are bound together, as they may be transported through different connections. In particular, KeyProvServerHello is bound to the preceding KeyProvClientHello by being transmitted in the corresponding HTTP response; KeyProvServerHello MUST have a sessionId attribute, and the sesionId on the subsequent KeyProvClientNonce MUST be identical. KeyProServerFinished is then once again bound to the rest through HTTP (and possibly through a sessionID). - The HTTP binding does not cover content negotiation. I'd suggest: "HTTP requests MAY include an HTTP Accept header field. This header field SHOULD have the value application/vnd.ietf.keyprov.dskpp+xml. The Accept header MAY include additional content types defined by future versions of this protocol." (The server is allowed to downgrade [6.2.3], so if a future version uses a different content type, that should be in the client's request, along with the current one, *if* the client is willing to downgrade.) - The examples in 12.2.8 don't match the requirements from 12.2.3. - 12.2.7 is extremely fuzzy as to when the server-side initialization message may be sent. As long as that's indeed in response to a specific user request with the appropriate Accept header (e.g., to a specific DSKPP server URL), the use of the 200 code seems fine. However, please clarify that using a 200 code combined with the DSKPP content type is *not* an appropriate means to trigger protocol initialization during a browsing session where the user's request was directed to some other resource. (In that case, some 40x code might be much more appropriate.) - It's not clear how one-step DSKPP would work over HTTP. What kind of request does the client send to trigger that? If that isn't intended to run over HTTP, please clarify. - In 12.2.3, the spec says: "HTTP proxies MUST NOT cache responses carrying DSKPP messages. For this reason, the following holds:" That's a conformance requirement on HTTP proxies; don't do that. Instead: "In order to avoid caching of responses carrying DSKPP messages by proxies, the following holds:" (Also, note that POST invalidates cached entities.) - In 12.2.5, "If the type of a DSKPP request cannot be determined, the DSKPP responder MUST return a 400 response." What precisely is meant by "type cannot be determined"? (Example?) Reviewing BCP56, I would suspect that there might be slight differences of opinion on whether DSKPP should have a port and URI scheme of its own. However, given that the protocol binding (with the above clarifications) will be layered rather cleanly on HTTP, and won't confuse URI-based addressing, I fail to see the benefit of allocating a separate port and/or URI scheme. This binding looks like it is implementable on top of a conventional Web server, which would suggest sticking to port 80 and http (or port 443 and https). Beyond that point, I do not see any significant disagreements between the guidance in BCP56 and this draft. Various other observations while going through the document... - -00 included schema fragments in section 4.9. These are gone in the corresponding sections in -01, making review of the schema for consistency with the human-readable text significantly harder. I'd recommend resurrecting the schema fragements in future iterations of the draft for ease of review. While dropping the schema fragments, *any* human-readable documentation for types such as AbstractRequestType type has been lost. - Please say early on in the spec what name space prefixes are used in XML snippets throughout the document, and what they mean. - What's the order relation for the various Version attributes? Are they treated as decimal numbers, as strings, as a dot-separated pairs of two integers? Is "01.00" the same as "1.0"? - Trying to assemble the overall XML schema to validate some of the examples... * DSKPP imports the schema from PSKC, which in turn imports a schema for the urn:ietf:params:xml:ns:keyprov:logo namespace, which apparently isn't available anywhere. * The DSKPP and PSKC drafts use inconsistent namespaces for PSKC, urn:ietf:params:xml:ns:keyprov:container vs urn:ietf:params:xml:ns:keyprov:1.0:container * The DSKPP schema uses an extension construct like this one repeatedly (DeviceIdentifierDataType, KeyContainerType, PayloadType, KeyProvTriggerType): In conjunction with use of elementFormDefault="unqualified", that unfortunately leads to a non-deterministic content model, as DeviceId is not actually in the target namespace. One possible fix is to move away from elementFormDefault="unqualified". (PSKC uses "qualified" anyway.) - StatusCode is one out of a closed list of strings. For extensibility, it might be worth using URIs/URNs instead of text strings here, and defining StatusCode to be of type anyURI. - Same for PlatformType. - ProtocolVariantsType uses elements to identify supported protocol variants. I wonder if having an extension point in the schema for future variants might be useful. Also, why not use an URI-based extensibility pattern? - In 11.3.3, ds:KeyInfoType is used for Payloads, and "only those choices of the ds:KeyInfoType that identify a symmetric key are allowed". Does a ds:RetrievalMethod that points to a ds:KeyName elsewhere possibly identify a symmetric key? Please be clearer about which parts of ds:KeyInfo you use here. - Same in 11.2.3 for public keys. - IdentifierType is limited to a maximum 128 characters in the schema, yet that limitation is nowhere found in the normative text. - PSKC uses strings for algorithm identifiers, DSKPP uses URIs. Why the inconsistency? (I'd prefer URIs, for consistency with XML Signature, XML Encryption, and neighboring specs.) - In section 6.2.2, the normative text defines , , , as "a series of URIs..." -- that's actually not true, as each of these elements includes a sequence of container elements that in turn contain the URIs. Please be precise when describing XML structures. - In section 6.2.2.2, the text about 4 and 2 pass DSKPP seems confused: If the ProtocolVariantsType is not used, then the DSKPP server will proceed with ordinary 4-pass DSKPP. However, it does not support 4-pass DSKPP, then the server MUST find a suitable two-pass variant or else the protocol run will fail. I believe it's supposed to say "if no protocol variants are indicated, then the server will proceed with ordinary 4 pass, or maybe with 2 pass", or something like that. Please phrase this more clearly. (Incidentally, what does it mean that the *type* is not used?) - In 6.2.2.4, "An AuthenticationCode MAY or MAY NOT contain alphanumeric characters.." -- excuse me? - same section, "A DSKPP client MAY contain Authentication Data consisting of signed data of client Nonce with a client certificate's private key." I believe this is supposed to describe a public key signature of the client Nonce. - same section, "The element of ... have the following meaning" -- make that "elements" - same section, a lot of discussion that "certificate itself is typically sufficient"; "DeviceID, KeyID, and/or nonce provided in the element ougth to be sufficient to identify the requester". What's probably meant is that ClientID can be omitted if the requester can be identified otherwise. If so, please say that. - The security considerations are somewhat inconsistent in their attacker model. In some cases, a man in the middle is assumed to have the capability to bypass TLS protection (e.g., 14.2.2); in other sections transport security is presented as a solution to concerns about the integrity of protocol exchanges (e.g., 14.2.4). It would contribute to the clarity of the security considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on. - While I've not worked this through fully, it appears that an active attacker can manipulate the SupportedKeyTypes and KeyType elements in the ClientHello and KeyProvServerHello messages, without the protocol failing, if both device and server support multiple key types with mutually interchangeable key material. That might lead to an inconsistent state, or possibly to the use of weak keys. It might be useful to use the negotiated algorithm value as input into the MAC derivation mechanism. - Finally, on yet another editorial note, the namespace in the schema and the one in the IANA considerations section are inconsistent. Regards, -- Thomas Roessler, W3C _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 16 11:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3z3-00024v-Qz; Fri, 16 Nov 2007 11:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3iR-0003bp-FA; Fri, 16 Nov 2007 11:06:47 -0500 Received: from homer.w3.org ([128.30.52.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3iR-0005dN-01; Fri, 16 Nov 2007 11:06:47 -0500 Received: from raktajino.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D9D1B4F159; Fri, 16 Nov 2007 11:06:45 -0500 (EST) Received: from roessler by raktajino.does-not-exist.org with local (Exim 4.66) (envelope-from ) id 1It3iP-0001f9-BM; Fri, 16 Nov 2007 17:06:45 +0100 Date: Fri, 16 Nov 2007 17:06:45 +0100 From: Thomas Roessler To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org Message-ID: <20071116160645.GH28302@raktajino.does-not-exist.org> Mail-Followup-To: adoherty@rsa.com, smachani@diversinet.com, mpei@verisign.com, mnystrom@rsa.com, pbaker@verisign.com, Hannes.Tschofenig@gmx.net, apps-review@ietf.org, keyprov@ietf.org References: <20071116153033.GF28302@raktajino.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071116153033.GF28302@raktajino.does-not-exist.org> User-Agent: Mutt/1.5.17 (2007-11-04) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Fri, 16 Nov 2007 11:23:53 -0500 Cc: Subject: [KEYPROV] Re: Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org On 2007-11-16 16:30:33 +0100, Thomas Roessler wrote: > Reviewing BCP56, I would suspect that there might be slight > differences of opinion on whether DSKPP should have a port and URI > scheme of its own. However, given that the protocol binding (with > the above clarifications) will be layered rather cleanly on HTTP, > and won't confuse URI-based addressing, I fail to see the benefit of > allocating a separate port and/or URI scheme. This binding looks > like it is implementable on top of a conventional Web server, which > would suggest sticking to port 80 and http (or port 443 and https). > Beyond that point, I do not see any significant disagreements > between the guidance in BCP56 and this draft. ... and reviewing the old discussion on apps-review (which I meant to do before sending the review, but didn't), the disagreement might in fact be not so slight. So, apologies. See in particular: http://www1.ietf.org/mail-archive/web/apps-review/current/msg00085.html So, there are a number of criteria on the table here: - BCP56 mainly talks about expected server implementation and network filtering. In terms of server implementation, DSKPP sounds as though it could be implemented on top of an existing HTTP server; from my review, the layering is reasonably clean. Yes, there is separate code, but not in a way that's significantly different from any Web app. The possible arguments in favor of new methods don't sound like they apply (POST should be just fine), which leaves questions about network administrators and "different data sets" as the remaining ones. I don't understand what the "different data sets" criterion is even supposed to mean, and can't speak to the network administrators. - In Chris' message (URL above), he writes: > Unless the primary client for your protocol is a web browser, I > would strongly encourage registering a separate port. There is indeed some indication in the specification that the protocol might at the very least be triggered through a traditional Web browser. Besides that, any exchanges beyond a possible trigger message seem to involve dereferencing a URI with POST as the method anyway, so the port is configurable at that point, if the deployer so desires. That, to me, suggests strongly that Chris' argument doesn't really apply to the spec at hand. To the more general statement that "At this point it's inevitable we'll end up with intrusive firewalls on port 80 that will break anything beyond stock browser-based HTTP", I'd notice that POST with some XML content type and some XML content is totally within the realm of "stock browser-based HTTP" today. http://www.w3.org/TR/XMLHttpRequest/ So, in summary, I don't see convincing reasons to urge the DSKPP group to move this away from port 80. Cheers, -- Thomas Roessler, W3C _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 16 12:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It55y-0000tK-OG; Fri, 16 Nov 2007 12:35:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It55w-0000sm-63 for keyprov@ietf.org; Fri, 16 Nov 2007 12:35:08 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It55v-0006x0-1o for keyprov@ietf.org; Fri, 16 Nov 2007 12:35:08 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAGHYxx3016978; Fri, 16 Nov 2007 12:34:59 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Fri, 16 Nov 2007 12:34:58 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAGHYoxh017665; Fri, 16 Nov 2007 12:34:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Nov 2007 12:34:40 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D36B3A6@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <20071116153033.GF28302@raktajino.does-not-exist.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-keyprov-dskpp-01 Thread-Index: AcgoZco3aJyfP+nHRP2VH3x+iKGlIAAD1kHw References: <20071116153033.GF28302@raktajino.does-not-exist.org> From: "Doherty, Andrea" To: "Thomas Roessler" , , , =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= , , , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: Subject: [KEYPROV] RE: Review of draft-ietf-keyprov-dskpp-01 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Thomas - Thank you for your thorough review, and constructive comments. = We'll go through these and provide feedback/questions. All - Thomas wrote: - -00 included schema fragments in section 4.9. These are gone in the corresponding sections in -01, making review of the schema for consistency with the human-readable text significantly harder. I'd recommend resurrecting the schema fragements in future iterations of the draft for ease of review. While dropping the schema fragments, *any* human-readable documentation for types such as AbstractRequestType type has been lost. What are other views on this change in -01? More feedback would be = greatly appreciated. Andrea=20 -----Original Message----- From: Thomas Roessler [mailto:tlr@w3.org]=20 Sent: Friday, November 16, 2007 10:31 AM To: Doherty, Andrea; smachani@diversinet.com; mpei@verisign.com; = Nystr=F6m, Magnus; pbaker@verisign.com; Hannes.Tschofenig@gmx.net Cc: apps-review@ietf.org; keyprov@ietf.org Subject: Review of draft-ietf-keyprov-dskpp-01 This is a review of draft-ietf-keyprov-dskpp-01. It occasionally strays into the PSKC draft; however, I haven't fully read that document. Specific observations on the HTTP binding: - In 12.2.4, the spec says "Persistent connections as defined in HTTP/1.1 are assumed, but not required." Taken literally, I don't know what "assumed, but not required" means. - The HTTP binding does not indicate whether it fully defines the behavior of the HTTP server that is appearing as part of the transactions, or whether the DSKPP server is identified by either a specific URI and/or Host. Please clarify that in the HTTP binding part. (4.3 -- and other places -- suggest that the DSKPP server is indeed identified by a specific URI, which would be just fine.) - In 12.2.4, instead of talking about "POST operations", maybe say "DSKPP requests are mapped to HTTP requests with the POST method". - For the 4-step protocol, it's probably worth calling out here how the different messages are bound together, as they may be transported through different connections. In particular, KeyProvServerHello is bound to the preceding KeyProvClientHello by being transmitted in the corresponding HTTP response; KeyProvServerHello MUST have a sessionId attribute, and the sesionId on the subsequent KeyProvClientNonce MUST be identical. KeyProServerFinished is then once again bound to the rest through HTTP (and possibly through a sessionID). - The HTTP binding does not cover content negotiation. I'd suggest: "HTTP requests MAY include an HTTP Accept header field. This header field SHOULD have the value application/vnd.ietf.keyprov.dskpp+xml. The Accept header MAY include additional content types defined by future versions of this protocol." =20 (The server is allowed to downgrade [6.2.3], so if a future version uses a different content type, that should be in the client's request, along with the current one, *if* the client is willing to downgrade.) - The examples in 12.2.8 don't match the requirements from 12.2.3. - 12.2.7 is extremely fuzzy as to when the server-side initialization message may be sent. As long as that's indeed in response to a specific user request with the appropriate Accept header (e.g., to a specific DSKPP server URL), the use of the 200 code seems fine. However, please clarify that using a 200 code combined with the DSKPP content type is *not* an appropriate means to trigger protocol initialization during a browsing session where the user's request was directed to some other resource. (In that case, some 40x code might be much more appropriate.) - It's not clear how one-step DSKPP would work over HTTP. What kind of request does the client send to trigger that? If that isn't intended to run over HTTP, please clarify. - In 12.2.3, the spec says: "HTTP proxies MUST NOT cache responses carrying DSKPP messages. For this reason, the following holds:" That's a conformance requirement on HTTP proxies; don't do that. Instead: "In order to avoid caching of responses carrying DSKPP messages by proxies, the following holds:" (Also, note that POST invalidates cached entities.) - In 12.2.5, "If the type of a DSKPP request cannot be determined, the DSKPP responder MUST return a 400 response." What precisely is meant by "type cannot be determined"? (Example?) Reviewing BCP56, I would suspect that there might be slight differences of opinion on whether DSKPP should have a port and URI scheme of its own. However, given that the protocol binding (with the above clarifications) will be layered rather cleanly on HTTP, and won't confuse URI-based addressing, I fail to see the benefit of allocating a separate port and/or URI scheme. This binding looks like it is implementable on top of a conventional Web server, which would suggest sticking to port 80 and http (or port 443 and https). Beyond that point, I do not see any significant disagreements between the guidance in BCP56 and this draft. Various other observations while going through the document... - -00 included schema fragments in section 4.9. These are gone in the corresponding sections in -01, making review of the schema for consistency with the human-readable text significantly harder. I'd recommend resurrecting the schema fragements in future iterations of the draft for ease of review. While dropping the schema fragments, *any* human-readable documentation for types such as AbstractRequestType type has been lost. - Please say early on in the spec what name space prefixes are used in XML snippets throughout the document, and what they mean. - What's the order relation for the various Version attributes? Are they treated as decimal numbers, as strings, as a dot-separated pairs of two integers? Is "01.00" the same as "1.0"? - Trying to assemble the overall XML schema to validate some of the examples... * DSKPP imports the schema from PSKC, which in turn imports a schema for the urn:ietf:params:xml:ns:keyprov:logo namespace, which apparently isn't available anywhere. =20 * The DSKPP and PSKC drafts use inconsistent namespaces for PSKC, urn:ietf:params:xml:ns:keyprov:container vs urn:ietf:params:xml:ns:keyprov:1.0:container * The DSKPP schema uses an extension construct like this one repeatedly (DeviceIdentifierDataType, KeyContainerType, PayloadType, KeyProvTriggerType): =20 =20 In conjunction with use of elementFormDefault=3D"unqualified", that unfortunately leads to a non-deterministic content model, as DeviceId is not actually in the target namespace. One possible fix is to move away from elementFormDefault=3D"unqualified". (PSKC uses "qualified" anyway.) - StatusCode is one out of a closed list of strings. For extensibility, it might be worth using URIs/URNs instead of text strings here, and defining StatusCode to be of type anyURI. - Same for PlatformType. - ProtocolVariantsType uses elements to identify supported protocol variants. I wonder if having an extension point in the schema for future variants might be useful. Also, why not use an URI-based extensibility pattern? - In 11.3.3, ds:KeyInfoType is used for Payloads, and "only those choices of the ds:KeyInfoType that identify a symmetric key are allowed". Does a ds:RetrievalMethod that points to a ds:KeyName elsewhere possibly identify a symmetric key? Please be clearer about which parts of ds:KeyInfo you use here. =20 - Same in 11.2.3 for public keys. - IdentifierType is limited to a maximum 128 characters in the schema, yet that limitation is nowhere found in the normative text. - PSKC uses strings for algorithm identifiers, DSKPP uses URIs. Why the inconsistency? (I'd prefer URIs, for consistency with XML Signature, XML Encryption, and neighboring specs.) - In section 6.2.2, the normative text defines ,=20 , , as "a series of URIs..." -- that's actually not true, as each of these elements includes a sequence of container elements that in turn contain the URIs. Please be precise when describing XML structures. - In section 6.2.2.2, the text about 4 and 2 pass DSKPP seems confused: =20 If the ProtocolVariantsType is not used, then the DSKPP server will proceed with ordinary 4-pass DSKPP. However, it does not support 4-pass DSKPP, then the server MUST find a suitable two-pass variant or else the protocol run will fail. =20 I believe it's supposed to say "if no protocol variants are indicated, then the server will proceed with ordinary 4 pass, or maybe with 2 pass", or something like that. Please phrase this more clearly. (Incidentally, what does it mean that the *type* is not used?) - In 6.2.2.4, "An AuthenticationCode MAY or MAY NOT contain alphanumeric characters.." -- excuse me? - same section, "A DSKPP client MAY contain Authentication Data consisting of signed data of client Nonce with a client certificate's private key." I believe this is supposed to describe a public key signature of the client Nonce. - same section, "The element of ... have the following meaning" -- make that "elements" - same section, a lot of discussion that "certificate itself is typically sufficient"; "DeviceID, KeyID, and/or nonce provided in the element ougth to be sufficient to identify the requester". What's probably meant is that ClientID can be omitted if the requester can be identified otherwise. If so, please say that. - The security considerations are somewhat inconsistent in their attacker model. In some cases, a man in the middle is assumed to have the capability to bypass TLS protection (e.g., 14.2.2); in other sections transport security is presented as a solution to concerns about the integrity of protocol exchanges (e.g., 14.2.4). It would contribute to the clarity of the security considerations if there was a clear discussion of the assumptions beforehand, and a consistent use of attacker models later on. - While I've not worked this through fully, it appears that an active attacker can manipulate the SupportedKeyTypes and KeyType elements in the ClientHello and KeyProvServerHello messages, without the protocol failing, if both device and server support multiple key types with mutually interchangeable key material. That might lead to an inconsistent state, or possibly to the use of weak keys. It might be useful to use the negotiated algorithm value as input into the MAC derivation mechanism. - Finally, on yet another editorial note, the namespace in the schema and the one in the IANA considerations section are inconsistent. Regards, --=20 Thomas Roessler, W3C _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Sun Nov 18 12:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itny9-0007Hv-MQ; Sun, 18 Nov 2007 12:30:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itny7-0007H6-7i; Sun, 18 Nov 2007 12:30:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itny6-0005kX-R0; Sun, 18 Nov 2007 12:30:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 75636175AD; Sun, 18 Nov 2007 17:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itny5-0003r0-Vf; Sun, 18 Nov 2007 12:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 12:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: keyprov@ietf.org Subject: [KEYPROV] I-D Action:draft-ietf-keyprov-symmetrickeyformat-01.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Symmetric Key Package Content Type Author(s) : S. Turner, et al. Filename : draft-ietf-keyprov-symmetrickeyformat-01.txt Pages : 8 Date : 2007-11-18 This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax [RFC3852] can be used to digitally sign, digest, authenticate, or encrypt this content type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-symmetrickeyformat-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-symmetrickeyformat-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-symmetrickeyformat-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18122035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-keyprov-symmetrickeyformat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-keyprov-symmetrickeyformat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18122035.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --NextPart-- From keyprov-bounces@ietf.org Mon Nov 19 04:45:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3C0-0003KS-1p; Mon, 19 Nov 2007 04:45:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Bu-0003IN-0V for keyprov@ietf.org; Mon, 19 Nov 2007 04:45:18 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu3Bt-0003ar-Di for keyprov@ietf.org; Mon, 19 Nov 2007 04:45:17 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAJ9eHZq016045 for ; Mon, 19 Nov 2007 01:40:17 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 01:44:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2007 01:44:17 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C957781B@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Auto Response] I-D submission: Portal Symmetric Key Container v1.2 Thread-Index: AcgqkA6jwfmFJxaKRpWZtLLjSZfwuAAAKK0Q From: "Pei, Mingliang" To: X-OriginalArrivalTime: 19 Nov 2007 09:44:18.0199 (UTC) FILETIME=[C1042270:01C82A90] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [KEYPROV] FW: [Auto Response] I-D submission: Portal Symmetric Key Container v1.2 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org PSKC v1.2 is submitted. - Ming -----Original Message----- From: Internet Draft Submission Manager [mailto:internet-drafts-reply@ietf.org]=20 Sent: Monday, November 19, 2007 1:40 AM To: Pei, Mingliang Subject: [Auto Response] I-D submission: Portal Symmetric Key Container v1.2 Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. Please note that the pre-meeting cutoff date for new documents (i.e., version -00 Internet-Drafts) was Monday, November 12 at 9:00 AM ET (14:00 UTC/GMT). Your submission was received after this time. The Internet-Drafts administrator will examine your submission, and the posting decision will be made as follows: * If you submitted a version -00 Internet-Draft before the cutoff deadline, then your document will be posted on the Internet-Drafts page of the IETF Web site as soon as possible, and an I-D Action message will be sent to the I-D Announce List. If your document was submitted before the cutoff deadline, but was rejected due to boilerplate or format issues, then the Internet-Drafts administrator will work with you to attempt to resolve these issues and post the document in time for the meeting.=20 * If you submitted a version -00 Internet-Draft after the cutoff deadline, then your document will NOT be processed until on or after Monday, December 3 at 9:00 AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes. * If you submitted a version -00 WG Internet-Draft after the cutoff deadline, and if this draft replaces an existing non-WG draft, then the renamed document will be posted on the Internet-Drafts page of the IETF Web site as soon as possible, and an I-D Action message will be sent to the I-D Announce List. * If you submitted a version -01 or higher Internet-Draft, then your document will be posted on the Internet-Drafts page of the IETF Web site as soon as possible, and an I-D Action message will be sent to the I-D Announce List. As you may be aware, the pre-meeting cutoff date for updated submissions is Monday, November 19 at 9:00 AM ET (14:00 UTC/GMT). Since the Secretariat receives a large number of Internet-Drafts in the week preceding the cutoff date for updated submissions, your document may not be processed and announced for a number of days. Our goal is to process and announce all valid pre-meeting Internet-Draft submissions by Friday, November 23 at the latest. =20 If you need to track the status of your Internet-Draft submission, then please send a note to ietf-action@ietf.org (using the suggested subject line Status of I-D Submission: ) and reference this auto-response acknowledgement in the body. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in the ID-Checklist (http://www.ietf.org/ID-Checklist.html) or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish your Internet-Draft to the IESG. The IETF Secretariat _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Nov 19 04:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Gg-00065N-Nh; Mon, 19 Nov 2007 04:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Gf-00064u-0e for keyprov@ietf.org; Mon, 19 Nov 2007 04:50:13 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu3GU-0006BK-Kt for keyprov@ietf.org; Mon, 19 Nov 2007 04:50:10 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAJ9j7Ki016148 for ; Mon, 19 Nov 2007 01:45:07 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 01:49:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C82A91.6DC7EEBF" Date: Mon, 19 Nov 2007 01:49:06 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C957781C@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSKC changes made from 01 to 02 Thread-Index: AcgqkWyffaM3M4WYSYO+OYDB7uGLyA== From: "Pei, Mingliang" To: X-OriginalArrivalTime: 19 Nov 2007 09:49:07.0903 (UTC) FILETIME=[6DB174F0:01C82A91] X-Spam-Score: -4.0 (----) X-Scan-Signature: ef2aea728e49481eb45f312e9985f142 Subject: [KEYPROV] PSKC changes made from 01 to 02 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C82A91.6DC7EEBF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C82A91.6DC7EEBF" ------_=_NextPart_002_01C82A91.6DC7EEBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The attached version has been submitted to IETF. Here are the changes made in 02 version: =20 Changes from last version: =20 1. Changed algorithm enumerations to URIs 2. Changed all attribute name initial from lower case to upper case 3. Changed VersionType to use 2 major digits and 3 minor digits. It is consistent with DSKPP. 4. PSKC schema file to not use default namespace 5. Example fixed and validated against schema 6. Add name TIME_DRIFT for HOTP time based algorithm 7. Changed HOTP key algorithm URI from URN style to URL. This causes some inconsistency with DSKPP v1.1 and we will align both specifications in the next revision. 8. Added Logo in the common attribute section. 9. Added logo schema file content in the schema section. 10. A few typos. There are some items that we didn't make into this revision such as how to handle user PIN policy. We would like to discuss those items during the next work group meeting in IETF. =20 Please review this revision. Thank you, =20 - Ming =20 ------_=_NextPart_002_01C82A91.6DC7EEBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
The = attached version=20 has been submitted to IETF. Here are the changes made in 02=20 version:
 
Changes from last version:
 
1. Changed algorithm enumerations to = URIs
2.=20 Changed all attribute name initial from lower case to upper case
3. = Changed=20 VersionType to use 2 major digits and 3 minor digits. It is consistent = with=20 DSKPP.
4. PSKC=20 schema file to not use default namespace
5. Example fixed and validated against = schema
6. Add name TIME_DRIFT = for HOTP=20 time based algorithm
7. = Changed HOTP=20 key algorithm URI from URN style to URL. This causes some inconsistency = with=20 DSKPP v1.1 and we will align both specifications in the next = revision.
8. Added Logo in the common attribute=20 section.
9. Added logo schema = file=20 content in the schema section.
10. A=20 few typos.
There are some=20 items that we didn't make into this revision such as how to handle user = PIN=20 policy. We would like to discuss those items during the next work group = meeting=20 in IETF.
 
Please = review this=20 revision. Thank you,
 
-=20 Ming
 
 ------_=_NextPart_002_01C82A91.6DC7EEBF-- ------_=_NextPart_001_01C82A91.6DC7EEBF Content-Type: text/plain; name="draft-ietf-keyprov-portable-symmetric-key-container-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-keyprov-portable-symmetric-key-container-02.txt Content-Disposition: attachment; filename="draft-ietf-keyprov-portable-symmetric-key-container-02.txt" DQoNCmtleXByb3YgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQLiBIb3llcg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBY3RpdklkZW50aXR5DQpJbnRlbmRlZCBzdGF0dXM6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBQZWkNCkV4 cGlyZXM6IE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBWZXJpU2lnbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTLiBNYWNoYW5pDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERpdmVyc2luZXQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT LiBDaGFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBHZW1hbHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDYsIDIwMDcNCg0KDQogICAgICAgICAg ICAgICAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyDQogICAgICAgZHJhZnQt aWV0Zi1rZXlwcm92LXBvcnRhYmxlLXN5bW1ldHJpYy1rZXktY29udGFpbmVyLTAyLnR4dA0KDQpT dGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFm dCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQg b3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUg YmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVj b21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0 aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1l bnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQog ICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nl c3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0K DQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA5LCAyMDA4Lg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0KDQoN Cg0KDQoNCg0KDQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwg MjAwOCAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBv cnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQpB YnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHN5bW1ldHJpYyBrZXkgZm9y bWF0IGZvciB0cmFuc3BvcnQgYW5kDQogICBwcm92aXNpb25pbmcgb2Ygc3ltbWV0cmljIGtleXMg KE9uZSBUaW1lIFBhc3N3b3JkIChPVFApIHNoYXJlZA0KICAgc2VjcmV0cyBvciBzeW1tZXRyaWMg Y3J5cHRvZ3JhcGhpYyBrZXlzKSB0byBkaWZmZXJlbnQgdHlwZXMgb2Ygc3Ryb25nDQogICBhdXRo ZW50aWNhdGlvbiBkZXZpY2VzLiAgVGhlIHN0YW5kYXJkIHRva2VuIGZvcm1hdCBlbmFibGVzDQog ICBlbnRlcnByaXNlcyB0byBkZXBsb3kgYmVzdC1vZi1icmVlZCBzb2x1dGlvbnMgY29tYmluaW5n IGNvbXBvbmVudHMNCiAgIGZyb20gZGlmZmVyZW50IHZlbmRvcnMgaW50byB0aGUgc2FtZSBpbmZy YXN0cnVjdHVyZS4NCg0KICAgVGhpcyB3b3JrIGlzIGEgam9pbnQgZWZmb3J0IGJ5IHRoZSBtZW1i ZXJzIG9mIE9BVEggKEluaXRpYXRpdmUgZm9yDQogICBPcGVuIEF1VEhlbnRpY2F0aW9uKSB0byBz cGVjaWZ5IGEgZm9ybWF0IHRoYXQgY2FuIGJlIGZyZWVseQ0KICAgZGlzdHJpYnV0ZWQgdG8gdGhl IHRlY2huaWNhbCBjb21tdW5pdHkuICBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgYQ0KICAgY29t bW9uIGFuZCBzaGFyZWQgc3BlY2lmaWNhdGlvbiB3aWxsIGZhY2lsaXRhdGUgYWRvcHRpb24gb2Yg dHdvLQ0KICAgZmFjdG9yIGF1dGhlbnRpY2F0aW9uIG9uIHRoZSBJbnRlcm5ldCBieSBlbmFibGlu ZyBpbnRlcm9wZXJhYmlsaXR5DQogICBiZXR3ZWVuIGNvbW1lcmNpYWwgYW5kIG9wZW4tc291cmNl IGltcGxlbWVudGF0aW9ucy4NCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9k dWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQNCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgMy4gIFVzZSBDYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDMuMS4gIE9mZmxpbmUg VXNlIENhc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAg ICAgICAzLjEuMS4gIENyZWRlbnRpYWwgbWlncmF0aW9uIGJ5IGVuZC11c2VyIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNg0KICAgICAgIDMuMS4yLiAgQnVsayBpbXBvcnQgb2YgbmV3IGNyZWRlbnRp YWxzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgICAgMy4xLjMuICBCdWxrIG1pZ3Jh dGlvbiBvZiBleGlzdGluZyBjcmVkZW50aWFscyAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgICAz LjEuNC4gIENyZWRlbnRpYWwgdXBsb2FkIGNhc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNw0KICAgICAzLjIuICBPbmxpbmUgVXNlIENhc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgICAgMy4yLjEuICBPbmxpbmUgcHJvdmlzaW9u aW5nIGEgY3JlZGVudGlhbCB0byBlbmQtdXNlcidzDQogICAgICAgICAgICAgICBhdXRoZW50aWNh dGlvbiB0b2tlbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgICAz LjIuMi4gIFNlcnZlciB0byBzZXJ2ZXIgcHJvdmlzaW9uaW5nIG9mIGNyZWRlbnRpYWxzIC4gLiAu IC4gLiAgOA0KICAgICAgIDMuMi4zLiAgT25saW5lIHVwZGF0ZSBvZiBhbiBleGlzdGluZyBhdXRo ZW50aWNhdGlvbiB0b2tlbg0KICAgICAgICAgICAgICAgY3JlZGVudGlhbCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICA0LiAgUmVxdWlyZW1lbnRzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDUu ICBTeW1tZXRyaWMgS2V5IEF0dHJpYnV0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMQ0KICAgICA1LjEuICBDb21tb24gQXR0cmlidXRlcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAgICAgNS4xLjEuICBEYXRhIChPUFRJT05B TCkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgICA1LjEu Mi4gIEtleUFsZ29yaXRobSAoTUFOREFUT1JZKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMQ0KICAgICAgIDUuMS4zLiAgVXNhZ2UgKE1BTkRBVE9SWSkgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgICAgNS4xLjQuICBLZXlJZCAoTUFOREFUT1JZKSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgICA1LjEuNS4gIElz c3VlciAoTUFOREFUT1JZKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0K ICAgICAgIDUuMS42LiAgRnJpZW5kbHlOYW1lIChPUFRJT05BTCkgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEzDQogICAgICAgNS4xLjcuICBBY2Nlc3NSdWxlcyAoT1BUSU9OQUwpIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgICA1LjEuOC4gIEVuY3J5cHRp b25NZXRob2QgKE1BTkRBVE9SWSB3aGVuICdEYXRhJyBhdHRyaWJ1dGUNCiAgICAgICAgICAgICAg IGlzIGVuY3J5cHRlZCkpIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx Mw0KICAgICAgIDUuMS45LiAgRGlnZXN0TWV0aG9kIChNQU5EQVRPUlkgd2hlbiBEaWdlc3QgaXMg cHJlc2VudCkgIC4gLiAuIDE0DQogICAgICAgNS4xLjEwLiBPVFAgYW5kIENSIHNwZWNpZmljIEF0 dHJpYnV0ZXMgKE9QVElPTkFMKSAgLiAuIC4gLiAuIC4gMTQNCiAgICAgICA1LjEuMTEuIExvZ28g KE9QVElPTkFMKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KDQoN Cg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAg ICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1l dHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICA2LiAgS2V5IGNv bnRhaW5lciBYTUwgc2NoZW1hIGRlZmluaXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTgNCiAgICAgNi4xLiAgWE1MIFNjaGVtYSBUeXBlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICAgIDYuMS4xLiAgS2V5VHlwZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQogICAgICAgNi4xLjIuICBVc2Fn ZVR5cGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAg ICAgICA2LjEuMy4gIERldmljZVR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMg0KICAgICAgIDYuMS40LiAgRGV2aWNlSWRUeXBlIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICAgICAgNi4xLjUuICBVc2VyVHlwZSBU eXBlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgICAgICA2 LjEuNi4gIEtleUNvbnRhaW5lclR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyNQ0KICAgICAgIDYuMS43LiAgRW5jcnlwdGlvbk1ldGhvZFR5cGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICAgICAgNi4xLjguICBEaWdlc3RNZXRob2RUeXBl IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgNi4yLiAgS2V5 QWxnb3JpdGhtVHlwZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy OQ0KICAgICA2LjMuICBWYWx1ZUZvcm1hdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDI5DQogICAgIDYuNC4gIERhdGEgZWxlbWVudHMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkNCiAgICAgICA2LjQuMS4gIEtleUNv bnRhaW5lciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQ0KICAg Ny4gIEZvcm1hbCBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDMxDQogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzkNCiAgICAgOC4xLiAgUGF5bG9hZCBjb25maWRl bnRpYWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOQ0KICAgICA4LjIu ICBQYXlsb2FkIGludGVncml0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDQwDQogICAgIDguMy4gIFBheWxvYWQgYXV0aGVudGljaXR5IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgIDkuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQ0KICAgMTAuIEFwcGVuZGl4 IEEgLSBFeGFtcGxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVycyAgLiAuIC4gLiAuIC4gLiAuIDQy DQogICAgIDEwLjEuIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyIHdpdGggYSBzaW5nbGUgTm9uLUVu Y3J5cHRlZA0KICAgICAgICAgICBIT1RQIFNlY3JldCBLZXkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQyDQogICAgIDEwLjIuIFN5bW1ldHJpYyBLZXkgQ29udGFp bmVyIHdpdGggYSBzaW5nbGUgUGFzc3dvcmQtYmFzZWQNCiAgICAgICAgICAgRW5jcnlwdGVkIEhP VFAgU2VjcmV0IEtleSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mg0KICAgMTEu IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQ0DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDYNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQg Q29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiA0Nw0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhveWVyLCBldCBhbC4gICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBO b3ZlbWJlciAyMDA3DQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBXaXRoIGluY3JlYXNpbmcg dXNlIG9mIHN5bW1ldHJpYyBrZXkgYmFzZWQgYXV0aGVudGljYXRpb24gc3lzdGVtcw0KICAgc3Vj aCBhcyBzeXN0ZW1zIGJhc2VkIG9uZSB0aW1lIHBhc3N3b3JkIChPVFApIGFuZCBjaGFsbGVuZ2Ug cmVzcG9uc2UNCiAgIG1lY2hhbmlzbXMsIHRoZXJlIGlzIGEgbmVlZCBmb3IgdmVuZG9yIGludGVy b3BlcmFiaWxpdHkgYW5kIGENCiAgIHN0YW5kYXJkIGZvcm1hdCBmb3IgaW1wb3J0aW5nLCBleHBv cnRpbmcgb3IgcHJvdmlzaW9uaW5nIHN5bW1ldHJpYw0KICAga2V5IGJhc2VkIGNyZWRlbnRpYWxz IGZyb20gb25lIHN5c3RlbSB0byBhbm90aGVyLiAgVHJhZGl0aW9uYWxseQ0KICAgYXV0aGVudGlj YXRpb24gc2VydmVyIHZlbmRvcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIGhhdmUgdXNlZA0KICAg cHJvcHJpZXRhcnkgZm9ybWF0cyBmb3IgaW1wb3J0aW5nLCBleHBvcnRpbmcgYW5kIHByb3Zpc2lv bmluZyB0aGVzZQ0KICAgY3JlZGVudGlhbHMgaW50byB0aGVpciBzeXN0ZW1zIG1ha2luZyBpdCBo YXJkIHRvIHVzZSB0b2tlbnMgZnJvbQ0KICAgdmVuZG9yIEEgd2l0aCBhIHNlcnZlciBmcm9tIHZl bmRvciBCLg0KDQogICBUaGlzIEludGVybmV0IGRyYWZ0IGRlc2NyaWJlcyBhIHN0YW5kYXJkIGZv cm1hdCBmb3Igc2VyaWFsaXppbmcNCiAgIHN5bW1ldHJpYyBrZXkgYmFzZWQgY3JlZGVudGlhbHMg c3VjaCBhcyBPVFAgc2hhcmVkIHNlY3JldHMgZm9yIHN5c3RlbQ0KICAgaW1wb3J0LCBleHBvcnQg b3IgbmV0d29yay9wcm90b2NvbCB0cmFuc3BvcnQuICBUaGUgZ29hbCBpcyB0aGF0IHRoZQ0KICAg Zm9ybWF0IHdpbGwgZmFjaWxpdGF0ZSBkeW5hbWljIHByb3Zpc2lvbmluZyBhbmQgdHJhbnNmZXIg b2YgYQ0KICAgc3ltbWV0cmljIGtleSBzdWNoIGFzIGFuIE9UUCBzaGFyZWQgc2VjcmV0IG9yIGFu IGVuY3J5cHRpb24ga2V5IG9mDQogICBkaWZmZXJlbnQgdHlwZXMuICBJbiB0aGUgY2FzZSBvZiBP VFAgc2hhcmVkIHNlY3JldHMsIHRoZSBmb3JtYXQgd2lsbA0KICAgZmFjaWxpdGF0ZSBkeW5hbWlj IHByb3Zpc2lvbmluZyB1c2luZyBhbiBPVFAgcHJvdmlzaW9uaW5nIHByb3RvY29sIHRvDQogICBk aWZmZXJlbnQgZmxhdm9ycyBvZiBlbWJlZGRlZCB0b2tlbnMgZm9yIE9UUCBjcmVkZW50aWFscyBv ciBhbGxvdw0KICAgY3VzdG9tZXJzIHRvIGltcG9ydCBuZXcgb3IgZXhpc3RpbmcgdG9rZW5zIGlu IGJhdGNoIG9yIHNpbmdsZQ0KICAgaW5zdGFuY2VzIGludG8gYSBjb21wbGlhbnQgc3lzdGVtLg0K DQogICBUaGlzIGRyYWZ0IGFsc28gc3BlY2lmaWVzIHRoZSB0b2tlbiBhdHRyaWJ1dGVzIHJlcXVp cmVkIGZvcg0KICAgaW50ZXJvcGVyYWJpbGl0eSBzdWNoIGFzIHRoZSBpbml0aWFsIGV2ZW50IGNv dW50ZXIgdXNlZCBpbiB0aGUgSE9UUA0KICAgYWxnb3JpdGhtIFtIT1RQXS4gIEl0IGlzIGFsc28g YXBwbGljYWJsZSBmb3Igb3RoZXIgdGltZS1iYXNlZCBvcg0KICAgcHJvcHJpZXRhcnkgYWxnb3Jp dGhtcy4NCg0KICAgVG8gcHJvdmlkZSBhbiBhbmFsb2d5LCBpbiBwdWJsaWMga2V5IGVudmlyb25t ZW50cyB0aGUgUEtDUyMxMiBmb3JtYXQNCiAgIFtQS0NTMTJdIGlzIGNvbW1vbmx5IHVzZWQgZm9y IGltcG9ydGluZyBhbmQgZXhwb3J0aW5nIHByaXZhdGUga2V5cw0KICAgYW5kIGNlcnRpZmljYXRl cyBiZXR3ZWVuIHN5c3RlbXMuICBJbiB0aGUgZW52aXJvbm1lbnRzIG91dGxpbmVkIGluDQogICB0 aGlzIGRvY3VtZW50IHdoZXJlIE9UUCBjcmVkZW50aWFscyBtYXkgYmUgdHJhbnNwb3J0ZWQgZGly ZWN0bHkgZG93bg0KICAgdG8gc21hcnRjYXJkcyBvciBkZXZpY2VzIHdpdGggbGltaXRlZCBjb21w dXRpbmcgY2FwYWJpbGl0aWVzLCBhDQogICBmb3JtYXQgd2l0aCBzbWFsbCAoc2l6ZSBpbiBieXRl cykgYW5kIGV4cGxpY2l0IHNoYXJlZCBzZWNyZXQNCiAgIGNvbmZpZ3VyYXRpb24gYXR0cmlidXRl IGluZm9ybWF0aW9uIGlzIGRlc2lyYWJsZSwgYXZvaWRpbmcgY29tcGxleGl0eQ0KICAgb2YgUEtD UyMxMi4gIEZvciBleGFtcGxlLCBvbmUgd291bGQgaGF2ZSB0byB1c2Ugb3BhcXVlIGRhdGEgd2l0 aGluDQogICBQS0NTIzEyIHRvIGNhcnJ5IHNoYXJlZCBzZWNyZXQgYXR0cmlidXRlcyB1c2VkIGZv ciBPVFAgY2FsY3VsYXRpb25zLA0KICAgd2hlcmVhcyBhIG1vcmUgZXhwbGljaXQgYXR0cmlidXRl IHNjaGVtYSBkZWZpbml0aW9uIGlzIGJldHRlciBmb3INCiAgIGludGVyb3BlcmFiaWxpdHkgYW5k IGVmZmljaWVuY3kuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAg ICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1l bnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJT SEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBi ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQogICBJbiBleGFtcGxl cywgIkM6IiBhbmQgIlM6IiBpbmRpY2F0ZSBsaW5lcyBzZW50IGJ5IHRoZSBjbGllbnQgYW5kDQog ICBzZXJ2ZXIgcmVzcGVjdGl2ZWx5Lg0KDQogICBJbiB0aGUgdGV4dCBiZWxvdywgT1RQIHJlZmVy cyB0byBvbmUgdGltZSBwYXNzd29yZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIb3llciwg ZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICAg W1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBD b250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjMuICBVc2UgQ2FzZXMNCg0KICAgVGhp cyBzZWN0aW9uIGRlc2NyaWJlcyBhIGNvbXByZWhlbnNpdmUgbGlzdCBvZiB1c2UgY2FzZXMgdGhh dA0KICAgaW5zcGlyZWQgdGhlIGRldmVsb3BtZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRo ZXNlIHJlcXVpcmVtZW50cw0KICAgd2VyZSB1c2VkIHRvIGRlcml2ZSB0aGUgcHJpbWFyeSByZXF1 aXJlbWVudCB0aGF0IGRyb3ZlIHRoZSBkZXNpZ24uDQogICBUaGVzZSByZXF1aXJlbWVudHMgYXJl IGNvdmVyZWQgaW4gdGhlIG5leHQgc2VjdGlvbi4NCg0KICAgVGhlc2UgdXNlIGNhc2VzIGFsc28g aGVscCBpbiB1bmRlcnN0YW5kaW5nIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMNCiAgIHNwZWNp ZmljYXRpb24gdG8gcmVhbCB3b3JsZCBzaXR1YXRpb25zLg0KDQozLjEuICBPZmZsaW5lIFVzZSBD YXNlcw0KDQogICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSB1c2UgY2FzZXMgcmVsYXRpbmcg dG8gb2ZmbGluZSB0cmFuc3BvcnQgb2YNCiAgIGNyZWRlbnRpYWxzIGZyb20gb25lIHN5c3RlbSB0 byBhbm90aGVyLCB1c2luZyBzb21lIGZvcm0gb2YgZXhwb3J0IGFuZA0KICAgaW1wb3J0IG1vZGVs Lg0KDQozLjEuMS4gIENyZWRlbnRpYWwgbWlncmF0aW9uIGJ5IGVuZC11c2VyDQoNCiAgIEEgdXNl ciB3YW50cyB0byBtaWdyYXRlIGEgY3JlZGVudGlhbCBmcm9tIG9uZSBhdXRoZW50aWNhdGlvbiB0 b2tlbg0KICAgKGNvbnRhaW5lcikgdG8gYSBkaWZmZXJlbnQgYXV0aGVudGljYXRpb24gdG9rZW4u ICBGb3IgZXhhbXBsZSwgdGhlDQogICBhdXRoZW50aWNhdGlvbiB0b2tlbnMgbWF5IGJlIHNvZnQg dG9rZW5zIG9uIHR3byBkaWZmZXJlbnQgc3lzdGVtcw0KICAgKGNvbXB1dGVycyBvciBtb2JpbGUg cGhvbmVzKS4gIFRoZSB1c2VyIGNhbiBleHBvcnQgdGhlIGNyZWRlbnRpYWwgaW4NCiAgIGEgc3Rh bmRhcmQgZm9ybWF0IGZvciBpbXBvcnQgaW50byB0aGUgb3RoZXIgYXV0aGVudGljYXRpb24gdG9r ZW4uDQoNCiAgIFRoZSBrZXkgcHJvdGVjdGlvbiBtZWNoYW5pc20gbWF5IHJlbHkgb24gcGFzc3dv cmQtYmFzZWQgZW5jcnlwdGlvbg0KICAgZm9yIHNvZnQgdG9rZW5zLCBhIHByZS1wbGFjZWQgaGFy ZHdhcmUtcHJvdGVjdGVkIHRyYW5zZmVyIGtleSBzaGFyZWQNCiAgIGJldHdlZW4gdGhlIHR3byBz eXN0ZW1zIG9yIG1heSBhbHNvIHJlbHkgb24gYXN5bW1ldHJpYyBrZXlzLyBQS0kgaWYNCiAgIGF2 YWlsYWJsZS4NCg0KMy4xLjIuICBCdWxrIGltcG9ydCBvZiBuZXcgY3JlZGVudGlhbHMNCg0KICAg VG9rZW5zIGFyZSBtYW51ZmFjdHVyZWQgaW4gYnVsayBhbmQgYXNzb2NpYXRlZCBjcmVkZW50aWFs cyAoa2V5DQogICByZWNvcmRzKSBuZWVkIHRvIGJlIGxvYWRlZCBpbnRvIHRoZSB2YWxpZGF0aW9u IHN5c3RlbSB0aHJvdWdoIGEgZmlsZQ0KICAgb24gcG9ydGFibGUgbWVkaWEuICBUaGUgbWFudWZh Y3R1cmVyIHByb3ZpZGVzIHRoZSBjcmVkZW50aWFscyBpbiB0aGUNCiAgIGZvcm0gb2YgYSBmaWxl IGNvbnRhaW5pbmcgcmVjb3JkcyBpbiBzdGFuZGFyZCBmb3JtYXQsIHR5cGljYWxseSBvbiBhDQog ICBDRC4gIE5vdGUgdGhhdCB0aGUgdG9rZW4gbWFudWZhY3R1cmVyIGFuZCB0aGUgdmVuZG9yIGZv ciB0aGUNCiAgIHZhbGlkYXRpb24gc3lzdGVtIG1heSBiZSB0aGUgc2FtZSBvciBkaWZmZXJlbnQu DQoNCiAgIEluIHRoaXMgY2FzZSB0aGUgZmlsZSB1c3VhbGx5IGlzIHByb3RlY3RlZCBieSBhIHN5 bW1ldHJpYyB0cmFuc3BvcnQNCiAgIGtleSB3aGljaCB3YXMgY29tbXVuaWNhdGVkIHNlcGFyYXRl bHkgb3V0c2lkZSBvZiB0aGUgZmlsZSBiZXR3ZWVuIHRoZQ0KICAgdHdvIHBhcnRpZXMuDQoNCjMu MS4zLiAgQnVsayBtaWdyYXRpb24gb2YgZXhpc3RpbmcgY3JlZGVudGlhbHMNCg0KICAgQW4gZW50 ZXJwcmlzZSB3YW50cyB0byBwb3J0IGNyZWRlbnRpYWxzIGZyb20gYW4gZXhpc3RpbmcgdmFsaWRh dGlvbg0KICAgc3lzdGVtIEEgaW50byBhIGRpZmZlcmVudCB2YWxpZGF0aW9uIHN5c3RlbSBCLiBU aGUgZXhpc3RpbmcNCiAgIHZhbGlkYXRpb24gc3lzdGVtIHByb3ZpZGVzIHRoZSBlbnRlcnByaXNl IHdpdGggYSBmdW5jdGlvbmFsaXR5IHRoYXQNCiAgIGVuYWJsZXMgZXhwb3J0IG9mIGNyZWRlbnRp YWxzIChPVFAgdG9rZW5zKSBpbiBhIHN0YW5kYXJkIGZvcm1hdC4NCg0KDQoNCkhveWVyLCBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRh aW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgU2luY2UgdGhlIE9UUCB0b2tlbnMgYXJl IGluIHRoZSBzdGFuZGFyZCBmb3JtYXQsIHRoZSBlbnRlcnByaXNlIGNhbg0KICAgaW1wb3J0IHRo ZSB0b2tlbiByZWNvcmRzIGludG8gdGhlIG5ldyB2YWxpZGF0aW9uIHN5c3RlbSBCIGFuZCBzdGFy dA0KICAgdXNpbmcgdGhlIGV4aXN0aW5nIHRva2Vucy4gIE5vdGUgdGhhdCB0aGUgdmVuZG9ycyBm b3IgdGhlIHR3bw0KICAgdmFsaWRhdGlvbiBzeXN0ZW1zIG1heSBiZSB0aGUgc2FtZSBvciBkaWZm ZXJlbnQuDQoNCiAgIEluIHRoaXMgY2FzZSB0aGUgZmlsZSB1c3VhbGx5IGlzIHByb3RlY3RlZCBi eSBhIHN5bW1ldHJpYyB0cmFuc3BvcnQNCiAgIGtleSB3aGljaCB3YXMgY29tbXVuaWNhdGVkIHNl cGFyYXRlbHkgb3V0c2lkZSBvZiB0aGUgZmlsZSBiZXR3ZWVuIHRoZQ0KICAgdHdvIHZhbGlkYXRp b24gc3lzdGVtcy4NCg0KMy4xLjQuICBDcmVkZW50aWFsIHVwbG9hZCBjYXNlDQoNCiAgIFVzZXIg d2FudHMgdG8gYWN0aXZhdGUgYW5kIHVzZSBhIG5ldyBjcmVkZW50aWFsIGFnYWluc3QgYSB2YWxp ZGF0aW9uDQogICBzeXN0ZW0gdGhhdCBpcyBub3QgYXdhcmUgb2YgdGhpcyBjcmVkZW50aWFsLiAg VGhpcyBjcmVkZW50aWFsIG1heSBiZQ0KICAgZW1iZWRkZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9u IHRva2VuIChlLmcuICBTRCBjYXJkLCBVU0IgZHJpdmUpIHRoYXQNCiAgIHRoZSB1c2VyIGhhcyBw dXJjaGFzZWQgYXQgdGhlIGxvY2FsIGVsZWN0cm9uaWNzIHJldGFpbGVyLiAgQWxvbmcgd2l0aA0K ICAgdGhlIGF1dGhlbnRpY2F0aW9uIHRva2VuLCB0aGUgdXNlciBtYXkgZ2V0IHRoZSBjcmVkZW50 aWFsIG9uIGEgQ0Qgb3INCiAgIGEgZmxvcHB5IGluIGEgc3RhbmRhcmQgZm9ybWF0LiAgVGhlIHVz ZXIgY2FuIG5vdyB1cGxvYWQgdmlhIGEgc2VjdXJlDQogICBvbmxpbmUgY2hhbm5lbCBvciBpbXBv cnQgdGhpcyBjcmVkZW50aWFsIGludG8gdGhlIG5ldyB2YWxpZGF0aW9uDQogICBzeXN0ZW0gYW5k IHN0YXJ0IHVzaW5nIHRoZSBjcmVkZW50aWFsLg0KDQogICBUaGUga2V5IHByb3RlY3Rpb24gbWVj aGFuaXNtIG1heSByZWx5IG9uIHBhc3N3b3JkLWJhc2VkIGVuY3J5cHRpb24sDQogICBvciBhIHBy ZS1wbGFjZWQgaGFyZHdhcmUtcHJvdGVjdGVkIHRyYW5zZmVyIGtleSBzaGFyZWQgYmV0d2VlbiB0 aGUNCiAgIHRva2VuIG1hbnVmYWN0dXJlciBhbmQgdGhlIHZhbGlkYXRpb24gc3lzdGVtKHMpIGlm IGF2YWlsYWJsZS4NCg0KMy4yLiAgT25saW5lIFVzZSBDYXNlcw0KDQogICBUaGlzIHNlY3Rpb24g ZGVzY3JpYmVzIHRoZSB1c2UgY2FzZXMgcmVsYXRlZCB0byBwcm92aXNpb25pbmcgdGhlDQogICBj cmVkZW50aWFscyB1c2luZyBzb21lIGZvcm0gb2YgYSBvbmxpbmUgcHJvdmlzaW9uaW5nIHByb3Rv Y29sLg0KDQozLjIuMS4gIE9ubGluZSBwcm92aXNpb25pbmcgYSBjcmVkZW50aWFsIHRvIGVuZC11 c2VyJ3MgYXV0aGVudGljYXRpb24NCiAgICAgICAgdG9rZW4NCg0KICAgQSBtb2JpbGUgZGV2aWNl IHVzZXIgd2FudHMgdG8gb2J0YWluIGFuIE9UUCBjcmVkZW50aWFsIChzaGFyZWQNCiAgIHNlY3Jl dCkgZm9yIHVzZSB3aXRoIGFuIE9UUCBzb2Z0IHRva2VuIG9uIHRoZSBkZXZpY2UuICBUaGUgc29m dCB0b2tlbg0KICAgY2xpZW50IGZyb20gdmVuZG9yIEEgaW5pdGlhdGVzIHRoZSBwcm92aXNpb25p bmcgcHJvY2VzcyBhZ2FpbnN0IGENCiAgIHByb3Zpc2lvbmluZyBzeXN0ZW0gZnJvbSB2ZW5kb3Ig QiB1c2luZyBhIHN0YW5kYXJkcy1iYXNlZA0KICAgcHJvdmlzaW9uaW5nIHByb3RvY29sIHN1Y2gg YXMgW0RTS1BQXS4gIFRoZSBwcm92aXNpb25pbmcgc3lzdGVtDQogICBkZWxpdmVycyBvbmUgb3Ig bW9yZSBPVFAgY3JlZGVudGlhbChzKSBpbiBhIHN0YW5kYXJkIGZvcm1hdCB0aGF0IGNhbg0KICAg YmUgcHJvY2Vzc2VkIGJ5IHRoZSBtb2JpbGUgZGV2aWNlLiAgVGhlIHVzZXIgY2FuIGRvd25sb2Fk IGEgcGF5bG9hZA0KICAgdGhhdCBjb250YWlucyBtb3JlIHRoYW4gb25lIGNyZWRlbnRpYWwuDQoN CiAgIEluIGEgdmFyaWF0aW9uIG9mIHRoZSBhYm92ZSwgaW5zdGVhZCBvZiB0aGUgdXNlcidzIG1v YmlsZSBwaG9uZSwgYQ0KICAgY3JlZGVudGlhbCBpcyBwcm92aXNpb25lZCBpbiB0aGUgdXNlcidz IHNvZnQgdG9rZW4gYXBwbGljYXRpb24gb24gYQ0KICAgbGFwdG9wIHVzaW5nIGEgbmV0d29yay1i YXNlZCBvbmxpbmUgcHJvdG9jb2wuICBBcyBiZWZvcmUsIHRoZQ0KICAgcHJvdmlzaW9uaW5nIHN5 c3RlbSBkZWxpdmVycyBhbiBPVFAgY3JlZGVudGlhbCBpbiBhIHN0YW5kYXJkIGZvcm1hdA0KICAg dGhhdCBjYW4gYmUgcHJvY2Vzc2VkIGJ5IHRoZSBzb2Z0IHRva2VuIG9uIHRoZSBQQy4NCg0KDQoN Cg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAg ICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3lt bWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCjMuMi4yLiAgU2Vy dmVyIHRvIHNlcnZlciBwcm92aXNpb25pbmcgb2YgY3JlZGVudGlhbHMNCg0KICAgU29tZXRpbWVz LCBpbnN0ZWFkIG9mIGltcG9ydGluZyB0b2tlbiBpbmZvcm1hdGlvbiBmcm9tIG1hbnVmYWN0dXJl cg0KICAgdXNpbmcgYSBmaWxlLCBhbiBPVFAgdmFsaWRhdGlvbiBzZXJ2ZXIgbWF5IGRvd25sb2Fk IHRoZSBjcmVkZW50aWFsDQogICBzZWVkIHJlY29yZHMgdXNpbmcgYW4gb25saW5lIHByb3RvY29s LiAgVGhlIGNyZWRlbnRpYWxzIGNhbiBiZQ0KICAgZG93bmxvYWRlZCBpbiBhIHN0YW5kYXJkIGZv cm1hdCB0aGF0IGNhbiBiZSBwcm9jZXNzZWQgYnkgYSB2YWxpZGF0aW9uDQogICBzeXN0ZW0uDQoN CiAgIEluIGFub3RoZXIgc2NlbmFyaW8sIGFuIE9UQSAob3Zlci10aGUtYWlyKSBjcmVkZW50aWFs IHByb3Zpc2lvbmluZw0KICAgZ2F0ZXdheSB0aGF0IHByb3Zpc2lvbnMgY3JlZGVudGlhbHMgdG8g bW9iaWxlIHBob25lcyBtYXkgb2J0YWluDQogICBjcmVkZW50aWFscyBmcm9tIHRoZSBjcmVkZW50 aWFsIGlzc3VlciB1c2luZyBhbiBvbmxpbmUgcHJvdG9jb2wuICBUaGUNCiAgIGNyZWRlbnRpYWxz IGFyZSBkZWxpdmVyZWQgaW4gYSBzdGFuZGFyZCBmb3JtYXQgdGhhdCBjYW4gYmUgcHJvY2Vzc2Vk DQogICBieSB0aGUgT1RBIGNyZWRlbnRpYWwgcHJvdmlzaW9uaW5nIGdhdGV3YXkgYW5kIHN1YnNl cXVlbnRseSBzZW50IHRvDQogICB0aGUgZW5kLXVzZXIncyBtb2JpbGUgcGhvbmUuDQoNCjMuMi4z LiAgT25saW5lIHVwZGF0ZSBvZiBhbiBleGlzdGluZyBhdXRoZW50aWNhdGlvbiB0b2tlbiBjcmVk ZW50aWFsDQoNCiAgIFRoZSBlbmQtdXNlciBvciB0aGUgY3JlZGVudGlhbCBpc3N1ZXIgd2FudHMg dG8gdXBkYXRlIG9yIGNvbmZpZ3VyZSBhbg0KICAgZXhpc3RpbmcgY3JlZGVudGlhbCBpbiB0aGUg YXV0aGVudGljYXRpb24gdG9rZW4gYW5kIHJlcXVlc3RzIGENCiAgIHJlcGxhY2VtZW50IGNyZWRl bnRpYWwgY29udGFpbmVyLiAgVGhlIGNvbnRhaW5lciBtYXkgb3IgbWF5IG5vdA0KICAgaW5jbHVk ZSBhIG5ldyBzZWNyZXQga2V5IGFuZCBtYXkgaW5jbHVkZSBuZXcgb3IgdXBkYXRlZCBzZWNyZXQg a2V5DQogICBhdHRyaWJ1dGVzIHN1Y2ggYXMgYSBuZXcgY291bnRlciB2YWx1ZSBpbiBIT1RQIGNy ZWRlbnRpYWwgY2FzZSwgYSBuZXcNCiAgIGxvZ28sIGEgbW9kaWZpZWQgcmVzcG9uc2UgZm9ybWF0 IG9yIGxlbmd0aCwgYSBuZXcgZnJpZW5kbHkgbmFtZSwgZXRjLg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAg ICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCjQuICBSZXF1aXJlbWVudHMNCg0KICAgVGhpcyBzZWN0aW9u IG91dGxpbmVzIHRoZSBtb3N0IHJlbGV2YW50IHJlcXVpcmVtZW50cyB0aGF0IGFyZSB0aGUNCiAg IGJhc2lzIG9mIHRoaXMgd29yay4gIFNldmVyYWwgb2YgdGhlIHJlcXVpcmVtZW50cyB3ZXJlIGRl cml2ZWQgZnJvbQ0KICAgdXNlIGNhc2VzIGRlc2NyaWJlZCBhYm92ZS4NCg0KICAgUjE6ICAgVGhl IGZvcm1hdCBNVVNUIHN1cHBvcnQgdHJhbnNwb3J0IG9mIG11bHRpcGxlIHR5cGVzIG9mDQogICAg ICAgICBzeW1tZXRyaWMga2V5IGNyZWRlbnRpYWxzIGluY2x1ZGluZyBIT1RQLCBvdGhlciBPVFAs IGNoYWxsZW5nZS0NCiAgICAgICAgIHJlc3BvbnNlLCBldGMuDQoNCiAgIFIyOiAgIFRoZSBmb3Jt YXQgTVVTVCBoYW5kbGUgdGhlIHN5bW1ldHJpYyBrZXkgaXRzZWxmIGFzIHdlbGwgb2YNCiAgICAg ICAgIGF0dHJpYnV0ZXMgdGhhdCBhcmUgdHlwaWNhbGx5IGFzc29jaWF0ZWQgd2l0aCBzeW1tZXRy aWMga2V5cy4NCiAgICAgICAgIFNvbWUgb2YgdGhlc2UgYXR0cmlidXRlcyBtYXkgYmUNCg0KICAg ICAgICAgKiAgVW5pcXVlIEtleSBJZGVudGlmaWVyDQoNCiAgICAgICAgICogIElzc3VlciBpbmZv cm1hdGlvbg0KDQogICAgICAgICAqICBBbGdvcml0aG0gSUQNCg0KICAgICAgICAgKiAgQWxnb3Jp dGhtIG1vZGUNCg0KICAgICAgICAgKiAgSXNzdWVyIE5hbWUNCg0KICAgICAgICAgKiAgSXNzdWVy IGxvZ28NCg0KICAgICAgICAgKiAgQ3JlZGVudGlhbCBmcmllbmRseSBuYW1lDQoNCiAgICAgICAg ICogIEV2ZW50IGNvdW50ZXIgdmFsdWUgKG1vdmluZyBmYWN0b3IgZm9yIE9UUCBhbGdvcml0aG1z KQ0KDQogICAgICAgICAqICBUaW1lIHZhbHVlDQoNCiAgIFIzOiAgIFRoZSBmb3JtYXQgU0hPVUxE IHN1cHBvcnQgYm90aCBvZmZsaW5lIGFuZCBvbmxpbmUgc2NlbmFyaW9zLg0KICAgICAgICAgVGhh dCBpcyBpdCBzaG91bGQgYmUgc2VyaWFsaXphYmxlIHRvIGEgZmlsZSBhcyB3ZWxsIGFzIGl0DQog ICAgICAgICBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoaXMgZm9ybWF0IGluIG9ubGluZSBw cm92aXNpb25pbmcNCiAgICAgICAgIHByb3RvY29scw0KDQogICBSNDogICBUaGUgZm9ybWF0IFNI T1VMRCBhbGxvdyBidWxrIHJlcHJlc2VudGF0aW9uIG9mIHN5bW1ldHJpYyBrZXkNCiAgICAgICAg IGNyZWRlbnRpYWxzLg0KDQogICBSNTogICBUaGUgZm9ybWF0IFNIT1VMRCBiZSBwb3J0YWJsZSB0 byB2YXJpb3VzIHBsYXRmb3Jtcy4NCiAgICAgICAgIEZ1cnRoZXJtb3JlLCBpdCBTSE9VTEQgYmUg Y29tcHV0YXRpb25hbGx5IGVmZmljaWVudCB0byBwcm9jZXNzLg0KDQogICBSNjogICBUaGUgZm9y bWF0IE1VU1QgcHJvdmlkZSBhcHByb3ByaWF0ZSBsZXZlbCBvZiBzZWN1cml0eSBpbiB0ZXJtcw0K ICAgICAgICAgb2YgZGF0YSBlbmNyeXB0aW9uIGFuZCBkYXRhIGludGVncml0eS4NCg0KDQoNCg0K DQoNCkhveWVyLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1t ZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgUjc6ICAgRm9y IG9ubGluZSBzY2VuYXJpb3MgdGhlIGZvcm1hdCBTSE9VTEQgTk9UIHJlbHkgb24gdHJhbnNwb3J0 DQogICAgICAgICBsZXZlbCBzZWN1cml0eSAoZS5nLiwgU1NML1RMUykgZm9yIGNvcmUgc2VjdXJp dHkgcmVxdWlyZW1lbnRzLg0KDQogICBSODogICBUaGUgZm9ybWF0IFNIT1VMRCBiZSBleHRlbnNp YmxlLiAgSXQgU0hPVUxEIGVuYWJsZSBleHRlbnNpb24NCiAgICAgICAgIHBvaW50cyBhbGxvd2lu ZyB2ZW5kb3JzIHRvIHNwZWNpZnkgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIGluIHRoZQ0KICAgICAg ICAgZnV0dXJlLg0KDQogICBSOTogICBUaGUgZm9ybWF0IFNIT1VMRCBhbGxvdyBmb3IgZGlzdHJp YnV0aW9uIG9mIGtleSBkZXJpdmF0aW9uIGRhdGENCiAgICAgICAgIHdpdGhvdXQgdGhlIGFjdHVh bCBzeW1tZXRyaWMga2V5IGl0c2VsZi4gIFRoaXMgaXMgdG8gc3VwcG9ydA0KICAgICAgICAgc3lt bWV0cmljIGtleSBtYW5hZ2VtZW50IHNjaGVtZXMgdGhhdCByZWx5IG9uIGtleSBkZXJpdmF0aW9u DQogICAgICAgICBhbGdvcml0aG1zIGJhc2VkIG9uIGEgcHJlLXBsYWNlZCBtYXN0ZXIga2V5LiAg VGhlIGtleQ0KICAgICAgICAgZGVyaXZhdGlvbiBkYXRhIHR5cGljYWxseSBjb25zaXN0cyBvZiBh IHJlZmVyZW5jZSB0byB0aGUga2V5LA0KICAgICAgICAgcmF0aGVyIHRoYW4gdGhlIGtleSB2YWx1 ZSBpdHNlbGYuDQoNCiAgIFIxMDogIFRoZSBmb3JtYXQgU0hPVUxEIGFsbG93IGZvciBhZGRpdGlv bmFsIGxpZmVjeWNsZSBtYW5hZ2VtZW50DQogICAgICAgICBvcGVyYXRpb25zIHN1Y2ggYXMgY291 bnRlciByZXN5bmNocm9uaXphdGlvbi4gIFN1Y2ggcHJvY2Vzc2VzDQogICAgICAgICByZXF1aXJl IGNvbmZpZGVudGlhbGl0eSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLCB0aHVzIGNvdWxkDQog ICAgICAgICB1c2UgYSBjb21tb24gc2VjdXJlIGNvbnRhaW5lciBmb3JtYXQsIHdpdGhvdXQgdGhl IHRyYW5zZmVyIG9mDQogICAgICAgICBrZXkgbWF0ZXJpYWwuDQoNCiAgIFIxMTogIFRoZSBmb3Jt YXQgTVVTVCBzdXBwb3J0IHRoZSB1c2Ugb2YgcHJlLXNoYXJlZCBzeW1tZXRyaWMga2V5cyB0bw0K ICAgICAgICAgZW5zdXJlIGNvbmZpZGVudGlhbGl0eSBvZiBzZW5zaXRpdmUgZGF0YSBlbGVtZW50 cy4NCg0KICAgUjEyOiAgVGhlIGZvcm1hdCBNVVNUIHN1cHBvcnQgYSBwYXNzd29yZC1iYXNlZCBl bmNyeXB0aW9uIChQQkUpDQogICAgICAgICBbUEtDUzVdIHNjaGVtZSB0byBlbnN1cmUgc2VjdXJp dHkgb2Ygc2Vuc2l0aXZlIGRhdGEgZWxlbWVudHMuDQogICAgICAgICBUaGlzIGlzIGEgd2lkZWx5 IHVzZWQgbWV0aG9kIGZvciB2YXJpb3VzIHByb3Zpc2lvbmluZw0KICAgICAgICAgc2NlbmFyaW9z Lg0KDQogICBSMTM6ICBUaGUgZm9ybWF0IFNIT1VMRCBzdXBwb3J0IGFzeW1tZXRyaWMgZW5jcnlw dGlvbiBhbGdvcml0aG1zIHN1Y2gNCiAgICAgICAgIGFzIFJTQSB0byBlbnN1cmUgZW5kLXRvLWVu ZCBzZWN1cml0eSBvZiBzZW5zaXRpdmUgZGF0YQ0KICAgICAgICAgZWxlbWVudHMuICBUaGlzIGlz IHRvIHN1cHBvcnQgc2NlbmFyaW9zIHdoZXJlIGEgcHJlLXNldCBzaGFyZWQNCiAgICAgICAgIGVu Y3J5cHRpb24ga2V5IGlzIGRpZmZpY3VsdCB0byB1c2UuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkhveWVyLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDks IDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQ b3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0K NS4gIFN5bW1ldHJpYyBLZXkgQXR0cmlidXRlcw0KDQogICBUaGUgc3ltbWV0cmljIGtleSBpbmNs dWRlcyBhIG51bWJlciBvZiBkYXRhIGF0dHJpYnV0ZXMgdGhhdCBkZWZpbmUNCiAgIHRoZSB0eXBl IG9mIHRoZSBrZXkgaXRzIHVzYWdlIGFuZCBhc3NvY2lhdGVkIG1ldGEtaW5mb3JtYXRpb24NCiAg IHJlcXVpcmVkIGR1cmluZyB0aGUgcHJvdmlzaW9uaW5nLCBjb25maWd1cmF0aW9uLCBhY2Nlc3Mg b3IgdXNhZ2UgaW4NCiAgIHRoZSBob3N0IGRldmljZS4NCg0KNS4xLiAgQ29tbW9uIEF0dHJpYnV0 ZXMNCg0KNS4xLjEuICBEYXRhIChPUFRJT05BTCkNCg0KICAgRGVmaW5lcyB0aGUgZGF0YSBhdHRy aWJ1dGVzIG9mIHRoZSBzeW1tZXRyaWMga2V5LiAgRWFjaCBpcyBhIG5hbWUNCiAgIHZhbHVlIHBh aXIgd2hpY2ggaGFzIGJvdGggYSBiYXNlNjQgZW5jb2RlZCB2YWx1ZSBhbmQgYSBiYXNlIDY0DQog ICBlbmNvZGVkIFZhbHVlRGlnZXN0LiAgVGhlIHZhbHVlIGNhbiBiZSBlbmNyeXB0ZWQuICBJZiB0 aGUgY29udGFpbmVyDQogICBoYXMgYmVlbiBlbmNyeXB0ZWQgdGhlIFZhbHVlRGlnZXN0IE1VU1Qg YmUgcG9wdWxhdGVkIHdpdGggdGhlIGRpZ2VzdA0KICAgb2YgdGhlIHVuZW5jcnlwdGVkIHZhbHVl Lg0KDQogICBUaGlzIGlzIGFsc28gd2hlcmUgdGhlIGtleSB2YWx1ZSBpcyBoZWxkLCB0aGVyZWZv cmUgdGhlIGZvbGxvd2luZw0KICAgbGlzdCBvZiBhdHRyaWJ1dGUgbmFtZXMgaGF2ZSBiZWVuIHJl c2VydmVkOg0KDQogICAgICBTRUNSRVQ6IHRoZSBzaGFyZWQgc2VjcmV0IGtleSB2YWx1ZSBpbiBi aW5hcnksIGJhc2U2NCBlbmNvZGVkDQoNCiAgICAgIENPVU5URVI6IHRoZSBldmVudCBjb3VudGVy IGZvciBldmVudCBiYXNlZCBPVFAgYWxnb3JpdGhtcy4gOCBieXRlcw0KICAgICAgdW5zaWduZWQg aW50ZWdlciBpbiBiaWcgZW5kaWFuIChpLmUuIG5ldHdvcmsgYnl0ZSBvcmRlcikgZm9ybQ0KICAg ICAgYmFzZTY0IGVuY29kZWQNCg0KICAgICAgVElNRTogdGhlIHRpbWUgZm9yIHRpbWUgYmFzZWQg T1RQIGFsZ29yaXRobXMuIDggYnl0ZXMgdW5zaWduZWQNCiAgICAgIGludGVnZXIgaW4gYmlnIGVu ZGlhbiAoaS5lLiBuZXR3b3JrIGJ5dGUgb3JkZXIpIGZvcm0gYmFzZTY0DQogICAgICBlbmNvZGVk IChOdW1iZXIgb2Ygc2Vjb25kcyBzaW5jZSAxOTcwKQ0KDQogICAgICBUSU1FX0lOVEVSVkFMOiB0 aGUgdGltZSBpbnRlcnZhbCB2YWx1ZSBmb3IgdGltZSBiYXNlZCBPVFANCiAgICAgIGFsZ29yaXRo bXMuIDggYnl0ZXMgdW5zaWduZWQgaW50ZWdlciBpbiBiaWcgZW5kaWFuIChpLmUuIG5ldHdvcmsN CiAgICAgIGJ5dGUgb3JkZXIpIGZvcm0gYmFzZTY0IGVuY29kZWQuDQoNCiAgICAgIFRJTUVfRFJJ RlQ6IHRoZSBkZXZpY2UgY2xvY2sgZHJpZnQgdmFsdWUgZm9yIHRpbWUgYmFzZWQgT1RQDQogICAg ICBhbGdvcml0aG1zLiAgVGhlIHZhbHVlIGluZGljYXRlcyBudW1iZXIgb2Ygc2Vjb25kcyB0aGF0 IHRoZSBkZXZpY2UNCiAgICAgIGNsb2NrIG1heSBkcmlmdCBlYWNoIGRheS4gMiBieXRlcyB1bnNp Z25lZCBpbnRlZ2VyIGluIGJpZyBlbmRpYW4NCiAgICAgIChpLmUuIG5ldHdvcmsgYnl0ZSBvcmRl cikgZm9ybSBiYXNlNjQgZW5jb2RlZC4NCg0KNS4xLjIuICBLZXlBbGdvcml0aG0gKE1BTkRBVE9S WSkNCg0KICAgRGVmaW5lcyB0aGUgdHlwZSBvZiBhbGdvcml0aG0gb2YgdGhlIHNlY3JldCBrZXku ICBUaGUgZm9sbG93aW5nDQogICBhbGdvcml0aG0gVVJJcyBhcmUgYW1vbmcgdGhlIGRlZmF1bHQg c3VwcG9ydCBsaXN0Lg0KDQogICBvICBodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyN0 cmlwbGVkZXMtY2JjDQoNCiAgIG8gIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2Fl czEyOC1jYmMNCg0KDQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg OSwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg IFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0K DQogICBvICBodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMxOTItY2JjDQoNCiAg IG8gIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2FlczI1Ni1jYmMNCg0KICAgbyAg aHR0cDovL3d3dy5pZXRmLm9yZy9rZXlwcm92L3Bza2MjaG90cA0KDQo1LjEuMi4xLiAgT1RQIEtl eSBBbGdvcml0aG0gSWRlbnRpZmllcnMNCg0KICAgT1RQIGtleSBhbGdvcml0aG0gVVJJcyBoYXZl IG5vdCBiZWVuIGRlZmluZWQgaW4gYSBjb21tb25seSBhdmFpbGFibGUNCiAgIHN0YW5kYXJkIHNw ZWNpZmljYXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGZvbGxvd2luZyBVUklzIGZv cg0KICAgdGhlIGtub3duIG9wZW4gc3RhbmRhcmQgT1RQIGFsZ29yaXRobXMuDQoNCjUuMS4yLjEu MS4gIEhPVFANCg0KICAgU3RhbmRhcmQgZG9jdW1lbnQ6IFJGQzQyMjYNCg0KICAgSWRlbnRpZmll cjogaHR0cDovL3d3dy5pZXRmLm9yZy9rZXlwcm92L3Bza2MjaG90cA0KDQogICBOb3RlIHRoYXQg dGhlIGFjdHVhbCBVUkwgd2lsbCBiZSBmaW5hbGl6ZWQgb25jZSBhIFVSTCBmb3IgdGhpcw0KICAg ZG9jdW1lbnQgaXMgZGV0ZXJtaW5lZC4NCg0KNS4xLjIuMS4yLiAgT3RoZXIgT1RQIEFsZ29yaXRo bXMNCg0KICAgQW4gaW1wbGVtZW50YXRpb24gc2hvdWxkIHJlZmVyIHRvIHZlbmRvciBzdXBwbGll ZCBPVFAga2V5IGFsZ29yaXRobQ0KICAgVVJJcyBmb3IgcHJvcHJpZXRhcnkgYWxnb3JpdGhtcy4N Cg0KNS4xLjMuICBVc2FnZSAoTUFOREFUT1JZKQ0KDQogICBEZWZpbmVzIHRoZSBpbnRlbmRlZCB1 c2FnZSBvZiB0aGUga2V5IGFuZCBpcyBhIGNvbWJpbmF0aW9uIG9mIG9uZSBvcg0KICAgbW9yZSBv ZiB0aGUgZm9sbG93aW5nIChzZXQgdG8gdHJ1ZSk6DQoNCiAgICAgIE9UUDogdGhlIGtleSB3aWxs IGJlIHVzZWQgZm9yIE9UUCBnZW5lcmF0aW9uDQoNCiAgICAgIENSOiB0aGUga2V5IHdpbGwgYmUg dXNlZCBmb3IgQ2hhbGxlbmdlL1Jlc3BvbnNlIHB1cnBvc2VzDQoNCiAgICAgIEVuY3J5cHQ6IHRo ZSBrZXkgd2lsbCBiZSB1c2VkIGZvciBkYXRhIGVuY3J5cHRpb24gcHVycG9zZXMNCg0KICAgICAg U2lnbjogdGhlIGtleSB3aWxsIGJlIHVzZWQgdG8gZ2VuZXJhdGUgYSBzaWduYXR1cmUgb3Iga2V5 ZWQNCiAgICAgIGhhc2hpbmcgZm9yIGRhdGEgaW50ZWdyaXR5IG9yIGF1dGhlbnRpY2F0aW9uIHB1 cnBvc2VzLg0KDQogICAgICBVbmxvY2s6IHRoZSBrZXkgd2lsbCBiZSB1c2VkIGZvciBhbiBpbnZl cnNlIGNoYWxsZW5nZSByZXNwb25zZSBpbg0KICAgICAgdGhlIGNhc2UgYSB1c2VyIGhhcyBsb2Nr ZWQgdGhlIGRldmljZSBieSBlbnRlcmluZyBhIHdyb25nIFBJTiB0b28NCiAgICAgIG1hbnkgdGlt ZXMgKGZvciBkZXZpY2VzIHdpdGggUElOLWlucHV0IGNhcGFiaWxpdHkpDQoNCiAgIEFkZGl0aW9u YWwgYXR0cmlidXRlcyB0aGF0IGFyZSBzcGVjaWZpYyB0byB0aGUgdXNhZ2UgdHlwZSBNQVkgYmUN CiAgIHJlcXVpcmVkLiAgU2VjdGlvbiA2LjEgZGVzY3JpYmVzIE9UUCBhbmQgQ1Igc3BlY2lmaWMg YXR0cmlidXRlcy4NCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVz IE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAw Nw0KDQoNCjUuMS40LiAgS2V5SWQgKE1BTkRBVE9SWSkNCg0KICAgQSB1bmlxdWUgYW5kIGdsb2Jh bCBpZGVudGlmaWVyIG9mIHRoZSBzeW1tZXRyaWMga2V5LiAgVGhlIGlkZW50aWZpZXINCiAgIGlz IGRlZmluZWQgYXMgYSBzdHJpbmcgb2YgYWxwaGFudW1lcmljIGNoYXJhY3RlcnMuDQoNCjUuMS41 LiAgSXNzdWVyIChNQU5EQVRPUlkpDQoNCiAgIFRoZSBrZXkgaXNzdWVyIG5hbWUsIHRoaXMgaXMg bm9ybWFsbHkgdGhlIG5hbWUgb2YgdGhlIG9yZ2FuaXphdGlvbg0KICAgdGhhdCBpc3N1ZXMgdGhl IGtleSB0byB0aGUgZW5kIHVzZXIgb2YgdGhlIGtleS4gIEZvciBleGFtcGxlIE15QmFuaw0KICAg aXNzdWluZyBoYXJkd2FyZSB0b2tlbnMgdG8gdGhlaXIgcmV0YWlsIGJhbmtpbmcgdXNlcnMgJ015 QmFuaycgd291bGQNCiAgIGJlIHRoZSBpc3N1ZXIuICBUaGUgSXNzdWVyIGlzIGRlZmluZWQgYXMg YSBTdHJpbmcuDQoNCjUuMS42LiAgRnJpZW5kbHlOYW1lIChPUFRJT05BTCkNCg0KICAgVGhlIHVz ZXIgZnJpZW5kbHkgbmFtZSB0aGF0IGlzIGFzc2lnbmVkIHRvIHRoZSBzZWNyZXQga2V5IGZvciBl YXN5DQogICByZWZlcmVuY2UuICBUaGUgRnJpZW5kbHlOYW1lIGlzIGRlZmluZWQgYXMgYSBTdHJp bmcuDQoNCjUuMS43LiAgQWNjZXNzUnVsZXMgKE9QVElPTkFMKQ0KDQogICBEZWZpbmVzIGEgc2V0 IG9mIGFjY2VzcyBydWxlcyBhbmQgcG9saWNpZXMgZm9yIHRoZSBwcm90ZWN0aW9uIG9mIHRoZQ0K ICAga2V5IG9uIHRoZSBob3N0IERldmljZS4gIEN1cnJlbnRseSBvbmx5IHRoZSBVc2VyUElOIHBv bGljeSBpcw0KICAgZGVmaW5lZC4gIFRoZSBVc2VyUElOIHBvbGljeSBzcGVjaWZpZXMgd2hldGhl ciB0aGUgdXNlciBNVVNUIGVudGVyIGENCiAgIFBJTiAoZm9yIGRldmljZXMgd2l0aCBQSU4gaW5w dXQgY2FwYWJpbGl0eSkgaW4gb3JkZXIgdG8gdW5sb2NrIG9yDQogICBhdXRoZW50aWNhdGUgdG8g dGhlIGRldmljZSBob3N0aW5nIHRoZSBrZXkgY29udGFpbmVyLiAgVGhlIFVzZXJQSU4gaXMNCiAg IGRlZmluZWQgYXMgYSBCb29sZWFuIChUUlVFIG9yIEZBTFNFKS4gIFdoZW4gdGhlIHVzZXIgUElO IGlzIHJlcXVpcmVkLA0KICAgdGhlIHBvbGljeSBNVVNUIGJlIHNldCB0byBUUlVFLiAgSWYgdGhl IFVzZXJQSU4gaXMgTk9UIHByb3ZpZGVkLA0KICAgaW1wbGVtZW50YXRpb25zIFNIQUxMIGRlZmF1 bHQgdGhlIHZhbHVlIHRvIEZBTFNFLg0KDQo1LjEuOC4gIEVuY3J5cHRpb25NZXRob2QgKE1BTkRB VE9SWSB3aGVuICdEYXRhJyBhdHRyaWJ1dGUgaXMgZW5jcnlwdGVkKSkNCg0KICAgSWRlbnRpZmll cyB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gYW5kIHBvc3NpYmxlIHBhcmFtZXRlcnMgdXNlZCB0 bw0KICAgcHJvdGVjdCB0aGUgU2VjcmV0IEtleSBkYXRhIGluIHRoZSBjb250YWluZXIuICBUaGUg ZW5jcnlwdGlvbg0KICAgYWxnb3JpdGhtIFVSSSBjYW4gYmUgb25lIG9mIHRoZSBmb2xsb3dpbmcu DQoNCiAgIG8gIGh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29tL3JzYWxhYnMvcGtjcy9zY2hlbWFz L3BrY3MtNSNwYmVzMg0KDQogICBvICBodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyN0 cmlwbGVkZXMtY2JjDQoNCiAgIG8gIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2Fl czEyOC1jYmMNCg0KICAgbyAgaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjYWVzMTky LWNiYw0KDQogICBvICBodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNhZXMyNTYtY2Jj DQoNCiAgIG8gIGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3JzYS0xXzUNCg0KICAg byAgaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjcnNhLW9hZXAtbWdmMXANCg0KDQoN Cg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAg ICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1l dHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBvICBodHRwOi8v d3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy10cmlwbGVkZXMNCg0KICAgbyAgaHR0cDovL3d3 dy53My5vcmcvMjAwMS8wNC94bWxlbmMja3ctYWVzMTI4DQoNCiAgIG8gIGh0dHA6Ly93d3cudzMu b3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczI1Ng0KDQogICBvICBodHRwOi8vd3d3LnczLm9yZy8y MDAxLzA0L3htbGVuYyNrdy1hZXM1MTINCg0KICAgV2hlbiBhbiBQQkUgYWxnb3JpdGhtIGlzIHVz ZWQgZm9yIGVuY3J5cHRpb24sIHRoZSBVUkkNCiAgIGh0dHA6Ly93d3cucnNhc2VjdXJpdHkuY29t L3JzYWxhYnMvcGtjcy9zY2hlbWFzL3BrY3MtNSNwYmVzMiBhbmQgdGhlDQogICBlbmNyeXB0aW9u IGFsZ29yaXRobSBpbiBQQkVFbmNyeXB0aW9uUGFyYW1UeXBlIGRlZmluZXMgdGhlIGV4YWN0IFBC RQ0KICAga2V5IGRlcml2YXRpb24gYW5kIGVuY3J5cHRpb24gYWxnb3JpdGhtcy4NCg0KICAgV2hl biB0aGUgdmFsdWUgaXMgbm90IHByb3ZpZGVkLCBpbXBsZW1lbnRhdGlvbnMgU0hBTEwgZW5zdXJl IHRoZQ0KICAgcHJpdmFjeSBvZiB0aGUga2V5IGRhdGEgdGhyb3VnaCBvdGhlciBzdGFuZGFyZCBt ZWNoYW5pc21zIGUuZy4NCiAgIHRyYW5zcG9ydCBsZXZlbCBlbmNyeXB0aW9uLg0KDQogICBXaGVu IHRoZSBjb250YWluZXIgKHBheWxvYWQpIGNvbnRhaW5zIG1vcmUgdGhhbiBvbmUga2V5IGFuZA0K ICAgRW5jcnlwdGlvbk1ldGhvZCBpcyBzcGVjaWZpZWQsIHRoZSBzYW1lIGVuY3J5cHRpb24ga2V5 IE1VU1QgYmUgdXNlZA0KICAgdG8gZW5jcnlwdCBhbGwgdGhlIGtleSBkYXRhIGVsZW1lbnRzIGlu IHRoZSBjb250YWluZXIuDQoNCjUuMS45LiAgRGlnZXN0TWV0aG9kIChNQU5EQVRPUlkgd2hlbiBE aWdlc3QgaXMgcHJlc2VudCkNCg0KICAgSWRlbnRpZmllcyB0aGUgYWxnb3JpdGhtIGFuZCBwb3Nz aWJsZSBwYXJhbWV0ZXJzIHVzZWQgdG8gZ2VuZXJhdGUgYQ0KICAgZGlnZXN0IG9mIHRoZSB0aGUg U2VjcmV0IEtleSBkYXRhLiAgVGhlIGRpZ2VzdCBndWFyYW50ZWVzIHRoZQ0KICAgaW50ZWdyaXR5 IGFuZCB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBrZXkgZGF0YS4NCg0KICAgU2VlIFNlY3Rpb24g Ni4xLjggZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gRGlnZXN0IGRhdGEgdmFsdWUgdHlwZS4NCg0K NS4xLjEwLiAgT1RQIGFuZCBDUiBzcGVjaWZpYyBBdHRyaWJ1dGVzIChPUFRJT05BTCkNCg0KICAg V2hlbiB0aGUga2V5IHVzYWdlIGlzIHNldCB0byBPVFAgb3IgQ1IsIGFkZGl0aW9uYWwgYXR0cmli dXRlcyBNVVNUIGJlDQogICBwcm92aWRlZCB0byBzdXBwb3J0IHRoZSBPVFAgYW5kL29yIHRoZSBy ZXNwb25zZSBjb21wdXRhdGlvbiBhcw0KICAgcmVxdWlyZWQgYnkgdGhlIHVuZGVybHlpbmcgYWxn b3JpdGhtIGFuZCB0byBjdXN0b21pemUgb3IgY29uZmlndXJlDQogICB0aGUgb3V0Y29tZSBvZiB0 aGUgY29tcHV0YXRpb24gKGZvcm1hdCwgbGVuZ3RoIGFuZCB1c2FnZSBtb2RlcykuDQoNCjUuMS4x MC4xLiAgQ2hhbGxlbmdlRm9ybWF0IChNQU5EQVRPUlkpDQoNCiAgIFRoZSBDaGFsbGVuZ2VGb3Jt YXQgYXR0cmlidXRlIGRlZmluZXMgdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUNCiAgIGNoYWxs ZW5nZSBpbiBhIENSIHVzYWdlIHNjZW5hcmlvLiAgVGhlIENoYWxsZW5nZSBhdHRyaWJ1dGUgaXMg ZGVmaW5lZA0KICAgYnkgdGhlIGZvbGxvd2luZyBzdWItYXR0cmlidXRlczoNCg0KICAgMS4gIEZv cm1hdCAoTUFOREFUT1JZKQ0KDQogICAgICAgICAgRGVmaW5lcyB0aGUgZm9ybWF0IG9mIHRoZSBj aGFsbGVuZ2UgYWNjZXB0ZWQgYnkgdGhlIGRldmljZSBhbmQNCiAgICAgICAgICBNVVNUIGJlIG9u ZSBvZiB0aGUgdmFsdWVzIGRlZmluZWQgaW4gU2VjdGlvbiA2LjMNCg0KDQoNCg0KDQpIb3llciwg ZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBb UGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBD b250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIDIuICBDaGVja0RpZ2l0IChPUFRJ T05BTCkNCg0KICAgICAgICAgIERlZmluZXMgaWYgdGhlIGRldmljZSBuZWVkcyB0byBjaGVjayB0 aGUgYXBwZW5kZWQgTHVobiBjaGVjaw0KICAgICAgICAgIGRpZ2l0IGNvbnRhaW5lZCBpbiBhIHBy b3ZpZGVkIGNoYWxsZW5nZS4gIFRoaXMgaXMgb25seSB2YWxpZA0KICAgICAgICAgIGlmIHRoZSBG b3JtYXQgYXR0cmlidXRlIGlzICdERUNJTUFMJy4gIFZhbHVlIE1VU1QgYmU6DQoNCiAgICAgICAg ICAgICBUUlVFIGRldmljZSB3aWxsIGNoZWNrIHRoZSBhcHBlbmRlZCBMdWhuIGNoZWNrIGRpZ2l0 IGluIGENCiAgICAgICAgICAgICBwcm92aWRlZCBjaGFsbGVuZ2UNCg0KICAgICAgICAgICAgIEZB TFNFIGRldmljZSB3aWxsIG5vdCBjaGVjayBhcHBlbmRlZCBMdWhuIGNoZWNrIGRpZ2l0IGluDQog ICAgICAgICAgICAgY2hhbGxlbmdlDQoNCiAgIDMuICBNaW4gKE1BTkRBVE9SWSkNCg0KICAgICAg ICAgIERlZmluZXMgdGhlIG1pbmltdW0gc2l6ZSBvZiB0aGUgY2hhbGxlbmdlIGFjY2VwdGVkIGJ5 IHRoZQ0KICAgICAgICAgIGRldmljZSBmb3IgQ1IgbW9kZS4NCg0KICAgICAgICAgIElmIHRoZSBG b3JtYXQgYXR0cmlidXRlIGlzICdERUNJTUFMJywgJ0hFWEFERUNJTUFMJyBvcg0KICAgICAgICAg ICdBTFBIQU5VTUVSSUMnIHRoaXMgdmFsdWUgaW5kaWNhdGVzIHRoZSBtaW5pbXVtIG51bWJlciBv Zg0KICAgICAgICAgIGRpZ2l0cy9jaGFyYWN0ZXJzLg0KDQogICAgICAgICAgSWYgdGhlIEZvcm1h dCBhdHRyaWJ1dGUgaXMgJ0JBU0U2NCcgb3IgJ0JJTkFSWScsIHRoaXMgdmFsdWUNCiAgICAgICAg ICBpbmRpY2F0ZXMgdGhlIG1pbmltdW0gbnVtYmVyIG9mIGJ5dGVzIG9mIHRoZSB1bmVuY29kZWQg dmFsdWUuDQoNCiAgICAgICAgICBWYWx1ZSBNVVNUIGJlOg0KDQoNCg0KICAgICAgICAgICAgIFVu c2lnbmVkIGludGVnZXIuDQoNCiAgIDQuICBNYXggKE1BTkRBVE9SWSkNCg0KICAgICAgICAgIERl ZmluZXMgdGhlIG1heGltdW0gc2l6ZSBvZiB0aGUgY2hhbGxlbmdlIGFjY2VwdGVkIGJ5IHRoZQ0K ICAgICAgICAgIGRldmljZSBmb3IgQ1IgbW9kZS4NCg0KICAgICAgICAgIElmIHRoZSBGb3JtYXQg YXR0cmlidXRlIGlzICdERUNJTUFMJywgJ0hFWEFERUNJTUFMJyBvcg0KICAgICAgICAgICdBTFBI QU5VTUVSSUMnIHRoaXMgdmFsdWUgaW5kaWNhdGVzIHRoZSBtYXhpbXVtIG51bWJlciBvZg0KICAg ICAgICAgIGRpZ2l0cy9jaGFyYWN0ZXJzLg0KDQogICAgICAgICAgSWYgdGhlIEZvcm1hdCBhdHRy aWJ1dGUgaXMgJ0JBU0U2NCcgb3IgJ0JJTkFSWScsIHRoaXMgdmFsdWUNCiAgICAgICAgICBpbmRp Y2F0ZXMgdGhlIG1heGltdW0gbnVtYmVyIG9mIGJ5dGVzIG9mIHRoZSB1bmVuY29kZWQgdmFsdWUu DQoNCiAgICAgICAgICBWYWx1ZSBNVVNUIGJlOg0KDQoNCg0KDQoNCg0KDQoNCkhveWVyLCBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdl IDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRh aW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgICAgICAgICAgIFVuc2lnbmVkIGludGVn ZXIuDQoNCjUuMS4xMC4yLiAgUmVzcG9uc2VGb3JtYXQgKE1BTkRBVE9SWSkNCg0KICAgVGhlIFJl c3BvbnNlRm9ybWF0IGF0dHJpYnV0ZSBkZWZpbmVzIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhl DQogICByZXN1bHQgb2YgYSBjb21wdXRhdGlvbi4gIFRoaXMgZGVmaW5lcyB0aGUgZm9ybWF0IG9m IHRoZSBPVFAgb3Igb2YNCiAgIHRoZSByZXNwb25zZSB0byBhIGNoYWxsZW5nZS4gIFRoZSBSZXNw b25zZSBhdHRyaWJ1dGUgaXMgZGVmaW5lZCBieQ0KICAgdGhlIGZvbGxvd2luZyBzdWItYXR0cmli dXRlczoNCg0KICAgMS4gIEZvcm1hdCAoTUFOREFUT1JZKQ0KDQogICAgICAgICAgRGVmaW5lcyB0 aGUgZm9ybWF0IG9mIHRoZSByZXNwb25zZSBnZW5lcmF0ZWQgYnkgdGhlIGRldmljZSBhbmQNCiAg ICAgICAgICBNVVNUIGJlIG9uZSBvZiB0aGUgdmFsdWVzIGRlZmluZWQgaW4gU2VjdGlvbiA2LjMN Cg0KICAgMi4gIENoZWNrRGlnaXQgKE9QVElPTkFMKQ0KDQogICAgICAgICAgRGVmaW5lcyBpZiB0 aGUgZGV2aWNlIG5lZWRzIHRvIGFwcGVuZCBhIEx1aG4gY2hlY2sgZGlnaXQgdG8NCiAgICAgICAg ICB0aGUgcmVzcG9uc2UuICBUaGlzIGlzIG9ubHkgdmFsaWQgaWYgdGhlIEZvcm1hdCBhdHRyaWJ1 dGUgaXMNCiAgICAgICAgICAnREVDSU1BTCcuICBWYWx1ZSBNVVNUIGJlOg0KDQogICAgICAgICAg ICAgVFJVRSBkZXZpY2Ugd2lsbCBhcHBlbmQgYSBMdWhuIGNoZWNrIGRpZ2l0IHRvIHRoZSByZXNw b25zZS4NCg0KICAgICAgICAgICAgIEZBTFNFIGRldmljZSB3aWxsIG5vdCBhcHBlbmQgYSBMdWhu IGNoZWNrIGRpZ2l0IHRvIHRoZQ0KICAgICAgICAgICAgIHJlc3BvbnNlLg0KDQogICAzLiAgTGVu Z3RoIChNQU5EQVRPUlkpDQoNCiAgICAgICAgICBEZWZpbmVzIHRoZSBsZW5ndGggb2YgdGhlIHJl c3BvbnNlIGdlbmVyYXRlZCBieSB0aGUgZGV2aWNlLg0KDQogICAgICAgICAgSWYgdGhlIEZvcm1h dCBhdHRyaWJ1dGUgaXMgJ0RFQ0lNQUwnLCAnSEVYQURFQ0lNQUwnIG9yDQogICAgICAgICAgJ0FM UEhBTlVNRVJJQycgdGhpcyB2YWx1ZSBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBkaWdpdHMvDQog ICAgICAgICAgY2hhcmFjdGVycy4NCg0KICAgICAgICAgIElmIHRoZSBGb3JtYXQgYXR0cmlidXRl IGlzICdCQVNFNjQnIG9yICdCSU5BUlknLCB0aGlzIHZhbHVlDQogICAgICAgICAgaW5kaWNhdGVz IHRoZSBudW1iZXIgb2YgYnl0ZXMgb2YgdGhlIHVuZW5jb2RlZCB2YWx1ZS4NCg0KICAgICAgICAg IFZhbHVlIE1VU1QgYmU6DQoNCg0KDQogICAgICAgICAgICAgVW5zaWduZWQgaW50ZWdlci4NCg0K NS4xLjEwLjMuICBBcHBQcm9maWxlSWQgKE9QVElPTkFMKQ0KDQogICBEZWZpbmVzIHRoZSBhcHBs aWNhdGlvbiBwcm9maWxlIGlkIHJlbGF0ZWQgdG8gYXR0cmlidXRlcyBwcmVzZW50IG9uIGENCiAg IHNtYXJ0IGNhcmQgdGhhdCBoYXZlIGluZmx1ZW5jZSB3aGVuIGNvbXB1dGluZyBhIHJlc3BvbnNl LiAgQW4gZXhhbXBsZQ0KICAgY291bGQgYmUgYW4gRU1WIE1hc3RlckNhcmQgQ0FQIFtDQVBdIGFw cGxpY2F0aW9uIG9uIGEgY2FyZCB0aGF0DQogICBjb250YWlucyBhdHRyaWJ1dGVzIG9yIHVzZXMg Zml4ZWQgZGF0YSBmb3IgYSBzcGVjaWZpYyBiYXRjaCBvZiBjYXJkcw0KDQoNCg0KSG95ZXIsIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29u dGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBzdWNoIGFzOg0KDQogICAgICBJQUYg SW50ZXJuZXQgYXV0aGVudGljYXRpb24gZmxhZw0KDQogICAgICBDVk4gQ3J5cHRvZ3JhbSB2ZXJz aW9uIG51bWJlciwgZm9yIGV4YW1wbGUgKE1DSElQMiwgTUNISVA0LCBWSVNBDQogICAgICAxMywg VklTQTE0KQ0KDQogICAgICBBSVAgKEFwcGxpY2F0aW9uIEludGVyY2hhbmdlIFByb2ZpbGUpLCAy IGJ5dGVzDQoNCiAgICAgIFRWUiBUZXJtaW5hbCBWZXJpZmljYXRpb24gUmVzdWx0LCA1IGJ5dGVz DQoNCiAgICAgIENWUiBUaGUgY2FyZCB2ZXJpZmljYXRpb24gcmVzdWx0DQoNCiAgICAgIEFtb3Vu dE90aGVyDQoNCiAgICAgIFRyYW5zYWN0aW9uRGF0ZQ0KDQogICAgICBUZXJtaW5hbENvdW50cnlD b2RlDQoNCiAgICAgIFRyYW5zYWN0aW9uQ3VycmVuY3lDb2RlDQoNCiAgICAgIEFtb3VudEF1dGhv cmlzZWQNCg0KICAgICAgSUlQQg0KDQogICBUaGVzZSB2YWx1ZXMgYXJlIG5vdCBjb250YWluZWQg d2l0aGluIGF0dHJpYnV0ZXMgaW4gdGhlIGNvbnRhaW5lciBidXQNCiAgIGFyZSBzaGFyZWQgYmV0 d2VlbiB0aGUgbWFudWZhY3R1cmluZyBhbmQgdGhlIHZhbGlkYXRpb24gc2VydmljZQ0KICAgdGhy b3VnaCB0aGlzIHVuaXF1ZSBBcHBQcm9maWxlSWQuDQoNCjUuMS4xMS4gIExvZ28gKE9QVElPTkFM KQ0KDQogICBTcGVjaWZpZXMgdGhlIGxvZ28gaW1hZ2UgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3 aXRoIGEga2V5LiAgVGhlIGxvZ28NCiAgIHR5cGUgaXMgZGVmaW5lZCBpbiBhIHNlcGFyYXRlIHNj aGVtYSBmaWxlIHdpdGggbmFtZXNwYWNlDQogICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmtleXBy b3Y6bG9nbzoxLjAuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSG95ZXIsIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29u dGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQo2LiAgS2V5IGNvbnRhaW5lciBYTUwgc2No ZW1hIGRlZmluaXRpb25zDQoNCiAgIFRoZSBwb3J0YWJsZSBrZXkgY29udGFpbmVyIGlzIGRlZmlu ZWQgYnkgdGhlIGZvbGxvd2luZyBlbnRpdGllczoNCg0KICAgMS4gIEtleUNvbnRhaW5lciBlbnRp dHkNCg0KICAgMi4gIERldmljZSBlbnRpdHkNCg0KICAgMy4gIEtleSBlbnRpdHkNCg0KICAgNC4g IFVzZXIgZW50aXR5DQoNCiAgIEEgS2V5Q29udGFpbmVyIE1BWSBjb250YWluIG9uZSBvciBtb3Jl IERldmljZSBlbnRpdGllcy4gIEEgRGV2aWNlIE1BWQ0KICAgY29udGFpbiBvbmUgb3IgbW9yZSBL ZXkgZW50aXRpZXMgYW5kIG1heSBiZSBhc3NvY2lhdGVkIHRvIG9uZSBvciBtb3JlDQogICBVc2Vy IGVudGl0aWVzLg0KDQogICBUaGUgZmlndXJlIGJlbG93IGluZGljYXRlcyBhIHBvc3NpYmxlIHJl bGF0aW9uc2hpcCBkaWFncmFtIG9mIGENCiAgIGNvbnRhaW5lci4NCg0KICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgIHwgS2V5Q29udGFpbmVyICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgfCAgLS0tLS0tLS0tLS0tLS0tLS0tICAgLS0tLS0tLS0tLS0t LS0tLS0gIHwNCiAgIHwgIHwgRGV2aWNlIDEgICAgICAgfCAgIHwgRGV2aWNlIG4gICAgICB8ICB8 DQogICB8ICB8ICAgICAgICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfCAgfA0KICAgfCAg fCAgLS0tLS0tLS0tLS0tICB8ICAgfCAtLS0tLS0tLS0tLS0gIHwgIHwNCiAgIHwgIHwgIHwgS2V5 IDEgICAgfCAgfCAgIHwgfCBLZXkgbiAgICB8ICB8ICB8DQogICB8ICB8ICAtLS0tLS0tLS0tLS0g IHwgICB8IC0tLS0tLS0tLS0tLSAgfCAgfA0KICAgfCAgfCAgICAgICAgICAgICAgICB8ICAgfCAg ICAgICAgICAgICAgIHwgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgICB8ICB8DQogICB8ICB8ICAtLS0tLS0tLS0tLS0gIHwgICB8IC0tLS0tLS0tLS0tLSAgfCAg fA0KICAgfCAgfCAgfCBLZXkgbSAgICB8ICB8ICAgfCB8IEtleSBwICAgIHwgIHwgIHwNCiAgIHwg IHwgIC0tLS0tLS0tLS0tLSAgfCAgIHwgLS0tLS0tLS0tLS0tICB8ICB8DQogICB8ICAtLS0tLS0t LS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tLS0tLSAgfA0KICAgfCAgICAgIHwgICAgICAgICAg ICAgICAgICB8ICAgICAgICB8ICAgICAgIHwNCiAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAg fCAgICAgICAgfCAgICAgICB8DQogICB8ICAtLS0tLS0tLS0tICAgICAgICAtLS0tLS0tLS0tIC0t LS0tLS0tLS0gfA0KICAgfCAgfCBVc2VyIDEgfCAgICAgICAgfCBVc2VyIDEgfCB8IFVzZXIgbiB8 IHwNCiAgIHwgIC0tLS0tLS0tLS0gICAgICAgIC0tLS0tLS0tLS0gLS0tLS0tLS0tLSB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KNi4xLiAgWE1MIFNjaGVtYSBU eXBlcw0KDQogICBUaGUgZm9sbG93aW5nIHR5cGVzIGFyZSBkZWZpbmVkIHRvIHJlcHJlc2VudCB0 aGUgcG9ydGFibGUga2V5DQogICBjb250YWluZXIgZW50aXRpZXMgYW5kIGFzc29jaWF0ZWQgYXR0 cmlidXRlcy4NCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1h eSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0K DQoNCjYuMS4xLiAgS2V5VHlwZQ0KDQogICBUaGUgS2V5VHlwZSByZXByZXNlbnRzIHRoZSBrZXkg ZW50aXR5IGluIHRoZSBLZXlDb250YWluZXIuICBUaGUNCiAgIEtleVR5cGUgaXMgZGVmaW5lZCBh cyBmb2xsb3dzOg0KDQoNCiAgIDxjb21wbGV4VHlwZSBuYW1lPSJLZXlUeXBlIj4NCiAgICAgPHNl cXVlbmNlPg0KICAgICAgICA8ZWxlbWVudCBuYW1lPSJJc3N1ZXIiIHR5cGU9InN0cmluZyIvPg0K ICAgICAgICA8ZWxlbWVudCBuYW1lPSJVc2FnZSIgdHlwZT0icHNrYzpVc2FnZVR5cGUiLz4NCiAg ICAgICAgPGVsZW1lbnQgbmFtZT0iRnJpZW5kbHlOYW1lIiB0eXBlPSJzdHJpbmciIG1pbk9jY3Vy cz0iMCIvPg0KICAgICAgICA8ZWxlbWVudCBuYW1lPSJEYXRhIiB0eXBlPSJwc2tjOkRhdGFUeXBl IiBtaW5PY2N1cnM9IjAiDQogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICAg IDxlbGVtZW50IG5hbWU9IkFjY2Vzc1J1bGVzIiBtaW5PY2N1cnM9IjAiPg0KICAgICAgICAgICA8 Y29tcGxleFR5cGU+DQogICAgICAgICAgICAgPHNpbXBsZUNvbnRlbnQ+DQogICAgICAgICAgICAg PGV4dGVuc2lvbiBiYXNlPSJzdHJpbmciPg0KICAgICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1l PSJVc2VyUElOIiB0eXBlPSJib29sZWFuIg0KICAgICAgICAgICAgICAgZGVmYXVsdD0iZmFsc2Ui Lz4NCiAgICAgICAgICAgICA8L2V4dGVuc2lvbj4NCiAgICAgICAgICAgIDwvc2ltcGxlQ29udGVu dD4NCiAgICAgICAgICAgPC9jb21wbGV4VHlwZT4NCiAgICAgICAgPC9lbGVtZW50Pg0KICAgICAg ICA8ZWxlbWVudCBuYW1lPSJMb2dvIiB0eXBlPSJsb2dvOkxvZ29UeXBlIiBtaW5PY2N1cnM9IjAi Lz4NCiAgICAgICAgPGVsZW1lbnQgbmFtZT0iRXhwaXJ5IiB0eXBlPSJzdHJpbmciIG1pbk9jY3Vy cz0iMCIvPg0KICAgICA8L3NlcXVlbmNlPg0KICAgICA8YXR0cmlidXRlIG5hbWU9IktleUlkIiB0 eXBlPSJzdHJpbmciIHVzZT0icmVxdWlyZWQiLz4NCiAgICAgPGF0dHJpYnV0ZSBuYW1lPSJLZXlB bGdvcml0aG0iIHR5cGU9DQogICAgICJwc2tjOktleUFsZ29yaXRobVR5cGUiIHVzZT0icmVxdWly ZWQiLz4NCiAgIDwvY29tcGxleFR5cGU+DQoNCiAgIFRoZSBjb21wb25lbnRzIG9mIHRoZSBLZXlU eXBlIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5ncyAoc2VlDQogICBTZWN0aW9uIDUgZm9yIGZ1 cnRoZXIgaW5mb3JtYXRpb24pOg0KDQogICBvICA8VXNhZ2U+IG9mIHR5cGUgVXNhZ2VUeXBlIGRl ZmluZXMgdGhlIHVzYWdlIG9mIHRoZSBTZWNyZXQgS2V5LiBUaGUNCiAgICAgIFVzYWdlIGF0dHJp YnV0ZSBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEuMy4NCg0KICAgbyAgPElzc3Vlcj4gaWRl bnRpZmllcyB0aGUgaXNzdWVyIG9mIHRoZSBTZWNyZXQgS2V5LiBUaGUgSXNzdWVyDQogICAgICBh dHRyaWJ1dGUgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLjUuDQoNCiAgIG8gIDxGcmllbmRs eU5hbWU+IGlzIGEgdXNlciBmcmllbmRseSBuYW1lIHRoYXQgaXMgYXNzaWduZWQgdG8gdGhlDQog ICAgICBTZWNyZXQgS2V5IGZvciBlYXN5IHJlZmVyZW5jZS4NCg0KICAgbyAgPERhdGE+IGNvbnZl eXMgdGhlIGRhdGEgYXR0cmlidXRlcyAoZWcgdGhlIFNlY3JldCBLZXkpIGluIG5hbWUNCiAgICAg IChzdHJpbmcpIHZhbHVlIChiYXNlNjQgZW5jb2RlZCkgcGFpcnMuICBUaGUgdmFsdWUgY2FuIGJl DQogICAgICBlbmNyeXB0ZWQsIGluIHRoaXMgY2FzZSBhIGRpZ2VzdCBvZiB0aGUgbm9uLWVuY3J5 cHRlZCBkYXRhIGlzDQogICAgICBwcmVzZW50LiAgVGhlIDxEYXRhPiBjb21wb25lbnQgaXMgZnVy dGhlciBkZXNjcmliZWQgYmVsb3cuDQoNCg0KDQoNCkhveWVyLCBldCBhbC4gICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBOb3Zl bWJlciAyMDA3DQoNCg0KICAgbyAgPEFjY2Vzc1J1bGVzPiBEZWZpbmVzIHRoZSBydWxlcyBmb3Ig YWNjZXNzaW5nIHRoZSBjcmVkZW50aWFsIG9uDQogICAgICB0aGUgZGV2aWNlIGUuZy4gYSBwYXNz d29yZCBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSB1c2VyIHRvIHZpZXcNCiAgICAgIGNyZWRlbnRp YWwgaW5mbyBvciB1c2UgdGhlIGNyZWRlbnRpYWwgdG8gZ2VuZXJhdGUgYW4gT1RQIHJlc3BvbnNl DQoNCiAgIG8gIEtleUlkIGlzIGEgZ2xvYmFsIGlkZW50aWZpZXIgb2YgdGhlIFNlY3JldCBLZXku IFNlZSBTZWN0aW9uIDUuMS40Lg0KDQogICBvICBLZXlBbGdvcml0aG0gZGVmaW5lcyB0aGUgYWxn b3JpdGhtIHVzZWQgd2l0aCB0aGUgU2VjcmV0IEtleS4gVGhlDQogICAgICB0eXBlIHZhbHVlcyBh cmUgZGVmaW5lZCBpbiBTZWN0aW9uIDYuMi4NCg0KICAgbyAgTG9nbyBvZiB0eXBlIExvZ29UeXBl IGFzc29jaWF0ZXMgZGlzcGxheSBsb2dvcyB3aXRoIHRoaXMgU2VjcmV0DQogICAgICBLZXkNCg0K ICAgbyAgRXhwaXJ5IGRlZmluZXMgdGhlIGV4cGlyeSBkYXRlIG9mIHRoZSBTZWNyZXQgS2V5IGlu IGZvcm1hdCBERC9NTS8NCiAgICAgIFlZWVkNCg0KICAgVGhlIDxEYXRhPiBlbGVtZW50IGlzIG9m IHR5cGUgPERhdGFUeXBlPiBhbmQgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KDQoNCiAgIDxjb21w bGV4VHlwZSBuYW1lPSJEYXRhVHlwZSI+DQogICAgIDxzZXF1ZW5jZT4NCiAgICAgICA8ZWxlbWVu dCBuYW1lPSJWYWx1ZSIgdHlwZT0iYmFzZTY0QmluYXJ5Ii8+DQogICAgICAgPGVsZW1lbnQgbmFt ZT0iVmFsdWVEaWdlc3QiIHR5cGU9ImJhc2U2NEJpbmFyeSIgbWluT2NjdXJzPSIwIi8+DQogICAg ICAgPGF0dHJpYnV0ZSBuYW1lPSJOYW1lIiB0eXBlPSJzdHJpbmciIHVzZT0icmVxdWlyZWQiLz4N CiAgICAgPC9zZXF1ZW5jZT4NCiAgIDwvY29tcGxleFR5cGU+DQoNCiAgIFRoZSAnTmFtZScgYXR0 cmlidXRlIGRlZmluZXMgdGhlIG5hbWUgb2YgdGhlIG5hbWUtdmFsdWUgcGFpciwgdGhlDQogICBm b2xsb3dpbmcgbGlzdCBvZiBhdHRyaWJ1dGUgbmFtZXMgaGF2ZSBiZWVuIHJlc2VydmVkOg0KDQog ICAgICBTRUNSRVQ6IHRoZSBrZXkga2V5IHZhbHVlIGluIGJpbmFyeSwgYmFzZTY0IGVuY29kZWQN Cg0KICAgICAgQ09VTlRFUjogdGhlIGV2ZW50IGNvdW50ZXIgZm9yIGV2ZW50IGJhc2VkIE9UUCBh bGdvcml0aG1zLiA4IGJ5dGVzDQogICAgICB1bnNpZ25lZCBpbnRlZ2VyIGluIGJpZyBlbmRpYW4g KGkuZS4gbmV0d29yayBieXRlIG9yZGVyKSBmb3JtDQogICAgICBiYXNlNjQgZW5jb2RlZA0KDQog ICAgICBUSU1FOiB0aGUgdGltZSBmb3IgdGltZSBiYXNlZCBPVFAgYWxnb3JpdGhtcy4gOCBieXRl cyB1bnNpZ25lZA0KICAgICAgaW50ZWdlciBpbiBiaWcgZW5kaWFuIChpLmUuIG5ldHdvcmsgYnl0 ZSBvcmRlcikgZm9ybSBiYXNlNjQNCiAgICAgIGVuY29kZWQgKE51bWJlciBvZiBzZWNvbmRzIHNp bmNlIDE5NzApDQoNCiAgICAgIFRJTUVfSU5URVJWQUw6IHRoZSB0aW1lIGludGVydmFsIHZhbHVl IGZvciB0aW1lIGJhc2VkIE9UUA0KICAgICAgYWxnb3JpdGhtcy4gOCBieXRlcyB1bnNpZ25lZCBp bnRlZ2VyIGluIGJpZyBlbmRpYW4gKGkuZS4gbmV0d29yaw0KICAgICAgYnl0ZSBvcmRlcikgZm9y bSBiYXNlNjQgZW5jb2RlZC4NCg0KICAgVGhlIDxWYWx1ZT4gZWxlbWVudCBpbiB0aGUgRGF0YVR5 cGUgY29udmV5cyB0aGUgdmFsdWUgb2YgdGhlIG5hbWUtDQogICB2YWx1ZSBwYWlyIGluIGJhc2Ug NjQgZW5jb2RpbmcuICBUaGUgdmFsdWUgTUFZIGJlIGVuY3J5cHRlZCBvciBpbg0KICAgY2xlYXIg dGV4dCBhcyBwZXIgdGhlIEVuY3J5cHRpb25NZXRob2QgZGF0YSBlbGVtZW50IGluIHRoZQ0KICAg S2V5Q29udGFpbmVyIChzZWUgU2VjdGlvbiA2LjEuNiBmb3IgZGV0YWlscyBhYm91dCBLZXlDb250 YWluZXJUeXBlKS4NCiAgIFdoZW4gdGhlIHZhbHVlIGlzIGVuY3J5cHRlZCwgdGhlIGRpZ2VzdCB2 YWx1ZSBpbiAnVmFsdWVEaWdlc3QnIE1VU1QNCg0KDQoNCkhveWVyLCBldCBhbC4gICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBO b3ZlbWJlciAyMDA3DQoNCg0KICAgYmUgcHJvdmlkZWQuICBUaGUgZGlnZXN0IE1VU1QgYmUgY2Fs Y3VsYXRlZCBvbiB0aGUgdW5lbmNyeXB0ZWQgdmFsdWUNCiAgIGFuZCBNVVNUIHVzZSB0aGUgRGln ZXN0IGFsZ29yaXRobXMgc3BlY2lmaWVkIGluIERpZ2VzdE1ldGhvZFR5cGUNCiAgIGVsZW1lbnQg b2YgdGhlIEtleUNvbnRhaW5lci4gIFRoZSBNQUMga2V5IGZvciB0aGUgTUFDIGNhbGN1bGF0aW9u DQogICBzaG91bGQgdXNlIHRoZSBzYW1lIGtleSBhcyB0aGUgZW5jcnlwdGlvbiBrZXkgc3BlY2lm aWVkIGluIHRoZQ0KICAgRW5jcnlwdGlvbk1ldGhvZCB1bmxlc3MgYSBzZXBhcmF0ZSBNQUMga2V5 IGlzIHNwZWNpZmllZC4gIFdoZW4gUEJFDQogICBtZXRob2QgaXMgdXNlZCBmb3IgZW5jcnlwdGlv biwgYSBkaWZmZXJlbnQgcGFzc3dvcmQgaXMgcmVjb21tZW5kZWQNCiAgIGZvciB0aGUgTUFDIGtl eSBkZXJpdmF0aW9uLiAgV2hlbiB0aGUga2V5IGRhdGEgaXMgaW4gY2xlYXIgdGV4dCwgdGhlDQog ICBLZXlDb250YWluZXIgcGF5bG9hZCBzaWduYXR1cmUgTUFZIGJlIHVzZWQgdG8gY2hlY2sgdGhl IGludGVncml0eSBvZg0KICAgdGhlIGtleSBvY3RldHMuDQoNCjYuMS4yLiAgVXNhZ2VUeXBlDQoN CiAgIFRoZSBVc2FnZVR5cGUgZGVmaW5lcyB0aGUgdXNhZ2UgYXR0cmlidXRlIG9mIHRoZSBrZXkg ZW50aXR5LiAgVGhlDQogICBVc2FnZVR5cGUgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4 ICAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFi bGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIDxj b21wbGV4VHlwZSBuYW1lPSJVc2FnZVR5cGUiPg0KICAgICA8c2VxdWVuY2U+DQogICAgICAgPGVs ZW1lbnQgbmFtZT0iUmVzcG9uc2VGb3JtYXQiPg0KICAgICAgICAgPGNvbXBsZXhUeXBlPg0KICAg ICAgICAgICA8YXR0cmlidXRlIG5hbWU9IkZvcm1hdCIgdHlwZT0icHNrYzpWYWx1ZUZvcm1hdCIN CiAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0KICAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9 Ikxlbmd0aCIgdHlwZT0idW5zaWduZWRJbnQiDQogICAgICAgICAgIHVzZT0icmVxdWlyZWQiLz4N CiAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJDaGVja0RpZ2l0cyIgdHlwZT0iYm9vbGVhbiIN CiAgICAgICAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgICAgICAgIDwvY29tcGxleFR5cGU+DQog ICAgICAgPC9lbGVtZW50Pg0KICAgICAgIDxlbGVtZW50IG5hbWU9IkNoYWxsZW5nZUZvcm1hdCIg bWluT2NjdXJzPSIwIj4NCiAgICAgICAgIDxjb21wbGV4VHlwZT4NCiAgICAgICAgICAgPGF0dHJp YnV0ZSBuYW1lPSJGb3JtYXQiIHR5cGU9InBza2M6VmFsdWVGb3JtYXQiDQogICAgICAgICAgIHVz ZT0icmVxdWlyZWQiLz4NCiAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJNaW4iIHR5cGU9InVu c2lnbmVkSW50IiB1c2U9InJlcXVpcmVkIi8+DQogICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0i TWF4IiB0eXBlPSJ1bnNpZ25lZEludCIgdXNlPSJyZXF1aXJlZCIvPg0KICAgICAgICAgICA8YXR0 cmlidXRlIG5hbWU9IkNoZWNrRGlnaXRzIiB0eXBlPSJib29sZWFuIg0KICAgICAgICAgICBkZWZh dWx0PSJmYWxzZSIvPg0KICAgICAgICAgPC9jb21wbGV4VHlwZT4NCiAgICAgICA8L2VsZW1lbnQ+ DQogICAgICAgPGVsZW1lbnQgbmFtZT0iQXBwUHJvZmlsZUlkIiB0eXBlPSJzdHJpbmciIG1pbk9j Y3Vycz0iMCIvPg0KICAgICA8L3NlcXVlbmNlPg0KICAgICA8YXR0cmlidXRlIG5hbWU9Ik9UUCIg dHlwZT0iYm9vbGVhbiINCiAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgICAgPGF0dHJpYnV0ZSBu YW1lPSJDUiIgdHlwZT0iYm9vbGVhbiINCiAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgICAgPGF0 dHJpYnV0ZSBuYW1lPSJTaWduIiB0eXBlPSJib29sZWFuIiBkZWZhdWx0PSJmYWxzZSIvPg0KICAg ICA8YXR0cmlidXRlIG5hbWU9IkVuY3J5cHQiIHR5cGU9ImJvb2xlYW4iIGRlZmF1bHQ9ImZhbHNl Ii8+DQogICAgIDxhdHRyaWJ1dGUgbmFtZT0iVW5sb2NrIiB0eXBlPSJib29sZWFuIiBkZWZhdWx0 PSJmYWxzZSIvPg0KICAgPC9jb21wbGV4VHlwZT4NCg0KICAgVGhlIFVzYWdlVHlwZSBjb21wb25l bnRzIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5nczoNCg0KICAgbyAgPFJlc3BvbnNlRm9ybWF0 PiBob2xkcyB0aGUgYWxnb3JpdGhtIHJlc3BvbnNlIGF0dHJpYnV0ZXMuDQoNCiAgIG8gIDxDaGFs bGVuZ2VGb3JtYXQ+IGhvbGQgdGhlIGNoYWxsZW5nZSBhdHRyaWJ1dGVzIGluIENSIGJhc2VkDQog ICAgICBhbGdvcml0aG0gY29tcHV0YXRpb25zLg0KDQogICBvICA8QXBwUHJvZmlsZUlkPiBJcyB0 aGUgdW5pcXVlIHNoYXJlZCBpZGVudGlmaWVyIGZvciBvdXQgb2YgYmFuZA0KICAgICAgc2hhcmVk IGNvbW1vbiBwYXJhbWV0ZXJzLg0KDQo2LjEuMy4gIERldmljZVR5cGUNCg0KICAgVGhlIERldmlj ZVR5cGUgdHlwZSByZXByZXNlbnRzIHRoZSBEZXZpY2UgZW50aXR5IGluIHRoZSBDb250YWluZXIu ICBBDQogICBEZXZpY2UgTUFZIGJlIGJvdW5kIHRvIGEgdXNlciBhbmQgTUFZIGNvbnRhaW4gbW9y ZSB0aGFuIG9uZSBrZXlzLiAgSXQNCiAgIGlzIHJlY29tbWVuZGVkIHRoYXQgYSBrZXkgaXMgYm91 bmQgdG8gb25lIGFuZCBvbmx5IG9uZSBEZXZpY2UuDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAg ICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIFRoZSBEZXZpY2VUeXBlIGlzIGRlZmluZWQgYXMgZm9s bG93czoNCg0KDQogICA8Y29tcGxleFR5cGUgbmFtZT0iRGV2aWNlVHlwZSI+DQogICAgIDxzZXF1 ZW5jZT4NCiAgICAgICA8ZWxlbWVudCBuYW1lPSJEZXZpY2VJZCIgdHlwZT0icHNrYzpEZXZpY2VJ ZFR5cGUiDQogICAgICAgbWluT2NjdXJzPSIwIi8+DQogICAgICAgPGVsZW1lbnQgbmFtZT0iS2V5 IiB0eXBlPSJwc2tjOktleVR5cGUiDQogICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4NCiAg ICAgICA8ZWxlbWVudCBuYW1lPSJVc2VyIiB0eXBlPSJwc2tjOlVzZXJUeXBlIiBtaW5PY2N1cnM9 IjAiLz4NCiAgICAgPC9zZXF1ZW5jZT4NCiAgIDwvY29tcGxleFR5cGU+DQoNCiAgIFRoZSBjb21w b25lbnRzIG9mIHRoZSBEZXZpY2VUeXBlIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5nczoNCg0K ICAgbyAgPERldmljZUlkPiwgYSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGRldmljZSwgZGVm aW5lZCBieSB0aGUNCiAgICAgIERldmljZUlkIHR5cGUuDQoNCiAgIG8gIDxLZXk+LCByZXByZXNl bnRzIHRoZSBrZXkgZW50aXR5IGRlZmluZWQgYnkgdGhlIEtleVR5cGUuDQoNCiAgIG8gIDxVc2Vy Piwgb3B0aW9uYWxseSBpZGVudGlmaWVzIHRoZSBvd25lciBvciB0aGUgdXNlciBvZiB0aGUgRGV2 aWNlLA0KICAgICAgYXMgZGVmaW5lZCBieSB0aGUgVXNlclR5cGUgLg0KDQo2LjEuNC4gIERldmlj ZUlkVHlwZQ0KDQogICBUaGUgRGV2aWNlSWQgdHlwZSByZXByZXNlbnRzIHRoZSBpZGVudGlmeWlu ZyBjcml0ZXJpYSB0byB1bmlxdWVseQ0KICAgaWRlbnRpZnkgdGhlIGRldmljZSB0aGF0IGNvbnRh aW5zIHRoZSBhc3NvY2lhdGVkIGtleXMuICBTaW5jZSBkZXZpY2VzDQogICBjYW4gY29tZSBpbiBk aWZmZXJlbnQgZm9ybSBmYWN0b3JzIHN1Y2ggYXMgaGFyZHdhcmUgdG9rZW5zLA0KICAgc21hcnRj YXJkcywgc29mdCB0b2tlbnMgaW4gYSBtb2JpbGUgcGhvbmUgb3IgUEMgZXRjIHRoaXMgdHlwZSBh bGxvd3MNCiAgIGRpZmZlcmVudCBjcml0ZXJpYSB0byBiZSB1c2VkLiAgQ29tYmluZWQgdGhvdWdo IHRoZSBjcml0ZXJpYSBNVVNUDQogICB1bmlxdWVseSBpZGVudGlmeSB0aGUgZGV2aWNlLiAgRm9y IGV4YW1wbGUgZm9yIGhhcmR3YXJlIHRva2VucyB0aGUNCiAgIGNvbWJpbmF0aW9uIG9mIFNlcmlh bE5vIGFuZCBNYW51ZmFjdHVyZXIgd2lsbCB1bmlxdWVseSBpZGVudGlmeSBhDQogICBkZXZpY2Ug YnV0IG5vdCBTZXJpYWxObyBhbG9uZSBzaW5jZSB0d28gZGlmZmVyZW50IHRva2VuIG1hbnVmYWN0 dXJlcnMNCiAgIG1pZ2h0IGlzc3VlIGRldmljZXMgd2l0aCB0aGUgc2FtZSBzZXJpYWwgbnVtYmVy IChzaW1pbGFyIHRvIHRoZQ0KICAgSXNzdWVyRE4gYW5kIHNlcmlhbCBudW1iZXIgb2YgYSBjZXJ0 aWZpY2F0ZSkuICBGb3Iga2V5cyBob2xkIG9uDQogICBiYW5raW5nIGNhcmRzIHRoZSBpZGVudGlm aWNhdGlvbiBvZiB0aGUgZGV2aWNlIGlzIG9mdGVuIGRvbmUgdmlhIHRoZQ0KICAgUHJpbWFyeSBB Y2NvdW50IE51bWJlciAoUEFOLCB0aGUgYmlnIG51bWJlciBwcmludGVkIG9uIHRoZSBmcm9udCBv Zg0KICAgdGhlIGNhcmQpIGFuZCBhbiBleHBpcnkgZGF0ZSBvZiB0aGUgY2FyZC4gIERldmljZUlk IGlzIGFuIGV4dGVuc2libGUNCiAgIHR5cGUgdGhhdCBhbGxvd3MgYWxsIHRoZXNlIGRpZmZlcmVu dCB3YXlzIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGENCiAgIHNwZWNpZmljIGtleSBjb250YWluaW5n IGRldmljZS4NCg0KICAgVGhlIERldmljZUlkVHlwZSBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6DQoN Cg0KDQoNCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5 LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAg UG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoN CiAgIDxjb21wbGV4VHlwZSBuYW1lPSJEZXZpY2VJZFR5cGUiPg0KICAgIDxzZXF1ZW5jZT4NCiAg ICAgPGVsZW1lbnQgbmFtZT0iTWFudWZhY3R1cmVyIiB0eXBlPSJzdHJpbmciLz4NCiAgICAgPGVs ZW1lbnQgbmFtZT0iU2VyaWFsTm8iIHR5cGU9InN0cmluZyIvPg0KICAgICA8ZWxlbWVudCBuYW1l PSJNb2RlbCIgdHlwZT0ic3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgPGVsZW1lbnQgbmFt ZT0iSXNzdWVObyIgdHlwZT0ic3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgPGVsZW1lbnQg bmFtZT0iRXhwaXJ5IiB0eXBlPSJzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgIDwvc2VxdWVu Y2U+DQogICA8L2NvbXBsZXhUeXBlPg0KDQogICBUaGUgY29tcG9uZW50cyBvZiB0aGUgRGV2aWNl SWQgdHlwZSBoYXZlIHRoZSBmb2xsb3dpbmcgbWVhbmluZ3M6DQoNCiAgIG8gIDxNYW51ZmFjdHVy ZXI+LCB0aGUgbWFudWZhY3R1cmVyIG9mIHRoZSBkZXZpY2UuDQoNCiAgIG8gIDxNb2RlbD4sIHRo ZSBtb2RlbCBvZiB0aGUgZGV2aWNlIChlLmcgb25lLWJ1dHRvbi1IT1RQLXRva2VuLVYxKQ0KDQog ICBvICA8U2VyaWFsTm8+LCB0aGUgc2VyaWFsIG51bWJlciBvZiB0aGUgZGV2aWNlIG9yIHRoZSBQ QU4gKHByaW1hcnkNCiAgICAgIGFjY291bnQgbnVtYmVyKSBpbiBjYXNlIG9mIEVNViAoRXVyb3Bh eS1NYXN0ZXJDYXJkLVZpc2EpIHNtYXJ0DQogICAgICBjYXJkcy4NCg0KICAgbyAgPElzc3VlTm8+ LCB0aGUgaXNzdWUgbnVtYmVyIGluIGNhc2Ugb2Ygc21hcnQgY2FyZHMgd2l0aCB0aGUgc2FtZQ0K ICAgICAgUEFOLCBlcXVpdmFsZW50IHRvIGEgUFNOIChQQU4gU2VxdWVuY2UgTnVtYmVyKS4NCg0K ICAgbyAgPEV4cGlyeT4sIHRoZSBleHBpcnkgZGF0ZSBvZiBhIGRldmljZSAoc3VjaCBhcyB0aGUg b25lIG9uIGFuIEVNVg0KICAgICAgY2FyZCx1c2VkIHdoZW4gaXNzdWUgbnVtYmVycyBhcmUgbm90 IHByaW50ZWQgb24gY2FyZHMpLiAgSW4gZm9ybWF0DQogICAgICBERC9NTS9ZWVlZDQoNCjYuMS41 LiAgVXNlclR5cGUgVHlwZQ0KDQogICBUaGUgVXNlclR5cGUgcmVwcmVzZW50cyB0aGUgaWRlbnRp ZnlpbmcgY3JpdGVyaWEgdG8gdW5pcXVlbHkgaWRlbnRpZnkNCiAgIHRoZSB1c2VyIHdobyBpcyBi b3VuZCB0byB0aGlzIGRldmljZS4NCg0KICAgVGhlIFVzZXJUeXBlIGlzIGRlZmluZWQgYXMgZm9s bG93czoNCg0KDQogICA8Y29tcGxleFR5cGUgbmFtZT0iVXNlclR5cGUiPg0KICAgICA8c2VxdWVu Y2U+DQogICAgICAgPHNlcXVlbmNlPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0iVXNlcklkIiB0 eXBlPSJzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0iRmly c3ROYW1lIiB0eXBlPSJzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQg bmFtZT0iTGFzdE5hbWUiIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgIDwvc2VxdWVuY2U+DQogICAg ICAgPGVsZW1lbnQgbmFtZT0iT3JnIiB0eXBlPSJzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAg ICA8L3NlcXVlbmNlPg0KICAgPC9jb21wbGV4VHlwZT4NCg0KICAgVGhlIGNvbXBvbmVudHMgb2Yg dGhlIFVzZXJUeXBlIHR5cGUgaGF2ZSB0aGUgZm9sbG93aW5nIG1lYW5pbmdzOg0KDQoNCg0KDQpI b3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAg ICAgICBbUGFnZSAyNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmlj IEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIG8gIDxGaXJzdE5hbWU+ LCB1c2VyIGZpcnN0IG5hbWUuDQoNCiAgIG8gIDxMYXN0TmFtZT4sIHVzZXIgbGFzdCBuYW1lLg0K DQogICBvICA8VXNlcklkPiwgdXNlciBpZCAoVUlEKSBvciB1c2VyIG5hbWUuDQoNCiAgIG8gIDxP cmc+LCB1c2VyIG9yZ2FuaXphdGlvbiBuYW1lLg0KDQo2LjEuNi4gIEtleUNvbnRhaW5lclR5cGUN Cg0KICAgVGhlIEtleUNvbnRhaW5lclR5cGUgcmVwcmVzZW50cyB0aGUga2V5IGNvbnRhaW5lciBl bnRpdHkuICBBDQogICBDb250YWluZXIgTUFZIGNvbnRhaW4gbW9yZSB0aGFuIG9uZSBEZXZpY2Ug ZW50aXR5OyBlYWNoIERldmljZSBlbnRpdHkNCiAgIE1BWSBjb250YWluIG1vcmUgdGhhbiBvbmUg S2V5IGVudGl0eS4NCg0KICAgVGhlIEtleUNvbnRhaW5lclR5cGUgaXMgZGVmaW5lZCBhcyBmb2xs b3dzOg0KDQoNCiAgICA8Y29tcGxleFR5cGUgbmFtZT0iS2V5Q29udGFpbmVyVHlwZSI+DQogICAg ICA8c2VxdWVuY2U+DQogICAgICAgIDxlbGVtZW50IG5hbWU9IkVuY3J5cHRpb25NZXRob2QiIG1p bk9jY3Vycz0iMCI+DQogICAgICAgICAgPGNvbXBsZXhUeXBlPg0KICAgICAgICAgICAgPGNvbXBs ZXhDb250ZW50Pg0KICAgICAgICAgICAgICA8ZXh0ZW5zaW9uIGJhc2U9InBza2M6RW5jcnlwdGlv bk1ldGhvZFR5cGUiLz4NCiAgICAgICAgICAgIDwvY29tcGxleENvbnRlbnQ+DQogICAgICAgICAg PC9jb21wbGV4VHlwZT4NCiAgICAgICAgPC9lbGVtZW50Pg0KICAgICAgICA8ZWxlbWVudCBuYW1l PSJEaWdlc3RNZXRob2QiPg0KICAgICAgICAgIDxjb21wbGV4VHlwZT4NCiAgICAgICAgICAgIDxj b21wbGV4Q29udGVudD4NCiAgICAgICAgICAgICAgPGV4dGVuc2lvbiBiYXNlPSJwc2tjOkRpZ2Vz dE1ldGhvZFR5cGUiLz4NCiAgICAgICAgICAgIDwvY29tcGxleENvbnRlbnQ+DQogICAgICAgICAg PC9jb21wbGV4VHlwZT4NCiAgICAgICAgPC9lbGVtZW50Pg0KICAgICAgICA8ZWxlbWVudCBuYW1l PSJEZXZpY2UiIHR5cGU9InBza2M6RGV2aWNlVHlwZSINCiAgICAgICAgICAgICAgICAgbWF4T2Nj dXJzPSJ1bmJvdW5kZWQiLz4NCiAgICAgICAgPGVsZW1lbnQgbmFtZT0iU2lnbmF0dXJlIiB0eXBl PSJkczpTaWduYXR1cmVUeXBlIg0KICAgICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NCiAg ICAgIDwvc2VxdWVuY2U+DQogICAgICA8YXR0cmlidXRlIG5hbWU9IlZlcnNpb24iIHR5cGU9InBz a2M6VmVyc2lvblR5cGUiIHVzZT0icmVxdWlyZWQiLz4NCiAgICA8L2NvbXBsZXhUeXBlPg0KDQog ICBUaGUgY29tcG9uZW50cyBvZiB0aGUgS2V5Q29udGFpbmVyIGhhdmUgdGhlIGZvbGxvd2luZyBt ZWFuaW5nczoNCg0KICAgbyAgVmVyc2lvbiwgdGhlIHZlcnNpb24gbnVtYmVyIGZvciB0aGUgcG9y dGFibGUga2V5IGNvbnRhaW5lciBmb3JtYXQNCiAgICAgICh0aGUgWE1MIHNjaGVtYSBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQpLg0KDQogICBvICA8RW5jcnlwdGlvbk1ldGhvZD4sIHRoZSBlbmNy eXB0aW9uIG1ldGhvZCB1c2VkIHRvIHByb3RlY3QgdGhlIEtleQ0KICAgICAgZGF0YSBhdHRyaWJ1 dGVzDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4 ICAgICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFi bGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIG8g IDxEaWdlc3RNZXRob2Q+LCB0aGUgZGlnZXN0IG1ldGhvZCB1c2VkIHRvIHNpZ24gdGhlIHVuZW5j cnlwdGVkIHRoZQ0KICAgICAgU2VjcmV0IEtleSBkYXRhIGF0dHJpYnV0ZXMNCg0KICAgbyAgPERl dmljZT4sIHRoZSBob3N0IERldmljZSBmb3Igb25lIG9yIG1vcmUgS2V5cy4NCg0KICAgbyAgPFNp Z25hdHVyZT4sIGNvbnRhaW5zIHRoZSBzaWduYXR1cmUgdmFsdWUgb2YgdGhlIENvbnRhaW5lci4g IFdoZW4NCiAgICAgIHRoZSBzaWduYXR1cmUgaXMgYXBwbGllZCB0byB0aGUgZW50aXJlIGNvbnRh aW5lciwgaXQgTVVTVCB1c2UgWE1MDQogICAgICBTaWduYXR1cmUgbWV0aG9kcyBhcyBkZWZpbmVk IGluIFtYTUxTSUddLiAgVGhlIHNpZ25hdHVyZSBpcw0KICAgICAgZW52ZWxvcGVkLg0KDQo2LjEu Ny4gIEVuY3J5cHRpb25NZXRob2RUeXBlDQoNCiAgIFRoZSBFbmNyeXB0aW9uTWV0aG9kVHlwZSBk ZWZpbmVzIHRoZSBhbGdvcml0aG0gYW5kIHBhcmFtZXRlcnMgdXNlZCB0bw0KICAgZW5jcnlwdCB0 aGUgU2VjcmV0IEtleSBkYXRhIGF0dHJpYnV0ZXMgaW4gdGhlIENvbnRhaW5lci4gIFRoZQ0KICAg ZW5jcnlwdGlvbiBpcyBhcHBsaWVkIG9uIGVhY2ggaW5kaXZpZHVhbCBTZWNyZXQgS2V5IGRhdGEg aW4gdGhlDQogICBDb250YWluZXIuICBUaGUgZW5jcnlwdGlvbiBtZXRob2QgTVVTVCBiZSB0aGUg c2FtZSBmb3IgYWxsIFNlY3JldCBLZXkNCiAgIGRhdGEgaW4gdGhlIGNvbnRhaW5lci4NCg0KICAg VGhlIEVuY3J5cHRpb25NZXRob2RUeXBlIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpI b3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAg ICAgICBbUGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmlj IEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgPGNvbXBsZXhUeXBl IG5hbWU9IkVuY3J5cHRpb25NZXRob2RUeXBlIj4NCiAgICAgICA8c2VxdWVuY2U+DQogICAgICAg ICA8ZWxlbWVudCBuYW1lPSJFbmNLZXlMYWJlbCIgbWluT2NjdXJzPSIwIi8+DQogICAgICAgICA8 Y2hvaWNlPg0KICAgICAgICAgICA8c2VxdWVuY2U+DQogICAgICAgICAgICAgPGVsZW1lbnQgbmFt ZT0iS2V5SW5mbyINCiAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJkczpLZXlJbmZvVHlwZSIg bWluT2NjdXJzPSIwIi8+DQogICAgICAgICAgICAgPGVsZW1lbnQgbmFtZT0iT0FFUFBhcmFtcyIN CiAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJiYXNlNjRCaW5hcnkiIG1pbk9jY3Vycz0iMCIv Pg0KICAgICAgICAgICA8L3NlcXVlbmNlPg0KICAgICAgICAgICA8c2VxdWVuY2U+DQogICAgICAg ICAgICAgPGVsZW1lbnQgbmFtZT0iUEJFRW5jcnlwdGlvblBhcmFtIg0KICAgICAgICAgICAgICAg ICAgICAgIHR5cGU9InBza2M6UEJFRW5jcnlwdGlvblBhcmFtVHlwZSIgbWluT2NjdXJzPSIwIi8+ DQogICAgICAgICAgICAgPGVsZW1lbnQgbmFtZT0iSVYiIHR5cGU9ImJhc2U2NEJpbmFyeSIgbWlu T2NjdXJzPSIwIi8+DQogICAgICAgICAgIDwvc2VxdWVuY2U+DQogICAgICAgICAgIDxhbnkgbmFt ZXNwYWNlPSIjI290aGVyIiBwcm9jZXNzQ29udGVudHM9InN0cmljdCIvPg0KICAgICAgICAgPC9j aG9pY2U+DQogICAgICAgPC9zZXF1ZW5jZT4NCiAgICAgICA8YXR0cmlidXRlIG5hbWU9IkFsZ29y aXRobSINCiAgICAgICAgICAgICAgICAgIHR5cGU9ImFueVVSSSIgdXNlPSJyZXF1aXJlZCIvPg0K ICAgICA8L2NvbXBsZXhUeXBlPg0KDQogICAgICAgPGNvbXBsZXhUeXBlIG5hbWU9IlBCRUVuY3J5 cHRpb25QYXJhbVR5cGUiPg0KICAgICAgIDxzZXF1ZW5jZT4NCiAgICAgICAgIDxlbGVtZW50IG5h bWU9IlBCRVNhbHQiIHR5cGU9ImJhc2U2NEJpbmFyeSINCiAgICAgICAgICAgICAgICAgIG1pbk9j Y3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0iUEJFSXRlcmF0aW9uQ291bnQiIHR5 cGU9ImludCINCiAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgIDwvc2Vx dWVuY2U+DQogICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJFbmNyeXB0aW9uQWxnb3JpdGhtIiB0eXBl PSJhbnlVUkkiLz4NCiAgICAgPC9jb21wbGV4VHlwZT4NCg0KICAgVGhlIGNvbXBvbmVudHMgb2Yg dGhlIEVuY3J5cHRpb25NZXRob2RUeXBlIGhhdmUgdGhlIGZvbGxvd2luZw0KICAgbWVhbmluZ3M6 DQoNCiAgIG8gIDxFbmNLZXlMYWJlbD46IGlkZW50aWZpZXMgYSB1bmlxdWUgbGFiZWwgZm9yIGEg cHJlLXNoYXJlZA0KICAgICAgZW5jcnlwdGlvbiBrZXkuDQoNCiAgIG8gIEFsZ29yaXRobTogaWRl bnRpZmllcyB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gdXNlZCB0byBwcm90ZWN0IHRoZQ0KICAg ICAgU2VjcmV0IEtleSBkYXRhLiAgSWYgRW5jcnlwdGlvbk1ldGhvZCBpcyBhYnNlbnQgaW4NCiAg ICAgIEtleUNvbnRhaW5lclR5cGUsIGltcGxlbWVudGF0aW9ucyBNVVNUIGd1YXJhbnRlZSB0aGUg cHJpdmFjeSBvZg0KICAgICAgdGhlIFNlY3JldCBLZXkgRGF0YSB0aHJvdWdoIG90aGVyIG1lY2hh bmlzbXMgZS5nLiB0aHJvdWdoDQogICAgICB0cmFuc3BvcnQgbGV2ZWwgc2VjdXJpdHkuDQoNCiAg IG8gIDxLZXlJbmZvPjogY29udmV5cyB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIGtleSBpZiBhbiBS U0EgYWxnb3JpdGhtDQogICAgICBoYXMgYmVlbiB1c2VkLg0KDQoNCg0KDQoNCkhveWVyLCBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdl IDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRh aW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgbyAgPE9BRVBQYXJhbXM+OiBjb252ZXlz IHRoZSBPQUVQIHBhcmFtZXRlcnMgaWYgYW4gUlNBIGFsZ29yaXRobSBoYXMNCiAgICAgIGJlZW4g dXNlZC4NCg0KICAgbyAgPFBCRUVuY3J5cHRpb25QYXJhbT46IGNvbnZleXMgdGhlIFBCRSBwYXJh bWV0ZXJzIGlmIGEgcGFzc3dvcmQtDQogICAgICBiYXNlZCBlbmNyeXB0aW9uIChQQkUpIGFsZ29y aXRobSBoYXMgYmVlbiB1c2VkLg0KDQogICBvDQoNCiAgICAgICogIDxQQkVTYWx0PjogY29udmV5 cyB0aGUgU2FsdCB3aGVuIFtQS0NTNV0gcGFzc3dvcmQtYmFzZWQNCiAgICAgICAgIGVuY3J5cHRp b24gaXMgYXBwbGllZC4NCg0KICAgICAgKiAgPFBCRUl0ZXJhdGlvbkNvdW50PjogY29udmV5cyB0 aGUgaXRlcmF0aW9uIGNvdW50IHZhbHVlIGluDQogICAgICAgICBbUEtDUzVdIHBhc3N3b3JkLWJh c2VkIGVuY3J5cHRpb24gaWYgaXQgaXMgZGlmZmVyZW50IGZyb20gdGhlDQogICAgICAgICBkZWZh dWx0IHZhbHVlLg0KDQogICAgICAqICA8RW5jcnlwdGlvbkFsZ29yaXRobT46IHNwZWNpZmllcyB0 aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gYWZ0ZXINCiAgICAgICAgIGEgUEJFIGtleSBpcyBkZXJp dmVkLiAgRm9yIGV4YW1wbGUsIFBCRS1BRVMxMjgtQ0JDIHNob3VsZCB1c2UNCiAgICAgICAgIFVS SSBodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVuYyNrdy1hZXMxMjgtY2JjDQoNCiAgIG8g IDxJVj46IGNvbnZleXMgdGhlIGluaXRpYWxpemF0aW9uIHZlY3RvciBmb3IgQ0JDIGJhc2VkIGVu Y3J5cHRpb24NCiAgICAgIGFsZ29yaXRobXMuICBJdCBpcyByZWNvbW1lbmRlZCBmb3Igc2VjdXJp dHkgcmVhc29ucyB0byB0cmFuc21pdA0KICAgICAgdGhpcyB2YWx1ZSBvdXQgb2YgYmFuZCBhbmQg dHJlYXQgaXQgdGhlIHNhbWUgbWFubmVyIGFzIHRoZSBrZXkNCiAgICAgIHZhbHVlLg0KDQo2LjEu OC4gIERpZ2VzdE1ldGhvZFR5cGUNCg0KICAgVGhlIERpZ2VzdE1ldGhvZFR5cGUgZGVmaW5lcyB0 aGUgYWxnb3JpdGhtIGFuZCBwYXJhbWV0ZXJzIHVzZWQgdG8NCiAgIGNyZWF0ZSB0aGUgZGlnZXN0 IG9uIHRoZSB1bmVuY3J5cHRlZCBTZWNyZXQgS2V5IGRhdGEgaW4gdGhlDQogICBDb250YWluZXIu ICBUaGUgZGlnZXN0IGlzIGFwcGxpZWQgb24gZWFjaCBpbmRpdmlkdWFsIFNlY3JldCBLZXkgZGF0 YQ0KICAgaW4gdGhlIENvbnRhaW5lciBiZWZvcmUgZW5jcnlwdGlvbi4gIFRoZSBkaWdlc3QgbWV0 aG9kIE1VU1QgYmUgdGhlDQogICBzYW1lIGZvciBhbGwgU2VjcmV0IEtleSBkYXRhIGluIHRoZSBj b250YWluZXIuICBVbmxlc3MgYSBkaWZmZXJlbnQNCiAgIGRpZ2VzdCBrZXkgaXMgc3BlY2lmaWVk IGl0IGlzIGFzc3VtZWQgdGhhdCBrZXllZCBkaWdlc3QgYWxnb3JpdGhtcw0KICAgd2lsbCB1c2Ug dGhlIHNhbWUga2V5IGFzIGZvciBlbmNyeXB0aW9uDQoNCiAgIFRoZSBEaWdlc3RNZXRob2RUeXBl IGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0KDQogICAgIDxjb21wbGV4VHlwZSBuYW1lPSJEaWdl c3RNZXRob2RUeXBlIj4NCiAgICAgICA8c2VxdWVuY2U+DQogICAgICAgICA8ZWxlbWVudCBuYW1l PSJEaWdlc3RLZXlMYWJlbCIgbWluT2NjdXJzPSIwIi8+DQogICAgICAgPC9zZXF1ZW5jZT4NCiAg ICAgICA8YXR0cmlidXRlIG5hbWU9IkFsZ29yaXRobSINCiAgICAgICAgICAgICAgICAgIHR5cGU9 ImFueVVSSSIgdXNlPSJyZXF1aXJlZCIvPg0KICAgICA8L2NvbXBsZXhUeXBlPg0KDQogICBUaGUg Y29tcG9uZW50cyBvZiB0aGUgRGlnZXN0TWV0aG9kVHlwZSBoYXZlIHRoZSBmb2xsb3dpbmcgbWVh bmluZ3M6DQoNCg0KDQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkg OSwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg IFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0K DQogICBvICBBbGdvcml0aG0sIGlkZW50aWZpZXMgdGhlIGRpZ2VzdCBhbGdvcml0aG0gdXNlZCB0 byBwcm90ZWN0IHRoZQ0KICAgICAgU2VjcmV0IEtleSBkYXRhLg0KDQogICBvICA8RGlnZXN0S2V5 TGFiZWw+OiBpZGVudGlmaWVzIGEgdW5pcXVlIGxhYmVsIGZvciBhIHByZS1zaGFyZWQNCiAgICAg IGRpZ2VzdCBrZXkuDQoNCjYuMi4gIEtleUFsZ29yaXRobVR5cGUNCg0KICAgVGhlIEtleUFsZ29y aXRobVR5cGUgZGVmaW5lcyB0aGUgYWxnb3JpdGhtcyBpbiB3aGljaCB0aGUgU2VjcmV0IEtleQ0K ICAgZGF0YSBpcyB1c2VkLiAgSXQgcmVmZXJzIHRvIGFueVVSSS4NCg0KNi4zLiAgVmFsdWVGb3Jt YXQNCg0KICAgVGhlIFZhbHVlRm9ybWF0IGRlZmluZXMgYWxsb3dlZCBmb3JtYXRzIGZvciBjaGFs bGVuZ2VzIG9yIHJlc3BvbnNlcw0KICAgaW4gdGhlIE9UUCBhbGdvcml0aG1zLg0KDQogICBUaGUg VmFsdWVGb3JtYXQgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KDQoNCiAgIDxzaW1wbGVUeXBlIG5h bWU9IlZhbHVlRm9ybWF0Ij4NCiAgICAgPHJlc3RyaWN0aW9uIGJhc2U9InN0cmluZyI+DQogICAg ICAgPGVudW1lcmF0aW9uIHZhbHVlPSJERUNJTUFMIi8+DQogICAgICAgPGVudW1lcmF0aW9uIHZh bHVlPSJIRVhBREVDSU1BTCIvPg0KICAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iQUxQSEFOVU1F UklDIi8+DQogICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJCQVNFNjQiLz4NCiAgICAgICA8ZW51 bWVyYXRpb24gdmFsdWU9IkJJTkFSWSIvPg0KICAgICA8L3Jlc3RyaWN0aW9uPg0KICAgPC9zaW1w bGVUeXBlPg0KDQogICAgICBERUNJTUFMIE9ubHkgbnVtZXJpY2FsIGRpZ2l0cw0KDQogICAgICBI RVhBREVDSU1BTCBIZXhhZGVjaW1hbCByZXNwb25zZQ0KDQogICAgICBBTFBIQU5VTUVSSUMgQWxs IGxldHRlcnMgYW5kIG51bWJlcnMgKGNhc2Ugc2Vuc2l0aXZlKQ0KDQogICAgICBCQVNFNjQgQmFz ZSA2NCBlbmNvZGVkDQoNCiAgICAgIEJJTkFSWSBCaW5hcnkgZGF0YSwgdGhpcyBpcyBtYWlubHkg dXNlZCBpbiBjYXNlIG9mIGNvbm5lY3RlZA0KICAgICAgZGV2aWNlcw0KDQo2LjQuICBEYXRhIGVs ZW1lbnRzDQoNCjYuNC4xLiAgS2V5Q29udGFpbmVyDQoNCiAgIFRoZSBLZXlDb250YWluZXIgZGF0 YSBlbGVtZW50IGlzIGRlZmluZWQgYXM6DQoNCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAg ICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAg ICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgIDxlbGVtZW50IG5hbWU9IktleUNvbnRhaW5lciIgdHlw ZT0icHNrYzpLZXlDb250YWluZXJUeXBlIi8+DQoNCiAgIFRoZSBLZXlDb250YWluZXIgZGF0YSBl bGVtZW50IGlzIG9mIHR5cGUgS2V5Q29udGFpbmVyVHlwZSBkZWZpbmVkIGluDQogICBTZWN0aW9u IDYuMS42Lg0KDQogICBUaGUgRW5jcnlwdGlvbk1ldGhvZCBkYXRhIGVsZW1lbnQgaW4gdGhlIEtl eUNvbnRhaW5lciBkZWZpbmVzIHRoZQ0KICAgZW5jcnlwdGlvbiBhbGdvcml0aG0gdXNlZCB0byBw cm90ZWN0IHRoZSBLZXkgZGF0YS4gIEluIGEgbXVsdGkta2V5DQogICBLZXlDb250YWluZXIsIHRo ZSBzYW1lIGVuY3J5cHRpb24gbWV0aG9kIGFuZCB0aGUgc2FtZSBlbmNyeXB0aW9uIGtleQ0KICAg TVVTVCBiZSB1c2VkIGZvciBhbGwga2V5IGRhdGEgZWxlbWVudHMuDQoNCiAgIFRoZSBLZXlDb250 YWluZXIgZGF0YSBlbGVtZW50IE1BWSBjb250YWluIG11bHRpcGxlIERldmljZSBkYXRhDQogICBl bGVtZW50cywgYWxsb3dpbmcgZm9yIGJ1bGsgcHJvdmlzaW9uaW5nIG9mIGtleXMuDQoNCiAgIFRo ZSBTaWduYXR1cmUgZGF0YSBlbGVtZW50IGlzIG9mIHR5cGUgPGRzOlNpZ25hdHVyZT4gYXMgZGVm aW5lZCBpbg0KICAgW1hNTFNJR10gYW5kIE1BWSBiZSBvbWl0dGVkIGluIHRoZSBLZXlDb250YWlu ZXIgZGF0YSBlbGVtZW50IHdoZW4NCiAgIGFwcGxpY2F0aW9uIGxheWVyIHByb3Zpc2lvbmluZyBv ciB0cmFuc3BvcnQgbGF5ZXIgcHJvdmlzaW9uaW5nDQogICBwcm90b2NvbHMgcHJvdmlkZSB0aGUg aW50ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHkgb2YgdGhlIHBheWxvYWQNCiAgIGJldHdlZW4gdGhl IHNlbmRlciBhbmQgdGhlIHJlY2lwaWVudCBvZiB0aGUgY29udGFpbmVyLiAgV2hlbg0KICAgcmVx dWlyZWQsIHRoaXMgc3BlY2lmaWNhdGlvbiByZWNvbW1lbmRzIHVzaW5nIGEgc3ltbWV0cmljIGtl eSBiYXNlZA0KICAgc2lnbmF0dXJlIHdpdGggdGhlIHNhbWUga2V5IHVzZWQgaW4gdGhlIGVuY3J5 cHRpb24gb2YgdGhlIHNlY3JldCBrZXkNCiAgIGRhdGEuICBUaGUgc2lnbmF0dXJlIGlzIGVudmVs b3BlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkhveWVyLCBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDgg ICAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJs ZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KNy4gIEZv cm1hbCBTeW50YXgNCg0KICAgVGhlIGZvbGxvd2luZyBzeW50YXggc3BlY2lmaWNhdGlvbiB1c2Vz IHRoZSB3aWRlbHkgYWRvcHRlZCBYTUwgc2NoZW1hDQogICBmb3JtYXQgYXMgZGVmaW5lZCBieSBh IFczQyByZWNvbW1lbmRhdGlvbg0KICAgKGh0dHA6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0w LykuICBJdCBpcyBhIGNvbXBsZXRlIHN5bnRheA0KICAgZGVmaW5pdGlvbiBpbiB0aGUgWE1MIFNj aGVtYSBEZWZpbml0aW9uIGZvcm1hdCAoWFNEKQ0KDQogICBBbGwgaW1wbGVtZW50YXRpb25zIG9m IHRoaXMgc3RhbmRhcmQgbXVzdCBjb21wbHkgd2l0aCB0aGUgc2NoZW1hDQogICBiZWxvdy4NCg0K DQo8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KDQo8eHM6c2NoZW1hIHht bG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSINCiAgeG1sbnM6cHNrYz0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczprZXlwcm92OmNvbnRhaW5lcjoxLjAiDQogIHhtbG5zOmxv Z289InVybjppZXRmOnBhcmFtczp4bWw6bnM6a2V5cHJvdjpsb2dvOjEuMCINCiAgeG1sbnM6ZHM9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiDQogIHRhcmdldE5hbWVzcGFjZT0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczprZXlwcm92OmNvbnRhaW5lcjoxLjAiDQogIGVsZW1lbnRG b3JtRGVmYXVsdD0icXVhbGlmaWVkIiBhdHRyaWJ1dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQi DQogIHZlcnNpb249IjEuMCI+DQoNCiAgPHhzOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cu dzMub3JnLzIwMDAvMDkveG1sZHNpZyMiDQogICAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cu dzMub3JnL1RSLzIwMDIvUkVDLXhtbGRzaWctY29yZS0yMDAyMDIxMi8NCiAgICAgIHhtbGRzaWct Y29yZS1zY2hlbWEueHNkIi8+DQoNCiAgPHhzOmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBh cmFtczp4bWw6bnM6a2V5cHJvdjpsb2dvOjEuMCINCiAgICBzY2hlbWFMb2NhdGlvbj0ia2V5cHJv di1sb2dvLTEuMC54c2QiLz4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iS2V5Q29udGFpbmVy VHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iRW5jcnlw dGlvbk1ldGhvZCIgbWluT2NjdXJzPSIwIj4NCiAgICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAg ICAgICAgIDx4czpjb21wbGV4Q29udGVudD4NCiAgICAgICAgICAgIDx4czpleHRlbnNpb24gYmFz ZT0icHNrYzpFbmNyeXB0aW9uTWV0aG9kVHlwZSIvPg0KICAgICAgICAgIDwveHM6Y29tcGxleENv bnRlbnQ+DQogICAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICAgICA8L3hzOmVsZW1lbnQ+DQog ICAgICA8eHM6ZWxlbWVudCBuYW1lPSJEaWdlc3RNZXRob2QiIG1pbk9jY3Vycz0iMCI+DQogICAg ICAgIDx4czpjb21wbGV4VHlwZT4NCiAgICAgICAgICA8eHM6Y29tcGxleENvbnRlbnQ+DQogICAg ICAgICAgICA8eHM6ZXh0ZW5zaW9uIGJhc2U9InBza2M6RGlnZXN0TWV0aG9kVHlwZSIvPg0KICAg ICAgICAgIDwveHM6Y29tcGxleENvbnRlbnQ+DQogICAgICAgIDwveHM6Y29tcGxleFR5cGU+DQog ICAgICA8L3hzOmVsZW1lbnQ+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJEZXZpY2UiIHR5cGU9 InBza2M6RGV2aWNlVHlwZSINCiAgICAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJTaWduYXR1cmUiIHR5cGU9ImRzOlNpZ25hdHVyZVR5 cGUiDQogICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4NCg0KDQoNCkhveWVyLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDMx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5l ciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgIDwveHM6c2VxdWVuY2U+DQogICAgPHhzOmF0 dHJpYnV0ZSBuYW1lPSJWZXJzaW9uIiB0eXBlPSJwc2tjOlZlcnNpb25UeXBlIg0KICAgICAgdXNl PSJyZXF1aXJlZCIvPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpzaW1wbGVUeXBlIG5h bWU9IlZlcnNpb25UeXBlIiBmaW5hbD0icmVzdHJpY3Rpb24iPg0KICAgIDx4czpyZXN0cmljdGlv biBiYXNlPSJ4czpzdHJpbmciPg0KICAgICAgPHhzOnBhdHRlcm4gdmFsdWU9IlxkezEsMn1cLlxk ezEsM30iLz4NCiAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoNCiAg PHhzOmNvbXBsZXhUeXBlIG5hbWU9IktleVR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAg IDx4czplbGVtZW50IG5hbWU9Iklzc3VlciIgdHlwZT0ieHM6c3RyaW5nIi8+DQogICAgICA8eHM6 ZWxlbWVudCBuYW1lPSJVc2FnZSIgdHlwZT0icHNrYzpVc2FnZVR5cGUiLz4NCiAgICAgIDx4czpl bGVtZW50IG5hbWU9IkZyaWVuZGx5TmFtZSIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAi Lz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IkRhdGEiIHR5cGU9InBza2M6RGF0YVR5cGUiDQog ICAgICAgICAgICAgICBtaW5PY2N1cnM9IjAiICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPg0KICAg ICAgPHhzOmVsZW1lbnQgbmFtZT0iQWNjZXNzUnVsZXMiIG1pbk9jY3Vycz0iMCI+DQogICAgICAg IDx4czpjb21wbGV4VHlwZT4NCiAgICAgICAgICA8eHM6c2ltcGxlQ29udGVudD4NCiAgICAgICAg ICAgIDx4czpleHRlbnNpb24gYmFzZT0ieHM6c3RyaW5nIj4NCiAgICAgICAgICAgICAgPHhzOmF0 dHJpYnV0ZSBuYW1lPSJVc2VyUElOIiB0eXBlPSJ4czpib29sZWFuIg0KICAgICAgICAgICAgICAg IGRlZmF1bHQ9ImZhbHNlIi8+DQogICAgICAgICAgICA8L3hzOmV4dGVuc2lvbj4NCiAgICAgICAg ICA8L3hzOnNpbXBsZUNvbnRlbnQ+DQogICAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICAgICA8 L3hzOmVsZW1lbnQ+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSJMb2dvIiB0eXBlPSJsb2dvOkxv Z29UeXBlIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IkV4cGlyeSIg dHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCiAgICA8L3hzOnNlcXVlbmNlPg0KICAg IDx4czphdHRyaWJ1dGUgbmFtZT0iS2V5SWQiIHR5cGU9InhzOnN0cmluZyIgdXNlPSJyZXF1aXJl ZCIvPg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iS2V5QWxnb3JpdGhtIiB0eXBlPSJwc2tjOktl eUFsZ29yaXRobVR5cGUiDQogICAgICB1c2U9InJlcXVpcmVkIi8+DQogIDwveHM6Y29tcGxleFR5 cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IkRldmljZUlkVHlwZSI+DQogICAgPHhzOnNl cXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iTWFudWZhY3R1cmVyIiB0eXBlPSJ4czpz dHJpbmciLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IlNlcmlhbE5vIiB0eXBlPSJ4czpzdHJp bmciLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9Ik1vZGVsIiB0eXBlPSJ4czpzdHJpbmciIG1p bk9jY3Vycz0iMCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iSXNzdWVObyIgdHlwZT0ieHM6 c3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IkV4cGlyeSIg dHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCiAgICA8L3hzOnNlcXVlbmNlPg0KICA8 L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4czpjb21wbGV4VHlwZSBuYW1lPSJEZXZpY2VUeXBlIj4N CiAgICA8eHM6c2VxdWVuY2U+DQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBp cmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAzMl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIg MjAwNw0KDQoNCiAgICAgIDx4czplbGVtZW50IG5hbWU9IkRldmljZUlkIiB0eXBlPSJwc2tjOkRl dmljZUlkVHlwZSINCiAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgPHhzOmVs ZW1lbnQgbmFtZT0iS2V5IiB0eXBlPSJwc2tjOktleVR5cGUiDQogICAgICAgICAgICAgICBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iVXNlciIgdHlwZT0i cHNrYzpVc2VyVHlwZSINCiAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0KICAgIDwveHM6 c2VxdWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9 IlVzZXJUeXBlIj4NCiAgICA8eHM6c2VxdWVuY2U+DQogICAgICA8eHM6c2VxdWVuY2U+DQogICAg ICAgIDx4czplbGVtZW50IG5hbWU9IlVzZXJJZCIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9 IjAiLz4NCiAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iRmlyc3ROYW1lIiB0eXBlPSJ4czpzdHJp bmciIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJMYXN0TmFtZSIg bWluT2NjdXJzPSIwIi8+DQogICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iT3JnIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAgIDwveHM6c2Vx dWVuY2U+DQogIDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IlVz YWdlVHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iUmVz cG9uc2VGb3JtYXQiPg0KICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgPHhzOmF0 dHJpYnV0ZSBuYW1lPSJGb3JtYXQiIHR5cGU9InBza2M6VmFsdWVGb3JtYXRUeXBlIg0KICAgICAg ICAgICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0KICAgICAgICAgIDx4czphdHRyaWJ1dGUg bmFtZT0iTGVuZ3RoIiB0eXBlPSJ4czp1bnNpZ25lZEludCINCiAgICAgICAgICAgIHVzZT0icmVx dWlyZWQiLz4NCiAgICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9IkNoZWNrRGlnaXRzIiB0eXBl PSJ4czpib29sZWFuIg0KICAgICAgICAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgICAgICAgPC94 czpjb21wbGV4VHlwZT4NCiAgICAgIDwveHM6ZWxlbWVudD4NCiAgICAgIDx4czplbGVtZW50IG5h bWU9IkNoYWxsZW5nZUZvcm1hdCIgbWluT2NjdXJzPSIwIj4NCiAgICAgICAgPHhzOmNvbXBsZXhU eXBlPg0KICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iRm9ybWF0IiB0eXBlPSJwc2tjOlZh bHVlRm9ybWF0VHlwZSINCiAgICAgICAgICAgICAgICAgICAgIHVzZT0icmVxdWlyZWQiLz4NCiAg ICAgICAgICA8eHM6YXR0cmlidXRlIG5hbWU9Ik1pbiIgdHlwZT0ieHM6dW5zaWduZWRJbnQiDQog ICAgICAgICAgICB1c2U9InJlcXVpcmVkIi8+DQogICAgICAgICAgPHhzOmF0dHJpYnV0ZSBuYW1l PSJNYXgiIHR5cGU9InhzOnVuc2lnbmVkSW50Ig0KICAgICAgICAgICAgdXNlPSJyZXF1aXJlZCIv Pg0KICAgICAgICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iQ2hlY2tEaWdpdHMiIHR5cGU9InhzOmJv b2xlYW4iDQogICAgICAgICAgICAgICAgICAgICBkZWZhdWx0PSJmYWxzZSIvPg0KICAgICAgICA8 L3hzOmNvbXBsZXhUeXBlPg0KICAgICAgPC94czplbGVtZW50Pg0KICAgICAgPHhzOmVsZW1lbnQg bmFtZT0iQXBwUHJvZmlsZUlkIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KICAg IDwveHM6c2VxdWVuY2U+DQogICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJPVFAiIHR5cGU9InhzOmJv b2xlYW4iDQogICAgICAgICAgICAgICBkZWZhdWx0PSJmYWxzZSIvPg0KDQoNCg0KSG95ZXIsIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMzNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29u dGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJD UiIgdHlwZT0ieHM6Ym9vbGVhbiINCiAgICAgICAgICAgICAgIGRlZmF1bHQ9ImZhbHNlIi8+DQog ICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJTaWduIiB0eXBlPSJ4czpib29sZWFuIg0KICAgICAgICAg ICAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgICA8eHM6YXR0cmlidXRlIG5hbWU9IkVuY3J5cHQi IHR5cGU9InhzOmJvb2xlYW4iDQogICAgICAgICAgICAgICBkZWZhdWx0PSJmYWxzZSIvPg0KICAg IDx4czphdHRyaWJ1dGUgbmFtZT0iVW5sb2NrIiB0eXBlPSJ4czpib29sZWFuIg0KICAgICAgICAg ICAgICAgZGVmYXVsdD0iZmFsc2UiLz4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29t cGxleFR5cGUgbmFtZT0iRW5jcnlwdGlvbk1ldGhvZFR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4N CiAgICAgIDx4czplbGVtZW50IG5hbWU9IkVuY0tleUxhYmVsIiBtaW5PY2N1cnM9IjAiLz4NCiAg ICAgIDx4czpjaG9pY2U+DQogICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICA8eHM6ZWxl bWVudCBuYW1lPSJLZXlJbmZvIg0KICAgICAgICAgICAgICAgICAgIHR5cGU9ImRzOktleUluZm9U eXBlIiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJPQUVQUGFy YW1zIg0KICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmJhc2U2NEJpbmFyeSIgbWluT2NjdXJz PSIwIi8+DQogICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAgIDx4czpzZXF1ZW5jZT4NCiAg ICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJQQkVFbmNyeXB0aW9uUGFyYW0iDQogICAgICAgICAg ICAgICAgICAgdHlwZT0icHNrYzpQQkVFbmNyeXB0aW9uUGFyYW1UeXBlIiBtaW5PY2N1cnM9IjAi Lz4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBuYW1lPSJJViIgdHlwZT0ieHM6YmFzZTY0QmluYXJ5 IiBtaW5PY2N1cnM9IjAiLz4NCiAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgICAgPHhzOmFu eSBuYW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ic3RyaWN0Ii8+DQogICAgICA8 L3hzOmNob2ljZT4NCiAgICA8L3hzOnNlcXVlbmNlPg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0i QWxnb3JpdGhtIg0KICAgICAgICAgICAgICAgdHlwZT0ieHM6YW55VVJJIiB1c2U9InJlcXVpcmVk Ii8+DQogIDwveHM6Y29tcGxleFR5cGU+DQoNCiAgPHhzOmNvbXBsZXhUeXBlIG5hbWU9IlBCRUVu Y3J5cHRpb25QYXJhbVR5cGUiPg0KICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgIDx4czplbGVtZW50 IG5hbWU9IlBCRVNhbHQiIHR5cGU9InhzOmJhc2U2NEJpbmFyeSINCiAgICAgICAgICAgICAgIG1p bk9jY3Vycz0iMCIvPg0KICAgICAgPHhzOmVsZW1lbnQgbmFtZT0iUEJFSXRlcmF0aW9uQ291bnQi IHR5cGU9InhzOmludCINCiAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPg0KICAgIDwveHM6 c2VxdWVuY2U+DQogICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJFbmNyeXB0aW9uQWxnb3JpdGhtIiB0 eXBlPSJ4czphbnlVUkkiLz4NCiAgPC94czpjb21wbGV4VHlwZT4NCg0KICA8eHM6Y29tcGxleFR5 cGUgbmFtZT0iRGlnZXN0TWV0aG9kVHlwZSI+DQogICAgPHhzOnNlcXVlbmNlPg0KICAgICAgPHhz OmVsZW1lbnQgbmFtZT0iRGlnZXN0S2V5TGFiZWwiIG1pbk9jY3Vycz0iMCIvPg0KICAgIDwveHM6 c2VxdWVuY2U+DQogICAgPHhzOmF0dHJpYnV0ZSBuYW1lPSJBbGdvcml0aG0iDQogICAgICAgICAg ICAgICB0eXBlPSJ4czphbnlVUkkiIHVzZT0icmVxdWlyZWQiLz4NCg0KDQoNCkhveWVyLCBldCBh bC4gICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdl IDM0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRh aW5lciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogIDx4 czpzaW1wbGVUeXBlIG5hbWU9IktleUFsZ29yaXRobVR5cGUiPg0KICAgIDx4czpyZXN0cmljdGlv biBiYXNlPSJ4czphbnlVUkkiLz4NCiAgPC94czpzaW1wbGVUeXBlPg0KDQogIDx4czpzaW1wbGVU eXBlIG5hbWU9IlZhbHVlRm9ybWF0VHlwZSI+DQogICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9Inhz OnN0cmluZyI+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkRFQ0lNQUwiLz4NCiAgICAg IDx4czplbnVtZXJhdGlvbiB2YWx1ZT0iSEVYQURFQ0lNQUwiLz4NCiAgICAgIDx4czplbnVtZXJh dGlvbiB2YWx1ZT0iQUxQSEFOVU1FUklDIi8+DQogICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9 IkJBU0U2NCIvPg0KICAgICAgPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJCSU5BUlkiLz4NCiAgICA8 L3hzOnJlc3RyaWN0aW9uPg0KICA8L3hzOnNpbXBsZVR5cGU+DQoNCiAgPHhzOmVsZW1lbnQgbmFt ZT0iS2V5Q29udGFpbmVyIg0KICAgICAgICAgICB0eXBlPSJwc2tjOktleUNvbnRhaW5lclR5cGUi Lz4NCg0KICA8eHM6Y29tcGxleFR5cGUgbmFtZT0iRGF0YVR5cGUiPg0KICAgIDx4czpzZXF1ZW5j ZT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IlZhbHVlIiB0eXBlPSJ4czpiYXNlNjRCaW5hcnki Lz4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IlZhbHVlRGlnZXN0Ig0KICAgICAgICAgICAgICAg dHlwZT0ieHM6YmFzZTY0QmluYXJ5IiBtaW5PY2N1cnM9IjAiLz4NCiAgICA8L3hzOnNlcXVlbmNl Pg0KICAgIDx4czphdHRyaWJ1dGUgbmFtZT0iTmFtZSIgdHlwZT0ieHM6c3RyaW5nIg0KICAgICAg ICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0KICA8L3hzOmNvbXBsZXhUeXBlPg0KDQo8L3hzOnNj aGVtYT4NCg0KICAgTG9nb1R5cGUgaXMgZGVmaW5lZCBpbiB0aGUgZm9sbG93aW5nIHNjaGVtYS4N Cg0KDQogICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KDQogICA8c2No ZW1hIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSINCiAgICAgeG1sbnM6 bG9nbz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczprZXlwcm92OmxvZ286MS4wIg0KICAgICB0YXJn ZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6a2V5cHJvdjpsb2dvOjEuMCINCiAg ICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1 bnF1YWxpZmllZCINCiAgICAgdmVyc2lvbj0iMS4wIj4NCg0KICAgICA8IS0tIExvZ29UeXBlIC0t Pg0KICAgICA8Y29tcGxleFR5cGUgbmFtZT0iTG9nb1R5cGUiPg0KICAgICAgIDxhbm5vdGF0aW9u Pg0KICAgICAgICAgPGRvY3VtZW50YXRpb24geG1sOmxhbmc9ImVuIj4NCiAgICAgICAgICAgVHlw ZSB0byBpbmNsdWRlIGxvZ28gaW5mb3JtYXRpb24uDQogICAgICAgICA8L2RvY3VtZW50YXRpb24+ DQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAg ICAgICAgICAgICAgICBbUGFnZSAzNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUg U3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgICA8 L2Fubm90YXRpb24+DQogICAgICAgPHNlcXVlbmNlPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0i Q29tbXVuaXR5TG9nb3MiIHR5cGU9ImxvZ286TG9nb0luZm9UeXBlIg0KICAgICAgICAgICBtaW5P Y2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+DQogICAgICAgICA8ZWxlbWVudCBuYW1l PSJJc3N1ZXJMb2dvIiB0eXBlPSJsb2dvOkxvZ29JbmZvVHlwZSINCiAgICAgICAgICAgbWluT2Nj dXJzPSIwIi8+DQogICAgICAgICA8ZWxlbWVudCBuYW1lPSJPdGhlckxvZ29zIiB0eXBlPSJsb2dv OkxvZ29JbmZvVHlwZSINCiAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91 bmRlZCIvPg0KICAgICAgIDwvc2VxdWVuY2U+DQogICAgIDwvY29tcGxleFR5cGU+DQoNCiAgICAg PGNvbXBsZXhUeXBlIG5hbWU9IkxvZ29JbmZvVHlwZSI+DQogICAgICAgPGFubm90YXRpb24+DQog ICAgICAgICA8ZG9jdW1lbnRhdGlvbiB4bWw6bGFuZz0iZW4iPg0KICAgICAgICAgICBEZWZpbmUg bG9nbyBpbmZvcm1hdGlvbiBmb3IgYSBnaXZlbiBsb2dvLiBJdCBjYW4gZWl0aGVyIGVtYmVkDQog ICAgICAgICAgIGZ1bGwgbG9nbyBkYXRhIGluZm9ybWF0aW9uLCBvciBpbmNsdWRlcyBvbmx5IGEg cmVmZXJlbmNlIFVSSQ0KICAgICAgICAgICB3aGVyZSB0aGUgZnVsbCBsb2cgZGF0YSBpbmZvcm1h dGlvbiB3aXRoIHR5cGUgTG9nb0RhdGFUeXBlDQogICAgICAgICAgIGNhbiBiZSBkb3dubG9hZGVk Lg0KICAgICAgICAgPC9kb2N1bWVudGF0aW9uPg0KICAgICAgIDwvYW5ub3RhdGlvbj4NCiAgICAg ICA8c2VxdWVuY2U+DQogICAgICAgICA8Y2hvaWNlPg0KICAgICAgICAgICA8ZWxlbWVudCBuYW1l PSJMb2dvRGF0YSIgdHlwZT0ibG9nbzpMb2dvRGF0YVR5cGUiLz4NCiAgICAgICAgICAgPGVsZW1l bnQgbmFtZT0iTG9nUmVmZXJlbmNlIiB0eXBlPSJhbnlVUkkiLz4NCiAgICAgICAgIDwvY2hvaWNl Pg0KICAgICAgIDwvc2VxdWVuY2U+DQogICAgIDwvY29tcGxleFR5cGU+DQoNCiAgICAgPGNvbXBs ZXhUeXBlIG5hbWU9IkxvZ29EYXRhVHlwZSI+DQogICAgICAgPGFubm90YXRpb24+DQogICAgICAg ICA8ZG9jdW1lbnRhdGlvbiB4bWw6bGFuZz0iZW4iPg0KICAgICAgICAgICBEZWZpbmUgbG9nbyBk YXRhIGluZm9ybWF0aW9uIGZvciBhIGdpdmVuIGxvZ28gaW1hZ2UuDQogICAgICAgICA8L2RvY3Vt ZW50YXRpb24+DQogICAgICAgPC9hbm5vdGF0aW9uPg0KICAgICAgIDxzZXF1ZW5jZT4NCiAgICAg ICAgIDxlbGVtZW50IG5hbWU9IkxvZ29JbWFnZURldGFpbHMiDQogICAgICAgICAgIHR5cGU9Imxv Z286TG9nb0ltYWdlRGV0YWlsc1R5cGUiLz4NCiAgICAgICAgIDxlbGVtZW50IG5hbWU9IkxvZ29J bWFnZUluZm8iIHR5cGU9ImxvZ286TG9nb0ltYWdlSW5mb1R5cGUiDQogICAgICAgICAgIG1pbk9j Y3Vycz0iMCIvPg0KICAgICAgIDwvc2VxdWVuY2U+DQogICAgIDwvY29tcGxleFR5cGU+DQoNCiAg ICAgPGNvbXBsZXhUeXBlIG5hbWU9IkxvZ29JbWFnZURldGFpbHNUeXBlIj4NCiAgICAgICA8YW5u b3RhdGlvbj4NCiAgICAgICAgIDxkb2N1bWVudGF0aW9uIHhtbDpsYW5nPSJlbiI+DQogICAgICAg ICAgIERlZmluZSBsb2dvIGltYWdlIGRhdGEgZm9yIGEgZ2l2ZW4gbG9nbyBpbWFnZS4NCiAgICAg ICAgIDwvZG9jdW1lbnRhdGlvbj4NCiAgICAgICA8L2Fubm90YXRpb24+DQoNCg0KDQpIb3llciwg ZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBb UGFnZSAzNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBD b250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCiAgICAgICA8c2VxdWVuY2U+DQogICAg ICAgICA8Y2hvaWNlPg0KICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJJbWFnZURhdGEiIHR5cGU9 ImJhc2U2NEJpbmFyeSIvPg0KICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJJbWFnZVJlZmVyZW5j ZSIgdHlwZT0iYW55VVJJIi8+DQogICAgICAgICA8L2Nob2ljZT4NCiAgICAgICA8L3NlcXVlbmNl Pg0KICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0iTUlNRVR5cGUiIHR5cGU9ImxvZ286TUlNRVR5cGVU eXBlIg0KICAgICAgICAgdXNlPSJyZXF1aXJlZCIvPg0KICAgICA8L2NvbXBsZXhUeXBlPg0KDQog ICAgIDxjb21wbGV4VHlwZSBuYW1lPSJMb2dvSW1hZ2VJbmZvVHlwZSI+DQogICAgICAgPGFubm90 YXRpb24+DQogICAgICAgICA8ZG9jdW1lbnRhdGlvbiB4bWw6bGFuZz0iZW4iPg0KICAgICAgICAg ICBEZWZpbmUgbG9nbyBpbWFnZSBwYXJhbWV0ZXJzIGZvciBhIGdpdmVuIGxvZ28gaW1hZ2UuDQog ICAgICAgICA8L2RvY3VtZW50YXRpb24+DQogICAgICAgPC9hbm5vdGF0aW9uPg0KICAgICAgIDxz ZXF1ZW5jZT4NCiAgICAgICAgIDxlbGVtZW50IG5hbWU9IlNpemUiIHR5cGU9ImludGVnZXIiIG1p bk9jY3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0ieFNpemUiIHR5cGU9ImludGVn ZXIiIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0ieVNpemUiIHR5cGU9 ImludGVnZXIiIG1pbk9jY3Vycz0iMCIvPg0KICAgICAgICAgPGVsZW1lbnQgbmFtZT0iUmVzb2x1 dGlvbiIgdHlwZT0ibG9nbzpMb2dvSW1hZ2VSZXNvbHV0aW9uVHlwZSINCiAgICAgICAgICAgbWlu T2NjdXJzPSIwIi8+DQogICAgICAgPC9zZXF1ZW5jZT4NCiAgICAgICA8YXR0cmlidXRlIG5hbWU9 ImNvbG9yZWQiIHR5cGU9ImJvb2xlYW4iIGRlZmF1bHQ9InRydWUiLz4NCiAgICAgICA8YXR0cmli dXRlIG5hbWU9ImxhbmciIHR5cGU9InN0cmluZyIgdXNlPSJvcHRpb25hbCIvPg0KICAgICA8L2Nv bXBsZXhUeXBlPg0KDQogICAgIDxjb21wbGV4VHlwZSBuYW1lPSJMb2dvSW1hZ2VSZXNvbHV0aW9u VHlwZSI+DQogICAgICAgPGFubm90YXRpb24+DQogICAgICAgICA8ZG9jdW1lbnRhdGlvbiB4bWw6 bGFuZz0iZW4iPg0KICAgICAgICAgICBEZWZpbmUgbG9nbyBpbWFnZSByZXNvbHV0aW9uIHBhcmFt ZXRlcnMuDQogICAgICAgICA8L2RvY3VtZW50YXRpb24+DQogICAgICAgPC9hbm5vdGF0aW9uPg0K ICAgICAgIDxzZXF1ZW5jZT4NCiAgICAgICAgIDxlbGVtZW50IG5hbWU9Ik51bUJpdHMiIHR5cGU9 ImludGVnZXIiLz4NCiAgICAgICAgIDxlbGVtZW50IG5hbWU9IlRhYmxlU2l6ZSIgdHlwZT0iaW50 ZWdlciIvPg0KICAgICAgIDwvc2VxdWVuY2U+DQogICAgIDwvY29tcGxleFR5cGU+DQoNCiAgICAg PCEtLSBNaW1lVHlwZVR5cGUgLS0+DQogICAgIDxzaW1wbGVUeXBlIG5hbWU9Ik1JTUVUeXBlVHlw ZSI+DQogICAgICAgPGFubm90YXRpb24+DQogICAgICAgICA8ZG9jdW1lbnRhdGlvbiB4bWw6bGFu Zz0iZW4iPg0KICAgICAgICAgICBDYW4gYmUgb25lIG9mIHRoZSBmb2xsb3dpbmcgc3VwcG9ydGVk IGltYWdlIGNvbnRlbnQgdHlwZXMuDQogICAgICAgICA8L2RvY3VtZW50YXRpb24+DQogICAgICAg PC9hbm5vdGF0aW9uPg0KICAgICAgIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJpbmciPg0KICAgICAg ICAgPGVudW1lcmF0aW9uIHZhbHVlPSJpbWFnZS9naWYiLz4NCg0KDQoNCkhveWVyLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDM3 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5l ciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJp bWFnZS9qcGVnIi8+DQogICAgICAgPC9yZXN0cmljdGlvbj4NCiAgICAgPC9zaW1wbGVUeXBlPg0K ICAgPC9zY2hlbWE+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSG95ZXIs IGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAg W1BhZ2UgMzhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkg Q29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQo4LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlIHBvcnRhYmxlIGtleSBjb250YWluZXIgY2FycmllcyBzZW5zaXRpdmUg aW5mb3JtYXRpb24gKGUuZy4sDQogICBjcnlwdG9ncmFwaGljIGtleXMpIGFuZCBtYXkgYmUgdHJh bnNwb3J0ZWQgYWNyb3NzIHRoZSBib3VuZGFyaWVzIG9mDQogICBvbmUgc2VjdXJlIHBlcmltZXRl ciB0byBhbm90aGVyLiAgRm9yIGV4YW1wbGUsIGEgY29udGFpbmVyIHJlc2lkaW5nDQogICB3aXRo aW4gdGhlIHNlY3VyZSBwZXJpbWV0ZXIgb2YgYSBiYWNrLWVuZCBwcm92aXNpb25pbmcgc2VydmVy IGluIGENCiAgIHNlY3VyZSByb29tIG1heSBiZSB0cmFuc3BvcnRlZCBhY3Jvc3MgdGhlIGludGVy bmV0IHRvIGFuIGVuZC11c2VyDQogICBkZXZpY2UgYXR0YWNoZWQgdG8gYSBwZXJzb25hbCBjb21w dXRlci4gIFRoaXMgbWVhbnMgdGhhdCBzcGVjaWFsIGNhcmUNCiAgIG11c3QgYmUgdGFrZW4gdG8g ZW5zdXJlIHRoZSBjb25maWRlbnRpYWxpdHksIGludGVncml0eSwgYW5kDQogICBhdXRoZW50aWNp dHkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCB3aXRoaW4uDQoNCjguMS4gIFBheWxvYWQg Y29uZmlkZW50aWFsaXR5DQoNCiAgIEJ5IGRlc2lnbiwgdGhlIGNvbnRhaW5lciBhbGxvd3MgdHdv IG1haW4gYXBwcm9hY2hlcyB0byBndWFyYW50ZWVpbmcNCiAgIHRoZSBjb25maWRlbnRpYWxpdHkg b2YgdGhlIGluZm9ybWF0aW9uIGl0IGNvbnRhaW5zIHdoaWxlIHRyYW5zcG9ydGVkLg0KDQogICBG aXJzdCwgdGhlIGNvbnRhaW5lciBrZXkgZGF0YSBwYXlsb2FkIG1heSBiZSBlbmNyeXB0ZWQuDQoN CiAgIEluIHRoaXMgY2FzZSBubyB0cmFuc3BvcnQgbGF5ZXIgc2VjdXJpdHkgaXMgcmVxdWlyZWQu ICBIb3dldmVyLA0KICAgc3RhbmRhcmQgc2VjdXJpdHkgYmVzdCBwcmFjdGljZXMgYXBwbHkgd2hl biBzZWxlY3RpbmcgdGhlIHN0cmVuZ3RoIG9mDQogICB0aGUgY3J5cHRvZ3JhcGhpYyBhbGdvcml0 aG0gZm9yIHBheWxvYWQgZW5jcnlwdGlvbi4gIFN5bW1ldHJpYw0KICAgY3J5cHRvZ3JhcGhpYyBj aXBoZXIgc2hvdWxkIGJlIHVzZWQgLSB0aGUgbG9uZ2VyIHRoZSBjcnlwdG9ncmFwaGljDQogICBr ZXksIHRoZSBzdHJvbmdlciB0aGUgcHJvdGVjdGlvbi4gIEF0IHRoZSB0aW1lIG9mIHRoaXMgd3Jp dGluZyBib3RoDQogICAzREVTIGFuZCBBRVMgYXJlIHJlY29tbWVuZGVkIGFsZ29yaXRobXMgYnV0 IDNERVMgbWF5IGJlIGRyb3BwZWQgaW4NCiAgIHRoZSByZWxhdGl2ZWx5IG5lYXIgZnV0dXJlLiAg QXBwbGljYXRpb25zIGNvbmNlcm5lZCB3aXRoIGFsZ29yaXRobQ0KICAgbG9uZ2V2aXR5IGFyZSBh ZHZpc2VkIHRvIHVzZSBBRVMuICBJbiBjYXNlcyB3aGVyZSB0aGUgZXhjaGFuZ2Ugb2YNCiAgIGVu Y3J5cHRpb24ga2V5cyBiZXR3ZWVuIHRoZSBzZW5kZXIgYW5kIHRoZSByZWNlaXZlciBpcyBub3Qg cG9zc2libGUsDQogICBhc3ltbWV0cmljIGVuY3J5cHRpb24gb2YgdGhlIHNlY3JldCBrZXkgcGF5 bG9hZCBtYXkgYmUgZW1wbG95ZWQuDQogICBTaW1pbGFybHkgdG8gc3ltbWV0cmljIGtleSBjcnlw dG9ncmFwaHksIHRoZSBzdHJvbmdlciB0aGUgYXN5bW1ldHJpYw0KICAga2V5LCB0aGUgbW9yZSBz ZWN1cmUgdGhlIHByb3RlY3Rpb24gaXMuDQoNCiAgIElmIHRoZSBwYXlsb2FkIGlzIGVuY3J5cHRl ZCB3aXRoIGEgbWV0aG9kIHRoYXQgdXNlcyBvbmUgb2YgdGhlDQogICBwYXNzd29yZC1iYXNlZCBl bmNyeXB0aW9uIG1ldGhvZHMgcHJvdmlkZWQgYWJvdmUsIHRoZSBwYXlsb2FkIG1heSBiZQ0KICAg c3ViamVjdGVkIHRvIHBhc3N3b3JkIGRpY3Rpb25hcnkgYXR0YWNrcyB0byBicmVhayB0aGUgZW5j cnlwdGlvbg0KICAgcGFzc3dvcmQgYW5kIHJlY292ZXIgdGhlIGluZm9ybWF0aW9uLiAgU3RhbmRh cmQgc2VjdXJpdHkgYmVzdA0KICAgcHJhY3RpY2VzIGZvciBzZWxlY3Rpb24gb2Ygc3Ryb25nIGVu Y3J5cHRpb24gcGFzc3dvcmRzIGFwcGx5DQogICBbU2NobmVpZXJdLg0KDQogICBQcmFjdGljYWwg aW1wbGVtZW50YXRpb25zIHNob3VsZCB1c2UgUEJFU2FsdCBhbmQgUEJFSXRlcmF0aW9uQ291bnQN CiAgIHdoZW4gUEJFIGVuY3J5cHRpb24gaXMgdXNlZC4gIERpZmZlcmVudCBQQkVTYWx0IHZhbHVl IHBlciBjcmVkZW50aWFsDQogICByZWNvcmQgc2hvdWxkIGJlIHVzZWQgZm9yIGJlc3QgcHJvdGVj dGlvbi4NCg0KICAgVGhlIHNlY29uZCBhcHByb2FjaCB0byBwcm90ZWN0aW5nIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlIHBheWxvYWQNCiAgIGlzIGJhc2VkIG9uIHVzaW5nIHRyYW5zcG9ydCBs YXllciBzZWN1cml0eS4gIFRoZSBzZWN1cmUgY2hhbm5lbA0KICAgZXN0YWJsaXNoZWQgYmV0d2Vl biB0aGUgc291cmNlIHNlY3VyZSBwZXJpbWV0ZXIgKHRoZSBwcm92aXNpb25pbmcNCiAgIHNlcnZl ciBmcm9tIHRoZSBleGFtcGxlIGFib3ZlKSBhbmQgdGhlIHRhcmdldCBwZXJpbWV0ZXIgKHRoZSBk ZXZpY2UNCiAgIGF0dGFjaGVkIHRvIHRoZSBlbmQtdXNlciBjb21wdXRlcikgdXRpbGl6ZXMgZW5j cnlwdGlvbiB0byB0cmFuc3BvcnQNCiAgIHRoZSBtZXNzYWdlcyB0aGF0IHRyYXZlbCBhY3Jvc3Mu ICBObyBwYXlsb2FkIGVuY3J5cHRpb24gaXMgcmVxdWlyZWQNCg0KDQoNCkhveWVyLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDM5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5l ciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAgaW4gdGhpcyBtb2RlLiAgU2VjdXJlIGNoYW5u ZWxzIHRoYXQgZW5jcnlwdCBhbmQgZGlnZXN0IGVhY2ggbWVzc2FnZQ0KICAgcHJvdmlkZSBhbiBl eHRyYSBtZWFzdXJlIG9mIHNlY3VyaXR5LCBlc3BlY2lhbGx5IHdoZW4gdGhlIHNpZ25hdHVyZQ0K ICAgb2YgdGhlIHBheWxvYWQgZG9lcyBub3QgZW5jb21wYXNzIHRoZSBlbnRpcmUgcGF5bG9hZC4N Cg0KICAgQmVjYXVzZSBvZiB0aGUgZmFjdCB0aGF0IHRoZSBwbGFpbiB0ZXh0IHBheWxvYWQgaXMg cHJvdGVjdGVkIG9ubHkgYnkNCiAgIHRoZSB0cmFuc3BvcnQgbGF5ZXIgc2VjdXJpdHksIHByYWN0 aWNhbCBpbXBsZW1lbnRhdGlvbiBtdXN0IGVuc3VyZQ0KICAgcHJvdGVjdGlvbiBhZ2FpbnN0IG1h bi1pbi10aGUtbWlkZGxlIGF0dGFja3MgW1NjaG5laWVyXS4gIFZhbGlkYXRpbmcNCiAgIHRoZSBz ZWN1cmUgY2hhbm5lbCBlbmQtcG9pbnRzIGlzIGNyaXRpY2FsbHkgaW1wb3J0YW50IGZvciBlbGlt aW5hdGluZw0KICAgaW50cnVkZXJzIHRoYXQgbWF5IGNvbXByb21pc2UgdGhlIGNvbmZpZGVudGlh bGl0eSBvZiB0aGUgcGF5bG9hZC4NCg0KOC4yLiAgUGF5bG9hZCBpbnRlZ3JpdHkNCg0KICAgVGhl IHBvcnRhYmxlIHN5bW1ldHJpYyBrZXkgY29udGFpbmVyIHByb3ZpZGVzIGEgbWVhbiB0byBndWFy YW50ZWUgdGhlDQogICBpbnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uIGl0IGNvbnRhaW5zIHRo cm91Z2ggZGlnaXRhbCBzaWduYXR1cmVzLg0KICAgRm9yIGJlc3Qgc2VjdXJpdHkgcHJhY3RpY2Vz LCB0aGUgZGlnaXRhbCBzaWduYXR1cmUgb2YgdGhlIGNvbnRhaW5lcg0KICAgc2hvdWxkIGVuY29t cGFzcyB0aGUgZW50aXJlIHBheWxvYWQuICBUaGlzIHByb3ZpZGVzIGFzc3VyYW5jZXMgZm9yDQog ICB0aGUgaW50ZWdyaXR5IG9mIGFsbCBhdHRyaWJ1dGVzLiAgSXQgYWxzbyBhbGxvd3MgdmVyaWZp Y2F0aW9uIG9mIHRoZQ0KICAgaW50ZWdyaXR5IG9mIGEgZ2l2ZW4gcGF5bG9hZCBldmVuIGFmdGVy IHRoZSBjb250YWluZXIgaXMgZGVsaXZlcmVkDQogICB0aHJvdWdoIHRoZSBjb21tdW5pY2F0aW9u IGNoYW5uZWwgdG8gdGhlIHRhcmdldCBwZXJpbWV0ZXIgYW5kIGNoYW5uZWwNCiAgIG1lc3NhZ2Ug aW50ZWdyaXR5IGNoZWNrIGlzIG5vIGxvbmdlciBwb3NzaWJsZS4NCg0KOC4zLiAgUGF5bG9hZCBh dXRoZW50aWNpdHkNCg0KICAgVGhlIGRpZ2l0YWwgc2lnbmF0dXJlIG9mIHRoZSBwYXlsb2FkIGlz IHRoZSBwcmltYXJ5IHdheSBvZiBzaG93aW5nDQogICBpdHMgYXV0aGVudGljaXR5LiAgVGhlIHJl Y2lwaWVudCBvZiB0aGUgY29udGFpbmVyIG1heSB1c2UgdGhlIHB1YmxpYw0KICAga2V5IGFzc29j aWF0ZWQgd2l0aCB0aGUgc2lnbmF0dXJlIHRvIGFzc2VydCB0aGUgYXV0aGVudGljaXR5IG9mIHRo ZQ0KICAgc2VuZGVyIGJ5IHRyYWNpbmcgaXQgYmFjayB0byBhIHByZWxvYWRlZCBwdWJsaWMga2V5 IG9yIGNlcnRpZmljYXRlLg0KICAgTm90ZSB0aGF0IHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBvZiB0 aGUgcGF5bG9hZCBjYW4gYmUgY2hlY2tlZCBldmVuDQogICBhZnRlciB0aGUgY29udGFpbmVyIGhh cyBiZWVuIGRlbGl2ZXJlZCB0aHJvdWdoIHRoZSBzZWN1cmUgY2hhbm5lbCBvZg0KICAgY29tbXVu aWNhdGlvbi4NCg0KICAgQSB3ZWFrZXIgcGF5bG9hZCBhdXRoZW50aWNpdHkgZ3VhcmFudGVlIG1h eSBiZSBwcm92aWRlZCBieSB0aGUNCiAgIHRyYW5zcG9ydCBsYXllciBpZiBpdCBpcyBjb25maWd1 cmVkIHRvIGRpZ2VzdCBlYWNoIG1lc3NhZ2UgaXQNCiAgIHRyYW5zcG9ydHMuICBIb3dldmVyLCBu byBhdXRoZW50aWNpdHkgdmVyaWZpY2F0aW9uIGlzIHBvc3NpYmxlIG9uY2UNCiAgIHRoZSBjb250 YWluZXIgaXMgZGVsaXZlcmVkIGF0IHRoZSByZWNpcGllbnQgZW5kLiAgVGhpcyBhcHByb2FjaCBt YXkNCiAgIGJlIHVzZWZ1bCBpbiBjYXNlcyB3aGVyZSB0aGUgZGlnaXRhbCBzaWduYXR1cmUgb2Yg dGhlIGNvbnRhaW5lciBkb2VzDQogICBub3QgZW5jb21wYXNzIHRoZSBlbnRpcmUgcGF5bG9hZC4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBF eHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtleSBDb250YWluZXIgICAgICAgTm92ZW1i ZXIgMjAwNw0KDQoNCjkuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBhdXRob3JzIG9mIHRo aXMgZHJhZnQgd291bGQgbGlrZSB0byB0aGFuayB0aGUgZm9sbG93aW5nIHBlb3BsZQ0KICAgZm9y IHRoZWlyIGNvbnRyaWJ1dGlvbnMgYW5kIHN1cHBvcnQgdG8gbWFrZSB0aGlzIGEgYmV0dGVyDQog ICBzcGVjaWZpY2F0aW9uOiBBcG9zdG9sIFZhc3NpbGV2LCBKb24gTWFydGluc29uLCBTaWRkaGFy dCBCYWphaiwgU3R1DQogICBWZWF0aCwgS2V2aW4gTGV3aXMsIFBoaWxpcCBIYWxsYW0tQmFrZXIs IEhhbm5lcyBUc2Nob2ZlbmlnLCBBbmRyZWENCiAgIERvaGVydHksIE1hZ251cyBOeXN0cm9tLCBU aW0gTW9zZXMsIGFuZCBBbmRlcnMgUnVuZGdyZW4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAg ICAgICAgICAgICAgW1BhZ2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5 bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQoxMC4gIEFwcGVu ZGl4IEEgLSBFeGFtcGxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVycw0KDQogICBBbGwgZXhhbXBs ZXMgYXJlIHN5bnRhY3RpY2FsbHkgY29ycmVjdCBhbmQgY29tcGF0aWJsZSB3aXRoIHRoZSBYTUwN CiAgIHNjaGVtYSBpbiBzZWN0aW9uIDcuICBIb3dldmVyLCA8U2lnbmF0dXJlPiwgS2V5IDxWYWx1 ZT4gYW5kIEtleQ0KICAgPFZhbHVlRGlnZXN0PiBkYXRhIHZhbHVlcyBhcmUgZmljdGl0aW91cw0K DQoxMC4xLiAgU3ltbWV0cmljIEtleSBDb250YWluZXIgd2l0aCBhIHNpbmdsZSBOb24tRW5jcnlw dGVkIEhPVFAgU2VjcmV0DQogICAgICAgS2V5DQoNCg0KICAgPD94bWwgdmVyc2lvbj0iMS4wIiBl bmNvZGluZz0iVVRGLTgiPz4NCiAgIDxLZXlDb250YWluZXINCiAgICAgeG1sbnM9InVybjppZXRm OnBhcmFtczp4bWw6bnM6a2V5cHJvdjpjb250YWluZXI6MS4wIg0KICAgICB4bWxuczpkcz0iaHR0 cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyINCiAgICAgeG1sbnM6eHNpPSJodHRwOi8v d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSINCiAgICAgeHNpOnNjaGVtYUxvY2F0 aW9uPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmtleXByb3Y6Y29udGFpbmVyOjEuMA0KICAgICAg IGtleXByb3YtcHNrYy0xLjAueHNkIiBWZXJzaW9uPSIxLjAiPg0KICAgICAgIDxEZXZpY2U+DQog ICAgICAgICA8RGV2aWNlSWQ+DQogICAgICAgICAgIDxNYW51ZmFjdHVyZXI+VG9rZW4gTWFudWZh Y3R1cmVyPC9NYW51ZmFjdHVyZXI+DQogICAgICAgICAgIDxTZXJpYWxObz45ODc2NTQzMjE4ODwv U2VyaWFsTm8+DQogICAgICAgICAgIDxFeHBpcnk+MTIvMzEvMjAxMjwvRXhwaXJ5Pg0KICAgICAg ICAgPC9EZXZpY2VJZD4NCiAgICAgICAgIDxLZXkgS2V5QWxnb3JpdGhtPSJodHRwOi8vd3d3Lmll dGYub3JnL2tleXByb3YvcHNrYyNob3RwIg0KICAgICAgICAgICBLZXlJZD0iNzc2NTQzMjE4NzEi Pg0KICAgICAgICAgPElzc3Vlcj5DcmVkZW50aWFsIElzc3VlcjwvSXNzdWVyPg0KICAgICAgICAg ICA8VXNhZ2UgT1RQPSJ0cnVlIj4NCiAgICAgICAgICAgICA8UmVzcG9uc2VGb3JtYXQgRm9ybWF0 PSJERUNJTUFMIiBMZW5ndGg9IjYiLz4NCiAgICAgICAgICAgPC9Vc2FnZT4NCiAgICAgICAgICAg PEZyaWVuZGx5TmFtZT5NeUZpcnN0VG9rZW48L0ZyaWVuZGx5TmFtZT4NCiAgICAgICAgICAgPERh dGEgTmFtZT0iU0VDUkVUIj4NCiAgICAgICAgICAgICA8VmFsdWU+DQogICAgICAgICAgICAgICB6 T2txSkVOU3NoNmIyaGRYejFXQksvb3ByYlk9DQogICAgICAgICAgICAgPC9WYWx1ZT4NCiAgICAg ICAgICAgPC9EYXRhPg0KICAgICAgICAgICA8RGF0YSBOYW1lPSJDT1VOVEVSIj4NCiAgICAgICAg ICAgICA8VmFsdWU+QUFBQUFBQUFBQUE9PC9WYWx1ZT4NCiAgICAgICAgICAgPC9EYXRhPg0KICAg ICAgICAgICA8RXhwaXJ5PjEwLzMwLzIwMTI8L0V4cGlyeT4NCiAgICAgICAgIDwvS2V5Pg0KICAg ICAgIDwvRGV2aWNlPg0KICAgPC9LZXlDb250YWluZXI+DQoNCjEwLjIuICBTeW1tZXRyaWMgS2V5 IENvbnRhaW5lciB3aXRoIGEgc2luZ2xlIFBhc3N3b3JkLWJhc2VkIEVuY3J5cHRlZA0KICAgICAg IEhPVFAgU2VjcmV0IEtleQ0KDQoNCg0KDQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAg RXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVt YmVyIDIwMDcNCg0KDQogIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQog IDxLZXlDb250YWluZXINCiAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczprZXlwcm92 OmNvbnRhaW5lcjoxLjAiDQogICAgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkv eG1sZHNpZyMiDQogICAgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVt YS1pbnN0YW5jZSINCiAgICB4c2k6c2NoZW1hTG9jYXRpb249InVybjppZXRmOnBhcmFtczp4bWw6 bnM6a2V5cHJvdjpjb250YWluZXI6MS4wDQogICAgICBrZXlwcm92LXBza2MtMS4wLnhzZCIgVmVy c2lvbj0iMS4wIj4NCiAgICAgIDxFbmNyeXB0aW9uTWV0aG9kIEFsZ29yaXRobT0NCiAgICAgICAg ICJodHRwOi8vd3d3LnJzYXNlY3VyaXR5LmNvbS9yc2FsYWJzL3BrY3Mvc2NoZW1hcy9wa2NzLTUj cGJlczIiPg0KICAgICAgICA8UEJFRW5jcnlwdGlvblBhcmFtIEVuY3J5cHRpb25BbGdvcml0aG09 DQogICAgICAgICAgImh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI2t3LWFlczEyOC1j YmMiPg0KICAgICAgICAgIDxQQkVTYWx0Pnk2VHpja2VMUlF3PTwvUEJFU2FsdD4NCiAgICAgICAg ICA8UEJFSXRlcmF0aW9uQ291bnQ+MTAyNDwvUEJFSXRlcmF0aW9uQ291bnQ+DQogICAgICAgIDwv UEJFRW5jcnlwdGlvblBhcmFtPg0KICAgICAgICA8SVY+YzJGdGNHeGxhWFk9PC9JVj4NCiAgICAg IDwvRW5jcnlwdGlvbk1ldGhvZD4NCiAgICAgIDxEaWdlc3RNZXRob2QNCiAgICAgICAgQWxnb3Jp dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjaG1hYy1zaGExIi8+DQogICAg ICA8RGV2aWNlPg0KICAgICAgICA8RGV2aWNlSWQ+DQogICAgICAgICAgPE1hbnVmYWN0dXJlcj5U b2tlbiBNYW51ZmFjdHVyZXI8L01hbnVmYWN0dXJlcj4NCiAgICAgICAgICA8U2VyaWFsTm8+OTg3 NjU0MzIxODc8L1NlcmlhbE5vPg0KICAgICAgICAgIDxFeHBpcnk+MTIvMzEvMjAxMjwvRXhwaXJ5 Pg0KICAgICAgICA8L0RldmljZUlkPg0KICAgICAgICA8S2V5IEtleUFsZ29yaXRobT0iaHR0cDov L3d3dy5pZXRmLm9yZy9rZXlwcm92L3Bza2MjaG90cCINCiAgICAgICAgICBLZXlJZD0iNzc2NTQz MjE4NzAiPg0KICAgICAgICA8SXNzdWVyPkNyZWRlbnRpYWwgSXNzdWVyPC9Jc3N1ZXI+DQogICAg ICAgICAgPFVzYWdlIE9UUD0idHJ1ZSI+DQogICAgICAgICAgICA8UmVzcG9uc2VGb3JtYXQgRm9y bWF0PSJERUNJTUFMIiBMZW5ndGg9IjYiLz4NCiAgICAgICAgICA8L1VzYWdlPg0KICAgICAgICAg IDxGcmllbmRseU5hbWU+TXlGaXJzdFRva2VuPC9GcmllbmRseU5hbWU+DQogICAgICAgICAgPERh dGEgTmFtZT0iU0VDUkVUIj4NCiAgICAgICAgICAgIDxWYWx1ZT4NCiAgICAgICAgICAgICAgSlNQ VXlwM2F6T2txSkVOU3NoNmIyaGRYejFXQll5cHpKeEVyK2lrUUFhMjJNNlYvQmdaaFJnPT0NCiAg ICAgICAgICAgIDwvVmFsdWU+DQogICAgICAgICAgICA8VmFsdWVEaWdlc3Q+DQogICAgICAgICAg ICAgIGk4aitrcGJmS1FzU2x3bUpZUzk5bFE9PQ0KICAgICAgICAgICAgPC9WYWx1ZURpZ2VzdD4N CiAgICAgICAgICA8L0RhdGE+DQogICAgICAgICAgPERhdGEgTmFtZT0iQ09VTlRFUiI+DQogICAg ICAgICAgICA8VmFsdWU+QUFBQUFBQUFBQUE9PC9WYWx1ZT4NCiAgICAgICAgICA8L0RhdGE+DQog ICAgICAgICAgPEV4cGlyeT4xMC8zMC8yMDEyPC9FeHBpcnk+DQogICAgICAgIDwvS2V5Pg0KICAg ICAgPC9EZXZpY2U+DQogIDwvS2V5Q29udGFpbmVyPg0KDQoNCg0KDQoNCkhveWVyLCBldCBhbC4g ICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDksIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDQz XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBQb3J0YWJsZSBTeW1tZXRyaWMgS2V5IENvbnRhaW5l ciAgICAgICBOb3ZlbWJlciAyMDA3DQoNCg0KMTEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQog ICBbQ0FQXSAgICAgIE1hc3RlckNhcmQgSW50ZXJuYXRpb25hbCwgIkNoaXAgQXV0aGVudGljYXRp b24gUHJvZ3JhbQ0KICAgICAgICAgICAgICBGdW5jdGlvbmFsIEFyY2hpdGVjdHVyZSIsIFNlcHRl bWJlciAyMDA0Lg0KDQogICBbRFNLUFBdICAgICJEeW5hbWljIFN5bW1ldHJpYyBLZXkgUHJvdmlz aW9uaW5nIFByb3RvY29sIiwgSW50ZXJuZXQNCiAgICAgICAgICAgICAgRHJhZnQgSW5mb3JtYXRp b25hbCwgVVJMOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvDQogICAgICAgICAgICAgIGtleXBy b3YvZHJhZnQtZG9oZXJ0eS1rZXlwcm92LWRza3BwLTAwLnR4dCwgSnVuZSAyMDA3Lg0KDQogICBb SE9UUF0gICAgIE1SYWloaSwgRC4sICJIT1RQOiBBbiBITUFDLUJhc2VkIE9uZSBUaW1lIFBhc3N3 b3JkDQogICAgICAgICAgICAgIEFsZ29yaXRobSIsIFJGQyA0MjI2LA0KICAgICAgICAgICAgICBV Ukw6IGh0dHA6Ly9yZmMuc3Vuc2l0ZS5kay9yZmMvcmZjNDIyNi5odG1sLA0KICAgICAgICAgICAg ICBEZWNlbWJlciAyMDA1Lg0KDQogICBbT0FUSF0gICAgICJJbml0aWF0aXZlIGZvciBPcGVuIEF1 VEhlbnRpY2F0aW9uIiwNCiAgICAgICAgICAgICAgVVJMOiBodHRwOi8vd3d3Lm9wZW5hdXRoZW50 aWNhdGlvbi5vcmcuDQoNCiAgIFtPQVRIUmVmQXJjaF0NCiAgICAgICAgICAgICAgT0FUSCwgIlJl ZmVyZW5jZSBBcmNoaXRlY3R1cmUiLA0KICAgICAgICAgICAgICBVUkw6IGh0dHA6Ly93d3cub3Bl bmF1dGhlbnRpY2F0aW9uLm9yZywgVmVyc2lvbiAxLjAsIDIwMDUuDQoNCiAgIFtPQ1JBXSAgICAg TVJhaWhpLCBELiwgIk9DUkE6IE9BVEggQ2hhbGxlbmdlIFJlc3BvbnNlIEFsZ29yaXRobSIsDQog ICAgICAgICAgICAgIEludGVybmV0IERyYWZ0IEluZm9ybWF0aW9uYWwsIFVSTDogaHR0cDovL3d3 dy5pZXRmLm9yZy8NCiAgICAgICAgICAgICAgaW50ZXJuZXQtZHJhZnRzLw0KICAgICAgICAgICAg ICBkcmFmdC1tcmFpaGktbXV0dWFsLW9hdGgtaG90cC12YXJpYW50cy0wMS50eHQsDQogICAgICAg ICAgICAgIERlY2VtYmVyIDIwMDUuDQoNCiAgIFtQS0NTMV0gICAgS2FsaXNraSwgQi4sICJSRkMg MjQzNzogUEtDUyAjMTogUlNBIENyeXB0b2dyYXBoeQ0KICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9ucyBWZXJzaW9uIDIuMC4iLA0KICAgICAgICAgICAgICBVUkw6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjL3JmYzI0MzcudHh0LCBWZXJzaW9uOiAyLjAsDQogICAgICAgICAgICAgIE9jdG9iZXIg MTk5OC4NCg0KICAgW1BLQ1MxMl0gICBSU0EgTGFib3JhdG9yaWVzLCAiUEtDUyAjMTI6IFBlcnNv bmFsIEluZm9ybWF0aW9uIEV4Y2hhbmdlDQogICAgICAgICAgICAgIFN5bnRheCBTdGFuZGFyZCIs IFZlcnNpb24gMS4wLA0KICAgICAgICAgICAgICBVUkw6IGZ0cDovL2Z0cC5yc2FzZWN1cml0eS5j b20vcHViL3BrY3MvcGtjcy0xMi8uDQoNCiAgIFtQS0NTNV0gICAgUlNBIExhYm9yYXRvcmllcywg IlBLQ1MgIzU6IFBhc3N3b3JkLUJhc2VkIENyeXB0b2dyYXBoeQ0KICAgICAgICAgICAgICBTdGFu ZGFyZCIsIFZlcnNpb24gMi4wLA0KICAgICAgICAgICAgICBVUkw6IGZ0cDovL2Z0cC5yc2FzZWN1 cml0eS5jb20vcHViL3BrY3MvcGtjcy01LywNCiAgICAgICAgICAgICAgTWFyY2ggMTk5OS4NCg0K ICAgW1JGQzIxMTldICAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1 aXJlbWVudA0KICAgICAgICAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAx OTk3LA0KICAgICAgICAgICAgICA8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjExOS50eHQ+ Lg0KDQogICBbU2NobmVpZXJdDQogICAgICAgICAgICAgIFNjaG5laWVyLCBCLiwgIlNlY3JldHMg YW5kIExpZXM6IERpZ2l0aWFsIFNlY3VyaXR5IGluIGENCiAgICAgICAgICAgICAgTmV0d29ya2Vk IFdvcmxkIiwgIFdpbGV5IENvbXB1dGVyIFB1Ymxpc2hpbmcsIElTQk4gMC04NDkzLQ0KDQoNCg0K SG95ZXIsIGV0IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAg ICAgICAgW1BhZ2UgNDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJp YyBLZXkgQ29udGFpbmVyICAgICAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICAgICAgICAgICAgIDgy NTMtNywgMjAwMC4NCg0KICAgW1hNTEVOQ10gICBFYXN0bGFrZSwgRC4sICJYTUwgRW5jcnlwdGlv biBTeW50YXggYW5kIFByb2Nlc3NpbmcuIiwNCiAgICAgICAgICAgICAgVVJMOiBodHRwOi8vd3d3 LnczLm9yZy9UUi94bWxlbmMtY29yZS8sIERlY2VtYmVyIDIwMDIuDQoNCiAgIFtYTUxTSUddICAg RWFzdGxha2UsIEQuLCAiWE1MLVNpZ25hdHVyZSBTeW50YXggYW5kIFByb2Nlc3NpbmciLA0KICAg ICAgICAgICAgICBVUkw6IGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDIvUkVDLXhtbGRzaWctY29y ZS0yMDAyMDIxMi8sDQogICAgICAgICAgICAgIFczQyBSZWNvbW1lbmRhdGlvbiwgRmVicnVhcnkg MjAwMi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSG95ZXIsIGV0IGFsLiAgICAgICAg ICAgICAgRXhwaXJlcyBNYXkgOSwgMjAwOCAgICAgICAgICAgICAgICAgW1BhZ2UgNDVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIFBvcnRhYmxlIFN5bW1ldHJpYyBLZXkgQ29udGFpbmVyICAgICAg IE5vdmVtYmVyIDIwMDcNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgUGhpbGlwIEhveWVy DQogICBBY3RpdklkZW5pdHksIEluYy4NCiAgIDEwOSBCb3JvdWdoIEhpZ2ggU3RyZWV0DQogICBM b25kb24sIFNFMSAgMU5MDQogICBVSw0KDQogICBQaG9uZTogKzQ0ICgwKSAyMCA3NzQ0IDY0NTUN CiAgIEVtYWlsOiBQaGlsaXAuSG95ZXJAYWN0aXZpZGVudGl0eS5jb20NCg0KDQogICBNaW5nbGlh bmcgUGVpDQogICBWZXJpU2lnbiwgSW5jLg0KICAgNDg3IEUuIE1pZGRsZWZpZWxkIFJvYWQNCiAg IE1vdW50YWluIFZpZXcsIENBICA5NDA0Mw0KICAgVVNBDQoNCiAgIFBob25lOiArMSA2NTAgNDI2 IDUxNzMNCiAgIEVtYWlsOiBtcGVpQHZlcmlzaWduLmNvbQ0KDQoNCiAgIFNhbGFoIE1hY2hhbmkN CiAgIERpdmVyc2luZXQsIEluYy4NCiAgIDIyMjUgU2hlcHBhcmQgQXZlbnVlIEVhc3QNCiAgIFN1 aXRlIDE4MDENCiAgIFRvcm9udG8sIE9udGFyaW8gIE0ySiA1QzINCiAgIENhbmFkYQ0KDQogICBQ aG9uZTogKzEgNDE2IDc1NiAyMzI0IEV4dC4gMzIxDQogICBFbWFpbDogc21hY2hhbmlAZGl2ZXJz aW5ldC5jb20NCg0KDQogICBTaHVoIENoYW5nDQogICBHZW1hbHRvIEluYy4NCg0KICAgRW1haWw6 IHNodWguY2hhbmdAZ2VtYWx0by5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIb3ll ciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAgICAgICAgICAg ICBbUGFnZSA0Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgUG9ydGFibGUgU3ltbWV0cmljIEtl eSBDb250YWluZXIgICAgICAgTm92ZW1iZXIgMjAwNw0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRl bWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmlj dGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRo ZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhp cyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3Zp ZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdB TklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0KICAgVEhFIElOVEVS TkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJB TlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJ TkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRl bGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJk aW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5k ZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAg b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRz IGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJ UFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBh c3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGlt cGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRh aW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRz IG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMg dGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8g dGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdtZW50DQoN CiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRo ZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4NCg0KDQoN Cg0KDQpIb3llciwgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE1heSA5LCAyMDA4ICAgICAg ICAgICAgICAgICBbUGFnZSA0N10NCgwNCg0K ------_=_NextPart_001_01C82A91.6DC7EEBF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C82A91.6DC7EEBF-- From keyprov-bounces@ietf.org Mon Nov 19 04:56:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3MW-0005Q1-Vo; Mon, 19 Nov 2007 04:56:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3MV-0005MX-Fp for keyprov@ietf.org; Mon, 19 Nov 2007 04:56:15 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu3MO-0006lh-0i for keyprov@ietf.org; Mon, 19 Nov 2007 04:56:15 -0500 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAJ9pAKk016293 for ; Mon, 19 Nov 2007 01:51:10 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 01:55:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Nov 2007 01:55:10 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C957781D@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUA== From: "Pei, Mingliang" To: X-OriginalArrivalTime: 19 Nov 2007 09:55:11.0263 (UTC) FILETIME=[4645CAF0:01C82A92] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org In one of email thread discussions with Hannes's comments, we exchanged discussion about whether we should keep One Pass in this spec. I also post this here for broad discussion and feedbacks. There are a few concerns puzzling me about "One-pass" case. 1. Which use case listed in the spec does it try to address? 2. It looks to me that it increased complexity for interop and documentation. When we mention about binding with HTTP, for example, one pass is much useful with HTTP. Two-pass could be used. As a client server protocol, a Client always sends something to request; why not always send the hello message. Thomas's email today again asks for clarification what a client should send with HTTP. I would feel that two-pass can be simply used instead. 3. If we don't use HTTP with One Pass, then what is it? =20 A different transport would obviously be necessary to make the "one pass" really a "one pass". I would prefer to simplify the spec by not supporting one-pass case. Or we need to specify something for recommendation, and current spec lacks it. Or I may haved missed some sections about its powerness. Comments? Thanks, - Ming _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Nov 19 09:16:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7Q5-0008At-S3; Mon, 19 Nov 2007 09:16:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7Q4-0008Aa-TE for keyprov@ietf.org; Mon, 19 Nov 2007 09:16:12 -0500 Received: from dvnet26.diversinet.com ([207.245.6.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu7Q4-00030r-C8 for keyprov@ietf.org; Mon, 19 Nov 2007 09:16:12 -0500 Received: from dvnet26.diversinet.com(10.11.12.8) by mcafee_webshield.diversinet.com via smtp id 4bff_2296eb72_96ab_11dc_9be1_0002b3ca872d; Mon, 19 Nov 2007 09:24:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Date: Mon, 19 Nov 2007 09:15:18 -0500 Message-ID: <2AB4BF7823761E4E90BA9372C429F1A901FC17D9@DVNET26.DIVERSINET.COM> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C957781D@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUAAIynYg From: "Salah Machani" To: "Pei, Mingliang" , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Ming,=20 The use case for 'one pass' is described in section 3.8 - SMS based transport use case. I agree with the assessment that 'one pass' is redundant when using HTTP transport. We should clarify in the spec that the 'one pass' variant is applicable when SMS is used as transport and revisit the definition of 'ServerFinished' message in 'one pass' to ensure that the formatting and size is suitable for SMS transport. =20 Regards, Salah =20 -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Monday, November 19, 2007 4:55 AM To: keyprov@ietf.org Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? In one of email thread discussions with Hannes's comments, we exchanged discussion about whether we should keep One Pass in this spec. I also post this here for broad discussion and feedbacks. There are a few concerns puzzling me about "One-pass" case. 1. Which use case listed in the spec does it try to address? 2. It looks to me that it increased complexity for interop and documentation. When we mention about binding with HTTP, for example, one pass is much useful with HTTP. Two-pass could be used. As a client server protocol, a Client always sends something to request; why not always send the hello message. Thomas's email today again asks for clarification what a client should send with HTTP. I would feel that two-pass can be simply used instead. 3. If we don't use HTTP with One Pass, then what is it? =20 A different transport would obviously be necessary to make the "one pass" really a "one pass". I would prefer to simplify the spec by not supporting one-pass case. Or we need to specify something for recommendation, and current spec lacks it. Or I may haved missed some sections about its powerness. Comments? Thanks, - Ming _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov Notice to Recipient: The information in this message is meant only for t= he intended recipient of the transmission and may contain confidential or= privileged information. =0D Any copying, retransmittal, taking of action in reliance on, or other use= of the information in this communication by persons other than the addre= ssees is prohibited. =0D If you received this email in error, please immediately notify us and ple= ase delete or destroy all copies of this message.=0D This message may have been altered without your or our knowledge and the = sender does not accept any liability for any errors. Thank you.=0D _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Mon Nov 19 14:36:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCQ9-0003sb-49; Mon, 19 Nov 2007 14:36:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCQ7-0003sP-Ve for keyprov@ietf.org; Mon, 19 Nov 2007 14:36:36 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuCQ7-0006bp-2f for keyprov@ietf.org; Mon, 19 Nov 2007 14:36:35 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAJJVKpl001191; Mon, 19 Nov 2007 11:31:20 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 19:35:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Date: Mon, 19 Nov 2007 11:35:21 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C957787C@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <2AB4BF7823761E4E90BA9372C429F1A901FC17D9@DVNET26.DIVERSINET.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUAAIynYgAAi67KA= From: "Pei, Mingliang" To: "Salah Machani" , X-OriginalArrivalTime: 19 Nov 2007 19:35:21.0616 (UTC) FILETIME=[52DC2100:01C82AE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Salah, Thanks. Use case 3.8 was from earlier OATH DSKPP draft. In this case, a user triggers a requesst from a wired client (e.g. desktop) to do authentication, and asks a response to be sent via SMS. We had the "SharedSecretDeliveryMethod" in a request to indicate whether a response should be sent back in SMS or HTTP for this purpose. Considering the complexity that additional information may need to be submitted in a request with SMS preference, we decided to remove this negotiation. So I thought that SMS support was going to be out of scope for the complexity for now. To clarify and complete the "one-pass" case in the spec associated with SMS, shall we specify the additional information in ClientHello for the wired side? I incline to think that the typical flow in this case is a combo of two-pass HTTP and one-pass SMS response. - Ming > -----Original Message----- > From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 > Sent: Monday, November 19, 2007 6:15 AM > To: Pei, Mingliang; keyprov@ietf.org > Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 > Ming,=20 >=20 > The use case for 'one pass' is described in section 3.8 - SMS=20 > based transport use case. I agree with the assessment that=20 > 'one pass' is redundant when using HTTP transport. We should=20 > clarify in the spec that the 'one pass' variant is applicable=20 > when SMS is used as transport and revisit the definition of=20 > 'ServerFinished' message in 'one pass' to ensure that the=20 > formatting and size is suitable for SMS transport. =20 >=20 > Regards, >=20 >=20 > Salah > =20 > -----Original Message----- > From: Pei, Mingliang [mailto:mpei@verisign.com] > Sent: Monday, November 19, 2007 4:55 AM > To: keyprov@ietf.org > Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 >=20 > In one of email thread discussions with Hannes's comments, we=20 > exchanged > discussion about whether we should keep One Pass in this spec. I also > post this here for broad discussion and feedbacks. >=20 > There are a few concerns puzzling me about "One-pass" case. >=20 > 1. Which use case listed in the spec does it try to address? >=20 > 2. It looks to me that it increased complexity for interop and > documentation. >=20 > When we mention about binding with HTTP, for example, one pass is much > useful with HTTP. Two-pass could be used. As a client server=20 > protocol, a > Client always sends something to request; why not always send=20 > the hello > message. >=20 > Thomas's email today again asks for clarification what a client should > send with HTTP. I would feel that two-pass can be simply used instead. >=20 > 3. If we don't use HTTP with One Pass, then what is it? > =20 > A different transport would obviously be necessary to make the "one > pass" really a "one pass". >=20 > I would prefer to simplify the spec by not supporting=20 > one-pass case. Or > we need to specify something for recommendation, and current=20 > spec lacks > it. Or I may haved missed some sections about its powerness. >=20 > Comments? Thanks, >=20 > - Ming >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > Notice to Recipient: The information in this message is=20 > meant only for the intended recipient of the transmission and=20 > may contain confidential or privileged information.=20 >=20 > Any copying, retransmittal, taking of action in reliance on,=20 > or other use of the information in this communication by=20 > persons other than the addressees is prohibited. =20 >=20 > If you received this email in error, please immediately=20 > notify us and please delete or destroy all copies of this message. >=20 > This message may have been altered without your or our=20 > knowledge and the sender does not accept any liability for=20 > any errors. Thank you. >=20 >=20 >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 20 06:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQqj-0002VM-7l; Tue, 20 Nov 2007 06:01:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQqi-0002Ut-BZ for keyprov@ietf.org; Tue, 20 Nov 2007 06:01:00 -0500 Received: from dvnet26.diversinet.com ([207.245.6.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuQqh-0006cc-IW for keyprov@ietf.org; Tue, 20 Nov 2007 06:01:00 -0500 Received: from dvnet26.diversinet.com(10.11.12.8) by mcafee_webshield.diversinet.com via smtp id 3593_0572efb0_9759_11dc_9051_0002b3ca872d; Tue, 20 Nov 2007 06:09:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Date: Tue, 20 Nov 2007 06:00:01 -0500 Message-ID: <2AB4BF7823761E4E90BA9372C429F1A901FC18C9@DVNET26.DIVERSINET.COM> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C957787C@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUAAIynYgAAi67KAAIrjXIA== From: "Salah Machani" To: "Pei, Mingliang" , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Ming, If there was a consensus to drop SMS support then we should remove the use case in 3.8. Otherwise, we need to have considerations in specification for dskpp run over SMS. Note that the SMS push with ServerFinished data does not necessary need to be triggered by a ClientHello from a desktop computer. This could be sent to the phone as a result of the user registering with the provisioning service through the web or other channels. It will be a true 'one pass' as specified in the draft. Regards, Salah -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Monday, November 19, 2007 2:35 PM To: Salah Machani; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Salah, Thanks. Use case 3.8 was from earlier OATH DSKPP draft. In this case, a user triggers a requesst from a wired client (e.g. desktop) to do authentication, and asks a response to be sent via SMS. We had the "SharedSecretDeliveryMethod" in a request to indicate whether a response should be sent back in SMS or HTTP for this purpose. Considering the complexity that additional information may need to be submitted in a request with SMS preference, we decided to remove this negotiation. So I thought that SMS support was going to be out of scope for the complexity for now. To clarify and complete the "one-pass" case in the spec associated with SMS, shall we specify the additional information in ClientHello for the wired side? I incline to think that the typical flow in this case is a combo of two-pass HTTP and one-pass SMS response. - Ming > -----Original Message----- > From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 > Sent: Monday, November 19, 2007 6:15 AM > To: Pei, Mingliang; keyprov@ietf.org > Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 > Ming,=20 >=20 > The use case for 'one pass' is described in section 3.8 - SMS=20 > based transport use case. I agree with the assessment that=20 > 'one pass' is redundant when using HTTP transport. We should=20 > clarify in the spec that the 'one pass' variant is applicable=20 > when SMS is used as transport and revisit the definition of=20 > 'ServerFinished' message in 'one pass' to ensure that the=20 > formatting and size is suitable for SMS transport. =20 >=20 > Regards, >=20 >=20 > Salah > =20 > -----Original Message----- > From: Pei, Mingliang [mailto:mpei@verisign.com] > Sent: Monday, November 19, 2007 4:55 AM > To: keyprov@ietf.org > Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 >=20 > In one of email thread discussions with Hannes's comments, we=20 > exchanged > discussion about whether we should keep One Pass in this spec. I also > post this here for broad discussion and feedbacks. >=20 > There are a few concerns puzzling me about "One-pass" case. >=20 > 1. Which use case listed in the spec does it try to address? >=20 > 2. It looks to me that it increased complexity for interop and > documentation. >=20 > When we mention about binding with HTTP, for example, one pass is much > useful with HTTP. Two-pass could be used. As a client server=20 > protocol, a > Client always sends something to request; why not always send=20 > the hello > message. >=20 > Thomas's email today again asks for clarification what a client should > send with HTTP. I would feel that two-pass can be simply used instead. >=20 > 3. If we don't use HTTP with One Pass, then what is it? > =20 > A different transport would obviously be necessary to make the "one > pass" really a "one pass". >=20 > I would prefer to simplify the spec by not supporting=20 > one-pass case. Or > we need to specify something for recommendation, and current=20 > spec lacks > it. Or I may haved missed some sections about its powerness. >=20 > Comments? Thanks, >=20 > - Ming >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > Notice to Recipient: The information in this message is=20 > meant only for the intended recipient of the transmission and=20 > may contain confidential or privileged information.=20 >=20 > Any copying, retransmittal, taking of action in reliance on,=20 > or other use of the information in this communication by=20 > persons other than the addressees is prohibited. =20 >=20 > If you received this email in error, please immediately=20 > notify us and please delete or destroy all copies of this message. >=20 > This message may have been altered without your or our=20 > knowledge and the sender does not accept any liability for=20 > any errors. Thank you. >=20 >=20 >=20 Notice to Recipient: The information in this message is meant only for t= he intended recipient of the transmission and may contain confidential or= privileged information. =0D Any copying, retransmittal, taking of action in reliance on, or other use= of the information in this communication by persons other than the addre= ssees is prohibited. =0D If you received this email in error, please immediately notify us and ple= ase delete or destroy all copies of this message.=0D This message may have been altered without your or our knowledge and the = sender does not accept any liability for any errors. Thank you.=0D _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 20 13:43:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY3u-0006V1-Ta; Tue, 20 Nov 2007 13:43:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY3t-0006Uk-G1 for keyprov@ietf.org; Tue, 20 Nov 2007 13:43:05 -0500 Received: from v29431.1blu.de ([88.84.142.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuY3s-0005Pd-Q6 for keyprov@ietf.org; Tue, 20 Nov 2007 13:43:05 -0500 Received: (qmail 19642 invoked from network); 20 Nov 2007 19:43:03 +0100 Received: from 213-239-234-98.clients.your-server.de (HELO ?213.239.196.40?) (213.239.234.98) by v29431.1blu.de with SMTP; 20 Nov 2007 19:43:03 +0100 Content-Type: text/plain; charset=utf-8 To: keyprov@ietf.org, mpei@verisign.com From: Andrea Doherty Date: Tue, 20 Nov 2007 18:20:14 +0000 X-Roundup-Name: KEYPROV Roundup Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1195582814.31.0.172330165255.issue37@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [KEYPROV] [issue37] Should support for one-pass be removed from DSKPP document? X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: KEYPROV Roundup Issue Tracker List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org New submission from Andrea Doherty : Ming wrote: There are a few concerns puzzling me about "One-pass" case. 1=2E Which use case listed in the spec does it try to address? 2=2E It looks to me that it increased complexity for interop and documentation. 3=2E If we don't use HTTP with One Pass, then what is it? =20 A different transport would obviously be necessary to make the "one pass" really a "one pass". I would prefer to simplify the spec by not supporting one-pass case. Or we need to specify something for recommendation, and current spec lacks it. Or I may haved missed some sections about its powerness. ---------- assignedto: mpei messages: 86 nosy: andrea, keyprov, mpei priority: feature status: chatting title: Should support for one-pass be removed from DSKPP document? _________________________________________________________ KEYPROV Roundup Issue Tracker _________________________________________________________ _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 20 14:56:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZCv-00032C-25; Tue, 20 Nov 2007 14:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY1E-0001kL-3D for keyprov@ietf.org; Tue, 20 Nov 2007 13:40:20 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuY1B-00047Q-CZ for keyprov@ietf.org; Tue, 20 Nov 2007 13:40:20 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAKIe9c4020215; Tue, 20 Nov 2007 13:40:09 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 20 Nov 2007 13:40:09 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAKIe5Vm026528; Tue, 20 Nov 2007 13:40:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Date: Tue, 20 Nov 2007 13:40:05 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D3DC7DF@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <2AB4BF7823761E4E90BA9372C429F1A901FC18C9@DVNET26.DIVERSINET.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUAAIynYgAAi67KAAIrjXIAAQfqxg References: <3E5A2F1AD44F5E49A74F79AB47C0C0C957787C@mou1wnexmb10.vcorp.ad.vrsn.com> <2AB4BF7823761E4E90BA9372C429F1A901FC18C9@DVNET26.DIVERSINET.COM> From: "Doherty, Andrea" To: "Salah Machani" , "Pei, Mingliang" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Tue, 20 Nov 2007 14:56:27 -0500 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Salah is correct that we should remove use case 3.8 from the DSKPP doc. As was agreed at the meeting in Chicago, if someone wants to pick up the use case and define how DSKPP can be extended/implemented to support it, then they can create a separate document. Andrea -----Original Message----- From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 Sent: Tuesday, November 20, 2007 6:00 AM To: Pei, Mingliang; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Ming, If there was a consensus to drop SMS support then we should remove the use case in 3.8. Otherwise, we need to have considerations in specification for dskpp run over SMS. Note that the SMS push with ServerFinished data does not necessary need to be triggered by a ClientHello from a desktop computer. This could be sent to the phone as a result of the user registering with the provisioning service through the web or other channels. It will be a true 'one pass' as specified in the draft. Regards, Salah -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Monday, November 19, 2007 2:35 PM To: Salah Machani; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Salah, Thanks. Use case 3.8 was from earlier OATH DSKPP draft. In this case, a user triggers a requesst from a wired client (e.g. desktop) to do authentication, and asks a response to be sent via SMS. We had the "SharedSecretDeliveryMethod" in a request to indicate whether a response should be sent back in SMS or HTTP for this purpose. Considering the complexity that additional information may need to be submitted in a request with SMS preference, we decided to remove this negotiation. So I thought that SMS support was going to be out of scope for the complexity for now. To clarify and complete the "one-pass" case in the spec associated with SMS, shall we specify the additional information in ClientHello for the wired side? I incline to think that the typical flow in this case is a combo of two-pass HTTP and one-pass SMS response. - Ming > -----Original Message----- > From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 > Sent: Monday, November 19, 2007 6:15 AM > To: Pei, Mingliang; keyprov@ietf.org > Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 > Ming,=20 >=20 > The use case for 'one pass' is described in section 3.8 - SMS=20 > based transport use case. I agree with the assessment that=20 > 'one pass' is redundant when using HTTP transport. We should=20 > clarify in the spec that the 'one pass' variant is applicable=20 > when SMS is used as transport and revisit the definition of=20 > 'ServerFinished' message in 'one pass' to ensure that the=20 > formatting and size is suitable for SMS transport. =20 >=20 > Regards, >=20 >=20 > Salah > =20 > -----Original Message----- > From: Pei, Mingliang [mailto:mpei@verisign.com] > Sent: Monday, November 19, 2007 4:55 AM > To: keyprov@ietf.org > Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 >=20 > In one of email thread discussions with Hannes's comments, we=20 > exchanged > discussion about whether we should keep One Pass in this spec. I also > post this here for broad discussion and feedbacks. >=20 > There are a few concerns puzzling me about "One-pass" case. >=20 > 1. Which use case listed in the spec does it try to address? >=20 > 2. It looks to me that it increased complexity for interop and > documentation. >=20 > When we mention about binding with HTTP, for example, one pass is much > useful with HTTP. Two-pass could be used. As a client server=20 > protocol, a > Client always sends something to request; why not always send=20 > the hello > message. >=20 > Thomas's email today again asks for clarification what a client should > send with HTTP. I would feel that two-pass can be simply used instead. >=20 > 3. If we don't use HTTP with One Pass, then what is it? > =20 > A different transport would obviously be necessary to make the "one > pass" really a "one pass". >=20 > I would prefer to simplify the spec by not supporting=20 > one-pass case. Or > we need to specify something for recommendation, and current=20 > spec lacks > it. Or I may haved missed some sections about its powerness. >=20 > Comments? Thanks, >=20 > - Ming >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > Notice to Recipient: The information in this message is=20 > meant only for the intended recipient of the transmission and=20 > may contain confidential or privileged information.=20 >=20 > Any copying, retransmittal, taking of action in reliance on,=20 > or other use of the information in this communication by=20 > persons other than the addressees is prohibited. =20 >=20 > If you received this email in error, please immediately=20 > notify us and please delete or destroy all copies of this message. >=20 > This message may have been altered without your or our=20 > knowledge and the sender does not accept any liability for=20 > any errors. Thank you. >=20 >=20 >=20 Notice to Recipient: The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information.=20 Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited. =20 If you received this email in error, please immediately notify us and please delete or destroy all copies of this message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors. Thank you. _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 20 14:56:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZCv-00032I-5W; Tue, 20 Nov 2007 14:56:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYA3-0005Oy-Ln for keyprov@ietf.org; Tue, 20 Nov 2007 13:49:27 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuYA2-0005c0-Ry for keyprov@ietf.org; Tue, 20 Nov 2007 13:49:27 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAKInQuK000187 for ; Tue, 20 Nov 2007 13:49:26 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for ; Tue, 20 Nov 2007 13:49:26 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAKIlnuf005625 for ; Tue, 20 Nov 2007 13:49:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [KEYPROV] Do we need "One-pass" support in DSKPP? Date: Tue, 20 Nov 2007 13:48:38 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D3DC803@rsana-ex-hq1.NA.RSA.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] Do we need "One-pass" support in DSKPP? Thread-Index: AcgY1D/9HKENSGGQT6C9s/8hVRyjjQCftcpAA0qv4dAAhOxzUAAIynYgAAi67KAAIrjXIAAQfqxgAABcIKA= From: "Doherty, Andrea" To: X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 X-Mailman-Approved-At: Tue, 20 Nov 2007 14:56:27 -0500 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Message bounced (see below); trying again... -----Original Message----- From: Doherty, Andrea=20 Sent: Tuesday, November 20, 2007 1:40 PM To: 'Salah Machani'; Pei, Mingliang; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Salah is correct that we should remove use case 3.8 from the DSKPP doc. As was agreed at the meeting in Chicago, if someone wants to pick up the use case and define how DSKPP can be extended/implemented to support it, then they can create a separate document. Andrea -----Original Message----- From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 Sent: Tuesday, November 20, 2007 6:00 AM To: Pei, Mingliang; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Ming, If there was a consensus to drop SMS support then we should remove the use case in 3.8. Otherwise, we need to have considerations in specification for dskpp run over SMS. Note that the SMS push with ServerFinished data does not necessary need to be triggered by a ClientHello from a desktop computer. This could be sent to the phone as a result of the user registering with the provisioning service through the web or other channels. It will be a true 'one pass' as specified in the draft. Regards, Salah -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Monday, November 19, 2007 2:35 PM To: Salah Machani; keyprov@ietf.org Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? Salah, Thanks. Use case 3.8 was from earlier OATH DSKPP draft. In this case, a user triggers a requesst from a wired client (e.g. desktop) to do authentication, and asks a response to be sent via SMS. We had the "SharedSecretDeliveryMethod" in a request to indicate whether a response should be sent back in SMS or HTTP for this purpose. Considering the complexity that additional information may need to be submitted in a request with SMS preference, we decided to remove this negotiation. So I thought that SMS support was going to be out of scope for the complexity for now. To clarify and complete the "one-pass" case in the spec associated with SMS, shall we specify the additional information in ClientHello for the wired side? I incline to think that the typical flow in this case is a combo of two-pass HTTP and one-pass SMS response. - Ming > -----Original Message----- > From: Salah Machani [mailto:SMachani@DIVERSINET.COM]=20 > Sent: Monday, November 19, 2007 6:15 AM > To: Pei, Mingliang; keyprov@ietf.org > Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 > Ming,=20 >=20 > The use case for 'one pass' is described in section 3.8 - SMS=20 > based transport use case. I agree with the assessment that=20 > 'one pass' is redundant when using HTTP transport. We should=20 > clarify in the spec that the 'one pass' variant is applicable=20 > when SMS is used as transport and revisit the definition of=20 > 'ServerFinished' message in 'one pass' to ensure that the=20 > formatting and size is suitable for SMS transport. =20 >=20 > Regards, >=20 >=20 > Salah > =20 > -----Original Message----- > From: Pei, Mingliang [mailto:mpei@verisign.com] > Sent: Monday, November 19, 2007 4:55 AM > To: keyprov@ietf.org > Subject: [KEYPROV] Do we need "One-pass" support in DSKPP? >=20 >=20 > In one of email thread discussions with Hannes's comments, we=20 > exchanged > discussion about whether we should keep One Pass in this spec. I also > post this here for broad discussion and feedbacks. >=20 > There are a few concerns puzzling me about "One-pass" case. >=20 > 1. Which use case listed in the spec does it try to address? >=20 > 2. It looks to me that it increased complexity for interop and > documentation. >=20 > When we mention about binding with HTTP, for example, one pass is much > useful with HTTP. Two-pass could be used. As a client server=20 > protocol, a > Client always sends something to request; why not always send=20 > the hello > message. >=20 > Thomas's email today again asks for clarification what a client should > send with HTTP. I would feel that two-pass can be simply used instead. >=20 > 3. If we don't use HTTP with One Pass, then what is it? > =20 > A different transport would obviously be necessary to make the "one > pass" really a "one pass". >=20 > I would prefer to simplify the spec by not supporting=20 > one-pass case. Or > we need to specify something for recommendation, and current=20 > spec lacks > it. Or I may haved missed some sections about its powerness. >=20 > Comments? Thanks, >=20 > - Ming >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > Notice to Recipient: The information in this message is=20 > meant only for the intended recipient of the transmission and=20 > may contain confidential or privileged information.=20 >=20 > Any copying, retransmittal, taking of action in reliance on,=20 > or other use of the information in this communication by=20 > persons other than the addressees is prohibited. =20 >=20 > If you received this email in error, please immediately=20 > notify us and please delete or destroy all copies of this message. >=20 > This message may have been altered without your or our=20 > knowledge and the sender does not accept any liability for=20 > any errors. Thank you. >=20 >=20 >=20 Notice to Recipient: The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information.=20 Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited. =20 If you received this email in error, please immediately notify us and please delete or destroy all copies of this message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors. Thank you. _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Tue Nov 20 14:56:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZCu-000326-Qq; Tue, 20 Nov 2007 14:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXfX-0000pb-A5 for keyprov@ietf.org; Tue, 20 Nov 2007 13:17:55 -0500 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXfF-0002l4-LM for keyprov@ietf.org; Tue, 20 Nov 2007 13:17:54 -0500 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 5567425ED46; Tue, 20 Nov 2007 19:17:36 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WKH9Y8YH; Tue, 20 Nov 2007 19:23:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Nov 2007 19:17:40 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC401562335@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSKC wrapped key question Thread-Index: AcgroaLfWu+4E5eeQRmAAwjQRCNIjw== From: "James Holland" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb X-Mailman-Approved-At: Tue, 20 Nov 2007 14:56:27 -0500 Cc: keyprov@ietf.org Subject: [KEYPROV] PSKC wrapped key question X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0608212347==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0608212347== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82BA1.E7C316C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82BA1.E7C316C5 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Ming, =20 I am a colleague of Philip Hoyer and I have a question = about the mandatory digest of key material within the PSKC document. The = latest draft state: - =20 5.1.1. Data (OPTIONAL) =20 Defines the data attributes of the symmetric key. Each is a name value pair which has both a base64 encoded value and a base 64 encoded ValueDigest. The value can be encrypted. If the container has been encrypted the ValueDigest MUST be populated with the digest of the unencrypted value. =20 =20 In our scenario we receive a request from a 3rd party to generate a 3DES = key in a HSM. In the request they pass a transport certificate that has = their public RSA key. With this public RSA key we wrap the generated key = for export to the requesting 3rd party. However, as we never have the = generated key in =93plain=94 outside the HSM we cannot generate a digest = of the key material it to be put into the PSKC document. The wrapped key = is returned from the HSM in the PSKC#8 format which we return in the = document. =20 So, in this scenario, a man in the middle attack my intercept the = request and return their own wrapped key within the document, as they = too have the transport key. What would you recommend as a possible = solution to this, if any?=20 =20 Also, in the scenario when there has been a key exchange ceremony = between the two parties, would this be a valid case for no mandatory = digest of the key material, with the wrapped key returned? =20 =20 =20 Regards, =20 James Holland Product Architect - ActivIdentity Mob: +44 787 6197 626 London Office Tel: +44 207 744 6460 Skype on HYPERLINK "callto://hoggmania/"callto://hoggmania/ =20 P Think before you print =20 The information contained in this email message may be privileged, = confidential and protected from disclosure. If you are not the intended = recipient, any dissemination, distribution or copying is strictly = prohibited. If you think that you have received this email message in = error, please notify the sender by reply email and delete the message = and any attachments. =20 No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date: = 19/11/2007 19:05 =20 ------_=_NextPart_001_01C82BA1.E7C316C5 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Hi Ming,

 

         &= nbsp;      I am a colleague of Philip Hoyer and I have a question about the mandatory = digest of key material within the PSKC document. The latest draft state: = -

 

5.1.1.  Data (OPTIONAL)

 

   Defines the data attributes of the = symmetric key.  Each is a name

   value pair which has both a base64 = encoded value and a base 64

   encoded ValueDigest.  The = value can be encrypted.  If the container

   has been encrypted the ValueDigest = MUST be populated with the digest

   of the unencrypted = value.

 

 

In our scenario we receive a request from a = 3rd party to generate a 3DES key in a HSM. In the request they pass a = transport certificate that has their public RSA key. With this public RSA key we = wrap the generated key for export to the requesting 3rd party. = However, as we never have the generated key in “plain” outside the HSM we = cannot generate a digest of the key material it to be put into the PSKC = document. The wrapped key is returned from the HSM in the  PSKC#8 format which we = return in the document.

 

So, in this scenario,  a man in the middle = attack my intercept the request and return their own wrapped key within the = document, as they too have the transport key. What would you recommend as a possible solution to this, if any?

 

Also, in the scenario when there has been a key = exchange ceremony between the two parties, would this be a valid case for no mandatory = digest of the key material, with the wrapped key returned?

 

 

 

Regards,=

 

James Holland

Product Architect - ActivIdentity

Mob: +44 787 6197 626

London Office Tel: +44 207 744 6460
Skype on callto://hoggmania/

=

 

P T= hink before you print

 

The information contained in this email message may be privileged, = confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you = think that you have received this email message in error, please notify the = sender by reply email and delete the message and any = attachments.

 


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date: = 19/11/2007 19:05

------_=_NextPart_001_01C82BA1.E7C316C5-- --===============0608212347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0608212347==-- From keyprov-bounces@ietf.org Tue Nov 20 15:15:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZVG-0001qT-Qn; Tue, 20 Nov 2007 15:15:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUt-0000yK-Bc; Tue, 20 Nov 2007 15:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0007kV-Qh; Tue, 20 Nov 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AEDE626E7B; Tue, 20 Nov 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuZUr-0006Ct-GM; Tue, 20 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 15:15:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: keyprov@ietf.org Subject: [KEYPROV] I-D ACTION:draft-ietf-keyprov-portable-symmetric-key-container-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Portable Symmetric Key Container Author(s) : P. Hoyer, et al. Filename : draft-ietf-keyprov-portable-symmetric-key-container-02.txt Pages : 47 Date : 2007-11-20 This document specifies a symmetric key format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-portable-symmetric-key-container-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-20140543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-keyprov-portable-symmetric-key-container-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20140543.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --NextPart-- From keyprov-bounces@ietf.org Tue Nov 20 15:35:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZod-00075X-BZ; Tue, 20 Nov 2007 15:35:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZa9-0001MU-6t for keyprov@ietf.org; Tue, 20 Nov 2007 15:20:30 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZZy-0001mf-Uh for keyprov@ietf.org; Tue, 20 Nov 2007 15:20:28 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAKKFHdh012260 for ; Tue, 20 Nov 2007 12:15:17 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 20:19:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C82BB2.A1E8DA11" Subject: FW: [KEYPROV] I-D ACTION:draft-ietf-keyprov-portable-symmetric-key-container-02.txt Date: Tue, 20 Nov 2007 12:19:19 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9577969@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] I-D ACTION:draft-ietf-keyprov-portable-symmetric-key-container-02.txt Thread-Index: Acgrsf/ovls0t4Z/Ts+NYJ7eBMXSlAAAJtAg From: "Pei, Mingliang" To: X-OriginalArrivalTime: 20 Nov 2007 20:19:20.0264 (UTC) FILETIME=[A2079C80:01C82BB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C82BB2.A1E8DA11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, November 20, 2007 12:15 PM To: i-d-announce@ietf.org Cc: keyprov@ietf.org Subject: [KEYPROV] I-D ACTION:draft-ietf-keyprov-portable-symmetric-key-container-02.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Portable Symmetric Key Container Author(s) : P. Hoyer, et al. Filename : draft-ietf-keyprov-portable-symmetric-key-container-02.txt Pages : 47 Date : 2007-11-20 =09 This document specifies a symmetric key format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetri c-key-container-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-portable-symmetric-key-container-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02. txt". =09 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_001_01C82BB2.A1E8DA11 Content-Type: application/octet-stream; name="ATT387919.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT387919.TXT Content-Disposition: attachment; filename="ATT387919.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0xMS0yMDE0MDU0My5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWtleXByb3YtcG9y dGFibGUtc3ltbWV0cmljLWtleS1jb250YWluZXItMDIudHh0DQo= ------_=_NextPart_001_01C82BB2.A1E8DA11 Content-Type: application/octet-stream; name="draft-ietf-keyprov-portable-symmetric-key-container-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-keyprov-portable-symmetric-key-container-02.URL Content-Disposition: attachment; filename="draft-ietf-keyprov-portable-symmetric-key-container-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWtleXByb3YtcG9ydGFibGUtc3ltbWV0cmljLWtleS1jb250YWluZXItMDIu dHh0DQo= ------_=_NextPart_001_01C82BB2.A1E8DA11 Content-Type: text/plain; name="ATT387920.txt" Content-Transfer-Encoding: base64 Content-Description: ATT387920.txt Content-Disposition: attachment; filename="ATT387920.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCktFWVBST1Yg bWFpbGluZyBsaXN0DQpLRVlQUk9WQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9rZXlwcm92DQo= ------_=_NextPart_001_01C82BB2.A1E8DA11 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov ------_=_NextPart_001_01C82BB2.A1E8DA11-- From keyprov-bounces@ietf.org Tue Nov 20 16:07:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaJ9-000646-GD; Tue, 20 Nov 2007 16:06:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaJ7-00063o-WF for keyprov@ietf.org; Tue, 20 Nov 2007 16:06:58 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuaJ5-0002FE-NM for keyprov@ietf.org; Tue, 20 Nov 2007 16:06:57 -0500 Received: (qmail invoked by alias); 20 Nov 2007 21:06:54 -0000 Received: from p5498411A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.65.26] by mail.gmx.net (mp016) with SMTP; 20 Nov 2007 22:06:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19vM1BApflvx7tXKYHqGIy07HqIwgOIePJ/TWWPni VR0O6JhH9NTr0m Message-ID: <47434C6D.3040308@gmx.net> Date: Tue, 20 Nov 2007 22:06:53 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [KEYPROV] Agenda X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Here is the agenda for the meeting: http://www3.ietf.org/proceedings/07dec/agenda/keyprov.txt _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 23 11:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivb3B-0007I7-2T; Fri, 23 Nov 2007 11:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivb39-0007HN-DP for keyprov@ietf.org; Fri, 23 Nov 2007 11:06:39 -0500 Received: from frhub1.activcard.fr ([91.151.120.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivb34-0004nJ-BT for keyprov@ietf.org; Fri, 23 Nov 2007 11:06:39 -0500 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 4765425ED54; Fri, 23 Nov 2007 17:06:29 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WKH9Z1W6; Fri, 23 Nov 2007 17:12:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Date: Fri, 23 Nov 2007 17:08:21 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA251E@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <3E5A2F1AD44F5E49A74F79AB47C0C0C9577460@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMAQ13Z+QAMedW/ACITewwA== References: <017630AA6DF2DF4EBC1DD4454F8EE2970D23AB0B@rsana-ex-hq1.NA.RSA.NET> <3E5A2F1AD44F5E49A74F79AB47C0C0C9577460@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Philip Hoyer" To: "Pei, Mingliang" , "Doherty, Andrea" , "KEYPROV Roundup Issue Tracker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b382e0fda7380faa630530317e47f8e4 Cc: "M'Raihi, David" , "Bajaj, Siddharth" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0309604482==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0309604482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82DEB.16A583EE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82DEB.16A583EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrea and Ming, As we discussed in the PSKC call I would like to explain a new proposal. I would like to keep the way to transmit the PIN value as a key. We though want the flexibility to define possibly multiple PINs and which keys are protected by the PIN. Hence I would like to introduce an element called PINPolicy Local This will replace the accessrule element. So to take the example of a PIN protected HOTP token with no encryption based on the latest draft with highlights: Token Manufacturer 98765432188 12/31/2012 Credential Issuer MyFirstToken zOkqJENSsh6b2hdXz1WBK/oprbY=3D AAAAAAAAAAA=3D 10/30/2012 Local =09 Credential Issuer RandomInitialTokenPIN zOkqJENSsh6b2hdXz1WBK/oprbY=3D In this way we can specifically say what keys are protected by which PINs and re-use most of our constructs in Key that would apply to the PIN such as the format the way to encrypt etc etc. Thoughts? Philip -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Tuesday, November 13, 2007 1:48 AM To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? I have chatted with Philip / Salah about my comments this afternoon while I was almost done my reply of this email. I sent it anyway now for broad review. Our meeting minutes from Philip later will contain other proposed changes in our discussion. 1. A PIN is associated with a key; we need to define a better way to associate with them when we carry PIN in a separate Key type. - The current proposal assumes that all keys in the same "Device" type will associate to the PIN credential in the same Device. - This has a limitation for "PREPEND" case where a device may have multiple keys, and each key has its own PIN as part of server authentication. 2. There is use case when a PIN is per device, instead of per key, for the "Local" access usage.=20 So I prefer defining PIN credential inside DeviceType, and refered by KeyType by an attribute or element, and DeviceType. 3. PIN policy is fine to have its own type. The AccessRule and PINUsageModeType should combine to be a PIN usage policy. If we are treating PIN as a separate credential, it is more consistent to make PIN usage policy part of Usage, I think. Thanks, - Ming =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, November 08, 2007 12:31 PM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Philip, >=20 > Thank you for your proposal. Here are a few comments: >=20 > 1. By do you mean "PIN is=20 > enabled"? Is the reverse true, that userPIN=3D"false"/> indicates PINless operation from a server's=20 > point of view?=20 >=20 > 2. Instead of , providing=20 > a PINUsageModeType would be more extensible and implementable: > > > > > > > >=20 > 3. Anders brought to my attention that a local PIN is needed=20 > instead of a server PIN in some scenarios. The device=20 > issuer, in this case, would also have a PIN policy that could=20 > differ from the policy of a server PIN. Anders provided the=20 > following example, which is taken from another=20 > standardization effort in the workings ("PKI for Web 2.0"): >=20 > // The following is sent down to the client by the issuer: >=20 > >=20 > // Request a key without PIN protection. >=20 > > > > > >=20 > // Request a set of keys with PIN protection. > // The specified policy disallows 11122 but accepts 11223 //=20 > 654321 would not be accepted either (sequence) >=20 > PatternRestrictions=3D"three-in-a-row sequences"> >=20 > // The next element is optional and is a way of grouping PINs=20 > // so that the user either only has to specify a single PIN=20 > // for a set of keys, or one unique PIN per key. >=20 > >=20 > > > > > > > > > > >=20 > >=20 > >=20 > >=20 > Your thoughts? > Andrea=20 >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Thursday, October 18, 2007 6:16 AM > To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Andrea, > You are right I have not addressed the Pin policy issue. >=20 > I would like to though.=20 >=20 > Since you seem to have a good idea of the requirements would=20 > you be able to help? >=20 > I suggest we create a new type called PINPolicy that contains=20 > the data required to be submitted. >=20 > So currently PIN usage I can think of is: > -KEY_ACCESS_CHECK (this check the pin on the device to allow=20 > access to a key for algorithms) -USED_IN_ALGO (used during=20 > calculation) >=20 > When you talk though about length I already have that in the=20 > part of the PIN 'key' see below >=20 > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW >=20 > Also when we talk about server verified pins in otps are we=20 > not really talking about the otp algo or usage here? >=20 > I was wondering hence if our usage element for the otp key=20 > should be augmented to contain and optional >=20 > >=20 > What do you think? >=20 > Philip >=20 >=20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com] > Sent: Thursday, October 18, 2007 1:28 AM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Philip, > This looks ok except that a more complex PIN policy is needed=20 > (refer to this comment I made to the previous version of the=20 > PSKC draft, Section > 5.1.7: > "Recommend that you allow for a more complex PIN policy,=20 > esp., (a) how the PIN is to be used in the OTP calculation=20 > (e.g., concatenated vs. > XOR's with the token code) and (b) PIN length. " >=20 > This doesn't seem to have been addressed yet based on=20 > feedback to my review (see attached) and example below. What=20 > is the status of this? =20 > Andrea >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Friday, September 28, 2007 11:48 AM > To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Gentlemen, > Since PSKC will be used also to bulk provision from=20 > manufacturing to a validation server and some of these=20 > devices do have a PIN pad there is the concept of an initial PIN. >=20 > Since we have not yet defined how this initial PIN is=20 > transmitted in the PSKC spec I would like to put forward a=20 > proposal for inclusion in the spec for specifying the=20 > transmission of PINs. >=20 > The PIN is effectively another shared secret hence I propose=20 > to treat it as a key in itself. >=20 > This has the advantage that we can leverage the Usage part of=20 > the schema that can define things like length and format=20 > (alphanumeric etc). we also can set an expiry etc. It also=20 > leverages the fact that the PIN itself will be encrypted in=20 > transport in the same manner as other key material. >=20 > I hence propose to extend the KeyAlgorithmType with a new=20 > type called 'userPIN' (inline with the name used in the=20 > access rules element already > present) >=20 >=20 > As an example a KeyContainer with a non encrypted HOTP key=20 > and a 4 digit numeric PIN (please note that the value and=20 > valuedigest are just copy and paste) ( I put the new section=20 > with NEW-> and <-NEW lines before and > after): >=20 > > xmlns=3D"urn:ietf:params:xml:ns:keyprov:container" > xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo" > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container" > .\keyprov_pskc_schema_v1.1.xsd" version=3D"1.1"> > > > > > Token Manufacturer > 98765432187 > 01/01/2008 > > > Credential Issuer > > > > NEW-> > > <-NEW > MyFirstToken > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW > > >=20 > Comments are welcome, >=20 > Philip >=20 > -----Original Message----- > From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, September 21, 2007 9:58 AM > To: keyprov@ietf.org > Subject: [KEYPROV] [issue28] How to transfer initial PIN to a=20 > client viaPSKC? >=20 >=20 > New submission from Mingliang Pei : >=20 > PSKC provies support about carrying PIN usage policy. When=20 > PIN is used, > how do=20 > you actually transfer the initial PIN using PSKC? Should PIN=20 > be treated > as=20 > another credential, for example? >=20 > ---------- > assignedto: mpei > messages: 71 > nosy: keyprov, mpei > priority: critical > status: chatting > title: How to transfer initial PIN to a client via PSKC? >=20 > _________________________________________________________ > KEYPROV Roundup Issue Tracker > > _________________________________________________________ >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 ------_=_NextPart_001_01C82DEB.16A583EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [KEYPROV] [issue28] How to transfer initial PIN to = aclientviaPSKC?

Andrea and Ming,

As = we discussed in the PSKC call I would like to explain a new = proposal.

I = would like to keep the way to transmit the PIN value as a = key.

We = though want the flexibility to define possibly multiple PINs and which = keys are protected by the PIN.

Hence I would like to introduce an element called = PINPolicy

<PINPolicy PINRef=3D"KeyId of the key containing the = PIN">

        <PINUsageMode>

        =         Local

        </PINUsageMode>

</PINPolicy>

This will replace the accessrule element.

So = to take the example of a PIN protected HOTP token with no encryption = based on the latest draft with highlights:

   <?xml version=3D"1.0" = encoding=3D"UTF-8"?>

   <KeyContainer

     = xmlns=3D"urn:ietf:params:xml:ns:keyprov:container:1.0"

     xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#"

     xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance"

     = xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container:1.0

       keyprov-pskc-1.0.xsd" = Version=3D"1.0">

       = <Device>

         = <DeviceId>

          <= /SPAN> <Manufacturer>Token = Manufacturer</Manufacturer>

           = <SerialNo>98765432188</SerialNo>

           = <Expiry>12/31/2012</Expiry>

         = </DeviceId>

         <Key = KeyAlgorithm=3D"http://www.ietf.org/keypro= v/pskc#hotp"

           = KeyId=3D"77654321871">

         = <Issuer>Credential Issuer</Issuer>

           = <Usage OTP=3D"true">

           &n= bsp; <ResponseFormat Format=3D"DECIMAL" = Length=3D"6"/>

           = </Usage>

           = <FriendlyName>MyFirstToken</FriendlyName>

           = <Data Name=3D"SECRET">

           &n= bsp; <Value>

           &n= bsp;   zOkqJENSsh6b2hdXz1WBK/oprbY=3D

           &n= bsp; </Value>

           = </Data>

           = <Data Name=3D"COUNTER">

           &n= bsp; <Value>AAAAAAAAAAA=3D</Value>

           = </Data>

           = <Expiry>10/30/2012</Expiry>

             <PINPolicy = PINRef=3D"77654321872">

                <PINUsageMode>Local</PINUsageMode>

          <= /SPAN> </PINPolicy> =        

         = </Key>

         <Key = KeyAlgorithm=3D"http://www.ietf.org/keyprov/psk= c#PIN"

           = KeyId=3D"77654321872">

         = <Issuer>Credential Issuer</Issuer>

           = <Usage>

           &n= bsp; <ResponseFormat Format=3D"DECIMAL" = Length=3D"4"/>

           = </Usage>

           = <FriendlyName>RandomInitialTokenPIN</FriendlyName>

           = <Data Name=3D"SECRET">

           &n= bsp; <Value>

           &n= bsp;   zOkqJENSsh6b2hdXz1WBK/oprbY=3D

           &n= bsp; </Value>

           = </Data>

         = </Key>

       = </Device>

   </KeyContainer>


In = this way we can specifically say what keys are protected by which PINs = and re-use most of our constructs in Key that would apply to the PIN such = as the format the way to encrypt etc etc.

Thoughts?

Philip

-----Original Message-----
From: Pei, Mingliang [mailto:mpei@verisign.com]
Sent: Tuesday, November 13, 2007 1:48 AM
To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org
Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to = aclientviaPSKC?

I = have chatted with Philip / Salah about my comments this = afternoon

while I was almost done my reply of this email. I sent it anyway = now for

broad review. Our meeting minutes from Philip later will contain = other

proposed changes in our discussion.

1. = A PIN is associated with a key; we need to define a better way = to

associate with them when we carry PIN in a separate Key = type.

- = The current proposal assumes that all keys in the same = "Device" type

will associate to the PIN credential in the same = Device.

- = This has a limitation for "PREPEND" case where a device may = have

multiple keys, and each key has its own PIN as part of = server

authentication.

2. = There is use case when a PIN is per device, instead of per key, = for

the "Local" access usage.

So = I prefer defining PIN credential inside DeviceType, and refered = by

KeyType by an attribute or element, and = DeviceType.

3. = PIN policy is fine to have its own type. The AccessRule = and

PINUsageModeType should combine to be a PIN usage policy. If we = are

treating PIN as a separate credential, it is more consistent to = make PIN

usage policy part of Usage, I think.

Thanks,

- = Ming

 

> -----Original Message-----

> From: Doherty, Andrea [mailto:adoherty@rsa.com] =

> Sent: Thursday, November 08, 2007 12:31 PM

> To: Philip Hoyer; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: Bajaj, Siddharth; M'Raihi, David; Johan = Rydell

> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN =

> to aclientviaPSKC?

>

> Philip,

>

> Thank you for your proposal.  Here are a few = comments:

>

> 1. By <AccessRules userPIN=3D"true"/> do you = mean "PIN is

> enabled"?  Is the reverse true, that <AccessRules =

> userPIN=3D"false"/> indicates PINless operation = from a server's

> point of view?

>

> 2. Instead of <UserPIN = position=3D"APPEND/PREPEND"/>, providing

> a PINUsageModeType would be more extensible and = implementable:

> <xs:complexType = name=3D"PINUsageModeType">

>       <xs:choice = maxOccurs=3D"unbounded">

>       =         <xs:element = name=3D"Local"/>

>       =         <xs:element = name=3D"Prepend"/>

>       =         <xs:element = name=3D"Embed"/>

>       = </xs:choice>

> </xs:complexType>

>

> 3. Anders brought to my attention that a local PIN is needed =

> instead of a server PIN in some scenarios.  The device =

> issuer, in this case, would also have a PIN policy that could =

> differ from the policy of a server PIN.  Anders provided = the

> following example, which is taken from another =

> standardization effort in the workings ("PKI for Web = 2.0"):

>

> // The following is sent down to the client by the = issuer:

>

> <KeyGenerationRequest ...>

>

> // Request a key without PIN protection.

>

>   <RequestedKey ID=3D"Key.1" = KeyUsage=3D"encryption">

>     = <KeyAlgorithmData>

>       <RSA = KeySize=3D"2048"/>

>     = </KeyAlgorithmData>

>   </RequestedKey>

>

> // Request a set of keys with PIN = protection.

> // The specified policy disallows 11122 but accepts 11223 // =

> 654321 would not be accepted either = (sequence)

>

>   <PINProtection Type=3D"numeric" = MinLength=3D"5" MaxLength=3D"8"

>          &nbs= p;       = PatternRestrictions=3D"three-in-a-row  = sequences">

>

> // The next element is optional and is a way of grouping PINs =

> // so that the user either only has to specify a single PIN =

> // for a set of keys, or one unique PIN per = key.

>

>     <PINGroupProtection = Shared=3D"true">

>

>       <RequestedKey = ID=3D"Key.2" = KeyUsage=3D"signature">

>         = <KeyAlgorithmData>

>           = <RSA KeySize=3D"2048"/>

>         = </KeyAlgorithmData>

>       = </RequestedKey>

>       <RequestedKey = ID=3D"Key.3" = KeyUsage=3D"authentication">

>         = <KeyAlgorithmData>

>           = <RSA KeySize=3D"2048"/>

>         = </KeyAlgorithmData>

>       = </RequestedKey>

>

>     = </PINGroupProtection>

>

>   </PINProtection>

>

> </KeyGenerationRequest>

>

> Your thoughts?

> Andrea

>

> -----Original Message-----

> From: Philip Hoyer [mailto:philip.hoyer@activi= dentity.com]

> Sent: Thursday, October 18, 2007 6:16 AM

> To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: M'Raihi, David; Bajaj,Siddharth; Johan = Rydell

> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN =

> to aclientviaPSKC?

>

> Andrea,

> You are right I have not addressed the Pin policy = issue.

>

> I would like to though.

>

> Since you seem to have a good idea of the requirements would =

> you be able to help?

>

> I suggest we create a new type called PINPolicy that contains =

> the data required to be submitted.

>

> So currently PIN usage I can think of is:

> -KEY_ACCESS_CHECK (this check the pin on the device to allow =

> access to a key for algorithms) -USED_IN_ALGO (used during =

> calculation)

>

> When you talk though about length I already have that in the =

> <Usage> part of the PIN 'key' see = below

>

> NEW->

>        <Key = KeyAlgorithm=3D"userPIN"  = KeyId=3D"12345678">

>          = <Issuer>Credential Issuer</Issuer>

>          = <Usage>

>           = <ResponseFormat format=3D"DECIMAL" = length=3D"4"/>

>          = </Usage>

>          = <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>

>          <Data = Name=3D"SECRET">

>          &nbs= p; = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          &nbs= p; = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>          = </Data>

>        = </Key>

> <-NEW

>

> Also when we talk about server verified pins in otps are we =

> not really talking about the otp algo or usage = here?

>

> I was wondering hence if our usage element for the otp key =

> should be augmented to contain and optional

>

> <UserPIN = position=3D"APPEND/PREPEND"/>

>

> What do you think?

>

> Philip

>

>

> -----Original Message-----

> From: Doherty, Andrea [mailto:adoherty@rsa.com]

> Sent: Thursday, October 18, 2007 1:28 AM

> To: Philip Hoyer; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: Bajaj, Siddharth; Johan Rydell; = M'Raihi,David

> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN =

> to a clientviaPSKC?

>

> Philip,

> This looks ok except that a more complex PIN policy is needed =

> (refer to this comment I made to the previous version of the =

> PSKC draft, Section

> 5.1.7:

> "Recommend that you allow for a more complex PIN policy, =

> esp., (a) how the PIN is to be used in the OTP calculation =

> (e.g., concatenated vs.

> XOR's with the token code) and (b) PIN length. = "

>

> This doesn't seem to have been addressed yet based on =

> feedback to my review (see attached) and example below.  = What

> is the status of this? 

> Andrea

>

> -----Original Message-----

> From: Philip Hoyer [mailto:philip.hoyer@activi= dentity.com]

> Sent: Friday, September 28, 2007 11:48 AM

> To: KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: Bajaj, Siddharth; Johan Rydell; = M'Raihi,David

> Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN =

> to a clientviaPSKC?

>

> Gentlemen,

> Since PSKC will be used also to bulk provision from =

> manufacturing to a validation server and some of these =

> devices do have a PIN pad there is the concept of an initial = PIN.

>

> Since we have not yet defined how this initial PIN is =

> transmitted in the PSKC spec I would like to put forward a =

> proposal for inclusion in the spec for specifying the =

> transmission of PINs.

>

> The PIN is effectively another shared secret hence I propose =

> to treat it as a key in itself.

>

> This has the advantage that we can leverage the Usage part of =

> the schema that can define things like length and format =

> (alphanumeric etc). we also can set an expiry etc. It also =

> leverages the fact that the PIN itself will be encrypted in =

> transport in the same manner as other key = material.

>

> I hence propose to extend the KeyAlgorithmType with a new =

> type called 'userPIN' (inline with the name used in the =

> access rules element already

> present)

>

>

> As an example a KeyContainer with a non encrypted HOTP key =

> and a 4 digit numeric PIN (please note that the value and =

> valuedigest are just copy and paste) ( I put the new section =

> with NEW-> and <-NEW lines before and

> after):

>

>    <?xml version=3D"1.0" = encoding=3D"UTF-8"?>

>    <KeyContainer

>    = xmlns=3D"urn:ietf:params:xml:ns:keyprov:container"

>    = xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo"

>    xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#"

>    xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance"

>    = xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container"=

> .\keyprov_pskc_schema_v1.1.xsd" = version=3D"1.1">

>      <EncryptionMethod = algorithm=3D"NONE"/>

>      <DigestMethod = algorithm=3D"HMAC-SHA1"></DigestMethod><= /P>

>      <Device>

>        = <DeviceId>

>          = <Manufacturer>Token = Manufacturer</Manufacturer>

>          = <SerialNo>98765432187</SerialNo>

>          = <Expiry>01/01/2008</Expiry>

>        = </DeviceId>

>        <Key = KeyAlgorithm=3D"HOTP"  = KeyId=3D"98765432187">

>          = <Issuer>Credential Issuer</Issuer>

>          = <Usage>

>           = <ResponseFormat format=3D"DECIMAL" = length=3D"6"/>

>          = </Usage>

> NEW->

>          = <AccessRules userPIN=3D"true"/>

> <-NEW

>          = <FriendlyName>MyFirstToken</FriendlyName>

>          <Data = Name=3D"SECRET">

>          &nbs= p; = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          &nbs= p; = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>          = </Data>

>          <Data = Name=3D"COUNTER">

>          &nbs= p; = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          &nbs= p; = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>          = </Data>

>        = </Key>

> NEW->

>        <Key = KeyAlgorithm=3D"userPIN"  = KeyId=3D"12345678">

>          = <Issuer>Credential Issuer</Issuer>

>          = <Usage>

>           = <ResponseFormat format=3D"DECIMAL" = length=3D"4"/>

>          = </Usage>

>          = <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>

>          <Data = Name=3D"SECRET">

>          &nbs= p; = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          &nbs= p; = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>          = </Data>

>        = </Key>

> <-NEW

>      = </Device>

>    </KeyContainer>

>

> Comments are welcome,

>

> Philip

>

> -----Original Message-----

> From: Mingliang Pei [mailto:hannes.tschofenig@gmx.ne= t]

> Sent: Friday, September 21, 2007 9:58 AM

> To: keyprov@ietf.org

> Subject: [KEYPROV] [issue28] How to transfer initial PIN to a =

> client viaPSKC?

>

>

> New submission from Mingliang Pei = <mpei@verisign.com>:

>

> PSKC provies support about carrying PIN usage policy. When =

> PIN is used,

> how do

> you actually transfer the initial PIN using PSKC? Should PIN =

> be treated

> as

> another credential, for example?

>

> ----------

> assignedto: mpei

> messages: 71

> nosy: keyprov, mpei

> priority: critical

> status: chatting

> title: How to transfer initial PIN to a client via = PSKC?

>

> = _________________________________________________________

> KEYPROV Roundup Issue Tracker = <hannes.tschofenig@gmx.net>

> <http://www.tschof= enig.com:8080/keyprov/issue28>

> = _________________________________________________________

>

> = _______________________________________________

> KEYPROV mailing list

> KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>

>

> = _______________________________________________

> KEYPROV mailing list

> KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>

>

> = _______________________________________________

> KEYPROV mailing list

> KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>

>

> = _______________________________________________

> KEYPROV mailing list

> KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>

------_=_NextPart_001_01C82DEB.16A583EE-- --===============0309604482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0309604482==-- From keyprov-bounces@ietf.org Sat Nov 24 09:22:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvu7-00015P-Sb; Sat, 24 Nov 2007 09:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvu5-0000yF-Pv; Sat, 24 Nov 2007 09:22:41 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ivvty-000435-GO; Sat, 24 Nov 2007 09:22:41 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1747485c2d; Sat, 24 Nov 2007 22:35:30 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm86474353d3; Wed, 21 Nov 2007 04:35:00 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 21 Nov 2007 04:35:00 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZVC-0001cP-W3; Tue, 20 Nov 2007 15:15:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZUt-0000yK-Bc; Tue, 20 Nov 2007 15:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuZUs-0007kV-Qh; Tue, 20 Nov 2007 15:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AEDE626E7B; Tue, 20 Nov 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuZUr-0006Ct-GM; Tue, 20 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Nov 2007 15:15:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: keyprov@ietf.org Subject: [KEYPROV] I-D ACTION:draft-ietf-keyprov-portable-symmetric-key-container-02.txt X-BeenThere: keyprov@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Provisioning of Symmetric Keys Working Group of the IETF. Title : Portable Symmetric Key Container Author(s) : P. Hoyer, et al. Filename : draft-ietf-keyprov-portable-symmetric-key-container-02.txt Pages : 47 Date : 2007-11-20 This document specifies a symmetric key format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-keyprov-portable-symmetric-key-container-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-20140543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-keyprov-portable-symmetric-key-container-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-keyprov-portable-symmetric-key-container-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-20140543.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --NextPart-- From keyprov-bounces@ietf.org Sun Nov 25 10:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwJZd-0003UL-LG; Sun, 25 Nov 2007 10:39:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwJZb-0003NT-Kv for keyprov@ietf.org; Sun, 25 Nov 2007 10:39:07 -0500 Received: from dvnet26.diversinet.com ([207.245.6.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwJZG-0007ZT-PL for keyprov@ietf.org; Sun, 25 Nov 2007 10:39:07 -0500 Received: from dvnet26.diversinet.com(10.11.12.8) by mcafee_webshield.diversinet.com via smtp id 0e68_a4bcdbea_9b6d_11dc_89cd_0002b3ca872d; Sun, 25 Nov 2007 10:46:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Date: Sun, 25 Nov 2007 10:37:44 -0500 Message-ID: <2AB4BF7823761E4E90BA9372C429F1A901FC1BF8@DVNET26.DIVERSINET.COM> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA251E@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMAQ13Z+QAMedW/ACITewwABh9GQg From: "Salah Machani" To: "Philip Hoyer" , "Pei, Mingliang" , "Doherty, Andrea" , "KEYPROV Roundup Issue Tracker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ca6670295b20436a5b35ca7c810b7878 Cc: "Bajaj, Siddharth" , "M'Raihi, David" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242014786==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1242014786== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82F79.206953AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82F79.206953AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Philip, =20 =20 Thanks for sending this. Just a couple of comments: =20 =20 1.=09The purpose of the PINpolicy that is currently defined thought the element is to indicate to the device client whether the user must enter a PIN (local PIN) in order to use the token secret or not. I am for replacing the AccessRules definition with a new PINPolicy taking into account other use cases but we need to make sure that the original use case is still supported: I am assuming in your proposed definition the is optional and the PINRef is also optional? When the is omitted, it would imply that the user PIN is not required and when included but the PINRef is omitted, it would imply that a user PIN is required but there is no initial PIN. Is this correct?=20 =20 2.=09In addition to the flexibility you indicated below, the proposed definition implies also that you want to allow for the same initial PIN to be used for multiple Token secrets in bulk provisioning scenario. This could be achieved by defining the PINPolicy as follows: Local zOkqJENSsh6b2hdXz1WBK/oprbY=3D =20 =09a.=09Is the reason you chose to use a reference to another element to avoid duplicating same PIN across multiple key data blocks in the same the same container? =20 3.=09What is the scope of the PINRef? I am assuming this is within the current PSKC container. Could for example the PINref refer to a key that has been provisioned from another 'previous' container? =20 =20 4.=09if we use the data to transmit the initial PIN as proposed, we will need to add a new usage type to indicate the key data value will be used as an initial pin to unlock the actual token secret. I think it is better to have this explicit then implied by the PINRef (being set to keyid). =20 Regards, =20 =20 Salah =20 =20 =20 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Friday, November 23, 2007 11:08 AM To: Pei, Mingliang; Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? =20 Andrea and Ming, As we discussed in the PSKC call I would like to explain a new proposal. I would like to keep the way to transmit the PIN value as a key. We though want the flexibility to define possibly multiple PINs and which keys are protected by the PIN. Hence I would like to introduce an element called PINPolicy Local This will replace the accessrule element. So to take the example of a PIN protected HOTP token with no encryption based on the latest draft with highlights: Token Manufacturer 98765432188 12/31/2012 Credential Issuer MyFirstToken zOkqJENSsh6b2hdXz1WBK/oprbY=3D AAAAAAAAAAA=3D 10/30/2012 Local =20 Credential Issuer RandomInitialTokenPIN zOkqJENSsh6b2hdXz1WBK/oprbY=3D =20 In this way we can specifically say what keys are protected by which PINs and re-use most of our constructs in Key that would apply to the PIN such as the format the way to encrypt etc etc. Thoughts? Philip -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com] Sent: Tuesday, November 13, 2007 1:48 AM To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? I have chatted with Philip / Salah about my comments this afternoon while I was almost done my reply of this email. I sent it anyway now for broad review. Our meeting minutes from Philip later will contain other proposed changes in our discussion. 1. A PIN is associated with a key; we need to define a better way to associate with them when we carry PIN in a separate Key type. - The current proposal assumes that all keys in the same "Device" type will associate to the PIN credential in the same Device. - This has a limitation for "PREPEND" case where a device may have multiple keys, and each key has its own PIN as part of server authentication. 2. There is use case when a PIN is per device, instead of per key, for the "Local" access usage.=20 So I prefer defining PIN credential inside DeviceType, and refered by KeyType by an attribute or element, and DeviceType. 3. PIN policy is fine to have its own type. The AccessRule and PINUsageModeType should combine to be a PIN usage policy. If we are treating PIN as a separate credential, it is more consistent to make PIN usage policy part of Usage, I think. Thanks, - Ming =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, November 08, 2007 12:31 PM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Philip, >=20 > Thank you for your proposal. Here are a few comments: >=20 > 1. By do you mean "PIN is=20 > enabled"? Is the reverse true, that userPIN=3D"false"/> indicates PINless operation from a server's=20 > point of view?=20 >=20 > 2. Instead of , providing=20 > a PINUsageModeType would be more extensible and implementable: > > > > > > > >=20 > 3. Anders brought to my attention that a local PIN is needed=20 > instead of a server PIN in some scenarios. The device=20 > issuer, in this case, would also have a PIN policy that could=20 > differ from the policy of a server PIN. Anders provided the=20 > following example, which is taken from another=20 > standardization effort in the workings ("PKI for Web 2.0"): >=20 > // The following is sent down to the client by the issuer: >=20 > >=20 > // Request a key without PIN protection. >=20 > > > > > >=20 > // Request a set of keys with PIN protection. > // The specified policy disallows 11122 but accepts 11223 //=20 > 654321 would not be accepted either (sequence) >=20 > PatternRestrictions=3D"three-in-a-row sequences"> >=20 > // The next element is optional and is a way of grouping PINs=20 > // so that the user either only has to specify a single PIN=20 > // for a set of keys, or one unique PIN per key. >=20 > >=20 > > > > > > > > > > >=20 > >=20 > >=20 > >=20 > Your thoughts? > Andrea=20 >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Thursday, October 18, 2007 6:16 AM > To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Andrea, > You are right I have not addressed the Pin policy issue. >=20 > I would like to though.=20 >=20 > Since you seem to have a good idea of the requirements would=20 > you be able to help? >=20 > I suggest we create a new type called PINPolicy that contains=20 > the data required to be submitted. >=20 > So currently PIN usage I can think of is: > -KEY_ACCESS_CHECK (this check the pin on the device to allow=20 > access to a key for algorithms) -USED_IN_ALGO (used during=20 > calculation) >=20 > When you talk though about length I already have that in the=20 > part of the PIN 'key' see below >=20 > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW >=20 > Also when we talk about server verified pins in otps are we=20 > not really talking about the otp algo or usage here? >=20 > I was wondering hence if our usage element for the otp key=20 > should be augmented to contain and optional >=20 > >=20 > What do you think? >=20 > Philip >=20 >=20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com] > Sent: Thursday, October 18, 2007 1:28 AM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Philip, > This looks ok except that a more complex PIN policy is needed=20 > (refer to this comment I made to the previous version of the=20 > PSKC draft, Section > 5.1.7: > "Recommend that you allow for a more complex PIN policy,=20 > esp., (a) how the PIN is to be used in the OTP calculation=20 > (e.g., concatenated vs. > XOR's with the token code) and (b) PIN length. " >=20 > This doesn't seem to have been addressed yet based on=20 > feedback to my review (see attached) and example below. What=20 > is the status of this? =20 > Andrea >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Friday, September 28, 2007 11:48 AM > To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Gentlemen, > Since PSKC will be used also to bulk provision from=20 > manufacturing to a validation server and some of these=20 > devices do have a PIN pad there is the concept of an initial PIN. >=20 > Since we have not yet defined how this initial PIN is=20 > transmitted in the PSKC spec I would like to put forward a=20 > proposal for inclusion in the spec for specifying the=20 > transmission of PINs. >=20 > The PIN is effectively another shared secret hence I propose=20 > to treat it as a key in itself. >=20 > This has the advantage that we can leverage the Usage part of=20 > the schema that can define things like length and format=20 > (alphanumeric etc). we also can set an expiry etc. It also=20 > leverages the fact that the PIN itself will be encrypted in=20 > transport in the same manner as other key material. >=20 > I hence propose to extend the KeyAlgorithmType with a new=20 > type called 'userPIN' (inline with the name used in the=20 > access rules element already > present) >=20 >=20 > As an example a KeyContainer with a non encrypted HOTP key=20 > and a 4 digit numeric PIN (please note that the value and=20 > valuedigest are just copy and paste) ( I put the new section=20 > with NEW-> and <-NEW lines before and > after): >=20 > > xmlns=3D"urn:ietf:params:xml:ns:keyprov:container" > xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo" > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container" > .\keyprov_pskc_schema_v1.1.xsd" version=3D"1.1"> > > > > > Token Manufacturer > 98765432187 > 01/01/2008 > > > Credential Issuer > > > > NEW-> > > <-NEW > MyFirstToken > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW > > >=20 > Comments are welcome, >=20 > Philip >=20 > -----Original Message----- > From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, September 21, 2007 9:58 AM > To: keyprov@ietf.org > Subject: [KEYPROV] [issue28] How to transfer initial PIN to a=20 > client viaPSKC? >=20 >=20 > New submission from Mingliang Pei : >=20 > PSKC provies support about carrying PIN usage policy. When=20 > PIN is used, > how do=20 > you actually transfer the initial PIN using PSKC? Should PIN=20 > be treated > as=20 > another credential, for example? >=20 > ---------- > assignedto: mpei > messages: 71 > nosy: keyprov, mpei > priority: critical > status: chatting > title: How to transfer initial PIN to a client via PSKC? >=20 > _________________________________________________________ > KEYPROV Roundup Issue Tracker > > _________________________________________________________ >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 Notice to Recipient: The information in this message is meant only for t= he intended recipient of the transmission and may contain confidential or= privileged information. =0D Any copying, retransmittal, taking of action in reliance on, or other use= of the information in this communication by persons other than the addre= ssees is prohibited. =0D If you received this email in error, please immediately notify us and ple= ase delete or destroy all copies of this message.=0D This message may have been altered without your or our knowledge and the = sender does not accept any liability for any errors. Thank you.=0D ------_=_NextPart_001_01C82F79.206953AE Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4KCjxoZWFkPgo8TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRF TlQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4KPCEtLVtpZiAhbXNv XT4KPHN0eWxlPgp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9Cm9cOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7 fQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30KPC9zdHlsZT4KPCFbZW5kaWZd LS0+Cjx0aXRsZT5SRTogW0tFWVBST1ZdIFtpc3N1ZTI4XSBIb3cgdG8gdHJhbnNmZXIgaW5pdGlh bCBQSU4gdG8gYWNsaWVudHZpYVBTS0M/PC90aXRsZT4KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFj ZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIgogbmFtZT0i U3RhdGUiLz4KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIgogbmFtZT0iQ2l0eSIvPgo8bzpTbWFydFRhZ1R5cGUg bmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3Mi CiBuYW1lPSJwbGFjZSIvPgo8IS0tW2lmICFtc29dPgo8c3R5bGU+CnN0MVw6KntiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjaWVvb3VpKSB9Cjwvc3R5bGU+CjwhW2VuZGlmXS0tPgo8c3R5bGU+CjwhLS0K IC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8KIEBmb250LWZhY2UKCXtmb250LWZhbWlseTpXaW5nZGlu Z3M7CglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30KIC8qIFN0eWxlIERl ZmluaXRpb25zICovCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7 bWFyZ2luOjBpbjsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsK CXtjb2xvcjpibHVlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJe2NvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30KcAoJe21zby1tYXJnaW4tdG9wLWFsdDphdXRvOwoJbWFyZ2luLXJpZ2h0OjBpbjsK CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJbWFyZ2luLWxlZnQ6MGluOwoJZm9udC1zaXpl OjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30Kc3Bhbi5FbWFpbFN0eWxl MTgKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsKCWZvbnQtZmFtaWx5OkFyaWFsOwoJ Y29sb3I6bmF2eTt9CkBwYWdlIFNlY3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4waW47CgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9CmRpdi5TZWN0aW9uMQoJe3BhZ2U6U2VjdGlvbjE7 fQogLyogTGlzdCBEZWZpbml0aW9ucyAqLwogQGxpc3QgbDAKCXttc28tbGlzdC1pZDo2Njc5MDg5 NTc7Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDc0NDk4NTQ0O30KQGxpc3QgbDA6bGV2ZWwxCgl7 bXNvLWxldmVsLXRhYi1zdG9wOi41aW47Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMDpsZXZlbDIKCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0IGwwOmxl dmVsMwoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5k ZW50Oi05LjBwdDt9CkBsaXN0IGwwOmxldmVsNAoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBs aXN0IGwwOmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJ dGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47Cgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDA6bGV2 ZWw3Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDA6bGV2ZWw4Cgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47Cglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlz dCBsMDpsZXZlbDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0 ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMQoJe21zby1saXN0LWlkOjE0MTY3MDMyNTE7Cglt c28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTk1MjQwMzQgMjE0 MjM5MDIyOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZlbC1zdGFy dC1hdDowOwoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0OwoJbXNvLWxldmVsLXRleHQ6 LTsKCW1zby1sZXZlbC10YWItc3RvcDouNWluOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluOwoJZm9udC1mYW1pbHk6QXJpYWw7Cgltc28tZmFyZWFz dC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9CkBsaXN0IGwxOmxldmVsMgoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsKCW1zby1sZXZlbC10ZXh0Om87Cgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWlu ZGVudDotLjI1aW47Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30KQGxpc3QgbDIKCXttc28t bGlzdC1pZDoxNTA4NTkyNDU4OwoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6NDc0NDk4NTQ0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30KQGxpc3QgbDI6bGV2 ZWwxCgl7bXNvLWxldmVsLXRhYi1zdG9wOi41aW47Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMjpsZXZlbDIKCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsKCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0uMjVpbjt9CkBsaXN0 IGwzCgl7bXNvLWxpc3QtaWQ6MTk1NjQ3ODk1NDsKCW1zby1saXN0LXR5cGU6aHlicmlkOwoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjgyMTg1OTI3NCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBs aXN0IGwzOmxldmVsMQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOwoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LS4yNWluO30KQGxpc3QgbDM6bGV2ZWwyCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1 aW47fQpAbGlzdCBsMzpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47Cgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotLjI1aW47fQpAbGlzdCBsMzps ZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5k ZW50Oi0uMjVpbjt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowaW47fQp1bAoJe21hcmdpbi1ib3R0b206 MGluO30KLS0+Cjwvc3R5bGU+CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgogPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CiAgPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+CiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+CjwvaGVhZD4KCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPWJsdWU+ Cgo8ZGl2IGNsYXNzPVNlY3Rpb24xPgoKPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToKMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlBoaWxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPgoKPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToKMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOgoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4KCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6CjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5UaGFua3MgZm9yIHNlbmRpbmcgdGhpcy4gSnVzdCBh IGNvdXBsZSBvZgpjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToKMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0yIGNvbG9yPSIjMzMzMzk5IiBmYWNlPUFyaWFsPjxzcGFuCnN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMzMzMzOTknPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+Cgo8b2wgc3R5bGU9J21hcmdpbi10b3A6MGluJyBzdGFydD0xIHR5 cGU9MT4KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMzMzMzOTk7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzMnPjxmb250CiAgICAgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IiBmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0OwogICAgIGZvbnQtZmFtaWx5OkFyaWFs Jz5UaGUgcHVycG9zZSBvZiB0aGUgUElOcG9saWN5IHRoYXQgaXMgY3VycmVudGx5IGRlZmluZWQg dGhvdWdodAogICAgIHRoZSAmbHQ7YWNjZXNzUnVsZXMmZ3Q7IGVsZW1lbnQgaXMgdG8gaW5kaWNh dGUgdG8gdGhlIGRldmljZSBjbGllbnQgd2hldGhlcgogICAgIHRoZSB1c2VyIG11c3QgZW50ZXIg YSBQSU4gKGxvY2FsIFBJTikgJm5ic3A7aW4gb3JkZXIgdG8gdXNlIHRoZSB0b2tlbiBzZWNyZXQg b3IKICAgICBub3QuIEkgYW0gZm9yIHJlcGxhY2luZyB0aGUgQWNjZXNzUnVsZXMgZGVmaW5pdGlv biB3aXRoIGEgbmV3IFBJTlBvbGljeSB0YWtpbmcKICAgICBpbnRvIGFjY291bnQgb3RoZXIgdXNl IGNhc2VzIGJ1dCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBvcmlnaW5hbCB1c2UKICAg ICBjYXNlIGlzIHN0aWxsIHN1cHBvcnRlZDombmJzcDsgSSBhbSBhc3N1bWluZyBpbiB5b3VyIHBy b3Bvc2VkIGRlZmluaXRpb24gdGhlCiAgICAgJmx0O1BJTlBvbGljeSZndDsgaXMgb3B0aW9uYWwg YW5kIHRoZSBQSU5SZWYgaXMgYWxzbyBvcHRpb25hbD8gJm5ic3A7V2hlbiB0aGUKICAgICAmbHQ7 UElOUG9saWN5Jmd0OyBpcyBvbWl0dGVkLCBpdCB3b3VsZCBpbXBseSB0aGF0IHRoZSB1c2VyIFBJ TiBpcyBub3QgcmVxdWlyZWQKICAgICBhbmQgd2hlbiBpbmNsdWRlZCBidXQgdGhlIFBJTlJlZiBp cyBvbWl0dGVkLCBpdCB3b3VsZCBpbXBseSB0aGF0IGEgdXNlcgogICAgIFBJTiBpcyByZXF1aXJl ZCBidXQgdGhlcmUgaXMgbm8gaW5pdGlhbCBQSU4uIElzIHRoaXMgY29ycmVjdD8gPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvbGk+Cjwvb2w+Cgo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPSIjMzMzMzk5IiBmYWNlPUFyaWFsPjxzcGFuCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMzMzMzOTknPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+Cgo8b2wgc3R5bGU9J21hcmdpbi10b3A6MGluJyBzdGFydD0yIHR5cGU9 MT4KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMzMzMzOTk7bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzMnPjxmb250CiAgICAgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0OwogICAgIGZvbnQtZmFtaWx5OkFyaWFsJz5J biBhZGRpdGlvbiB0byB0aGUgZmxleGliaWxpdHkgeW91IGluZGljYXRlZCBiZWxvdywgdGhlCiAg ICAgcHJvcG9zZWQgZGVmaW5pdGlvbiBpbXBsaWVzIGFsc28gdGhhdCB5b3Ugd2FudCB0byBhbGxv dyBmb3IgdGhlIHNhbWUgaW5pdGlhbAogICAgIFBJTiB0byBiZSB1c2VkIGZvciBtdWx0aXBsZSBU b2tlbiBzZWNyZXRzIGluIGJ1bGsgcHJvdmlzaW9uaW5nIHNjZW5hcmlvLiZuYnNwOyAmbmJzcDtU aGlzCiAgICAgY291bGQgYmUgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgdGhlIFBJTlBvbGljeSBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xpPgo8L29sPgoKPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi41aW4nPjxmb250IHNp emU9Mgpjb2xvcj0iIzMzMzM5OSIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 IzMzMzM5OSc+Jmx0O1BJTlBvbGljeSZndDs8L3NwYW4+PC9mb250Pjxmb250CnNpemU9MiBjb2xv cj0iIzMzMzM5OSIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMzMzMzOTknPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 OjEuMGluO3RleHQtaW5kZW50Oi41aW4nPjxmb250IHNpemU9Mgpjb2xvcj0iIzMzMzM5OSIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzMzMzM5OSc+Jmx0O1BJTlVzYWdlTW9k ZSZndDtMb2NhbCZsdDsvUElOVXNhZ2VNb2RlJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5k ZW50Oi41aW4nPjxmb250IHNpemU9Mgpjb2xvcj0iIzMzMzM5OSIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6IzMzMzM5OSc+Jmx0O1BJTkluaXRWYWx1ZSZndDt6T2txSkVOU3No NmIyaGRYejFXQksvb3ByYlk9Jmx0Oy9QSU5Jbml0VmFsdWUmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4KCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0 ZXh0LWluZGVudDouNWluJz48Zm9udCBzaXplPTIKY29sb3I9IiMzMzMzOTkiIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOiMzMzMzOTknPiZsdDsvUElOUG9saWN5Jmd0OyAmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPG9sIHN0eWxlPSdtYXJnaW4tdG9wOjBp bicgc3RhcnQ9MiB0eXBlPTE+CiA8b2wgc3R5bGU9J21hcmdpbi10b3A6MGluJyBzdGFydD0xIHR5 cGU9YT4KICA8bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjojMzMzMzk5O21zby1saXN0 OmwyIGxldmVsMiBsZm8zJz48Zm9udAogICAgICBzaXplPTIgY29sb3I9IiMzMzMzOTkiIGZhY2U9 QXJpYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKICAgICAgZm9u dC1mYW1pbHk6QXJpYWwnPklzIHRoZSByZWFzb24geW91IGNob3NlIHRvIHVzZSBhIHJlZmVyZW5j ZSB0byBhbm90aGVyICZsdDtrZXkmZ3Q7CiAgICAgIGVsZW1lbnQgdG8gYXZvaWQgZHVwbGljYXRp bmcgc2FtZSBQSU4gYWNyb3NzIG11bHRpcGxlIGtleSBkYXRhIGJsb2NrcyBpbgogICAgICB0aGUg c2FtZSB0aGUgc2FtZSBjb250YWluZXI/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvbGk+CiA8 L29sPgo8L29sPgoKPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouMjVpbic+ PGZvbnQgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IgpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMzMzMzOTknPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8b2wgc3R5bGU9J21hcmdpbi10b3A6MGluJyBzdGFy dD0zIHR5cGU9MT4KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMzMzMzOTk7bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzMnPjxmb250CiAgICAgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IiBm YWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CiAgICAg Zm9udC1mYW1pbHk6QXJpYWwnPldoYXQgaXMgdGhlIHNjb3BlIG9mIHRoZSBQSU5SZWY/Jm5ic3A7 IEkgYW0gYXNzdW1pbmcgdGhpcyBpcwogICAgIHdpdGhpbiB0aGUgY3VycmVudCBQU0tDIGNvbnRh aW5lci4mbmJzcDsgQ291bGQgZm9yIGV4YW1wbGUgdGhlIFBJTnJlZiByZWZlciB0bwogICAgIGEg a2V5IHRoYXQgaGFzIGJlZW4gcHJvdmlzaW9uZWQgZnJvbSBhbm90aGVyICYjODIxNjtwcmV2aW91 cyYjODIxNzsKICAgICBjb250YWluZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4KICAgICBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsmbmJzcDs8L3NwYW4+ PC9mb250Pjxmb250CiAgICAgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2xp Pgo8L29sPgoKPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouMjVpbic+PGZv bnQgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IgpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMzMzMzOTknPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8b2wgc3R5bGU9J21hcmdpbi10b3A6MGluJyBzdGFydD00 IHR5cGU9MT4KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOiMzMzMzOTk7bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzMnPjxmb250CiAgICAgc2l6ZT0yIGNvbG9yPSIjMzMzMzk5IiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0OwogICAgIGZvbnQtZmFtaWx5OkFy aWFsJz5pZiB3ZSB1c2UgdGhlICZsdDtrZXkmZ3Q7IGRhdGEgdG8gdHJhbnNtaXQgdGhlIGluaXRp YWwKICAgICBQSU4gYXMgcHJvcG9zZWQsIHdlIHdpbGwgbmVlZCB0byBhZGQgYSBuZXcgdXNhZ2Ug dHlwZSB0byBpbmRpY2F0ZSB0aGUga2V5CiAgICAgZGF0YSB2YWx1ZSB3aWxsIGJlIHVzZWQgYXMg YW4gaW5pdGlhbCBwaW4gdG8gdW5sb2NrIHRoZSBhY3R1YWwgdG9rZW4KICAgICBzZWNyZXQuIEkg dGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgdGhpcyBleHBsaWNpdCB0aGVuIGltcGxpZWQgYnkg dGhlCiAgICAgUElOUmVmIChiZWluZyBzZXQgdG8ga2V5aWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L2xpPgo8L29sPgoKPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToKMTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOgoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToKMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOgoxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4K CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 Jz5TYWxhaDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48Zm9udCBzaXplPTIgY29sb3I9bmF2eQpmYWNlPUFy aWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48Zm9udCBzaXplPTIgY29sb3I9bmF2eQpm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi4yNWluJz48Zm9udCBzaXplPTIgY29sb3I9 bmF2eQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+Cgo8 ZGl2PgoKPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWdu OmNlbnRlcic+PGZvbnQgc2l6ZT0zCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPgoKPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVy IHRhYmluZGV4PS0xPgoKPC9zcGFuPjwvZm9udD48L2Rpdj4KCjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+ PC9iPjxmb250IHNpemU9MgpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpUYWhvbWEnPiBQaGlsaXAgSG95ZXIKW21haWx0bzpwaGlsaXAuaG95ZXJA YWN0aXZpZGVudGl0eS5jb21dIDxicj4KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQn PlNlbnQ6PC9zcGFuPjwvYj4gRnJpZGF5LCBOb3ZlbWJlciAyMywgMjAwNwoxMTowOCBBTTxicj4K PGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IFBlaSwgTWlu Z2xpYW5nOyBEb2hlcnR5LApBbmRyZWE7IEtFWVBST1YgUm91bmR1cCBJc3N1ZSBUcmFja2VyOyBr ZXlwcm92QGlldGYub3JnPGJyPgo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6 PC9zcGFuPjwvYj4gTSdSYWloaSwgRGF2aWQ7CkJhamFqLFNpZGRoYXJ0aDsgSm9oYW4gUnlkZWxs PGJyPgo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9i PiBSRTogW0tFWVBST1ZdIFtpc3N1ZTI4XQpIb3cgdG8gdHJhbnNmZXIgaW5pdGlhbCBQSU4gdG8g YWNsaWVudHZpYVBTS0M/PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjwvZGl2PgoKPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6CjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+QW5k cmVhIGFuZCBNaW5nLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkFzIHdlIGRpc2N1c3NlZCBpbiB0aGUg UFNLQyBjYWxsIEkgd291bGQgbGlrZSB0bwpleHBsYWluIGEgbmV3IHByb3Bvc2FsLjwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPkkgd291bGQgbGlrZSB0byBrZWVwIHRoZSB3YXkgdG8gdHJhbnNtaXQgdGhl IFBJTgp2YWx1ZSBhcyBhIGtleS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz5XZSB0aG91Z2ggd2FudCB0 aGUgZmxleGliaWxpdHkgdG8gZGVmaW5lIHBvc3NpYmx5Cm11bHRpcGxlIFBJTnMgYW5kIHdoaWNo IGtleXMgYXJlIHByb3RlY3RlZCBieSB0aGUgUElOLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkhlbmNl IEkgd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgYW4gZWxlbWVudCBjYWxsZWQKUElOUG9saWN5PC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmx0O1BJTlBvbGljeSBQSU5SZWY9JnF1b3Q7S2V5SWQgb2YgdGhl IGtleQpjb250YWluaW5nIHRoZSBQSU4mcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQgpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbHQ7UElOVXNhZ2VNb2RlJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsKJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yCmZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPkxvY2FsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3Nw YW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QgpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbHQ7 L1BJTlVzYWdlTW9kZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbHQ7L1BJTlBvbGljeSZndDs8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz5UaGlzIHdpbGwgcmVwbGFjZSB0aGUgYWNjZXNzcnVsZSBlbGVt ZW50Ljwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlNvIHRvIHRha2UgdGhlIGV4YW1wbGUgb2YgYSBQSU4g cHJvdGVjdGVkIEhPVFAgdG9rZW4Kd2l0aCBubyBlbmNyeXB0aW9uIGJhc2VkIG9uIHRoZSBsYXRl c3QgZHJhZnQgd2l0aCBoaWdobGlnaHRzOjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyAmbHQ7P3htbCB2ZXJzaW9uPSZxdW90OzEuMCZxdW90OwplbmNvZGluZz0mcXVvdDtVVEYtOCZx dW90Oz8mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7ICZsdDtLZXlDb250YWlu ZXI8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKeG1sbnM9JnF1 b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczprZXlwcm92OmNvbnRhaW5lcjoxLjAmcXVvdDs8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeG1sbnM6ZHM9JnF1b3Q7 PGEKaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIj5odHRwOi8vd3d3Lncz Lm9yZy8yMDAwLzA5L3htbGRzaWc8L2E+IyZxdW90Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB4bWxuczp4c2k9JnF1b3Q7PGEKaHJlZj0iaHR0cDovL3d3dy53 My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1M U2NoZW1hLWluc3RhbmNlPC9hPiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOwp4c2k6c2NoZW1hTG9jYXRpb249JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnht bDpuczprZXlwcm92OmNvbnRhaW5lcjoxLjA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuCmxhbmc9RU4tR0I+ IDwvc3Bhbj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RlIKc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+a2V5cHJvdi1w c2tjLTEuMC54c2QmcXVvdDsKVmVyc2lvbj0mcXVvdDsxLjAmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtEZXZpY2UmZ3Q7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7CiZsdDtEZXZpY2VJZCZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUZSIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9m b250PjxzcGFuCmxhbmc9RlI+IDwvc3Bhbj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0IKc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmx0O01hbnVmYWN0dXJlciZndDtUb2tlbgpNYW51ZmFjdHVyZXImbHQ7L01h bnVmYWN0dXJlciZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1NlcmlhbE5vJmd0Ozk4 NzY1NDMyMTg4Jmx0Oy9TZXJpYWxObyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0V4 cGlyeSZndDsxMi8zMS8yMDEyJmx0Oy9FeHBpcnkmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvRGV2aWNl SWQmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtLZXkgS2V5QWxnb3JpdGhtPSZxdW90OzxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcva2V5cHJvdi9wc2tjI2hvdHAiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv a2V5cHJvdi9wc2tjI2hvdHA8L2E+JnF1b3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4K CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CktleUlk PSZxdW90Ozc3NjU0MzIxODcxJnF1b3Q7Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7SXNzdWVyJmd0O0Ny ZWRlbnRpYWwgSXNzdWVyJmx0Oy9Jc3N1ZXImZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZs dDtVc2FnZSBPVFA9JnF1b3Q7dHJ1ZSZxdW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKJmx0O1Jlc3BvbnNlRm9ybWF0IEZvcm1hdD0mcXVvdDtERUNJTUFMJnF1b3Q7 IExlbmd0aD0mcXVvdDs2JnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9V c2FnZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0ZyaWVuZGx5TmFtZSZndDtNeUZp cnN0VG9rZW4mbHQ7L0ZyaWVuZGx5TmFtZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0 O0RhdGEgTmFtZT0mcXVvdDtTRUNSRVQmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7CiZsdDtWYWx1ZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsKek9rcUpFTlNzaDZiMmhkWHoxV0JLL29wcmJZPTwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7L1ZhbHVlJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwombHQ7L0RhdGEmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtEYXRhIE5h bWU9JnF1b3Q7Q09VTlRFUiZxdW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsKJmx0O1ZhbHVlJmd0O0FBQUFBQUFBQUFBPSZsdDsvVmFsdWUmZ3Q7PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7CiZsdDsvRGF0YSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0V4 cGlyeSZndDsxMC8zMC8yMDEyJmx0Oy9FeHBpcnkmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQgpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9mb250Pjxz cGFuCmxhbmc9RU4tR0I+IDwvc3Bhbj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0IKc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmx0O1BJTlBvbGljeQpQSU5SZWY9JnF1b3Q7Nzc2NTQzMjE4NzImcXVvdDsmZ3Q7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbgpsYW5nPUVO LUdCPiAmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4KbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbHQ7UElOVXNhZ2VNb2RlJmd0O0xvY2FsJmx0Oy9QSU5Vc2FnZU1v ZGUmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48c3BhbgpsYW5nPUVO LUdCPiA8L3NwYW4+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZs dDsvUElOUG9saWN5Jmd0Ozwvc3Bhbj48L2ZvbnQ+PHNwYW4KbGFuZz1FTi1HQj4gJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4K CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvS2V5Jmd0Ozwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PHNwYW4KbGFuZz1FTi1HQj4gPC9zcGFuPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQgpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbHQ7S2V5IEtleUFsZ29yaXRobT0mcXVv dDs8YQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2tleXByb3YvcHNrYyI+aHR0cDovL3d3dy5p ZXRmLm9yZy9rZXlwcm92L3Bza2M8L2E+I1BJTiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OwpLZXlJZD0mcXVvdDs3NzY1NDMyMTg3MiZxdW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O0lzc3Vl ciZndDtDcmVkZW50aWFsCklzc3VlciZsdDsvSXNzdWVyJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwombHQ7VXNhZ2UmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZs dDtSZXNwb25zZUZvcm1hdCBGb3JtYXQ9JnF1b3Q7REVDSU1BTCZxdW90OyBMZW5ndGg9JnF1b3Q7 NCZxdW90Oy8mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvVXNhZ2UmZ3Q7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtGcmllbmRseU5hbWUmZ3Q7UmFuZG9tSW5pdGlhbFRva2Vu UElOJmx0Oy9GcmllbmRseU5hbWUmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxw Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtEYXRh IE5hbWU9JnF1b3Q7U0VDUkVUJnF1b3Q7Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwombHQ7VmFsdWUmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7CnpPa3FKRU5Tc2g2YjJoZFh6MVdCSy9vcHJiWT08L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9WYWx1ZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKJmx0Oy9EYXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7L0tleSZndDs8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9EZXZpY2UmZ3Q7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7ICZsdDsvS2V5Q29udGFpbmVyJmd0Ozwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToKMTIuMHB0 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz5JbiB0aGlzIHdheSB3ZSBjYW4gc3BlY2lmaWNh bGx5IHNheSB3aGF0IGtleXMgYXJlCnByb3RlY3RlZCBieSB3aGljaCBQSU5zIGFuZCByZS11c2Ug bW9zdCBvZiBvdXI8L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9RU4tR0I+IDwvc3Bhbj48Zm9udApz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6CiJDb3VyaWVyIE5ldyInPmNvbnN0cnVjdHMgaW4gS2V5IHRo YXQgd291bGQgYXBwbHkgdG8gdGhlIFBJTiBzdWNoIGFzIHRoZSBmb3JtYXQKdGhlIHdheSB0byBl bmNyeXB0IGV0YyBldGMuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VGhvdWdodHM/PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+UGhpbGlwPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6CiJDb3VyaWVyIE5ldyInPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPgpG cm9tOiBQZWksIE1pbmdsaWFuZyBbPGEgaHJlZj0ibWFpbHRvOm1wZWlAdmVyaXNpZ24uY29tIj5t YWlsdG86bXBlaUB2ZXJpc2lnbi5jb208L2E+XTxicj4KU2VudDogVHVlc2RheSwgTm92ZW1iZXIg MTMsIDIwMDcgMTo0OCBBTTxicj4KVG86IERvaGVydHksIEFuZHJlYTsgUGhpbGlwIEhveWVyOyBL RVlQUk9WIFJvdW5kdXAgSXNzdWUgVHJhY2tlcjsKa2V5cHJvdkBpZXRmLm9yZzxicj4KQ2M6IEJh amFqLCBTaWRkaGFydGg7IE0nUmFpaGksIERhdmlkOyBKb2hhbiBSeWRlbGw8YnI+ClN1YmplY3Q6 IFJFOiBbS0VZUFJPVl0gW2lzc3VlMjhdIEhvdyB0byB0cmFuc2ZlciBpbml0aWFsIFBJTiB0byBh Y2xpZW50dmlhUFNLQz88L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz5JIGhhdmUgY2hhdHRlZCB3aXRoIFBo aWxpcCAvIFNhbGFoIGFib3V0IG15IGNvbW1lbnRzCnRoaXMgYWZ0ZXJub29uPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+d2hpbGUgSSB3YXMgYWxtb3N0IGRvbmUgbXkgcmVwbHkgb2YgdGhpcyBlbWFpbC4g SQpzZW50IGl0IGFueXdheSBub3cgZm9yPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxw Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+YnJvYWQgcmV2aWV3 LiBPdXIgbWVldGluZyBtaW51dGVzIGZyb20gUGhpbGlwIGxhdGVyCndpbGwgY29udGFpbiBvdGhl cjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPnByb3Bvc2VkIGNoYW5nZXMgaW4gb3VyIGRpc2N1c3Npb24u PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+MS4gQSBQSU4gaXMgYXNzb2NpYXRlZCB3aXRoIGEga2V5OyB3 ZSBuZWVkIHRvIGRlZmluZQphIGJldHRlciB3YXkgdG88L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz5hc3Nv Y2lhdGUgd2l0aCB0aGVtIHdoZW4gd2UgY2FycnkgUElOIGluIGEgc2VwYXJhdGUKS2V5IHR5cGUu PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+LSBUaGUgY3VycmVudCBwcm9wb3NhbCBhc3N1bWVzIHRoYXQg YWxsIGtleXMgaW4gdGhlCnNhbWUgJnF1b3Q7RGV2aWNlJnF1b3Q7IHR5cGU8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz53aWxsIGFzc29jaWF0ZSB0byB0aGUgUElOIGNyZWRlbnRpYWwgaW4gdGhlIHNhbWUK RGV2aWNlLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPi0gVGhpcyBoYXMgYSBsaW1pdGF0aW9uIGZvciAm cXVvdDtQUkVQRU5EJnF1b3Q7IGNhc2UKd2hlcmUgYSBkZXZpY2UgbWF5IGhhdmU8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz5tdWx0aXBsZSBrZXlzLCBhbmQgZWFjaCBrZXkgaGFzIGl0cyBvd24gUElOIGFz IHBhcnQKb2Ygc2VydmVyPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+YXV0aGVudGljYXRpb24uPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Mi4gVGhlcmUgaXMgdXNlIGNhc2Ugd2hlbiBhIFBJTiBpcyBwZXIgZGV2 aWNlLAppbnN0ZWFkIG9mIHBlciBrZXksIGZvcjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRoZSAmcXVv dDtMb2NhbCZxdW90OyBhY2Nlc3MgdXNhZ2UuIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlNvIEkgcHJl ZmVyIGRlZmluaW5nIFBJTiBjcmVkZW50aWFsIGluc2lkZSBEZXZpY2VUeXBlLAphbmQgcmVmZXJl ZCBieTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPktleVR5cGUgYnkgYW4gYXR0cmlidXRlIG9yIGVsZW1l bnQsIGFuZCBEZXZpY2VUeXBlLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjMuIFBJTiBwb2xpY3kgaXMg ZmluZSB0byBoYXZlIGl0cyBvd24gdHlwZS4gVGhlCkFjY2Vzc1J1bGUgYW5kPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+UElOVXNhZ2VNb2RlVHlwZSBzaG91bGQgY29tYmluZSB0byBiZSBhIFBJTiB1c2Fn ZQpwb2xpY3kuIElmIHdlIGFyZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPnRyZWF0aW5nIFBJTiBhcyBh IHNlcGFyYXRlIGNyZWRlbnRpYWwsIGl0IGlzIG1vcmUgY29uc2lzdGVudAp0byBtYWtlIFBJTjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPnVzYWdlIHBvbGljeSBwYXJ0IG9mIFVzYWdlLCBJIHRoaW5rLjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPlRoYW5rcyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4tIE1pbmc8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcm9tOiBEb2hlcnR5 LCBBbmRyZWEgWzxhCmhyZWY9Im1haWx0bzphZG9oZXJ0eUByc2EuY29tIj5tYWlsdG86YWRvaGVy dHlAcnNhLmNvbTwvYT5dIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU2VudDogVGh1cnNkYXks IE5vdmVtYmVyIDA4LCAyMDA3IDEyOjMxIFBNPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4K CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBUbzog UGhpbGlwIEhveWVyOyBLRVlQUk9WIFJvdW5kdXAgSXNzdWUKVHJhY2tlcjsga2V5cHJvdkBpZXRm Lm9yZzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ2M6IEJhamFqLCBTaWRkaGFydGg7IE0nUmFp aGksIERhdmlkOyBKb2hhbgpSeWRlbGw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFN1YmplY3Q6 IFJFOiBbS0VZUFJPVl0gW2lzc3VlMjhdIEhvdyB0bwp0cmFuc2ZlciBpbml0aWFsIFBJTiA8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IHRvIGFjbGllbnR2aWFQU0tDPzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBQaGlsaXAsPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFRoYW5rIHlvdSBmb3IgeW91ciBw cm9wb3NhbC4mbmJzcDsgSGVyZSBhcmUgYQpmZXcgY29tbWVudHM6PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDEuIEJ5ICZsdDtBY2Nlc3NSdWxlcwp1 c2VyUElOPSZxdW90O3RydWUmcXVvdDsvJmd0OyBkbyB5b3UgbWVhbiAmcXVvdDtQSU4gaXMgPC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBlbmFibGVkJnF1b3Q7PyZuYnNwOyBJcyB0aGUgcmV2ZXJz ZSB0cnVlLCB0aGF0CiZsdDtBY2Nlc3NSdWxlcyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHVz ZXJQSU49JnF1b3Q7ZmFsc2UmcXVvdDsvJmd0OyBpbmRpY2F0ZXMKUElObGVzcyBvcGVyYXRpb24g ZnJvbSBhIHNlcnZlcidzIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgcG9pbnQgb2Ygdmlldz8g PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDIuIElu c3RlYWQgb2YgJmx0O1VzZXJQSU4gcG9zaXRpb249JnF1b3Q7QVBQRU5EL1BSRVBFTkQmcXVvdDsv Jmd0OywKcHJvdmlkaW5nIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgYSBQSU5Vc2FnZU1vZGVU eXBlIHdvdWxkIGJlIG1vcmUgZXh0ZW5zaWJsZSBhbmQKaW1wbGVtZW50YWJsZTo8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7ICZsdDt4czpjb21wbGV4VHlwZQpuYW1lPSZxdW90O1BJTlVzYWdlTW9k ZVR5cGUmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O3hzOmNob2ljZQptYXhPY2N1cnM9JnF1b3Q7dW5ib3VuZGVkJnF1 b3Q7Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7eHM6 ZWxlbWVudApuYW1lPSZxdW90O0xvY2FsJnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3hzOmVsZW1lbnQgbmFtZT0mcXVvdDtQcmVwZW5kJnF1 b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3hz OmVsZW1lbnQKbmFtZT0mcXVvdDtFbWJlZCZxdW90Oy8mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy94czpjaG9pY2UmZ3Q7PC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0Ozwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAzLiBBbmRlcnMgYnJvdWdo dCB0byBteSBhdHRlbnRpb24gdGhhdCBhIGxvY2FsClBJTiBpcyBuZWVkZWQgPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyBpbnN0ZWFkIG9mIGEgc2VydmVyIFBJTiBpbiBzb21lCnNjZW5hcmlvcy4m bmJzcDsgVGhlIGRldmljZSA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGlzc3VlciwgaW4gdGhp cyBjYXNlLCB3b3VsZCBhbHNvIGhhdmUgYSBQSU4KcG9saWN5IHRoYXQgY291bGQgPC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyBkaWZmZXIgZnJvbSB0aGUgcG9saWN5IG9mIGEgc2VydmVyIFBJTi4m bmJzcDsKQW5kZXJzIHByb3ZpZGVkIHRoZSA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGZvbGxv d2luZyBleGFtcGxlLCB3aGljaCBpcyB0YWtlbiBmcm9tIGFub3RoZXIgPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyBzdGFuZGFyZGl6YXRpb24gZWZmb3J0IGluIHRoZSB3b3JraW5ncwooJnF1b3Q7 UEtJIGZvciBXZWIgMi4wJnF1b3Q7KTo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgLy8gVGhlIGZvbGxvd2luZyBpcyBzZW50IGRvd24gdG8gdGhlIGNs aWVudCBieQp0aGUgaXNzdWVyOjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyAmbHQ7S2V5R2VuZXJhdGlvblJlcXVlc3QgLi4uJmd0Ozwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAvLyBSZXF1ZXN0IGEga2V5 IHdpdGhvdXQgUElOIHByb3RlY3Rpb24uPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxw Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7ICZsdDtSZXF1ZXN0ZWRLZXkKSUQ9JnF1b3Q7 S2V5LjEmcXVvdDsgS2V5VXNhZ2U9JnF1b3Q7ZW5jcnlwdGlvbiZxdW90OyZndDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtLZXlBbGdvcml0aG1E YXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0O1JTQQpLZXlTaXplPSZxdW90OzIwNDgmcXVvdDsvJmd0Ozwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9LZXlBbGdvcml0 aG1EYXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsgJmx0Oy9SZXF1 ZXN0ZWRLZXkmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IC8vIFJlcXVlc3QgYSBzZXQgb2Yga2V5cyB3aXRoIFBJTiBwcm90ZWN0aW9uLjwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgLy8gVGhlIHNwZWNpZmllZCBwb2xpY3kgZGlzYWxsb3dzIDEx MTIyIGJ1dAphY2NlcHRzIDExMjIzIC8vIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgNjU0MzIx IHdvdWxkIG5vdCBiZSBhY2NlcHRlZCBlaXRoZXIgKHNlcXVlbmNlKTwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyAmbHQ7UElOUHJv dGVjdGlvbgpUeXBlPSZxdW90O251bWVyaWMmcXVvdDsgTWluTGVuZ3RoPSZxdW90OzUmcXVvdDsg TWF4TGVuZ3RoPSZxdW90OzgmcXVvdDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ClBhdHRlcm5SZXN0cmljdGlvbnM9 JnF1b3Q7dGhyZWUtaW4tYS1yb3cmbmJzcDsgc2VxdWVuY2VzJnF1b3Q7Jmd0Ozwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAvLyBUaGUgbmV4dCBlbGVt ZW50IGlzIG9wdGlvbmFsIGFuZCBpcyBhIHdheSBvZgpncm91cGluZyBQSU5zIDwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgLy8gc28gdGhhdCB0aGUgdXNlciBlaXRoZXIgb25seSBoYXMgdG8gc3Bl Y2lmeQphIHNpbmdsZSBQSU4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAvLyBmb3IgYSBzZXQg b2Yga2V5cywgb3Igb25lIHVuaXF1ZSBQSU4gcGVyCmtleS48L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O1BJTkdyb3VwUHJvdGVjdGlvbgpTaGFyZWQ9JnF1b3Q7dHJ1ZSZxdW90OyZndDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1JlcXVlc3RlZEtleSBJRD0mcXVvdDtLZXkuMiZxdW90 OyBLZXlVc2FnZT0mcXVvdDtzaWduYXR1cmUmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7 S2V5QWxnb3JpdGhtRGF0YSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtSU0Eg S2V5U2l6ZT0mcXVvdDsyMDQ4JnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvS2V5QWxn b3JpdGhtRGF0YSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvUmVxdWVzdGVkS2V5Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1JlcXVlc3Rl ZEtleSBJRD0mcXVvdDtLZXkuMyZxdW90OyBLZXlVc2FnZT0mcXVvdDthdXRoZW50aWNhdGlvbiZx dW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtLZXlBbGdvcml0aG1EYXRhJmd0Ozwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1JTQSBLZXlTaXplPSZxdW90OzIwNDgmcXVvdDsvJmd0 Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9LZXlBbGdvcml0aG1EYXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9SZXF1 ZXN0ZWRLZXkmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvUElOR3JvdXBQcm90ZWN0aW9uJmd0 Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4K CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNw OyZuYnNwOyAmbHQ7L1BJTlByb3RlY3Rpb24mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7ICZsdDsvS2V5R2VuZXJhdGlvblJlcXVlc3QmZ3Q7PC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFlvdXIgdGhv dWdodHM/PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBBbmRyZWEgPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcm9tOiBQaGlsaXAgSG95ZXIgWzxhCmhyZWY9 Im1haWx0bzpwaGlsaXAuaG95ZXJAYWN0aXZpZGVudGl0eS5jb20iPm1haWx0bzpwaGlsaXAuaG95 ZXJAYWN0aXZpZGVudGl0eS5jb208L2E+XTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTgsIDIwMDcgNjoxNiBBTTwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgVG86IERvaGVydHksIEFuZHJlYTsgS0VZUFJPViBSb3VuZHVwIElzc3VlClRyYWNrZXI7IGtl eXByb3ZAaWV0Zi5vcmc8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IENjOiBNJ1JhaWhpLCBEYXZp ZDsgQmFqYWosU2lkZGhhcnRoOyBKb2hhbgpSeWRlbGw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IFN1YmplY3Q6IFJFOiBbS0VZUFJPVl0gW2lzc3VlMjhdIEhvdyB0bwp0cmFuc2ZlciBpbml0aWFs IFBJTiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRvIGFjbGllbnR2aWFQU0tDPzwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBBbmRyZWEsPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyBZb3UgYXJlIHJpZ2h0IEkgaGF2ZSBub3QgYWRkcmVzc2VkIHRo ZSBQaW4KcG9saWN5IGlzc3VlLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyBJIHdvdWxkIGxpa2UgdG8gdGhvdWdoLiA8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU2luY2UgeW91IHNlZW0gdG8gaGF2ZSBh IGdvb2QgaWRlYSBvZiB0aGUKcmVxdWlyZW1lbnRzIHdvdWxkIDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgeW91IGJlIGFibGUgdG8gaGVscD88L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgSSBzdWdnZXN0IHdlIGNyZWF0ZSBhIG5ldyB0eXBlIGNhbGxl ZCBQSU5Qb2xpY3kKdGhhdCBjb250YWlucyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRoZSBk YXRhIHJlcXVpcmVkIHRvIGJlIHN1Ym1pdHRlZC48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU28gY3VycmVudGx5IFBJTiB1c2FnZSBJIGNhbiB0aGlu ayBvZiBpczo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC1LRVlfQUNDRVNTX0NIRUNLICh0aGlz IGNoZWNrIHRoZSBwaW4gb24gdGhlCmRldmljZSB0byBhbGxvdyA8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IGFjY2VzcyB0byBhIGtleSBmb3IgYWxnb3JpdGhtcykgLVVTRURfSU5fQUxHTwoodXNl ZCBkdXJpbmcgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBjYWxjdWxhdGlvbik8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgV2hlbiB5b3UgdGFsayB0 aG91Z2ggYWJvdXQgbGVuZ3RoIEkgYWxyZWFkeQpoYXZlIHRoYXQgaW4gdGhlIDwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgJmx0O1VzYWdlJmd0OyBwYXJ0IG9mIHRoZSBQSU4gJ2tleScgc2VlIGJl bG93PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IE5F Vy0mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwombHQ7S2V5IEtleUFsZ29yaXRobT0mcXVvdDt1c2VyUElOJnF1b3Q7 Jm5ic3A7IEtleUlkPSZxdW90OzEyMzQ1Njc4JnF1b3Q7Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKJmx0O0lzc3VlciZndDtDcmVkZW50aWFsIElzc3VlciZsdDsvSXNzdWVyJmd0Ozwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsKJmx0O1VzYWdlJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsK Jmx0O1Jlc3BvbnNlRm9ybWF0IGZvcm1hdD0mcXVvdDtERUNJTUFMJnF1b3Q7IGxlbmd0aD0mcXVv dDs0JnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDsvVXNhZ2UmZ3Q7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwombHQ7RnJpZW5kbHlOYW1lJmd0O015Rmlyc3RUb2tlbkluaXRpYWxQ SU4mbHQ7L0ZyaWVuZGx5TmFtZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtEYXRhIE5h bWU9JnF1b3Q7U0VDUkVUJnF1b3Q7Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKJmx0O1ZhbHVlJmd0O1dsZGpUSFp3Um05WVRraEJSeXRzZURNclVuYz0mbHQ7L1ZhbHVlJmd0 Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1ZhbHVlRGlnZXN0Jmd0O1ds ZGpUSFp3Um05WVRraEJSeXRzZURNPSZsdDsvVmFsdWVEaWdlc3QmZ3Q7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwombHQ7L0RhdGEmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7L0tleSZndDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7ICZsdDstTkVXPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IEFsc28gd2hlbiB3ZSB0YWxrIGFib3V0IHNlcnZlciB2ZXJpZmllZCBw aW5zIGluCm90cHMgYXJlIHdlIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgbm90IHJlYWxseSB0 YWxraW5nIGFib3V0IHRoZSBvdHAgYWxnbyBvciB1c2FnZQpoZXJlPzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBJIHdhcyB3b25kZXJpbmcgaGVuY2Ug aWYgb3VyIHVzYWdlIGVsZW1lbnQgZm9yCnRoZSBvdHAga2V5IDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgc2hvdWxkIGJlIGF1Z21lbnRlZCB0byBjb250YWluIGFuZCBvcHRpb25hbDwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAmbHQ7VXNlclBJTgpw b3NpdGlvbj0mcXVvdDtBUFBFTkQvUFJFUEVORCZxdW90Oy8mZ3Q7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFdoYXQgZG8geW91IHRoaW5rPzwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBQaGlsaXA8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZndDsgRnJvbTogRG9oZXJ0eSwgQW5kcmVhIFs8YQpocmVmPSJtYWlsdG86YWRvaGVy dHlAcnNhLmNvbSI+bWFpbHRvOmFkb2hlcnR5QHJzYS5jb208L2E+XTwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTgsIDIwMDcgMToyOCBBTTwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgVG86IFBoaWxpcCBIb3llcjsgS0VZUFJPViBSb3VuZHVwIElzc3Vl ClRyYWNrZXI7IGtleXByb3ZAaWV0Zi5vcmc8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IENjOiBC YWphaiwgU2lkZGhhcnRoOyBKb2hhbiBSeWRlbGw7Ck0nUmFpaGksRGF2aWQ8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7IFN1YmplY3Q6IFJFOiBbS0VZUFJPVl0gW2lzc3VlMjhdIEhvdyB0bwp0cmFu c2ZlciBpbml0aWFsIFBJTiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRvIGEgY2xpZW50dmlh UFNLQz88L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsg UGhpbGlwLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgVGhpcyBsb29rcyBvayBleGNlcHQgdGhh dCBhIG1vcmUgY29tcGxleCBQSU4KcG9saWN5IGlzIG5lZWRlZCA8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5n PUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IChyZWZlciB0byB0aGlzIGNvbW1lbnQgSSBtYWRlIHRvIHRoZSBwcmV2aW91cwp2ZXJz aW9uIG9mIHRoZSA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFBTS0MgZHJhZnQsIFNlY3Rpb248 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IDUuMS43Ojwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsg JnF1b3Q7UmVjb21tZW5kIHRoYXQgeW91IGFsbG93IGZvciBhIG1vcmUKY29tcGxleCBQSU4gcG9s aWN5LCA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGVzcC4sIChhKSBob3cgdGhlIFBJTiBpcyB0 byBiZSB1c2VkIGluIHRoZSBPVFAKY2FsY3VsYXRpb24gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyAoZS5nLiwgY29uY2F0ZW5hdGVkIHZzLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgWE9SJ3Mg d2l0aCB0aGUgdG9rZW4gY29kZSkgYW5kIChiKSBQSU4gbGVuZ3RoLgomcXVvdDs8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgVGhpcyBkb2Vzbid0IHNl ZW0gdG8gaGF2ZSBiZWVuIGFkZHJlc3NlZCB5ZXQKYmFzZWQgb24gPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyBmZWVkYmFjayB0byBteSByZXZpZXcgKHNlZSBhdHRhY2hlZCkgYW5kCmV4YW1wbGUg YmVsb3cuJm5ic3A7IFdoYXQgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBpcyB0aGUgc3RhdHVz IG9mIHRoaXM/Jm5ic3A7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQW5kcmVhPC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcm9tOiBQaGlsaXAgSG95ZXIg WzxhCmhyZWY9Im1haWx0bzpwaGlsaXAuaG95ZXJAYWN0aXZpZGVudGl0eS5jb20iPm1haWx0bzpw aGlsaXAuaG95ZXJAYWN0aXZpZGVudGl0eS5jb208L2E+XTwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMDcgMTE6NDggQU08L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7IFRvOiBLRVlQUk9WIFJvdW5kdXAgSXNzdWUgVHJhY2tlcjsKa2V5cHJvdkBp ZXRmLm9yZzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ2M6IEJhamFqLCBTaWRkaGFydGg7IEpv aGFuIFJ5ZGVsbDsKTSdSYWloaSxEYXZpZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU3ViamVj dDogUkU6IFtLRVlQUk9WXSBbaXNzdWUyOF0gSG93IHRvCnRyYW5zZmVyIGluaXRpYWwgUElOIDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgdG8gYSBjbGllbnR2aWFQU0tDPzwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBHZW50bGVtZW4sPC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyBTaW5jZSBQU0tDIHdpbGwgYmUgdXNlZCBhbHNvIHRvIGJ1bGsgcHJv dmlzaW9uCmZyb20gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBtYW51ZmFjdHVyaW5nIHRvIGEg dmFsaWRhdGlvbiBzZXJ2ZXIgYW5kIHNvbWUgb2YKdGhlc2UgPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyBkZXZpY2VzIGRvIGhhdmUgYSBQSU4gcGFkIHRoZXJlIGlzIHRoZSBjb25jZXB0Cm9mIGFu IGluaXRpYWwgUElOLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyBTaW5jZSB3ZSBoYXZlIG5vdCB5ZXQgZGVmaW5lZCBob3cgdGhpcyBpbml0aWFsClBJ TiBpcyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRyYW5zbWl0dGVkIGluIHRoZSBQU0tDIHNw ZWMgSSB3b3VsZCBsaWtlIHRvCnB1dCBmb3J3YXJkIGEgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyBwcm9wb3NhbCBmb3IgaW5jbHVzaW9uIGluIHRoZSBzcGVjIGZvcgpzcGVjaWZ5aW5nIHRoZSA8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRyYW5zbWlzc2lvbiBvZiBQSU5zLjwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBUaGUgUElOIGlzIGVmZmVj dGl2ZWx5IGFub3RoZXIgc2hhcmVkIHNlY3JldApoZW5jZSBJIHByb3Bvc2UgPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyB0byB0cmVhdCBpdCBhcyBhIGtleSBpbiBpdHNlbGYuPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFRoaXMgaGFzIHRoZSBhZHZh bnRhZ2UgdGhhdCB3ZSBjYW4gbGV2ZXJhZ2UgdGhlClVzYWdlIHBhcnQgb2YgPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyB0aGUgc2NoZW1hIHRoYXQgY2FuIGRlZmluZSB0aGluZ3MgbGlrZSBsZW5n dGgKYW5kIGZvcm1hdCA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IChhbHBoYW51bWVyaWMgZXRj KS4gd2UgYWxzbyBjYW4gc2V0IGFuIGV4cGlyeQpldGMuIEl0IGFsc28gPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyBsZXZlcmFnZXMgdGhlIGZhY3QgdGhhdCB0aGUgUElOIGl0c2VsZiB3aWxsIGJl CmVuY3J5cHRlZCBpbiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRyYW5zcG9ydCBpbiB0aGUg c2FtZSBtYW5uZXIgYXMgb3RoZXIga2V5Cm1hdGVyaWFsLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBJIGhlbmNlIHByb3Bvc2UgdG8gZXh0ZW5kIHRo ZSBLZXlBbGdvcml0aG1UeXBlCndpdGggYSBuZXcgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB0 eXBlIGNhbGxlZCAndXNlclBJTicgKGlubGluZSB3aXRoIHRoZSBuYW1lCnVzZWQgaW4gdGhlIDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgYWNjZXNzIHJ1bGVzIGVsZW1lbnQgYWxyZWFkeTwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgcHJlc2VudCk8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxw Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBBcyBhbiBl eGFtcGxlIGEgS2V5Q29udGFpbmVyIHdpdGggYSBub24KZW5jcnlwdGVkIEhPVFAga2V5IDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgYW5kIGEgNCBkaWdpdCBudW1lcmljIFBJTiAocGxlYXNlIG5v dGUgdGhhdCB0aGUKdmFsdWUgYW5kIDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgdmFsdWVkaWdl c3QgYXJlIGp1c3QgY29weSBhbmQgcGFzdGUpICggSSBwdXQKdGhlIG5ldyBzZWN0aW9uIDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgd2l0aCBORVctJmd0OyBhbmQgJmx0Oy1ORVcgbGluZXMgYmVm b3JlIGFuZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgYWZ0ZXIpOjwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 P3htbAp2ZXJzaW9uPSZxdW90OzEuMCZxdW90OyBlbmNvZGluZz0mcXVvdDtVVEYtOCZxdW90Oz8m Z3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7S2V5Q29u dGFpbmVyPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOwp4bWxucz0m cXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmtleXByb3Y6Y29udGFpbmVyJnF1b3Q7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOwp4bWxuczpsb2dvPSZxdW90O3Vy bjppZXRmOnBhcmFtczp4bWw6bnM6a2V5cHJvdjpsb2dvJnF1b3Q7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFu Zz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB4bWxuczpkcz0mcXVvdDs8YQpocmVmPSJodHRwOi8v d3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWciPmh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1s ZHNpZzwvYT4jJnF1b3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyB4bWxuczp4c2k9JnF1b3Q7PGEKaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hl bWEtaW5zdGFuY2UiPmh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlPC9h PiZxdW90Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgeHNpOnNj aGVtYUxvY2F0aW9uPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6a2V5cHJvdjpjb250YWlu ZXImcXVvdDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC5ca2V5cHJvdl9wc2tjX3NjaGVtYV92 MS4xLnhzZCZxdW90Owp2ZXJzaW9uPSZxdW90OzEuMSZxdW90OyZndDs8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtFbmNyeXB0aW9uTWV0 aG9kIGFsZ29yaXRobT0mcXVvdDtOT05FJnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtEaWdlc3RNZXRob2QKYWxnb3Jp dGhtPSZxdW90O0hNQUMtU0hBMSZxdW90OyZndDsmbHQ7L0RpZ2VzdE1ldGhvZCZndDs8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtEZXZp Y2UmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOwombHQ7RGV2aWNlSWQmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwom bHQ7TWFudWZhY3R1cmVyJmd0O1Rva2VuIE1hbnVmYWN0dXJlciZsdDsvTWFudWZhY3R1cmVyJmd0 Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O1NlcmlhbE5vJmd0Ozk4NzY1NDMyMTg3Jmx0Oy9T ZXJpYWxObyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtFeHBpcnkmZ3Q7MDEvMDEvMjAw OCZsdDsvRXhwaXJ5Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9EZXZpY2VJZCZndDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZs dDtLZXkgS2V5QWxnb3JpdGhtPSZxdW90O0hPVFAmcXVvdDsmbmJzcDsgS2V5SWQ9JnF1b3Q7OTg3 NjU0MzIxODcmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7SXNzdWVyJmd0O0Ny ZWRlbnRpYWwgSXNzdWVyJmx0Oy9Jc3N1ZXImZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7 VXNhZ2UmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7UmVzcG9uc2VGb3JtYXQg Zm9ybWF0PSZxdW90O0RFQ0lNQUwmcXVvdDsgbGVuZ3RoPSZxdW90OzYmcXVvdDsvJmd0Ozwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9Vc2FnZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IE5FVy0mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7QWNjZXNzUnVsZXMgdXNlclBJTj0m cXVvdDt0cnVlJnF1b3Q7LyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7ICZsdDstTkVXPC9z cGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7RnJpZW5kbHlOYW1lJmd0O015Rmlyc3RUb2tlbiZsdDsv RnJpZW5kbHlOYW1lJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0RhdGEgTmFtZT0mcXVv dDtTRUNSRVQmcXVvdDsmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7 VmFsdWUmZ3Q7V2xkalRIWndSbTlZVGtoQlJ5dHNlRE1yVW5jPSZsdDsvVmFsdWUmZ3Q7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7VmFsdWVEaWdlc3QmZ3Q7V2xkalRIWndS bTlZVGtoQlJ5dHNlRE09Jmx0Oy9WYWx1ZURpZ2VzdCZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 CiZsdDsvRGF0YSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtEYXRhIE5hbWU9JnF1b3Q7 Q09VTlRFUiZxdW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtW YWx1ZSZndDtXbGRqVEhad1JtOVlUa2hCUnl0c2VETXJVbmM9Jmx0Oy9WYWx1ZSZndDs8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtWYWx1ZURpZ2VzdCZndDtXbGRqVEhad1Jt OVlUa2hCUnl0c2VETT0mbHQ7L1ZhbHVlRGlnZXN0Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4t R0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsK Jmx0Oy9EYXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9LZXkmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyBORVctJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0tleSBLZXlBbGdvcml0aG09JnF1b3Q7dXNlclBJ TiZxdW90OyZuYnNwOyBLZXlJZD0mcXVvdDsxMjM0NTY3OCZxdW90OyZndDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7CiZsdDtJc3N1ZXImZ3Q7Q3JlZGVudGlhbCBJc3N1ZXImbHQ7L0lzc3VlciZndDs8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtVc2FnZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7CiZsdDtSZXNwb25zZUZvcm1hdCBmb3JtYXQ9JnF1b3Q7REVDSU1BTCZxdW90OyBsZW5n dGg9JnF1b3Q7NCZxdW90Oy8mZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7L1VzYWdlJmd0 Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0O0ZyaWVuZGx5TmFtZSZndDtNeUZpcnN0VG9rZW5J bml0aWFsUElOJmx0Oy9GcmllbmRseU5hbWUmZ3Q7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwombHQ7 RGF0YSBOYW1lPSZxdW90O1NFQ1JFVCZxdW90OyZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7CiZsdDtWYWx1ZSZndDtXbGRqVEhad1JtOVlUa2hCUnl0c2VETXJVbmM9Jmx0Oy9W YWx1ZSZndDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7CiZsdDtWYWx1ZURpZ2Vz dCZndDtXbGRqVEhad1JtOVlUa2hCUnl0c2VETT0mbHQ7L1ZhbHVlRGlnZXN0Jmd0Ozwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsKJmx0Oy9EYXRhJmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKJmx0Oy9LZXkmZ3Q7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyAmbHQ7LU5FVzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9EZXZpY2UmZ3Q7PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L0tleUNvbnRhaW5lciZndDs8L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ29tbWVudHMgYXJl IHdlbGNvbWUsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVO LUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7IFBoaWxpcDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Ig c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsg RnJvbTogPHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5IHc6c3Q9Im9uIj5NaW5nbGlhbmc8 L3N0MTpDaXR5PgogPHN0MTpTdGF0ZSB3OnN0PSJvbiI+UGVpPC9zdDE6U3RhdGU+PC9zdDE6cGxh Y2U+IFs8YQpocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+bWFpbHRvOmhh bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+XTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgU2Vu dDogRnJpZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMDcgOTo1OCBBTTwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgVG86IGtleXByb3ZAaWV0Zi5vcmc8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoK PHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFN1Ympl Y3Q6IFtLRVlQUk9WXSBbaXNzdWUyOF0gSG93IHRvIHRyYW5zZmVyCmluaXRpYWwgUElOIHRvIGEg PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBjbGllbnQgdmlhUFNLQz88L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1F Ti1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyBOZXcgc3VibWlzc2lvbiBmcm9tIDxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6Q2l0eQog dzpzdD0ib24iPk1pbmdsaWFuZzwvc3QxOkNpdHk+IDxzdDE6U3RhdGUgdzpzdD0ib24iPlBlaTwv c3QxOlN0YXRlPjwvc3QxOnBsYWNlPgombHQ7bXBlaUB2ZXJpc2lnbi5jb20mZ3Q7Ojwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBQU0tDIHByb3ZpZXMg c3VwcG9ydCBhYm91dCBjYXJyeWluZyBQSU4gdXNhZ2UKcG9saWN5LiBXaGVuIDwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgUElOIGlzIHVzZWQsPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4K CjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBob3cg ZG8gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB5b3UgYWN0dWFsbHkgdHJhbnNmZXIgdGhlIGlu aXRpYWwgUElOIHVzaW5nClBTS0M/IFNob3VsZCBQSU4gPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyBiZSB0cmVhdGVkPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBhcyA8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IGFub3RoZXIgY3JlZGVudGlhbCwgZm9yIGV4YW1wbGU/PC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g bGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IC0tLS0tLS0tLS08L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IGFzc2lnbmVkdG86IG1wZWk8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdC IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IG1lc3NhZ2VzOiA3MTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgbm9zeToga2V5cHJvdiwgbXBl aTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgcHJpb3JpdHk6IGNyaXRpY2FsPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyBzdGF0dXM6IGNoYXR0aW5nPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB0 aXRsZTogSG93IHRvIHRyYW5zZmVyIGluaXRpYWwgUElOIHRvIGEgY2xpZW50CnZpYSBQU0tDPzwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxw Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OwpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+ PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IEtFWVBST1YgUm91bmR1cCBJc3N1ZSBUcmFja2VyCiZsdDtoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgJmx0Ozxh CmhyZWY9Imh0dHA6Ly93d3cudHNjaG9mZW5pZy5jb206ODA4MC9rZXlwcm92L2lzc3VlMjgiPmh0 dHA6Ly93d3cudHNjaG9mZW5pZy5jb206ODA4MC9rZXlwcm92L2lzc3VlMjg8L2E+Jmd0Ozwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9m b250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsK Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBLRVlQUk9WIG1haWxpbmcgbGlzdDwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgS0VZUFJPVkBpZXRmLm9yZzwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgPGEKaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8va2V5 cHJvdiI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8va2V5cHJvdjwvYT48 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8 cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgS0VZUFJPViBtYWlsaW5nIGxpc3Q8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IEtFWVBST1ZAaWV0Zi5vcmc8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBs YW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IDxhCmhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2tleXByb3YiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2tleXByb3Y8 L2E+PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w PgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEtFWVBST1YgbWFpbGluZyBs aXN0PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBLRVlQUk9WQGlldGYub3JnPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyA8YQpocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9rZXlwcm92Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXlw cm92PC9hPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4KCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Owpmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4KCjxwPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsKZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBLRVlQUk9WIG1haWxp bmcgbGlzdDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 CmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgS0VZUFJPVkBpZXRmLm9yZzwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+Cgo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7CmZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgPGEKaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8va2V5cHJvdiI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v a2V5cHJvdjwvYT48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPgoKPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Owpmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+Cgo8L2Rpdj4KCgo8RElWPjxQPjxIUj4KTm90aWNlIHRvIFJlY2lwaWVudDogIFRo ZSBpbmZvcm1hdGlvbiBpbiB0aGlzIG1lc3NhZ2UgaXMgbWVhbnQgb25seSBmb3IgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvZiB0aGUgdHJhbnNtaXNzaW9uIGFuZCBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gPEJSPgpBbnkgY29weWluZywgcmV0cmFu c21pdHRhbCwgdGFraW5nIG9mIGFjdGlvbiBpbiByZWxpYW5jZSBvbiwgb3Igb3RoZXIgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGNvbW11bmljYXRpb24gYnkgcGVyc29ucyBvdGhlciB0 aGFuIHRoZSBhZGRyZXNzZWVzIGlzIHByb2hpYml0ZWQuICA8QlI+CklmIHlvdSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHVzIGFuZCBwbGVh c2UgZGVsZXRlIG9yIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuPEJSPgpUaGlz IG1lc3NhZ2UgbWF5IGhhdmUgYmVlbiBhbHRlcmVkIHdpdGhvdXQgeW91ciBvciBvdXIga25vd2xl ZGdlIGFuZCB0aGUgc2VuZGVyIGRvZXMgbm90IGFjY2VwdCBhbnkgbGlhYmlsaXR5IGZvciBhbnkg ZXJyb3JzLiAgVGhhbmsgeW91LjxCUj4KCjwvUD48L0RJVj4KPC9ib2R5PgoKPC9odG1sPgo= ------_=_NextPart_001_01C82F79.206953AE-- --===============1242014786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1242014786==-- From keyprov-bounces@ietf.org Mon Nov 26 06:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwcW7-0001rL-G3; Mon, 26 Nov 2007 06:52:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwcW6-0001rE-3R for keyprov@ietf.org; Mon, 26 Nov 2007 06:52:46 -0500 Received: from frhub1.activcard.fr ([91.151.120.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwcW5-0006dC-3N for keyprov@ietf.org; Mon, 26 Nov 2007 06:52:45 -0500 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 6800D25ED44; Mon, 26 Nov 2007 12:52:44 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WKH9Z2DC; Mon, 26 Nov 2007 12:58:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Nov 2007 12:54:46 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2524@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSKC] meeting minutes 14/11/07 Thread-Index: AcgwIyPN0bN5DjFyS9KIfD8dI5sWAg== From: "Philip Hoyer" To: , "Salah Machani" , , "Hallam-Baker, Phillip" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: keyprov@ietf.org Subject: [KEYPROV] [PSKC] meeting minutes 14/11/07 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514379317==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0514379317== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83023.24208750" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83023.24208750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: Phillip Hallam-Baker [PHB], Ming Pei, Philip Hoyer =20 =20 * Discussed question about URI in attribute or element. PHB things it is only matter of taste no best practice. So decision to leave for now. * Submission of new spec, Ming will check current document and fix examples over week end and submit. * Discussion about URI definition, where to put definition, in original algorithm draft in keyprov documents or in the new draft from Hallam Baker. PHB not really important where but that it is done. Objective is to create new IANA registry for algorithms. Maybe better to note the use of the algorithm in the keyprov drafts. PHB preference using existing identifier without creating new ones. What do we do about HOTP do we use OATH? Better not since HOTP now is RFC. [Ming] what about internal structure. [PHB] do not create internal structure. [Ming] should we use URN or URL? What about HOTP should the URL to the RFC? [PHB] need to check what is preferred in IETF, there is no right or wrong? * ACTION PHB to check what is best practice with IETF * What about namespace, currently we use URN. What is PHB opinion, currently stick with URN. [PHB] prefers URN because of operational issues since if URL are used some implementation pull the xsd. It makes sense that for algorithms there is no need to pull the algorithm. =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C83023.24208750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees: Phillip Hallam-Baker [PHB], = Ming Pei, Philip = Hoyer      =

 

  • Discussed = question about URI in attribute or element. PHB things it is only matter of = taste no best practice. So decision to leave for = now.
  • Submission of new spec, Ming will check current document and fix examples over week = end and submit.
  • Discussion about URI definition, where to put definition, in original algorithm draft in = keyprov documents or in the new draft from Hallam Baker. PHB not really = important where but that it is done. Objective is to create new IANA registry = for algorithms. Maybe better to note the use of the algorithm in the = keyprov drafts. PHB preference using existing identifier without creating = new ones. What do we do about HOTP do we use OATH? Better not since HOTP now = is RFC. [Ming] what about internal structure. [PHB] do not create internal structure. [Ming] should we use URN or URL? What about HOTP should = the URL to the RFC? [PHB] need to check what is preferred in IETF, there is = no right or wrong?
  • ACTION = PHB to check what is best practice with IETF
  • What = about namespace, currently we use URN. What is PHB opinion, currently = stick with URN. [PHB] prefers URN because of operational issues since if URL = are used some implementation pull the xsd. It makes sense that for = algorithms there is no need to pull the algorithm.

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, = distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C83023.24208750-- --===============0514379317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0514379317==-- From keyprov-bounces@ietf.org Mon Nov 26 15:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkiC-0005CH-T3; Mon, 26 Nov 2007 15:37:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkiA-0005AG-Mx for keyprov@ietf.org; Mon, 26 Nov 2007 15:37:46 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwki4-0002c7-O8 for keyprov@ietf.org; Mon, 26 Nov 2007 15:37:46 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAQKWI3L029712; Mon, 26 Nov 2007 12:32:18 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 12:36:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Date: Mon, 26 Nov 2007 12:36:27 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9577B18@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA251E@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? Thread-Index: Acf8MVrpAzqGMPw0Qiq5kI+8dbx60wFtRt+wA82XUAAAFH6XMAQ13Z+QAMedW/ACITewwACeq63Q From: "Pei, Mingliang" To: "Philip Hoyer" , "Doherty, Andrea" , "KEYPROV Roundup Issue Tracker" , X-OriginalArrivalTime: 26 Nov 2007 20:36:27.0622 (UTC) FILETIME=[04DC8060:01C8306C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 332c59655f21ab919af3dd431ceacad6 Cc: "M'Raihi, David" , "Bajaj, Siddharth" , Johan Rydell X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135345477==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0135345477== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8306C.04CEBF01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8306C.04CEBF01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 It looks good for remote PIN usage case, i.e., one PIN per key where PIN is used along with key for respective algorithm. Another point that we touched was to handle a device PINPolicy in the following situation: =20 - A PIN is provisioned and used to login to a device. The device may contain multiple keys. It would be redundant to include PINPolicy in each Key element for the m-key elements in a device. We may allow Device element to have a PINPolicy where PINUsageMode =3D Local. =20 Thus I consider a variation of this as follows. =20 I: =20 ... Issuer 1 Issuer 2 =20 II: =20 =20 I am not very satisfied with the two flavors of PINPolicy though. Thoughts? =20 - Ming ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Friday, November 23, 2007 8:08 AM To: Pei, Mingliang; Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? =09 =09 Andrea and Ming, As we discussed in the PSKC call I would like to explain a new proposal. =09 I would like to keep the way to transmit the PIN value as a key. We though want the flexibility to define possibly multiple PINs and which keys are protected by the PIN. =09 Hence I would like to introduce an element called PINPolicy Local =09 This will replace the accessrule element. =09 So to take the example of a PIN protected HOTP token with no encryption based on the latest draft with highlights: =09 Token Manufacturer 98765432188 12/31/2012 Credential Issuer MyFirstToken zOkqJENSsh6b2hdXz1WBK/oprbY=3D AAAAAAAAAAA=3D 10/30/2012 Local =20 Credential Issuer RandomInitialTokenPIN zOkqJENSsh6b2hdXz1WBK/oprbY=3D In this way we can specifically say what keys are protected by which PINs and re-use most of our constructs in Key that would apply to the PIN such as the format the way to encrypt etc etc. Thoughts? Philip =09 -----Original Message----- From: Pei, Mingliang [mailto:mpei@verisign.com] Sent: Tuesday, November 13, 2007 1:48 AM To: Doherty, Andrea; Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN to aclientviaPSKC? =09 I have chatted with Philip / Salah about my comments this afternoon while I was almost done my reply of this email. I sent it anyway now for broad review. Our meeting minutes from Philip later will contain other proposed changes in our discussion. 1. A PIN is associated with a key; we need to define a better way to associate with them when we carry PIN in a separate Key type. - The current proposal assumes that all keys in the same "Device" type will associate to the PIN credential in the same Device. - This has a limitation for "PREPEND" case where a device may have multiple keys, and each key has its own PIN as part of server authentication. 2. There is use case when a PIN is per device, instead of per key, for the "Local" access usage.=20 So I prefer defining PIN credential inside DeviceType, and refered by KeyType by an attribute or element, and DeviceType. 3. PIN policy is fine to have its own type. The AccessRule and PINUsageModeType should combine to be a PIN usage policy. If we are treating PIN as a separate credential, it is more consistent to make PIN usage policy part of Usage, I think. Thanks, - Ming =20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com]=20 > Sent: Thursday, November 08, 2007 12:31 PM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; M'Raihi, David; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Philip, >=20 > Thank you for your proposal. Here are a few comments: >=20 > 1. By do you mean "PIN is=20 > enabled"? Is the reverse true, that userPIN=3D"false"/> indicates PINless operation from a server's=20 > point of view?=20 >=20 > 2. Instead of , providing=20 > a PINUsageModeType would be more extensible and implementable: > > > > > > > >=20 > 3. Anders brought to my attention that a local PIN is needed=20 > instead of a server PIN in some scenarios. The device=20 > issuer, in this case, would also have a PIN policy that could=20 > differ from the policy of a server PIN. Anders provided the=20 > following example, which is taken from another=20 > standardization effort in the workings ("PKI for Web 2.0"): >=20 > // The following is sent down to the client by the issuer: >=20 > >=20 > // Request a key without PIN protection. >=20 > > > > > >=20 > // Request a set of keys with PIN protection. > // The specified policy disallows 11122 but accepts 11223 //=20 > 654321 would not be accepted either (sequence) >=20 > PatternRestrictions=3D"three-in-a-row sequences"> >=20 > // The next element is optional and is a way of grouping PINs=20 > // so that the user either only has to specify a single PIN=20 > // for a set of keys, or one unique PIN per key. >=20 > >=20 > > > > > > > > > > >=20 > >=20 > >=20 > >=20 > Your thoughts? > Andrea=20 >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Thursday, October 18, 2007 6:16 AM > To: Doherty, Andrea; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: M'Raihi, David; Bajaj,Siddharth; Johan Rydell > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to aclientviaPSKC? >=20 > Andrea, > You are right I have not addressed the Pin policy issue. >=20 > I would like to though.=20 >=20 > Since you seem to have a good idea of the requirements would=20 > you be able to help? >=20 > I suggest we create a new type called PINPolicy that contains=20 > the data required to be submitted. >=20 > So currently PIN usage I can think of is: > -KEY_ACCESS_CHECK (this check the pin on the device to allow=20 > access to a key for algorithms) -USED_IN_ALGO (used during=20 > calculation) >=20 > When you talk though about length I already have that in the=20 > part of the PIN 'key' see below >=20 > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW >=20 > Also when we talk about server verified pins in otps are we=20 > not really talking about the otp algo or usage here? >=20 > I was wondering hence if our usage element for the otp key=20 > should be augmented to contain and optional >=20 > >=20 > What do you think? >=20 > Philip >=20 >=20 > -----Original Message----- > From: Doherty, Andrea [mailto:adoherty@rsa.com] > Sent: Thursday, October 18, 2007 1:28 AM > To: Philip Hoyer; KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Philip, > This looks ok except that a more complex PIN policy is needed=20 > (refer to this comment I made to the previous version of the=20 > PSKC draft, Section > 5.1.7: > "Recommend that you allow for a more complex PIN policy,=20 > esp., (a) how the PIN is to be used in the OTP calculation=20 > (e.g., concatenated vs. > XOR's with the token code) and (b) PIN length. " >=20 > This doesn't seem to have been addressed yet based on=20 > feedback to my review (see attached) and example below. What=20 > is the status of this? =20 > Andrea >=20 > -----Original Message----- > From: Philip Hoyer [mailto:philip.hoyer@actividentity.com] > Sent: Friday, September 28, 2007 11:48 AM > To: KEYPROV Roundup Issue Tracker; keyprov@ietf.org > Cc: Bajaj, Siddharth; Johan Rydell; M'Raihi,David > Subject: RE: [KEYPROV] [issue28] How to transfer initial PIN=20 > to a clientviaPSKC? >=20 > Gentlemen, > Since PSKC will be used also to bulk provision from=20 > manufacturing to a validation server and some of these=20 > devices do have a PIN pad there is the concept of an initial PIN. >=20 > Since we have not yet defined how this initial PIN is=20 > transmitted in the PSKC spec I would like to put forward a=20 > proposal for inclusion in the spec for specifying the=20 > transmission of PINs. >=20 > The PIN is effectively another shared secret hence I propose=20 > to treat it as a key in itself. >=20 > This has the advantage that we can leverage the Usage part of=20 > the schema that can define things like length and format=20 > (alphanumeric etc). we also can set an expiry etc. It also=20 > leverages the fact that the PIN itself will be encrypted in=20 > transport in the same manner as other key material. >=20 > I hence propose to extend the KeyAlgorithmType with a new=20 > type called 'userPIN' (inline with the name used in the=20 > access rules element already > present) >=20 >=20 > As an example a KeyContainer with a non encrypted HOTP key=20 > and a 4 digit numeric PIN (please note that the value and=20 > valuedigest are just copy and paste) ( I put the new section=20 > with NEW-> and <-NEW lines before and > after): >=20 > > xmlns=3D"urn:ietf:params:xml:ns:keyprov:container" > xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo" > xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container" > .\keyprov_pskc_schema_v1.1.xsd" version=3D"1.1"> > > > > > Token Manufacturer > 98765432187 > 01/01/2008 > > > Credential Issuer > > > > NEW-> > > <-NEW > MyFirstToken > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > NEW-> > > Credential Issuer > > > > MyFirstTokenInitialPIN > > WldjTHZwRm9YTkhBRytseDMrUnc=3D > WldjTHZwRm9YTkhBRytseDM=3D > > > <-NEW > > >=20 > Comments are welcome, >=20 > Philip >=20 > -----Original Message----- > From: Mingliang Pei [mailto:hannes.tschofenig@gmx.net] > Sent: Friday, September 21, 2007 9:58 AM > To: keyprov@ietf.org > Subject: [KEYPROV] [issue28] How to transfer initial PIN to a=20 > client viaPSKC? >=20 >=20 > New submission from Mingliang Pei : >=20 > PSKC provies support about carrying PIN usage policy. When=20 > PIN is used, > how do=20 > you actually transfer the initial PIN using PSKC? Should PIN=20 > be treated > as=20 > another credential, for example? >=20 > ---------- > assignedto: mpei > messages: 71 > nosy: keyprov, mpei > priority: critical > status: chatting > title: How to transfer initial PIN to a client via PSKC? >=20 > _________________________________________________________ > KEYPROV Roundup Issue Tracker > > _________________________________________________________ >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 =09 ------_=_NextPart_001_01C8306C.04CEBF01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [KEYPROV] [issue28] How to transfer initial PIN = to aclientviaPSKC?
 
It looks good for remote PIN usage case, i.e., = one PIN per=20 key where PIN is used along with key for respective algorithm. Another = point=20 that we touched was to handle a device PINPolicy in the = following=20 situation:
 
- A PIN is provisioned and used to login = to a device.=20 The device may contain multiple keys. It would be redundant to include = PINPolicy=20 in each Key element for the m-key elements in a device. We may allow = Device=20 element to have a PINPolicy where PINUsageMode =3D = Local.
 
Thus I consider a variation of this as=20 follows.
 
I:
 
<Device>
   =20 <LocalPINPolicy/>
    <Key=20 KeyAlgorithm=3D"...#PIN"    =20 KeyId=3D1>...</Key>
    <Key = KeyAlgorithm=3D"...#HOTP"=20 KeyId=3D"2"><Issuer>Issuer=20 1</Issuer></Key>
    <Key = KeyAlgorithm=3D"...#HOTP"=20 KeyId=3D"3"><Issuer>Issuer=20 2</Issuer></Key>
</Device>
 
II:
 
<Device>
    <Key KeyAlgorithm=3D"...#PIN"=20 KeyId=3D"1"><PINPolicy = RefId=3D"2"/></Key>
    <Key = KeyAlgorithm=3D"...#PIN"=20 KeyId=3D"2"></Key>
</Device>
 
I am not very satisfied with the two flavors of = PINPolicy=20 though. Thoughts?
 
- Ming

From: Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Friday, = November 23,=20 2007 8:08 AM
To: Pei, Mingliang; Doherty, Andrea; KEYPROV = Roundup=20 Issue Tracker; keyprov@ietf.org
Cc: Bajaj, Siddharth; = M'Raihi,=20 David; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How to = transfer=20 initial PIN to aclientviaPSKC?

Andrea and=20 Ming,

As = we discussed in=20 the PSKC call I would like to explain a new = proposal.

I = would like to=20 keep the way to transmit the PIN value as a key.

We = though want the=20 flexibility to define possibly multiple PINs and which keys are = protected by=20 the PIN.

Hence I would like=20 to introduce an element called PINPolicy

<PINPolicy=20 PINRef=3D"KeyId of the key containing the PIN">

       =20 <PINUsageMode>

       =20         Local

        </PINUsageMode>

</PINPolicy>

This will replace=20 the accessrule element.

So = to take the=20 example of a PIN protected HOTP token with no encryption based on the = latest=20 draft with=20 highlights:

  =20 <?xml version=3D"1.0" encoding=3D"UTF-8"?>

  =20 <KeyContainer

    =20 = xmlns=3D"urn:ietf:params:xml:ns:keyprov:container:1.0"

     xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#"

     xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance"

    =20 = xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container:1.0=

       keyprov-pskc-1.0.xsd" Version=3D"1.0">

       = <Device>

        =20 <DeviceId>

           <Manufacturer>Token=20 Manufacturer</Manufacturer>

          =20 <SerialNo>98765432188</SerialNo>

          =20 <Expiry>12/31/2012</Expiry>

        =20 </DeviceId>

         <Key=20 KeyAlgorithm=3D"http://www.ietf.org/keypro= v/pskc#hotp"

          =20 KeyId=3D"77654321871">

        =20 <Issuer>Credential Issuer</Issuer>

           = <Usage=20 OTP=3D"true">

          &nbs= p; =20 <ResponseFormat Format=3D"DECIMAL" = Length=3D"6"/>

          =20 </Usage>

          =20 = <FriendlyName>MyFirstToken</FriendlyName>

           = <Data=20 Name=3D"SECRET">

          &nbs= p; =20 <Value>

          &nbs= p;   =20 zOkqJENSsh6b2hdXz1WBK/oprbY=3D

          &nbs= p; =20 </Value>

          =20 </Data>

           = <Data=20 Name=3D"COUNTER">

          &nbs= p; =20 <Value>AAAAAAAAAAA=3D</Value>

          =20 </Data>

          =20 <Expiry>10/30/2012</Expiry>

             <PINPolicy=20 PINRef=3D"77654321872">

          &nbs= p;     <PINUsageMode>Local</PINUsageMode>

=

           </PINPolicy>=20        

        =20 </Key>

         <Key = KeyAlgorithm=3D"http://www.ietf.org/keyprov/psk= c#PIN"

          =20 KeyId=3D"77654321872">

        =20 <Issuer>Credential Issuer</Issuer>

          =20 <Usage>

          &nbs= p; =20 <ResponseFormat Format=3D"DECIMAL" Length=3D"4"/>

          =20 </Usage>

          =20 <FriendlyName>RandomInitialTokenPIN</FriendlyName>

           = <Data=20 Name=3D"SECRET">

          &nbs= p; =20 <Value>

          &nbs= p;   =20 zOkqJENSsh6b2hdXz1WBK/oprbY=3D

          &nbs= p; =20 </Value>

          =20 </Data>

        =20 </Key>

       = </Device>

  =20 </KeyContainer>


In = this way we can=20 specifically say what keys are protected by which PINs and re-use most = of=20 our constructs=20 in Key that would apply to the PIN such as the format the way to = encrypt etc=20 etc.

Thoughts?

Philip

-----Original Message-----
From: Pei, Mingliang [mailto:mpei@verisign.com]
Sent: = Tuesday, November 13, 2007 1:48 AM
To: Doherty, Andrea; Philip = Hoyer;=20 KEYPROV Roundup Issue Tracker; keyprov@ietf.org
Cc: Bajaj, = Siddharth;=20 M'Raihi, David; Johan Rydell
Subject: RE: [KEYPROV] [issue28] How = to=20 transfer initial PIN to aclientviaPSKC?

I = have chatted=20 with Philip / Salah about my comments this afternoon

while I was almost=20 done my reply of this email. I sent it anyway now = for

broad review. Our=20 meeting minutes from Philip later will contain other

proposed changes=20 in our discussion.

1. = A PIN is=20 associated with a key; we need to define a better way = to

associate with=20 them when we carry PIN in a separate Key type.

- = The current=20 proposal assumes that all keys in the same "Device" = type

will associate to=20 the PIN credential in the same Device.

- = This has a=20 limitation for "PREPEND" case where a device may = have

multiple keys, and=20 each key has its own PIN as part of server

authentication.

2. = There is use=20 case when a PIN is per device, instead of per key, = for

the "Local" access=20 usage.

So = I prefer=20 defining PIN credential inside DeviceType, and refered = by

KeyType by an=20 attribute or element, and DeviceType.

3. = PIN policy is=20 fine to have its own type. The AccessRule and

PINUsageModeType=20 should combine to be a PIN usage policy. If we are

treating PIN as a=20 separate credential, it is more consistent to make = PIN

usage policy part=20 of Usage, I think.

Thanks,

-=20 Ming

 

> -----Original=20 Message-----

> From:=20 Doherty, Andrea [mailto:adoherty@rsa.com] =

> Sent:=20 Thursday, November 08, 2007 12:31 PM

> To: Philip=20 Hoyer; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: Bajaj,=20 Siddharth; M'Raihi, David; Johan Rydell

> Subject: RE:=20 [KEYPROV] [issue28] How to transfer initial PIN

> to=20 aclientviaPSKC?

>=20

>=20 Philip,

>=20

> Thank you for=20 your proposal.  Here are a few comments:

>=20

> 1. By=20 <AccessRules userPIN=3D"true"/> do you mean "PIN is =

>=20 enabled"?  Is the reverse true, that <AccessRules =

>=20 userPIN=3D"false"/> indicates PINless operation from a server's=20

> point of=20 view?

>=20

> 2. Instead of=20 <UserPIN position=3D"APPEND/PREPEND"/>, providing =

> a=20 PINUsageModeType would be more extensible and = implementable:

>=20 <xs:complexType name=3D"PINUsageModeType">

>=20       <xs:choice=20 maxOccurs=3D"unbounded">

>=20       =        =20 <xs:element name=3D"Local"/>

>=20       =        =20 <xs:element name=3D"Prepend"/>

>=20       =        =20 <xs:element name=3D"Embed"/>

>=20       </xs:choice>

>=20 </xs:complexType>

>=20

> 3. Anders=20 brought to my attention that a local PIN is needed

> instead of a=20 server PIN in some scenarios.  The device

> issuer, in=20 this case, would also have a PIN policy that could

> differ from=20 the policy of a server PIN.  Anders provided the =

> following=20 example, which is taken from another

>=20 standardization effort in the workings ("PKI for Web = 2.0"):

>=20

> // The=20 following is sent down to the client by the issuer:

>=20

>=20 <KeyGenerationRequest ...>

>=20

> // Request a=20 key without PIN protection.

>=20

>  =20 <RequestedKey ID=3D"Key.1" = KeyUsage=3D"encryption">

>     = <KeyAlgorithmData>

>       <RSA=20 KeySize=3D"2048"/>

>    =20 </KeyAlgorithmData>

>  =20 </RequestedKey>

>=20

> // Request a=20 set of keys with PIN protection.

> // The=20 specified policy disallows 11122 but accepts 11223 // =

> 654321 would=20 not be accepted either (sequence)

>=20

>  =20 <PINProtection Type=3D"numeric" MinLength=3D"5" = MaxLength=3D"8"

>          =        =20 PatternRestrictions=3D"three-in-a-row  = sequences">

>=20

> // The next=20 element is optional and is a way of grouping PINs

> // so that=20 the user either only has to specify a single PIN

> // for a set=20 of keys, or one unique PIN per key.

>=20

>     <PINGroupProtection=20 Shared=3D"true">

>=20

>       <RequestedKey = ID=3D"Key.2"=20 KeyUsage=3D"signature">

>        =20 <KeyAlgorithmData>

>          = =20 <RSA KeySize=3D"2048"/>

>        =20 </KeyAlgorithmData>

>      =20 </RequestedKey>

>       <RequestedKey = ID=3D"Key.3"=20 KeyUsage=3D"authentication">

>        =20 <KeyAlgorithmData>

>          = =20 <RSA KeySize=3D"2048"/>

>        =20 </KeyAlgorithmData>

>      =20 </RequestedKey>

>=20

>    =20 </PINGroupProtection>

>=20

>  =20 </PINProtection>

>=20

>=20 </KeyGenerationRequest>

>=20

> Your=20 thoughts?

> Andrea=20

>=20

> -----Original=20 Message-----

> From: Philip=20 Hoyer [mailto:philip.hoyer@activi= dentity.com]

> Sent:=20 Thursday, October 18, 2007 6:16 AM

> To: Doherty,=20 Andrea; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: M'Raihi,=20 David; Bajaj,Siddharth; Johan Rydell

> Subject: RE:=20 [KEYPROV] [issue28] How to transfer initial PIN

> to=20 aclientviaPSKC?

>=20

>=20 Andrea,

> You are right=20 I have not addressed the Pin policy issue.

>=20

> I would like=20 to though.

>=20

> Since you=20 seem to have a good idea of the requirements would

> you be able=20 to help?

>=20

> I suggest we=20 create a new type called PINPolicy that contains

> the data=20 required to be submitted.

>=20

> So currently=20 PIN usage I can think of is:

>=20 -KEY_ACCESS_CHECK (this check the pin on the device to allow=20

> access to a=20 key for algorithms) -USED_IN_ALGO (used during

>=20 calculation)

>=20

> When you talk=20 though about length I already have that in the

> <Usage>=20 part of the PIN 'key' see below

>=20

>=20 NEW->

>        <Key=20 KeyAlgorithm=3D"userPIN"  = KeyId=3D"12345678">

>         =20 <Issuer>Credential Issuer</Issuer>

>         =20 <Usage>

>          = =20 <ResponseFormat format=3D"DECIMAL" = length=3D"4"/>

>         =20 </Usage>

>         =20 = <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>

>          = <Data=20 Name=3D"SECRET">

>          =  =20 = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          =  =20 = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>         =20 </Data>

>       =20 </Key>

>=20 <-NEW

>=20

> Also when we=20 talk about server verified pins in otps are we

> not really=20 talking about the otp algo or usage here?

>=20

> I was=20 wondering hence if our usage element for the otp key =

> should be=20 augmented to contain and optional

>=20

> <UserPIN=20 position=3D"APPEND/PREPEND"/>

>=20

> What do you=20 think?

>=20

>=20 Philip

>=20

>=20

> -----Original=20 Message-----

> From:=20 Doherty, Andrea [mailto:adoherty@rsa.com]

> Sent:=20 Thursday, October 18, 2007 1:28 AM

> To: Philip=20 Hoyer; KEYPROV Roundup Issue Tracker; = keyprov@ietf.org

> Cc: Bajaj,=20 Siddharth; Johan Rydell; M'Raihi,David

> Subject: RE:=20 [KEYPROV] [issue28] How to transfer initial PIN

> to a=20 clientviaPSKC?

>=20

>=20 Philip,

> This looks ok=20 except that a more complex PIN policy is needed

> (refer to=20 this comment I made to the previous version of the

> PSKC draft,=20 Section

>=20 5.1.7:

> "Recommend=20 that you allow for a more complex PIN policy,

> esp., (a) how=20 the PIN is to be used in the OTP calculation

> (e.g.,=20 concatenated vs.

> XOR's with=20 the token code) and (b) PIN length. "

>=20

> This doesn't=20 seem to have been addressed yet based on

> feedback to=20 my review (see attached) and example below.  What =

> is the status=20 of this? 

>=20 Andrea

>=20

> -----Original=20 Message-----

> From: Philip=20 Hoyer [mailto:philip.hoyer@activi= dentity.com]

> Sent: Friday,=20 September 28, 2007 11:48 AM

> To: KEYPROV=20 Roundup Issue Tracker; keyprov@ietf.org

> Cc: Bajaj,=20 Siddharth; Johan Rydell; M'Raihi,David

> Subject: RE:=20 [KEYPROV] [issue28] How to transfer initial PIN

> to a=20 clientviaPSKC?

>=20

>=20 Gentlemen,

> Since PSKC=20 will be used also to bulk provision from

> manufacturing=20 to a validation server and some of these

> devices do=20 have a PIN pad there is the concept of an initial = PIN.

>=20

> Since we have=20 not yet defined how this initial PIN is

> transmitted=20 in the PSKC spec I would like to put forward a

> proposal for=20 inclusion in the spec for specifying the

> transmission=20 of PINs.

>=20

> The PIN is=20 effectively another shared secret hence I propose

> to treat it=20 as a key in itself.

>=20

> This has the=20 advantage that we can leverage the Usage part of

> the schema=20 that can define things like length and format

> (alphanumeric=20 etc). we also can set an expiry etc. It also

> leverages the=20 fact that the PIN itself will be encrypted in

> transport in=20 the same manner as other key material.

>=20

> I hence=20 propose to extend the KeyAlgorithmType with a new

> type called=20 'userPIN' (inline with the name used in the

> access rules=20 element already

>=20 present)

>=20

>=20

> As an example=20 a KeyContainer with a non encrypted HOTP key

> and a 4 digit=20 numeric PIN (please note that the value and

> valuedigest=20 are just copy and paste) ( I put the new section

> with NEW->=20 and <-NEW lines before and

>=20 after):

>=20

>    <?xml version=3D"1.0"=20 encoding=3D"UTF-8"?>

>    <KeyContainer

>   =20 xmlns=3D"urn:ietf:params:xml:ns:keyprov:container"

>   =20 xmlns:logo=3D"urn:ietf:params:xml:ns:keyprov:logo"

>    xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#"

>    xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance"

>   =20 = xsi:schemaLocation=3D"urn:ietf:params:xml:ns:keyprov:container"

>=20 .\keyprov_pskc_schema_v1.1.xsd" version=3D"1.1">

>      <EncryptionMethod=20 algorithm=3D"NONE"/>

>      <DigestMethod=20 algorithm=3D"HMAC-SHA1"></DigestMethod>

>      = <Device>

>       =20 <DeviceId>

>         =20 <Manufacturer>Token = Manufacturer</Manufacturer>

>         =20 <SerialNo>98765432187</SerialNo>

>         =20 <Expiry>01/01/2008</Expiry>

>       =20 </DeviceId>

>        <Key=20 KeyAlgorithm=3D"HOTP"  = KeyId=3D"98765432187">

>         =20 <Issuer>Credential Issuer</Issuer>

>         =20 <Usage>

>          = =20 <ResponseFormat format=3D"DECIMAL" = length=3D"6"/>

>         =20 </Usage>

>=20 NEW->

>         =20 <AccessRules userPIN=3D"true"/>

>=20 <-NEW

>         =20 = <FriendlyName>MyFirstToken</FriendlyName>

>          = <Data=20 Name=3D"SECRET">

>          =  =20 = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          =  =20 = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>         =20 </Data>

>          = <Data=20 Name=3D"COUNTER">

>          =  =20 = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          =  =20 = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>         =20 </Data>

>       =20 </Key>

>=20 NEW->

>        <Key=20 KeyAlgorithm=3D"userPIN"  = KeyId=3D"12345678">

>         =20 <Issuer>Credential Issuer</Issuer>

>         =20 <Usage>

>          = =20 <ResponseFormat format=3D"DECIMAL" = length=3D"4"/>

>         =20 </Usage>

>         =20 = <FriendlyName>MyFirstTokenInitialPIN</FriendlyName>

>          = <Data=20 Name=3D"SECRET">

>          =  =20 = <Value>WldjTHZwRm9YTkhBRytseDMrUnc=3D</Value>

>          =  =20 = <ValueDigest>WldjTHZwRm9YTkhBRytseDM=3D</ValueDigest><= /SPAN>

>         =20 </Data>

>       =20 </Key>

>=20 <-NEW

>      = </Device>

>    = </KeyContainer>

>=20

> Comments are=20 welcome,

>=20

>=20 Philip

>=20

> -----Original=20 Message-----

> From:=20 Mingliang Pei [mailto:hannes.tschofenig@gmx.ne= t]

> Sent: Friday,=20 September 21, 2007 9:58 AM

> To:=20 keyprov@ietf.org

> Subject:=20 [KEYPROV] [issue28] How to transfer initial PIN to a =

> client=20 viaPSKC?

>=20

>=20

> New=20 submission from Mingliang Pei = <mpei@verisign.com>:

>=20

> PSKC provies=20 support about carrying PIN usage policy. When

> PIN is=20 used,

> how do=20

> you actually=20 transfer the initial PIN using PSKC? Should PIN

> be=20 treated

> as=20

> another=20 credential, for example?

>=20

>=20 ----------

> assignedto:=20 mpei

> messages:=20 71

> nosy:=20 keyprov, mpei

> priority:=20 critical

> status:=20 chatting

> title: How to=20 transfer initial PIN to a client via PSKC?

>=20

>=20 = _________________________________________________________

> KEYPROV=20 Roundup Issue Tracker = <hannes.tschofenig@gmx.net>

> <http://www.tschof= enig.com:8080/keyprov/issue28>

>=20 = _________________________________________________________

>=20

>=20 _______________________________________________

> KEYPROV=20 mailing list

>=20 KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>=20

>=20

>=20 _______________________________________________

> KEYPROV=20 mailing list

>=20 KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>=20

>=20

>=20 _______________________________________________

> KEYPROV=20 mailing list

>=20 KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>=20

>=20

>=20 _______________________________________________

> KEYPROV=20 mailing list

>=20 KEYPROV@ietf.org

> https://www1.ietf= .org/mailman/listinfo/keyprov

>=20

------_=_NextPart_001_01C8306C.04CEBF01-- --===============0135345477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0135345477==-- From keyprov-bounces@ietf.org Mon Nov 26 17:48:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmks-0007MK-4c; Mon, 26 Nov 2007 17:48:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwmkq-0007LY-26 for keyprov@ietf.org; Mon, 26 Nov 2007 17:48:40 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwmko-0004tM-TV for keyprov@ietf.org; Mon, 26 Nov 2007 17:48:39 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAQMhGNv002608; Mon, 26 Nov 2007 14:43:16 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 14:47:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Nov 2007 14:47:25 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C95FFCB1@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2409@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on DSKPP and alignment issues Thread-Index: Acf7oug3ta9C5KZbTbqUCnRJgKeQagVdlpyAABM8ePAAFoU0EACzkD4QBvszj/A= From: "Pei, Mingliang" To: "Philip Hoyer" , "Doherty, Andrea" , "Salah" , X-OriginalArrivalTime: 26 Nov 2007 22:47:26.0209 (UTC) FILETIME=[50F1B710:01C8307E] X-Spam-Score: 0.0 (/) X-Scan-Signature: bec09d1709ba59869cec93c1a1c207e5 Cc: keyprov@ietf.org Subject: [KEYPROV] RE: Comments on DSKPP and alignment issues X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132253991==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1132253991== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8307E.50C0B48B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8307E.50C0B48B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have resolved most alignment issues between DSKPP and PSKC. There are a few minor issues to resolve. =20 1. KeyType as an element in DSKPP vs. KeyType as a type for key in PSKC. =20 Proposal: =20 Change DSKPP KeyType to be KeyAlgorithm. Notice that the actual value of KeyType matches the attribute KeyAlgorithm of PSKC KeyType. =20 =20 http://www.ietf.org/keyprov/pskc#HOTP =20 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu rID-AES =20 http://www.ietf.org/keyprov/pskc#HOTP <.../> =20 become =20 =20 http://www.ietf.org/keyprov/pskc#HOTP =20 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu rID-AES =20 Comments? =20 2. (new) For element name convention about IDs, DSKPP currently uses "xxxID" (e.g. KeyID) while PSKC uses "xxxId" (e.g., KeyId). Which style do you vote for? =20 Please see inline for status on the others. =20 Thanks, =20 - Ming =09 ________________________________ From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Thursday, September 20, 2007 12:26 PM To: Doherty, Andrea; Pei, Mingliang; Salah; magnus@rsa.com Cc: Shuh Subject: Comments on DSKPP and alignment issues Hi Andrea and others, =20 Please find below an analysis for alignment points between DSKPP and PSKC and a long overdue comment on the draft itself. =20 Please review and then I would like to agree on what we should tackle for the next two releases of the respective specs, end of this month and end of next month. =20 Feel free to post to the mailing list, I was not sure that I immediately should. =20 Philip =20 Alignment points =20 1) KeyType DSKPP The type of symmetric cryptographic methods for which the key will be used (e.g., OATH HOTP or RSA SecurID authentication, AES encryption, etc.) =20 PSKC The KeyType represents the key entity in the KeyContainer. =20 MP: TBD =20 2) Key Container DSKPP Key Container =20 An object that encapsulates a symmetric key and its configuration data (DSKPP Key Container is effectively the PSKC KeyType) =20 PSKC The KeyContainerType represents the key container entity. A Container MAY contain more than one Device entity; each Device entity MAY contain more than one Key entity. =20 MP: PSKC KeyContainer is used. =20 3) VersionType DSKPP: =20 PSKC =20 MP: DSKPP version type is adopted. =20 4) AlgorithmsType =20 MP: Use URI in both DSKPP and PSKC. =20 5) KeyID DSKPP base64binary PSKC string =20 MP: Use "string" type. =20 COMMENTS: 4.2.2 Key wrapping normally is intended as a generic mechanism that can be used with symmetric and asymmetric keys. Is there a reason for the distinction between Key Transport and Key Wrap? These methods need alignment with the protection mechanism s in PSKC so for example a pre-shared key label or index should be supported. =20 Two Pass DSKPP What about a use case where DSKPP server does not generate the keys itself but wants to provision Ks (obtained form a credential provider) directly to the device without derivation. Do we support this? The other use case of this is that a key K is generated inside an HSM and then exported WRAPPED, this key would then need to be provisioned via DSKPP to the device without other derivations. =20 4.3.1.1 Unless the use of the private key of the certificate is protected with a credential like a PIN this would not authenticate the user but only be a proof of possession of the device =20 4.3.1.3 What hash algorithms are supported, should we define that certain algorithms MUST be supported? Can the client transmit which algorithm was used in case more than one is supported? =20 General comments about authentication section 4.3 There is a lot of work and a proliferation of protocols that has been done for mutual authentication in the smart card world for the setup of secure channel mechanisms. Global platform SCP01 and SCP02 are some examples. I suggest we take this into consideration. Matter of fact if one would think of piggy backing those ideas the authentication would be multiple pass and result in a generation of secure communication session keys that can be used by DSKPP to protect the payload or used to generate the keys. =20 It is not very clearly defined what authentication is mandated (eg proof of possession of device) whereas the initial statement talks about user authentication. =20 4.5.2=20 The k is mandated as 16 octets, in section 4.6 the example is:=20 =20 K_TOKEN =3D DSKPP-PRF (R_C, "Key generation" || k || R_S, dsLen) =20 So R_C representing k MUST be 16 octets=20 =20 But section 4.2.1 we state: "Based on information contained in the message, the cryptographic module generates a random nonce, R_C. The length of the nonce R_C may depend on the selected key type." =20 =20 4.8.1.1 Should we use whitespace characters in the string inputted into MAC, I suggest '_' is better than whitespace ' ' since whitespace can be represented by ASCII 32 and extended ASCII 255. So I suggest using 'MAC_1_computation' Same for all strings used as input into MACs. =20 =20 4.8.2.1 "Further, the server is REQUIRED to include an identifier, ID_S, for itself (via the key container) in the message." The format for ID_S is not defined. Also if the container is PSKC where should this be set? =20 =20 4.9.1 and 4.9.2 In other protocol work we had both the concept of a unique request id and the concept of the session id. If we think that DSKPP could also be bound over non session protocols then being able to specify that the response is the response for a specific (identified by the request Id coming back) request can be very useful. Please see OTPS ValidationService for an example. =20 4.9.5 Since there is an authentication protocol happening is 'AuthenticationDataInvalid' enough? Is there a need to distinguish between ClientId not found and wrong one time authentication code?=20 =20 4.9.7 If more than one module is connected to the client do we need the ability to pass the module number and slot number here? Even if optionally? =20 4.9.12 ClientId, if this can represent the user, it might be a DN as in RFC 2253, hence the identifier restriction of 128 characters might be too small. if this is only the certificate as transmitted in ds:KeyInfoType one does not know if the certificate was PIN protected eg proof of user being present or not. =20 4.10.3 since PSKC is mandated we could make the PSKC URI the default value in the schema What about versioning of the PSKC, do we drive it via the URI or explicitely? In case versioning is driven via URI should we mention it in the text? =20 =20 =20 =20 ________________________________ =20 =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C8307E.50C0B48B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We have = resolved most=20 alignment issues between DSKPP and PSKC. There are a few minor issues to = resolve.
 
1. = KeyType as an=20 element in DSKPP vs. KeyType as a type for key in=20 PSKC.
 
Proposal:
 
Change = DSKPP KeyType=20 to be KeyAlgorithm. Notice that the actual value of KeyType matches the=20 attribute KeyAlgorithm of PSKC = KeyType.
 
<xs:element=20 name=3D"KeyType"
 =20 type=3D"dskpp:AlgorithmType"/>
 
<KeyProvClientHello=20 ...>
 <SupportedKeyTypes>
 =20 <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm><= BR> =20 <Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst= #SecurID-AES</Algorithm>
 </SupportedKeyTypes>=
 
<KeyProvServerHello=20 ...>
 =20 <KeyAlgorithm>http://www.ietf.org/keyprov/pskc#HOTP</KeyAlgorith= m>
 =20 <.../>
<KeyProvServerHello>
 
become
 
<xs:element=20 name=3D"KeyAlgorithm"
 =20 type=3D"dskpp:AlgorithmType"/>
 
<KeyProvClientHello=20 ...>
 <SupportedKeyAlgorithms>
 = =20 <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm><= BR> =20 <Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst= #SecurID-AES</Algorithm>
 </SupportedKeyAlgorithms>
 
Comments?
 
2. (new) = For=20 element name convention about IDs, DSKPP currently uses "xxxID" (e.g. = KeyID)=20 while PSKC uses "xxxId" (e.g., KeyId). Which style do you vote=20 for?
 
Please see inline=20 for status on the others.
 
Thanks,
 
- Ming

From:=20 Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Thursday, September 20, = 2007 12:26=20 PM
To: Doherty, = Andrea; Pei,=20 Mingliang; Salah; magnus@rsa.com
Cc: Shuh
Subject: Comments on DSKPP and = alignment=20 issues

Hi Andrea and=20 others,

 

Please find below an = analysis for=20 alignment points between DSKPP and PSKC and a long overdue comment on = the=20 draft itself.

 

Please review and then I = would=20 like to agree on what we should tackle for the next two releases of = the=20 respective specs, end of this month and end of next=20 month.

 

Feel free to post to the = mailing=20 list, I was not sure that I immediately = should.

 

Philip

 

Alignment=20 points

 

1)=20 KeyType

DSKPP

The type of symmetric=20 cryptographic methods for which the key will be used (e.g., OATH HOTP = or RSA=20 SecurID authentication,=20 = AES           &nbs= p;            = ;=20 encryption, etc.)

 

PSKC

The KeyType represents = the key=20 entity in the KeyContainer.

 

MP:=20 TBD

 

2) Key=20 Container

DSKPP

Key=20 Container      =20  

An object that = encapsulates a=20 symmetric key and its configuration data

(DSKPP Key Container is=20 effectively the PSKC KeyType)

 

PSKC

The KeyContainerType = represents=20 the key container entity.  A Container MAY contain more than one = Device=20 entity; each Device entity MAY contain more than one Key=20 entity.

 

MP: PSKC KeyContainer = is=20 used.

 

3)=20 VersionType

DSKPP:

<xs:simpleType=20 name=3D"VersionType">

     = <xs:restriction base=3D"xs:string">

      =20 <xs:pattern = value=3D"\d{1,2}\.\d{1,3}"/>

     = </xs:restriction>

  =20 </xs:simpleType>

 

PSKC

<simpleType = name=3D"VersionType"=20 final=3D"restriction">

           =              = <restriction base=3D"string">

           =             &= nbsp;           =20 <pattern = value=3D"\d{1,9}\.\d{0,9}"/>

           =              = </restriction>

</simpleType>

 

MP: DSKPP version type is=20 adopted.

 

4)=20 AlgorithmsType

 

MP: Use URI in both DSKPP and=20 PSKC.

 

5)=20 KeyID

DSKPP=20 base64binary

PSKC=20 string

 

MP: Use "string" = type.

 

COMMENTS:

4.2.2

           = =20 Key wrapping normally is intended as a generic mechanism that can be = used with=20 symmetric and asymmetric keys. Is there a reason for the distinction = between=20 Key Transport and Key Wrap? These methods need alignment with the = protection=20 mechanism s in PSKC so for example a pre-shared key label or index = should be=20 supported.

 

Two Pass=20 DSKPP

What about a use case = where DSKPP=20 server does not generate the keys itself but wants to provision Ks = (obtained=20 form a credential provider) directly to the device without derivation. = Do we=20 support this? The other use case of this is that a key K is generated = inside=20 an HSM and then exported WRAPPED, this key would then need to be = provisioned=20 via DSKPP to the device without other=20 derivations.

 

4.3.1.1 Unless the use = of the=20 private key of the certificate is protected with a credential like a = PIN this=20 would not authenticate the user but only be a proof of possession of = the=20 device

 

4.3.1.3 What hash = algorithms are=20 supported, should we define that certain algorithms MUST be supported? = Can the=20 client transmit which algorithm was used in case more than one is=20 supported?

 

General comments about=20 authentication section 4.3

There is a lot of work = and a=20 proliferation of protocols that has been done for mutual = authentication in the=20 smart card world for the setup of secure channel mechanisms. Global = platform=20 SCP01 and SCP02 are some examples. I suggest we take this into=20 consideration.

Matter of fact if one = would think=20 of piggy backing those ideas the authentication would be multiple pass = and=20 result in a generation of secure communication session keys that can = be used=20 by DSKPP to protect the payload or used to generate the=20 keys.

 

It is not very clearly = defined=20 what authentication is mandated (eg proof of possession of device) = whereas the=20 initial statement talks about user=20 authentication.

 

4.5.2=20

The k is mandated as 16 = octets, in=20 section 4.6 the example is:

 

K_TOKEN =3D DSKPP-PRF = (R_C, "Key=20 generation" || k || R_S, dsLen)

 

So R_C representing k = MUST be 16=20 octets

 

But section 4.2.1 we=20 state:

“Based on = information contained in=20 the <ServerHello> message, the cryptographic module generates a = random=20 nonce, R_C. The         length = of the=20 nonce R_C may depend on the selected key = type.”

 

 

4.8.1.1

Should we use whitespace = characters in the string inputted into MAC, I suggest ‘_’ = is better than=20 whitespace ‘ ‘ since whitespace can be represented by = ASCII 32 and extended=20 ASCII 255. So I suggest using ‘MAC_1_computation’ Same for = all strings used as=20 input into MACs.

 

 

4.8.2.1

“Further, the = server is REQUIRED=20 to include an identifier, ID_S, for itself (via the key container) in = the=20 <ServerFinished> message.”

The format for ID_S is = not=20 defined. Also if the container is PSKC where should this be=20 set?

 

 

4.9.1 and=20 4.9.2

In other protocol work = we had both=20 the concept of a unique request id and the concept of the session id. = If we=20 think that DSKPP could also be bound over non session protocols then = being=20 able to specify that the response is the response for a specific = (identified=20 by the request Id coming back) request can be very useful. Please see = OTPS=20 ValidationService for an example.

 

4.9.5

Since there is an = authentication=20 protocol happening is ‘AuthenticationDataInvalid’ enough? = Is there a need to=20 distinguish between ClientId not found and wrong one time = authentication code?=20

 

4.9.7

If more than one module = is=20 connected to the client do we need the ability to pass the module = number and=20 slot number here? Even if optionally?

 

4.9.12

ClientId, if this can = represent=20 the user, it might be a DN as in RFC 2253, hence the identifier = restriction of=20 128 characters might be too small.

<AuthenticationCertificate>=20 if this is only the certificate as transmitted in ds:KeyInfoType one = does not=20 know if the certificate was PIN protected eg proof of user being = present or=20 not.

 

4.10.3

<SupportedKeyContainers>=20 since PSKC is mandated we could make the PSKC URI the default value in = the=20 schema

What about versioning of = the PSKC,=20 do we drive it via the URI or explicitely? In case versioning is = driven via=20 URI should we mention it in the text?

 

 

 

 

________________________________

 

 

Philip=20 Hoyer=20

 

Senior Architect = - Office=20 of CTO

 

ActivIdentity = (UK)=

109 Borough High = Street

London SE1=20 1NL

 

Telephone: +44 = (0) 20 7744=20 6248

Direct: +44 (0) = 20 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended=20 recipient,

you must not = copy,=20 distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C8307E.50C0B48B-- --===============1132253991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1132253991==-- From keyprov-bounces@ietf.org Mon Nov 26 19:18:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwo9a-0002bo-Ab; Mon, 26 Nov 2007 19:18:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwo9Y-0002bh-R3 for keyprov@ietf.org; Mon, 26 Nov 2007 19:18:16 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwo9Y-0000up-7X for keyprov@ietf.org; Mon, 26 Nov 2007 19:18:16 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lAR0CUKc005918; Mon, 26 Nov 2007 16:12:30 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Nov 2007 00:16:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Nov 2007 16:16:39 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C95FFCD7@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC401562335@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PSKC wrapped key question Thread-Index: AcgroaLfWu+4E5eeQRmAAwjQRCNIjwE5UfNw From: "Pei, Mingliang" To: "James Holland" X-OriginalArrivalTime: 27 Nov 2007 00:16:39.0907 (UTC) FILETIME=[C7FF3330:01C8308A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: keyprov@ietf.org Subject: [KEYPROV] RE: PSKC wrapped key question X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032871936==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============1032871936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8308A.C7EFE400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8308A.C7EFE400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi James, =20 This is a good case that you raised where a target key isn't revealed to the server with HSM. =20 For your first question, I think that it should rely on client authentication. The transport certificate in a request isn't sufficient for this purpose, I think. Anyone would be able to request a key, including MITM. =20 For the second question, we are actually pending on making a change that doesn't use the presence of a ValueDigest to indicate "isEncryped". It isn't natural other than the HSM case you raised. One proposal is to add an attribute in DataType to indicate whether it is encrypted. We defered this change in the current version in consideration of possible adoption of XMLEnc that wouldn't need this change. =20 For PKCS#8 format that your HSM returns, do you mean standard PKCS#1 http://www.w3.org/2001/04/xmlenc#rsa-1_5 wrapped 3DES key data? Currently encryption algorithm type is anyURI; this should give sufficient flexibility to specify an algorithm. =20 - Ming ________________________________ From: James Holland [mailto:james.holland@actividentity.com]=20 Sent: Tuesday, November 20, 2007 10:18 AM To: Pei, Mingliang Cc: Philip Hoyer; shuh.chang@gemalto.com; keyprov@ietf.org Subject: PSKC wrapped key question =09 =09 Hi Ming, =20 I am a colleague of Philip Hoyer and I have a question about the mandatory digest of key material within the PSKC document. The latest draft state: - =20 5.1.1. Data (OPTIONAL) =20 Defines the data attributes of the symmetric key. Each is a name value pair which has both a base64 encoded value and a base 64 encoded ValueDigest. The value can be encrypted. If the container has been encrypted the ValueDigest MUST be populated with the digest of the unencrypted value. =20 =20 In our scenario we receive a request from a 3rd party to generate a 3DES key in a HSM. In the request they pass a transport certificate that has their public RSA key. With this public RSA key we wrap the generated key for export to the requesting 3rd party. However, as we never have the generated key in "plain" outside the HSM we cannot generate a digest of the key material it to be put into the PSKC document. The wrapped key is returned from the HSM in the PSKC#8 format which we return in the document. =20 So, in this scenario, a man in the middle attack my intercept the request and return their own wrapped key within the document, as they too have the transport key. What would you recommend as a possible solution to this, if any?=20 =20 Also, in the scenario when there has been a key exchange ceremony between the two parties, would this be a valid case for no mandatory digest of the key material, with the wrapped key returned? =20 =20 =20 Regards, =20 James Holland =09 =09 Product Architect - ActivIdentity =09 Mob: +44 787 6197 626 London Office Tel: +44 207 744 6460 Skype on callto://hoggmania/ =20 =20 P Think before you print =20 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. =20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.1/1140 - Release Date: 19/11/2007 19:05 =09 ------_=_NextPart_001_01C8308A.C7EFE400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi James,
 
This is a good case that you raised where a = target key=20 isn't revealed to the server with HSM.
 
For your first question, I think that it should = rely on=20 client authentication. The transport certificate in a request isn't = sufficient=20 for this purpose, I think. Anyone would be able to request a key, = including=20 MITM.
 
For the second question, we are actually = pending on making=20 a change that doesn't use the presence of a ValueDigest to indicate=20 "isEncryped". It isn't natural other than the HSM case you raised. One = proposal=20 is to add an attribute in DataType to indicate whether it is encrypted. = We=20 defered this change in the current version in consideration of possible = adoption=20 of XMLEnc that wouldn't need this change.
 
For PKCS#8 format that your HSM returns, do you = mean=20 standard PKCS#1 http://www.w3.org/2001/= 04/xmlenc#rsa-1_5 wrapped=20 3DES key data? Currently encryption algorithm type is anyURI; this = should give=20 sufficient flexibility to specify an algorithm.
 
- Ming

From: James Holland=20 [mailto:james.holland@actividentity.com]
Sent: Tuesday, = November=20 20, 2007 10:18 AM
To: Pei, Mingliang
Cc: Philip = Hoyer;=20 shuh.chang@gemalto.com; keyprov@ietf.org
Subject: PSKC = wrapped key=20 question

Hi Ming,

 

         &= nbsp;     =20 I am a colleague of Philip Hoyer and I have a question about the = mandatory=20 digest of key material within the PSKC document. The latest draft = state:=20 -

 

5.1.1.  Data = (OPTIONAL)

 

   Defines the data attributes of = the=20 symmetric key.  Each is a name

   value pair which has both a = base64 encoded=20 value and a base 64

   encoded ValueDigest.  The = value can be=20 encrypted.  If the container

   has been encrypted the = ValueDigest MUST be=20 populated with the digest

   of the unencrypted=20 value.

 

 

In our scenario we receive a request from a = 3rd=20 party to generate a 3DES key in a HSM. In the request they pass a = transport=20 certificate that has their public RSA key. With this public RSA key we = wrap=20 the generated key for export to the requesting 3rd party. = However,=20 as we never have the generated key in “plain” outside the = HSM we cannot=20 generate a digest of the key material it to be put into the PSKC = document. The=20 wrapped key is returned from the HSM in the  PSKC#8 format which = we=20 return in the document.

 

So, in this scenario,  a man in the middle = attack my=20 intercept the request and return their own wrapped key within the = document, as=20 they too have the transport key. What would you recommend as a = possible=20 solution to this, if any?

 

Also, in the scenario when there has been a key = exchange=20 ceremony between the two parties, would this be a valid case for no = mandatory=20 digest of the key material, with the wrapped key = returned?

 

 

 

Regards,

 

James=20 Holland

Product = Architect -=20 ActivIdentity

Mob: = +44 787=20 6197 626

London = Office Tel:=20 +44 207 744 6460
Skype on callto://hoggmania/

 

P=20 Think=20 before you print

 

The = information=20 contained in this email message may be privileged, confidential and = protected=20 from disclosure. If you are not the intended recipient, any = dissemination,=20 distribution or copying is strictly prohibited. If you think that you = have=20 received this email message in error, please notify the sender by = reply email=20 and delete the message and any attachments.

 


No virus found in this outgoing message.
Checked = by AVG=20 Free Edition.
Version: 7.5.503 / Virus Database: 269.16.1/1140 - = Release=20 Date: 19/11/2007 19:05

------_=_NextPart_001_01C8308A.C7EFE400-- --===============1032871936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============1032871936==-- From keyprov-bounces@ietf.org Tue Nov 27 10:45:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2ci-0000Sh-Cm; Tue, 27 Nov 2007 10:45:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2ch-0000SY-46 for keyprov@ietf.org; Tue, 27 Nov 2007 10:45:19 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix2cR-0000lw-W4 for keyprov@ietf.org; Tue, 27 Nov 2007 10:45:19 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lARFhiXi006798; Tue, 27 Nov 2007 10:43:44 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 27 Nov 2007 10:43:43 -0500 Received: from rsana-ex-hq1.NA.RSA.NET (rsana-ex-hq1.na.rsa.net [10.100.8.50]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lARFhbXO016945; Tue, 27 Nov 2007 10:43:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Nov 2007 10:43:23 -0500 Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE2970D453035@rsana-ex-hq1.NA.RSA.NET> In-reply-to: <3E5A2F1AD44F5E49A74F79AB47C0C0C95FFCB1@mou1wnexmb10.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on DSKPP and alignment issues Thread-Index: Acf7oug3ta9C5KZbTbqUCnRJgKeQagVdlpyAABM8ePAAFoU0EACzkD4QBvszj/AAI/VukA== References: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2409@sur-corp-ex-02.corp.ad.activcard.com> <3E5A2F1AD44F5E49A74F79AB47C0C0C95FFCB1@mou1wnexmb10.vcorp.ad.vrsn.com> From: "Doherty, Andrea" To: "Pei, Mingliang" , "Philip Hoyer" , "Salah" , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=X, SPAM=19%, Reasons='ECARD_WORD! 2, HTML_70_90 0.1, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_BOLD 0, __HTML_FONT_BLUE 0, __HTML_FONT_GREEN 0, __HTML_FONT_RED 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: 2aa34c4ab5f171a446500d5e81b7c403 Cc: keyprov@ietf.org Subject: [KEYPROV] RE: Comments on DSKPP and alignment issues X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0545854170==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============0545854170== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8310C.3B582841" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8310C.3B582841 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ming, regarding #1 (KeyType), below, it would be good to get feedback from others. KeyType is more commonly used, and I would argue that it would be clearer to implementers than KeyAlgorithm in the context that we are using it. =20 =20 For those who missed this before, here is a previous email exchange that Ming and I had on this topic:=20 =20 In a previous email exchange, I raised the point that -=20 #7, KeyType: A Google search was done and there were 610,000 hits on keyType. However, there were only 9 hits on keyAlgorithmType, of which 7 are from PSKC. keyAlgorithmType is a common notation in several APIs including PKCS#11. What other aspects of keyTypes are there than the algorithm? For EncryptionAlgorithm, etc., one cannot just say "Encryption", but possibly could say "EncryptionMechanism". If that was the case, then wouldn't it make more sense to say keyMechanismType? =09 * As a guiding principal, I think that it is important that KEYPROV docs rely on commonly used, rather than homegrown, types. =09 Ming responded that -=20 The google search result is interesting about KeyType. However, the numbers cannot justify the choice though. One reason is that KeyType itself can have multiple meanings while KeyAlgorithm is more specific to our purpose. =09 * Key may be database primary key; so KeyType was used by some for database index reference. * Key can be also used for a hash table. Then key type for a hash table has more reference. * Our particular refernece is for a "secret". =09 In the first page of the google search result, the first two / PKSC11 class KeyType is the main one related. The rest is mostly not relevant to our meaning of key. Anyway, I do see your point, and like to get broad opinions. KeyType is intuitive to mean what kind of key, and I don't see strong reasons. KeyAlgorithm is more specific to algorithms associated with a key. We have an issue that KeyType is used differently in DSKPP and PSKC that we need to resolve for a best fit. In PSKC, KeyType is a type to define a Key. Key has an attribute called KeyAlgorithm. If we look at JCE, there is definition of Key class. The attribute is algorithm, not a type. So it looks natural. In DSKPP, KeyType is an element instead. Let us try to not use the same word in two types of keyprov docs. In DSKPP, KeyType is actually a AlgorithmType. See ServerHello definition below. ... =09 For this reason, it seems to be also natural to change KeyType to KeyAlgorithm, similar to the existing EncryptionAlgorithm in the same block of definition about ServerHello. I am open for another better choice. Andrea ________________________________ From: Pei, Mingliang [mailto:mpei@verisign.com]=20 Sent: Monday, November 26, 2007 5:47 PM To: Philip Hoyer; Doherty, Andrea; Salah; magnus@rsa.com Cc: Shuh; keyprov@ietf.org Subject: RE: Comments on DSKPP and alignment issues We have resolved most alignment issues between DSKPP and PSKC. There are a few minor issues to resolve. =20 1. KeyType as an element in DSKPP vs. KeyType as a type for key in PSKC. =20 Proposal: =20 Change DSKPP KeyType to be KeyAlgorithm. Notice that the actual value of KeyType matches the attribute KeyAlgorithm of PSKC KeyType. =20 =20 http://www.ietf.org/keyprov/pskc#HOTP =20 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu rID-AES =20 http://www.ietf.org/keyprov/pskc#HOTP <.../> =20 become =20 =20 http://www.ietf.org/keyprov/pskc#HOTP =20 http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#Secu rID-AES =20 Comments? =20 2. (new) For element name convention about IDs, DSKPP currently uses "xxxID" (e.g. KeyID) while PSKC uses "xxxId" (e.g., KeyId). Which style do you vote for? =20 Please see inline for status on the others. =20 Thanks, =20 - Ming =09 ________________________________ =09 From: Philip Hoyer [mailto:philip.hoyer@actividentity.com]=20 Sent: Thursday, September 20, 2007 12:26 PM To: Doherty, Andrea; Pei, Mingliang; Salah; magnus@rsa.com Cc: Shuh Subject: Comments on DSKPP and alignment issues Hi Andrea and others, =20 Please find below an analysis for alignment points between DSKPP and PSKC and a long overdue comment on the draft itself. =20 Please review and then I would like to agree on what we should tackle for the next two releases of the respective specs, end of this month and end of next month. =20 Feel free to post to the mailing list, I was not sure that I immediately should. =20 Philip =20 Alignment points =20 1) KeyType DSKPP The type of symmetric cryptographic methods for which the key will be used (e.g., OATH HOTP or RSA SecurID authentication, AES encryption, etc.) =20 PSKC The KeyType represents the key entity in the KeyContainer. =20 MP: TBD =20 2) Key Container DSKPP Key Container =20 An object that encapsulates a symmetric key and its configuration data (DSKPP Key Container is effectively the PSKC KeyType) =20 PSKC The KeyContainerType represents the key container entity. A Container MAY contain more than one Device entity; each Device entity MAY contain more than one Key entity. =20 MP: PSKC KeyContainer is used. =20 3) VersionType DSKPP: =20 PSKC =20 MP: DSKPP version type is adopted. =20 4) AlgorithmsType =20 MP: Use URI in both DSKPP and PSKC. =20 5) KeyID DSKPP base64binary PSKC string =20 MP: Use "string" type. =20 COMMENTS: 4.2.2 Key wrapping normally is intended as a generic mechanism that can be used with symmetric and asymmetric keys. Is there a reason for the distinction between Key Transport and Key Wrap? These methods need alignment with the protection mechanism s in PSKC so for example a pre-shared key label or index should be supported. =20 Two Pass DSKPP What about a use case where DSKPP server does not generate the keys itself but wants to provision Ks (obtained form a credential provider) directly to the device without derivation. Do we support this? The other use case of this is that a key K is generated inside an HSM and then exported WRAPPED, this key would then need to be provisioned via DSKPP to the device without other derivations. =20 4.3.1.1 Unless the use of the private key of the certificate is protected with a credential like a PIN this would not authenticate the user but only be a proof of possession of the device =20 4.3.1.3 What hash algorithms are supported, should we define that certain algorithms MUST be supported? Can the client transmit which algorithm was used in case more than one is supported? =20 General comments about authentication section 4.3 There is a lot of work and a proliferation of protocols that has been done for mutual authentication in the smart card world for the setup of secure channel mechanisms. Global platform SCP01 and SCP02 are some examples. I suggest we take this into consideration. Matter of fact if one would think of piggy backing those ideas the authentication would be multiple pass and result in a generation of secure communication session keys that can be used by DSKPP to protect the payload or used to generate the keys. =20 It is not very clearly defined what authentication is mandated (eg proof of possession of device) whereas the initial statement talks about user authentication. =20 4.5.2=20 The k is mandated as 16 octets, in section 4.6 the example is:=20 =20 K_TOKEN =3D DSKPP-PRF (R_C, "Key generation" || k || R_S, dsLen) =20 So R_C representing k MUST be 16 octets=20 =20 But section 4.2.1 we state: "Based on information contained in the message, the cryptographic module generates a random nonce, R_C. The length of the nonce R_C may depend on the selected key type." =20 =20 4.8.1.1 Should we use whitespace characters in the string inputted into MAC, I suggest '_' is better than whitespace ' ' since whitespace can be represented by ASCII 32 and extended ASCII 255. So I suggest using 'MAC_1_computation' Same for all strings used as input into MACs. =20 =20 4.8.2.1 "Further, the server is REQUIRED to include an identifier, ID_S, for itself (via the key container) in the message." The format for ID_S is not defined. Also if the container is PSKC where should this be set? =20 =20 4.9.1 and 4.9.2 In other protocol work we had both the concept of a unique request id and the concept of the session id. If we think that DSKPP could also be bound over non session protocols then being able to specify that the response is the response for a specific (identified by the request Id coming back) request can be very useful. Please see OTPS ValidationService for an example. =20 4.9.5 Since there is an authentication protocol happening is 'AuthenticationDataInvalid' enough? Is there a need to distinguish between ClientId not found and wrong one time authentication code?=20 =20 4.9.7 If more than one module is connected to the client do we need the ability to pass the module number and slot number here? Even if optionally? =20 4.9.12 ClientId, if this can represent the user, it might be a DN as in RFC 2253, hence the identifier restriction of 128 characters might be too small. if this is only the certificate as transmitted in ds:KeyInfoType one does not know if the certificate was PIN protected eg proof of user being present or not. =20 4.10.3 since PSKC is mandated we could make the PSKC URI the default value in the schema What about versioning of the PSKC, do we drive it via the URI or explicitely? In case versioning is driven via URI should we mention it in the text? =20 =20 =20 =20 ________________________________ =20 =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C8310C.3B582841 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ming, regarding=20 #1 (KeyType), below, it would be = good to=20 get feedback from others.  KeyType is more commonly used, and I = would argue=20 that it would be clearer to implementers than KeyAlgorithm in the = context that=20 we are using it. 
 
For those who missed this before, here is a = previous=20 email exchange that Ming and I had on this topic:=20
 
In a previous email exchange, I raised the = point that -=20
       &nbs= p;   =20 #7, KeyType: A Google search was done and there were 610,000 hits on=20 keyType.  However, there were only 9 hits on keyAlgorithmType, of = which 7=20 are from PSKC.  keyAlgorithmType is a common notation in several = APIs=20 including PKCS#11.  What other aspects of keyTypes are there than = the=20 algorithm?  For EncryptionAlgorithm, etc., one cannot just say=20 "Encryption", but possibly could say "EncryptionMechanism".  If = that was=20 the case, then wouldn't it make more sense to say=20 keyMechanismType?

       =20 *  As a guiding principal, I think that it is important that = KEYPROV=20 docs rely on commonly used, rather than homegrown, = types.
Ming responded that -
    The=20 google search result is interesting about KeyType. However, the = numbers cannot=20 justify the choice though. One reason is that KeyType itself can have = multiple=20 meanings while KeyAlgorithm is more specific to our purpose.

* = Key may=20 be database primary key; so KeyType was used by some for database = index=20 reference.
* Key can be also used for a hash table. Then key type = for a=20 hash table has more reference.
* Our particular refernece is for a=20 "secret".

In the first page of the google search result, the = first two=20 / PKSC11 class KeyType is the main one related. The rest is mostly not = relevant to our meaning of key.
Anyway, I do see your point, and = like to=20 get broad opinions. KeyType is intuitive to mean what kind of key, and = I don't=20 see strong reasons. KeyAlgorithm is more specific to algorithms = associated=20 with a key. We have an issue that KeyType is used differently in DSKPP = and=20 PSKC that we need to resolve for a best fit. In PSKC, KeyType is a = type to=20 define a Key. Key has an attribute called KeyAlgorithm. If we look at = JCE,=20 there is definition of Key class. The attribute is algorithm, not a = type. So=20 it looks natural. In DSKPP, KeyType is = an element=20 instead. Let us try to not use the same word in two types of keyprov = docs. In=20 DSKPP, KeyType is actually a AlgorithmType. See ServerHello definition = below.

  = <xs:complexType=20 name=3D"ServerHelloPDU">...
         <xs:sequence=20 = minOccurs=3D"0">
      = ;    =20 <xs:element=20 = name=3D"KeyType"
         = ;   =20 = type=3D"dskpp:AlgorithmType"/>
  =         =20 <xs:element=20 name=3D"EncryptionAlgorithm"
         &nb= sp;  =20 = type=3D"dskpp:AlgorithmType"/>
  =         =20 <xs:element=20 = name=3D"MacAlgorithm"
        =     =20 type=3D"dskpp:AlgorithmType"/>

For this reason, it seems to = be also=20 natural to change KeyType to KeyAlgorithm, similar to the existing=20 EncryptionAlgorithm in the same block of definition about ServerHello. = I am=20 open for another better = choice.

Andrea
From: Pei, Mingliang = [mailto:mpei@verisign.com]=20
Sent: Monday, November 26, 2007 5:47 PM
To: Philip = Hoyer;=20 Doherty, Andrea; Salah; magnus@rsa.com
Cc: Shuh;=20 keyprov@ietf.org
Subject: RE: Comments on DSKPP and alignment=20 issues

We have = resolved most=20 alignment issues between DSKPP and PSKC. There are a few minor issues to = resolve.
 
1. = KeyType as an=20 element in DSKPP vs. KeyType as a type for key in=20 PSKC.
 
Proposal:
 
Change = DSKPP KeyType=20 to be KeyAlgorithm. Notice that the actual value of KeyType matches the=20 attribute KeyAlgorithm of PSKC = KeyType.
 
<xs:element=20 name=3D"KeyType"
 =20 type=3D"dskpp:AlgorithmType"/>
 
<KeyProvClientHello=20 ...>
 <SupportedKeyTypes>
 =20 <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm><= BR> =20 <Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst= #SecurID-AES</Algorithm>
 </SupportedKeyTypes>=
 
<KeyProvServerHello=20 ...>
 =20 <KeyAlgorithm>http://www.ietf.org/keyprov/pskc#HOTP</KeyAlgorith= m>
 =20 <.../>
<KeyProvServerHello>
 
become
 
<xs:element=20 name=3D"KeyAlgorithm"
 =20 type=3D"dskpp:AlgorithmType"/>
 
<KeyProvClientHello=20 ...>
 <SupportedKeyAlgorithms>
 = =20 <Algorithm>http://www.ietf.org/keyprov/pskc#HOTP</Algorithm><= BR> =20 <Algorithm>http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst= #SecurID-AES</Algorithm>
 </SupportedKeyAlgorithms>
 
Comments?
 
2. (new) = For=20 element name convention about IDs, DSKPP currently uses "xxxID" (e.g. = KeyID)=20 while PSKC uses "xxxId" (e.g., KeyId). Which style do you vote=20 for?
 
Please see inline=20 for status on the others.
 
Thanks,
 
- Ming

From:=20 Philip Hoyer=20 [mailto:philip.hoyer@actividentity.com]
Sent: Thursday, September 20, = 2007 12:26=20 PM
To: Doherty, = Andrea; Pei,=20 Mingliang; Salah; magnus@rsa.com
Cc: Shuh
Subject: Comments on DSKPP and = alignment=20 issues

Hi Andrea and=20 others,

 

Please find below an = analysis for=20 alignment points between DSKPP and PSKC and a long overdue comment on = the=20 draft itself.

 

Please review and then I = would=20 like to agree on what we should tackle for the next two releases of = the=20 respective specs, end of this month and end of next=20 month.

 

Feel free to post to the = mailing=20 list, I was not sure that I immediately = should.

 

Philip

 

Alignment=20 points

 

1)=20 KeyType

DSKPP

The type of symmetric=20 cryptographic methods for which the key will be used (e.g., OATH HOTP = or RSA=20 SecurID authentication,=20 = AES           &nbs= p;            = ;=20 encryption, etc.)

 

PSKC

The KeyType represents = the key=20 entity in the KeyContainer.

 

MP:=20 TBD

 

2) Key=20 Container

DSKPP

Key=20 Container      =20  

An object that = encapsulates a=20 symmetric key and its configuration data

(DSKPP Key Container is=20 effectively the PSKC KeyType)

 

PSKC

The KeyContainerType = represents=20 the key container entity.  A Container MAY contain more than one = Device=20 entity; each Device entity MAY contain more than one Key=20 entity.

 

MP: PSKC KeyContainer = is=20 used.

 

3)=20 VersionType

DSKPP:

<xs:simpleType=20 name=3D"VersionType">

     = <xs:restriction base=3D"xs:string">

      =20 <xs:pattern = value=3D"\d{1,2}\.\d{1,3}"/>

     = </xs:restriction>

  =20 </xs:simpleType>

 

PSKC

<simpleType = name=3D"VersionType"=20 final=3D"restriction">

           =              = <restriction base=3D"string">

           =             &= nbsp;           =20 <pattern = value=3D"\d{1,9}\.\d{0,9}"/>

           =              = </restriction>

</simpleType>

 

MP: DSKPP version type is=20 adopted.

 

4)=20 AlgorithmsType

 

MP: Use URI in both DSKPP and=20 PSKC.

 

5)=20 KeyID

DSKPP=20 base64binary

PSKC=20 string

 

MP: Use "string" = type.

 

COMMENTS:

4.2.2

           = =20 Key wrapping normally is intended as a generic mechanism that can be = used with=20 symmetric and asymmetric keys. Is there a reason for the distinction = between=20 Key Transport and Key Wrap? These methods need alignment with the = protection=20 mechanism s in PSKC so for example a pre-shared key label or index = should be=20 supported.

 

Two Pass=20 DSKPP

What about a use case = where DSKPP=20 server does not generate the keys itself but wants to provision Ks = (obtained=20 form a credential provider) directly to the device without derivation. = Do we=20 support this? The other use case of this is that a key K is generated = inside=20 an HSM and then exported WRAPPED, this key would then need to be = provisioned=20 via DSKPP to the device without other=20 derivations.

 

4.3.1.1 Unless the use = of the=20 private key of the certificate is protected with a credential like a = PIN this=20 would not authenticate the user but only be a proof of possession of = the=20 device

 

4.3.1.3 What hash = algorithms are=20 supported, should we define that certain algorithms MUST be supported? = Can the=20 client transmit which algorithm was used in case more than one is=20 supported?

 

General comments about=20 authentication section 4.3

There is a lot of work = and a=20 proliferation of protocols that has been done for mutual = authentication in the=20 smart card world for the setup of secure channel mechanisms. Global = platform=20 SCP01 and SCP02 are some examples. I suggest we take this into=20 consideration.

Matter of fact if one = would think=20 of piggy backing those ideas the authentication would be multiple pass = and=20 result in a generation of secure communication session keys that can = be used=20 by DSKPP to protect the payload or used to generate the=20 keys.

 

It is not very clearly = defined=20 what authentication is mandated (eg proof of possession of device) = whereas the=20 initial statement talks about user=20 authentication.

 

4.5.2=20

The k is mandated as 16 = octets, in=20 section 4.6 the example is:

 

K_TOKEN =3D DSKPP-PRF = (R_C, "Key=20 generation" || k || R_S, dsLen)

 

So R_C representing k = MUST be 16=20 octets

 

But section 4.2.1 we=20 state:

“Based on = information contained in=20 the <ServerHello> message, the cryptographic module generates a = random=20 nonce, R_C. The         length = of the=20 nonce R_C may depend on the selected key = type.”

 

 

4.8.1.1

Should we use whitespace = characters in the string inputted into MAC, I suggest ‘_’ = is better than=20 whitespace ‘ ‘ since whitespace can be represented by = ASCII 32 and extended=20 ASCII 255. So I suggest using ‘MAC_1_computation’ Same for = all strings used as=20 input into MACs.

 

 

4.8.2.1

“Further, the = server is REQUIRED=20 to include an identifier, ID_S, for itself (via the key container) in = the=20 <ServerFinished> message.”

The format for ID_S is = not=20 defined. Also if the container is PSKC where should this be=20 set?

 

 

4.9.1 and=20 4.9.2

In other protocol work = we had both=20 the concept of a unique request id and the concept of the session id. = If we=20 think that DSKPP could also be bound over non session protocols then = being=20 able to specify that the response is the response for a specific = (identified=20 by the request Id coming back) request can be very useful. Please see = OTPS=20 ValidationService for an example.

 

4.9.5

Since there is an = authentication=20 protocol happening is ‘AuthenticationDataInvalid’ enough? = Is there a need to=20 distinguish between ClientId not found and wrong one time = authentication code?=20

 

4.9.7

If more than one module = is=20 connected to the client do we need the ability to pass the module = number and=20 slot number here? Even if optionally?

 

4.9.12

ClientId, if this can = represent=20 the user, it might be a DN as in RFC 2253, hence the identifier = restriction of=20 128 characters might be too small.

<AuthenticationCertificate>=20 if this is only the certificate as transmitted in ds:KeyInfoType one = does not=20 know if the certificate was PIN protected eg proof of user being = present or=20 not.

 

4.10.3

<SupportedKeyContainers>=20 since PSKC is mandated we could make the PSKC URI the default value in = the=20 schema

What about versioning of = the PSKC,=20 do we drive it via the URI or explicitely? In case versioning is = driven via=20 URI should we mention it in the text?

 

 

 

 

________________________________

 

 

Philip=20 Hoyer=20

 

Senior Architect = - Office=20 of CTO

 

ActivIdentity = (UK)=

109 Borough High = Street

London SE1=20 1NL

 

Telephone: +44 = (0) 20 7744=20 6248

Direct: +44 (0) = 20 7744=20 6455

Fax: +44 (0) 20 = 7744=20 6249

 

Private and = confidential:=20 This message and any attachments may = contain

privileged / = confidential=20 information. If you are not an intended=20 recipient,

you must not = copy,=20 distribute, discuss or take any action in reliance on=20 it.

If you have = received this=20 communication in error, please notify the = sender

and delete this = message=20 immediately.

 

------_=_NextPart_001_01C8310C.3B582841-- --===============0545854170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============0545854170==-- From keyprov-bounces@ietf.org Wed Nov 28 07:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLx3-0007kU-DM; Wed, 28 Nov 2007 07:23:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxLx1-0007gY-RJ for keyprov@ietf.org; Wed, 28 Nov 2007 07:23:35 -0500 Received: from frhub1.activcard.fr ([91.151.120.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxLx0-0008K9-SI for keyprov@ietf.org; Wed, 28 Nov 2007 07:23:35 -0500 Received: from sur-corp-ex-01.activcard.fr (unknown [192.168.33.28]) by frhub1.activcard.fr (Postfix) with ESMTP id 87BEE25ED44; Wed, 28 Nov 2007 13:23:34 +0100 (CET) Received: from sur-corp-ex-02.corp.ad.activcard.com ([192.168.33.40]) by sur-corp-ex-01.activcard.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WKH9ZNNM; Wed, 28 Nov 2007 13:29:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 13:25:33 +0100 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC4FA2531@sur-corp-ex-02.corp.ad.activcard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSKC] conf call minutes 26/11/07 Thread-Index: AcgxucWDvFUGsvEwShS7xoc8dcRrqw== From: "Philip Hoyer" To: , "Salah Machani" , , "Hannes Tschofenig" , "Hallam-Baker, Phillip" X-Spam-Score: 0.0 (/) X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1 Cc: keyprov@ietf.org Subject: [KEYPROV] [PSKC] conf call minutes 26/11/07 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2041701564==" Errors-To: keyprov-bounces@ietf.org This is a multi-part message in MIME format. --===============2041701564== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831B9.C82167FE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831B9.C82167FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attendees: Ming Pei, Hannes Tschofenig, Salah Macchani, Phillip Hallam-Baker, Philip Hoyer =20 Issues to discuss at IETF meeting 3rd of December: * Xmlenc/xmldsig usage * Salah did couple of tests in terms of hierarchy in terms of supporting on mobile phones (without signature) and it was ok. Salah in general ok with proposal. [Salah to capture issues]. * [Ming to review proposal and add comments on slide] * Profiling the use of algorithms because of move to URIs=20 * PHB small preference for not using xmlenc because of need of profiling. But on the other hand if things need to be done later we could ride on that instead of extending keyprov. * PINPolicy=20 * What about keyTemplate (have attributes) [Ming] agrees on Usage PINPolicy, helps mostly for bulk, but size is not that critical. Nice to have. Not necessary for single key. Not needed to present at IETF. * URI for algorithms especially specific ones. ACTION Philip Hallam Baker to send slide content to Ming * Alignment of attributes between PSKC and ASN.1 spec. ACTION Hannes to look at the issue. Philip's suggestion was to put the definition in a specific section of PSKC spec referenced from ASN.1 spec. * Logotype how do we proceed=20 =20 Slides [Ming to collate]:[PHB] no specific format.[Hannes to upload] first draft COB Wednesday. * Highlight with status update=20 * Xmlenc/xmldsig [PH] to create draft [Ming to add and Salah to review] =20 * PINPolicy [PH] mention that this is being used in field * Ming to create slide of outstanding issues * Draft of profile for minimum algorithm support [Ming] * Logo type [Ming] =20 ACTION: Ming to chat with Magnus, Andrea, Russ on the core issues we need to make a conclusion on. Hannes to send mail with names. =20 =20 ________________________________ =20 Philip Hoyer=20 =20 Senior Architect - Office of CTO =20 ActivIdentity (UK) 109 Borough High Street London SE1 1NL =20 Telephone: +44 (0) 20 7744 6248 Direct: +44 (0) 20 7744 6455 Fax: +44 (0) 20 7744 6249 =20 Private and confidential: This message and any attachments may contain privileged / confidential information. If you are not an intended recipient, you must not copy, distribute, discuss or take any action in reliance on it. If you have received this communication in error, please notify the sender and delete this message immediately. =20 ------_=_NextPart_001_01C831B9.C82167FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attendees:

Ming Pei, Hannes Tschofenig, Salah Macchani, Phillip Hallam-Baker, Philip Hoyer

 

Issues to discuss at IETF meeting = 3rd of December:

  • Xmlenc/xmldsig = usage
    • Salah = did couple of tests in terms of hierarchy in terms of supporting on mobile = phones (without signature) and it was ok. Salah in general ok with = proposal. [Salah to capture issues].
    • [Ming to = review proposal and add comments on slide]
    • Profiling the use of algorithms because of move to URIs =
    • PHB = small preference for not using xmlenc because of need of profiling. But = on the other hand if things need to be done later we could ride on that = instead of extending keyprov.
  • PINPolicy =
  • What = about keyTemplate (have attributes) [Ming] agrees on Usage PINPolicy, = helps mostly for bulk, but size is not that critical. Nice to have. Not necessary for single key. Not needed to present at = IETF.
  • URI for = algorithms especially specific ones. ACTION Philip Hallam Baker to send slide = content to Ming
  • Alignment = of attributes between PSKC and ASN.1 spec. ACTION Hannes to look at = the issue. Philip’s suggestion was to put the definition in a specific = section of PSKC spec referenced from ASN.1 = spec.
  • Logotype = how do we proceed

 

Slides [Ming to collate]:[PHB] no specific format.[Hannes to upload] first draft COB = Wednesday.

  • Highlight = with status update
  • Xmlenc/xmldsig [PH] to create draft [Ming to add and Salah to review]  =
  • PINPolicy = [PH] mention that this is being used in = field
  • Ming to = create slide of outstanding issues
  • Draft of = profile for minimum algorithm support [Ming]
  • Logo type = [Ming]

 

ACTION: Ming to chat with Magnus, Andrea, Russ = on the core issues we need to make a conclusion on. Hannes to send mail with = names.

 

 

________________________________

 

Philip Hoyer

 

Senior Architect - = Office of CTO

 

ActivIdentity = (UK)=

109 Borough High Street

London SE1 1NL

 

Telephone: +44 (0) = 20 7744 6248

Direct: +44 (0) 20 = 7744 6455

Fax: +44 (0) 20 = 7744 6249

 

Private and = confidential: This message and any attachments may = contain

privileged / = confidential information. If you are not an intended = recipient,

you must not copy, distribute, discuss or take any action in reliance on = it.

If you have = received this communication in error, please notify the = sender

and delete this = message immediately.

 

------_=_NextPart_001_01C831B9.C82167FE-- --===============2041701564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov --===============2041701564==-- From keyprov-bounces@ietf.org Wed Nov 28 15:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTgI-0004PO-9R; Wed, 28 Nov 2007 15:38:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTgH-0004Op-0Z for keyprov@ietf.org; Wed, 28 Nov 2007 15:38:49 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxTgG-0006L8-19 for keyprov@ietf.org; Wed, 28 Nov 2007 15:38:48 -0500 Received: (qmail invoked by alias); 28 Nov 2007 20:38:46 -0000 Received: from p54984A75.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.74.117] by mail.gmx.net (mp021) with SMTP; 28 Nov 2007 21:38:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gtFE5LaygrP3xQ+ZT7nTeEqg79cBMB/BvVUEbNA UaqH8ToXbNPEGw Message-ID: <474DD1D5.1000403@gmx.net> Date: Wed, 28 Nov 2007 21:38:45 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Subject: [KEYPROV] Review of draft-ietf-keyprov-portable-symmetric-key-container-02.txt X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Hi all, I read through draft-ietf-keyprov-portable-symmetric-key-container-02.txt. I have a couple of comments. * There are a couple of editorial issues but I will provide them to the authors offline. * Structure of the document I believe the structure and presentation of the document could be improved by re-arranging sections and paragraphs it a bit. Proposal for a modified ToC: o Introduction o Terminology o Use Cases o Requirements o Key Container [This is the part that is a bit tricky since you want to describe the data model in a way that the reader actually understands it. You would have to describe all attributes and elements in this section but the presentation style needs some discussion. ] o Introduction This section starts with the high-level overview of the structure of the key container. There is text to re-use already in Section 6 (and the corresponding figure as well.) This text would, for example, indicate * what is the semantic if there are multiple elements within the element * what is the semantic if there are multiple elements within the element The text about the element is already in Section 6.4.1. o Device Element Text from Section 5.1 goes in here. The , and elements are child elements of the element. o EncryptionMethod Element Text from Section 5.1.8 (and Section 6.1.7) goes in here. o DigestMethod Element Text from Section 5.1.9 (and Section 6.1.8) goes in here. o Signature Element o XML Schema o Security Considerations o IANA Considerations o References * Why is the element a child element of the element? Looking at the figure in Section 6 one would rather get the impression that the element is a child element of the element that happens to have a relationship to the element. * The element is a bit strange. It is the attempt to map a TLV or AVP into XML. Here is an example (code snippet): AAAAAAAAAAA= Depending on the setting of the 'Name' attribute the value is interpreted in a different fashion. This is a somewhat strange usage of XML. Why don't you just define a new type that may contain different elements? This would also make the assignment of the data types a lot easier and would also offer extensibility in a nice fashion. * Section 7 contains two XML schemas. I would put them in two separate sub-sections since you may need to reference them separately in the IANA consideration section. * The IANA consideration section for the namespace registration and the schema registration is missing. * There are internationalization considerations when some of the fields are supposed to be processed by humans. Is this the case? * The Logo schema is pretty complex but it is not really well described in the document. * Section 5 and section 6 have a lot of overlap. The style is also somewhat different. Section 6 describes XML schema snippets. This is not good practice and not so helpful given that Section 7 lists the full schema anyway. It might be more helpful to provide more examples, if necessary. Some elements/attributes that are listed in Section 6 are not listed in Section 5 although it would be very useful (example: 'expiry'). * There is no description of the examples. You don't need to put the examples in the appendix. It is fine to leave them in the main section since many readers are for sure going to look at the examples; if not only at the examples. * Section 5 has each element listed as (OPTIONAL) or (MANDATORY). This seems like a nice idea but was not done in a consistent fashion nor does it work well when you have dependencies to the occurrence of other elements/attributes/values. * XML element and XML attribute names are not used consistently in the same fashion. * With regard to the algorithm URIs there is no reference provided to Phillip's document. Don't you think that would be needed/useful? * What exactly is the element used for? * References: You need to split the references into normative and informative references. At least the following references are hopefully informative -- otherwise we run into problems: - [CAP] - [OATH] - [OATHRefArch] - [OCRA] - [Schneier] Please double-check the other references. The reference style is also a bit strange (see, for example, the [DSKPP] reference). Are you using XML2RFC to edit the document? Ciao Hannes _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 29 08:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjon-00079F-Bg; Thu, 29 Nov 2007 08:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjol-000791-QB for keyprov@ietf.org; Thu, 29 Nov 2007 08:52:39 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixjol-0004jH-1P for keyprov@ietf.org; Thu, 29 Nov 2007 08:52:39 -0500 Received: (qmail invoked by alias); 29 Nov 2007 13:52:37 -0000 Received: from p54986E15.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.110.21] by mail.gmx.net (mp021) with SMTP; 29 Nov 2007 14:52:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/RS6peCALRLyx5oX3wXexLwwEBWwKD3OlDFrUk01 ClKOWVbI8lXBaf Message-ID: <474EC424.2070008@gmx.net> Date: Thu, 29 Nov 2007 14:52:36 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [KEYPROV] [Fwd: I-D ACTION:draft-eastlake-additional-xmlsec-uris-00.txt] X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org I ran into this document. Since it also defines algorithm identifiers it is also of interest for the group. Ciao Hannes -------- Original Message -------- Subject: I-D ACTION:draft-eastlake-additional-xmlsec-uris-00.txt Date: Tue, 13 Nov 2007 11:15:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional XML Security Uniform Resource Identifiers (URIs) Author(s) : D. Eastlake 3rd Filename : draft-eastlake-additional-xmlsec-uris-00.txt Pages : 25 Date : 2007-11-13 This document expands and updates the list of URIs intended for use with XML Digital Signatures, Encryption, Canonnicalization, and Key Management specified in RFC 4051. These URIs identify algorithms and types of information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eastlake-additional-xmlsec-uris-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Thu Nov 29 12:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmri-0006dE-JO; Thu, 29 Nov 2007 12:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmrh-0006d4-UG for keyprov@ietf.org; Thu, 29 Nov 2007 12:07:53 -0500 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixmrg-0000XS-9x for keyprov@ietf.org; Thu, 29 Nov 2007 12:07:53 -0500 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id lATH2S9l016796; Thu, 29 Nov 2007 09:02:28 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 17:06:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] [Fwd: I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] Date: Thu, 29 Nov 2007 09:06:38 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C95FFEFE@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <474EC424.2070008@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [Fwd: I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] Thread-Index: Acgyjvgu+4lNL1nPRBSKsQzc1obfkgAGrjdw From: "Pei, Mingliang" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 29 Nov 2007 17:06:41.0448 (UTC) FILETIME=[36280280:01C832AA] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org PSKC currently cites some URIs from this document, for example, for the later version of HMAC 256 that are not present in xmlenc and xmldsig document at the time. While we are creating a new URI document, should it become some kind of extension of this doc or an inclusion of this doc? Extension doc would list only ones that are not listed in this doc, xmlenc, and xmldsig spec. Currently, it looks to be an "inclusion" where we list URIs, which refer back to this document.=20 - Ming > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, November 29, 2007 5:53 AM > To: keyprov@ietf.org > Subject: [KEYPROV] [Fwd:=20 > I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] >=20 > I ran into this document. > Since it also defines algorithm identifiers it is also of=20 > interest for the group. >=20 > Ciao > Hannes >=20 > -------- Original Message -------- > Subject: I-D ACTION:draft-eastlake-additional-xmlsec-uris-00.txt > Date: Tue, 13 Nov 2007 11:15:01 -0500 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Additional XML Security Uniform=20 > Resource Identifiers (URIs) > Author(s) : D. Eastlake 3rd > Filename : draft-eastlake-additional-xmlsec-uris-00.txt > Pages : 25 > Date : 2007-11-13 > =09 > This document expands and updates the list of URIs intended for use > with XML Digital Signatures, Encryption, Canonnicalization, and Key > Management specified in RFC 4051. These URIs identify=20 > algorithms and > types of information. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-eastlake-additional- > xmlsec-uris-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-eastlake-additional-xmlsec-uris-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 30 06:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4Dn-0005ez-8Q; Fri, 30 Nov 2007 06:39:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4Dm-0005dC-Pj for keyprov@ietf.org; Fri, 30 Nov 2007 06:39:50 -0500 Received: from mail2.ics.ntts.co.jp ([202.32.24.42]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy4Dl-00029W-RE for keyprov@ietf.org; Fri, 30 Nov 2007 06:39:50 -0500 Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id lAUBdltd002944; Fri, 30 Nov 2007 20:39:47 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id lAUBdlOv012147; Fri, 30 Nov 2007 20:39:47 +0900 (JST) Received: from mail26.silk.ntts.co.jp [10.7.18.26] by sadoku34.silk.ntts.co.jp with SMTP id WAA12146; Fri, 30 Nov 2007 20:39:47 +0900 Received: from mail26.silk.ntts.co.jp (localhost [127.0.0.1]) by mail26.silk.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id lAUBdlMt019342; Fri, 30 Nov 2007 20:39:47 +0900 (JST) Received: from [127.0.0.1] (lepus.ms.ntts.co.jp [10.7.221.39]) by mail26.silk.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id lAUBdhj3019256; Fri, 30 Nov 2007 20:39:46 +0900 (JST) Message-ID: <474FF67A.1010007@po.ntts.co.jp> Date: Fri, 30 Nov 2007 20:39:38 +0900 From: KATO Akihiro User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: keyprov@ietf.org Subject: RE: [KEYPROV] [Fwd: I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org > > PSKC currently cites some URIs from this document, for example, for the > > later version of HMAC 256 that are not present in xmlenc and xmldsig > > document at the time. > > > > While we are creating a new URI document, should it become some kind of > > extension of this doc or an inclusion of this doc? Extension doc would > > list only ones that are not listed in this doc, xmlenc, and xmldsig > > spec. Currently, it looks to be an "inclusion" where we list URIs, which > > refer back to this document. draft-eastlake-additional-xmlsec-uris includes strong cryptographic primitives. When I consider recent and few years future cryptographic attack, I support PSKC document include this draft for hmac-sha256 or later, and AES backup block cipher Camellia. I suggest PSKC include following uris and reference: Section 5.1.2. http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc Section 5.1.9. For default support list: http://www.w3.org/2000/09/xmldsig#hmac-sha1 http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 Section 11: Reference of draft-eastlake-additional-xmlsec-uris-00.txt, Thanks. > > - Ming > > >> >> -----Original Message----- >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net] >> >> Sent: Thursday, November 29, 2007 5:53 AM >> >> To: keyprov at ietf.org >> >> Subject: [KEYPROV] [Fwd: >> >> I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] >> >> >> >> I ran into this document. >> >> Since it also defines algorithm identifiers it is also of >> >> interest for the group. >> >> >> >> Ciao >> >> Hannes >> >> >> >> -------- Original Message -------- >> >> Subject: I-D ACTION:draft-eastlake-additional-xmlsec-uris-00.txt >> >> Date: Tue, 13 Nov 2007 11:15:01 -0500 >> >> From: Internet-Drafts at ietf.org >> >> Reply-To: internet-drafts at ietf.org >> >> To: i-d-announce at ietf.org >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line >> >> Internet-Drafts directories. >> >> >> >> >> >> Title : Additional XML Security Uniform >> >> Resource Identifiers (URIs) >> >> Author(s) : D. Eastlake 3rd >> >> Filename : draft-eastlake-additional-xmlsec-uris-00.txt >> >> Pages : 25 >> >> Date : 2007-11-13 >> >> >> >> This document expands and updates the list of URIs intended for use >> >> with XML Digital Signatures, Encryption, Canonnicalization, and Key >> >> Management specified in RFC 4051. These URIs identify >> >> algorithms and >> >> types of information. >> >> >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-eastlake-additional- >> >> xmlsec-uris-00.txt >> >> >> >> To remove yourself from the I-D Announcement list, send a message to >> >> i-d-announce-request at ietf.org with the word unsubscribe in >> >> the body of >> >> the message. >> >> You can also visit >> >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> >> to change your subscription settings. >> >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> >> username "anonymous" and a password of your e-mail address. After >> >> logging in, type "cd internet-drafts" and then >> >> "get draft-eastlake-additional-xmlsec-uris-00.txt". >> >> >> >> A list of Internet-Drafts directories can be found in >> >> http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> >> >> Send a message to: >> >> mailserv at ietf.org. >> >> In the body type: >> >> "FILE >> >> /internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt". >> >> >> >> NOTE: The mail server at ietf.org can return the document in >> >> MIME-encoded form by using the "mpack" utility. To use this >> >> feature, insert the command "ENCODING mime" before the "FILE" >> >> command. To decode the response(s), you will need "munpack" or >> >> a MIME-compliant mail reader. Different MIME-compliant >> >> mail readers >> >> exhibit different behavior, especially when dealing with >> >> "multipart" MIME messages (i.e. documents which have been split >> >> up into multiple messages), so check your local documentation on >> >> how to manipulate these messages. >> >> >> >> Below is the data which will enable a MIME compliant mail reader >> >> implementation to automatically retrieve the ASCII version of the >> >> Internet-Draft. >> >> >> >> -- - KATO Akihiro + NTT Software Corporation _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov From keyprov-bounces@ietf.org Fri Nov 30 13:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAhM-0003Wd-IW; Fri, 30 Nov 2007 13:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAhL-0003WL-B1 for keyprov@ietf.org; Fri, 30 Nov 2007 13:34:47 -0500 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyAhJ-0002bj-9L for keyprov@ietf.org; Fri, 30 Nov 2007 13:34:47 -0500 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id lAUITnGH001939; Fri, 30 Nov 2007 10:29:49 -0800 Received: from MOU1WNEXMB10.vcorp.ad.vrsn.com ([10.25.13.204]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Nov 2007 10:33:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [KEYPROV] [Fwd:I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] Date: Fri, 30 Nov 2007 10:33:34 -0800 Message-ID: <3E5A2F1AD44F5E49A74F79AB47C0C0C9600022@mou1wnexmb10.vcorp.ad.vrsn.com> In-Reply-To: <474FF67A.1010007@po.ntts.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [KEYPROV] [Fwd:I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] Thread-Index: AcgzRZQJFTcadsZRRXSuBCuO65j9GAAOXofg From: "Pei, Mingliang" To: "KATO Akihiro" , X-OriginalArrivalTime: 30 Nov 2007 18:33:34.0676 (UTC) FILETIME=[83E53940:01C8337F] X-Spam-Score: -4.0 (----) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: keyprov@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Provisioning of Symmetric Keys \(keyprov\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: keyprov-bounces@ietf.org Kato, Thank you very much for the suggestions. For section 11, yes, we will add the reference in next rev. For the additional algorithms to section=20 5.1.2 and 5.1.9, we like to hear more feedbacks in this thread and IETF meeting next week. The list impacts interop scope. - Ming > -----Original Message----- > From: KATO Akihiro [mailto:akato@po.ntts.co.jp]=20 > Sent: Friday, November 30, 2007 3:40 AM > To: keyprov@ietf.org > Subject: RE: [KEYPROV]=20 > [Fwd:I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] >=20 > > > PSKC currently cites some URIs from this document, for=20 > example, for=20 > > > the later version of HMAC 256 that are not present in xmlenc and=20 > > > xmldsig document at the time. > > > > > > While we are creating a new URI document, should it=20 > become some kind=20 > > > of extension of this doc or an inclusion of this doc?=20 > Extension doc=20 > > > would list only ones that are not listed in this doc, xmlenc, and=20 > > > xmldsig spec. Currently, it looks to be an "inclusion"=20 > where we list=20 > > > URIs, which refer back to this document. >=20 > draft-eastlake-additional-xmlsec-uris includes strong=20 > cryptographic primitives. When I consider recent and few=20 > years future cryptographic attack, I support PSKC document=20 > include this draft for hmac-sha256 or later, and AES backup=20 > block cipher Camellia. >=20 > I suggest PSKC include following uris and reference: >=20 > Section 5.1.2. > http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc > http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc > http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc >=20 > Section 5.1.9. > For default support list: > http://www.w3.org/2000/09/xmldsig#hmac-sha1 > http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 > http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 > http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 >=20 > Section 11: > Reference of draft-eastlake-additional-xmlsec-uris-00.txt, >=20 > Thanks. >=20 > > > - Ming > > > > >> >> -----Original Message----- > >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net] > >> >> Sent: Thursday, November 29, 2007 5:53 AM > >> >> To: keyprov at ietf.org > >> >> Subject: [KEYPROV] [Fwd: > >> >> I-DACTION:draft-eastlake-additional-xmlsec-uris-00.txt] > >> >> > >> >> I ran into this document. > >> >> Since it also defines algorithm identifiers it is also=20 > of interest=20 > >> >> for the group. > >> >> > >> >> Ciao > >> >> Hannes > >> >> > >> >> -------- Original Message -------- > >> >> Subject: I-D=20 > ACTION:draft-eastlake-additional-xmlsec-uris-00.txt > >> >> Date: Tue, 13 Nov 2007 11:15:01 -0500 > >> >> From: Internet-Drafts at ietf.org > >> >> Reply-To: internet-drafts at ietf.org > >> >> To: i-d-announce at ietf.org > >> >> > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > >> >> directories. > >> >> > >> >> > >> >> Title : Additional XML Security Uniform > >> >> Resource Identifiers (URIs) > >> >> Author(s) : D. Eastlake 3rd > >> >> Filename :=20 > draft-eastlake-additional-xmlsec-uris-00.txt > >> >> Pages : 25 > >> >> Date : 2007-11-13 > >> >> =09 > >> >> This document expands and updates the list of URIs=20 > intended for use > >> >> with XML Digital Signatures, Encryption,=20 > Canonnicalization, and Key > >> >> Management specified in RFC 4051. These URIs identify=20 > >> >> algorithms and > >> >> types of information. > >> >> > >> >> > >> >> > >> >> A URL for this Internet-Draft is: > >> >> http://www.ietf.org/internet-drafts/draft-eastlake-additional- > >> >> xmlsec-uris-00.txt > >> >> > >> >> To remove yourself from the I-D Announcement list, send=20 > a message=20 > >> >> to i-d-announce-request at ietf.org with the word=20 > unsubscribe in=20 > >> >> the body of the message. > >> >> You can also visit > >> >> https://www1.ietf.org/mailman/listinfo/I-D-announce > >> >> to change your subscription settings. > >> >> > >> >> Internet-Drafts are also available by anonymous FTP. Login with=20 > >> >> the username "anonymous" and a password of your e-mail address.=20 > >> >> After logging in, type "cd internet-drafts" and then "get=20 > >> >> draft-eastlake-additional-xmlsec-uris-00.txt". > >> >> > >> >> A list of Internet-Drafts directories can be found in=20 > >> >> http://www.ietf.org/shadow.html or=20 > >> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> >> > >> >> Internet-Drafts can also be obtained by e-mail. > >> >> > >> >> Send a message to: > >> >> mailserv at ietf.org. > >> >> In the body type: > >> >> "FILE > >> >> /internet-drafts/draft-eastlake-additional-xmlsec-uris-00.txt". > >> >> =09 > >> >> NOTE: The mail server at ietf.org can return the document in > >> >> MIME-encoded form by using the "mpack" utility.=20 > To use this > >> >> feature, insert the command "ENCODING mime"=20 > before the "FILE" > >> >> command. To decode the response(s), you will=20 > need "munpack" or > >> >> a MIME-compliant mail reader. Different=20 > MIME-compliant mail=20 > >> >> readers > >> >> exhibit different behavior, especially when dealing with > >> >> "multipart" MIME messages (i.e. documents which=20 > have been split > >> >> up into multiple messages), so check your local=20 > documentation on > >> >> how to manipulate these messages. > >> >> > >> >> Below is the data which will enable a MIME compliant=20 > mail reader=20 > >> >> implementation to automatically retrieve the ASCII=20 > version of the=20 > >> >> Internet-Draft. > >> >> > >> >> >=20 >=20 > -- > - KATO Akihiro > + NTT Software Corporation >=20 >=20 > _______________________________________________ > KEYPROV mailing list > KEYPROV@ietf.org > https://www1.ietf.org/mailman/listinfo/keyprov >=20 _______________________________________________ KEYPROV mailing list KEYPROV@ietf.org https://www1.ietf.org/mailman/listinfo/keyprov