From nobody Thu Jan 1 03:51:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107551A1B4B for ; Thu, 1 Jan 2015 03:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxHNXkT622s4 for ; Thu, 1 Jan 2015 03:51:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8371A1B3D for ; Thu, 1 Jan 2015 03:51:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 95AC2BF0F for ; Thu, 1 Jan 2015 11:51:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 097QXFExMoB6 for ; Thu, 1 Jan 2015 11:51:29 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.21.122]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0034EBF03 for ; Thu, 1 Jan 2015 11:51:28 +0000 (GMT) Message-ID: <54A534C0.5020008@cs.tcd.ie> Date: Thu, 01 Jan 2015 11:51:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20150101024148.8907718047D@rfc-editor.org> In-Reply-To: <20150101024148.8907718047D@rfc-editor.org> X-Forwarded-Message-Id: <20150101024148.8907718047D@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gstrBDFFwf98jqcXLsxwD6e0fVI Subject: [saag] Fwd: RFC 7435 on Opportunistic Security: Some Protection Most of the Time X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 11:51:35 -0000 FYI and thanks all for all your efforts discussing this. Now we need to figure out how to do it well enough in new protocols so it's a real improvement over what we'd normally have done, but I'm pretty confident we'll manage. Cheers, S. -------- Forwarded Message -------- Subject: RFC 7435 on Opportunistic Security: Some Protection Most of the Time Date: Wed, 31 Dec 2014 18:41:48 -0800 (PST) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7435 Title: Opportunistic Security: Some Protection Most of the Time Author: V. Dukhovni Status: Informational Stream: IETF Date: December 2014 Mailbox: ietf-dane@dukhovni.org Pages: 11 Characters: 27451 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-dukhovni-opportunistic-security-06.txt URL: https://www.rfc-editor.org/rfc/rfc7435.txt This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jan 1 04:03:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2EA1A1B5B; Thu, 1 Jan 2015 04:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZGywsWyDyyH; Thu, 1 Jan 2015 04:03:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A981A1B49; Thu, 1 Jan 2015 04:03:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 921A6BF15; Thu, 1 Jan 2015 12:02:58 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGzwhmwrmoEj; Thu, 1 Jan 2015 12:02:55 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.21.122]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BCE7FBF11; Thu, 1 Jan 2015 12:02:55 +0000 (GMT) Message-ID: <54A53770.9090900@cs.tcd.ie> Date: Thu, 01 Jan 2015 12:02:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jan Pechanec , ietf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/W6F-HT9WbqMdB1gYePAi5Eq4AAo Cc: Darren.Moffat@oracle.com, Stef Walter , Nikos Mavrogiannopoulos , saag@ietf.org Subject: Re: [saag] Last Call: (The PKCS#11 URI Scheme) to Proposed Standard: new draft 17 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 12:03:03 -0000 And so's you know, I'll work with the authors and commenters to ensure we close out the LC comments (IETF LC has now ended, formally) before taking this further. I expect that'll take a week or two at least. I'll drop a note to ietf@ietf.org when I put a version on an IESG telechat just in case we've missed someone's comment in the final processing. Thanks all for all the good comments and Jan for engaging on those, Cheers, S. On 31/12/14 19:45, Jan Pechanec wrote: > > hi, I've addressed comments received so far during the last > call and given that there are several different changes I've filed a > new draft 17. There is still an ongoing discussion on i18n > requirements and I expect that there will be a new draft following on. > > > draft-pechanec-pkcs11uri-17.txt contains the following > changes: > > - slot attributes added to identify a PKCS#11 slot > > - some minor editorial changes as suggested by Derek Atkins > > - IANA registration template added to the draft itself as > suggested by Martin Duerst. > > - normative language used as per RFC2119 as suggested by Sarah > Banks > > - IRIs (RFC3987) are referenced per Nico Williams's suggestion > > - a syntax error found by Shawn Emery fixed in the ABNF grammar > > - ABNF was simplified as suggested by the ABNF check tool > http://tools.ietf.org/tools/bap/abnf.cgi (I replaced "*1(xx)" with "[ > xx ]") > > - text notes that use of "x-*" attributes is obsolete and > should be avoided as per BCP178. Based on a comment by Bjoern > Hoehrmann. > > - a new section on generating PKCS#11 URIs added based on > initial comment by Henry B. Hotz. > > > direct link to the diff from the previous version: > > http://www.ietf.org/rfcdiff?url1=draft-pechanec-pkcs11uri-16&url2=draft-pechanec-pkcs11uri-17 > > > best regards, Jan. > > -- > Jan Pechanec > From nobody Thu Jan 1 08:09:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB061A899F; Tue, 30 Dec 2014 15:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bFVyQiF6znr; Tue, 30 Dec 2014 15:07:27 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7D21A899C; Tue, 30 Dec 2014 15:07:27 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBUN7J9d002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 23:07:20 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBUN7IoM026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2014 23:07:19 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sBUN7HEh017519; Tue, 30 Dec 2014 23:07:18 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Dec 2014 15:07:17 -0800 Date: Tue, 30 Dec 2014 15:07:15 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20141230081415.GH24442@localhost> Message-ID: References: <20141218004717.GN9443@localhost> <20141218012300.GP9443@localhost> <1418900792.7577.5.camel@gnutls.org> <5492B941.3030408@Oracle.COM> <30738721-F5A2-4485-84AC-573AD9113699@oxy.edu> <20141220000456.GC12662@localhost> <20141230081415.GH24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HRyfBWvYOsl_k651PQEux8mTWBA X-Mailman-Approved-At: Thu, 01 Jan 2015 08:09:18 -0800 Cc: Darren J Moffat , Stef Walter , ietf@ietf.org, saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] PKCS#11 URI slot attributes & last call X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 23:07:29 -0000 On Tue, 30 Dec 2014, Nico Williams wrote: >> >> [discussion about an abstract "list PKCS#11 resource URIs" >> >> operation elided.] >> >> I've been thinking about this for the past days and I'm not >> sure if such guidelines should be provided since it very much depends >> on how a URI will be used and in what scenarios. >> >> for example, if referencing a key pair, an "id" attribute is >> there to distinguish multiple public-key/private-key pairs held by the >> same subject. However, I think that if used on a command line to >> provide an access to the key pair, it would be used only if there >> really were multiple keys of the same name. And that information I >> may acquire only when I try not to use those attributes when I get an >> error message about multiple key pairs - which may or may not be >> acceptible. On the other hand, it may be a good idea to use it always >> if such a URI would be provided in a long lived configuration file, >> for example. > >Which attributes to use for the listing would have to be >context-specific. Most apps/users would never want to match on slot >attributes, but some might. We can't say much about that. yes, and I think it will be important to state in the text that the choice of exact set of attributes is context specific. >Users will mostly not be writing PKCS#11 URIs, that's for sure. PKCS#11 >is not very user-friendly... > >Where a PKCS#11 URI is used, I suspect it will be produced by an >application, and then cut-n-pasted around as necessary by the user. > >Do we have to say much about how the app should go about forming a URI >for a PKCS#11 resource? It depends. > >If the same app will consume the same URI, then we need not say >anything. If a different app will consume the same URI then we might >have to. This is about inter-app interoperation. I'd say it does not matter much whether it's the same application which is gonna use the generated URI or not, it's all about the context - if it's enough or not. >As to how to say anything about this, here's what comes to mind: > > Given a PKCS#11 URI template [RFC6570], an application MAY support > listing URIs of PKCS#11 resources such that the resulting URIs can > later be used to access the same resources if the template captured > the necessary context. I like the use of the templates. I just quickly read through the RFC. It looks that, for example, when generating a key pair, the application could support a default template with empty variables which would be used to optionally list a URI based on the CK_OBJECT_HANDLE of the generated key pair. And it could accept a different one to override the default. As mentioned above, I'd like to explicitly express that URI list is context specific. I slightly modified the paragraph above: When listing URIs of PKCS#11 resources the exact set of attributes used in a URI is inherently context specific. A PKCS#11 URI template [RFC6570] support MAY be provided by a URI generating application to list URIs to access the same resource(s) again if the template captured the necessary context. I think we wouldn't need to say more about the matter. thank you, J. >I don't think we could say much more without gaining experience with >deployment. > >Caveat emptor: I'm not too conversant with URI templating, so I don't >know how to phrase this correctly... > >Nico > -- Jan Pechanec From nobody Thu Jan 1 19:01:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F321A870A; Thu, 1 Jan 2015 19:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtO7fqGJTx2h; Thu, 1 Jan 2015 19:01:37 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 033B81A8709; Thu, 1 Jan 2015 19:01:37 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id A04D11634; Thu, 1 Jan 2015 19:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3Wckt4BGJPK8CH SbMTlK930Xeng=; b=IPs2I7DG9nYFr2i1vbfL9Ndh9t9hTkgiXHP3zHk8yT3H7U RWMs8M5wqbpH8dE4I1fHfZrunFGNTFrWIIXGrqMu/MdBU0e561SoqibP+weaMa9T M9mq8+Qxlq2MH2s6Dpn63S5ivstexMFK4gnIAQuEXpSCnzlvFonZoAu40lDw8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 1852F161A; Thu, 1 Jan 2015 19:01:36 -0800 (PST) Date: Thu, 1 Jan 2015 21:01:35 -0600 From: Nico Williams To: John C Klensin Message-ID: <20150102030130.GN24442@localhost> References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VdJyWWL-yG_a7yr2sno42yyhD_Q Cc: Darren J Moffat , ietf@ietf.org, saag@ietf.org, Jan Pechanec , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 03:01:38 -0000 On Wed, Dec 31, 2014 at 10:41:28AM -0500, John C Klensin wrote: > [...] In the case of PKCS#11 there's not a lot in the way of security considerations regarding normalization: all the "devices" in question are trusted, and the user is supposed to be in physical possession of them. As usual, we assume local security. Therefore there's no question of an attacker trying to fool a user into entering their PINs into fake tokens. This makes the security considerations regarding normalization simpler in this case. I think we could use some text like this: PKCS#11 does not specify a canonical from for UTF-8 string slots in the API. This presents the usual false negative and false positive (aliasing) concerns that arise when dealing with unnormalized strings. Because all PKCS#11 items are local and local security is assumed, these concerns are mainly about usability. In order to improve the user experience, applications that create PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to NFC. For the same reason PKCS#11 libraries, slots (token readers), and tokens SHOULD normalize their names to NFC. When listing libraries, slots, tokens, or objects, an application SHOULD normalize their names to NFC. When matching PKCS#11 URIs to libraries, slots, tokens, and/or objects, applications may use form-insensitive Unicode string comparison for matching, as the objects might pre-date these recommendations). Then later in the security considerations section, add something like: PKCS#11 does not authenticate devices to users; PKCS#11 only authenticates users to tokens. Instead, local and physical security are demanded: the user must be in possession of their tokens, and system into whose slots the users' tokens are inserted must be secure. As a result, the usual security considerations regarding normalization do not arise. For the same reason, confusable script issues also do not arise. Nonetheless, it is best to normalize to NFC all strings appearing in PKCS#11 API elements. Nico -- From nobody Thu Jan 1 22:57:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8E51A003B; Thu, 1 Jan 2015 22:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4qy-KSJxOLG; Thu, 1 Jan 2015 22:57:20 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B98B1A0022; Thu, 1 Jan 2015 22:57:20 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::5d37:599c:4e1c:4919] (unknown [IPv6:2a02:80:3ffc:0:5d37:599c:4e1c:4919]) by mail.frobbit.se (Postfix) with ESMTPSA id C17DA21DDA; Fri, 2 Jan 2015 07:57:18 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7BE47B0F-BBA2-48B5-ADDC-FDA9FAD8A271"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20150102030130.GN24442@localhost> Date: Fri, 2 Jan 2015 07:57:18 +0100 Message-Id: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tU2zLod9aOzzKhtsxUAkmTdGqwk Cc: John Klensin , Darren J Moffat , saag@ietf.org, Jan Pechanec , ietf@ietf.org Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 06:57:23 -0000 --Apple-Mail=_7BE47B0F-BBA2-48B5-ADDC-FDA9FAD8A271 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 2 jan 2015, at 04:01, Nico Williams wrote: > > On Wed, Dec 31, 2014 at 10:41:28AM -0500, John C Klensin wrote: >> [...] > > In the case of PKCS#11 there's not a lot in the way of security > considerations regarding normalization: all the "devices" in question > are trusted, and the user is supposed to be in physical possession of > them. As usual, we assume local security. Therefore there's no > question of an attacker trying to fool a user into entering their PINs > into fake tokens. > > This makes the security considerations regarding normalization simpler > in this case. For the record, I like what is suggested the below. Patrik > I think we could use some text like this: > > PKCS#11 does not specify a canonical from for UTF-8 string slots in > the API. This presents the usual false negative and false positive > (aliasing) concerns that arise when dealing with unnormalized > strings. Because all PKCS#11 items are local and local security is > assumed, these concerns are mainly about usability. > > In order to improve the user experience, applications that create > PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to > NFC. For the same reason PKCS#11 libraries, slots (token readers), > and tokens SHOULD normalize their names to NFC. When listing > libraries, slots, tokens, or objects, an application SHOULD normalize > their names to NFC. When matching PKCS#11 URIs to libraries, slots, > tokens, and/or objects, applications may use form-insensitive Unicode > string comparison for matching, as the objects might pre-date these > recommendations). > > Then later in the security considerations section, add something like: > > PKCS#11 does not authenticate devices to users; PKCS#11 only > authenticates users to tokens. Instead, local and physical security > are demanded: the user must be in possession of their tokens, and > system into whose slots the users' tokens are inserted must be > secure. As a result, the usual security considerations regarding > normalization do not arise. For the same reason, confusable script > issues also do not arise. Nonetheless, it is best to normalize to > NFC all strings appearing in PKCS#11 API elements. > > Nico > -- --Apple-Mail=_7BE47B0F-BBA2-48B5-ADDC-FDA9FAD8A271 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUpkFOrMabGguI180RAiCDAJ0T6odqlw+Rf3RHf+Lfv6GpUy/lPACfVLOk qiSjbk/6FOZ6zhg9Fps3OoU= =rkuX -----END PGP SIGNATURE----- --Apple-Mail=_7BE47B0F-BBA2-48B5-ADDC-FDA9FAD8A271-- From nobody Fri Jan 2 06:30:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E621A8750; Fri, 2 Jan 2015 06:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCw0JK_8kQQL; Fri, 2 Jan 2015 06:30:32 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071E31A874F; Fri, 2 Jan 2015 06:30:32 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=P5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y73FD-0001E3-L2; Fri, 02 Jan 2015 09:30:27 -0500 Date: Fri, 02 Jan 2015 09:30:22 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Nico Williams Message-ID: <881FA95C72F0C69B513D143E@P5> In-Reply-To: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Hw9lCwJn_w5bCC7DcVSUBlfrWSI Cc: Darren J Moffat , saag@ietf.org, Jan Pechanec , ietf@ietf.org Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 14:30:38 -0000 --On Friday, 02 January, 2015 07:57 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: > For the record, I like what is suggested the below. Wfm, but please note the other comments in my prior note. To summarize, normalization is not the only issue. Even for some normalization cases, NFC is not the cure. For example, NFKC is needed to rationalize characters of various widths but causes problems elsewhere. So, I would suggest some additional words that say, more or less, that, until PKCS#11 is revised to be clear about how to handle characters outside the ASCII repertoire, those who discover a need to use such characters should be cautious, conservative, and expend extra effort to be sure they know what they are doing and that failure to do so will create both operational and security risks. >=20 >> I think we could use some text like this: >>=20 >> PKCS#11 does not specify a canonical from for UTF-8 string >> slots in the API. This presents the usual false negative >> and false positive (aliasing) concerns that arise when >> dealing with unnormalized strings. Because all PKCS#11 >... From nobody Fri Jan 2 07:19:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF71A879F; Fri, 2 Jan 2015 07:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scLsZvLi_XgM; Fri, 2 Jan 2015 07:19:34 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996AD1A8794; Fri, 2 Jan 2015 07:19:34 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::41e3:a051:8600:13d2] (unknown [IPv6:2a02:80:3ffc:0:41e3:a051:8600:13d2]) by mail.frobbit.se (Postfix) with ESMTPSA id ABEEB21DAD; Fri, 2 Jan 2015 16:19:32 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CB9DAAA5-C0ED-4B04-9ABF-8875EC49A8CE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <881FA95C72F0C69B513D143E@P5> Date: Fri, 2 Jan 2015 16:19:32 +0100 Message-Id: <681FC255-E7F5-4327-9B5D-6B7FEB0FE489@frobbit.se> References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> <881FA95C72F0C69B513D143E@P5> To: John Klensin X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_eP36Flgx9j7ALajsq-t35QQfLk Cc: Darren J Moffat , saag@ietf.org, Jan Pechanec , ietf@ietf.org Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 15:19:36 -0000 --Apple-Mail=_CB9DAAA5-C0ED-4B04-9ABF-8875EC49A8CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 jan 2015, at 15:30, John C Klensin wrote: >=20 >=20 >=20 > --On Friday, 02 January, 2015 07:57 +0100 Patrik F=C3=A4ltstr=C3=B6m > wrote: >=20 >> For the record, I like what is suggested the below. >=20 > Wfm, but please note the other comments in my prior note. To > summarize, normalization is not the only issue. Even for some > normalization cases, NFC is not the cure. This is why I think the way NFC is mentioned is correct. > For example, NFKC is > needed to rationalize characters of various widths but causes > problems elsewhere. So, I would suggest some additional words > that say, more or less, that, until PKCS#11 is revised to be > clear about how to handle characters outside the ASCII > repertoire, those who discover a need to use such characters > should be cautious, conservative, and expend extra effort to be > sure they know what they are doing and that failure to do so > will create both operational and security risks. Having this clarification explicit and not only implicit would make the = text even better. Patrik --Apple-Mail=_CB9DAAA5-C0ED-4B04-9ABF-8875EC49A8CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUprcErMabGguI180RAspLAKCZa2I8TgqFIrPOuMLgfj1tUUfsrgCfZy2z SfOangrPTQKP5uW8PkcI/v8= =kzwh -----END PGP SIGNATURE----- --Apple-Mail=_CB9DAAA5-C0ED-4B04-9ABF-8875EC49A8CE-- From nobody Fri Jan 2 09:06:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69931A1B87; Fri, 2 Jan 2015 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voOWqVs0SvsC; Fri, 2 Jan 2015 09:05:59 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B11001A1B84; Fri, 2 Jan 2015 09:05:59 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 51C3D674058; Fri, 2 Jan 2015 09:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=h/KzyacF2bPlSHbWLvUSBebE8Us=; b=O3JLqmmkokb oFLWQamZSmrmvF63UTvOFWv1vvoyMcCgbK1FmAmil46YO0wNQ93JvZED9TJgKk21 rnvXYhG/lhP9s1j2BVxeS5fXUqdcbC66EVhaOA1V9xoH8CG4hv6yWDoVfujigd5d lJrzQVCE4kpM+A+Rb1V68aqVO7SJh6P4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id C6813674057; Fri, 2 Jan 2015 09:05:58 -0800 (PST) Date: Fri, 2 Jan 2015 11:05:58 -0600 From: Nico Williams To: John C Klensin Message-ID: <20150102170553.GW24442@localhost> References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> <881FA95C72F0C69B513D143E@P5> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <881FA95C72F0C69B513D143E@P5> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6QEHdr4z9HwtcAVgrt_Ge5Ong64 Cc: Darren J Moffat , ietf@ietf.org, saag@ietf.org, Jan Pechanec , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 17:06:00 -0000 On Fri, Jan 02, 2015 at 09:30:22AM -0500, John C Klensin wrote: > --On Friday, 02 January, 2015 07:57 +0100 Patrik F=E4ltstr=F6m > wrote: >=20 > > For the record, I like what is suggested the below. >=20 > Wfm, but please note the other comments in my prior note. To > summarize, normalization is not the only issue. Even for some > normalization cases, NFC is not the cure. For example, NFKC is Indeed, which is why the proposed text also mentions confusable scripts. (I didn't include references, but they could be added, all as informative given the special circumstances here). > needed to rationalize characters of various widths but causes > problems elsewhere. So, I would suggest some additional words > that say, more or less, that, until PKCS#11 is revised to be > clear about how to handle characters outside the ASCII > repertoire, those who discover a need to use such characters > should be cautious, conservative, and expend extra effort to be > sure they know what they are doing and that failure to do so > will create both operational and security risks. I'm not opposed. I just don't think this will really add value. Thanks for your and Patrick's help BTW (my apologies if my earlier reply to you seemed caustic; I tend to get annoyed when told that the IETF "doesn't do APIs" :/). Happy new year, Nico --=20 From nobody Sat Jan 3 12:13:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542C51A0108 for ; Sat, 3 Jan 2015 12:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itDgcLCzlELj for ; Sat, 3 Jan 2015 12:13:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC8C1A007F for ; Sat, 3 Jan 2015 12:13:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2A853BE73 for ; Sat, 3 Jan 2015 20:13:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jupWEwUNww9m for ; Sat, 3 Jan 2015 20:13:22 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.26.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 990B1BF2C for ; Sat, 3 Jan 2015 20:13:14 +0000 (GMT) Message-ID: <54A84D58.3000502@cs.tcd.ie> Date: Sat, 03 Jan 2015 20:13:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <5494DDCD.6030504@cs.tcd.ie> In-Reply-To: <5494DDCD.6030504@cs.tcd.ie> Content-Type: multipart/mixed; boundary="------------060304080004060001050906" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/b7WhnywLclI1xqY7p0kKuJfveaI Subject: Re: [saag] Important open-source activities... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 20:13:44 -0000 This is a multi-part message in MIME format. --------------060304080004060001050906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Folks, I'll try summarise this thread in a week or so, so please continue to chime in in the meantime. (And to make my life easier when summarising, I've attached a mail from another list that I think is relevant too.) Cheers, S. On 20/12/14 02:24, Stephen Farrell wrote: > > Hiya, > > The IESG have recently been discussing how the IETF would > work better with or for open-source communities. As part of > that it'd be good to get some appreciation of which open > source activities folks consider important (and why). And > of course there are multiple directions here - e.g. where an > IETF activity has fed directly into an open-source activity > and the opposite where the IETF end up documenting something > already done by some open-source community. > > As part of that analysis, an utterly reasonable question > was asked: yeah, but which open-source things are important > to IETF participants? > > So, which bits of open-source do we in the security area > of the IETF consider important and why? And what could > we do better? (For any sensible definition of "we":-) > > BTW, those are deliberately open questions - answer in any > way you like, (but pithily please:-) to the list or to > Kathleen and I off-list if need be. (If we see a bunch of > offlist answers, we'll summarise those back to the list.) > > And since this is really information-gathering, there's > no need for us to disagree with one another on the list > (but I expect we won't resist that specific temptation, as > usual:-) > > Thanks, > S. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --------------060304080004060001050906 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Message-ID: <54A84C77.3000002@cs.tcd.ie> Date: Sat, 03 Jan 2015 20:09:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ianG , cryptography@metzdowd.com, "Salz, Rich" Subject: Re: [Cryptography] New Encryption Standard of the Russian Federation GOST Grasshopper References: <54A6E5F2.9090506@iang.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D55237427@USMBX1.msg.corp.akamai.com> <54A81B9E.90900@iang.org> In-Reply-To: <54A81B9E.90900@iang.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/01/15 16:41, ianG wrote: > > > I'm assuming you mean the last part: How can their voice be heard? > > Well, about 6m back I took a straw poll on the question of one or many > algorithms and posted it somewhere. What it showed (I claim) is that > there is about a 50:50 split between the maximalists and the > minimalists. Which contrasted to an alleged "consensus" in IETF that > there should be many algorithms. With how many folks did you make contact? I did see some traffic here and one or two other places, but am not sure how broad a net you cast. > Another way is for people to reach out. Easy to poo-poo and dismiss > because IETF WGs have open lists. But there is a fair percentage of > people who decline to participate for other reasons. An open list might > not be enough. Perhaps a survey to ask them? I don't know how that'd pan out with the IETF's rough consensus process (surveys being vulnerable to various effects) but thinking about ways of reaching out is worthwhile yes. I'll feed that back. Cheers, S. --------------060304080004060001050906-- From nobody Sat Jan 3 18:42:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B031A1ADF; Sat, 3 Jan 2015 18:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_bTOMERiPqQ; Sat, 3 Jan 2015 18:42:40 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BE91A1AD8; Sat, 3 Jan 2015 18:42:40 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t042gW55003971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 02:42:33 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t042gRX4028357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2015 02:42:28 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t042gRf5012875; Sun, 4 Jan 2015 02:42:27 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Jan 2015 18:42:27 -0800 Date: Sat, 3 Jan 2015 18:42:25 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20141231194426.GP24442@localhost> Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20141231194426.GP24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sMmT8JdvLLgOexLKu1Eo2PYCOF4 Cc: John C Klensin , Darren J Moffat , ietf@ietf.org, saag@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 02:42:42 -0000 On Wed, 31 Dec 2014, Nico Williams wrote: >> Alternate suggestion in the interest of getting this out and >> recognizing that this is mostly a PKCS#11 problem (presumably >> ITU and/or RSA, but what do I know) and shouldn't be an IETF one: > >RSA. for the record, PKCS#11 management has been transitioned to OASIS in 2013. There is a recent draft out for version 2.40 and supposedly it should become a new version of the standard soon. 2.30 draft from 2009 never made it so the last version is still 2.20 from 2004. I do not see anything about UTF-8 normalization and/or i18n in 2.40. I will reach out to them and ask whether that was a deliberate decision. However, I think we can proceed with the URI draft independently to that if it is updated as discussed here. I'm just going through this whole thread. regards, Jan. -- Jan Pechanec From nobody Sat Jan 3 19:59:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9467E1A1B13; Sat, 3 Jan 2015 19:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGxUsmgPd9MA; Sat, 3 Jan 2015 19:59:04 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8921A1B06; Sat, 3 Jan 2015 19:59:04 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t043wtX9011792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 03:58:56 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t043wsk6017861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2015 03:58:55 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t043wsk9017849; Sun, 4 Jan 2015 03:58:54 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Jan 2015 19:58:54 -0800 Date: Sat, 3 Jan 2015 19:58:52 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20141231091906.GO24442@localhost> Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <48A18B23-AAF9-44EA-8557-D25EBE398B56@frobbit.se> <20141231091906.GO24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ahz4MYBWUk9VWh2RrC3BlCpqzIg Cc: Darren J Moffat , John C Klensin , "ietf@ietf.org" , "saag@ietf.org" , =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [saag] NF* (Re: PKCS#11 URI slot attributes & last call) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 03:59:06 -0000 On Wed, 31 Dec 2014, Nico Williams wrote: >I'm in favor of saying "do form-insensitive comparison". I'd settle for >"always normalize to NFC when creating PKCS#11 resources" because, after >all, that's what IRIs need anyways, it's just that a PKCS#11 URI-using >app might not be in a position to make "normalize on create" happen. we could recommend the normalize-before-matching approach. Even for objects (keys), the application could use only non-UTF-8 value attributes in the PKCS#11 search template. Then, go through all returning objects and for UTF-8 value attributes, do NFC normalization first before matching them. however, I think that "SHOULD" would be too strong. I think it could be mentioned side by side to the warning text based on what John noted about situations with a need to use non-ASCII characters. Jan -- Jan Pechanec From nobody Sat Jan 3 20:55:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3561A1EFE; Sat, 3 Jan 2015 20:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGpoKfWdj61Q; Sat, 3 Jan 2015 20:55:45 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8A1A1AE3; Sat, 3 Jan 2015 20:55:45 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id BFE0B584059; Sat, 3 Jan 2015 20:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3A2jYkf3Rzd+Xx FmghAEyw4fBno=; b=UOlzYufXo2sRlnDw8G++OwdaKSSRPy8hgHFtgoUkkGjCZI lsHMnjcNBQkldLs1bug99QaekQ2ohkNhmptohiPo/XsjkSWw1PgTTEK497zeJenQ jB/E5mo0N+aH9/dkUwuFMBMU5Zn/z6aOaCjKxmDlIVOFzVlniGKwQX2v7DAho= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 3E604584057; Sat, 3 Jan 2015 20:55:44 -0800 (PST) Date: Sat, 3 Jan 2015 22:55:43 -0600 From: Nico Williams To: Jan Pechanec Message-ID: <20150104045539.GY24442@localhost> References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <48A18B23-AAF9-44EA-8557-D25EBE398B56@frobbit.se> <20141231091906.GO24442@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dYA6C231f4HuLXfTIAs6RQNdu_U Cc: Darren J Moffat , John C Klensin , "ietf@ietf.org" , "saag@ietf.org" , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Subject: Re: [saag] NF* (Re: PKCS#11 URI slot attributes & last call) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 04:55:46 -0000 On Sat, Jan 03, 2015 at 07:58:52PM -0800, Jan Pechanec wrote: > we could recommend the normalize-before-matching approach. > Even for objects (keys), the application could use only non-UTF-8 > value attributes in the PKCS#11 search template. Then, go through all > returning objects and for UTF-8 value attributes, do NFC normalization > first before matching them. > > however, I think that "SHOULD" would be too strong. I think > it could be mentioned side by side to the warning text based on what > John noted about situations with a need to use non-ASCII characters. "RECOMMEND" and "SHOULD" mean the same thing. Even if you try to use "recommend" outside RFC2119 usage, it still kinda means "SHOULD", but "should", "ought to" -- these can be taken to mean "not quite SHOULD". Nico -- From nobody Sat Jan 3 21:58:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8991A6F1E; Sat, 3 Jan 2015 21:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFrAbRHafBy; Sat, 3 Jan 2015 21:58:42 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225A51A049C; Sat, 3 Jan 2015 21:58:42 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t045wNxu028446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 05:58:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t045wJYN026420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jan 2015 05:58:20 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t045wJsv012590; Sun, 4 Jan 2015 05:58:19 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 03 Jan 2015 21:58:19 -0800 Date: Sat, 3 Jan 2015 21:58:17 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20150102030130.GN24442@localhost> Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-586517042-1420350762=:6923" Content-ID: X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yJLuKZTRYY43mbhLYKZ6HvZcOqQ Cc: Darren J Moffat , ietf@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , saag@ietf.org, John C Klensin Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 05:58:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-586517042-1420350762=:6923 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Thu, 1 Jan 2015, Nico Williams wrote: Nico, many thanks for the drafted text and also to Patrik and John for discussing it. I've updated the draft in sections on URI matching guidelines, URI comparision, added a new section on I18n, and added a new paragraph to the Security considerations. Individial diffs inline, a draft for new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt). >I think we could use some text like this: > > PKCS#11 does not specify a canonical from for UTF-8 string slots in > the API. This presents the usual false negative and false positive > (aliasing) concerns that arise when dealing with unnormalized > strings. Because all PKCS#11 items are local and local security is > assumed, these concerns are mainly about usability. > > In order to improve the user experience, applications that create > PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to > NFC. For the same reason PKCS#11 libraries, slots (token readers), > and tokens SHOULD normalize their names to NFC. When listing > libraries, slots, tokens, or objects, an application SHOULD normalize > their names to NFC. When matching PKCS#11 URIs to libraries, slots, > tokens, and/or objects, applications may use form-insensitive Unicode > string comparison for matching, as the objects might pre-date these > recommendations). I've created "Internationalization Considerations" section and put the text above there after I slightly modified it. I wanted to mention CK_UTF8CHAR type so that it's clear what is discussed. 768 6. Internationalization Considerations 770 The PKCS#11 specification does not specify a canonical form for 771 strings of characters of the CK_UTF8CHAR type. This presents the 772 usual false negative and false positive (aliasing) concerns that 773 arise when dealing with unnormalized strings. Because all PKCS#11 774 items are local and local security is assumed, these concerns are 775 mainly about usability. 777 In order to improve the user experience, applications that create 778 PKCS#11 objects or label tokens, SHOULD normalize labels to NFC. For 779 the same reason PKCS#11 libraries, slots (token readers), and tokens 780 SHOULD normalize their names to NFC. When listing PKCS#11 libraries, 781 slots, tokens, and/or objects, an application SHOULD normalize their 782 names to NFC. When matching PKCS#11 URIs to libraries, slots, 783 tokens, and/or objects, applications MAY use form-insensitive Unicode 784 string comparison for matching, as those might pre-date these 785 recommendations. See also Section 3.5. in section 3.5 on URI Matching Guidelines, I've added the following as the last paragraph of the section (it was based on John's note from his last email). This paragraph might not be necessary there and the first part could be moved to the I18N section but I think it's good to put it to where attribute matching is discussed so that it is not easily overlooked. 513 As noted in Section 6, the PKCS#11 specification is not clear about 514 how to normalize UTF-8 encoded Unicode characters [RFC2279]. Those 515 who discover a need to use characters outside the ASCII repertoire 516 should be cautious, conservative, and expend extra effort to be sure 517 they know what they are doing and that failure to do so may create 518 both operational and security risks. It means that when matching 519 UTF-8 string based attributes (see Table 1) with such characters, 520 normalizing all UTF-8 strings before string comparison may be the 521 only safe approach. For example, for objects (keys) it means that 522 PKCS#11 attribute search template would only contain attributes that 523 are not UTF-8 strings and another pass through returned objects is 524 then needed for UTF-8 string comparison after the normalization is 525 applied. >Then later in the security considerations section, add something like: > > PKCS#11 does not authenticate devices to users; PKCS#11 only > authenticates users to tokens. Instead, local and physical security > are demanded: the user must be in possession of their tokens, and > system into whose slots the users' tokens are inserted must be > secure. As a result, the usual security considerations regarding > normalization do not arise. For the same reason, confusable script > issues also do not arise. Nonetheless, it is best to normalize to > NFC all strings appearing in PKCS#11 API elements. I've added the following to the Security Considerations section (again, slightly modified, I'd rather not use "PKCS#11" as an alias for the specification): 807 The PKCS#11 specification does not provide means to authenticate 808 devices to users; it only allows to authenticate users to tokens. 809 Instead, local and physical security are demanded: the user must be 810 in possession of their tokens, and system into whose slots the users' 811 tokens are inserted must be secure. As a result, the usual security 812 considerations regarding normalization do not arise. For the same 813 reason, confusable script issues also do not arise. Nonetheless, it 814 is best to normalize to NFC all strings appearing in PKCS#11 API 815 elements. See also Section 6. on top of that, I've added the following sentence to 3.6. PKCS#11 URI Comparison section: 532 strictly avoiding false positives. When working with UTF-8 strings 533 with characters outside the ASCII character sets, see important 534 caveats in Section 3.5 and Section 6. the attribute Table 1 now also states which attributes are UTF-8 strings so that it's clear without consulting the spec. thank you, Jan. -- Jan Pechanec ---559023410-586517042-1420350762=:6923 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=draft-pechanec-pkcs11uri-18-v1.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=draft-pechanec-pkcs11uri-18-v1.txt DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gUGVjaGFuZWMNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgT3JhY2xlIENvcnBvcmF0 aW9uDQpFeHBpcmVzOiBKdWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKYW51YXJ5IDMsIDIwMTUNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZQ0KICAg ICAgICAgICAgICAgICAgICAgIGRyYWZ0LXBlY2hhbmVjLXBrY3MxMXVyaS0x OA0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgUEtD UyMxMSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkNCiAgIFNj aGVtZSBmb3IgaWRlbnRpZnlpbmcgUEtDUyMxMSBvYmplY3RzIHN0b3JlZCBp biBQS0NTIzExIHRva2VucywgYW5kDQogICBhbHNvIGZvciBpZGVudGlmeWlu ZyBQS0NTIzExIHRva2Vucywgc2xvdHMgb3IgbGlicmFyaWVzLiAgVGhlIFVS SSBpcw0KICAgYmFzZWQgb24gaG93IFBLQ1MjMTEgb2JqZWN0cywgdG9rZW5z LCBzbG90cywgYW5kIGxpYnJhcmllcyBhcmUNCiAgIGlkZW50aWZpZWQgaW4g dGhlIFBLQ1MjMTEgQ3J5cHRvZ3JhcGhpYyBUb2tlbiBJbnRlcmZhY2UgU3Rh bmRhcmQuDQoNClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElF VEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlz IGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVseSA3LCAyMDE1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwN CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAg IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQu ICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBF eHBpcmVzIEp1bHkgNywgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJ IFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDINCiAg IDIuICBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIFBLQ1MjMTEgVVJJ IFNjaGVtZSBEZWZpbml0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA0DQogICAgIDMuMS4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBOYW1l IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAg My4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjMuICBQS0NTIzExIFVS SSBTY2hlbWUgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0DQogICAgIDMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBRdWVyeSBB dHRyaWJ1dGUgU2VtYW50aWNzICAuIC4gLiAuIC4gLiAgIDkNCiAgICAgMy41 LiAgUEtDUyMxMSBVUkkgTWF0Y2hpbmcgR3VpZGVsaW5lcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAzLjYuICBQS0NTIzExIFVSSSBD b21wYXJpc29uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEyDQogICAgIDMuNy4gIEdlbmVyYXRpbmcgUEtDUyMxMSBVUklzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCiAgIDQuICBFeGFt cGxlcyBvZiBQS0NTIzExIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMw0KICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2 DQogICA2LiAgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgIDcuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNw0KICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4DQog ICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgICAgOC4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOA0KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5DQoNCjEu ICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIFBLQ1MgIzExOiBDcnlwdG9ncmFw aGljIFRva2VuIEludGVyZmFjZSBTdGFuZGFyZCBbcGtjczExX3NwZWNdDQog ICBzcGVjaWZpZXMgYW4gQVBJLCBjYWxsZWQgQ3J5cHRva2ksIGZvciBkZXZp Y2VzIHdoaWNoIGhvbGQNCiAgIGNyeXB0b2dyYXBoaWMgaW5mb3JtYXRpb24g YW5kIHBlcmZvcm0gY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbnMuDQogICBDcnlw dG9raSwgcHJvbm91bmNlZCBjcnlwdG8ta2V5IGFuZCBzaG9ydCBmb3IgY3J5 cHRvZ3JhcGhpYyB0b2tlbg0KICAgaW50ZXJmYWNlLCBmb2xsb3dzIGEgc2lt cGxlIG9iamVjdC1iYXNlZCBhcHByb2FjaCwgYWRkcmVzc2luZyB0aGUNCiAg IGdvYWxzIG9mIHRlY2hub2xvZ3kgaW5kZXBlbmRlbmNlIChhbnkga2luZCBv ZiBkZXZpY2UgbWF5IGJlIHVzZWQpIGFuZA0KICAgcmVzb3VyY2Ugc2hhcmlu ZyAobXVsdGlwbGUgYXBwbGljYXRpb25zIG1heSBhY2Nlc3MgbXVsdGlwbGUg ZGV2aWNlcyksDQogICBwcmVzZW50aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGEg Y29tbW9uLCBsb2dpY2FsIHZpZXcgb2YgdGhlIGRldmljZSAtIGENCiAgIGNy eXB0b2dyYXBoaWMgdG9rZW4uDQoNCiAgIEl0IGlzIGRlc2lyYWJsZSBmb3Ig YXBwbGljYXRpb25zIG9yIGxpYnJhcmllcyB0aGF0IHdvcmsgd2l0aCBQS0NT IzExDQogICB0b2tlbnMgdG8gYWNjZXB0IGEgY29tbW9uIGlkZW50aWZpZXIg dGhhdCBjb25zdW1lcnMgY291bGQgdXNlIHRvDQogICBpZGVudGlmeSBhbiBl eGlzdGluZyBQS0NTIzExIHN0b3JhZ2Ugb2JqZWN0IGluIGEgUEtDUyMxMSB0 b2tlbiwgYW4NCiAgIGV4aXN0aW5nIHRva2VuIGl0c2VsZiwgYSBzbG90LCBv ciBhbiBleGlzdGluZyBDcnlwdG9raSBsaWJyYXJ5IChhbHNvDQogICBjYWxs ZWQgYSBwcm9kdWNlciwgbW9kdWxlLCBvciBwcm92aWRlcikuICBUaGUgc2V0 IG9mIHN0b3JhZ2Ugb2JqZWN0DQogICB0eXBlcyB0aGF0IGNhbiBiZSBzdG9y ZWQgaW4gYSBQS0NTIzExIHRva2VuIGluY2x1ZGVzIGEgY2VydGlmaWNhdGUs IGENCiAgIHB1YmxpYywgcHJpdmF0ZSBvciBzZWNyZXQga2V5LCBhbmQgYSBk YXRhIG9iamVjdC4gIFRoZXNlIG9iamVjdHMgY2FuDQogICBiZSB1bmlxdWVs eSBpZGVudGlmaWFibGUgdmlhIHRoZSBQS0NTIzExIFVSSSBzY2hlbWUgZGVm aW5lZCBpbiB0aGlzDQogICBkb2N1bWVudC4gIFRoZSBzZXQgb2YgYXR0cmli dXRlcyBkZXNjcmliaW5nIGEgc3RvcmFnZSBvYmplY3QgY2FuDQogICBjb250 YWluIGFuIG9iamVjdCBsYWJlbCwgaXRzIHR5cGUsIGFuZCBpdHMgSUQuICBU aGUgc2V0IG9mIGF0dHJpYnV0ZXMNCiAgIHRoYXQgaWRlbnRpZmllcyBhIFBL Q1MjMTEgdG9rZW4gY2FuIGNvbnRhaW4gYSB0b2tlbiBsYWJlbCwNCiAgIG1h bnVmYWN0dXJlciBuYW1lLCBzZXJpYWwgbnVtYmVyLCBhbmQgdG9rZW4gbW9k ZWwuICBBdHRyaWJ1dGVzIHRoYXQNCiAgIGNhbiBpZGVudGlmeSBhIHNsb3Qg YXJlIGEgc2xvdCBJRCwgZGVzY3JpcHRpb24sIGFuZCBtYW51ZmFjdHVyZXIu DQogICBBdHRyaWJ1dGVzIHRoYXQgY2FuIGlkZW50aWZ5IGEgQ3J5cHRva2kg bGlicmFyeSBhcmUgYSBsaWJyYXJ5DQogICBtYW51ZmFjdHVyZXIsIGRlc2Ny aXB0aW9uLCBhbmQgdmVyc2lvbi4gIExpYnJhcnkgYXR0cmlidXRlcyBtYXkg YmUNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBK dWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUg ICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgbmVjZXNzYXJ5IHRv IHVzZSBpZiBtb3JlIHRoYW4gb25lIENyeXB0b2tpIGxpYnJhcnkgcHJvdmlk ZXMgYSB0b2tlbg0KICAgYW5kL29yIFBLQ1MjMTEgb2JqZWN0cyBvZiB0aGUg c2FtZSBuYW1lLiAgQSBzZXQgb2YgcXVlcnkgYXR0cmlidXRlcw0KICAgaXMg cHJvdmlkZWQgYXMgd2VsbC4NCg0KICAgVGhlIFBLQ1MjMTEgVVJJIGNhbm5v dCBpZGVudGlmeSBvdGhlciBvYmplY3RzIGRlZmluZWQgaW4gdGhlDQogICBz cGVjaWZpY2F0aW9uIFtwa2NzMTFfc3BlY10gYXNpZGUgZnJvbSBzdG9yYWdl IG9iamVjdHMuICBGb3IgZXhhbXBsZSwNCiAgIG9iamVjdHMgbm90IGlkZW50 aWZpYWJsZSBieSBhIFBLQ1MjMTEgVVJJIGluY2x1ZGUgYSBoYXJkd2FyZSBm ZWF0dXJlDQogICBhbmQgbWVjaGFuaXNtLiAgTm90ZSB0aGF0IGEgQ3J5cHRv a2kgbGlicmFyeSBkb2VzIG5vdCBoYXZlIHRvIHByb3ZpZGUNCiAgIGZvciBz dG9yYWdlIG9iamVjdHMgYXQgYWxsLiAgVGhlIFVSSSBjYW4gc3RpbGwgYmUg dXNlZCB0byBpZGVudGlmeSBhDQogICBzcGVjaWZpYyBQS0NTIzExIHRva2Vu LCBzbG90IG9yIGFuIEFQSSBwcm9kdWNlciBpbiBzdWNoIGEgY2FzZS4NCg0K ICAgQSBzdWJzZXQgb2YgZXhpc3RpbmcgUEtDUyMxMSBzdHJ1Y3R1cmUgbWVt YmVycyBhbmQgb2JqZWN0IGF0dHJpYnV0ZXMNCiAgIHdhcyBjaG9zZW4gdG8g dW5pcXVlbHkgaWRlbnRpZnkgYSBQS0NTIzExIHN0b3JhZ2Ugb2JqZWN0LCB0 b2tlbiwNCiAgIHNsb3QsIG9yIGxpYnJhcnkgaW4gYSBjb25maWd1cmF0aW9u IGZpbGUsIG9uIGEgY29tbWFuZCBsaW5lLCBvciBpbiBhDQogICBjb25maWd1 cmF0aW9uIHByb3BlcnR5IG9mIHNvbWV0aGluZyBlbHNlLiAgU2hvdWxkIHRo ZXJlIGJlIGEgbmVlZCBmb3INCiAgIGEgbW9yZSBjb21wbGV4IGluZm9ybWF0 aW9uIGV4Y2hhbmdlIG9uIFBLQ1MjMTEgZW50aXRpZXMgYSBkaWZmZXJlbnQN CiAgIG1lYW5zIG9mIGRhdGEgbWFyc2hhbGxpbmcgc2hvdWxkIGJlIGNob3Nl biBhY2NvcmRpbmdseS4NCg0KICAgQSBQS0NTIzExIFVSSSBpcyBub3QgaW50 ZW5kZWQgdG8gYmUgdXNlZCB0byBjcmVhdGUgbmV3IFBLQ1MjMTENCiAgIG9i amVjdHMgaW4gdG9rZW5zLCBvciB0byBjcmVhdGUgUEtDUyMxMSB0b2tlbnMu ICBJdCBpcyBzb2xlbHkgdG8gYmUNCiAgIHVzZWQgdG8gaWRlbnRpZnkgYW5k IHdvcmsgd2l0aCBleGlzdGluZyBzdG9yYWdlIG9iamVjdHMsIHRva2Vucywg YW5kDQogICBzbG90cyB0aHJvdWdoIHRoZSBQS0NTIzExIEFQSSwgb3IgaWRl bnRpZnkgQ3J5cHRva2kgbGlicmFyaWVzDQogICB0aGVtc2VsdmVzLg0KDQog ICBUaGUgVVJJIHNjaGVtZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgaXMg ZGVzaWduZWQgc3BlY2lmaWNhbGx5IHdpdGgNCiAgIGEgbWFwcGluZyB0byB0 aGUgUEtDUyMxMSBBUEkgaW4gbWluZC4gIFRoZSBVUkkgdXNlcyB0aGUgc2No ZW1lLCBwYXRoDQogICBhbmQgcXVlcnkgY29tcG9uZW50cyBkZWZpbmVkIGlu IHRoZSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXINCiAgIChVUkkpOiBH ZW5lcmljIFN5bnRheCBbUkZDMzk4Nl0gZG9jdW1lbnQuICBUaGUgVVJJIGRv ZXMgbm90IHVzZSB0aGUNCiAgIGhpZXJhcmNoaWNhbCBlbGVtZW50IGZvciBh IG5hbWluZyBhdXRob3JpdHkgaW4gdGhlIHBhdGggc2luY2UgdGhlDQogICBh dXRob3JpdHkgcGFydCBjb3VsZCBub3QgYmUgbWFwcGVkIHRvIFBLQ1MjMTEg QVBJIGVsZW1lbnRzLiAgVGhlIFVSSQ0KICAgZG9lcyBub3QgdXNlIHRoZSBm cmFnbWVudCBjb21wb25lbnQuDQoNCiAgIElmIGFuIGFwcGxpY2F0aW9uIGhh cyBubyBhY2Nlc3MgdG8gYSBwcm9kdWNlciBvciBwcm9kdWNlcnMgb2YgdGhl DQogICBQS0NTIzExIEFQSSB0aGUgcXVlcnkgY29tcG9uZW50IG1vZHVsZSBh dHRyaWJ1dGVzIGNhbiBiZSB1c2VkLg0KICAgSG93ZXZlciwgdGhlIFBLQ1Mj MTEgVVJJIGNvbnN1bWVyIGNhbiBhbHdheXMgZGVjaWRlIHRvIHByb3ZpZGUg aXRzDQogICBvd24gYWRlcXVhdGUgdXNlciBpbnRlcmZhY2UgdG8gbG9jYXRl IGFuZCBsb2FkIFBLQ1MjMTEgQVBJIHByb2R1Y2Vycy4NCg0KICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFM TCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMN CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmli ZWQgaW4gW1JGQzIxMTldLg0KDQoyLiAgQ29udHJpYnV0b3JzDQoNCiAgIFN0 ZWYgV2FsdGVyLCBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvcywgTmljbyBXaWxs aWFtcywgRGFuIFdpbnNoaXAsIGFuZA0KICAgSmFyb3NsYXYgSW1yaWNoIGNv bnRyaWJ1dGVkIHRvIHRoZSBkZXZlbG9wbWVudCBvZiB0aGlzIGRvY3VtZW50 Lg0KDQoNCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBp cmVzIEp1bHkgNywgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNj aGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQozLiAgUEtDUyMx MSBVUkkgU2NoZW1lIERlZmluaXRpb24NCg0KICAgSW4gYWNjb3JkYW5jZSB3 aXRoIFtSRkM0Mzk1XSwgdGhpcyBzZWN0aW9uIHByb3ZpZGVzIHRoZSBpbmZv cm1hdGlvbg0KICAgcmVxdWlyZWQgdG8gcmVnaXN0ZXIgdGhlIFBLQ1MjMTEg VVJJIHNjaGVtZS4NCg0KMy4xLiAgUEtDUyMxMSBVUkkgU2NoZW1lIE5hbWUN Cg0KICAgcGtjczExDQoNCjMuMi4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBTdGF0 dXMNCg0KICAgUGVybWFuZW50Lg0KDQozLjMuICBQS0NTIzExIFVSSSBTY2hl bWUgU3ludGF4DQoNCiAgIFRoZSBQS0NTIzExIFVSSSBpcyBhIHNlcXVlbmNl IG9mIGF0dHJpYnV0ZSB2YWx1ZSBwYWlycyBzZXBhcmF0ZWQgYnkgYQ0KICAg c2VtaWNvbG9uIHRoYXQgZm9ybSBhIG9uZSBsZXZlbCBwYXRoIGNvbXBvbmVu dCwgb3B0aW9uYWxseSBmb2xsb3dlZA0KICAgYnkgYSBxdWVyeS4gIEluIGFj Y29yZGFuY2Ugd2l0aCBTZWN0aW9uIDIuNSBvZiBbUkZDMzk4Nl0sIHRoZSBk YXRhDQogICBzaG91bGQgZmlyc3QgYmUgZW5jb2RlZCBhcyBvY3RldHMgYWNj b3JkaW5nIHRvIHRoZSBVVEYtOCBjaGFyYWN0ZXINCiAgIGVuY29kaW5nIFtS RkMzNjI5XTsgdGhlbiBvbmx5IHRob3NlIG9jdGV0cyB0aGF0IGRvIG5vdCBj b3JyZXNwb25kIHRvDQogICBjaGFyYWN0ZXJzIGluIHRoZSB1bnJlc2VydmVk IHNldCBvciB0byBwZXJtaXR0ZWQgY2hhcmFjdGVycyBmcm9tIHRoZQ0KICAg cmVzZXJ2ZWQgc2V0IHNob3VsZCBiZSBwZXJjZW50LWVuY29kZWQuICBUaGlz IHNwZWNpZmljYXRpb24gc3VnZ2VzdHMNCiAgIG9uZSBhbGxvd2FibGUgZXhj ZXB0aW9uIHRvIHRoYXQgcnVsZSBmb3IgdGhlICJpZCIgYXR0cmlidXRlLCBh cw0KICAgc3RhdGVkIGxhdGVyIGluIHRoaXMgc2VjdGlvbi4gIE5vdGUgdGhh dCBpZiBhIFVSSSBkb2VzIGNhcnJ5DQogICBjaGFyYWN0ZXJzIG91dHNpZGUg b2YgdGhlIEFTQ0lJIGNoYXJhY3RlciBzZXQgYSBjb252ZXJzaW9uIHRvIGFu DQogICBJbnRlcm5hdGlvbmFsaXplZCBSZXNvdXJjZSBJZGVudGlmaWVyIChJ UkkpIGRlZmluZWQgaW4gW1JGQzM5ODddIG1heQ0KICAgYmUgY29uc2lkZXJl ZC4gIEdyYW1tYXIgcnVsZXMgInVucmVzZXJ2ZWQiIGFuZCAicGN0LWVuY29k ZWQiIGluIHRoZQ0KICAgUEtDUyMxMSBVUkkgc3BlY2lmaWNhdGlvbiBiZWxv dyBhcmUgaW1wb3J0ZWQgZnJvbSBbUkZDMzk4Nl0uICBBcyBhDQogICBzcGVj aWFsIGNhc2UsIG5vdGUgdGhhdCBhY2NvcmRpbmcgdG8gQXBwZW5kaXggQSBv ZiBbUkZDMzk4Nl0sIGEgc3BhY2UNCiAgIG11c3QgYmUgcGVyY2VudC1lbmNv ZGVkLg0KDQogICBUaGUgUEtDUyMxMSBzcGVjaWZpY2F0aW9uIGltcG9zZXMg dmFyaW91cyBsaW1pdGF0aW9ucyBvbiB0aGUgdmFsdWUgb2YNCiAgIGF0dHJp YnV0ZXMsIGJlIGl0IGEgbW9yZSByZXN0cmljdGl2ZSBjaGFyYWN0ZXIgc2V0 IGZvciB0aGUgInNlcmlhbCINCiAgIGF0dHJpYnV0ZSBvciBmaXhlZCBzaXpl ZCBidWZmZXJzIGZvciBhbG1vc3QgYWxsIHRoZSBvdGhlcnMsIGluY2x1ZGlu Zw0KICAgInRva2VuIiwgIm1hbnVmYWN0dXJlciIsIGFuZCAibW9kZWwiIGF0 dHJpYnV0ZXMuICBIb3dldmVyLCB0aGUNCiAgIFBLQ1MjMTEgVVJJIG5vdGF0 aW9uIGRvZXMgbm90IGltcG9zZSBzdWNoIGxpbWl0YXRpb25zIGFzaWRlIGZy b20NCiAgIHJlbW92aW5nIGdlbmVyaWMgYW5kIFBLQ1MjMTEgVVJJIGRlbGlt aXRlcnMgZnJvbSBhIHBlcm1pdHRlZA0KICAgY2hhcmFjdGVyIHNldC4gIFdl IGJlbGlldmUgdGhhdCBiZWluZyB0b28gcmVzdHJpY3RpdmUgb24gdGhlDQog ICBhdHRyaWJ1dGUgdmFsdWVzIGNvdWxkIGxpbWl0IHRoZSBQS0NTIzExIFVS SSB1c2VmdWxuZXNzLiAgV2hhdCBpcw0KICAgbW9yZSwgcG9zc2libGUgZnV0 dXJlIGNoYW5nZXMgdG8gdGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBzaG91 bGQgbm90DQogICBhZmZlY3QgZXhpc3RpbmcgYXR0cmlidXRlcy4NCg0KICAg QSBQS0NTIzExIFVSSSB0YWtlcyB0aGUgZm9ybSAoZm9yIGV4cGxhbmF0aW9u IG9mIEF1Z21lbnRlZCBCTkYsIHNlZQ0KICAgW1JGQzUyMzRdKToNCg0KDQoN Cg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1 bHkgNywgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAg ICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogIHBrMTEtVVJJICAgICAg ICAgICAgID0gInBrY3MxMToiIHBrMTEtcGF0aCBbICI/IiBwazExLXF1ZXJ5 IF0NCiAgOyBQYXRoIGNvbXBvbmVudCBhbmQgaXRzIGF0dHJpYnV0ZXMuICBQ YXRoIG1heSBiZSBlbXB0eS4NCiAgcGsxMS1wYXRoICAgICAgICAgICAgPSBb IHBrMTEtcGF0dHIgKigiOyIgcGsxMS1wYXR0cikgXQ0KICBwazExLXBhdHRy ICAgICAgICAgICA9IHBrMTEtdG9rZW4gLyBwazExLW1hbnVmIC8gcGsxMS1z ZXJpYWwgLw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEtbW9kZWwg LyBwazExLWxpYi1tYW51ZiAvDQogICAgICAgICAgICAgICAgICAgICAgICAg cGsxMS1saWItdmVyIC8gcGsxMS1saWItZGVzYyAvDQogICAgICAgICAgICAg ICAgICAgICAgICAgcGsxMS1vYmplY3QgLyBwazExLXR5cGUgLyBwazExLWlk IC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLXNsb3QtZGVzYyAv IHBrMTEtc2xvdC1tYW51ZiAvDQogICAgICAgICAgICAgICAgICAgICAgICAg cGsxMS1zbG90LWlkIC8gcGsxMS12LXBhdHRyDQogIDsgUXVlcnkgY29tcG9u ZW50IGFuZCBpdHMgYXR0cmlidXRlcy4gIFF1ZXJ5IG1heSBiZSBlbXB0eS4N CiAgcGsxMS1xYXR0ciAgICAgICAgICAgPSBwazExLXBpbi1zb3VyY2UgLyBw azExLXBpbi12YWx1ZSAvDQogICAgICAgICAgICAgICAgICAgICAgICAgcGsx MS1tb2R1bGUtbmFtZSAvIHBrMTEtbW9kdWxlLXBhdGggLw0KICAgICAgICAg ICAgICAgICAgICAgICAgIHBrMTEtdi1xYXR0cg0KICBwazExLXF1ZXJ5ICAg ICAgICAgICA9IFsgcGsxMS1xYXR0ciAqKCImIiBwazExLXFhdHRyKSBdDQog IDsgUkZDIDM5ODYgc2VjdGlvbiAyLjIgbWFuZGF0ZXMgYWxsIHBvdGVudGlh bGx5IHJlc2VydmVkIGNoYXJhY3RlcnMNCiAgOyB0aGF0IGRvIG5vdCBjb25m bGljdCB3aXRoIGFjdHVhbCBkZWxpbWl0ZXJzIG9mIHRoZSBVUkkgZG8gbm90 IGhhdmUNCiAgOyB0byBiZSBwZXJjZW50LWVuY29kZWQuDQogIHBrMTEtcmVz LWF2YWlsICAgICAgID0gIjoiIC8gIlsiIC8gIl0iIC8gIkAiIC8gIiEiIC8g IiQiIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAiJyIgLyAiKCIgLyAi KSIgLyAiKiIgLyAiKyIgLyAiLCIgLyAiPSINCiAgcGsxMS1wYXRoLXJlcy1h dmFpbCAgPSBwazExLXJlcy1hdmFpbCAvICImIg0KICA7ICIvIiBhbmQgIj8i IGluIHRoZSBxdWVyeSBjb21wb25lbnQgTUFZIGJlIHVuZW5jb2RlZCBidXQg IiYiIE1VU1QNCiAgOyBiZSBlbmNvZGVkIHNpbmNlIGl0IGZ1bmN0aW9ucyBh cyBhIGRlbGltaXRlciB3aXRoaW4gdGhlIGNvbXBvbmVudC4NCiAgcGsxMS1x dWVyeS1yZXMtYXZhaWwgPSBwazExLXJlcy1hdmFpbCAvICIvIiAvICI/IiAv ICJ8Ig0KICBwazExLXBjaGFyICAgICAgICAgICA9IHVucmVzZXJ2ZWQgLyBw azExLXBhdGgtcmVzLWF2YWlsIC8gcGN0LWVuY29kZWQNCiAgcGsxMS1xY2hh ciAgICAgICAgICAgPSB1bnJlc2VydmVkIC8gcGsxMS1xdWVyeS1yZXMtYXZh aWwgLyBwY3QtZW5jb2RlZA0KICBwazExLXRva2VuICAgICAgICAgICA9ICJ0 b2tlbiIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtbWFudWYgICAgICAgICAg ID0gIm1hbnVmYWN0dXJlciIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtc2Vy aWFsICAgICAgICAgID0gInNlcmlhbCIgIj0iICpwazExLXBjaGFyDQogIHBr MTEtbW9kZWwgICAgICAgICAgID0gIm1vZGVsIiAiPSIgKnBrMTEtcGNoYXIN CiAgcGsxMS1saWItbWFudWYgICAgICAgPSAibGlicmFyeS1tYW51ZmFjdHVy ZXIiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxpYi1kZXNjICAgICAgICA9 ICJsaWJyYXJ5LWRlc2NyaXB0aW9uIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsx MS1saWItdmVyICAgICAgICAgPSAibGlicmFyeS12ZXJzaW9uIiAiPSIgMSpE SUdJVCBbICIuIiAxKkRJR0lUIF0NCiAgcGsxMS1vYmplY3QgICAgICAgICAg PSAib2JqZWN0IiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS10eXBlICAgICAg ICAgICAgPSAidHlwZSIgIj0iICggInB1YmxpYyIgLyAicHJpdmF0ZSIgLyAi Y2VydCIgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICJzZWNyZXQta2V5 IiAvICJkYXRhIiApDQogIHBrMTEtaWQgICAgICAgICAgICAgID0gImlkIiAi PSIgKnBrMTEtcGNoYXINCiAgcGsxMS1zbG90LW1hbnVmICAgICAgPSAic2xv dC1tYW51ZmFjdHVyZXIiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLXNsb3Qt ZGVzYyAgICAgICA9ICJzbG90LWRlc2NyaXB0aW9uIiAiPSIgKnBrMTEtcGNo YXINCiAgcGsxMS1zbG90LWlkICAgICAgICAgPSAic2xvdC1pZCIgIj0iIDEq RElHSVQNCiAgcGsxMS1waW4tc291cmNlICAgICAgPSAicGluLXNvdXJjZSIg Ij0iICpwazExLXFjaGFyDQogIHBrMTEtcGluLXZhbHVlICAgICAgID0gInBp bi12YWx1ZSIgIj0iICpwazExLXFjaGFyDQogIHBrMTEtbW9kdWxlLW5hbWUg ICAgID0gIm1vZHVsZS1uYW1lIiAiPSIgKnBrMTEtcWNoYXINCiAgcGsxMS1t b2R1bGUtcGF0aCAgICAgPSAibW9kdWxlLXBhdGgiICI9IiAqcGsxMS1xY2hh cg0KICBwazExLXYtYXR0ci1ubS1jaGFyICA9IEFMUEhBIC8gRElHSVQgLyAi LSIgLyAiXyINCiAgOyBQZXJtaXR0ZWQgdmFsdWUgb2YgYSB2ZW5kb3Igc3Bl Y2lmaWMgYXR0cmlidXRlIGlzIGJhc2VkIG9uDQogIDsgd2hldGhlciB0aGUg YXR0cmlidXRlIGlzIHVzZWQgaW4gdGhlIHBhdGggb3IgaW4gdGhlIHF1ZXJ5 Lg0KICBwazExLXYtcGF0dHIgICAgICAgICA9IDEqcGsxMS12LWF0dHItbm0t Y2hhciAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS12LXFhdHRyICAgICAgICAg PSAxKnBrMTEtdi1hdHRyLW5tLWNoYXIgIj0iICpwazExLXFjaGFyDQoNCg0K DQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA3LCAy MDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAg ICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgIFRoZSBVUkkgcGF0aCBjb21wb25l bnQgY29udGFpbnMgYXR0cmlidXRlcyB0aGF0IGlkZW50aWZ5IGEgcmVzb3Vy Y2UNCiAgIGluIGEgb25lIGxldmVsIGhpZXJhcmNoeSBwcm92aWRlZCBieSBD cnlwdG9raSBwcm9kdWNlcnMuICBUaGUgcXVlcnkNCiAgIGNvbXBvbmVudCBj YW4gY29udGFpbiBhIGZldyBhdHRyaWJ1dGVzIHRoYXQgbWF5IGJlIG5lZWRl ZCB0byByZXRyaWV2ZQ0KICAgdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkg dGhlIFVSSSBwYXRoLiAgQXR0cmlidXRlcyBpbiB0aGUgcGF0aA0KICAgY29t cG9uZW50IGFyZSBkZWxpbWl0ZWQgYnkgJzsnIGNoYXJhY3RlciwgYXR0cmli dXRlcyBpbiB0aGUgcXVlcnkNCiAgIGNvbXBvbmVudCB1c2UgJyYnIGFzIGEg ZGVsaW1pdGVyLg0KDQogICBCb3RoIHBhdGggYW5kIHF1ZXJ5IGNvbXBvbmVu dHMgbWF5IGNvbnRhaW4gdmVuZG9yIHNwZWNpZmljDQogICBhdHRyaWJ1dGVz LiAgU3VjaCBhdHRyaWJ1dGUgbmFtZXMgTVVTVCBOT1QgY2xhc2ggd2l0aCBl eGlzdGluZw0KICAgYXR0cmlidXRlIG5hbWVzLiAgTm90ZSB0aGF0IGluIGFj Y29yZGFuY2Ugd2l0aCBbQkNQMTc4XSwgcHJldmlvdXNseQ0KICAgdXNlZCBj b252ZW50aW9uIG9mIHN0YXJ0aW5nIHZlbmRvciBhdHRyaWJ1dGVzIHdpdGgg YW4gIngtIiBwcmVmaXggaXMNCiAgIG5vdyBkZXByaWNhdGVkLg0KDQogICBU aGUgZ2VuZXJhbCAnLycgZGVsaW1pdGVyIE1VU1QgYmUgcGVyY2VudC1lbmNv ZGVkIGluIHRoZSBwYXRoDQogICBjb21wb25lbnQgc28gdGhhdCBnZW5lcmlj IFVSSSBwYXJzZXJzIG5ldmVyIHNwbGl0IHRoZSBwYXRoIGNvbXBvbmVudA0K ICAgaW50byBtdWx0aXBsZSBzZWdtZW50cy4gIEl0IE1BWSBiZSB1bmVuY29k ZWQgaW4gdGhlIHF1ZXJ5IGNvbXBvbmVudC4NCiAgIERlbGltaXRlciAnPycg IE1VU1QgYmUgcGVyY2VudC1lbmNvZGVkIGluIHRoZSBwYXRoIGNvbXBvbmVu dCBzaW5jZQ0KICAgdGhlIFBLQ1MjMTEgVVJJIHVzZXMgYSBxdWVyeSBjb21w b25lbnQuICBEZWxpbWl0ZXIgJyMnIE1VU1QgYmUgYWx3YXlzDQogICBwZXJj ZW50LWVuY29kZWQgc28gdGhhdCBnZW5lcmljIFVSSSBwYXJzZXJzIGRvIG5v dCB0cmVhdCBhIGhhc2ggYXMgYQ0KICAgYmVnaW5uaW5nIG9mIGEgZnJhZ21l bnQgaWRlbnRpZmllciBjb21wb25lbnQuICBBbGwgb3RoZXIgZ2VuZXJpYw0K ICAgZGVsaW1pdGVycyBNQVkgYmUgdXNlZCB1bmVuY29kZWQgKCc6JywgJ1sn LCAnXScsIGFuZCAnQCcpIGluIHRoZQ0KICAgUEtDUyMxMSBVUkkuDQoNCiAg IFRoZSBmb2xsb3dpbmcgdGFibGUgcHJlc2VudHMgbWFwcGluZyBiZXR3ZWVu IHRoZSBQS0NTIzExIFVSSSBwYXRoDQogICBjb21wb25lbnQgYXR0cmlidXRl cyBhbmQgdGhlIFBLQ1MjMTEgQVBJIHN0cnVjdHVyZSBtZW1iZXJzIGFuZCBv YmplY3QNCiAgIGF0dHJpYnV0ZXMuICBHaXZlbiB0aGF0IFBLQ1MjMTEgVVJJ IHVzZXJzIG1heSBiZSBxdWl0ZSBpZ25vcmFudCBhYm91dA0KICAgdGhlIFBL Q1MjMTEgc3BlY2lmaWNhdGlvbiB0aGUgbWFwcGluZyBpcyBhIHByb2R1Y3Qg b2YgYSBuZWNlc3NhcnkNCiAgIGNvbXByb21pc2UgYmV0d2VlbiBob3cgcHJl Y2lzZWx5IGFyZSB0aGUgVVJJIGF0dHJpYnV0ZSBuYW1lcyBtYXBwZWQNCiAg IHRvIHRoZSBuYW1lcyBpbiB0aGUgc3BlY2lmaWNhdGlvbiBhbmQgdGhlIGVh c2Ugb2YgdXNlIGFuZA0KICAgdW5kZXJzdGFuZGluZyBvZiB0aGUgVVJJIHNj aGVtZS4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IFVS SSBjb21wb25lbnQgcGF0aCAgIHwgQXR0cmlidXRlICAgICAgICAgICB8IEF0 dHJpYnV0ZSAgICAgICAgICAgIHwNCiAgIHwgYXR0cmlidXRlIG5hbWUgICAg ICAgfCByZXByZXNlbnRzICAgICAgICAgIHwgY29ycmVzcG9uZHMgaW4gdGhl ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCBQS0NTIzExICAgICAgICAgICAgICB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IHNwZWNp ZmljYXRpb24gdG8gICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgIHwgaWQgICAgICAgICAgICAgICAgICAgfCBr ZXkgaWRlbnRpZmllciBmb3IgIHwgIkNLQV9JRCIgb2JqZWN0ICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8IG9iamVjdCAgICAgICAgICAg ICAgfCBhdHRyaWJ1dGUgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgIHwgbGlicmFyeS1kZXNjcmlwdGlvbiAgfCBjaGFy YWN0ZXItc3RyaW5nICAgIHwgImxpYnJhcnlEZXNjcmlwdGlvbiIgfA0KICAg fCAgICAgICAgICAgICAgICAgICAgICB8IGRlc2NyaXB0aW9uIG9mIHRoZSAg fCBtZW1iZXIgb2YgQ0tfSU5GTyAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgbGlicmFyeSAgICAgICAgICAgICB8IHN0cnVjdHVyZS4gIEl0 IGlzIGFuIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgVVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IGxpYnJhcnktbWFudWZhY3R1 cmVyIHwgSUQgb2YgdGhlIENyeXB0b2tpICB8ICJtYW51ZmFjdHVyZXJJRCIg ICAgIHwNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJl cyBKdWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hl bWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgfCAgICAgICAg ICAgICAgICAgICAgICB8IGxpYnJhcnkgICAgICAgICAgICAgfCBtZW1iZXIg b2YgdGhlICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwg bWFudWZhY3R1cmVyICAgICAgICB8IENLX0lORk8gc3RydWN0dXJlLiAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgSXQgaXMgYW4gVVRGLTggICAgICAgfA0KICAgfCAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJpbmcuICAg ICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAg IHwgbGlicmFyeS12ZXJzaW9uICAgICAgfCBDcnlwdG9raSBsaWJyYXJ5ICAg IHwgImxpYnJhcnlWZXJzaW9uIiAgICAgfA0KICAgfCAgICAgICAgICAgICAg ICAgICAgICB8IHZlcnNpb24gbnVtYmVyICAgICAgfCBtZW1iZXIgb2YgQ0tf SU5GTyAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8IHN0cnVjdHVyZSAgICAgICAgICAgIHwNCiAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBtYW51ZmFjdHVyZXIgICAg ICAgICB8IElEIG9mIHRoZSB0b2tlbiAgICAgfCAibWFudWZhY3R1cmVySUQi ICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgbWFudWZhY3R1 cmVyICAgICAgICB8IG1lbWJlciBvZiAgICAgICAgICAgIHwNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgQ0tf VE9LRU5fSU5GTyAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1Y3R1cmUuICBJdCBpcyBh biB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8IFVURi04IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgfCBtb2RlbCAgICAgICAgICAgICAgICB8 IHRva2VuIG1vZGVsICAgICAgICAgfCAibW9kZWwiIG1lbWJlciBvZiAgICB8 DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICB8IENLX1RPS0VOX0lORk8gICAgICAgIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgc3RydWN0dXJl LiAgSXQgaXMgYW4gfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfCBVVEYtOCBzdHJpbmcuICAgICAgICB8DQog ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgb2JqZWN0ICAgICAg ICAgICAgICAgfCBkZXNjcmlwdGlvbiAobmFtZSkgIHwgIkNLQV9MQUJFTCIg b2JqZWN0ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IG9mIHRo ZSBvYmplY3QgICAgICAgfCBhdHRyaWJ1dGUuICBJdCBpcyBhbiB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 IFVURi04IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KICAgfCBzZXJpYWwgICAgICAgICAgICAgICB8IGNoYXJhY3Rl ci1zdHJpbmcgICAgfCAic2VyaWFsTnVtYmVyIiAgICAgICB8DQogICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgc2VyaWFsIG51bWJlciBvZiAgICB8IG1l bWJlciBvZiAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCB0aGUgdG9rZW4gICAgICAgICAgIHwgQ0tfVE9LRU5fSU5GTyAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCBzdHJ1Y3R1cmUgICAgICAgICAgICB8DQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgc2xvdC1kZXNjcmlwdGlvbiAgICAg fCBzbG90IGRlc2NyaXB0aW9uICAgIHwgInNsb3REZXNjcmlwdGlvbiIgICAg fA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfCBtZW1iZXIgb2YgICAgICAgICAgICB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IENLX1NMT1Rf SU5GTyAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwgc3RydWN0dXJlLiAgSXQgaXMgYW4gfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCBVVEYtOCBzdHJpbmcuICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgIHwgc2xvdC1pZCAgICAgICAgICAgICAgfCBDcnlw dG9raS1hc3NpZ25lZCAgIHwgZGVjaW1hbCBudW1iZXIgb2YgICAgfA0KICAg fCAgICAgICAgICAgICAgICAgICAgICB8IHZhbHVlIHRoYXQgICAgICAgICAg fCAiQ0tfU0xPVF9JRCIgdHlwZSAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgaWRlbnRpZmllcyBhIHNsb3QgICB8ICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBz bG90LW1hbnVmYWN0dXJlciAgICB8IElEIG9mIHRoZSBzbG90ICAgICAgfCAi bWFudWZhY3R1cmVySUQiICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAg ICAgIHwgbWFudWZhY3R1cmVyICAgICAgICB8IG1lbWJlciBvZiAgICAgICAg ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwgQ0tfU0xPVF9JTkZPICAgICAgICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1 Y3R1cmUuICBJdCBpcyBhbiB8DQogICB8ICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8IFVURi04IHN0cmluZy4gICAgICAg IHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCB0b2tlbiAg ICAgICAgICAgICAgICB8IGFwcGxpY2F0aW9uLWRlZmluZWQgfCAibGFiZWwi IG1lbWJlciBvZiAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwg bGFiZWwsIGFzc2lnbmVkICAgICB8IHRoZSBDS19UT0tFTl9JTkZPICAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBkdXJpbmcgdG9rZW4gICAg ICAgIHwgc3RydWN0dXJlLiAgSXQgaXMgYW4gfA0KDQoNCg0KUGVjaGFuZWMg JiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgNywgMjAxNSAgICAgICAg ICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5 IDIwMTUNCg0KDQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgaW5pdGlh bGl6YXRpb24gICAgICB8IFVURi04IHN0cmluZy4gICAgICAgIHwNCiAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCB0eXBlICAgICAgICAgICAg ICAgICB8IG9iamVjdCBjbGFzcyAodHlwZSkgfCAiQ0tBX0NMQVNTIiBvYmpl Y3QgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICB8IGF0dHJpYnV0ZSAgICAgICAgICAgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgVGFibGUgMTogTWFwcGluZyBi ZXR3ZWVuIFVSSSBwYXRoIGNvbXBvbmVudCBhdHRyaWJ1dGVzIGFuZCBQS0NT IzExDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWNhdGlv biBuYW1lcw0KDQogICBUaGUgcXVlcnkgY29tcG9uZW50IGF0dHJpYnV0ZSAi cGluLXNvdXJjZSIgc3BlY2lmaWVzIHdoZXJlIHRoZQ0KICAgYXBwbGljYXRp b24gb3IgbGlicmFyeSBzaG91bGQgZmluZCB0aGUgbm9ybWFsIHVzZXIncyB0 b2tlbiBQSU4sIHRoZQ0KICAgInBpbi12YWx1ZSIgYXR0cmlidXRlIHByb3Zp ZGVzIHRoZSBub3JtYWwgdXNlcidzIFBJTiB2YWx1ZSBkaXJlY3RseSwNCiAg IGlmIG5lZWRlZCwgYW5kIHRoZSAibW9kdWxlLW5hbWUiIGFuZCAibW9kdWxl LXBhdGgiIGF0dHJpYnV0ZXMgbW9kaWZ5DQogICBkZWZhdWx0IHNldHRpbmdz IGZvciBhY2Nlc3NpbmcgUEtDUyMxMSBwcm92aWRlcnMuICBGb3IgdGhlIGRl ZmluaXRpb24NCiAgIG9mIGEgIm5vcm1hbCB1c2VyIiwgc2VlIFtwa2NzMTFf c3BlY10uDQoNCiAgIFRoZSBBQk5GIHJ1bGVzIGFib3ZlIGlzIGEgYmVzdCBl ZmZvcnQgZGVmaW5pdGlvbiBhbmQgdGhpcyBwYXJhZ3JhcGgNCiAgIHNwZWNp ZmllcyBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzLiAgVGhlIFBLQ1MjMTEgVVJJ IE1VU1QgTk9UIGNvbnRhaW4NCiAgIGR1cGxpY2F0ZSBhdHRyaWJ1dGVzIG9m IHRoZSBzYW1lIG5hbWUgaW4gdGhlIFVSSSBwYXRoIGNvbXBvbmVudC4gIEl0 DQogICBtZWFucyB0aGF0IGVhY2ggYXR0cmlidXRlIG1heSBiZSBwcmVzZW50 IGF0IG1vc3Qgb25jZSBpbiB0aGUgUEtDUyMxMQ0KICAgVVJJIHBhdGguICBB c2lkZSBmcm9tIHRoZSBxdWVyeSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudCwNCiAgIGR1cGxpY2F0ZSAodmVuZG9yKSBhdHRyaWJ1dGVz IE1BWSBiZSBwcmVzZW50IGluIHRoZSBVUkkgcXVlcnkNCiAgIGNvbXBvbmVu dCBhbmQgaXQgaXMgdXAgdG8gdGhlIFVSSSBjb25zdW1lciB0byBkZWNpZGUg b24gaG93IHRvIGRlYWwNCiAgIHdpdGggc3VjaCBkdXBsaWNhdGVzLg0KDQog ICBUaGUgd2hvbGUgdmFsdWUgb2YgdGhlICJpZCIgYXR0cmlidXRlIFNIT1VM RCBiZSBwZXJjZW50LWVuY29kZWQgc2luY2UNCiAgIGl0IGlzIHN1cHBvc2Vk IHRvIGJlIGhhbmRsZWQgYXMgYXJiaXRyYXJ5IGJpbmFyeSBkYXRhLg0KDQog ICBUaGUgImxpYnJhcnktdmVyc2lvbiIgYXR0cmlidXRlIHJlcHJlc2VudHMg dGhlIG1ham9yIGFuZCBtaW5vcg0KICAgdmVyc2lvbiBudW1iZXIgb2YgdGhl IGxpYnJhcnkgYW5kIGl0cyBmb3JtYXQgaXMgIk0uTiIuICBCb3RoIG51bWJl cnMNCiAgIGFyZSBvbmUgYnl0ZSBpbiBzaXplLCBzZWUgdGhlICJsaWJyYXJ5 VmVyc2lvbiIgbWVtYmVyIG9mIHRoZSBDS19JTkZPDQogICBzdHJ1Y3R1cmUg aW4gW3BrY3MxMV9zcGVjXSBmb3IgbW9yZSBpbmZvcm1hdGlvbi4gIFZhbHVl ICJNIiBmb3IgdGhlDQogICBhdHRyaWJ1dGUgTVVTVCBiZSBpbnRlcnByZXRl ZCBhcyAiTSIgZm9yIHRoZSBtYWpvciBhbmQgIjAiIGZvciB0aGUNCiAgIG1p bm9yIHZlcnNpb24gb2YgdGhlIGxpYnJhcnkuICBJZiB0aGUgYXR0cmlidXRl IGlzIHByZXNlbnQgdGhlIG1ham9yDQogICB2ZXJzaW9uIG51bWJlciBpcyBS RVFVSVJFRC4gIEJvdGggIk0iIGFuZCAiTiIgTVVTVCBiZSBkZWNpbWFsDQog ICBudW1iZXJzLg0KDQogICBTbG90IElEIGlzIGEgQ3J5cHRva2ktYXNzaWdu ZWQgbnVtYmVyIHRoYXQgaXMgbm90IGd1YXJhbnRlZWQgc3RhYmxlDQogICBh Y3Jvc3MgUEtDUyMxMSBtb2R1bGUgaW5pdGlhbGl6YXRpb25zLiAgSG93ZXZl ciwgdGhlcmUgYXJlIGNlcnRhaW4NCiAgIGxpYnJhcmllcyBhbmQgbW9kdWxl cyB3aGljaCBwcm92aWRlIHN0YWJsZSBzbG90IGlkZW50aWZpZXJzLiAgRm9y DQogICB0aGVzZSBjYXNlcywgd2hlbiB0aGUgc2xvdCBkZXNjcmlwdGlvbiBh bmQgbWFudWZhY3R1cmVyIElEIGlzIG5vdA0KICAgc3VmZmljaWVudCB0byB1 bmlxdWVseSBpZGVudGlmeSBhIHNwZWNpZmljIHJlYWRlciwgdGhlIHNsb3Qg SUQgTUFZIGJlDQogICB1c2VkIHRvIGluY3JlYXNlIHRoZSBwcmVjaXNpb24g b2YgdGhlIHRva2VuIGlkZW50aWZpY2F0aW9uLiAgSW4gb3RoZXINCiAgIHNj ZW5hcmlvcywgdXNpbmcgdGhlIHNsb3QgSURzIGlzIGxpa2VseSB0byBjYXVz ZSB1c2FiaWxpdHkgaXNzdWVzLg0KDQogICBBbiBlbXB0eSBQS0NTIzExIFVS SSBwYXRoIGF0dHJpYnV0ZSB0aGF0IGRvZXMgYWxsb3cgZm9yIGFuIGVtcHR5 DQogICB2YWx1ZSBtYXRjaGVzIGEgY29ycmVzcG9uZGluZyBzdHJ1Y3R1cmUg bWVtYmVyIG9yIGFuIG9iamVjdCBhdHRyaWJ1dGUNCiAgIHdpdGggYW4gZW1w dHkgdmFsdWUuICBOb3RlIHRoYXQgYWNjb3JkaW5nIHRvIHRoZSBQS0NTIzEx DQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVs eSA3LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAg ICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgIHNwZWNpZmljYXRpb24g W3BrY3MxMV9zcGVjXSwgZW1wdHkgY2hhcmFjdGVyIHZhbHVlcyBpbiBhIFBL Q1MjMTEgQVBJDQogICBwcm9kdWNlciBtdXN0IGJlIHBhZGRlZCB3aXRoIHNw YWNlcyBhbmQgc2hvdWxkIG5vdCBiZSBOVUxMDQogICB0ZXJtaW5hdGVkLg0K DQozLjQuICBQS0NTIzExIFVSSSBTY2hlbWUgUXVlcnkgQXR0cmlidXRlIFNl bWFudGljcw0KDQogICBBbiBhcHBsaWNhdGlvbiBNQVkgYWx3YXlzIGFzayBm b3IgYSBQSU4gYnkgYW55IG1lYW5zIGl0IGRlY2lkZXMgdG8uDQogICBXaGF0 IGlzIG1vcmUsIGluIG9yZGVyIG5vdCB0byBsaW1pdCBQS0NTIzExIFVSSSBw b3J0YWJpbGl0eSB0aGUgInBpbi0NCiAgIHNvdXJjZSIgYXR0cmlidXRlIHZh bHVlIGZvcm1hdCBhbmQgaW50ZXJwcmV0YXRpb24gaXMgbGVmdCB0byBiZQ0K ICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuICBIb3dldmVyLCB0aGUgZm9s bG93aW5nIHJ1bGVzIFNIT1VMRCBiZQ0KICAgZm9sbG93ZWQgaW4gZGVzY2Vu ZGluZyBvcmRlciBmb3IgdGhlIHZhbHVlIG9mIHRoZSAicGluLXNvdXJjZSIN CiAgIGF0dHJpYnV0ZToNCg0KICAgbyAgaWYgdGhlIHZhbHVlIHJlcHJlc2Vu dHMgYSBsb2NhbCBhYnNvbHV0ZSBwYXRoIHRoZSBpbXBsZW1lbnRhdGlvbg0K ICAgICAgU0hPVUxEIHVzZSBpdCBhcyBhIFBJTiBmaWxlIGNvbnRhaW5pbmcg dGhlIFBJTiB2YWx1ZQ0KDQogICBvICBpZiB0aGUgdmFsdWUgY29udGFpbnMg Inw8YWJzb2x1dGUtY29tbWFuZC1wYXRoPiIgdGhlDQogICAgICBpbXBsZW1l bnRhdGlvbiBTSE9VTEQgcmVhZCB0aGUgUElOIGZyb20gdGhlIG91dHB1dCBv ZiBhbg0KICAgICAgYXBwbGljYXRpb24gc3BlY2lmaWVkIHdpdGggYWJzb2x1 dGUgcGF0aCAiPGFic29sdXRlLWNvbW1hbmQtDQogICAgICBwYXRoPiIuICBO b3RlIHRoYXQgY2hhcmFjdGVyICJ8IiByZXByZXNlbnRpbmcgYSBwaXBlIGRv ZXMgbm90IGhhdmUNCiAgICAgIHRvIGJlIHBlcmNlbnQgZW5jb2RlZCBpbiB0 aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSBQS0NTIzExIFVSSS4NCg0KICAg byAgaWYgdGhlIHZhbHVlIHJlcHJlc2VudHMgYSBVUkkgaXQgU0hPVUxEIGJl IHRyZWF0ZWQgYXMgYW4gb2JqZWN0DQogICAgICBjb250YWluaW5nIHRoZSBQ SU4uICBTdWNoIGEgVVJJIG1heSBiZSAiZmlsZToiLCAiaHR0cHM6IiwgYW5v dGhlcg0KICAgICAgUEtDUyMxMSBVUkksIG9yIHNvbWV0aGluZyBlbHNlLg0K DQogICBvICBpbnRlcnByZXQgdGhlIHZhbHVlIGFzIG5lZWRlZCBpbiBhbiBp bXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQgd2F5DQoNCiAgIElmIGEgVVJJIGNv bnRhaW5zIGJvdGggInBpbi1zb3VyY2UiIGFuZCAicGluLXZhbHVlIiBxdWVy eSBhdHRyaWJ1dGVzDQogICB0aGUgVVJJIFNIT1VMRCBiZSByZWZ1c2VkIGFz IGludmFsaWQuDQoNCiAgIFVzZSBvZiB0aGUgInBpbi12YWx1ZSIgYXR0cmli dXRlIG1heSBoYXZlIHNlY3VyaXR5IHJlbGF0ZWQNCiAgIGNvbnNlcXVlbmNl cy4gIFNlY3Rpb24gNyBzaG91bGQgYmUgY29uc3VsdGVkIGJlZm9yZSB0aGlz IGF0dHJpYnV0ZSBpcw0KICAgZXZlciB1c2VkLiAgU3RhbmRhcmQgcGVyY2Vu dCBlbmNvZGluZyBydWxlcyBTSE9VTEQgYmUgZm9sbG93ZWQgZm9yDQogICB0 aGUgYXR0cmlidXRlIHZhbHVlLg0KDQogICBBIGNvbnN1bWVyIG9mIFBLQ1Mj MTEgVVJJcyBNQVkgbW9kaWZ5IGRlZmF1bHQgc2V0dGluZ3MgZm9yIGFjY2Vz c2luZw0KICAgYSBQS0NTIzExIHByb3ZpZGVyIG9yIHByb3ZpZGVycyBieSBh Y2NlcHRpbmcgcXVlcnkgY29tcG9uZW50DQogICBhdHRyaWJ1dGVzICJtb2R1 bGUtbmFtZSIgYW5kICJtb2R1bGUtcGF0aCIuIg0KDQogICBQcm9jZXNzaW5n IHRoZSBVUkkgcXVlcnkgbW9kdWxlIGF0dHJpYnV0ZXMgU0hPVUxEIGZvbGxv dyB0aGVzZSBydWxlczoNCg0KICAgbyAgYXR0cmlidXRlICJtb2R1bGUtbmFt ZSIgU0hPVUxEIGNvbnRhaW4gYSBjYXNlLWluc2Vuc2l0aXZlIFBLQ1MjMTEN CiAgICAgIG1vZHVsZSBuYW1lIChub3QgcGF0aCBub3IgZmlsZW5hbWUpIHdp dGhvdXQgc3lzdGVtIHNwZWNpZmljDQogICAgICBhZmZpeGVzLiAgU3VjaCBh ZmZpeCBjb3VsZCBiZSBhbiAiLnNvIiBvciAiLkRMTCIgc3VmZml4LCBvciBh DQogICAgICAibGliIiBwcmVmaXgsIGZvciBleGFtcGxlLiAgTm90IHVzaW5n IHN5c3RlbSBzcGVjaWZpYyBhZmZpeGVzIGlzDQogICAgICBleHBlY3RlZCB0 byBpbmNyZWFzZSBwb3J0YWJpbGl0eSBvZiBQS0NTIzExIFVSSXMgYW1vbmcg ZGlmZmVyZW50DQogICAgICBzeXN0ZW1zLiAgQSBVUkkgY29uc3VtZXIgc2Vh cmNoaW5nIGZvciBQS0NTIzExIG1vZHVsZXMgU0hPVUxEIHVzZQ0KDQoNCg0K UGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgNywgMjAx NSAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAg ICBKYW51YXJ5IDIwMTUNCg0KDQogICAgICBhIHN5c3RlbSBvciBhcHBsaWNh dGlvbiBzcGVjaWZpYyBsb2NhdGlvbnMgdG8gZmluZCBtb2R1bGVzIGJhc2Vk DQogICAgICBvbiB0aGUgbmFtZSBwcm92aWRlZCBpbiB0aGUgYXR0cmlidXRl Lg0KDQogICBvICBhdHRyaWJ1dGUgIm1vZHVsZS1wYXRoIiBTSE9VTEQgY29u dGFpbiBhIHN5c3RlbSBzcGVjaWZpYyBhYnNvbHV0ZQ0KICAgICAgcGF0aCB0 byB0aGUgUEtDUyMxMSBtb2R1bGUsIG9yIGEgc3lzdGVtIHNwZWNpZmljIGFi c29sdXRlIHBhdGggdG8NCiAgICAgIHRoZSBkaXJlY3Rvcnkgb2Ygd2hlcmUg UEtDUyMxMSBtb2R1bGVzIGFyZSBsb2NhdGVkLiAgRm9yIHNlY3VyaXR5DQog ICAgICByZWFzb25zLCBhIFVSSSB3aXRoIGEgcmVsYXRpdmUgcGF0aCBpbiB0 aGlzIGF0dHJpYnV0ZSBTSE9VTEQgYmUNCiAgICAgIHJlamVjdGVkLg0KDQog ICBvICB0aGUgVVJJIGNvbnN1bWVyIE1BWSByZWZ1c2UgdG8gYWNjZXB0IGVp dGhlciBvZiB0aGUgYXR0cmlidXRlcywgb3INCiAgICAgIGJvdGguICBJZiB1 c2Ugb2YgYW4gYXR0cmlidXRlIHByZXNlbnQgaW4gdGhlIFVSSSBzdHJpbmcg aXMgbm90DQogICAgICBhY2NlcHRlZCBhIHdhcm5pbmcgbWVzc2FnZSBTSE9V TEQgYmUgcHJlc2VudGVkIHRvIHRoZSBwcm92aWRlciBvZg0KICAgICAgdGhl IFVSSS4NCg0KICAgbyAgaWYgZWl0aGVyIG9mIHRoZSBtb2R1bGUgYXR0cmli dXRlcyBpcyBwcmVzZW50LCBvbmx5IHRob3NlIG1vZHVsZXMNCiAgICAgIGZv dW5kIG1hdGNoaW5nIHRoZXNlIHF1ZXJ5IGF0dHJpYnV0ZXMgU0hPVUxEIGJl IHVzZWQgdG8gc2VhcmNoIGZvcg0KICAgICAgYW4gZW50aXR5IHJlcHJlc2Vu dGVkIGJ5IHRoZSBVUkkuDQoNCiAgIG8gIHVzZSBvZiB0aGUgbW9kdWxlIGF0 dHJpYnV0ZXMgZG9lcyBub3Qgc3VwcHJlc3MgbWF0Y2hpbmcgb2YgYW55DQog ICAgICBvdGhlciBVUkkgcGF0aCBjb21wb25lbnQgYXR0cmlidXRlcyBwcmVz ZW50IGluIGEgVVJJLg0KDQogICBvICBzZW1hbnRpY3Mgb2YgdXNpbmcgYm90 aCBhdHRyaWJ1dGVzIGluIHRoZSBzYW1lIFVSSSBzdHJpbmcgaXMNCiAgICAg IGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGJ1dCBzdWNoIHVzZSBTSE9VTEQg YmUgYXZvaWRlZC4gIEF0dHJpYnV0ZQ0KICAgICAgIm1vZHVsZS1uYW1lIiBp cyBwcmVmZXJyZWQgdG8gIm1vZHVsZS1wYXRoIiBkdWUgdG8gaXRzIHN5c3Rl bQ0KICAgICAgaW5kZXBlbmRlbnQgbmF0dXJlIGJ1dCB0aGUgbGF0dGVyIG1h eSBiZSBtb3JlIHN1aXRhYmxlIGZvcg0KICAgICAgZGV2ZWxvcG1lbnQgYW5k IGRlYnVnZ2luZy4NCg0KICAgbyAgYSBVUkkgTVVTVCBOT1QgY29udGFpbiBt dWx0aXBsZSBtb2R1bGUgYXR0cmlidXRlcyBvZiB0aGUgc2FtZQ0KICAgICAg bmFtZS4NCg0KICAgVXNlIG9mIHRoZSBtb2R1bGUgYXR0cmlidXRlcyBtYXkg aGF2ZSBzZWN1cml0eSByZWxhdGVkIGNvbnNlcXVlbmNlcy4NCiAgIFNlY3Rp b24gNyBzaG91bGQgYmUgY29uc3VsdGVkIGJlZm9yZSB0aGVzZSBhdHRyaWJ1 dGVzIGFyZSBldmVyIHVzZWQuDQoNCiAgIEEgd29yZCAibW9kdWxlIiB3YXMg Y2hvc2VuIG92ZXIgd29yZCAibGlicmFyeSIgaW4gdGhlc2UgcXVlcnkNCiAg IGF0dHJpYnV0ZSBuYW1lcyB0byBhdm9pZCBjb25mdXNpb24gd2l0aCBzZW1h bnRpY2FsbHkgZGlmZmVyZW50DQogICBsaWJyYXJ5IGF0dHJpYnV0ZXMgdXNl ZCBpbiB0aGUgVVJJIHBhdGggY29tcG9uZW50Lg0KDQozLjUuICBQS0NTIzEx IFVSSSBNYXRjaGluZyBHdWlkZWxpbmVzDQoNCiAgIFRoZSBQS0NTIzExIFVS SSBjYW4gaWRlbnRpZnkgUEtDUyMxMSBzdG9yYWdlIG9iamVjdHMsIHRva2Vu cywgc2xvdHMsDQogICBvciBDcnlwdG9raSBsaWJyYXJpZXMuICBOb3RlIHRo YXQgc2luY2UgYSBVUkkgbWF5IGlkZW50aWZ5IGZvdXINCiAgIGRpZmZlcmVu dCB0eXBlcyBvZiBlbnRpdGllcyB0aGUgY29udGV4dCB3aXRoaW4gd2hpY2gg dGhlIFVSSSBpcyB1c2VkDQogICBtYXkgYmUgbmVlZGVkIHRvIGRldGVybWlu ZSB0aGUgdHlwZS4gIEZvciBleGFtcGxlLCBhIFVSSSB3aXRoIG9ubHkNCiAg IGxpYnJhcnkgYXR0cmlidXRlcyBtYXkgZWl0aGVyIHJlcHJlc2VudCBhbGwg b2JqZWN0cyBpbiBhbGwgdG9rZW5zIGluDQogICBhbGwgQ3J5cHRva2kgbGli cmFyaWVzIGlkZW50aWZpZWQgYnkgdGhlIFVSSSwgYWxsIHRva2VucyBpbiB0 aG9zZQ0KICAgbGlicmFyaWVzLCBvciBqdXN0IHRoZSBsaWJyYXJpZXMuDQoN Cg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1 bHkgNywgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAg ICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBUaGUgZm9sbG93aW5n IGd1aWRlbGluZXMgY2FuIGhlbHAgYSBQS0NTIzExIFVSSSBjb25zdW1lciAo ZWcuIGFuDQogICBhcHBsaWNhdGlvbiBhY2NlcHRpbmcgUEtDUyMxMSBVUklz KSB0byBtYXRjaCB0aGUgVVJJIHdpdGggdGhlIGRlc2lyZWQNCiAgIHJlc291 cmNlLg0KDQogICBvICB0aGUgY29uc3VtZXIgTVVTVCBrbm93IHdoZXRoZXIg dGhlIFVSSSBpcyB0byBpZGVudGlmeSBQS0NTIzExDQogICAgICBzdG9yYWdl IG9iamVjdChzKSwgdG9rZW4ocyksIHNsb3QocyksIG9yIENyeXB0b2tpIHBy b2R1Y2VyKHMpLg0KDQogICBvICBpZiB0aGUgY29uc3VtZXIgaXMgd2lsbGlu ZyB0byBhY2NlcHQgcXVlcnkgY29tcG9uZW50IG1vZHVsZQ0KICAgICAgYXR0 cmlidXRlcyBvbmx5IHRob3NlIFBLQ1MjMTEgcHJvdmlkZXJzIG1hdGNoaW5n IHRoZXNlIGF0dHJpYnV0ZXMNCiAgICAgIFNIT1VMRCBiZSB3b3JrZWQgd2l0 aC4gIFNlZSBTZWN0aW9uIDMuNCBmb3IgbW9yZSBpbmZvcm1hdGlvbi4NCg0K ICAgbyAgYW4gdW5yZWNvZ25pemVkIGF0dHJpYnV0ZSBpbiB0aGUgVVJJIHBh dGggY29tcG9uZW50LCBpbmNsdWRpbmcgYQ0KICAgICAgdmVuZG9yIHNwZWNp ZmljIGF0dHJpYnV0ZSwgU0hPVUxEIHJlc3VsdCBpbiBhbiBlbXB0eSBzZXQg b2YNCiAgICAgIG1hdGNoZWQgcmVzb3VyY2VzLiAgVGhlIGNvbnN1bWVyIFNI T1VMRCBjb25zaWRlciB3aGV0aGVyIGFuIGVycm9yDQogICAgICBtZXNzYWdl IHByZXNlbnRlZCB0byB0aGUgdXNlciBpcyBhcHByb3ByaWF0ZSBpbiBzdWNo IGEgY2FzZS4NCg0KICAgbyAgYW4gdW5yZWNvZ25pemVkIGF0dHJpYnV0ZSBp biB0aGUgVVJJIHF1ZXJ5IFNIT1VMRCBiZSBpZ25vcmVkLiAgVGhlDQogICAg ICBjb25zdW1lciBTSE9VTEQgY29uc2lkZXIgd2hldGhlciBhIHdhcm5pbmcg bWVzc2FnZSBwcmVzZW50ZWQgdG8NCiAgICAgIHRoZSB1c2VyIGlzIGFwcHJv cHJpYXRlIGluIHN1Y2ggYSBjYXNlLg0KDQogICBvICBhbiBhdHRyaWJ1dGUg bm90IHByZXNlbnQgaW4gdGhlIFVSSSBwYXRoIGJ1dCBrbm93biB0byBhIGNv bnN1bWVyDQogICAgICBtYXRjaGVzIGV2ZXJ5dGhpbmcuICBFYWNoIGFkZGl0 aW9uYWwgYXR0cmlidXRlIHByZXNlbnQgaW4gdGhlIFVSSQ0KICAgICAgcGF0 aCBmdXJ0aGVyIHJlc3RyaWN0cyB0aGUgc2VsZWN0aW9uLg0KDQogICBvICBh IGxvZ2ljYWwgZXh0ZW5zaW9uIG9mIHRoZSBhYm92ZSBpcyB0aGF0IGFuIGVt cHR5IFVSSSBwYXRoIG1hdGNoZXMNCiAgICAgIGV2ZXJ5dGhpbmcuICBGb3Ig ZXhhbXBsZSwgaWYgdXNlZCB0byBpZGVudGlmeSBzdG9yYWdlIG9iamVjdHMg aXQNCiAgICAgIG1hdGNoZXMgYWxsIGFjY2Vzc2libGUgb2JqZWN0cyBpbiBh bGwgdG9rZW5zIHByb3ZpZGVkIGJ5IGFsbA0KICAgICAgUEtDUyMxMSBBUEkg cHJvZHVjZXJzIGZvdW5kIGluIHRoZSBzeXN0ZW0uDQoNCiAgIG8gIG5vdGUg dGhhdCB1c2Ugb2YgUElOIGF0dHJpYnV0ZXMgbWF5IGNoYW5nZSB0aGUgc2V0 IG9mIHN0b3JhZ2UNCiAgICAgIG9iamVjdHMgdmlzaWJsZSB0byB0aGUgY29u c3VtZXIuDQoNCiAgIG8gIGluIGFkZGl0aW9uIHRvIHF1ZXJ5IGNvbXBvbmVu dCBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhpcw0KICAgICAgZG9jdW1lbnQs IHZlbmRvciBzcGVjaWZpYyBxdWVyeSBhdHRyaWJ1dGVzIG1heSBjb250YWlu IGZ1cnRoZXINCiAgICAgIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBwZXJm b3JtIHRoZSBzZWxlY3Rpb24gb3Igb3RoZXIgcmVsYXRlZA0KICAgICAgaW5m b3JtYXRpb24uDQoNCiAgIEFzIG5vdGVkIGluIFNlY3Rpb24gNiwgdGhlIFBL Q1MjMTEgc3BlY2lmaWNhdGlvbiBpcyBub3QgY2xlYXIgYWJvdXQNCiAgIGhv dyB0byBub3JtYWxpemUgVVRGLTggZW5jb2RlZCBVbmljb2RlIGNoYXJhY3Rl cnMgW1JGQzIyNzldLiAgVGhvc2UNCiAgIHdobyBkaXNjb3ZlciBhIG5lZWQg dG8gdXNlIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgQVNDSUkgcmVwZXJ0b2ly ZQ0KICAgc2hvdWxkIGJlIGNhdXRpb3VzLCBjb25zZXJ2YXRpdmUsIGFuZCBl eHBlbmQgZXh0cmEgZWZmb3J0IHRvIGJlIHN1cmUNCiAgIHRoZXkga25vdyB3 aGF0IHRoZXkgYXJlIGRvaW5nIGFuZCB0aGF0IGZhaWx1cmUgdG8gZG8gc28g bWF5IGNyZWF0ZQ0KICAgYm90aCBvcGVyYXRpb25hbCBhbmQgc2VjdXJpdHkg cmlza3MuICBJdCBtZWFucyB0aGF0IHdoZW4gbWF0Y2hpbmcNCiAgIFVURi04 IHN0cmluZyBiYXNlZCBhdHRyaWJ1dGVzIChzZWUgVGFibGUgMSkgd2l0aCBz dWNoIGNoYXJhY3RlcnMsDQogICBub3JtYWxpemluZyBhbGwgVVRGLTggc3Ry aW5ncyBiZWZvcmUgc3RyaW5nIGNvbXBhcmlzb24gbWF5IGJlIHRoZQ0KICAg b25seSBzYWZlIGFwcHJvYWNoLiAgRm9yIGV4YW1wbGUsIGZvciBvYmplY3Rz IChrZXlzKSBpdCBtZWFucyB0aGF0DQogICBQS0NTIzExIGF0dHJpYnV0ZSBz ZWFyY2ggdGVtcGxhdGUgd291bGQgb25seSBjb250YWluIGF0dHJpYnV0ZXMg dGhhdA0KICAgYXJlIG5vdCBVVEYtOCBzdHJpbmdzIGFuZCBhbm90aGVyIHBh c3MgdGhyb3VnaCByZXR1cm5lZCBvYmplY3RzIGlzDQoNCg0KDQpQZWNoYW5l YyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA3LCAyMDE1ICAgICAg ICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVh cnkgMjAxNQ0KDQoNCiAgIHRoZW4gbmVlZGVkIGZvciBVVEYtOCBzdHJpbmcg Y29tcGFyaXNvbiBhZnRlciB0aGUgbm9ybWFsaXphdGlvbiBpcw0KICAgYXBw bGllZC4NCg0KMy42LiAgUEtDUyMxMSBVUkkgQ29tcGFyaXNvbg0KDQogICBD b21wYXJpc29uIG9mIHR3byBVUklzIGlzIGEgd2F5IG9mIGRldGVybWluaW5n IHdoZXRoZXIgdGhlIFVSSXMgYXJlDQogICBlcXVpdmFsZW50IHdpdGhvdXQg Y29tcGFyaW5nIHRoZSBhY3R1YWwgcmVzb3VyY2UgdGhlIFVSSXMgcG9pbnQg dG8uDQogICBUaGUgY29tcGFyaXNvbiBvZiBVUklzIGFpbXMgdG8gbWluaW1p emUgZmFsc2UgbmVnYXRpdmVzIHdoaWxlDQogICBzdHJpY3RseSBhdm9pZGlu ZyBmYWxzZSBwb3NpdGl2ZXMuICBXaGVuIHdvcmtpbmcgd2l0aCBVVEYtOCBz dHJpbmdzDQogICB3aXRoIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgQVNDSUkg Y2hhcmFjdGVyIHNldHMsIHNlZSBpbXBvcnRhbnQNCiAgIGNhdmVhdHMgaW4g U2VjdGlvbiAzLjUgYW5kIFNlY3Rpb24gNi4NCg0KICAgVHdvIFBLQ1MjMTEg VVJJcyBhcmUgc2FpZCB0byBiZSBlcXVhbCBpZiBVUklzIGFzIGNoYXJhY3Rl ciBzdHJpbmdzDQogICBhcmUgaWRlbnRpY2FsIGFzIHNwZWNpZmllZCBpbiBT ZWN0aW9uIDYuMi4xIG9mIFtSRkMzOTg2XSwgb3IgaWYgYm90aA0KICAgZm9s bG93aW5nIHJ1bGVzIGFyZSBmdWxmaWxsZWQ6DQoNCiAgIG8gIHNldCBvZiBh dHRyaWJ1dGVzIHByZXNlbnQgaW4gdGhlIFVSSSBpcyBlcXVhbC4gIE5vdGUg dGhhdCB0aGUNCiAgICAgIG9yZGVyaW5nIG9mIGF0dHJpYnV0ZXMgaW4gdGhl IFVSSSBzdHJpbmcgaXMgbm90IHNpZ25pZmljYW50IGZvcg0KICAgICAgdGhl IG1lY2hhbmlzbSBvZiBjb21wYXJpc29uLg0KDQogICBvICB2YWx1ZXMgb2Yg cmVzcGVjdGl2ZSBhdHRyaWJ1dGVzIGFyZSBlcXVhbCBiYXNlZCBvbiBydWxl cyBzcGVjaWZpZWQNCiAgICAgIGJlbG93DQoNCiAgIFRoZSBydWxlcyBmb3Ig Y29tcGFyaW5nIHZhbHVlcyBvZiByZXNwZWN0aXZlIGF0dHJpYnV0ZXMgYXJl Og0KDQogICBvICB2YWx1ZXMgb2YgcGF0aCBjb21wb25lbnQgYXR0cmlidXRl cyAibGlicmFyeS1kZXNjcmlwdGlvbiIsDQogICAgICAibGlicmFyeS1tYW51 ZmFjdHVyZXIiLCAibWFudWZhY3R1cmVyIiwgIm1vZGVsIiwgIm9iamVjdCIs DQogICAgICAic2VyaWFsIiwgInNsb3QtZGVzY3JpcHRpb24iLCAic2xvdC1t YW51ZmFjdHVyZXIiLCAidG9rZW4iLA0KICAgICAgInR5cGUiLCBhbmQgcXVl cnkgY29tcG9uZW50IGF0dHJpYnV0ZSAibW9kdWxlLW5hbWUiIE1VU1QgYmUN CiAgICAgIGNvbXBhcmVkIHVzaW5nIGEgc2ltcGxlIHN0cmluZyBjb21wYXJp c29uIGFzIHNwZWNpZmllZCBpbg0KICAgICAgU2VjdGlvbiA2LjIuMSBvZiBb UkZDMzk4Nl0gYWZ0ZXIgdGhlIGNhc2UgYW5kIHRoZSBwZXJjZW50LWVuY29k aW5nDQogICAgICBub3JtYWxpemF0aW9uIGFyZSBib3RoIGFwcGxpZWQgYXMg c3BlY2lmaWVkIGluIFNlY3Rpb24gNi4yLjIgb2YNCiAgICAgIFtSRkMzOTg2 XS4NCg0KICAgbyAgdmFsdWUgb2YgYXR0cmlidXRlICJpZCIgTVVTVCBiZSBj b21wYXJlZCB1c2luZyB0aGUgc2ltcGxlIHN0cmluZw0KICAgICAgY29tcGFy aXNvbiBhZnRlciBhbGwgYnl0ZXMgYXJlIHBlcmNlbnQtZW5jb2RlZCB1c2lu ZyB1cHBlcmNhc2UNCiAgICAgIGxldHRlcnMgZm9yIGRpZ2l0cyBBLUYuDQoN CiAgIG8gIHZhbHVlIG9mIGF0dHJpYnV0ZSAibGlicmFyeS12ZXJzaW9uIiBN VVNUIGJlIHByb2Nlc3NlZCBhcyBhDQogICAgICBzcGVjaWZpYyBzY2hlbWUt YmFzZWQgbm9ybWFsaXphdGlvbiBwZXJtaXR0ZWQgYnkgU2VjdGlvbiA2LjIu MyBvZg0KICAgICAgW1JGQzM5ODZdLiAgVGhlIHZhbHVlIE1VU1QgYmUgc3Bs aXQgaW50byBhIG1ham9yIGFuZCBtaW5vciB2ZXJzaW9uDQogICAgICB3aXRo IGNoYXJhY3RlciAnLicgKGRvdCkgc2VydmluZyBhcyBhIGRlbGltaXRlci4g IExpYnJhcnkgdmVyc2lvbg0KICAgICAgIk0iIE1VU1QgYmUgdHJlYXRlZCBh cyAiTSIgZm9yIHRoZSBtYWpvciB2ZXJzaW9uIGFuZCAiMCIgZm9yIHRoZQ0K ICAgICAgbWlub3IgdmVyc2lvbi4gIFJlc3VsdGluZyBtaW5vciBhbmQgbWFq b3IgdmVyc2lvbiBudW1iZXJzIE1VU1QgYmUNCiAgICAgIHRoZW4gc2VwYXJh dGVseSBjb21wYXJlZCBudW1lcmljYWxseS4NCg0KDQoNCg0KDQoNClBlY2hh bmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDcsIDIwMTUgICAg ICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgICAgSmFu dWFyeSAyMDE1DQoNCg0KICAgbyAgdmFsdWUgb2YgYXR0cmlidXRlICJzbG90 LWlkIiBNVVNUIGJlIHByb2Nlc3NlZCBhcyBhIHNwZWNpZmljDQogICAgICBz Y2hlbWUtYmFzZWQgbm9ybWFsaXphdGlvbiBwZXJtaXR0ZWQgYnkgU2VjdGlv biA2LjIuMyBvZiBbUkZDMzk4Nl0NCiAgICAgIGFuZCBjb21wYXJlZCBudW1l cmljYWxseS4NCg0KICAgbyAgdmFsdWUgb2YgInBpbi1zb3VyY2UiLCBpZiBk ZWVtZWQgY29udGFpbmluZyB0aGUgZmlsZW5hbWUgd2l0aCB0aGUNCiAgICAg IFBJTiB2YWx1ZSwgTVVTVCBiZSBjb21wYXJlZCB1c2luZyB0aGUgc2ltcGxl IHN0cmluZyBjb21wYXJpc29uDQogICAgICBhZnRlciB0aGUgZnVsbCBzeW50 YXggYmFzZWQgbm9ybWFsaXphdGlvbiBhcyBzcGVjaWZpZWQgaW4NCiAgICAg IFNlY3Rpb24gNi4yLjIgb2YgW1JGQzM5ODZdIGlzIGFwcGxpZWQuICBJZiB2 YWx1ZSBvZiB0aGUgInBpbi0NCiAgICAgIHNvdXJjZSIgYXR0cmlidXRlIGlz IGJlbGlldmVkIHRvIGJlIG92ZXJsb2FkZWQgdGhlIGNhc2UgYW5kDQogICAg ICBwZXJjZW50LWVuY29kaW5nIG5vcm1hbGl6YXRpb24gU0hPVUxEIGJlIGFw cGxpZWQgYmVmb3JlIHRoZSB2YWx1ZXMNCiAgICAgIGFyZSBjb21wYXJlZCBi dXQgdGhlIGV4YWN0IG1lY2hhbmlzbSBvZiBjb21wYXJpc29uIGlzIGxlZnQg dG8gdGhlDQogICAgICBhcHBsaWNhdGlvbi4NCg0KICAgbyAgdmFsdWUgb2Yg YXR0cmlidXRlICJtb2R1bGUtcGF0aCIgTVVTVCBiZSBjb21wYXJlZCB1c2lu ZyB0aGUgc2ltcGxlDQogICAgICBzdHJpbmcgY29tcGFyaXNvbiBhZnRlciB0 aGUgZnVsbCBzeW50YXggYmFzZWQgbm9ybWFsaXphdGlvbiBhcw0KICAgICAg c3BlY2lmaWVkIGluIFNlY3Rpb24gNi4yLjIgb2YgW1JGQzM5ODZdIGlzIGFw cGxpZWQuDQoNCiAgIG8gIHdoZW4gY29tcGFyaW5nIHZlbmRvciBzcGVjaWZp YyBhdHRyaWJ1dGVzIHRoZSBjYXNlIGFuZCBwZXJjZW50LQ0KICAgICAgZW5j b2Rpbmcgbm9ybWFsaXphdGlvbiBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2 LjIuMiBvZiBbUkZDMzk4Nl0NCiAgICAgIFNIT1VMRCBiZSBhcHBsaWVkIGJl Zm9yZSB0aGUgdmFsdWVzIGFyZSBjb21wYXJlZCBidXQgdGhlIGV4YWN0DQog ICAgICBtZWNoYW5pc20gb2Ygc3VjaCBhIGNvbXBhcmlzb24gaXMgbGVmdCB0 byB0aGUgYXBwbGljYXRpb24uDQoNCjMuNy4gIEdlbmVyYXRpbmcgUEtDUyMx MSBVUklzDQoNCiAgIFdoZW4gZ2VuZXJhdGluZyBVUklzIGZvciBQS0NTIzEx IHJlc291cmNlcyB0aGUgZXhhY3Qgc2V0IG9mDQogICBhdHRyaWJ1dGVzIHVz ZWQgaW4gYSBVUkkgaXMgaW5oZXJlbnRseSBjb250ZXh0IHNwZWNpZmljLiAg QSBQS0NTIzExDQogICBVUkkgdGVtcGxhdGUgW1JGQzY1NzBdIHN1cHBvcnQg TUFZIGJlIHByb3ZpZGVkIGJ5IGEgVVJJIGdlbmVyYXRpbmcNCiAgIGFwcGxp Y2F0aW9uIHRvIGxpc3QgVVJJcyB0byBhY2Nlc3MgdGhlIHNhbWUgcmVzb3Vy Y2UocykgYWdhaW4gaWYgdGhlDQogICB0ZW1wbGF0ZSBjYXB0dXJlZCB0aGUg bmVjZXNzYXJ5IGNvbnRleHQuDQoNCjQuICBFeGFtcGxlcyBvZiBQS0NTIzEx IFVSSXMNCg0KICAgVGhpcyBzZWN0aW9uIGNvbnRhaW5zIHNvbWUgZXhhbXBs ZXMgb2YgaG93IFBLQ1MjMTEgdG9rZW4gb2JqZWN0cywNCiAgIHRva2Vucywg c2xvdHMsIGFuZCBsaWJyYXJpZXMgY2FuIGJlIGlkZW50aWZpZWQgdXNpbmcg dGhlIFBLQ1MjMTEgVVJJDQogICBzY2hlbWUuICBOb3RlIHRoYXQgaW4gc29t ZSBvZiB0aGUgZm9sbG93aW5nIGV4YW1wbGVzLCBuZXdsaW5lcyBhbmQNCiAg IHNwYWNlcyB3ZXJlIGluc2VydGVkIGZvciBiZXR0ZXIgcmVhZGFiaWxpdHku ICBBcyBzcGVjaWZpZWQgaW4NCiAgIEFwcGVuZGl4IEMgb2YgW1JGQzM5ODZd LCB3aGl0ZXNwYWNlIFNIT1VMRCBiZSBpZ25vcmVkIHdoZW4gZXh0cmFjdGlu Zw0KICAgdGhlIFVSSS4gIEFsc28gbm90ZSB0aGF0IGFsbCBzcGFjZXMgYXMg cGFydCBvZiB0aGUgVVJJIGFyZSBwZXJjZW50LQ0KICAgZW5jb2RlZCwgYXMg c3BlY2lmaWVkIGluIEFwcGVuZGl4IEEgb2YgW1JGQzM5ODZdLg0KDQogICBB biBlbXB0eSBQS0NTIzExIFVSSSBtaWdodCBiZSB1c2VmdWwgdG8gUEtDUyMx MSBjb25zdW1lcnMuICBTZWUNCiAgIFNlY3Rpb24gMy41IGZvciBtb3JlIGlu Zm9ybWF0aW9uIG9uIHNlbWFudGljcyBvZiBzdWNoIGEgVVJJLg0KDQogICAg IHBrY3MxMToNCg0KDQoNCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAg ICAgICBFeHBpcmVzIEp1bHkgNywgMjAxNSAgICAgICAgICAgICAgICAgW1Bh Z2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1Mj MTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQog ICBPbmUgb2YgdGhlIHNpbXBsZXN0IGFuZCBtb3N0IHVzZWZ1bCBmb3JtcyBt aWdodCBiZSBhIFBLQ1MjMTEgVVJJIHRoYXQNCiAgIHNwZWNpZmllcyBvbmx5 IGFuIG9iamVjdCBsYWJlbCBhbmQgaXRzIHR5cGUuICBUaGUgZGVmYXVsdCB0 b2tlbiBpcw0KICAgdXNlZCBzbyB0aGUgVVJJIGRvZXMgbm90IHNwZWNpZnkg aXQuICBOb3RlIHRoYXQgd2hlbiBzcGVjaWZ5aW5nDQogICBwdWJsaWMgb2Jq ZWN0cywgYSB0b2tlbiBQSU4gbWF5IG5vdCBiZSByZXF1aXJlZC4NCg0KICAg ICBwa2NzMTE6b2JqZWN0PW15LXB1YmtleTt0eXBlPXB1YmxpYw0KDQogICBX aGVuIGEgcHJpdmF0ZSBrZXkgaXMgc3BlY2lmaWVkIGVpdGhlciB0aGUgInBp bi1zb3VyY2UiIGF0dHJpYnV0ZSwNCiAgICJwaW4tdmFsdWUsIG9yIGFuIGFw cGxpY2F0aW9uIHNwZWNpZmljIG1ldGhvZCB3b3VsZCBiZSB1c3VhbGx5IHVz ZWQuDQogICBOb3RlIHRoYXQgJy8nIGlzIG5vdCBwZXJjZW50LWVuY29kZWQg aW4gdGhlICJwaW4tc291cmNlIiBhdHRyaWJ1dGUNCiAgIHZhbHVlIHNpbmNl IHRoaXMgYXR0cmlidXRlIGlzIHBhcnQgb2YgdGhlIHF1ZXJ5IGNvbXBvbmVu dCwgbm90IHRoZQ0KICAgcGF0aCwgYW5kIHRodXMgaXMgc2VwYXJhdGVkIGJ5 ICc/JyBmcm9tIHRoZSByZXN0IG9mIHRoZSBVUkkuDQoNCiAgICAgcGtjczEx Om9iamVjdD1teS1rZXk7dHlwZT1wcml2YXRlP3Bpbi1zb3VyY2U9L2V0Yy90 b2tlbg0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWRlbnRpZmllcyBh IGNlcnRpZmljYXRlIGluIHRoZSBzb2Z0d2FyZSB0b2tlbi4NCiAgIE5vdGUg YW4gZW1wdHkgdmFsdWUgZm9yIHRoZSBhdHRyaWJ1dGUgInNlcmlhbCIgd2hp Y2ggbWF0Y2hlcyBvbmx5DQogICBlbXB0eSAic2VyaWFsTnVtYmVyIiBtZW1i ZXIgb2YgdGhlICJDS19UT0tFTl9JTkZPIiBzdHJ1Y3R1cmUuICBBbHNvDQog ICBub3RlIHRoYXQgdGhlICJpZCIgYXR0cmlidXRlIHZhbHVlIGlzIGVudGly ZWx5IHBlcmNlbnQtZW5jb2RlZCwgYXMNCiAgIHJlY29tbWVuZGVkLiAgV2hp bGUgJywnIGlzIGluIHRoZSByZXNlcnZlZCBzZXQgaXQgZG9lcyBub3QgaGF2 ZSB0byBiZQ0KICAgcGVyY2VudC1lbmNvZGVkIHNpbmNlIGl0IGRvZXMgbm90 IGNvbmZsaWN0IHdpdGggYW55IHN1Yi1kZWxpbWl0ZXJzDQogICB1c2VkLiAg VGhlICcjJyBjaGFyYWN0ZXIgYXMgaW4gIlRoZSBTb2Z0d2FyZSBQS0NTIzEx IFNvZnR0b2tlbiIgTVVTVA0KICAgYmUgcGVyY2VudC1lbmNvZGVkLg0KDQog ICAgIHBrY3MxMTp0b2tlbj1UaGUlMjBTb2Z0d2FyZSUyMFBLQ1MlMjMxMSUy MFNvZnR0b2tlbjsNCiAgICAgICAgICAgIG1hbnVmYWN0dXJlcj1TbmFrZSUy ME9pbCwlMjBJbmMuOw0KICAgICAgICAgICAgbW9kZWw9MS4wOw0KICAgICAg ICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0KICAgICAgICAgICAgdHlw ZT1jZXJ0Ow0KICAgICAgICAgICAgaWQ9JTY5JTk1JTNFJTVDJUY0JUJEJUVD JTkxOw0KICAgICAgICAgICAgc2VyaWFsPQ0KICAgICAgICAgICAgP3Bpbi1z b3VyY2U9L2V0Yy90b2tlbl9waW4NCg0KICAgVGhlIG5leHQgZXhhbXBsZSBj b3ZlcnMgaG93IHRvIHVzZSB0aGUgIm1vZHVsZS1uYW1lIiBxdWVyeSBhdHRy aWJ1dGUuDQogICBDb25zaWRlcmluZyB0aGF0IHRoZSBtb2R1bGUgaXMgbG9j YXRlZCBpbiAvdXNyL2xpYi9saWJteXBrY3MxMS5zby4xDQogICBmaWxlLCB0 aGUgYXR0cmlidXRlIHZhbHVlIGlzICJteXBrY3MxMSIsIG1lYW5pbmcgb25s eSB0aGUgbW9kdWxlIG5hbWUNCiAgIHdpdGhvdXQgdGhlIGZ1bGwgcGF0aCwg YW5kIHdpdGhvdXQgdGhlIHBsYXRmb3JtIHNwZWNpZmljICJsaWIiIHByZWZp eA0KICAgYW5kICIuc28uMSIgc3VmZml4Lg0KDQogICAgIHBrY3MxMTpvYmpl Y3Q9bXktc2lnbi1rZXk7DQogICAgICAgICAgICB0eXBlPXByaXZhdGUNCiAg ICAgICAgICAgID9tb2R1bGUtbmFtZT1teXBrY3MxMQ0KDQoNCg0KDQoNCg0K DQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkg NywgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAg ICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBUaGUgZm9sbG93aW5nIGV4 YW1wbGUgY292ZXJzIGhvdyB0byB1c2UgdGhlICJtb2R1bGUtcGF0aCIgcXVl cnkNCiAgIGF0dHJpYnV0ZS4gIFRoZSBhdHRyaWJ1dGUgbWF5IGJlIHVzZWZ1 bCBpZiBhIHVzZXIgbmVlZHMgdG8gcHJvdmlkZQ0KICAgdGhlIGtleSB2aWEg YSBQS0NTIzExIG1vZHVsZSBzdG9yZWQgb24gYSByZW1vdmFibGUgbWVkaWEs IGZvcg0KICAgZXhhbXBsZS4gIEdldHRpbmcgdGhlIFBJTiB0byBhY2Nlc3Mg dGhlIHByaXZhdGUga2V5IGhlcmUgaXMgbGVmdCB0bw0KICAgYmUgYXBwbGlj YXRpb24gc3BlY2lmaWMuDQoNCiAgICAgcGtjczExOm9iamVjdD1teS1zaWdu LWtleTsNCiAgICAgICAgICAgIHR5cGU9cHJpdmF0ZQ0KICAgICAgICAgICAg P21vZHVsZS1wYXRoPS9tbnQvbGlibXlwa2NzMTEuc28uMQ0KDQogICBJbiB0 aGUgY29udGV4dCB3aGVyZSBhIHRva2VuIGlzIGV4cGVjdGVkIHRoZSB0b2tl biBjYW4gYmUgaWRlbnRpZmllZA0KICAgd2l0aG91dCBzcGVjaWZ5aW5nIGFu eSBQS0NTIzExIG9iamVjdHMuICBBIFBJTiBtaWdodCBzdGlsbCBiZSBuZWVk ZWQNCiAgIGluIHRoZSBjb250ZXh0IG9mIGxpc3RpbmcgYWxsIG9iamVjdHMg aW4gdGhlIHRva2VuLCBmb3IgZXhhbXBsZS4NCiAgIFNlY3Rpb24gNyBzaG91 bGQgYmUgY29uc3VsdGVkIGJlZm9yZSB0aGUgInBpbi12YWx1ZSIgYXR0cmli dXRlIGlzDQogICBldmVyIHVzZWQuDQoNCiAgICAgcGtjczExOnRva2VuPVNv ZnR3YXJlJTIwUEtDUyUyMzExJTIwc29mdHRva2VuOw0KICAgICAgICAgICAg bWFudWZhY3R1cmVyPVNuYWtlJTIwT2lsLCUyMEluYy4NCiAgICAgICAgICAg ID9waW4tdmFsdWU9dGhlLXBpbg0KDQogICBJbiB0aGUgY29udGV4dCB3aGVy ZSBhIHNsb3QgaXMgZXhwZWN0ZWQgdGhlIHNsb3QgY2FuIGJlIGlkZW50aWZp ZWQNCiAgIHdpdGhvdXQgc3BlY2lmeWluZyBhbnkgUEtDUyMxMSBvYmplY3Rz IGluIGFueSB0b2tlbiBpdCBtYXkgYmUNCiAgIGluc2VydGVkIGluIGl0Lg0K DQogICAgIHBrY3MxMTpzbG90LWRlc2NyaXB0aW9uPVN1biUyME1ldGFzbG90 DQoNCiAgIFRoZSBDcnlwdG9raSBsaWJyYXJ5IGFsb25lIGNhbiBiZSBhbHNv IGlkZW50aWZpZWQgd2l0aG91dCBzcGVjaWZ5aW5nDQogICBhIFBLQ1MjMTEg dG9rZW4gb3Igb2JqZWN0Lg0KDQogICAgIHBrY3MxMTpsaWJyYXJ5LW1hbnVm YWN0dXJlcj1TbmFrZSUyME9pbCwlMjBJbmMuOw0KICAgICAgICAgICAgbGli cmFyeS1kZXNjcmlwdGlvbj1Tb2Z0JTIwVG9rZW4lMjBMaWJyYXJ5Ow0KICAg ICAgICAgICAgbGlicmFyeS12ZXJzaW9uPTEuMjMNCg0KICAgVGhlIGZvbGxv d2luZyBleGFtcGxlIHNob3dzIGFuIGF0dHJpYnV0ZSB2YWx1ZSB3aXRoIGEg c2VtaWNvbG9uLiAgSW4NCiAgIHN1Y2ggY2FzZSBpdCBNVVNUIGJlIHBlcmNl bnQtZW5jb2RlZC4gIFRoZSB0b2tlbiBhdHRyaWJ1dGUgdmFsdWUgTVVTVA0K ICAgYmUgcmVhZCBhcyAiTXkgdG9rZW47IGNyZWF0ZWQgYnkgSm9lIi4gIExv d2VyIGNhc2UgbGV0dGVycyBNQVkgYmUNCiAgIHVzZWQgaW4gcGVyY2VudC1l bmNvZGluZyBhcyBzaG93biBiZWxvdyBpbiB0aGUgImlkIiBhdHRyaWJ1dGUg dmFsdWUNCiAgIGJ1dCBub3RlIHRoYXQgU2VjdGlvbnMgMi4xIGFuZCA2LjIu Mi4xIG9mIFtSRkMzOTg2XSByZWFkIHRoYXQgYWxsDQogICBwZXJjZW50LWVu Y29kZWQgY2hhcmFjdGVycyBTSE9VTEQgdXNlIHRoZSB1cHBlcmNhc2UgaGV4 YWRlY2ltYWwNCiAgIGRpZ2l0cy4gIE1vcmUgc3BlY2lmaWNhbGx5LCBpZiB0 aGUgVVJJIHN0cmluZyB3YXMgdG8gYmUgY29tcGFyZWQgdGhlDQogICBhbGdv cml0aG0gZGVmaW5lZCBpbiBTZWN0aW9uIDMuNiBleHBsaWNpdGx5IHJlcXVp cmVzIHBlcmNlbnQtZW5jb2RpbmcNCiAgIHRvIHVzZSB0aGUgdXBwZXJjYXNl IGRpZ2l0cyBBLUYgaW4gdGhlICJpZCIgYXR0cmlidXRlIHZhbHVlcy4gIEFu ZCBhcw0KICAgZXhwbGFpbmVkIGluIFNlY3Rpb24gMy4zLCBsaWJyYXJ5IHZl cnNpb24gIjMiIE1VU1QgYmUgaW50ZXJwcmV0ZWQgYXMNCiAgICIzIiBmb3Ig dGhlIG1ham9yIGFuZCAiMCIgZm9yIHRoZSBtaW5vciB2ZXJzaW9uIG9mIHRo ZSBsaWJyYXJ5Lg0KDQogICAgIHBrY3MxMTp0b2tlbj1NeSUyMHRva2VuJTI1 JTIwY3JlYXRlZCUyMGJ5JTIwSm9lOw0KICAgICAgICAgICAgbGlicmFyeS12 ZXJzaW9uPTM7DQogICAgICAgICAgICBpZD0lMDElMDIlMDMlQmElZGQlQ2El ZmUlMDQlMDUlMDYNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAg RXhwaXJlcyBKdWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE1 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVS SSBTY2hlbWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgSWYg dGhlcmUgaXMgYW55IG5lZWQgdG8gaW5jbHVkZSBsaXRlcmFsICIlOyIgc3Vi c3RyaW5nLCBmb3IgZXhhbXBsZSwNCiAgIGJvdGggY2hhcmFjdGVycyBNVVNU IGJlIGVzY2FwZWQuICBUaGUgdG9rZW4gdmFsdWUgTVVTVCBiZSByZWFkIGFz ICJBDQogICBuYW1lIHdpdGggYSBzdWJzdHJpbmcgJTsiLg0KDQogICAgIHBr Y3MxMTp0b2tlbj1BJTIwbmFtZSUyMHdpdGglMjBhJTIwc3Vic3RyaW5nJTIw JTI1JTNCOw0KICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0K ICAgICAgICAgICAgdHlwZT1jZXJ0DQoNCiAgIFRoZSBuZXh0IGV4YW1wbGUg aW5jbHVkZXMgYSBzbWFsbCBBIHdpdGggYWN1dGUgaW4gdGhlIHRva2VuIG5h bWUuICBJdA0KICAgTVVTVCBiZSBlbmNvZGVkIGluIG9jdGV0cyBhY2NvcmRp bmcgdG8gdGhlIFVURi04IGNoYXJhY3RlciBlbmNvZGluZw0KICAgYW5kIHRo ZW4gcGVyY2VudC1lbmNvZGVkLiAgR2l2ZW4gdGhhdCBhIHNtYWxsIEEgd2l0 aCBhY3V0ZSBpcyBVKzIyNQ0KICAgdW5pY29kZSBjb2RlIHBvaW50LCB0aGUg VVRGLTggZW5jb2RpbmcgaXMgMTk1IDE2MSBpbiBkZWNpbWFsLCBhbmQNCiAg IHRoYXQgaXMgIiVDMyVBMSIgaW4gcGVyY2VudC1lbmNvZGluZy4NCg0KICAg ICBwa2NzMTE6dG9rZW49TmFtZSUyMHdpdGglMjBhJTIwc21hbGwlMjBBJTIw d2l0aCUyMGFjdXRlOiUyMCVDMyVBMTsNCiAgICAgICAgICAgIG9iamVjdD1t eS1jZXJ0aWZpY2F0ZTsNCiAgICAgICAgICAgIHR5cGU9Y2VydA0KDQogICBC b3RoIHRoZSBwYXRoIGFuZCBxdWVyeSBjb21wb25lbnRzIE1BWSBjb250YWlu IHZlbmRvciBzcGVjaWZpYw0KICAgYXR0cmlidXRlcy4gIEF0dHJpYnV0ZXMg aW4gdGhlIHF1ZXJ5IGNvbXBvbmVudCBNVVNUIGJlIGRlbGltaXRlZCBieQ0K ICAgJyYnLg0KDQogICAgIHBrY3MxMTp0b2tlbj1teS10b2tlbjsNCiAgICAg ICAgICAgIG9iamVjdD1teS1jZXJ0aWZpY2F0ZTsNCiAgICAgICAgICAgIHR5 cGU9Y2VydDsNCiAgICAgICAgICAgIHZlbmRvci1hYWE9dmFsdWUtYQ0KICAg ICAgICAgICAgP3Bpbi1zb3VyY2U9L2V0Yy90b2tlbl9waW4NCiAgICAgICAg ICAgICZ2ZW5kb3ItYmJiPXZhbHVlLWINCg0KNS4gIElBTkEgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBtb3ZlcyB0aGUgInBrY3MxMSIg VVJJIHNjaGVtZSBmcm9tIHRoZSBwcm92aXNpb25hbCB0bw0KICAgcGVybWFu ZW50IFVSSSBzY2hlbWUgcmVnaXN0cnkuDQoNCiAgIFRoZSByZWdpc3RyYXRp b24gdGVtcGxhdGUgaXMgYXMgZm9sbG93czoNCg0KICAgICAgVVJJIHNjaGVt ZSBuYW1lOiBwa2NzMTENCg0KICAgICAgVVJJIHNjaGVtZSBzdGF0dXM6IHBl cm1hbmVudA0KDQogICAgICBVUkkgc2NoZW1lIHN5bnRheDogc2VlIFNlY3Rp b24gMy4zDQoNCiAgICAgIFVSSSBzY2hlbWUgc2VtYW50aWNzOiBzZWUgU2Vj dGlvbiAxDQoNCiAgICAgIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zOiBzZWUg U2VjdGlvbiAzLjMNCg0KICAgICAgQXBwbGljYXRpb25zL3Byb3RvY29scyB0 aGF0IHVzZSB0aGlzIFVSSSBzY2hlbWUgbmFtZTogZm9yIGdlbmVyYWwNCiAg ICAgIGluZm9ybWF0aW9uLCBzZWUgU2VjdGlvbiAxLiAgTGlzdCBvZiBrbm93 biBjb25zdW1lcnMgb2YgdGhlDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSA3LCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoN CiAgICAgIFBLQ1MjMTEgVVJJIGluY2x1ZGUgR251VExTLCBHbm9tZSwgcDEx LWtpdCwgU29sYXJpcyAxMSBhbmQgaGlnaGVyLA0KICAgICAgT3BlblNDLCBP cGVuQ29ubmVjdCwgYW5kIEZyZWVJUEEuDQoNCiAgICAgIEludGVyb3BlcmFi aWxpdHkgY29uc2lkZXJhdGlvbnM6IE4vQQ0KDQogICAgICBTZWN1cml0eSBj b25zaWRlcmF0aW9uczogc2VlIFNlY3Rpb24gNw0KDQogICAgICBDb250YWN0 OiBzZWUgQXV0aG9ycycgQWRkcmVzc2VzIHNlY3Rpb24NCg0KICAgICAgQXV0 aG9yL0NoYW5nZSBDb250cm9sbGVyOiBzZWUgQXV0aG9ycycgQWRkcmVzc2Vz IHNlY3Rpb24NCg0KICAgICAgUmVmZXJlbmNlczogc2VlIFJlZmVyZW5jZXMg c2VjdGlvbg0KDQo2LiAgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBkb2VzIG5v dCBzcGVjaWZ5IGEgY2Fub25pY2FsIGZvcm0gZm9yDQogICBzdHJpbmdzIG9m IGNoYXJhY3RlcnMgb2YgdGhlIENLX1VURjhDSEFSIHR5cGUuICBUaGlzIHBy ZXNlbnRzIHRoZQ0KICAgdXN1YWwgZmFsc2UgbmVnYXRpdmUgYW5kIGZhbHNl IHBvc2l0aXZlIChhbGlhc2luZykgY29uY2VybnMgdGhhdA0KICAgYXJpc2Ug d2hlbiBkZWFsaW5nIHdpdGggdW5ub3JtYWxpemVkIHN0cmluZ3MuICBCZWNh dXNlIGFsbCBQS0NTIzExDQogICBpdGVtcyBhcmUgbG9jYWwgYW5kIGxvY2Fs IHNlY3VyaXR5IGlzIGFzc3VtZWQsIHRoZXNlIGNvbmNlcm5zIGFyZQ0KICAg bWFpbmx5IGFib3V0IHVzYWJpbGl0eS4NCg0KICAgSW4gb3JkZXIgdG8gaW1w cm92ZSB0aGUgdXNlciBleHBlcmllbmNlLCBhcHBsaWNhdGlvbnMgdGhhdCBj cmVhdGUNCiAgIFBLQ1MjMTEgb2JqZWN0cyBvciBsYWJlbCB0b2tlbnMsIFNI T1VMRCBub3JtYWxpemUgbGFiZWxzIHRvIE5GQy4gIEZvcg0KICAgdGhlIHNh bWUgcmVhc29uIFBLQ1MjMTEgbGlicmFyaWVzLCBzbG90cyAodG9rZW4gcmVh ZGVycyksIGFuZCB0b2tlbnMNCiAgIFNIT1VMRCBub3JtYWxpemUgdGhlaXIg bmFtZXMgdG8gTkZDLiAgV2hlbiBsaXN0aW5nIFBLQ1MjMTEgbGlicmFyaWVz LA0KICAgc2xvdHMsIHRva2VucywgYW5kL29yIG9iamVjdHMsIGFuIGFwcGxp Y2F0aW9uIFNIT1VMRCBub3JtYWxpemUgdGhlaXINCiAgIG5hbWVzIHRvIE5G Qy4gIFdoZW4gbWF0Y2hpbmcgUEtDUyMxMSBVUklzIHRvIGxpYnJhcmllcywg c2xvdHMsDQogICB0b2tlbnMsIGFuZC9vciBvYmplY3RzLCBhcHBsaWNhdGlv bnMgTUFZIHVzZSBmb3JtLWluc2Vuc2l0aXZlIFVuaWNvZGUNCiAgIHN0cmlu ZyBjb21wYXJpc29uIGZvciBtYXRjaGluZywgYXMgdGhvc2UgbWlnaHQgcHJl LWRhdGUgdGhlc2UNCiAgIHJlY29tbWVuZGF0aW9ucy4gIFNlZSBhbHNvIFNl Y3Rpb24gMy41Lg0KDQo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K ICAgVGhlcmUgYXJlIGdlbmVyYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg Zm9yIFVSSSBzY2hlbWVzIGRpc2N1c3NlZA0KICAgaW4gU2VjdGlvbiA3IG9m IFtSRkMzOTg2XS4NCg0KICAgRnJvbSB0aG9zZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucywgU2VjdGlvbiA3LjEgb2YgW1JGQzM5ODZdIGFwcGxpZXMNCiAg IHNpbmNlIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBzYW1lIFBL Q1MjMTEgVVJJIHdpbGwgYWx3YXlzDQogICBpZGVudGlmeSB0aGUgc2FtZSBv YmplY3QsIHRva2VuLCBzbG90LCBvciBhIGxpYnJhcnkgaW4gdGhlIGZ1dHVy ZS4NCg0KICAgU2VjdGlvbiA3LjIgb2YgW1JGQzM5ODZdIGFwcGxpZXMgc2lu Y2UgYnkgYWNjZXB0aW5nIHF1ZXJ5IGNvbXBvbmVudA0KICAgYXR0cmlidXRl cyAibW9kdWxlLW5hbWUiIG9yICJtb2R1bGUtcGF0aCIgdGhlIGNvbnN1bWVy IHBvdGVudGlhbGx5DQogICBhbGxvd3MgbG9hZGluZyBvZiBhcmJpdHJhcnkg Y29kZSBpbnRvIGEgcHJvY2Vzcy4NCg0KICAgU2VjdGlvbiA3LjUgb2YgW1JG QzM5ODZdIGFwcGxpZXMgc2luY2UgdGhlIFBLQ1MjMTEgVVJJIG1heSBiZSB1 c2VkIGluDQogICB3b3JsZCByZWFkYWJsZSBjb21tYW5kIGxpbmUgYXJndW1l bnRzIHRvIHJ1biBhcHBsaWNhdGlvbnMsIHN0b3JlZCBpbg0KICAgcHVibGlj IGNvbmZpZ3VyYXRpb24gZmlsZXMsIG9yIG90aGVyd2lzZSB1c2VkIGluIGNs ZWFyIHRleHQuICBGb3INCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAg ICAgRXhwaXJlcyBKdWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdl IDE3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzEx IFVSSSBTY2hlbWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAg dGhhdCByZWFzb24gdGhlICJwaW4tdmFsdWUiIGF0dHJpYnV0ZSBzaG91bGQg b25seSBiZSB1c2VkIGlmIHRoZSBVUkkNCiAgIHN0cmluZyBpdHNlbGYgaXMg cHJvdGVjdGVkIHdpdGggdGhlIHNhbWUgbGV2ZWwgb2Ygc2VjdXJpdHkgYXMg dGhlDQogICB0b2tlbiBQSU4gaXRzZWxmIG90aGVyd2lzZSBpcy4NCg0KICAg VGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcm92aWRlIG1l YW5zIHRvIGF1dGhlbnRpY2F0ZQ0KICAgZGV2aWNlcyB0byB1c2VyczsgaXQg b25seSBhbGxvd3MgdG8gYXV0aGVudGljYXRlIHVzZXJzIHRvIHRva2Vucy4N CiAgIEluc3RlYWQsIGxvY2FsIGFuZCBwaHlzaWNhbCBzZWN1cml0eSBhcmUg ZGVtYW5kZWQ6IHRoZSB1c2VyIG11c3QgYmUNCiAgIGluIHBvc3Nlc3Npb24g b2YgdGhlaXIgdG9rZW5zLCBhbmQgc3lzdGVtIGludG8gd2hvc2Ugc2xvdHMg dGhlIHVzZXJzJw0KICAgdG9rZW5zIGFyZSBpbnNlcnRlZCBtdXN0IGJlIHNl Y3VyZS4gIEFzIGEgcmVzdWx0LCB0aGUgdXN1YWwgc2VjdXJpdHkNCiAgIGNv bnNpZGVyYXRpb25zIHJlZ2FyZGluZyBub3JtYWxpemF0aW9uIGRvIG5vdCBh cmlzZS4gIEZvciB0aGUgc2FtZQ0KICAgcmVhc29uLCBjb25mdXNhYmxlIHNj cmlwdCBpc3N1ZXMgYWxzbyBkbyBub3QgYXJpc2UuICBOb25ldGhlbGVzcywg aXQNCiAgIGlzIGJlc3QgdG8gbm9ybWFsaXplIHRvIE5GQyBhbGwgc3RyaW5n cyBhcHBlYXJpbmcgaW4gUEtDUyMxMSBBUEkNCiAgIGVsZW1lbnRzLiAgU2Vl IGFsc28gU2VjdGlvbiA2Lg0KDQo4LiAgUmVmZXJlbmNlcw0KDQo4LjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0K ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOSwg U1REIDE0LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMzYyOV0gIFllcmdlYXUs IEYuLCAiVVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTw0K ICAgICAgICAgICAgICAxMDY0NiIsIFJGQyAzNjI5LCBTVEQgNjMsIE5vdmVt YmVyIDIwMDMuDQoNCiAgIFtSRkMzOTg2XSAgQmVybmVycy1MZWUsIFQuLCBG aWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0NCiAgICAg ICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBT eW50YXgiLCBSRkMgMzk4NiwgU1REDQogICAgICAgICAgICAgIDY2LCBKYW51 YXJ5IDIwMDUuDQoNCiAgIFtSRkM1MjM0XSAgQ3JvY2tlciwgRC4gYW5kIFAu IE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgNCiAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNTIzNCwgU1REIDY4 LCBKYW51YXJ5IDIwMDguDQoNCjguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMNCg0KICAgW0JDUDE3OF0gICBTYWludC1BbmRyZSwgUC4sIENyb2NrZXIs IEQuLCBhbmQgTS4gTm90dGluZ2hhbSwNCiAgICAgICAgICAgICAgIkRlcHJl Y2F0aW5nIHRoZSAiWC0iIFByZWZpeCBhbmQgU2ltaWxhciBDb25zdHJ1Y3Rz IGluDQogICAgICAgICAgICAgIEFwcGxpY2F0aW9uIFByb3RvY29scyIsIFJG QyA2NjQ4LCBCQ1AgMTc4LCBKdW5lIDIwMTIuDQoNCiAgIFtSRkMyMjc5XSAg WWVyZ2VhdSwgRi4sICJVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQg b2YgSVNPDQogICAgICAgICAgICAgIDEwNjQ2IiwgUkZDIDIyNzksIEphbnVh cnkgMTk5OC4NCg0KICAgW1JGQzM5ODddICBEdWVyc3QsIE0uIGFuZCBNLiBT dWlnbmFyZCwgIkludGVybmF0aW9uYWxpemVkIFJlc291cmNlDQogICAgICAg ICAgICAgIElkZW50aWZpZXJzIChJUklzKSIsIFJGQyAzOTg3LCBKYW51YXJ5 IDIwMDUuDQoNCiAgIFtSRkM0Mzk1XSAgSGFuc2VuLCBULiwgSGFyZGllLCBU LiwgYW5kIEwuIE1hc2ludGVyLCAiR3VpZGVsaW5lcyBhbmQNCiAgICAgICAg ICAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgZm9yIE5ldyBVUkkgU2No ZW1lcyIsIFJGQyA0Mzk1LA0KICAgICAgICAgICAgICBGZWJydWFyeSAyMDA2 Lg0KDQoNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJl cyBKdWx5IDcsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hl bWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgW1JGQzY1NzBd ICBHcmVnb3JpbywgSi4sIEZpZWxkaW5nLCBSLiwgSGFkbGV5LCBNLiwgTm90 dGluZ2hhbSwgTS4sDQogICAgICAgICAgICAgIGFuZCBELiBPcmNoYXJkLCAi VVJJIFRlbXBsYXRlIiwgUkZDIDY1NzAsIE1hcmNoIDIwMTIuDQoNCiAgIFtw a2NzMTFfc3BlY10NCiAgICAgICAgICAgICAgUlNBIExhYm9yYXRvcmllcywg IlBLQ1MgIzExOiBDcnlwdG9ncmFwaGljIFRva2VuIEludGVyZmFjZQ0KICAg ICAgICAgICAgICBTdGFuZGFyZCB2Mi4yMCIsIEp1bmUgMjAwNC4NCg0KQXV0 aG9ycycgQWRkcmVzc2VzDQoNCiAgIEphbiBQZWNoYW5lYw0KICAgT3JhY2xl IENvcnBvcmF0aW9uDQogICA0MTgwIE5ldHdvcmsgQ2lyY2xlDQogICBTYW50 YSBDbGFyYSAgQ0EgOTUwNTQNCiAgIFVTQQ0KDQogICBFbWFpbDogSmFuLlBl Y2hhbmVjQE9yYWNsZS5DT00NCiAgIFVSSTogICBodHRwOi8vd3d3Lm9yYWNs ZS5jb20NCg0KDQogICBEYXJyZW4gSi4gTW9mZmF0DQogICBPcmFjbGUgQ29y cG9yYXRpb24NCiAgIE9yYWNsZSBQYXJrd2F5DQogICBUaGFtZXMgVmFsbGV5 IFBhcmsNCiAgIFJlYWRpbmcgIFJHNiAxUkENCiAgIFVLDQoNCiAgIEVtYWls OiBEYXJyZW4uTW9mZmF0QE9yYWNsZS5DT00NCiAgIFVSSTogICBodHRwOi8v d3d3Lm9yYWNsZS5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4 cGlyZXMgSnVseSA3LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxOV0N Cg== ---559023410-586517042-1420350762=:6923-- From nobody Sat Jan 3 23:55:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB6E1A6FFC for ; Sat, 3 Jan 2015 23:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9l2CrZpRBMT for ; Sat, 3 Jan 2015 23:55:11 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1481A6FFB for ; Sat, 3 Jan 2015 23:55:11 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 96CE5A888132; Sat, 3 Jan 2015 23:55:10 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 3 Jan 2015 23:55:10 -0800 (PST) Message-ID: In-Reply-To: <54A1960A.3010902@cs.tcd.ie> References: <54A1960A.3010902@cs.tcd.ie> Date: Sat, 3 Jan 2015 23:55:10 -0800 (PST) From: "Dan Harkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/saag/c_UvI56Cwzr-7noXjvtlZQimmEM Cc: "saag@ietf.org" Subject: Re: [saag] PSK considered helpful X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 07:55:12 -0000 On Mon, December 29, 2014 9:57 am, Stephen Farrell wrote: > > So what might make for a good BCP is to recommend something more > like an opportunistic DH exchange with a PSK used to authenticate > that there's no MitM (i.e. the PSK is only for authentication > and never for confidentiality). Or a PAKE :-) Dan. From nobody Sun Jan 4 03:40:29 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE01A8739; Sun, 4 Jan 2015 03:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y_aQeUV0qYE; Sun, 4 Jan 2015 03:40:24 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96DC1A8710; Sun, 4 Jan 2015 03:40:23 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar1so18248306iec.2; Sun, 04 Jan 2015 03:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fh4zSZq1irDelJskvgekorGVjTjzMaEVMyrHRwSkgcY=; b=zpFhSSRXkGIDN24IePuNnVJ7647gnFTv2oD7ZuzI9A0MyPGycL2maGl/a1EJ0F0ZWk QE8O2tAFZ4WqeIJbX2Zpq+w+YH2gZmOFZzCAraSIokJgZ8tOdvtyB9Bt0utc/K+OU4pQ Ls0xnQFo2qDb5+Yx9g6HS0ynuIX0D+parxWHVVImEOVT04q8oV1zoU8KXMm9LZpZar2U e1cUVjY86eA9WzMgNBHM9XKNsqRZ0c8x9WzKcR7LdNRQjr0uw6LW/uIxuqrBhg3sWc4i il6bpVuk6bB/FyiUv4stZe+z6WyELqpNG5mo7oYQwrcASiKDl+vcNATOd1De1w6aotqN J/eg== MIME-Version: 1.0 X-Received: by 10.50.8.7 with SMTP id n7mr6584503iga.16.1420371622717; Sun, 04 Jan 2015 03:40:22 -0800 (PST) Received: by 10.50.111.161 with HTTP; Sun, 4 Jan 2015 03:40:22 -0800 (PST) In-Reply-To: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> Date: Sun, 4 Jan 2015 12:40:22 +0100 Message-ID: From: Jaroslav Imrich To: Jan Pechanec Content-Type: multipart/alternative; boundary=089e013c660e057097050bd20aa3 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4R4pxPyRlE0qsm95ITOl8_-qs9I Cc: Darren J Moffat , ietf@ietf.org, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , saag@ietf.org, John C Klensin Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 11:40:28 -0000 --089e013c660e057097050bd20aa3 Content-Type: text/plain; charset=UTF-8 Hello Jan, the text mentions "NFC" but I was unable to find any pointer or reference to its definition. I was not familiar with the term before so I think reference in the text would be helpful. Regards, Jaroslav On Sun, Jan 4, 2015 at 6:58 AM, Jan Pechanec wrote: > On Thu, 1 Jan 2015, Nico Williams wrote: > > Nico, many thanks for the drafted text and also to Patrik and > John for discussing it. > > I've updated the draft in sections on URI matching guidelines, > URI comparision, added a new section on I18n, and added a new paragraph > to the Security considerations. Individial diffs inline, a draft for > new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt). > > >I think we could use some text like this: > > > > PKCS#11 does not specify a canonical from for UTF-8 string slots in > > the API. This presents the usual false negative and false positive > > (aliasing) concerns that arise when dealing with unnormalized > > strings. Because all PKCS#11 items are local and local security is > > assumed, these concerns are mainly about usability. > > > > In order to improve the user experience, applications that create > > PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to > > NFC. For the same reason PKCS#11 libraries, slots (token readers), > > and tokens SHOULD normalize their names to NFC. When listing > > libraries, slots, tokens, or objects, an application SHOULD normalize > > their names to NFC. When matching PKCS#11 URIs to libraries, slots, > > tokens, and/or objects, applications may use form-insensitive Unicode > > string comparison for matching, as the objects might pre-date these > > recommendations). > > I've created "Internationalization Considerations" section and > put the text above there after I slightly modified it. I wanted to > mention CK_UTF8CHAR type so that it's clear what is discussed. > > 768 6. Internationalization Considerations > > 770 The PKCS#11 specification does not specify a canonical form for > 771 strings of characters of the CK_UTF8CHAR type. This presents > the > 772 usual false negative and false positive (aliasing) concerns that > 773 arise when dealing with unnormalized strings. Because all > PKCS#11 > 774 items are local and local security is assumed, these concerns > are > 775 mainly about usability. > > 777 In order to improve the user experience, applications that > create > 778 PKCS#11 objects or label tokens, SHOULD normalize labels to > NFC. For > 779 the same reason PKCS#11 libraries, slots (token readers), and > tokens > 780 SHOULD normalize their names to NFC. When listing PKCS#11 > libraries, > 781 slots, tokens, and/or objects, an application SHOULD normalize > their > 782 names to NFC. When matching PKCS#11 URIs to libraries, slots, > 783 tokens, and/or objects, applications MAY use form-insensitive > Unicode > 784 string comparison for matching, as those might pre-date these > 785 recommendations. See also Section 3.5. > > in section 3.5 on URI Matching Guidelines, I've added the > following as the last paragraph of the section (it was based on John's > note from his last email). This paragraph might not be necessary there > and the first part could be moved to the I18N section but I think it's > good to put it to where attribute matching is discussed so that it is > not easily overlooked. > > 513 As noted in Section 6, the PKCS#11 specification is not clear > about > 514 how to normalize UTF-8 encoded Unicode characters [RFC2279]. > Those > 515 who discover a need to use characters outside the ASCII > repertoire > 516 should be cautious, conservative, and expend extra effort to be > sure > 517 they know what they are doing and that failure to do so may > create > 518 both operational and security risks. It means that when > matching > 519 UTF-8 string based attributes (see Table 1) with such > characters, > 520 normalizing all UTF-8 strings before string comparison may be > the > 521 only safe approach. For example, for objects (keys) it means > that > 522 PKCS#11 attribute search template would only contain attributes > that > 523 are not UTF-8 strings and another pass through returned objects > is > 524 then needed for UTF-8 string comparison after the normalization > is > 525 applied. > > >Then later in the security considerations section, add something like: > > > > PKCS#11 does not authenticate devices to users; PKCS#11 only > > authenticates users to tokens. Instead, local and physical security > > are demanded: the user must be in possession of their tokens, and > > system into whose slots the users' tokens are inserted must be > > secure. As a result, the usual security considerations regarding > > normalization do not arise. For the same reason, confusable script > > issues also do not arise. Nonetheless, it is best to normalize to > > NFC all strings appearing in PKCS#11 API elements. > > I've added the following to the Security Considerations > section (again, slightly modified, I'd rather not use "PKCS#11" as > an alias for the specification): > > 807 The PKCS#11 specification does not provide means to authenticate > 808 devices to users; it only allows to authenticate users to > tokens. > 809 Instead, local and physical security are demanded: the user > must be > 810 in possession of their tokens, and system into whose slots the > users' > 811 tokens are inserted must be secure. As a result, the usual > security > 812 considerations regarding normalization do not arise. For the > same > 813 reason, confusable script issues also do not arise. > Nonetheless, it > 814 is best to normalize to NFC all strings appearing in PKCS#11 API > 815 elements. See also Section 6. > > on top of that, I've added the following sentence to 3.6. PKCS#11 > URI > Comparison section: > > 532 strictly avoiding false positives. When working with UTF-8 > strings > 533 with characters outside the ASCII character sets, see important > 534 caveats in Section 3.5 and Section 6. > > the attribute Table 1 now also states which attributes are > UTF-8 strings so that it's clear without consulting the spec. > > thank you, Jan. > > -- > Jan Pechanec > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --089e013c660e057097050bd20aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Jan,

the text mentions= "NFC" but I was unable to find any pointer or reference to its d= efinition. I was not familiar with the term before so I think reference in = the text would be helpful.

Regards, Jaroslav
=


On= Sun, Jan 4, 2015 at 6:58 AM, Jan Pechanec <jan.pechanec@oracle.com<= /a>> wrote:
On Thu, 1 Jan 2015,= Nico Williams wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Nico, many thanks for the drafted text and also= to Patrik and
John for discussing it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've updated the draft in sections on URI m= atching guidelines,
URI comparision, added a new section on I18n, and added a new paragraph
to the Security considerations.=C2=A0 Individial diffs inline, a draft for<= br> new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt).

>I think we could use some text like this:
>
>=C2=A0 =C2=A0PKCS#11 does not specify a canonical from for UTF-8 string= slots in
>=C2=A0 =C2=A0the API.=C2=A0 This presents the usual false negative and = false positive
>=C2=A0 =C2=A0(aliasing) concerns that arise when dealing with unnormali= zed
>=C2=A0 =C2=A0strings.=C2=A0 Because all PKCS#11 items are local and loc= al security is
>=C2=A0 =C2=A0assumed, these concerns are mainly about usability.
>
>=C2=A0 =C2=A0In order to improve the user experience, applications that= create
>=C2=A0 =C2=A0PKCS#11 objects or otherwise label tokens, SHOULD normaliz= e labels to
>=C2=A0 =C2=A0NFC.=C2=A0 For the same reason PKCS#11 libraries, slots (t= oken readers),
>=C2=A0 =C2=A0and tokens SHOULD normalize their names to NFC.=C2=A0 When= listing
>=C2=A0 =C2=A0libraries, slots, tokens, or objects, an application SHOUL= D normalize
>=C2=A0 =C2=A0their names to NFC.=C2=A0 When matching PKCS#11 URIs to li= braries, slots,
>=C2=A0 =C2=A0tokens, and/or objects, applications may use form-insensit= ive Unicode
>=C2=A0 =C2=A0string comparison for matching, as the objects might pre-d= ate these
>=C2=A0 =C2=A0recommendations).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've created "Internationalizat= ion Considerations" section and
put the text above there after I slightly modified it.=C2=A0 I wanted to mention CK_UTF8CHAR type so that it's clear what is discussed.

768=C2=A0 =C2=A0 =C2=A06.=C2=A0 Internationalization Considerations

770=C2=A0 =C2=A0 =C2=A0 =C2=A0 The PKCS#11 specification does not specify a= canonical form for
771=C2=A0 =C2=A0 =C2=A0 =C2=A0 strings of characters of the CK_UTF8CHAR typ= e.=C2=A0 This presents the
772=C2=A0 =C2=A0 =C2=A0 =C2=A0 usual false negative and false positive (ali= asing) concerns that
773=C2=A0 =C2=A0 =C2=A0 =C2=A0 arise when dealing with unnormalized strings= .=C2=A0 Because all PKCS#11
774=C2=A0 =C2=A0 =C2=A0 =C2=A0 items are local and local security is assume= d, these concerns are
775=C2=A0 =C2=A0 =C2=A0 =C2=A0 mainly about usability.

777=C2=A0 =C2=A0 =C2=A0 =C2=A0 In order to improve the user experience, app= lications that create
778=C2=A0 =C2=A0 =C2=A0 =C2=A0 PKCS#11 objects or label tokens, SHOULD norm= alize labels to NFC.=C2=A0 For
779=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same reason PKCS#11 libraries, slots (to= ken readers), and tokens
780=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD normalize their names to NFC.=C2=A0 W= hen listing PKCS#11 libraries,
781=C2=A0 =C2=A0 =C2=A0 =C2=A0 slots, tokens, and/or objects, an applicatio= n SHOULD normalize their
782=C2=A0 =C2=A0 =C2=A0 =C2=A0 names to NFC.=C2=A0 When matching PKCS#11 UR= Is to libraries, slots,
783=C2=A0 =C2=A0 =C2=A0 =C2=A0 tokens, and/or objects, applications MAY use= form-insensitive Unicode
784=C2=A0 =C2=A0 =C2=A0 =C2=A0 string comparison for matching, as those mig= ht pre-date these
785=C2=A0 =C2=A0 =C2=A0 =C2=A0 recommendations.=C2=A0 See also Section 3.5.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in section 3.5 on URI Matching Guidelines, I= 9;ve added the
following as the last paragraph of the section (it was based on John's<= br> note from his last email).=C2=A0 This paragraph might not be necessary ther= e
and the first part could be moved to the I18N section but I think it's<= br> good to put it to where attribute matching is discussed so that it is
not easily overlooked.

513=C2=A0 =C2=A0 =C2=A0 =C2=A0 As noted in Section 6, the PKCS#11 specifica= tion is not clear about
514=C2=A0 =C2=A0 =C2=A0 =C2=A0 how to normalize UTF-8 encoded Unicode chara= cters [RFC2279].=C2=A0 Those
515=C2=A0 =C2=A0 =C2=A0 =C2=A0 who discover a need to use characters outsid= e the ASCII repertoire
516=C2=A0 =C2=A0 =C2=A0 =C2=A0 should be cautious, conservative, and expend= extra effort to be sure
517=C2=A0 =C2=A0 =C2=A0 =C2=A0 they know what they are doing and that failu= re to do so may create
518=C2=A0 =C2=A0 =C2=A0 =C2=A0 both operational and security risks.=C2=A0 I= t means that when matching
519=C2=A0 =C2=A0 =C2=A0 =C2=A0 UTF-8 string based attributes (see Table 1) = with such characters,
520=C2=A0 =C2=A0 =C2=A0 =C2=A0 normalizing all UTF-8 strings before string = comparison may be the
521=C2=A0 =C2=A0 =C2=A0 =C2=A0 only safe approach.=C2=A0 For example, for o= bjects (keys) it means that
522=C2=A0 =C2=A0 =C2=A0 =C2=A0 PKCS#11 attribute search template would only= contain attributes that
523=C2=A0 =C2=A0 =C2=A0 =C2=A0 are not UTF-8 strings and another pass throu= gh returned objects is
524=C2=A0 =C2=A0 =C2=A0 =C2=A0 then needed for UTF-8 string comparison afte= r the normalization is
525=C2=A0 =C2=A0 =C2=A0 =C2=A0 applied.

>Then later in the security considerations section, add something like:<= br> >
>=C2=A0 =C2=A0PKCS#11 does not authenticate devices to users; PKCS#11 on= ly
>=C2=A0 =C2=A0authenticates users to tokens.=C2=A0 Instead, local and ph= ysical security
>=C2=A0 =C2=A0are demanded: the user must be in possession of their toke= ns, and
>=C2=A0 =C2=A0system into whose slots the users' tokens are inserted= must be
>=C2=A0 =C2=A0secure.=C2=A0 As a result, the usual security consideratio= ns regarding
>=C2=A0 =C2=A0normalization do not arise.=C2=A0 For the same reason, con= fusable script
>=C2=A0 =C2=A0issues also do not arise.=C2=A0 Nonetheless, it is best to= normalize to
>=C2=A0 =C2=A0NFC all strings appearing in PKCS#11 API elements.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've added the following to the Secu= rity Considerations
section (again, slightly modified, I'd rather not use "PKCS#11&quo= t; as
an alias for the specification):

807=C2=A0 =C2=A0 =C2=A0 =C2=A0 The PKCS#11 specification does not provide m= eans to authenticate
808=C2=A0 =C2=A0 =C2=A0 =C2=A0 devices to users; it only allows to authenti= cate users to tokens.
809=C2=A0 =C2=A0 =C2=A0 =C2=A0 Instead, local and physical security are dem= anded: the user must be
810=C2=A0 =C2=A0 =C2=A0 =C2=A0 in possession of their tokens, and system in= to whose slots the users'
811=C2=A0 =C2=A0 =C2=A0 =C2=A0 tokens are inserted must be secure.=C2=A0 As= a result, the usual security
812=C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations regarding normalization do no= t arise.=C2=A0 For the same
813=C2=A0 =C2=A0 =C2=A0 =C2=A0 reason, confusable script issues also do not= arise.=C2=A0 Nonetheless, it
814=C2=A0 =C2=A0 =C2=A0 =C2=A0 is best to normalize to NFC all strings appe= aring in PKCS#11 API
815=C2=A0 =C2=A0 =C2=A0 =C2=A0 elements.=C2=A0 See also Section 6.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 on top of that, I've added the following se= ntence to 3.6. PKCS#11 URI
Comparison section:

532=C2=A0 =C2=A0 =C2=A0 =C2=A0 strictly avoiding false positives.=C2=A0 Whe= n working with UTF-8 strings
533=C2=A0 =C2=A0 =C2=A0 =C2=A0 with characters outside the ASCII character = sets, see important
534=C2=A0 =C2=A0 =C2=A0 =C2=A0 caveats in Section 3.5 and Section 6.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the attribute Table 1 now also states which att= ributes are
UTF-8 strings so that it's clear without consulting the spec.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 thank you, Jan.

--
Jan Pechanec <jan.pechanec@or= acle.com>
_________________________________________= ______
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag


--089e013c660e057097050bd20aa3-- From nobody Sun Jan 4 06:53:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291141A8738; Sun, 4 Jan 2015 06:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9__eY906XN5; Sun, 4 Jan 2015 06:53:26 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5591A1EF8; Sun, 4 Jan 2015 06:53:26 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t04ErE5x024204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 14:53:15 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t04ErDOD013633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 14:53:13 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t04ErCVh016259; Sun, 4 Jan 2015 14:53:12 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Jan 2015 06:53:11 -0800 Date: Sun, 4 Jan 2015 06:53:10 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Jaroslav Imrich In-Reply-To: Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_LRH1WqGCxTa1z7vmlSX4IYVyQA Cc: Darren J Moffat , ietf@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , saag@ietf.org, John C Klensin Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 14:53:29 -0000 On Sun, 4 Jan 2015, Jaroslav Imrich wrote: >Hello Jan, > >the text mentions "NFC" but I was unable to find any pointer or reference >to its definition. I was not familiar with the term before so I think >reference in the text would be helpful. hi Jaroslav, it's defined in the Unicode standard which I can reference directly but you would still need to search for the term rather than read the whole standard. please google "unicode NFC", all first hits lead to the right information. Jan. > >Regards, Jaroslav > > >On Sun, Jan 4, 2015 at 6:58 AM, Jan Pechanec >wrote: > >> On Thu, 1 Jan 2015, Nico Williams wrote: >> >> Nico, many thanks for the drafted text and also to Patrik and >> John for discussing it. >> >> I've updated the draft in sections on URI matching guidelines, >> URI comparision, added a new section on I18n, and added a new paragraph >> to the Security considerations. Individial diffs inline, a draft for >> new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt). >> >> >I think we could use some text like this: >> > >> > PKCS#11 does not specify a canonical from for UTF-8 string slots in >> > the API. This presents the usual false negative and false positive >> > (aliasing) concerns that arise when dealing with unnormalized >> > strings. Because all PKCS#11 items are local and local security is >> > assumed, these concerns are mainly about usability. >> > >> > In order to improve the user experience, applications that create >> > PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to >> > NFC. For the same reason PKCS#11 libraries, slots (token readers), >> > and tokens SHOULD normalize their names to NFC. When listing >> > libraries, slots, tokens, or objects, an application SHOULD normalize >> > their names to NFC. When matching PKCS#11 URIs to libraries, slots, >> > tokens, and/or objects, applications may use form-insensitive Unicode >> > string comparison for matching, as the objects might pre-date these >> > recommendations). >> >> I've created "Internationalization Considerations" section and >> put the text above there after I slightly modified it. I wanted to >> mention CK_UTF8CHAR type so that it's clear what is discussed. >> >> 768 6. Internationalization Considerations >> >> 770 The PKCS#11 specification does not specify a canonical form for >> 771 strings of characters of the CK_UTF8CHAR type. This presents >> the >> 772 usual false negative and false positive (aliasing) concerns that >> 773 arise when dealing with unnormalized strings. Because all >> PKCS#11 >> 774 items are local and local security is assumed, these concerns >> are >> 775 mainly about usability. >> >> 777 In order to improve the user experience, applications that >> create >> 778 PKCS#11 objects or label tokens, SHOULD normalize labels to >> NFC. For >> 779 the same reason PKCS#11 libraries, slots (token readers), and >> tokens >> 780 SHOULD normalize their names to NFC. When listing PKCS#11 >> libraries, >> 781 slots, tokens, and/or objects, an application SHOULD normalize >> their >> 782 names to NFC. When matching PKCS#11 URIs to libraries, slots, >> 783 tokens, and/or objects, applications MAY use form-insensitive >> Unicode >> 784 string comparison for matching, as those might pre-date these >> 785 recommendations. See also Section 3.5. >> >> in section 3.5 on URI Matching Guidelines, I've added the >> following as the last paragraph of the section (it was based on John's >> note from his last email). This paragraph might not be necessary there >> and the first part could be moved to the I18N section but I think it's >> good to put it to where attribute matching is discussed so that it is >> not easily overlooked. >> >> 513 As noted in Section 6, the PKCS#11 specification is not clear >> about >> 514 how to normalize UTF-8 encoded Unicode characters [RFC2279]. >> Those >> 515 who discover a need to use characters outside the ASCII >> repertoire >> 516 should be cautious, conservative, and expend extra effort to be >> sure >> 517 they know what they are doing and that failure to do so may >> create >> 518 both operational and security risks. It means that when >> matching >> 519 UTF-8 string based attributes (see Table 1) with such >> characters, >> 520 normalizing all UTF-8 strings before string comparison may be >> the >> 521 only safe approach. For example, for objects (keys) it means >> that >> 522 PKCS#11 attribute search template would only contain attributes >> that >> 523 are not UTF-8 strings and another pass through returned objects >> is >> 524 then needed for UTF-8 string comparison after the normalization >> is >> 525 applied. >> >> >Then later in the security considerations section, add something like: >> > >> > PKCS#11 does not authenticate devices to users; PKCS#11 only >> > authenticates users to tokens. Instead, local and physical security >> > are demanded: the user must be in possession of their tokens, and >> > system into whose slots the users' tokens are inserted must be >> > secure. As a result, the usual security considerations regarding >> > normalization do not arise. For the same reason, confusable script >> > issues also do not arise. Nonetheless, it is best to normalize to >> > NFC all strings appearing in PKCS#11 API elements. >> >> I've added the following to the Security Considerations >> section (again, slightly modified, I'd rather not use "PKCS#11" as >> an alias for the specification): >> >> 807 The PKCS#11 specification does not provide means to authenticate >> 808 devices to users; it only allows to authenticate users to >> tokens. >> 809 Instead, local and physical security are demanded: the user >> must be >> 810 in possession of their tokens, and system into whose slots the >> users' >> 811 tokens are inserted must be secure. As a result, the usual >> security >> 812 considerations regarding normalization do not arise. For the >> same >> 813 reason, confusable script issues also do not arise. >> Nonetheless, it >> 814 is best to normalize to NFC all strings appearing in PKCS#11 API >> 815 elements. See also Section 6. >> >> on top of that, I've added the following sentence to 3.6. PKCS#11 >> URI >> Comparison section: >> >> 532 strictly avoiding false positives. When working with UTF-8 >> strings >> 533 with characters outside the ASCII character sets, see important >> 534 caveats in Section 3.5 and Section 6. >> >> the attribute Table 1 now also states which attributes are >> UTF-8 strings so that it's clear without consulting the spec. >> >> thank you, Jan. >> >> -- >> Jan Pechanec >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >> > -- Jan Pechanec From nobody Sun Jan 4 17:04:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA41A0377; Sun, 4 Jan 2015 17:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUfHNAJcX62E; Sun, 4 Jan 2015 17:04:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B6A1A0372; Sun, 4 Jan 2015 17:04:31 -0800 (PST) Received: from DM2PR0301MB0654.namprd03.prod.outlook.com (25.160.96.16) by DM2PR0301MB1247.namprd03.prod.outlook.com (25.160.219.24) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 01:04:08 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (25.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 01:04:07 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 01:04:07 +0000 From: Christian Huitema To: Jan Pechanec , Jaroslav Imrich Thread-Topic: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) Thread-Index: AQHQJRBR50Yivp23dEaWxzuwY8Axt5ysJrWAgANWCICAAF+UAIAANd4AgACpunA= Date: Mon, 5 Jan 2015 01:04:07 +0000 Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.235.151.68] authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:DM2PR0301MB0654; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(20776003)(64706001)(4396001)(66066001)(86612001)(102836002)(122556002)(62966003)(2950100001)(2900100001)(2656002)(87936001)(33656002)(99396003)(120916001)(74316001)(40100003)(68736005)(77156002)(76176999)(54356999)(50986999)(76576001)(46102003)(31966008)(107046002)(93886004)(21056001)(101416001)(106356001)(92566001)(106116001)(99286002)(97736003)(86362001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2015 01:04:07.5399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1247; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Q87ZXDZ-6HNJ8D08dNjW_TujJ14 Cc: Darren J Moffat , "saag@ietf.org" , "ietf@ietf.org" , John C Klensin , =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 01:04:38 -0000 > hi Jaroslav, it's defined in the Unicode standard which I can=20 > reference directly but you would still need to search for the term=20 > rather than read the whole standard. Of course it is defined in the context of Unicode. But then, in a generic n= etworking context, NFC also stands for near-field communication. So it is d= efinitely good practice to spell the acronym out in the text on first use. -- Christian Huitema From nobody Sun Jan 4 20:13:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2711A1A6C; Sun, 4 Jan 2015 20:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIw4cQfzVU1S; Sun, 4 Jan 2015 20:13:40 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4999E1A1A6A; Sun, 4 Jan 2015 20:13:40 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t054DVPM031716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 04:13:32 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t054DQWQ000897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2015 04:13:27 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t054DQJ9018927; Mon, 5 Jan 2015 04:13:26 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Jan 2015 20:13:25 -0800 Date: Sun, 4 Jan 2015 20:13:24 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Christian Huitema In-Reply-To: Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-351212254-1420431205=:8160" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/luLaXvDQUGu8UnIlV3TL98D6VCE Cc: Darren J Moffat , "ietf@ietf.org" , =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , "saag@ietf.org" , John C Klensin Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:13:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-351212254-1420431205=:8160 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jan 2015, Christian Huitema wrote: >> hi Jaroslav, it's defined in the Unicode standard which I can >> reference directly but you would still need to search for the term >> rather than read the whole standard. > >Of course it is defined in the context of Unicode. But then, in a >generic networking context, NFC also stands for near-field >communication. So it is definitely good practice to spell the acronym >out in the text on first use. hello Christian, yes, I will spell it. I can see that I can also reference only Annex 15 that defines the normalization forms. The text now says: 777 In order to improve the user experience, applications that create 778 PKCS#11 objects or label tokens SHOULD normalize labels to 779 Normalization Form C (NFC) [UAX15]. For the same reason PKCS#11 with the new reference: 854 [UAX15] Davis, M., Ed., Whistler, K., Ed., and Unicode Consortium, 855 "Unicode Standard Annex #15 - Unicode Normalization Forms, 856 Version Unicode 7.0.0", June 2014. v2 of upcoming draft 18, draft-pechanec-pkcs11uri-18-v2.txt, is attached. thank you, Jan. -- Jan Pechanec ---559023410-351212254-1420431205=:8160 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=draft-pechanec-pkcs11uri-18-v2.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=draft-pechanec-pkcs11uri-18-v2.txt DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gUGVjaGFuZWMNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgT3JhY2xlIENvcnBvcmF0 aW9uDQpFeHBpcmVzOiBKdWx5IDgsIDIwMTUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKYW51YXJ5IDQsIDIwMTUNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZQ0KICAg ICAgICAgICAgICAgICAgICAgIGRyYWZ0LXBlY2hhbmVjLXBrY3MxMXVyaS0x OA0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgUEtD UyMxMSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkNCiAgIFNj aGVtZSBmb3IgaWRlbnRpZnlpbmcgUEtDUyMxMSBvYmplY3RzIHN0b3JlZCBp biBQS0NTIzExIHRva2VucywgYW5kDQogICBhbHNvIGZvciBpZGVudGlmeWlu ZyBQS0NTIzExIHRva2Vucywgc2xvdHMgb3IgbGlicmFyaWVzLiAgVGhlIFVS SSBpcw0KICAgYmFzZWQgb24gaG93IFBLQ1MjMTEgb2JqZWN0cywgdG9rZW5z LCBzbG90cywgYW5kIGxpYnJhcmllcyBhcmUNCiAgIGlkZW50aWZpZWQgaW4g dGhlIFBLQ1MjMTEgQ3J5cHRvZ3JhcGhpYyBUb2tlbiBJbnRlcmZhY2UgU3Rh bmRhcmQuDQoNClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElF VEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlz IGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVseSA4LCAyMDE1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwN CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAg IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQu ICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBF eHBpcmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJ IFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDINCiAg IDIuICBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIFBLQ1MjMTEgVVJJ IFNjaGVtZSBEZWZpbml0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA0DQogICAgIDMuMS4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBOYW1l IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAg My4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjMuICBQS0NTIzExIFVS SSBTY2hlbWUgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0DQogICAgIDMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBRdWVyeSBB dHRyaWJ1dGUgU2VtYW50aWNzICAuIC4gLiAuIC4gLiAgIDkNCiAgICAgMy41 LiAgUEtDUyMxMSBVUkkgTWF0Y2hpbmcgR3VpZGVsaW5lcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAzLjYuICBQS0NTIzExIFVSSSBD b21wYXJpc29uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEyDQogICAgIDMuNy4gIEdlbmVyYXRpbmcgUEtDUyMxMSBVUklzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCiAgIDQuICBFeGFt cGxlcyBvZiBQS0NTIzExIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMw0KICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2 DQogICA2LiAgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgIDcuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNw0KICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4DQog ICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgICAgOC4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOA0KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5DQoNCjEu ICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIFBLQ1MgIzExOiBDcnlwdG9ncmFw aGljIFRva2VuIEludGVyZmFjZSBTdGFuZGFyZCBbUEtDUzExXQ0KICAgc3Bl Y2lmaWVzIGFuIEFQSSwgY2FsbGVkIENyeXB0b2tpLCBmb3IgZGV2aWNlcyB3 aGljaCBob2xkDQogICBjcnlwdG9ncmFwaGljIGluZm9ybWF0aW9uIGFuZCBw ZXJmb3JtIGNyeXB0b2dyYXBoaWMgZnVuY3Rpb25zLg0KICAgQ3J5cHRva2ks IHByb25vdW5jZWQgY3J5cHRvLWtleSBhbmQgc2hvcnQgZm9yIGNyeXB0b2dy YXBoaWMgdG9rZW4NCiAgIGludGVyZmFjZSwgZm9sbG93cyBhIHNpbXBsZSBv YmplY3QtYmFzZWQgYXBwcm9hY2gsIGFkZHJlc3NpbmcgdGhlDQogICBnb2Fs cyBvZiB0ZWNobm9sb2d5IGluZGVwZW5kZW5jZSAoYW55IGtpbmQgb2YgZGV2 aWNlIG1heSBiZSB1c2VkKSBhbmQNCiAgIHJlc291cmNlIHNoYXJpbmcgKG11 bHRpcGxlIGFwcGxpY2F0aW9ucyBtYXkgYWNjZXNzIG11bHRpcGxlIGRldmlj ZXMpLA0KICAgcHJlc2VudGluZyBhcHBsaWNhdGlvbnMgd2l0aCBhIGNvbW1v biwgbG9naWNhbCB2aWV3IG9mIHRoZSBkZXZpY2UgLSBhDQogICBjcnlwdG9n cmFwaGljIHRva2VuLg0KDQogICBJdCBpcyBkZXNpcmFibGUgZm9yIGFwcGxp Y2F0aW9ucyBvciBsaWJyYXJpZXMgdGhhdCB3b3JrIHdpdGggUEtDUyMxMQ0K ICAgdG9rZW5zIHRvIGFjY2VwdCBhIGNvbW1vbiBpZGVudGlmaWVyIHRoYXQg Y29uc3VtZXJzIGNvdWxkIHVzZSB0bw0KICAgaWRlbnRpZnkgYW4gZXhpc3Rp bmcgUEtDUyMxMSBzdG9yYWdlIG9iamVjdCBpbiBhIFBLQ1MjMTEgdG9rZW4s IGFuDQogICBleGlzdGluZyB0b2tlbiBpdHNlbGYsIGEgc2xvdCwgb3IgYW4g ZXhpc3RpbmcgQ3J5cHRva2kgbGlicmFyeSAoYWxzbw0KICAgY2FsbGVkIGEg cHJvZHVjZXIsIG1vZHVsZSwgb3IgcHJvdmlkZXIpLiAgVGhlIHNldCBvZiBz dG9yYWdlIG9iamVjdA0KICAgdHlwZXMgdGhhdCBjYW4gYmUgc3RvcmVkIGlu IGEgUEtDUyMxMSB0b2tlbiBpbmNsdWRlcyBhIGNlcnRpZmljYXRlLCBhDQog ICBwdWJsaWMsIHByaXZhdGUgb3Igc2VjcmV0IGtleSwgYW5kIGEgZGF0YSBv YmplY3QuICBUaGVzZSBvYmplY3RzIGNhbg0KICAgYmUgdW5pcXVlbHkgaWRl bnRpZmlhYmxlIHZpYSB0aGUgUEtDUyMxMSBVUkkgc2NoZW1lIGRlZmluZWQg aW4gdGhpcw0KICAgZG9jdW1lbnQuICBUaGUgc2V0IG9mIGF0dHJpYnV0ZXMg ZGVzY3JpYmluZyBhIHN0b3JhZ2Ugb2JqZWN0IGNhbg0KICAgY29udGFpbiBh biBvYmplY3QgbGFiZWwsIGl0cyB0eXBlLCBhbmQgaXRzIElELiAgVGhlIHNl dCBvZiBhdHRyaWJ1dGVzDQogICB0aGF0IGlkZW50aWZpZXMgYSBQS0NTIzEx IHRva2VuIGNhbiBjb250YWluIGEgdG9rZW4gbGFiZWwsDQogICBtYW51ZmFj dHVyZXIgbmFtZSwgc2VyaWFsIG51bWJlciwgYW5kIHRva2VuIG1vZGVsLiAg QXR0cmlidXRlcyB0aGF0DQogICBjYW4gaWRlbnRpZnkgYSBzbG90IGFyZSBh IHNsb3QgSUQsIGRlc2NyaXB0aW9uLCBhbmQgbWFudWZhY3R1cmVyLg0KICAg QXR0cmlidXRlcyB0aGF0IGNhbiBpZGVudGlmeSBhIENyeXB0b2tpIGxpYnJh cnkgYXJlIGEgbGlicmFyeQ0KICAgbWFudWZhY3R1cmVyLCBkZXNjcmlwdGlv biwgYW5kIHZlcnNpb24uICBMaWJyYXJ5IGF0dHJpYnV0ZXMgbWF5IGJlDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4 LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgIG5lY2Vzc2FyeSB0byB1c2Ug aWYgbW9yZSB0aGFuIG9uZSBDcnlwdG9raSBsaWJyYXJ5IHByb3ZpZGVzIGEg dG9rZW4NCiAgIGFuZC9vciBQS0NTIzExIG9iamVjdHMgb2YgdGhlIHNhbWUg bmFtZS4gIEEgc2V0IG9mIHF1ZXJ5IGF0dHJpYnV0ZXMNCiAgIGlzIHByb3Zp ZGVkIGFzIHdlbGwuDQoNCiAgIFRoZSBQS0NTIzExIFVSSSBjYW5ub3QgaWRl bnRpZnkgb3RoZXIgb2JqZWN0cyBkZWZpbmVkIGluIHRoZQ0KICAgc3BlY2lm aWNhdGlvbiBbUEtDUzExXSBhc2lkZSBmcm9tIHN0b3JhZ2Ugb2JqZWN0cy4g IEZvciBleGFtcGxlLA0KICAgb2JqZWN0cyBub3QgaWRlbnRpZmlhYmxlIGJ5 IGEgUEtDUyMxMSBVUkkgaW5jbHVkZSBhIGhhcmR3YXJlIGZlYXR1cmUNCiAg IGFuZCBtZWNoYW5pc20uICBOb3RlIHRoYXQgYSBDcnlwdG9raSBsaWJyYXJ5 IGRvZXMgbm90IGhhdmUgdG8gcHJvdmlkZQ0KICAgZm9yIHN0b3JhZ2Ugb2Jq ZWN0cyBhdCBhbGwuICBUaGUgVVJJIGNhbiBzdGlsbCBiZSB1c2VkIHRvIGlk ZW50aWZ5IGENCiAgIHNwZWNpZmljIFBLQ1MjMTEgdG9rZW4sIHNsb3Qgb3Ig YW4gQVBJIHByb2R1Y2VyIGluIHN1Y2ggYSBjYXNlLg0KDQogICBBIHN1YnNl dCBvZiBleGlzdGluZyBQS0NTIzExIHN0cnVjdHVyZSBtZW1iZXJzIGFuZCBv YmplY3QgYXR0cmlidXRlcw0KICAgd2FzIGNob3NlbiB0byB1bmlxdWVseSBp ZGVudGlmeSBhIFBLQ1MjMTEgc3RvcmFnZSBvYmplY3QsIHRva2VuLA0KICAg c2xvdCwgb3IgbGlicmFyeSBpbiBhIGNvbmZpZ3VyYXRpb24gZmlsZSwgb24g YSBjb21tYW5kIGxpbmUsIG9yIGluIGENCiAgIGNvbmZpZ3VyYXRpb24gcHJv cGVydHkgb2Ygc29tZXRoaW5nIGVsc2UuICBTaG91bGQgdGhlcmUgYmUgYSBu ZWVkIGZvcg0KICAgYSBtb3JlIGNvbXBsZXggaW5mb3JtYXRpb24gZXhjaGFu Z2Ugb24gUEtDUyMxMSBlbnRpdGllcyBhIGRpZmZlcmVudA0KICAgbWVhbnMg b2YgZGF0YSBtYXJzaGFsbGluZyBzaG91bGQgYmUgY2hvc2VuIGFjY29yZGlu Z2x5Lg0KDQogICBBIFBLQ1MjMTEgVVJJIGlzIG5vdCBpbnRlbmRlZCB0byBi ZSB1c2VkIHRvIGNyZWF0ZSBuZXcgUEtDUyMxMQ0KICAgb2JqZWN0cyBpbiB0 b2tlbnMsIG9yIHRvIGNyZWF0ZSBQS0NTIzExIHRva2Vucy4gIEl0IGlzIHNv bGVseSB0byBiZQ0KICAgdXNlZCB0byBpZGVudGlmeSBhbmQgd29yayB3aXRo IGV4aXN0aW5nIHN0b3JhZ2Ugb2JqZWN0cywgdG9rZW5zLCBhbmQNCiAgIHNs b3RzIHRocm91Z2ggdGhlIFBLQ1MjMTEgQVBJLCBvciBpZGVudGlmeSBDcnlw dG9raSBsaWJyYXJpZXMNCiAgIHRoZW1zZWx2ZXMuDQoNCiAgIFRoZSBVUkkg c2NoZW1lIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCBz cGVjaWZpY2FsbHkgd2l0aA0KICAgYSBtYXBwaW5nIHRvIHRoZSBQS0NTIzEx IEFQSSBpbiBtaW5kLiAgVGhlIFVSSSB1c2VzIHRoZSBzY2hlbWUsIHBhdGgN CiAgIGFuZCBxdWVyeSBjb21wb25lbnRzIGRlZmluZWQgaW4gdGhlIFVuaWZv cm0gUmVzb3VyY2UgSWRlbnRpZmllcg0KICAgKFVSSSk6IEdlbmVyaWMgU3lu dGF4IFtSRkMzOTg2XSBkb2N1bWVudC4gIFRoZSBVUkkgZG9lcyBub3QgdXNl IHRoZQ0KICAgaGllcmFyY2hpY2FsIGVsZW1lbnQgZm9yIGEgbmFtaW5nIGF1 dGhvcml0eSBpbiB0aGUgcGF0aCBzaW5jZSB0aGUNCiAgIGF1dGhvcml0eSBw YXJ0IGNvdWxkIG5vdCBiZSBtYXBwZWQgdG8gUEtDUyMxMSBBUEkgZWxlbWVu dHMuICBUaGUgVVJJDQogICBkb2VzIG5vdCB1c2UgdGhlIGZyYWdtZW50IGNv bXBvbmVudC4NCg0KICAgSWYgYW4gYXBwbGljYXRpb24gaGFzIG5vIGFjY2Vz cyB0byBhIHByb2R1Y2VyIG9yIHByb2R1Y2VycyBvZiB0aGUNCiAgIFBLQ1Mj MTEgQVBJIHRoZSBxdWVyeSBjb21wb25lbnQgbW9kdWxlIGF0dHJpYnV0ZXMg Y2FuIGJlIHVzZWQuDQogICBIb3dldmVyLCB0aGUgUEtDUyMxMSBVUkkgY29u c3VtZXIgY2FuIGFsd2F5cyBkZWNpZGUgdG8gcHJvdmlkZSBpdHMNCiAgIG93 biBhZGVxdWF0ZSB1c2VyIGludGVyZmFjZSB0byBsb2NhdGUgYW5kIGxvYWQg UEtDUyMxMSBBUEkgcHJvZHVjZXJzLg0KDQogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5E RUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZD MjExOV0uDQoNCjIuICBDb250cmlidXRvcnMNCg0KICAgU3RlZiBXYWx0ZXIs IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zLCBOaWNvIFdpbGxpYW1zLCBEYW4g V2luc2hpcCwgYW5kDQogICBKYXJvc2xhdiBJbXJpY2ggY29udHJpYnV0ZWQg dG8gdGhlIGRldmVsb3BtZW50IG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4 LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCjMuICBQS0NTIzExIFVSSSBTY2hl bWUgRGVmaW5pdGlvbg0KDQogICBJbiBhY2NvcmRhbmNlIHdpdGggW1JGQzQz OTVdLCB0aGlzIHNlY3Rpb24gcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uDQog ICByZXF1aXJlZCB0byByZWdpc3RlciB0aGUgUEtDUyMxMSBVUkkgc2NoZW1l Lg0KDQozLjEuICBQS0NTIzExIFVSSSBTY2hlbWUgTmFtZQ0KDQogICBwa2Nz MTENCg0KMy4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cw0KDQogICBQ ZXJtYW5lbnQuDQoNCjMuMy4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBTeW50YXgN Cg0KICAgVGhlIFBLQ1MjMTEgVVJJIGlzIGEgc2VxdWVuY2Ugb2YgYXR0cmli dXRlIHZhbHVlIHBhaXJzIHNlcGFyYXRlZCBieSBhDQogICBzZW1pY29sb24g dGhhdCBmb3JtIGEgb25lIGxldmVsIHBhdGggY29tcG9uZW50LCBvcHRpb25h bGx5IGZvbGxvd2VkDQogICBieSBhIHF1ZXJ5LiAgSW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gMi41IG9mIFtSRkMzOTg2XSwgdGhlIGRhdGENCiAgIHNo b3VsZCBmaXJzdCBiZSBlbmNvZGVkIGFzIG9jdGV0cyBhY2NvcmRpbmcgdG8g dGhlIFVURi04IGNoYXJhY3Rlcg0KICAgZW5jb2RpbmcgW1JGQzM2MjldOyB0 aGVuIG9ubHkgdGhvc2Ugb2N0ZXRzIHRoYXQgZG8gbm90IGNvcnJlc3BvbmQg dG8NCiAgIGNoYXJhY3RlcnMgaW4gdGhlIHVucmVzZXJ2ZWQgc2V0IG9yIHRv IHBlcm1pdHRlZCBjaGFyYWN0ZXJzIGZyb20gdGhlDQogICByZXNlcnZlZCBz ZXQgc2hvdWxkIGJlIHBlcmNlbnQtZW5jb2RlZC4gIFRoaXMgc3BlY2lmaWNh dGlvbiBzdWdnZXN0cw0KICAgb25lIGFsbG93YWJsZSBleGNlcHRpb24gdG8g dGhhdCBydWxlIGZvciB0aGUgImlkIiBhdHRyaWJ1dGUsIGFzDQogICBzdGF0 ZWQgbGF0ZXIgaW4gdGhpcyBzZWN0aW9uLiAgTm90ZSB0aGF0IGlmIGEgVVJJ IGRvZXMgY2FycnkNCiAgIGNoYXJhY3RlcnMgb3V0c2lkZSBvZiB0aGUgQVND SUkgY2hhcmFjdGVyIHNldCBhIGNvbnZlcnNpb24gdG8gYW4NCiAgIEludGVy bmF0aW9uYWxpemVkIFJlc291cmNlIElkZW50aWZpZXIgKElSSSkgZGVmaW5l ZCBpbiBbUkZDMzk4N10gbWF5DQogICBiZSBjb25zaWRlcmVkLiAgR3JhbW1h ciBydWxlcyAidW5yZXNlcnZlZCIgYW5kICJwY3QtZW5jb2RlZCIgaW4gdGhl DQogICBQS0NTIzExIFVSSSBzcGVjaWZpY2F0aW9uIGJlbG93IGFyZSBpbXBv cnRlZCBmcm9tIFtSRkMzOTg2XS4gIEFzIGENCiAgIHNwZWNpYWwgY2FzZSwg bm90ZSB0aGF0IGFjY29yZGluZyB0byBBcHBlbmRpeCBBIG9mIFtSRkMzOTg2 XSwgYSBzcGFjZQ0KICAgbXVzdCBiZSBwZXJjZW50LWVuY29kZWQuDQoNCiAg IFRoZSBQS0NTIzExIHNwZWNpZmljYXRpb24gaW1wb3NlcyB2YXJpb3VzIGxp bWl0YXRpb25zIG9uIHRoZSB2YWx1ZSBvZg0KICAgYXR0cmlidXRlcywgYmUg aXQgYSBtb3JlIHJlc3RyaWN0aXZlIGNoYXJhY3RlciBzZXQgZm9yIHRoZSAi c2VyaWFsIg0KICAgYXR0cmlidXRlIG9yIGZpeGVkIHNpemVkIGJ1ZmZlcnMg Zm9yIGFsbW9zdCBhbGwgdGhlIG90aGVycywgaW5jbHVkaW5nDQogICAidG9r ZW4iLCAibWFudWZhY3R1cmVyIiwgYW5kICJtb2RlbCIgYXR0cmlidXRlcy4g IEhvd2V2ZXIsIHRoZQ0KICAgUEtDUyMxMSBVUkkgbm90YXRpb24gZG9lcyBu b3QgaW1wb3NlIHN1Y2ggbGltaXRhdGlvbnMgYXNpZGUgZnJvbQ0KICAgcmVt b3ZpbmcgZ2VuZXJpYyBhbmQgUEtDUyMxMSBVUkkgZGVsaW1pdGVycyBmcm9t IGEgcGVybWl0dGVkDQogICBjaGFyYWN0ZXIgc2V0LiAgV2UgYmVsaWV2ZSB0 aGF0IGJlaW5nIHRvbyByZXN0cmljdGl2ZSBvbiB0aGUNCiAgIGF0dHJpYnV0 ZSB2YWx1ZXMgY291bGQgbGltaXQgdGhlIFBLQ1MjMTEgVVJJIHVzZWZ1bG5l c3MuICBXaGF0IGlzDQogICBtb3JlLCBwb3NzaWJsZSBmdXR1cmUgY2hhbmdl cyB0byB0aGUgUEtDUyMxMSBzcGVjaWZpY2F0aW9uIHNob3VsZCBub3QNCiAg IGFmZmVjdCBleGlzdGluZyBhdHRyaWJ1dGVzLg0KDQogICBBIFBLQ1MjMTEg VVJJIHRha2VzIHRoZSBmb3JtIChmb3IgZXhwbGFuYXRpb24gb2YgQXVnbWVu dGVkIEJORiwgc2VlDQogICBbUkZDNTIzNF0pOg0KDQoNCg0KDQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1 ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAg IEphbnVhcnkgMjAxNQ0KDQoNCiAgcGsxMS1VUkkgICAgICAgICAgICAgPSAi cGtjczExOiIgcGsxMS1wYXRoIFsgIj8iIHBrMTEtcXVlcnkgXQ0KICA7IFBh dGggY29tcG9uZW50IGFuZCBpdHMgYXR0cmlidXRlcy4gIFBhdGggbWF5IGJl IGVtcHR5Lg0KICBwazExLXBhdGggICAgICAgICAgICA9IFsgcGsxMS1wYXR0 ciAqKCI7IiBwazExLXBhdHRyKSBdDQogIHBrMTEtcGF0dHIgICAgICAgICAg ID0gcGsxMS10b2tlbiAvIHBrMTEtbWFudWYgLyBwazExLXNlcmlhbCAvDQog ICAgICAgICAgICAgICAgICAgICAgICAgcGsxMS1tb2RlbCAvIHBrMTEtbGli LW1hbnVmIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLWxpYi12 ZXIgLyBwazExLWxpYi1kZXNjIC8NCiAgICAgICAgICAgICAgICAgICAgICAg ICBwazExLW9iamVjdCAvIHBrMTEtdHlwZSAvIHBrMTEtaWQgLw0KICAgICAg ICAgICAgICAgICAgICAgICAgIHBrMTEtc2xvdC1kZXNjIC8gcGsxMS1zbG90 LW1hbnVmIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLXNsb3Qt aWQgLyBwazExLXYtcGF0dHINCiAgOyBRdWVyeSBjb21wb25lbnQgYW5kIGl0 cyBhdHRyaWJ1dGVzLiAgUXVlcnkgbWF5IGJlIGVtcHR5Lg0KICBwazExLXFh dHRyICAgICAgICAgICA9IHBrMTEtcGluLXNvdXJjZSAvIHBrMTEtcGluLXZh bHVlIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLW1vZHVsZS1u YW1lIC8gcGsxMS1tb2R1bGUtcGF0aCAvDQogICAgICAgICAgICAgICAgICAg ICAgICAgcGsxMS12LXFhdHRyDQogIHBrMTEtcXVlcnkgICAgICAgICAgID0g WyBwazExLXFhdHRyICooIiYiIHBrMTEtcWF0dHIpIF0NCiAgOyBSRkMgMzk4 NiBzZWN0aW9uIDIuMiBtYW5kYXRlcyBhbGwgcG90ZW50aWFsbHkgcmVzZXJ2 ZWQgY2hhcmFjdGVycw0KICA7IHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGgg YWN0dWFsIGRlbGltaXRlcnMgb2YgdGhlIFVSSSBkbyBub3QgaGF2ZQ0KICA7 IHRvIGJlIHBlcmNlbnQtZW5jb2RlZC4NCiAgcGsxMS1yZXMtYXZhaWwgICAg ICAgPSAiOiIgLyAiWyIgLyAiXSIgLyAiQCIgLyAiISIgLyAiJCIgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICInIiAvICIoIiAvICIpIiAvICIqIiAv ICIrIiAvICIsIiAvICI9Ig0KICBwazExLXBhdGgtcmVzLWF2YWlsICA9IHBr MTEtcmVzLWF2YWlsIC8gIiYiDQogIDsgIi8iIGFuZCAiPyIgaW4gdGhlIHF1 ZXJ5IGNvbXBvbmVudCBNQVkgYmUgdW5lbmNvZGVkIGJ1dCAiJiIgTVVTVA0K ICA7IGJlIGVuY29kZWQgc2luY2UgaXQgZnVuY3Rpb25zIGFzIGEgZGVsaW1p dGVyIHdpdGhpbiB0aGUgY29tcG9uZW50Lg0KICBwazExLXF1ZXJ5LXJlcy1h dmFpbCA9IHBrMTEtcmVzLWF2YWlsIC8gIi8iIC8gIj8iIC8gInwiDQogIHBr MTEtcGNoYXIgICAgICAgICAgID0gdW5yZXNlcnZlZCAvIHBrMTEtcGF0aC1y ZXMtYXZhaWwgLyBwY3QtZW5jb2RlZA0KICBwazExLXFjaGFyICAgICAgICAg ICA9IHVucmVzZXJ2ZWQgLyBwazExLXF1ZXJ5LXJlcy1hdmFpbCAvIHBjdC1l bmNvZGVkDQogIHBrMTEtdG9rZW4gICAgICAgICAgID0gInRva2VuIiAiPSIg KnBrMTEtcGNoYXINCiAgcGsxMS1tYW51ZiAgICAgICAgICAgPSAibWFudWZh Y3R1cmVyIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1zZXJpYWwgICAgICAg ICAgPSAic2VyaWFsIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1tb2RlbCAg ICAgICAgICAgPSAibW9kZWwiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxp Yi1tYW51ZiAgICAgICA9ICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIgIj0iICpw azExLXBjaGFyDQogIHBrMTEtbGliLWRlc2MgICAgICAgID0gImxpYnJhcnkt ZGVzY3JpcHRpb24iICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxpYi12ZXIg ICAgICAgICA9ICJsaWJyYXJ5LXZlcnNpb24iICI9IiAxKkRJR0lUIFsgIi4i IDEqRElHSVQgXQ0KICBwazExLW9iamVjdCAgICAgICAgICA9ICJvYmplY3Qi ICI9IiAqcGsxMS1wY2hhcg0KICBwazExLXR5cGUgICAgICAgICAgICA9ICJ0 eXBlIiAiPSIgKCAicHVibGljIiAvICJwcml2YXRlIiAvICJjZXJ0IiAvDQog ICAgICAgICAgICAgICAgICAgICAgICAgInNlY3JldC1rZXkiIC8gImRhdGEi ICkNCiAgcGsxMS1pZCAgICAgICAgICAgICAgPSAiaWQiICI9IiAqcGsxMS1w Y2hhcg0KICBwazExLXNsb3QtbWFudWYgICAgICA9ICJzbG90LW1hbnVmYWN0 dXJlciIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtc2xvdC1kZXNjICAgICAg ID0gInNsb3QtZGVzY3JpcHRpb24iICI9IiAqcGsxMS1wY2hhcg0KICBwazEx LXNsb3QtaWQgICAgICAgICA9ICJzbG90LWlkIiAiPSIgMSpESUdJVA0KICBw azExLXBpbi1zb3VyY2UgICAgICA9ICJwaW4tc291cmNlIiAiPSIgKnBrMTEt cWNoYXINCiAgcGsxMS1waW4tdmFsdWUgICAgICAgPSAicGluLXZhbHVlIiAi PSIgKnBrMTEtcWNoYXINCiAgcGsxMS1tb2R1bGUtbmFtZSAgICAgPSAibW9k dWxlLW5hbWUiICI9IiAqcGsxMS1xY2hhcg0KICBwazExLW1vZHVsZS1wYXRo ICAgICA9ICJtb2R1bGUtcGF0aCIgIj0iICpwazExLXFjaGFyDQogIHBrMTEt di1hdHRyLW5tLWNoYXIgID0gQUxQSEEgLyBESUdJVCAvICItIiAvICJfIg0K ICA7IFBlcm1pdHRlZCB2YWx1ZSBvZiBhIHZlbmRvciBzcGVjaWZpYyBhdHRy aWJ1dGUgaXMgYmFzZWQgb24NCiAgOyB3aGV0aGVyIHRoZSBhdHRyaWJ1dGUg aXMgdXNlZCBpbiB0aGUgcGF0aCBvciBpbiB0aGUgcXVlcnkuDQogIHBrMTEt di1wYXR0ciAgICAgICAgID0gMSpwazExLXYtYXR0ci1ubS1jaGFyICI9IiAq cGsxMS1wY2hhcg0KICBwazExLXYtcWF0dHIgICAgICAgICA9IDEqcGsxMS12 LWF0dHItbm0tY2hhciAiPSIgKnBrMTEtcWNoYXINCg0KDQoNClBlY2hhbmVj ICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDgsIDIwMTUgICAgICAg ICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgICAgSmFudWFy eSAyMDE1DQoNCg0KICAgVGhlIFVSSSBwYXRoIGNvbXBvbmVudCBjb250YWlu cyBhdHRyaWJ1dGVzIHRoYXQgaWRlbnRpZnkgYSByZXNvdXJjZQ0KICAgaW4g YSBvbmUgbGV2ZWwgaGllcmFyY2h5IHByb3ZpZGVkIGJ5IENyeXB0b2tpIHBy b2R1Y2Vycy4gIFRoZSBxdWVyeQ0KICAgY29tcG9uZW50IGNhbiBjb250YWlu IGEgZmV3IGF0dHJpYnV0ZXMgdGhhdCBtYXkgYmUgbmVlZGVkIHRvIHJldHJp ZXZlDQogICB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgVVJJIHBh dGguICBBdHRyaWJ1dGVzIGluIHRoZSBwYXRoDQogICBjb21wb25lbnQgYXJl IGRlbGltaXRlZCBieSAnOycgY2hhcmFjdGVyLCBhdHRyaWJ1dGVzIGluIHRo ZSBxdWVyeQ0KICAgY29tcG9uZW50IHVzZSAnJicgYXMgYSBkZWxpbWl0ZXIu DQoNCiAgIEJvdGggcGF0aCBhbmQgcXVlcnkgY29tcG9uZW50cyBtYXkgY29u dGFpbiB2ZW5kb3Igc3BlY2lmaWMNCiAgIGF0dHJpYnV0ZXMuICBTdWNoIGF0 dHJpYnV0ZSBuYW1lcyBNVVNUIE5PVCBjbGFzaCB3aXRoIGV4aXN0aW5nDQog ICBhdHRyaWJ1dGUgbmFtZXMuICBOb3RlIHRoYXQgaW4gYWNjb3JkYW5jZSB3 aXRoIFtCQ1AxNzhdLCBwcmV2aW91c2x5DQogICB1c2VkIGNvbnZlbnRpb24g b2Ygc3RhcnRpbmcgdmVuZG9yIGF0dHJpYnV0ZXMgd2l0aCBhbiAieC0iIHBy ZWZpeCBpcw0KICAgbm93IGRlcHJpY2F0ZWQuDQoNCiAgIFRoZSBnZW5lcmFs ICcvJyBkZWxpbWl0ZXIgTVVTVCBiZSBwZXJjZW50LWVuY29kZWQgaW4gdGhl IHBhdGgNCiAgIGNvbXBvbmVudCBzbyB0aGF0IGdlbmVyaWMgVVJJIHBhcnNl cnMgbmV2ZXIgc3BsaXQgdGhlIHBhdGggY29tcG9uZW50DQogICBpbnRvIG11 bHRpcGxlIHNlZ21lbnRzLiAgSXQgTUFZIGJlIHVuZW5jb2RlZCBpbiB0aGUg cXVlcnkgY29tcG9uZW50Lg0KICAgRGVsaW1pdGVyICc/JyAgTVVTVCBiZSBw ZXJjZW50LWVuY29kZWQgaW4gdGhlIHBhdGggY29tcG9uZW50IHNpbmNlDQog ICB0aGUgUEtDUyMxMSBVUkkgdXNlcyBhIHF1ZXJ5IGNvbXBvbmVudC4gIERl bGltaXRlciAnIycgTVVTVCBiZSBhbHdheXMNCiAgIHBlcmNlbnQtZW5jb2Rl ZCBzbyB0aGF0IGdlbmVyaWMgVVJJIHBhcnNlcnMgZG8gbm90IHRyZWF0IGEg aGFzaCBhcyBhDQogICBiZWdpbm5pbmcgb2YgYSBmcmFnbWVudCBpZGVudGlm aWVyIGNvbXBvbmVudC4gIEFsbCBvdGhlciBnZW5lcmljDQogICBkZWxpbWl0 ZXJzIE1BWSBiZSB1c2VkIHVuZW5jb2RlZCAoJzonLCAnWycsICddJywgYW5k ICdAJykgaW4gdGhlDQogICBQS0NTIzExIFVSSS4NCg0KICAgVGhlIGZvbGxv d2luZyB0YWJsZSBwcmVzZW50cyBtYXBwaW5nIGJldHdlZW4gdGhlIFBLQ1Mj MTEgVVJJIHBhdGgNCiAgIGNvbXBvbmVudCBhdHRyaWJ1dGVzIGFuZCB0aGUg UEtDUyMxMSBBUEkgc3RydWN0dXJlIG1lbWJlcnMgYW5kIG9iamVjdA0KICAg YXR0cmlidXRlcy4gIEdpdmVuIHRoYXQgUEtDUyMxMSBVUkkgdXNlcnMgbWF5 IGJlIHF1aXRlIGlnbm9yYW50IGFib3V0DQogICB0aGUgUEtDUyMxMSBzcGVj aWZpY2F0aW9uIHRoZSBtYXBwaW5nIGlzIGEgcHJvZHVjdCBvZiBhIG5lY2Vz c2FyeQ0KICAgY29tcHJvbWlzZSBiZXR3ZWVuIGhvdyBwcmVjaXNlbHkgYXJl IHRoZSBVUkkgYXR0cmlidXRlIG5hbWVzIG1hcHBlZA0KICAgdG8gdGhlIG5h bWVzIGluIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgZWFzZSBvZiB1c2Ug YW5kDQogICB1bmRlcnN0YW5kaW5nIG9mIHRoZSBVUkkgc2NoZW1lLg0KDQog ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVVJJIGNvbXBvbmVu dCBwYXRoICAgfCBBdHRyaWJ1dGUgICAgICAgICAgIHwgQXR0cmlidXRlICAg ICAgICAgICAgfA0KICAgfCBhdHRyaWJ1dGUgbmFtZSAgICAgICB8IHJlcHJl c2VudHMgICAgICAgICAgfCBjb3JyZXNwb25kcyBpbiB0aGUgICB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 IFBLQ1MjMTEgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgc3BlY2lmaWNhdGlvbiB0 byAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgfCBpZCAgICAgICAgICAgICAgICAgICB8IGtleSBpZGVudGlm aWVyIGZvciAgfCAiQ0tBX0lEIiBvYmplY3QgICAgICB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgb2JqZWN0ICAgICAgICAgICAgICB8IGF0dHJp YnV0ZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgfCBsaWJyYXJ5LWRlc2NyaXB0aW9uICB8IGNoYXJhY3Rlci1zdHJp bmcgICAgfCAibGlicmFyeURlc2NyaXB0aW9uIiB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgZGVzY3JpcHRpb24gb2YgdGhlICB8IG1lbWJlciBv ZiBDS19JTkZPICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBs aWJyYXJ5ICAgICAgICAgICAgIHwgc3RydWN0dXJlLiAgSXQgaXMgYW4gfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCBVVEYtOCBzdHJpbmcuICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgIHwgbGlicmFyeS1tYW51ZmFjdHVyZXIgfCBJRCBv ZiB0aGUgQ3J5cHRva2kgIHwgIm1hbnVmYWN0dXJlcklEIiAgICAgfA0KDQoN Cg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwg MjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAg ICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICB8ICAgICAgICAgICAgICAgICAg ICAgIHwgbGlicmFyeSAgICAgICAgICAgICB8IG1lbWJlciBvZiB0aGUgICAg ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51ZmFjdHVy ZXIgICAgICAgIHwgQ0tfSU5GTyBzdHJ1Y3R1cmUuICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBJdCBp cyBhbiBVVEYtOCAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8IHN0cmluZy4gICAgICAgICAgICAg IHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBsaWJyYXJ5 LXZlcnNpb24gICAgICB8IENyeXB0b2tpIGxpYnJhcnkgICAgfCAibGlicmFy eVZlcnNpb24iICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwg dmVyc2lvbiBudW1iZXIgICAgICB8IG1lbWJlciBvZiBDS19JTkZPICAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQogICB8IG1hbnVmYWN0dXJlciAgICAgICAgIHwgSUQg b2YgdGhlIHRva2VuICAgICB8ICJtYW51ZmFjdHVyZXJJRCIgICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51ZmFjdHVyZXIgICAgICAg IHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBDS19UT0tFTl9JTkZP ICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8IHN0cnVjdHVyZS4gIEl0IGlzIGFuIHwNCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg VVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICB8IG1vZGVsICAgICAgICAgICAgICAgIHwgdG9rZW4gbW9k ZWwgICAgICAgICB8ICJtb2RlbCIgbWVtYmVyIG9mICAgIHwNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgQ0tf VE9LRU5fSU5GTyAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1Y3R1cmUuICBJdCBpcyBh biB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8IFVURi04IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgfCBvYmplY3QgICAgICAgICAgICAgICB8 IGRlc2NyaXB0aW9uIChuYW1lKSAgfCAiQ0tBX0xBQkVMIiBvYmplY3QgICB8 DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgb2YgdGhlIG9iamVjdCAg ICAgICB8IGF0dHJpYnV0ZS4gIEl0IGlzIGFuIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgVVRGLTggc3Ry aW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8IHNlcmlhbCAgICAgICAgICAgICAgIHwgY2hhcmFjdGVyLXN0cmluZyAg ICB8ICJzZXJpYWxOdW1iZXIiICAgICAgIHwNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCBzZXJpYWwgbnVtYmVyIG9mICAgIHwgbWVtYmVyIG9mICAg ICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHRoZSB0 b2tlbiAgICAgICAgICAgfCBDS19UT0tFTl9JTkZPICAgICAgICB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 IHN0cnVjdHVyZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KICAgfCBzbG90LWRlc2NyaXB0aW9uICAgICB8IHNsb3QgZGVz Y3JpcHRpb24gICAgfCAic2xvdERlc2NyaXB0aW9uIiAgICB8DQogICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IG1l bWJlciBvZiAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgQ0tfU0xPVF9JTkZPICAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCBzdHJ1Y3R1cmUuICBJdCBpcyBhbiB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IFVURi04 IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgfCBzbG90LWlkICAgICAgICAgICAgICB8IENyeXB0b2tpLWFzc2ln bmVkICAgfCBkZWNpbWFsIG51bWJlciBvZiAgICB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgdmFsdWUgdGhhdCAgICAgICAgICB8ICJDS19TTE9U X0lEIiB0eXBlICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBp ZGVudGlmaWVzIGEgc2xvdCAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IHNsb3QtbWFudWZh Y3R1cmVyICAgIHwgSUQgb2YgdGhlIHNsb3QgICAgICB8ICJtYW51ZmFjdHVy ZXJJRCIgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51 ZmFjdHVyZXIgICAgICAgIHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0KICAg fCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fCBDS19TTE9UX0lORk8gICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IHN0cnVjdHVyZS4gIEl0 IGlzIGFuIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgVVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IHRva2VuICAgICAgICAgICAg ICAgIHwgYXBwbGljYXRpb24tZGVmaW5lZCB8ICJsYWJlbCIgbWVtYmVyIG9m ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBsYWJlbCwgYXNz aWduZWQgICAgIHwgdGhlIENLX1RPS0VOX0lORk8gICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8IGR1cmluZyB0b2tlbiAgICAgICAgfCBzdHJ1 Y3R1cmUuICBJdCBpcyBhbiB8DQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBpbml0aWFsaXphdGlvbiAg ICAgIHwgVVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQogICB8IHR5cGUgICAgICAgICAgICAgICAgIHwgb2Jq ZWN0IGNsYXNzICh0eXBlKSB8ICJDS0FfQ0xBU1MiIG9iamVjdCAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgYXR0cmlidXRlICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQoNCiAgICBUYWJsZSAxOiBNYXBwaW5nIGJldHdlZW4gVVJJ IHBhdGggY29tcG9uZW50IGF0dHJpYnV0ZXMgYW5kIFBLQ1MjMTENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpY2F0aW9uIG5hbWVzDQoN CiAgIFRoZSBxdWVyeSBjb21wb25lbnQgYXR0cmlidXRlICJwaW4tc291cmNl IiBzcGVjaWZpZXMgd2hlcmUgdGhlDQogICBhcHBsaWNhdGlvbiBvciBsaWJy YXJ5IHNob3VsZCBmaW5kIHRoZSBub3JtYWwgdXNlcidzIHRva2VuIFBJTiwg dGhlDQogICAicGluLXZhbHVlIiBhdHRyaWJ1dGUgcHJvdmlkZXMgdGhlIG5v cm1hbCB1c2VyJ3MgUElOIHZhbHVlIGRpcmVjdGx5LA0KICAgaWYgbmVlZGVk LCBhbmQgdGhlICJtb2R1bGUtbmFtZSIgYW5kICJtb2R1bGUtcGF0aCIgYXR0 cmlidXRlcyBtb2RpZnkNCiAgIGRlZmF1bHQgc2V0dGluZ3MgZm9yIGFjY2Vz c2luZyBQS0NTIzExIHByb3ZpZGVycy4gIEZvciB0aGUgZGVmaW5pdGlvbg0K ICAgb2YgYSAibm9ybWFsIHVzZXIiLCBzZWUgW1BLQ1MxMV0uDQoNCiAgIFRo ZSBBQk5GIHJ1bGVzIGFib3ZlIGlzIGEgYmVzdCBlZmZvcnQgZGVmaW5pdGlv biBhbmQgdGhpcyBwYXJhZ3JhcGgNCiAgIHNwZWNpZmllcyBhZGRpdGlvbmFs IGNvbnN0cmFpbnRzLiAgVGhlIFBLQ1MjMTEgVVJJIE1VU1QgTk9UIGNvbnRh aW4NCiAgIGR1cGxpY2F0ZSBhdHRyaWJ1dGVzIG9mIHRoZSBzYW1lIG5hbWUg aW4gdGhlIFVSSSBwYXRoIGNvbXBvbmVudC4gIEl0DQogICBtZWFucyB0aGF0 IGVhY2ggYXR0cmlidXRlIG1heSBiZSBwcmVzZW50IGF0IG1vc3Qgb25jZSBp biB0aGUgUEtDUyMxMQ0KICAgVVJJIHBhdGguICBBc2lkZSBmcm9tIHRoZSBx dWVyeSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwNCiAg IGR1cGxpY2F0ZSAodmVuZG9yKSBhdHRyaWJ1dGVzIE1BWSBiZSBwcmVzZW50 IGluIHRoZSBVUkkgcXVlcnkNCiAgIGNvbXBvbmVudCBhbmQgaXQgaXMgdXAg dG8gdGhlIFVSSSBjb25zdW1lciB0byBkZWNpZGUgb24gaG93IHRvIGRlYWwN CiAgIHdpdGggc3VjaCBkdXBsaWNhdGVzLg0KDQogICBUaGUgd2hvbGUgdmFs dWUgb2YgdGhlICJpZCIgYXR0cmlidXRlIFNIT1VMRCBiZSBwZXJjZW50LWVu Y29kZWQgc2luY2UNCiAgIGl0IGlzIHN1cHBvc2VkIHRvIGJlIGhhbmRsZWQg YXMgYXJiaXRyYXJ5IGJpbmFyeSBkYXRhLg0KDQogICBUaGUgImxpYnJhcnkt dmVyc2lvbiIgYXR0cmlidXRlIHJlcHJlc2VudHMgdGhlIG1ham9yIGFuZCBt aW5vcg0KICAgdmVyc2lvbiBudW1iZXIgb2YgdGhlIGxpYnJhcnkgYW5kIGl0 cyBmb3JtYXQgaXMgIk0uTiIuICBCb3RoIG51bWJlcnMNCiAgIGFyZSBvbmUg Ynl0ZSBpbiBzaXplLCBzZWUgdGhlICJsaWJyYXJ5VmVyc2lvbiIgbWVtYmVy IG9mIHRoZSBDS19JTkZPDQogICBzdHJ1Y3R1cmUgaW4gW1BLQ1MxMV0gZm9y IG1vcmUgaW5mb3JtYXRpb24uICBWYWx1ZSAiTSIgZm9yIHRoZQ0KICAgYXR0 cmlidXRlIE1VU1QgYmUgaW50ZXJwcmV0ZWQgYXMgIk0iIGZvciB0aGUgbWFq b3IgYW5kICIwIiBmb3IgdGhlDQogICBtaW5vciB2ZXJzaW9uIG9mIHRoZSBs aWJyYXJ5LiAgSWYgdGhlIGF0dHJpYnV0ZSBpcyBwcmVzZW50IHRoZSBtYWpv cg0KICAgdmVyc2lvbiBudW1iZXIgaXMgUkVRVUlSRUQuICBCb3RoICJNIiBh bmQgIk4iIE1VU1QgYmUgZGVjaW1hbA0KICAgbnVtYmVycy4NCg0KICAgU2xv dCBJRCBpcyBhIENyeXB0b2tpLWFzc2lnbmVkIG51bWJlciB0aGF0IGlzIG5v dCBndWFyYW50ZWVkIHN0YWJsZQ0KICAgYWNyb3NzIFBLQ1MjMTEgbW9kdWxl IGluaXRpYWxpemF0aW9ucy4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBjZXJ0YWlu DQogICBsaWJyYXJpZXMgYW5kIG1vZHVsZXMgd2hpY2ggcHJvdmlkZSBzdGFi bGUgc2xvdCBpZGVudGlmaWVycy4gIEZvcg0KICAgdGhlc2UgY2FzZXMsIHdo ZW4gdGhlIHNsb3QgZGVzY3JpcHRpb24gYW5kIG1hbnVmYWN0dXJlciBJRCBp cyBub3QNCiAgIHN1ZmZpY2llbnQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYSBz cGVjaWZpYyByZWFkZXIsIHRoZSBzbG90IElEIE1BWSBiZQ0KICAgdXNlZCB0 byBpbmNyZWFzZSB0aGUgcHJlY2lzaW9uIG9mIHRoZSB0b2tlbiBpZGVudGlm aWNhdGlvbi4gIEluIG90aGVyDQogICBzY2VuYXJpb3MsIHVzaW5nIHRoZSBz bG90IElEcyBpcyBsaWtlbHkgdG8gY2F1c2UgdXNhYmlsaXR5IGlzc3Vlcy4N Cg0KICAgQW4gZW1wdHkgUEtDUyMxMSBVUkkgcGF0aCBhdHRyaWJ1dGUgdGhh dCBkb2VzIGFsbG93IGZvciBhbiBlbXB0eQ0KICAgdmFsdWUgbWF0Y2hlcyBh IGNvcnJlc3BvbmRpbmcgc3RydWN0dXJlIG1lbWJlciBvciBhbiBvYmplY3Qg YXR0cmlidXRlDQogICB3aXRoIGFuIGVtcHR5IHZhbHVlLiAgTm90ZSB0aGF0 IGFjY29yZGluZyB0byB0aGUgUEtDUyMxMQ0KDQoNCg0KUGVjaGFuZWMgJiBN b2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg VGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIw MTUNCg0KDQogICBzcGVjaWZpY2F0aW9uIFtQS0NTMTFdLCBlbXB0eSBjaGFy YWN0ZXIgdmFsdWVzIGluIGEgUEtDUyMxMSBBUEkNCiAgIHByb2R1Y2VyIG11 c3QgYmUgcGFkZGVkIHdpdGggc3BhY2VzIGFuZCBzaG91bGQgbm90IGJlIE5V TEwNCiAgIHRlcm1pbmF0ZWQuDQoNCjMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVt ZSBRdWVyeSBBdHRyaWJ1dGUgU2VtYW50aWNzDQoNCiAgIEFuIGFwcGxpY2F0 aW9uIE1BWSBhbHdheXMgYXNrIGZvciBhIFBJTiBieSBhbnkgbWVhbnMgaXQg ZGVjaWRlcyB0by4NCiAgIFdoYXQgaXMgbW9yZSwgaW4gb3JkZXIgbm90IHRv IGxpbWl0IFBLQ1MjMTEgVVJJIHBvcnRhYmlsaXR5IHRoZSAicGluLQ0KICAg c291cmNlIiBhdHRyaWJ1dGUgdmFsdWUgZm9ybWF0IGFuZCBpbnRlcnByZXRh dGlvbiBpcyBsZWZ0IHRvIGJlDQogICBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp Yy4gIEhvd2V2ZXIsIHRoZSBmb2xsb3dpbmcgcnVsZXMgU0hPVUxEIGJlDQog ICBmb2xsb3dlZCBpbiBkZXNjZW5kaW5nIG9yZGVyIGZvciB0aGUgdmFsdWUg b2YgdGhlICJwaW4tc291cmNlIg0KICAgYXR0cmlidXRlOg0KDQogICBvICBp ZiB0aGUgdmFsdWUgcmVwcmVzZW50cyBhIGxvY2FsIGFic29sdXRlIHBhdGgg dGhlIGltcGxlbWVudGF0aW9uDQogICAgICBTSE9VTEQgdXNlIGl0IGFzIGEg UElOIGZpbGUgY29udGFpbmluZyB0aGUgUElOIHZhbHVlDQoNCiAgIG8gIGlm IHRoZSB2YWx1ZSBjb250YWlucyAifDxhYnNvbHV0ZS1jb21tYW5kLXBhdGg+ IiB0aGUNCiAgICAgIGltcGxlbWVudGF0aW9uIFNIT1VMRCByZWFkIHRoZSBQ SU4gZnJvbSB0aGUgb3V0cHV0IG9mIGFuDQogICAgICBhcHBsaWNhdGlvbiBz cGVjaWZpZWQgd2l0aCBhYnNvbHV0ZSBwYXRoICI8YWJzb2x1dGUtY29tbWFu ZC0NCiAgICAgIHBhdGg+Ii4gIE5vdGUgdGhhdCBjaGFyYWN0ZXIgInwiIHJl cHJlc2VudGluZyBhIHBpcGUgZG9lcyBub3QgaGF2ZQ0KICAgICAgdG8gYmUg cGVyY2VudCBlbmNvZGVkIGluIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhl IFBLQ1MjMTEgVVJJLg0KDQogICBvICBpZiB0aGUgdmFsdWUgcmVwcmVzZW50 cyBhIFVSSSBpdCBTSE9VTEQgYmUgdHJlYXRlZCBhcyBhbiBvYmplY3QNCiAg ICAgIGNvbnRhaW5pbmcgdGhlIFBJTi4gIFN1Y2ggYSBVUkkgbWF5IGJlICJm aWxlOiIsICJodHRwczoiLCBhbm90aGVyDQogICAgICBQS0NTIzExIFVSSSwg b3Igc29tZXRoaW5nIGVsc2UuDQoNCiAgIG8gIGludGVycHJldCB0aGUgdmFs dWUgYXMgbmVlZGVkIGluIGFuIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCB3 YXkNCg0KICAgSWYgYSBVUkkgY29udGFpbnMgYm90aCAicGluLXNvdXJjZSIg YW5kICJwaW4tdmFsdWUiIHF1ZXJ5IGF0dHJpYnV0ZXMNCiAgIHRoZSBVUkkg U0hPVUxEIGJlIHJlZnVzZWQgYXMgaW52YWxpZC4NCg0KICAgVXNlIG9mIHRo ZSAicGluLXZhbHVlIiBhdHRyaWJ1dGUgbWF5IGhhdmUgc2VjdXJpdHkgcmVs YXRlZA0KICAgY29uc2VxdWVuY2VzLiAgU2VjdGlvbiA3IHNob3VsZCBiZSBj b25zdWx0ZWQgYmVmb3JlIHRoaXMgYXR0cmlidXRlIGlzDQogICBldmVyIHVz ZWQuICBTdGFuZGFyZCBwZXJjZW50IGVuY29kaW5nIHJ1bGVzIFNIT1VMRCBi ZSBmb2xsb3dlZCBmb3INCiAgIHRoZSBhdHRyaWJ1dGUgdmFsdWUuDQoNCiAg IEEgY29uc3VtZXIgb2YgUEtDUyMxMSBVUklzIE1BWSBtb2RpZnkgZGVmYXVs dCBzZXR0aW5ncyBmb3IgYWNjZXNzaW5nDQogICBhIFBLQ1MjMTEgcHJvdmlk ZXIgb3IgcHJvdmlkZXJzIGJ5IGFjY2VwdGluZyBxdWVyeSBjb21wb25lbnQN CiAgIGF0dHJpYnV0ZXMgIm1vZHVsZS1uYW1lIiBhbmQgIm1vZHVsZS1wYXRo Ii4iDQoNCiAgIFByb2Nlc3NpbmcgdGhlIFVSSSBxdWVyeSBtb2R1bGUgYXR0 cmlidXRlcyBTSE9VTEQgZm9sbG93IHRoZXNlIHJ1bGVzOg0KDQogICBvICBh dHRyaWJ1dGUgIm1vZHVsZS1uYW1lIiBTSE9VTEQgY29udGFpbiBhIGNhc2Ut aW5zZW5zaXRpdmUgUEtDUyMxMQ0KICAgICAgbW9kdWxlIG5hbWUgKG5vdCBw YXRoIG5vciBmaWxlbmFtZSkgd2l0aG91dCBzeXN0ZW0gc3BlY2lmaWMNCiAg ICAgIGFmZml4ZXMuICBTdWNoIGFmZml4IGNvdWxkIGJlIGFuICIuc28iIG9y ICIuRExMIiBzdWZmaXgsIG9yIGENCiAgICAgICJsaWIiIHByZWZpeCwgZm9y IGV4YW1wbGUuICBOb3QgdXNpbmcgc3lzdGVtIHNwZWNpZmljIGFmZml4ZXMg aXMNCiAgICAgIGV4cGVjdGVkIHRvIGluY3JlYXNlIHBvcnRhYmlsaXR5IG9m IFBLQ1MjMTEgVVJJcyBhbW9uZyBkaWZmZXJlbnQNCiAgICAgIHN5c3RlbXMu ICBBIFVSSSBjb25zdW1lciBzZWFyY2hpbmcgZm9yIFBLQ1MjMTEgbW9kdWxl cyBTSE9VTEQgdXNlDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAg IEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2Ug OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBV UkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgICAg IGEgc3lzdGVtIG9yIGFwcGxpY2F0aW9uIHNwZWNpZmljIGxvY2F0aW9ucyB0 byBmaW5kIG1vZHVsZXMgYmFzZWQNCiAgICAgIG9uIHRoZSBuYW1lIHByb3Zp ZGVkIGluIHRoZSBhdHRyaWJ1dGUuDQoNCiAgIG8gIGF0dHJpYnV0ZSAibW9k dWxlLXBhdGgiIFNIT1VMRCBjb250YWluIGEgc3lzdGVtIHNwZWNpZmljIGFi c29sdXRlDQogICAgICBwYXRoIHRvIHRoZSBQS0NTIzExIG1vZHVsZSwgb3Ig YSBzeXN0ZW0gc3BlY2lmaWMgYWJzb2x1dGUgcGF0aCB0bw0KICAgICAgdGhl IGRpcmVjdG9yeSBvZiB3aGVyZSBQS0NTIzExIG1vZHVsZXMgYXJlIGxvY2F0 ZWQuICBGb3Igc2VjdXJpdHkNCiAgICAgIHJlYXNvbnMsIGEgVVJJIHdpdGgg YSByZWxhdGl2ZSBwYXRoIGluIHRoaXMgYXR0cmlidXRlIFNIT1VMRCBiZQ0K ICAgICAgcmVqZWN0ZWQuDQoNCiAgIG8gIHRoZSBVUkkgY29uc3VtZXIgTUFZ IHJlZnVzZSB0byBhY2NlcHQgZWl0aGVyIG9mIHRoZSBhdHRyaWJ1dGVzLCBv cg0KICAgICAgYm90aC4gIElmIHVzZSBvZiBhbiBhdHRyaWJ1dGUgcHJlc2Vu dCBpbiB0aGUgVVJJIHN0cmluZyBpcyBub3QNCiAgICAgIGFjY2VwdGVkIGEg d2FybmluZyBtZXNzYWdlIFNIT1VMRCBiZSBwcmVzZW50ZWQgdG8gdGhlIHBy b3ZpZGVyIG9mDQogICAgICB0aGUgVVJJLg0KDQogICBvICBpZiBlaXRoZXIg b2YgdGhlIG1vZHVsZSBhdHRyaWJ1dGVzIGlzIHByZXNlbnQsIG9ubHkgdGhv c2UgbW9kdWxlcw0KICAgICAgZm91bmQgbWF0Y2hpbmcgdGhlc2UgcXVlcnkg YXR0cmlidXRlcyBTSE9VTEQgYmUgdXNlZCB0byBzZWFyY2ggZm9yDQogICAg ICBhbiBlbnRpdHkgcmVwcmVzZW50ZWQgYnkgdGhlIFVSSS4NCg0KICAgbyAg dXNlIG9mIHRoZSBtb2R1bGUgYXR0cmlidXRlcyBkb2VzIG5vdCBzdXBwcmVz cyBtYXRjaGluZyBvZiBhbnkNCiAgICAgIG90aGVyIFVSSSBwYXRoIGNvbXBv bmVudCBhdHRyaWJ1dGVzIHByZXNlbnQgaW4gYSBVUkkuDQoNCiAgIG8gIHNl bWFudGljcyBvZiB1c2luZyBib3RoIGF0dHJpYnV0ZXMgaW4gdGhlIHNhbWUg VVJJIHN0cmluZyBpcw0KICAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMg YnV0IHN1Y2ggdXNlIFNIT1VMRCBiZSBhdm9pZGVkLiAgQXR0cmlidXRlDQog ICAgICAibW9kdWxlLW5hbWUiIGlzIHByZWZlcnJlZCB0byAibW9kdWxlLXBh dGgiIGR1ZSB0byBpdHMgc3lzdGVtDQogICAgICBpbmRlcGVuZGVudCBuYXR1 cmUgYnV0IHRoZSBsYXR0ZXIgbWF5IGJlIG1vcmUgc3VpdGFibGUgZm9yDQog ICAgICBkZXZlbG9wbWVudCBhbmQgZGVidWdnaW5nLg0KDQogICBvICBhIFVS SSBNVVNUIE5PVCBjb250YWluIG11bHRpcGxlIG1vZHVsZSBhdHRyaWJ1dGVz IG9mIHRoZSBzYW1lDQogICAgICBuYW1lLg0KDQogICBVc2Ugb2YgdGhlIG1v ZHVsZSBhdHRyaWJ1dGVzIG1heSBoYXZlIHNlY3VyaXR5IHJlbGF0ZWQgY29u c2VxdWVuY2VzLg0KICAgU2VjdGlvbiA3IHNob3VsZCBiZSBjb25zdWx0ZWQg YmVmb3JlIHRoZXNlIGF0dHJpYnV0ZXMgYXJlIGV2ZXIgdXNlZC4NCg0KICAg QSB3b3JkICJtb2R1bGUiIHdhcyBjaG9zZW4gb3ZlciB3b3JkICJsaWJyYXJ5 IiBpbiB0aGVzZSBxdWVyeQ0KICAgYXR0cmlidXRlIG5hbWVzIHRvIGF2b2lk IGNvbmZ1c2lvbiB3aXRoIHNlbWFudGljYWxseSBkaWZmZXJlbnQNCiAgIGxp YnJhcnkgYXR0cmlidXRlcyB1c2VkIGluIHRoZSBVUkkgcGF0aCBjb21wb25l bnQuDQoNCjMuNS4gIFBLQ1MjMTEgVVJJIE1hdGNoaW5nIEd1aWRlbGluZXMN Cg0KICAgVGhlIFBLQ1MjMTEgVVJJIGNhbiBpZGVudGlmeSBQS0NTIzExIHN0 b3JhZ2Ugb2JqZWN0cywgdG9rZW5zLCBzbG90cywNCiAgIG9yIENyeXB0b2tp IGxpYnJhcmllcy4gIE5vdGUgdGhhdCBzaW5jZSBhIFVSSSBtYXkgaWRlbnRp ZnkgZm91cg0KICAgZGlmZmVyZW50IHR5cGVzIG9mIGVudGl0aWVzIHRoZSBj b250ZXh0IHdpdGhpbiB3aGljaCB0aGUgVVJJIGlzIHVzZWQNCiAgIG1heSBi ZSBuZWVkZWQgdG8gZGV0ZXJtaW5lIHRoZSB0eXBlLiAgRm9yIGV4YW1wbGUs IGEgVVJJIHdpdGggb25seQ0KICAgbGlicmFyeSBhdHRyaWJ1dGVzIG1heSBl aXRoZXIgcmVwcmVzZW50IGFsbCBvYmplY3RzIGluIGFsbCB0b2tlbnMgaW4N CiAgIGFsbCBDcnlwdG9raSBsaWJyYXJpZXMgaWRlbnRpZmllZCBieSB0aGUg VVJJLCBhbGwgdG9rZW5zIGluIHRob3NlDQogICBsaWJyYXJpZXMsIG9yIGp1 c3QgdGhlIGxpYnJhcmllcy4NCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZh dCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUg UEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0K DQoNCiAgIFRoZSBmb2xsb3dpbmcgZ3VpZGVsaW5lcyBjYW4gaGVscCBhIFBL Q1MjMTEgVVJJIGNvbnN1bWVyIChlZy4gYW4NCiAgIGFwcGxpY2F0aW9uIGFj Y2VwdGluZyBQS0NTIzExIFVSSXMpIHRvIG1hdGNoIHRoZSBVUkkgd2l0aCB0 aGUgZGVzaXJlZA0KICAgcmVzb3VyY2UuDQoNCiAgIG8gIHRoZSBjb25zdW1l ciBNVVNUIGtub3cgd2hldGhlciB0aGUgVVJJIGlzIHRvIGlkZW50aWZ5IFBL Q1MjMTENCiAgICAgIHN0b3JhZ2Ugb2JqZWN0KHMpLCB0b2tlbihzKSwgc2xv dChzKSwgb3IgQ3J5cHRva2kgcHJvZHVjZXIocykuDQoNCiAgIG8gIGlmIHRo ZSBjb25zdW1lciBpcyB3aWxsaW5nIHRvIGFjY2VwdCBxdWVyeSBjb21wb25l bnQgbW9kdWxlDQogICAgICBhdHRyaWJ1dGVzIG9ubHkgdGhvc2UgUEtDUyMx MSBwcm92aWRlcnMgbWF0Y2hpbmcgdGhlc2UgYXR0cmlidXRlcw0KICAgICAg U0hPVUxEIGJlIHdvcmtlZCB3aXRoLiAgU2VlIFNlY3Rpb24gMy40IGZvciBt b3JlIGluZm9ybWF0aW9uLg0KDQogICBvICBhbiB1bnJlY29nbml6ZWQgYXR0 cmlidXRlIGluIHRoZSBVUkkgcGF0aCBjb21wb25lbnQsIGluY2x1ZGluZyBh DQogICAgICB2ZW5kb3Igc3BlY2lmaWMgYXR0cmlidXRlLCBTSE9VTEQgcmVz dWx0IGluIGFuIGVtcHR5IHNldCBvZg0KICAgICAgbWF0Y2hlZCByZXNvdXJj ZXMuICBUaGUgY29uc3VtZXIgU0hPVUxEIGNvbnNpZGVyIHdoZXRoZXIgYW4g ZXJyb3INCiAgICAgIG1lc3NhZ2UgcHJlc2VudGVkIHRvIHRoZSB1c2VyIGlz IGFwcHJvcHJpYXRlIGluIHN1Y2ggYSBjYXNlLg0KDQogICBvICBhbiB1bnJl Y29nbml6ZWQgYXR0cmlidXRlIGluIHRoZSBVUkkgcXVlcnkgU0hPVUxEIGJl IGlnbm9yZWQuICBUaGUNCiAgICAgIGNvbnN1bWVyIFNIT1VMRCBjb25zaWRl ciB3aGV0aGVyIGEgd2FybmluZyBtZXNzYWdlIHByZXNlbnRlZCB0bw0KICAg ICAgdGhlIHVzZXIgaXMgYXBwcm9wcmlhdGUgaW4gc3VjaCBhIGNhc2UuDQoN CiAgIG8gIGFuIGF0dHJpYnV0ZSBub3QgcHJlc2VudCBpbiB0aGUgVVJJIHBh dGggYnV0IGtub3duIHRvIGEgY29uc3VtZXINCiAgICAgIG1hdGNoZXMgZXZl cnl0aGluZy4gIEVhY2ggYWRkaXRpb25hbCBhdHRyaWJ1dGUgcHJlc2VudCBp biB0aGUgVVJJDQogICAgICBwYXRoIGZ1cnRoZXIgcmVzdHJpY3RzIHRoZSBz ZWxlY3Rpb24uDQoNCiAgIG8gIGEgbG9naWNhbCBleHRlbnNpb24gb2YgdGhl IGFib3ZlIGlzIHRoYXQgYW4gZW1wdHkgVVJJIHBhdGggbWF0Y2hlcw0KICAg ICAgZXZlcnl0aGluZy4gIEZvciBleGFtcGxlLCBpZiB1c2VkIHRvIGlkZW50 aWZ5IHN0b3JhZ2Ugb2JqZWN0cyBpdA0KICAgICAgbWF0Y2hlcyBhbGwgYWNj ZXNzaWJsZSBvYmplY3RzIGluIGFsbCB0b2tlbnMgcHJvdmlkZWQgYnkgYWxs DQogICAgICBQS0NTIzExIEFQSSBwcm9kdWNlcnMgZm91bmQgaW4gdGhlIHN5 c3RlbS4NCg0KICAgbyAgbm90ZSB0aGF0IHVzZSBvZiBQSU4gYXR0cmlidXRl cyBtYXkgY2hhbmdlIHRoZSBzZXQgb2Ygc3RvcmFnZQ0KICAgICAgb2JqZWN0 cyB2aXNpYmxlIHRvIHRoZSBjb25zdW1lci4NCg0KICAgbyAgaW4gYWRkaXRp b24gdG8gcXVlcnkgY29tcG9uZW50IGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0 aGlzDQogICAgICBkb2N1bWVudCwgdmVuZG9yIHNwZWNpZmljIHF1ZXJ5IGF0 dHJpYnV0ZXMgbWF5IGNvbnRhaW4gZnVydGhlcg0KICAgICAgaW5mb3JtYXRp b24gYWJvdXQgaG93IHRvIHBlcmZvcm0gdGhlIHNlbGVjdGlvbiBvciBvdGhl ciByZWxhdGVkDQogICAgICBpbmZvcm1hdGlvbi4NCg0KICAgQXMgbm90ZWQg aW4gU2VjdGlvbiA2LCB0aGUgUEtDUyMxMSBzcGVjaWZpY2F0aW9uIGlzIG5v dCBjbGVhciBhYm91dA0KICAgaG93IHRvIG5vcm1hbGl6ZSBVVEYtOCBlbmNv ZGVkIFVuaWNvZGUgY2hhcmFjdGVycyBbUkZDMzYyOV0uICBUaG9zZQ0KICAg d2hvIGRpc2NvdmVyIGEgbmVlZCB0byB1c2UgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBBU0NJSSByZXBlcnRvaXJlDQogICBzaG91bGQgYmUgY2F1dGlvdXMs IGNvbnNlcnZhdGl2ZSwgYW5kIGV4cGVuZCBleHRyYSBlZmZvcnQgdG8gYmUg c3VyZQ0KICAgdGhleSBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcgYW5kIHRo YXQgZmFpbHVyZSB0byBkbyBzbyBtYXkgY3JlYXRlDQogICBib3RoIG9wZXJh dGlvbmFsIGFuZCBzZWN1cml0eSByaXNrcy4gIEl0IG1lYW5zIHRoYXQgd2hl biBtYXRjaGluZw0KICAgVVRGLTggc3RyaW5nIGJhc2VkIGF0dHJpYnV0ZXMg KHNlZSBUYWJsZSAxKSB3aXRoIHN1Y2ggY2hhcmFjdGVycywNCiAgIG5vcm1h bGl6aW5nIGFsbCBVVEYtOCBzdHJpbmdzIGJlZm9yZSBzdHJpbmcgY29tcGFy aXNvbiBtYXkgYmUgdGhlDQogICBvbmx5IHNhZmUgYXBwcm9hY2guICBGb3Ig ZXhhbXBsZSwgZm9yIG9iamVjdHMgKGtleXMpIGl0IG1lYW5zIHRoYXQNCiAg IFBLQ1MjMTEgYXR0cmlidXRlIHNlYXJjaCB0ZW1wbGF0ZSB3b3VsZCBvbmx5 IGNvbnRhaW4gYXR0cmlidXRlcyB0aGF0DQogICBhcmUgbm90IFVURi04IHN0 cmluZ3MgYW5kIGFub3RoZXIgcGFzcyB0aHJvdWdoIHJldHVybmVkIG9iamVj dHMgaXMNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJl cyBKdWx5IDgsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hl bWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgdGhlbiBuZWVk ZWQgZm9yIFVURi04IHN0cmluZyBjb21wYXJpc29uIGFmdGVyIHRoZSBub3Jt YWxpemF0aW9uIGlzDQogICBhcHBsaWVkLg0KDQozLjYuICBQS0NTIzExIFVS SSBDb21wYXJpc29uDQoNCiAgIENvbXBhcmlzb24gb2YgdHdvIFVSSXMgaXMg YSB3YXkgb2YgZGV0ZXJtaW5pbmcgd2hldGhlciB0aGUgVVJJcyBhcmUNCiAg IGVxdWl2YWxlbnQgd2l0aG91dCBjb21wYXJpbmcgdGhlIGFjdHVhbCByZXNv dXJjZSB0aGUgVVJJcyBwb2ludCB0by4NCiAgIFRoZSBjb21wYXJpc29uIG9m IFVSSXMgYWltcyB0byBtaW5pbWl6ZSBmYWxzZSBuZWdhdGl2ZXMgd2hpbGUN CiAgIHN0cmljdGx5IGF2b2lkaW5nIGZhbHNlIHBvc2l0aXZlcy4gIFdoZW4g d29ya2luZyB3aXRoIFVURi04IHN0cmluZ3MNCiAgIHdpdGggY2hhcmFjdGVy cyBvdXRzaWRlIHRoZSBBU0NJSSBjaGFyYWN0ZXIgc2V0cywgc2VlIGltcG9y dGFudA0KICAgY2F2ZWF0cyBpbiBTZWN0aW9uIDMuNSBhbmQgU2VjdGlvbiA2 Lg0KDQogICBUd28gUEtDUyMxMSBVUklzIGFyZSBzYWlkIHRvIGJlIGVxdWFs IGlmIFVSSXMgYXMgY2hhcmFjdGVyIHN0cmluZ3MNCiAgIGFyZSBpZGVudGlj YWwgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNi4yLjEgb2YgW1JGQzM5ODZd LCBvciBpZiBib3RoDQogICBmb2xsb3dpbmcgcnVsZXMgYXJlIGZ1bGZpbGxl ZDoNCg0KICAgbyAgc2V0IG9mIGF0dHJpYnV0ZXMgcHJlc2VudCBpbiB0aGUg VVJJIGlzIGVxdWFsLiAgTm90ZSB0aGF0IHRoZQ0KICAgICAgb3JkZXJpbmcg b2YgYXR0cmlidXRlcyBpbiB0aGUgVVJJIHN0cmluZyBpcyBub3Qgc2lnbmlm aWNhbnQgZm9yDQogICAgICB0aGUgbWVjaGFuaXNtIG9mIGNvbXBhcmlzb24u DQoNCiAgIG8gIHZhbHVlcyBvZiByZXNwZWN0aXZlIGF0dHJpYnV0ZXMgYXJl IGVxdWFsIGJhc2VkIG9uIHJ1bGVzIHNwZWNpZmllZA0KICAgICAgYmVsb3cN Cg0KICAgVGhlIHJ1bGVzIGZvciBjb21wYXJpbmcgdmFsdWVzIG9mIHJlc3Bl Y3RpdmUgYXR0cmlidXRlcyBhcmU6DQoNCiAgIG8gIHZhbHVlcyBvZiBwYXRo IGNvbXBvbmVudCBhdHRyaWJ1dGVzICJsaWJyYXJ5LWRlc2NyaXB0aW9uIiwN CiAgICAgICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIsICJtYW51ZmFjdHVyZXIi LCAibW9kZWwiLCAib2JqZWN0IiwNCiAgICAgICJzZXJpYWwiLCAic2xvdC1k ZXNjcmlwdGlvbiIsICJzbG90LW1hbnVmYWN0dXJlciIsICJ0b2tlbiIsDQog ICAgICAidHlwZSIsIGFuZCBxdWVyeSBjb21wb25lbnQgYXR0cmlidXRlICJt b2R1bGUtbmFtZSIgTVVTVCBiZQ0KICAgICAgY29tcGFyZWQgdXNpbmcgYSBz aW1wbGUgc3RyaW5nIGNvbXBhcmlzb24gYXMgc3BlY2lmaWVkIGluDQogICAg ICBTZWN0aW9uIDYuMi4xIG9mIFtSRkMzOTg2XSBhZnRlciB0aGUgY2FzZSBh bmQgdGhlIHBlcmNlbnQtZW5jb2RpbmcNCiAgICAgIG5vcm1hbGl6YXRpb24g YXJlIGJvdGggYXBwbGllZCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2LjIu MiBvZg0KICAgICAgW1JGQzM5ODZdLg0KDQogICBvICB2YWx1ZSBvZiBhdHRy aWJ1dGUgImlkIiBNVVNUIGJlIGNvbXBhcmVkIHVzaW5nIHRoZSBzaW1wbGUg c3RyaW5nDQogICAgICBjb21wYXJpc29uIGFmdGVyIGFsbCBieXRlcyBhcmUg cGVyY2VudC1lbmNvZGVkIHVzaW5nIHVwcGVyY2FzZQ0KICAgICAgbGV0dGVy cyBmb3IgZGlnaXRzIEEtRi4NCg0KICAgbyAgdmFsdWUgb2YgYXR0cmlidXRl ICJsaWJyYXJ5LXZlcnNpb24iIE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGENCiAg ICAgIHNwZWNpZmljIHNjaGVtZS1iYXNlZCBub3JtYWxpemF0aW9uIHBlcm1p dHRlZCBieSBTZWN0aW9uIDYuMi4zIG9mDQogICAgICBbUkZDMzk4Nl0uICBU aGUgdmFsdWUgTVVTVCBiZSBzcGxpdCBpbnRvIGEgbWFqb3IgYW5kIG1pbm9y IHZlcnNpb24NCiAgICAgIHdpdGggY2hhcmFjdGVyICcuJyAoZG90KSBzZXJ2 aW5nIGFzIGEgZGVsaW1pdGVyLiAgTGlicmFyeSB2ZXJzaW9uDQogICAgICAi TSIgTVVTVCBiZSB0cmVhdGVkIGFzICJNIiBmb3IgdGhlIG1ham9yIHZlcnNp b24gYW5kICIwIiBmb3IgdGhlDQogICAgICBtaW5vciB2ZXJzaW9uLiAgUmVz dWx0aW5nIG1pbm9yIGFuZCBtYWpvciB2ZXJzaW9uIG51bWJlcnMgTVVTVCBi ZQ0KICAgICAgdGhlbiBzZXBhcmF0ZWx5IGNvbXBhcmVkIG51bWVyaWNhbGx5 Lg0KDQoNCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBp cmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNj aGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBvICB2YWx1 ZSBvZiBhdHRyaWJ1dGUgInNsb3QtaWQiIE1VU1QgYmUgcHJvY2Vzc2VkIGFz IGEgc3BlY2lmaWMNCiAgICAgIHNjaGVtZS1iYXNlZCBub3JtYWxpemF0aW9u IHBlcm1pdHRlZCBieSBTZWN0aW9uIDYuMi4zIG9mIFtSRkMzOTg2XQ0KICAg ICAgYW5kIGNvbXBhcmVkIG51bWVyaWNhbGx5Lg0KDQogICBvICB2YWx1ZSBv ZiAicGluLXNvdXJjZSIsIGlmIGRlZW1lZCBjb250YWluaW5nIHRoZSBmaWxl bmFtZSB3aXRoIHRoZQ0KICAgICAgUElOIHZhbHVlLCBNVVNUIGJlIGNvbXBh cmVkIHVzaW5nIHRoZSBzaW1wbGUgc3RyaW5nIGNvbXBhcmlzb24NCiAgICAg IGFmdGVyIHRoZSBmdWxsIHN5bnRheCBiYXNlZCBub3JtYWxpemF0aW9uIGFz IHNwZWNpZmllZCBpbg0KICAgICAgU2VjdGlvbiA2LjIuMiBvZiBbUkZDMzk4 Nl0gaXMgYXBwbGllZC4gIElmIHZhbHVlIG9mIHRoZSAicGluLQ0KICAgICAg c291cmNlIiBhdHRyaWJ1dGUgaXMgYmVsaWV2ZWQgdG8gYmUgb3ZlcmxvYWRl ZCB0aGUgY2FzZSBhbmQNCiAgICAgIHBlcmNlbnQtZW5jb2Rpbmcgbm9ybWFs aXphdGlvbiBTSE9VTEQgYmUgYXBwbGllZCBiZWZvcmUgdGhlIHZhbHVlcw0K ICAgICAgYXJlIGNvbXBhcmVkIGJ1dCB0aGUgZXhhY3QgbWVjaGFuaXNtIG9m IGNvbXBhcmlzb24gaXMgbGVmdCB0byB0aGUNCiAgICAgIGFwcGxpY2F0aW9u Lg0KDQogICBvICB2YWx1ZSBvZiBhdHRyaWJ1dGUgIm1vZHVsZS1wYXRoIiBN VVNUIGJlIGNvbXBhcmVkIHVzaW5nIHRoZSBzaW1wbGUNCiAgICAgIHN0cmlu ZyBjb21wYXJpc29uIGFmdGVyIHRoZSBmdWxsIHN5bnRheCBiYXNlZCBub3Jt YWxpemF0aW9uIGFzDQogICAgICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2LjIu MiBvZiBbUkZDMzk4Nl0gaXMgYXBwbGllZC4NCg0KICAgbyAgd2hlbiBjb21w YXJpbmcgdmVuZG9yIHNwZWNpZmljIGF0dHJpYnV0ZXMgdGhlIGNhc2UgYW5k IHBlcmNlbnQtDQogICAgICBlbmNvZGluZyBub3JtYWxpemF0aW9uIGFzIHNw ZWNpZmllZCBpbiBTZWN0aW9uIDYuMi4yIG9mIFtSRkMzOTg2XQ0KICAgICAg U0hPVUxEIGJlIGFwcGxpZWQgYmVmb3JlIHRoZSB2YWx1ZXMgYXJlIGNvbXBh cmVkIGJ1dCB0aGUgZXhhY3QNCiAgICAgIG1lY2hhbmlzbSBvZiBzdWNoIGEg Y29tcGFyaXNvbiBpcyBsZWZ0IHRvIHRoZSBhcHBsaWNhdGlvbi4NCg0KMy43 LiAgR2VuZXJhdGluZyBQS0NTIzExIFVSSXMNCg0KICAgV2hlbiBnZW5lcmF0 aW5nIFVSSXMgZm9yIFBLQ1MjMTEgcmVzb3VyY2VzIHRoZSBleGFjdCBzZXQg b2YNCiAgIGF0dHJpYnV0ZXMgdXNlZCBpbiBhIFVSSSBpcyBpbmhlcmVudGx5 IGNvbnRleHQgc3BlY2lmaWMuICBBIFBLQ1MjMTENCiAgIFVSSSB0ZW1wbGF0 ZSBbUkZDNjU3MF0gc3VwcG9ydCBNQVkgYmUgcHJvdmlkZWQgYnkgYSBVUkkg Z2VuZXJhdGluZw0KICAgYXBwbGljYXRpb24gdG8gbGlzdCBVUklzIHRvIGFj Y2VzcyB0aGUgc2FtZSByZXNvdXJjZShzKSBhZ2FpbiBpZiB0aGUNCiAgIHRl bXBsYXRlIGNhcHR1cmVkIHRoZSBuZWNlc3NhcnkgY29udGV4dC4NCg0KNC4g IEV4YW1wbGVzIG9mIFBLQ1MjMTEgVVJJcw0KDQogICBUaGlzIHNlY3Rpb24g Y29udGFpbnMgc29tZSBleGFtcGxlcyBvZiBob3cgUEtDUyMxMSB0b2tlbiBv YmplY3RzLA0KICAgdG9rZW5zLCBzbG90cywgYW5kIGxpYnJhcmllcyBjYW4g YmUgaWRlbnRpZmllZCB1c2luZyB0aGUgUEtDUyMxMSBVUkkNCiAgIHNjaGVt ZS4gIE5vdGUgdGhhdCBpbiBzb21lIG9mIHRoZSBmb2xsb3dpbmcgZXhhbXBs ZXMsIG5ld2xpbmVzIGFuZA0KICAgc3BhY2VzIHdlcmUgaW5zZXJ0ZWQgZm9y IGJldHRlciByZWFkYWJpbGl0eS4gIEFzIHNwZWNpZmllZCBpbg0KICAgQXBw ZW5kaXggQyBvZiBbUkZDMzk4Nl0sIHdoaXRlc3BhY2UgU0hPVUxEIGJlIGln bm9yZWQgd2hlbiBleHRyYWN0aW5nDQogICB0aGUgVVJJLiAgQWxzbyBub3Rl IHRoYXQgYWxsIHNwYWNlcyBhcyBwYXJ0IG9mIHRoZSBVUkkgYXJlIHBlcmNl bnQtDQogICBlbmNvZGVkLCBhcyBzcGVjaWZpZWQgaW4gQXBwZW5kaXggQSBv ZiBbUkZDMzk4Nl0uDQoNCiAgIEFuIGVtcHR5IFBLQ1MjMTEgVVJJIG1pZ2h0 IGJlIHVzZWZ1bCB0byBQS0NTIzExIGNvbnN1bWVycy4gIFNlZQ0KICAgU2Vj dGlvbiAzLjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gc2VtYW50aWNzIG9m IHN1Y2ggYSBVUkkuDQoNCiAgICAgcGtjczExOg0KDQoNCg0KDQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1 ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAg IEphbnVhcnkgMjAxNQ0KDQoNCiAgIE9uZSBvZiB0aGUgc2ltcGxlc3QgYW5k IG1vc3QgdXNlZnVsIGZvcm1zIG1pZ2h0IGJlIGEgUEtDUyMxMSBVUkkgdGhh dA0KICAgc3BlY2lmaWVzIG9ubHkgYW4gb2JqZWN0IGxhYmVsIGFuZCBpdHMg dHlwZS4gIFRoZSBkZWZhdWx0IHRva2VuIGlzDQogICB1c2VkIHNvIHRoZSBV UkkgZG9lcyBub3Qgc3BlY2lmeSBpdC4gIE5vdGUgdGhhdCB3aGVuIHNwZWNp ZnlpbmcNCiAgIHB1YmxpYyBvYmplY3RzLCBhIHRva2VuIFBJTiBtYXkgbm90 IGJlIHJlcXVpcmVkLg0KDQogICAgIHBrY3MxMTpvYmplY3Q9bXktcHVia2V5 O3R5cGU9cHVibGljDQoNCiAgIFdoZW4gYSBwcml2YXRlIGtleSBpcyBzcGVj aWZpZWQgZWl0aGVyIHRoZSAicGluLXNvdXJjZSIgYXR0cmlidXRlLA0KICAg InBpbi12YWx1ZSwgb3IgYW4gYXBwbGljYXRpb24gc3BlY2lmaWMgbWV0aG9k IHdvdWxkIGJlIHVzdWFsbHkgdXNlZC4NCiAgIE5vdGUgdGhhdCAnLycgaXMg bm90IHBlcmNlbnQtZW5jb2RlZCBpbiB0aGUgInBpbi1zb3VyY2UiIGF0dHJp YnV0ZQ0KICAgdmFsdWUgc2luY2UgdGhpcyBhdHRyaWJ1dGUgaXMgcGFydCBv ZiB0aGUgcXVlcnkgY29tcG9uZW50LCBub3QgdGhlDQogICBwYXRoLCBhbmQg dGh1cyBpcyBzZXBhcmF0ZWQgYnkgJz8nIGZyb20gdGhlIHJlc3Qgb2YgdGhl IFVSSS4NCg0KICAgICBwa2NzMTE6b2JqZWN0PW15LWtleTt0eXBlPXByaXZh dGU/cGluLXNvdXJjZT0vZXRjL3Rva2VuDQoNCiAgIFRoZSBmb2xsb3dpbmcg ZXhhbXBsZSBpZGVudGlmaWVzIGEgY2VydGlmaWNhdGUgaW4gdGhlIHNvZnR3 YXJlIHRva2VuLg0KICAgTm90ZSBhbiBlbXB0eSB2YWx1ZSBmb3IgdGhlIGF0 dHJpYnV0ZSAic2VyaWFsIiB3aGljaCBtYXRjaGVzIG9ubHkNCiAgIGVtcHR5 ICJzZXJpYWxOdW1iZXIiIG1lbWJlciBvZiB0aGUgIkNLX1RPS0VOX0lORk8i IHN0cnVjdHVyZS4gIEFsc28NCiAgIG5vdGUgdGhhdCB0aGUgImlkIiBhdHRy aWJ1dGUgdmFsdWUgaXMgZW50aXJlbHkgcGVyY2VudC1lbmNvZGVkLCBhcw0K ICAgcmVjb21tZW5kZWQuICBXaGlsZSAnLCcgaXMgaW4gdGhlIHJlc2VydmVk IHNldCBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlDQogICBwZXJjZW50LWVuY29k ZWQgc2luY2UgaXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCBhbnkgc3ViLWRl bGltaXRlcnMNCiAgIHVzZWQuICBUaGUgJyMnIGNoYXJhY3RlciBhcyBpbiAi VGhlIFNvZnR3YXJlIFBLQ1MjMTEgU29mdHRva2VuIiBNVVNUDQogICBiZSBw ZXJjZW50LWVuY29kZWQuDQoNCiAgICAgcGtjczExOnRva2VuPVRoZSUyMFNv ZnR3YXJlJTIwUEtDUyUyMzExJTIwU29mdHRva2VuOw0KICAgICAgICAgICAg bWFudWZhY3R1cmVyPVNuYWtlJTIwT2lsLCUyMEluYy47DQogICAgICAgICAg ICBtb2RlbD0xLjA7DQogICAgICAgICAgICBvYmplY3Q9bXktY2VydGlmaWNh dGU7DQogICAgICAgICAgICB0eXBlPWNlcnQ7DQogICAgICAgICAgICBpZD0l NjklOTUlM0UlNUMlRjQlQkQlRUMlOTE7DQogICAgICAgICAgICBzZXJpYWw9 DQogICAgICAgICAgICA/cGluLXNvdXJjZT0vZXRjL3Rva2VuX3Bpbg0KDQog ICBUaGUgbmV4dCBleGFtcGxlIGNvdmVycyBob3cgdG8gdXNlIHRoZSAibW9k dWxlLW5hbWUiIHF1ZXJ5IGF0dHJpYnV0ZS4NCiAgIENvbnNpZGVyaW5nIHRo YXQgdGhlIG1vZHVsZSBpcyBsb2NhdGVkIGluIC91c3IvbGliL2xpYm15cGtj czExLnNvLjENCiAgIGZpbGUsIHRoZSBhdHRyaWJ1dGUgdmFsdWUgaXMgIm15 cGtjczExIiwgbWVhbmluZyBvbmx5IHRoZSBtb2R1bGUgbmFtZQ0KICAgd2l0 aG91dCB0aGUgZnVsbCBwYXRoLCBhbmQgd2l0aG91dCB0aGUgcGxhdGZvcm0g c3BlY2lmaWMgImxpYiIgcHJlZml4DQogICBhbmQgIi5zby4xIiBzdWZmaXgu DQoNCiAgICAgcGtjczExOm9iamVjdD1teS1zaWduLWtleTsNCiAgICAgICAg ICAgIHR5cGU9cHJpdmF0ZQ0KICAgICAgICAgICAgP21vZHVsZS1uYW1lPW15 cGtjczExDQoNCg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoN CiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBjb3ZlcnMgaG93IHRvIHVzZSB0 aGUgIm1vZHVsZS1wYXRoIiBxdWVyeQ0KICAgYXR0cmlidXRlLiAgVGhlIGF0 dHJpYnV0ZSBtYXkgYmUgdXNlZnVsIGlmIGEgdXNlciBuZWVkcyB0byBwcm92 aWRlDQogICB0aGUga2V5IHZpYSBhIFBLQ1MjMTEgbW9kdWxlIHN0b3JlZCBv biBhIHJlbW92YWJsZSBtZWRpYSwgZm9yDQogICBleGFtcGxlLiAgR2V0dGlu ZyB0aGUgUElOIHRvIGFjY2VzcyB0aGUgcHJpdmF0ZSBrZXkgaGVyZSBpcyBs ZWZ0IHRvDQogICBiZSBhcHBsaWNhdGlvbiBzcGVjaWZpYy4NCg0KICAgICBw a2NzMTE6b2JqZWN0PW15LXNpZ24ta2V5Ow0KICAgICAgICAgICAgdHlwZT1w cml2YXRlDQogICAgICAgICAgICA/bW9kdWxlLXBhdGg9L21udC9saWJteXBr Y3MxMS5zby4xDQoNCiAgIEluIHRoZSBjb250ZXh0IHdoZXJlIGEgdG9rZW4g aXMgZXhwZWN0ZWQgdGhlIHRva2VuIGNhbiBiZSBpZGVudGlmaWVkDQogICB3 aXRob3V0IHNwZWNpZnlpbmcgYW55IFBLQ1MjMTEgb2JqZWN0cy4gIEEgUElO IG1pZ2h0IHN0aWxsIGJlIG5lZWRlZA0KICAgaW4gdGhlIGNvbnRleHQgb2Yg bGlzdGluZyBhbGwgb2JqZWN0cyBpbiB0aGUgdG9rZW4sIGZvciBleGFtcGxl Lg0KICAgU2VjdGlvbiA3IHNob3VsZCBiZSBjb25zdWx0ZWQgYmVmb3JlIHRo ZSAicGluLXZhbHVlIiBhdHRyaWJ1dGUgaXMNCiAgIGV2ZXIgdXNlZC4NCg0K ICAgICBwa2NzMTE6dG9rZW49U29mdHdhcmUlMjBQS0NTJTIzMTElMjBzb2Z0 dG9rZW47DQogICAgICAgICAgICBtYW51ZmFjdHVyZXI9U25ha2UlMjBPaWws JTIwSW5jLg0KICAgICAgICAgICAgP3Bpbi12YWx1ZT10aGUtcGluDQoNCiAg IEluIHRoZSBjb250ZXh0IHdoZXJlIGEgc2xvdCBpcyBleHBlY3RlZCB0aGUg c2xvdCBjYW4gYmUgaWRlbnRpZmllZA0KICAgd2l0aG91dCBzcGVjaWZ5aW5n IGFueSBQS0NTIzExIG9iamVjdHMgaW4gYW55IHRva2VuIGl0IG1heSBiZQ0K ICAgaW5zZXJ0ZWQgaW4gaXQuDQoNCiAgICAgcGtjczExOnNsb3QtZGVzY3Jp cHRpb249U3VuJTIwTWV0YXNsb3QNCg0KICAgVGhlIENyeXB0b2tpIGxpYnJh cnkgYWxvbmUgY2FuIGJlIGFsc28gaWRlbnRpZmllZCB3aXRob3V0IHNwZWNp ZnlpbmcNCiAgIGEgUEtDUyMxMSB0b2tlbiBvciBvYmplY3QuDQoNCiAgICAg cGtjczExOmxpYnJhcnktbWFudWZhY3R1cmVyPVNuYWtlJTIwT2lsLCUyMElu Yy47DQogICAgICAgICAgICBsaWJyYXJ5LWRlc2NyaXB0aW9uPVNvZnQlMjBU b2tlbiUyMExpYnJhcnk7DQogICAgICAgICAgICBsaWJyYXJ5LXZlcnNpb249 MS4yMw0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgYW4gYXR0 cmlidXRlIHZhbHVlIHdpdGggYSBzZW1pY29sb24uICBJbg0KICAgc3VjaCBj YXNlIGl0IE1VU1QgYmUgcGVyY2VudC1lbmNvZGVkLiAgVGhlIHRva2VuIGF0 dHJpYnV0ZSB2YWx1ZSBNVVNUDQogICBiZSByZWFkIGFzICJNeSB0b2tlbjsg Y3JlYXRlZCBieSBKb2UiLiAgTG93ZXIgY2FzZSBsZXR0ZXJzIE1BWSBiZQ0K ICAgdXNlZCBpbiBwZXJjZW50LWVuY29kaW5nIGFzIHNob3duIGJlbG93IGlu IHRoZSAiaWQiIGF0dHJpYnV0ZSB2YWx1ZQ0KICAgYnV0IG5vdGUgdGhhdCBT ZWN0aW9ucyAyLjEgYW5kIDYuMi4yLjEgb2YgW1JGQzM5ODZdIHJlYWQgdGhh dCBhbGwNCiAgIHBlcmNlbnQtZW5jb2RlZCBjaGFyYWN0ZXJzIFNIT1VMRCB1 c2UgdGhlIHVwcGVyY2FzZSBoZXhhZGVjaW1hbA0KICAgZGlnaXRzLiAgTW9y ZSBzcGVjaWZpY2FsbHksIGlmIHRoZSBVUkkgc3RyaW5nIHdhcyB0byBiZSBj b21wYXJlZCB0aGUNCiAgIGFsZ29yaXRobSBkZWZpbmVkIGluIFNlY3Rpb24g My42IGV4cGxpY2l0bHkgcmVxdWlyZXMgcGVyY2VudC1lbmNvZGluZw0KICAg dG8gdXNlIHRoZSB1cHBlcmNhc2UgZGlnaXRzIEEtRiBpbiB0aGUgImlkIiBh dHRyaWJ1dGUgdmFsdWVzLiAgQW5kIGFzDQogICBleHBsYWluZWQgaW4gU2Vj dGlvbiAzLjMsIGxpYnJhcnkgdmVyc2lvbiAiMyIgTVVTVCBiZSBpbnRlcnBy ZXRlZCBhcw0KICAgIjMiIGZvciB0aGUgbWFqb3IgYW5kICIwIiBmb3IgdGhl IG1pbm9yIHZlcnNpb24gb2YgdGhlIGxpYnJhcnkuDQoNCiAgICAgcGtjczEx OnRva2VuPU15JTIwdG9rZW4lMjUlMjBjcmVhdGVkJTIwYnklMjBKb2U7DQog ICAgICAgICAgICBsaWJyYXJ5LXZlcnNpb249MzsNCiAgICAgICAgICAgIGlk PSUwMSUwMiUwMyVCYSVkZCVDYSVmZSUwNCUwNSUwNg0KDQoNCg0KUGVjaGFu ZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAxNSAgICAg ICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51 YXJ5IDIwMTUNCg0KDQogICBJZiB0aGVyZSBpcyBhbnkgbmVlZCB0byBpbmNs dWRlIGxpdGVyYWwgIiU7IiBzdWJzdHJpbmcsIGZvciBleGFtcGxlLA0KICAg Ym90aCBjaGFyYWN0ZXJzIE1VU1QgYmUgZXNjYXBlZC4gIFRoZSB0b2tlbiB2 YWx1ZSBNVVNUIGJlIHJlYWQgYXMgIkENCiAgIG5hbWUgd2l0aCBhIHN1YnN0 cmluZyAlOyIuDQoNCiAgICAgcGtjczExOnRva2VuPUElMjBuYW1lJTIwd2l0 aCUyMGElMjBzdWJzdHJpbmclMjAlMjUlM0I7DQogICAgICAgICAgICBvYmpl Y3Q9bXktY2VydGlmaWNhdGU7DQogICAgICAgICAgICB0eXBlPWNlcnQNCg0K ICAgVGhlIG5leHQgZXhhbXBsZSBpbmNsdWRlcyBhIHNtYWxsIEEgd2l0aCBh Y3V0ZSBpbiB0aGUgdG9rZW4gbmFtZS4gIEl0DQogICBNVVNUIGJlIGVuY29k ZWQgaW4gb2N0ZXRzIGFjY29yZGluZyB0byB0aGUgVVRGLTggY2hhcmFjdGVy IGVuY29kaW5nDQogICBhbmQgdGhlbiBwZXJjZW50LWVuY29kZWQuICBHaXZl biB0aGF0IGEgc21hbGwgQSB3aXRoIGFjdXRlIGlzIFUrMjI1DQogICB1bmlj b2RlIGNvZGUgcG9pbnQsIHRoZSBVVEYtOCBlbmNvZGluZyBpcyAxOTUgMTYx IGluIGRlY2ltYWwsIGFuZA0KICAgdGhhdCBpcyAiJUMzJUExIiBpbiBwZXJj ZW50LWVuY29kaW5nLg0KDQogICAgIHBrY3MxMTp0b2tlbj1OYW1lJTIwd2l0 aCUyMGElMjBzbWFsbCUyMEElMjB3aXRoJTIwYWN1dGU6JTIwJUMzJUExOw0K ICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0KICAgICAgICAg ICAgdHlwZT1jZXJ0DQoNCiAgIEJvdGggdGhlIHBhdGggYW5kIHF1ZXJ5IGNv bXBvbmVudHMgTUFZIGNvbnRhaW4gdmVuZG9yIHNwZWNpZmljDQogICBhdHRy aWJ1dGVzLiAgQXR0cmlidXRlcyBpbiB0aGUgcXVlcnkgY29tcG9uZW50IE1V U1QgYmUgZGVsaW1pdGVkIGJ5DQogICAnJicuDQoNCiAgICAgcGtjczExOnRv a2VuPW15LXRva2VuOw0KICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmlj YXRlOw0KICAgICAgICAgICAgdHlwZT1jZXJ0Ow0KICAgICAgICAgICAgdmVu ZG9yLWFhYT12YWx1ZS1hDQogICAgICAgICAgICA/cGluLXNvdXJjZT0vZXRj L3Rva2VuX3Bpbg0KICAgICAgICAgICAgJnZlbmRvci1iYmI9dmFsdWUtYg0K DQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50 IG1vdmVzIHRoZSAicGtjczExIiBVUkkgc2NoZW1lIGZyb20gdGhlIHByb3Zp c2lvbmFsIHRvDQogICBwZXJtYW5lbnQgVVJJIHNjaGVtZSByZWdpc3RyeS4N Cg0KICAgVGhlIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBpcyBhcyBmb2xsb3dz Og0KDQogICAgICBVUkkgc2NoZW1lIG5hbWU6IHBrY3MxMQ0KDQogICAgICBV Ukkgc2NoZW1lIHN0YXR1czogcGVybWFuZW50DQoNCiAgICAgIFVSSSBzY2hl bWUgc3ludGF4OiBzZWUgU2VjdGlvbiAzLjMNCg0KICAgICAgVVJJIHNjaGVt ZSBzZW1hbnRpY3M6IHNlZSBTZWN0aW9uIDENCg0KICAgICAgRW5jb2Rpbmcg Y29uc2lkZXJhdGlvbnM6IHNlZSBTZWN0aW9uIDMuMw0KDQogICAgICBBcHBs aWNhdGlvbnMvcHJvdG9jb2xzIHRoYXQgdXNlIHRoaXMgVVJJIHNjaGVtZSBu YW1lOiBmb3IgZ2VuZXJhbA0KICAgICAgaW5mb3JtYXRpb24sIHNlZSBTZWN0 aW9uIDEuICBMaXN0IG9mIGtub3duIGNvbnN1bWVycyBvZiB0aGUNCg0KDQoN ClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDgsIDIw MTUgICAgICAgICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAg ICAgSmFudWFyeSAyMDE1DQoNCg0KICAgICAgUEtDUyMxMSBVUkkgaW5jbHVk ZSBHbnVUTFMsIEdub21lLCBwMTEta2l0LCBTb2xhcmlzIDExIGFuZCBoaWdo ZXIsDQogICAgICBPcGVuU0MsIE9wZW5Db25uZWN0LCBhbmQgRnJlZUlQQS4N Cg0KICAgICAgSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczogTi9B DQoNCiAgICAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiBzZWUgU2VjdGlv biA3DQoNCiAgICAgIENvbnRhY3Q6IHNlZSBBdXRob3JzJyBBZGRyZXNzZXMg c2VjdGlvbg0KDQogICAgICBBdXRob3IvQ2hhbmdlIENvbnRyb2xsZXI6IHNl ZSBBdXRob3JzJyBBZGRyZXNzZXMgc2VjdGlvbg0KDQogICAgICBSZWZlcmVu Y2VzOiBzZWUgUmVmZXJlbmNlcyBzZWN0aW9uDQoNCjYuICBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgUEtDUyMxMSBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IHNwZWNpZnkgYSBjYW5vbmljYWwgZm9y bSBmb3INCiAgIHN0cmluZ3Mgb2YgY2hhcmFjdGVycyBvZiB0aGUgQ0tfVVRG OENIQVIgdHlwZS4gIFRoaXMgcHJlc2VudHMgdGhlDQogICB1c3VhbCBmYWxz ZSBuZWdhdGl2ZSBhbmQgZmFsc2UgcG9zaXRpdmUgKGFsaWFzaW5nKSBjb25j ZXJucyB0aGF0DQogICBhcmlzZSB3aGVuIGRlYWxpbmcgd2l0aCB1bm5vcm1h bGl6ZWQgc3RyaW5ncy4gIEJlY2F1c2UgYWxsIFBLQ1MjMTENCiAgIGl0ZW1z IGFyZSBsb2NhbCBhbmQgbG9jYWwgc2VjdXJpdHkgaXMgYXNzdW1lZCwgdGhl c2UgY29uY2VybnMgYXJlDQogICBtYWlubHkgYWJvdXQgdXNhYmlsaXR5Lg0K DQogICBJbiBvcmRlciB0byBpbXByb3ZlIHRoZSB1c2VyIGV4cGVyaWVuY2Us IGFwcGxpY2F0aW9ucyB0aGF0IGNyZWF0ZQ0KICAgUEtDUyMxMSBvYmplY3Rz IG9yIGxhYmVsIHRva2VucyBTSE9VTEQgbm9ybWFsaXplIGxhYmVscyB0bw0K ICAgTm9ybWFsaXphdGlvbiBGb3JtIEMgKE5GQykgW1VBWDE1XS4gIEZvciB0 aGUgc2FtZSByZWFzb24gUEtDUyMxMQ0KICAgbGlicmFyaWVzLCBzbG90cyAo dG9rZW4gcmVhZGVycyksIGFuZCB0b2tlbnMgU0hPVUxEIG5vcm1hbGl6ZSB0 aGVpcg0KICAgbmFtZXMgdG8gTkZDLiAgV2hlbiBsaXN0aW5nIFBLQ1MjMTEg bGlicmFyaWVzLCBzbG90cywgdG9rZW5zLCBhbmQvb3INCiAgIG9iamVjdHMs IGFuIGFwcGxpY2F0aW9uIFNIT1VMRCBub3JtYWxpemUgdGhlaXIgbmFtZXMg dG8gTkZDLiAgV2hlbg0KICAgbWF0Y2hpbmcgUEtDUyMxMSBVUklzIHRvIGxp YnJhcmllcywgc2xvdHMsIHRva2VucywgYW5kL29yIG9iamVjdHMsDQogICBh cHBsaWNhdGlvbnMgTUFZIHVzZSBmb3JtLWluc2Vuc2l0aXZlIFVuaWNvZGUg c3RyaW5nIGNvbXBhcmlzb24gZm9yDQogICBtYXRjaGluZywgYXMgdGhvc2Ug bWlnaHQgcHJlLWRhdGUgdGhlc2UgcmVjb21tZW5kYXRpb25zLiAgU2VlIGFs c28NCiAgIFNlY3Rpb24gMy41Lg0KDQo3LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlcmUgYXJlIGdlbmVyYWwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIFVSSSBzY2hlbWVzIGRpc2N1c3NlZA0KICAgaW4gU2Vj dGlvbiA3IG9mIFtSRkMzOTg2XS4NCg0KICAgRnJvbSB0aG9zZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucywgU2VjdGlvbiA3LjEgb2YgW1JGQzM5ODZdIGFw cGxpZXMNCiAgIHNpbmNlIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRo ZSBzYW1lIFBLQ1MjMTEgVVJJIHdpbGwgYWx3YXlzDQogICBpZGVudGlmeSB0 aGUgc2FtZSBvYmplY3QsIHRva2VuLCBzbG90LCBvciBhIGxpYnJhcnkgaW4g dGhlIGZ1dHVyZS4NCg0KICAgU2VjdGlvbiA3LjIgb2YgW1JGQzM5ODZdIGFw cGxpZXMgc2luY2UgYnkgYWNjZXB0aW5nIHF1ZXJ5IGNvbXBvbmVudA0KICAg YXR0cmlidXRlcyAibW9kdWxlLW5hbWUiIG9yICJtb2R1bGUtcGF0aCIgdGhl IGNvbnN1bWVyIHBvdGVudGlhbGx5DQogICBhbGxvd3MgbG9hZGluZyBvZiBh cmJpdHJhcnkgY29kZSBpbnRvIGEgcHJvY2Vzcy4NCg0KICAgU2VjdGlvbiA3 LjUgb2YgW1JGQzM5ODZdIGFwcGxpZXMgc2luY2UgdGhlIFBLQ1MjMTEgVVJJ IG1heSBiZSB1c2VkIGluDQogICB3b3JsZCByZWFkYWJsZSBjb21tYW5kIGxp bmUgYXJndW1lbnRzIHRvIHJ1biBhcHBsaWNhdGlvbnMsIHN0b3JlZCBpbg0K DQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkg OCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAg ICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBwdWJsaWMgY29uZmlndXJh dGlvbiBmaWxlcywgb3Igb3RoZXJ3aXNlIHVzZWQgaW4gY2xlYXIgdGV4dC4g IEZvcg0KICAgdGhhdCByZWFzb24gdGhlICJwaW4tdmFsdWUiIGF0dHJpYnV0 ZSBzaG91bGQgb25seSBiZSB1c2VkIGlmIHRoZSBVUkkNCiAgIHN0cmluZyBp dHNlbGYgaXMgcHJvdGVjdGVkIHdpdGggdGhlIHNhbWUgbGV2ZWwgb2Ygc2Vj dXJpdHkgYXMgdGhlDQogICB0b2tlbiBQSU4gaXRzZWxmIG90aGVyd2lzZSBp cy4NCg0KICAgVGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBw cm92aWRlIG1lYW5zIHRvIGF1dGhlbnRpY2F0ZQ0KICAgZGV2aWNlcyB0byB1 c2VyczsgaXQgb25seSBhbGxvd3MgdG8gYXV0aGVudGljYXRlIHVzZXJzIHRv IHRva2Vucy4NCiAgIEluc3RlYWQsIGxvY2FsIGFuZCBwaHlzaWNhbCBzZWN1 cml0eSBhcmUgZGVtYW5kZWQ6IHRoZSB1c2VyIG11c3QgYmUNCiAgIGluIHBv c3Nlc3Npb24gb2YgdGhlaXIgdG9rZW5zLCBhbmQgc3lzdGVtIGludG8gd2hv c2Ugc2xvdHMgdGhlIHVzZXJzJw0KICAgdG9rZW5zIGFyZSBpbnNlcnRlZCBt dXN0IGJlIHNlY3VyZS4gIEFzIGEgcmVzdWx0LCB0aGUgdXN1YWwgc2VjdXJp dHkNCiAgIGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyBub3JtYWxpemF0aW9u IGRvIG5vdCBhcmlzZS4gIEZvciB0aGUgc2FtZQ0KICAgcmVhc29uLCBjb25m dXNhYmxlIHNjcmlwdCBpc3N1ZXMgYWxzbyBkbyBub3QgYXJpc2UuICBOb25l dGhlbGVzcywgaXQNCiAgIGlzIGJlc3QgdG8gbm9ybWFsaXplIHRvIE5GQyBh bGwgc3RyaW5ncyBhcHBlYXJpbmcgaW4gUEtDUyMxMSBBUEkNCiAgIGVsZW1l bnRzLiAgU2VlIGFsc28gU2VjdGlvbiA2Lg0KDQo4LiAgUmVmZXJlbmNlcw0K DQo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0g IEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBS RkMgMjExOSwgU1REIDE0LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMzYyOV0g IFllcmdlYXUsIEYuLCAiVVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0 IG9mIElTTw0KICAgICAgICAgICAgICAxMDY0NiIsIFJGQyAzNjI5LCBTVEQg NjMsIE5vdmVtYmVyIDIwMDMuDQoNCiAgIFtSRkMzOTg2XSAgQmVybmVycy1M ZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZv cm0NCiAgICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTog R2VuZXJpYyBTeW50YXgiLCBSRkMgMzk4NiwgU1REDQogICAgICAgICAgICAg IDY2LCBKYW51YXJ5IDIwMDUuDQoNCiAgIFtSRkM1MjM0XSAgQ3JvY2tlciwg RC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgN CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNTIz NCwgU1REIDY4LCBKYW51YXJ5IDIwMDguDQoNCjguMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KICAgW0JDUDE3OF0gICBTYWludC1BbmRyZSwgUC4s IENyb2NrZXIsIEQuLCBhbmQgTS4gTm90dGluZ2hhbSwNCiAgICAgICAgICAg ICAgIkRlcHJlY2F0aW5nIHRoZSAiWC0iIFByZWZpeCBhbmQgU2ltaWxhciBD b25zdHJ1Y3RzIGluDQogICAgICAgICAgICAgIEFwcGxpY2F0aW9uIFByb3Rv Y29scyIsIFJGQyA2NjQ4LCBCQ1AgMTc4LCBKdW5lIDIwMTIuDQoNCiAgIFtQ S0NTMTFdICAgUlNBIExhYm9yYXRvcmllcywgIlBLQ1MgIzExOiBDcnlwdG9n cmFwaGljIFRva2VuIEludGVyZmFjZQ0KICAgICAgICAgICAgICBTdGFuZGFy ZCB2Mi4yMCIsIEp1bmUgMjAwNC4NCg0KICAgW1JGQzM5ODddICBEdWVyc3Qs IE0uIGFuZCBNLiBTdWlnbmFyZCwgIkludGVybmF0aW9uYWxpemVkIFJlc291 cmNlDQogICAgICAgICAgICAgIElkZW50aWZpZXJzIChJUklzKSIsIFJGQyAz OTg3LCBKYW51YXJ5IDIwMDUuDQoNCiAgIFtSRkM0Mzk1XSAgSGFuc2VuLCBU LiwgSGFyZGllLCBULiwgYW5kIEwuIE1hc2ludGVyLCAiR3VpZGVsaW5lcyBh bmQNCiAgICAgICAgICAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgZm9y IE5ldyBVUkkgU2NoZW1lcyIsIFJGQyA0Mzk1LA0KICAgICAgICAgICAgICBG ZWJydWFyeSAyMDA2Lg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAg ICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFn ZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMx MSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAg IFtSRkM2NTcwXSAgR3JlZ29yaW8sIEouLCBGaWVsZGluZywgUi4sIEhhZGxl eSwgTS4sIE5vdHRpbmdoYW0sIE0uLA0KICAgICAgICAgICAgICBhbmQgRC4g T3JjaGFyZCwgIlVSSSBUZW1wbGF0ZSIsIFJGQyA2NTcwLCBNYXJjaCAyMDEy Lg0KDQogICBbVUFYMTVdICAgIERhdmlzLCBNLiwgRWQuLCBXaGlzdGxlciwg Sy4sIEVkLiwgYW5kIFVuaWNvZGUgQ29uc29ydGl1bSwNCiAgICAgICAgICAg ICAgIlVuaWNvZGUgU3RhbmRhcmQgQW5uZXggIzE1IC0gVW5pY29kZSBOb3Jt YWxpemF0aW9uIEZvcm1zLA0KICAgICAgICAgICAgICBWZXJzaW9uIFVuaWNv ZGUgNy4wLjAiLCBKdW5lIDIwMTQuDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0K DQogICBKYW4gUGVjaGFuZWMNCiAgIE9yYWNsZSBDb3Jwb3JhdGlvbg0KICAg NDE4MCBOZXR3b3JrIENpcmNsZQ0KICAgU2FudGEgQ2xhcmEgIENBIDk1MDU0 DQogICBVU0ENCg0KICAgRW1haWw6IEphbi5QZWNoYW5lY0BPcmFjbGUuQ09N DQogICBVUkk6ICAgaHR0cDovL3d3dy5vcmFjbGUuY29tDQoNCg0KICAgRGFy cmVuIEouIE1vZmZhdA0KICAgT3JhY2xlIENvcnBvcmF0aW9uDQogICBPcmFj bGUgUGFya3dheQ0KICAgVGhhbWVzIFZhbGxleSBQYXJrDQogICBSZWFkaW5n ICBSRzYgMVJBDQogICBVSw0KDQogICBFbWFpbDogRGFycmVuLk1vZmZhdEBP cmFjbGUuQ09NDQogICBVUkk6ICAgaHR0cDovL3d3dy5vcmFjbGUuY29tDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K UGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAx NSAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQo= ---559023410-351212254-1420431205=:8160-- From nobody Mon Jan 5 11:11:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263FC1A88A9 for ; Mon, 5 Jan 2015 11:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0xg0FCS8Ik for ; Mon, 5 Jan 2015 11:11:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AB01A888C for ; Mon, 5 Jan 2015 11:11:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 519FFBEC6 for ; Mon, 5 Jan 2015 19:11:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OcS3N2fYZwV for ; Mon, 5 Jan 2015 19:11:26 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6E43BE79 for ; Mon, 5 Jan 2015 19:11:25 +0000 (GMT) Message-ID: <54AAE1DC.4090102@cs.tcd.ie> Date: Mon, 05 Jan 2015 19:11:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20150105184151.27660.23252.idtracker@ietfa.amsl.com> In-Reply-To: <20150105184151.27660.23252.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150105184151.27660.23252.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QtDVuV6RKxPQHlWY0_QCUUOkJrc Subject: [saag] Fwd: IETF 92 - Working Group/BOF/IRTF Scheduling X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 19:11:40 -0000 FYI, if you hoping for some kind of BoF in March, now's the time to start talking to a relevant AD. Cheers, S. -------- Forwarded Message -------- Subject: IETF 92 - Working Group/BOF/IRTF Scheduling Date: Mon, 05 Jan 2015 10:41:51 -0800 From: IETF Agenda Reply-To: IETF Agenda To: Working Group Chairs CC: irsg@irtf.org ----------------------------------------------------------------- IETF 92 – Dallas, TX, USA Meeting Dates: March 22 – 27, 2015 ----------------------------------------------------------------- We are accepting scheduling requests for all Working Groups, BOFs, and Research Groups starting today. NOTE: There is an option for an experimental room set for IETF 92. This set will include a boardroom style at the front and classroom seats behind it. Please check the box on the session request form if your working group is willing to participate (subject to availability). The milestones and deadlines for scheduling-related activities are as follows: Cut-off dates are subject to change. • 2015-01-05 (Monday): Working Group and BOF scheduling begins. To request a Working Group session, use the IETF Meeting Session Request Tool. • 2015-02-06 (Friday): Cut-off date for requests to schedule Working Group meetings at UTC 23:59. To request a Working Group session, use the IETF Meeting Session Request Tool. • 2015-02-06 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. To request a BOF, please see instructions on Requesting a BOF. • 2015-02-13 (Friday): Cut-off date for Area Directors to approve BOFs at UTC 23:59. • 2015-02-20 (Friday): Preliminary agenda published for comment. • 2015-02-25 (Wednesday): Cut-off date for requests to reschedule Working Group and BOF meetings UTC 23:59. • 2015-02-27 (Friday): Final agenda to be published. • 2015-03-09 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. • 2015-03-16 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. • 2015-04-17 (Friday): Proceedings submission cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool. • 2015-05-11 (Monday): Proceedings submission corrections cutoff date by UTC 23:59, upload using IETF Meeting Materials Management Tool. =============================================================== For your convenience, comprehensive information on requesting meeting sessions is presented below: 1. Requests to schedule Working Group sessions should be submitted using the "IETF Meeting Session Request Tool," a Web-based tool for submitting all of the information required by the Secretariat to schedule your sessions. The URL for the tool is: https://datatracker.ietf.org/secr/sreq/ Instructions for using the tool are available at: http://www.ietf.org/wg/request-tool-instructions.html If you require an account on this tool, or assistance in using it, then please send a message to ietf-action@ietf.org. If you are unable to use the tool, then you may send your request via e-mail to agenda@ietf.org, with a copy to the appropriate Area Director(s). Requests to schedule BOF sessions must be sent to agenda@ietf.org with a copy to the appropriate Area Director(s). When submitting a Working Group or BOF session request by e-mail, please include the Working Group or BOF acronym in the Subject line. 2. BOFs will NOT be scheduled unless the Area Director approves the BOF. The proponents behind a BOF need to contact a relevant Area Director, preferably well in advance of the BOF approval deadline date. The AD needs to have the full name of the BOF, its acronym, suggested names of chairs, an agenda, full description of the BOF and the information covered in item 4. Please read RFC 5434 for instructions on how to drive a successful BOF effort. The approval depends on, for instance, Internet-Drafts and list discussion on the suggested topic. BOF agenda requests, if approved, will be submitted to the IETF Secretariat by the ADs. 3. A Working Group may request either one or two sessions. If your Working Group requires more than two sessions, then your request must be approved by an Area Director. Additional sessions will be assigned, based on availability, after Wednesday, February 25th, 2015, the cut-off date for requests to reschedule a session. 4. You MUST provide the following information before a Working Group or BOF session will be scheduled: a. Working Group or BOF full name with acronym in brackets: b. AREA under which Working Group or BOF appears: c. CONFLICTS you wish to avoid, please be as specific as possible: d. Expected Attendance: e. Special requests: f. Number of sessions: g. Length of session: 1 hour, 1.5 hours, 2 hours, 2.5 hours For more information on scheduling Working Group and BOF sessions, please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and Procedures" (http://www.ietf.org/rfc/rfc2418.txt). =============================================================== Submitting Session Agendas For the convenience of meeting attendees, we ask that you submit the agendas for your Working Group sessions as early as possible. Draft Working Group agendas are due Monday, March 9th, 2015 at UTC 23:59. Revised Working Group agendas are due no later than Monday, March 16th, 2015 at UTC 23:59. The proposed agenda for a BOF session should be submitted along with your request for a session. Please be sure to copy your Area Director on that message. Please submit the agendas for your Working Group sessions using the "IETF Meeting Materials Management Tool," a Web-based tool for making your meeting agenda, minutes, and presentation slides available to the community before, during, and after an IETF meeting. If you are a BOF chair, then you may use the tool to submit a revised agenda as well as other materials for your BOF once the BOF has been approved. The URL for the tool is: https://datatracker.ietf.org/secr/proceedings/ Additional information about this tool is available at: http://www.ietf.org/wg/meeting-materials.html Agendas submitted via the tool will be available to the public on the "IETF Meeting Materials" webpage as soon as they are submitted. The URL for the "IETF 92 Meeting Materials" Web page is: https://datatracker.ietf.org/meeting/92/materials.html If you are a Working Group chair, then you already have accounts on the "IETF Meeting Session Request Tool" and the "IETF Meeting Materials Management Tool." The same User ID and password will work for both tools. If you are a BOF chair who is not also a Working Group chair, then you will be given an account on the "IETF Meeting Materials Management Tool" when your BOF has been approved. If you require assistance in using either tool, or wish to report a bug, then please send a message to: ietf-action@ietf.org. =============================================================== For your convenience please find a list of the IETF Area Directors with their e-mail addresses below: IETF Chair Jari Arkko Applications Area (app) Barry Leiba Pete Resnick Internet Area (int) Brian Haberman Ted Lemon Operations & Management Area (ops) Benoit Claise Joel Jaeggli Real-time Applications and Infrastructure Area (rai) Richard Barnes Alissa Cooper Routing Area (rtg) Alia Atlas Adrian Farrel Security Area (sec) Stephen Farrell Kathleen Moriarty Transport Area (tsv) Spencer Dawkins Martin Stiemerling =========================================================== 91st IETF Meeting Attendance Numbers 6lo – 77 6man - 86 6tisch - 50 ace - 70 actn - 119 alto - 12 anima - 86 appsawg/apparea - 104 aqm – 60 arcmedia (BoF) - 21 avtcore - 58 avtext – 17 bess – 82 bess (2nd session) - 19 bfd – 43 bier (BoF) - 163 bmwg - 25 ccamp - 42 cdni – 49 clue – 22 clue (2nd session) - 18 core - 55 core (2nd session) – 68 dane - 137 dclcrg (RG BoF) – 34 detnet (BoF) - 87 dhc – 35 dice - 82 dime - 15 dispatch - 34 dmm - 31 dnsop - 145 dnssd – 70 dprive – 131 dtn – 45 ecrit - 21 eppext – 39 grow - 42 homenet - 103 httpauth - 35 httpbis - 114 httpbis (2nd session) – 161 i2nsf - 102 i2rs - 179 ianaplan – 79 iccrg (RG) - 44 icnrg (RG) - 52 idr – 91 idr (2nd session) - 64 intarea (AG) - 41 ippm - 31 ipsecme - 30 IRTF Open Meeting - 100 isis - 38 jose - 32 kitten - 29 lime - 63 lisp - 30 lmap - 46 lwig - 32 manet - 21 mboned - 41 mif – 40 mile - 23 mmusic - 43 mmusic (2nd session) - 43 mpls - 88 mpls (2nd session) - 78 mptcp - 49 netconf - 87 netmod – 72 netmod (2nd session) - 35 ntp (combined with tictoc) - 18 nvo3 – 123 nwcrg (RG) - 19 oauth - 51 opsawg/opsarea - 37 ospf – 55 pals - 72 pce – 64 pcp - 26 pim - 41 ppsp - 16 precis - 25 radext - 11 rmcat - 50 rtcweb - 107 rtcweb (2nd session) - 111 rtgarea (AG) - 97 rtgwg - 82 saag (AG) - 153 sacm - 31 sacm (2nd session) - 26 scim - 14 sdnrg (RG) – 213 sfc - 179 sidr - 55 sipcore - 37 siprec - 20 softwire - 47 spring - 90 stir - 38 straw - 26 taps - 40 tcpinc - 44 tcpm - 34 tictoc (combined with ntp) - 18 tls - 95 tram - 39 trans - 36 trill - 15 tsvwg - 40 tsvwg (2nd session) - 47 uta - 113 v6ops - 105 v6ops (2nd session) – 80 xrblock - 12 From nobody Tue Jan 6 02:15:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DE21A9136 for ; Tue, 6 Jan 2015 02:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEa6E1lGI3Lf for ; Tue, 6 Jan 2015 02:15:21 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5611E1A1F70 for ; Tue, 6 Jan 2015 02:15:20 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so5009295wiv.14 for ; Tue, 06 Jan 2015 02:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/7dXSnpJmPOF7LE5XmPFQb9DSDbmaeZLbXuKe2M/IgM=; b=dYbch4gxnzIU2DNWxqGAts6xlrN4CaT1WSZj7dpf7R3HWKD5tO3Ya0UVi5nmhYWHTj Z2CDWh8zwsX9FV2lBXiXzwSPyH0i10WE4IGCyb510WpuwMUNdB9saI2KrsYMVQT5/b6y X3uJ8r9GfqbOSn7Z8qrVqhBQt6NYmy1LqjRX4rE5ywfCVfd5F4OJisrUTN5G5v0IrRQ6 7fBPZTguh9wfFVNZ8S94nhwcAcrY82qOI/w7tM1PMkGtCjJ1t4v3xzlBPYj1DMx/eJV6 I4hN7mEC/mOEKdLChV6EN5k6D45VDJ+QI7UUOXG7NZ2WSG2ze2CebTE1aj1englOZT7w CYFQ== X-Received: by 10.194.190.162 with SMTP id gr2mr191712184wjc.13.1420539318379; Tue, 06 Jan 2015 02:15:18 -0800 (PST) Received: from [172.24.249.55] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id mo12sm78817262wjc.35.2015.01.06.02.15.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 02:15:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: <54AAE1DC.4090102@cs.tcd.ie> Date: Tue, 6 Jan 2015 12:15:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B6CC9C2-B4D6-48FC-873E-D38DE5B91A54@gmail.com> References: <20150105184151.27660.23252.idtracker@ietfa.amsl.com> <54AAE1DC.4090102@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/L2QcumM0h2OHfnDR7b-SR05dlYo Cc: Security Area Advisory Group Subject: Re: [saag] IETF 92 - Working Group/BOF/IRTF Scheduling X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 10:15:23 -0000 > On Jan 5, 2015, at 9:11 PM, Stephen Farrell = wrote: >=20 >=20 > FYI, if you hoping for some kind of BoF in March, now's > the time to start talking to a relevant AD. >=20 > Cheers, > S. >=20 According to RFC 5434, the time for that was around November. But, better late than never. Yoav From nobody Sun Jan 11 12:38:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06B1A066C; Wed, 7 Jan 2015 11:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MANGLED_MEDS=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTW5X4DIJEgj; Wed, 7 Jan 2015 11:16:30 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981991A0102; Wed, 7 Jan 2015 11:16:30 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t07JGDDB030867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2015 19:16:14 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t07JG77l003933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Jan 2015 19:16:08 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t07JG7nV001291; Wed, 7 Jan 2015 19:16:07 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2015 11:16:07 -0800 Date: Wed, 7 Jan 2015 11:16:05 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: John C Klensin , =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , Nico Williams In-Reply-To: Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-475718409-1420658027=:8929" Content-ID: X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YmjxJgKpkhyPsrrBw9-ZisEzovY X-Mailman-Approved-At: Sun, 11 Jan 2015 12:38:23 -0800 Cc: Darren J Moffat , Stef Walter , ietf@ietf.org, Nikos Mavrogiannopoulos , saag@ietf.org Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 19:16:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-475718409-1420658027=:8929 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Sat, 3 Jan 2015, Jan Pechanec wrote: hi, I haven't received any other comments on the draft recently (I know the LC already ended on Dec 29 though) so I think I can file changes discussed and drafted in this thread as draft 18 on Friday. Thank you all for feedback, I really appreciate it. one more change for the draft 18 (v2 attached) is to spell "NFC" and reference the Unicode Annex on normalization based on comments from Jaroslav and Christian. In order to improve the user experience, applications that create - PKCS#11 objects or label tokens, SHOULD normalize labels to NFC. For - the same reason PKCS#11 libraries, slots (token readers), and tokens ... + PKCS#11 objects or label tokens SHOULD normalize labels to + Normalization Form C (NFC) [UAX15]. For the same reason PKCS#11 + libraries, slots (token readers), and tokens SHOULD normalize their ... + [UAX15] Davis, M., Ed., Whistler, K., Ed., and Unicode Consortium, + "Unicode Standard Annex #15 - Unicode Normalization Forms, + Version Unicode 7.0.0", June 2014. best regards, Jan. >On Thu, 1 Jan 2015, Nico Williams wrote: > > Nico, many thanks for the drafted text and also to Patrik and >John for discussing it. > > I've updated the draft in sections on URI matching guidelines, >URI comparision, added a new section on I18n, and added a new paragraph >to the Security considerations. Individial diffs inline, a draft for >new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt). > >>I think we could use some text like this: >> >> PKCS#11 does not specify a canonical from for UTF-8 string slots in >> the API. This presents the usual false negative and false positive >> (aliasing) concerns that arise when dealing with unnormalized >> strings. Because all PKCS#11 items are local and local security is >> assumed, these concerns are mainly about usability. >> >> In order to improve the user experience, applications that create >> PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to >> NFC. For the same reason PKCS#11 libraries, slots (token readers), >> and tokens SHOULD normalize their names to NFC. When listing >> libraries, slots, tokens, or objects, an application SHOULD normalize >> their names to NFC. When matching PKCS#11 URIs to libraries, slots, >> tokens, and/or objects, applications may use form-insensitive Unicode >> string comparison for matching, as the objects might pre-date these >> recommendations). > > I've created "Internationalization Considerations" section and >put the text above there after I slightly modified it. I wanted to >mention CK_UTF8CHAR type so that it's clear what is discussed. > >768 6. Internationalization Considerations > >770 The PKCS#11 specification does not specify a canonical form for >771 strings of characters of the CK_UTF8CHAR type. This presents the >772 usual false negative and false positive (aliasing) concerns that >773 arise when dealing with unnormalized strings. Because all PKCS#11 >774 items are local and local security is assumed, these concerns are >775 mainly about usability. > >777 In order to improve the user experience, applications that create >778 PKCS#11 objects or label tokens, SHOULD normalize labels to NFC. For >779 the same reason PKCS#11 libraries, slots (token readers), and tokens >780 SHOULD normalize their names to NFC. When listing PKCS#11 libraries, >781 slots, tokens, and/or objects, an application SHOULD normalize their >782 names to NFC. When matching PKCS#11 URIs to libraries, slots, >783 tokens, and/or objects, applications MAY use form-insensitive Unicode >784 string comparison for matching, as those might pre-date these >785 recommendations. See also Section 3.5. > > in section 3.5 on URI Matching Guidelines, I've added the >following as the last paragraph of the section (it was based on John's >note from his last email). This paragraph might not be necessary there >and the first part could be moved to the I18N section but I think it's >good to put it to where attribute matching is discussed so that it is >not easily overlooked. > >513 As noted in Section 6, the PKCS#11 specification is not clear about >514 how to normalize UTF-8 encoded Unicode characters [RFC2279]. Those >515 who discover a need to use characters outside the ASCII repertoire >516 should be cautious, conservative, and expend extra effort to be sure >517 they know what they are doing and that failure to do so may create >518 both operational and security risks. It means that when matching >519 UTF-8 string based attributes (see Table 1) with such characters, >520 normalizing all UTF-8 strings before string comparison may be the >521 only safe approach. For example, for objects (keys) it means that >522 PKCS#11 attribute search template would only contain attributes that >523 are not UTF-8 strings and another pass through returned objects is >524 then needed for UTF-8 string comparison after the normalization is >525 applied. > >>Then later in the security considerations section, add something like: >> >> PKCS#11 does not authenticate devices to users; PKCS#11 only >> authenticates users to tokens. Instead, local and physical security >> are demanded: the user must be in possession of their tokens, and >> system into whose slots the users' tokens are inserted must be >> secure. As a result, the usual security considerations regarding >> normalization do not arise. For the same reason, confusable script >> issues also do not arise. Nonetheless, it is best to normalize to >> NFC all strings appearing in PKCS#11 API elements. > > I've added the following to the Security Considerations >section (again, slightly modified, I'd rather not use "PKCS#11" as >an alias for the specification): > >807 The PKCS#11 specification does not provide means to authenticate >808 devices to users; it only allows to authenticate users to tokens. >809 Instead, local and physical security are demanded: the user must be >810 in possession of their tokens, and system into whose slots the users' >811 tokens are inserted must be secure. As a result, the usual security >812 considerations regarding normalization do not arise. For the same >813 reason, confusable script issues also do not arise. Nonetheless, it >814 is best to normalize to NFC all strings appearing in PKCS#11 API >815 elements. See also Section 6. > > on top of that, I've added the following sentence to 3.6. PKCS#11 URI >Comparison section: > >532 strictly avoiding false positives. When working with UTF-8 strings >533 with characters outside the ASCII character sets, see important >534 caveats in Section 3.5 and Section 6. > > the attribute Table 1 now also states which attributes are >UTF-8 strings so that it's clear without consulting the spec. > > thank you, Jan. > > -- Jan Pechanec ---559023410-475718409-1420658027=:8929 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=draft-pechanec-pkcs11uri-18-v2.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=draft-pechanec-pkcs11uri-18-v2.txt DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gUGVjaGFuZWMNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgT3JhY2xlIENvcnBvcmF0 aW9uDQpFeHBpcmVzOiBKdWx5IDgsIDIwMTUgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBKYW51YXJ5IDQsIDIwMTUNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZQ0KICAg ICAgICAgICAgICAgICAgICAgIGRyYWZ0LXBlY2hhbmVjLXBrY3MxMXVyaS0x OA0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgUEtD UyMxMSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkNCiAgIFNj aGVtZSBmb3IgaWRlbnRpZnlpbmcgUEtDUyMxMSBvYmplY3RzIHN0b3JlZCBp biBQS0NTIzExIHRva2VucywgYW5kDQogICBhbHNvIGZvciBpZGVudGlmeWlu ZyBQS0NTIzExIHRva2Vucywgc2xvdHMgb3IgbGlicmFyaWVzLiAgVGhlIFVS SSBpcw0KICAgYmFzZWQgb24gaG93IFBLQ1MjMTEgb2JqZWN0cywgdG9rZW5z LCBzbG90cywgYW5kIGxpYnJhcmllcyBhcmUNCiAgIGlkZW50aWZpZWQgaW4g dGhlIFBLQ1MjMTEgQ3J5cHRvZ3JhcGhpYyBUb2tlbiBJbnRlcmZhY2UgU3Rh bmRhcmQuDQoNClN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBv ZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElF VEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlz IGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVseSA4LCAyMDE1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwN CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCiAg IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBj YXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJl c3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQu ICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBF eHBpcmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJ IFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQpUYWJsZSBv ZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDINCiAg IDIuICBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgMy4gIFBLQ1MjMTEgVVJJ IFNjaGVtZSBEZWZpbml0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA0DQogICAgIDMuMS4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBOYW1l IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAg My4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjMuICBQS0NTIzExIFVS SSBTY2hlbWUgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0DQogICAgIDMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBRdWVyeSBB dHRyaWJ1dGUgU2VtYW50aWNzICAuIC4gLiAuIC4gLiAgIDkNCiAgICAgMy41 LiAgUEtDUyMxMSBVUkkgTWF0Y2hpbmcgR3VpZGVsaW5lcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMA0KICAgICAzLjYuICBQS0NTIzExIFVSSSBD b21wYXJpc29uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEyDQogICAgIDMuNy4gIEdlbmVyYXRpbmcgUEtDUyMxMSBVUklzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMNCiAgIDQuICBFeGFt cGxlcyBvZiBQS0NTIzExIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMw0KICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2 DQogICA2LiAgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcNCiAgIDcuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNw0KICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4DQog ICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgNCiAgICAgOC4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxOA0KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5DQoNCjEu ICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIFBLQ1MgIzExOiBDcnlwdG9ncmFw aGljIFRva2VuIEludGVyZmFjZSBTdGFuZGFyZCBbUEtDUzExXQ0KICAgc3Bl Y2lmaWVzIGFuIEFQSSwgY2FsbGVkIENyeXB0b2tpLCBmb3IgZGV2aWNlcyB3 aGljaCBob2xkDQogICBjcnlwdG9ncmFwaGljIGluZm9ybWF0aW9uIGFuZCBw ZXJmb3JtIGNyeXB0b2dyYXBoaWMgZnVuY3Rpb25zLg0KICAgQ3J5cHRva2ks IHByb25vdW5jZWQgY3J5cHRvLWtleSBhbmQgc2hvcnQgZm9yIGNyeXB0b2dy YXBoaWMgdG9rZW4NCiAgIGludGVyZmFjZSwgZm9sbG93cyBhIHNpbXBsZSBv YmplY3QtYmFzZWQgYXBwcm9hY2gsIGFkZHJlc3NpbmcgdGhlDQogICBnb2Fs cyBvZiB0ZWNobm9sb2d5IGluZGVwZW5kZW5jZSAoYW55IGtpbmQgb2YgZGV2 aWNlIG1heSBiZSB1c2VkKSBhbmQNCiAgIHJlc291cmNlIHNoYXJpbmcgKG11 bHRpcGxlIGFwcGxpY2F0aW9ucyBtYXkgYWNjZXNzIG11bHRpcGxlIGRldmlj ZXMpLA0KICAgcHJlc2VudGluZyBhcHBsaWNhdGlvbnMgd2l0aCBhIGNvbW1v biwgbG9naWNhbCB2aWV3IG9mIHRoZSBkZXZpY2UgLSBhDQogICBjcnlwdG9n cmFwaGljIHRva2VuLg0KDQogICBJdCBpcyBkZXNpcmFibGUgZm9yIGFwcGxp Y2F0aW9ucyBvciBsaWJyYXJpZXMgdGhhdCB3b3JrIHdpdGggUEtDUyMxMQ0K ICAgdG9rZW5zIHRvIGFjY2VwdCBhIGNvbW1vbiBpZGVudGlmaWVyIHRoYXQg Y29uc3VtZXJzIGNvdWxkIHVzZSB0bw0KICAgaWRlbnRpZnkgYW4gZXhpc3Rp bmcgUEtDUyMxMSBzdG9yYWdlIG9iamVjdCBpbiBhIFBLQ1MjMTEgdG9rZW4s IGFuDQogICBleGlzdGluZyB0b2tlbiBpdHNlbGYsIGEgc2xvdCwgb3IgYW4g ZXhpc3RpbmcgQ3J5cHRva2kgbGlicmFyeSAoYWxzbw0KICAgY2FsbGVkIGEg cHJvZHVjZXIsIG1vZHVsZSwgb3IgcHJvdmlkZXIpLiAgVGhlIHNldCBvZiBz dG9yYWdlIG9iamVjdA0KICAgdHlwZXMgdGhhdCBjYW4gYmUgc3RvcmVkIGlu IGEgUEtDUyMxMSB0b2tlbiBpbmNsdWRlcyBhIGNlcnRpZmljYXRlLCBhDQog ICBwdWJsaWMsIHByaXZhdGUgb3Igc2VjcmV0IGtleSwgYW5kIGEgZGF0YSBv YmplY3QuICBUaGVzZSBvYmplY3RzIGNhbg0KICAgYmUgdW5pcXVlbHkgaWRl bnRpZmlhYmxlIHZpYSB0aGUgUEtDUyMxMSBVUkkgc2NoZW1lIGRlZmluZWQg aW4gdGhpcw0KICAgZG9jdW1lbnQuICBUaGUgc2V0IG9mIGF0dHJpYnV0ZXMg ZGVzY3JpYmluZyBhIHN0b3JhZ2Ugb2JqZWN0IGNhbg0KICAgY29udGFpbiBh biBvYmplY3QgbGFiZWwsIGl0cyB0eXBlLCBhbmQgaXRzIElELiAgVGhlIHNl dCBvZiBhdHRyaWJ1dGVzDQogICB0aGF0IGlkZW50aWZpZXMgYSBQS0NTIzEx IHRva2VuIGNhbiBjb250YWluIGEgdG9rZW4gbGFiZWwsDQogICBtYW51ZmFj dHVyZXIgbmFtZSwgc2VyaWFsIG51bWJlciwgYW5kIHRva2VuIG1vZGVsLiAg QXR0cmlidXRlcyB0aGF0DQogICBjYW4gaWRlbnRpZnkgYSBzbG90IGFyZSBh IHNsb3QgSUQsIGRlc2NyaXB0aW9uLCBhbmQgbWFudWZhY3R1cmVyLg0KICAg QXR0cmlidXRlcyB0aGF0IGNhbiBpZGVudGlmeSBhIENyeXB0b2tpIGxpYnJh cnkgYXJlIGEgbGlicmFyeQ0KICAgbWFudWZhY3R1cmVyLCBkZXNjcmlwdGlv biwgYW5kIHZlcnNpb24uICBMaWJyYXJ5IGF0dHJpYnV0ZXMgbWF5IGJlDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4 LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgIG5lY2Vzc2FyeSB0byB1c2Ug aWYgbW9yZSB0aGFuIG9uZSBDcnlwdG9raSBsaWJyYXJ5IHByb3ZpZGVzIGEg dG9rZW4NCiAgIGFuZC9vciBQS0NTIzExIG9iamVjdHMgb2YgdGhlIHNhbWUg bmFtZS4gIEEgc2V0IG9mIHF1ZXJ5IGF0dHJpYnV0ZXMNCiAgIGlzIHByb3Zp ZGVkIGFzIHdlbGwuDQoNCiAgIFRoZSBQS0NTIzExIFVSSSBjYW5ub3QgaWRl bnRpZnkgb3RoZXIgb2JqZWN0cyBkZWZpbmVkIGluIHRoZQ0KICAgc3BlY2lm aWNhdGlvbiBbUEtDUzExXSBhc2lkZSBmcm9tIHN0b3JhZ2Ugb2JqZWN0cy4g IEZvciBleGFtcGxlLA0KICAgb2JqZWN0cyBub3QgaWRlbnRpZmlhYmxlIGJ5 IGEgUEtDUyMxMSBVUkkgaW5jbHVkZSBhIGhhcmR3YXJlIGZlYXR1cmUNCiAg IGFuZCBtZWNoYW5pc20uICBOb3RlIHRoYXQgYSBDcnlwdG9raSBsaWJyYXJ5 IGRvZXMgbm90IGhhdmUgdG8gcHJvdmlkZQ0KICAgZm9yIHN0b3JhZ2Ugb2Jq ZWN0cyBhdCBhbGwuICBUaGUgVVJJIGNhbiBzdGlsbCBiZSB1c2VkIHRvIGlk ZW50aWZ5IGENCiAgIHNwZWNpZmljIFBLQ1MjMTEgdG9rZW4sIHNsb3Qgb3Ig YW4gQVBJIHByb2R1Y2VyIGluIHN1Y2ggYSBjYXNlLg0KDQogICBBIHN1YnNl dCBvZiBleGlzdGluZyBQS0NTIzExIHN0cnVjdHVyZSBtZW1iZXJzIGFuZCBv YmplY3QgYXR0cmlidXRlcw0KICAgd2FzIGNob3NlbiB0byB1bmlxdWVseSBp ZGVudGlmeSBhIFBLQ1MjMTEgc3RvcmFnZSBvYmplY3QsIHRva2VuLA0KICAg c2xvdCwgb3IgbGlicmFyeSBpbiBhIGNvbmZpZ3VyYXRpb24gZmlsZSwgb24g YSBjb21tYW5kIGxpbmUsIG9yIGluIGENCiAgIGNvbmZpZ3VyYXRpb24gcHJv cGVydHkgb2Ygc29tZXRoaW5nIGVsc2UuICBTaG91bGQgdGhlcmUgYmUgYSBu ZWVkIGZvcg0KICAgYSBtb3JlIGNvbXBsZXggaW5mb3JtYXRpb24gZXhjaGFu Z2Ugb24gUEtDUyMxMSBlbnRpdGllcyBhIGRpZmZlcmVudA0KICAgbWVhbnMg b2YgZGF0YSBtYXJzaGFsbGluZyBzaG91bGQgYmUgY2hvc2VuIGFjY29yZGlu Z2x5Lg0KDQogICBBIFBLQ1MjMTEgVVJJIGlzIG5vdCBpbnRlbmRlZCB0byBi ZSB1c2VkIHRvIGNyZWF0ZSBuZXcgUEtDUyMxMQ0KICAgb2JqZWN0cyBpbiB0 b2tlbnMsIG9yIHRvIGNyZWF0ZSBQS0NTIzExIHRva2Vucy4gIEl0IGlzIHNv bGVseSB0byBiZQ0KICAgdXNlZCB0byBpZGVudGlmeSBhbmQgd29yayB3aXRo IGV4aXN0aW5nIHN0b3JhZ2Ugb2JqZWN0cywgdG9rZW5zLCBhbmQNCiAgIHNs b3RzIHRocm91Z2ggdGhlIFBLQ1MjMTEgQVBJLCBvciBpZGVudGlmeSBDcnlw dG9raSBsaWJyYXJpZXMNCiAgIHRoZW1zZWx2ZXMuDQoNCiAgIFRoZSBVUkkg c2NoZW1lIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCBz cGVjaWZpY2FsbHkgd2l0aA0KICAgYSBtYXBwaW5nIHRvIHRoZSBQS0NTIzEx IEFQSSBpbiBtaW5kLiAgVGhlIFVSSSB1c2VzIHRoZSBzY2hlbWUsIHBhdGgN CiAgIGFuZCBxdWVyeSBjb21wb25lbnRzIGRlZmluZWQgaW4gdGhlIFVuaWZv cm0gUmVzb3VyY2UgSWRlbnRpZmllcg0KICAgKFVSSSk6IEdlbmVyaWMgU3lu dGF4IFtSRkMzOTg2XSBkb2N1bWVudC4gIFRoZSBVUkkgZG9lcyBub3QgdXNl IHRoZQ0KICAgaGllcmFyY2hpY2FsIGVsZW1lbnQgZm9yIGEgbmFtaW5nIGF1 dGhvcml0eSBpbiB0aGUgcGF0aCBzaW5jZSB0aGUNCiAgIGF1dGhvcml0eSBw YXJ0IGNvdWxkIG5vdCBiZSBtYXBwZWQgdG8gUEtDUyMxMSBBUEkgZWxlbWVu dHMuICBUaGUgVVJJDQogICBkb2VzIG5vdCB1c2UgdGhlIGZyYWdtZW50IGNv bXBvbmVudC4NCg0KICAgSWYgYW4gYXBwbGljYXRpb24gaGFzIG5vIGFjY2Vz cyB0byBhIHByb2R1Y2VyIG9yIHByb2R1Y2VycyBvZiB0aGUNCiAgIFBLQ1Mj MTEgQVBJIHRoZSBxdWVyeSBjb21wb25lbnQgbW9kdWxlIGF0dHJpYnV0ZXMg Y2FuIGJlIHVzZWQuDQogICBIb3dldmVyLCB0aGUgUEtDUyMxMSBVUkkgY29u c3VtZXIgY2FuIGFsd2F5cyBkZWNpZGUgdG8gcHJvdmlkZSBpdHMNCiAgIG93 biBhZGVxdWF0ZSB1c2VyIGludGVyZmFjZSB0byBsb2NhdGUgYW5kIGxvYWQg UEtDUyMxMSBBUEkgcHJvZHVjZXJzLg0KDQogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5E RUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZD MjExOV0uDQoNCjIuICBDb250cmlidXRvcnMNCg0KICAgU3RlZiBXYWx0ZXIs IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zLCBOaWNvIFdpbGxpYW1zLCBEYW4g V2luc2hpcCwgYW5kDQogICBKYXJvc2xhdiBJbXJpY2ggY29udHJpYnV0ZWQg dG8gdGhlIGRldmVsb3BtZW50IG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4 LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCjMuICBQS0NTIzExIFVSSSBTY2hl bWUgRGVmaW5pdGlvbg0KDQogICBJbiBhY2NvcmRhbmNlIHdpdGggW1JGQzQz OTVdLCB0aGlzIHNlY3Rpb24gcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uDQog ICByZXF1aXJlZCB0byByZWdpc3RlciB0aGUgUEtDUyMxMSBVUkkgc2NoZW1l Lg0KDQozLjEuICBQS0NTIzExIFVSSSBTY2hlbWUgTmFtZQ0KDQogICBwa2Nz MTENCg0KMy4yLiAgUEtDUyMxMSBVUkkgU2NoZW1lIFN0YXR1cw0KDQogICBQ ZXJtYW5lbnQuDQoNCjMuMy4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBTeW50YXgN Cg0KICAgVGhlIFBLQ1MjMTEgVVJJIGlzIGEgc2VxdWVuY2Ugb2YgYXR0cmli dXRlIHZhbHVlIHBhaXJzIHNlcGFyYXRlZCBieSBhDQogICBzZW1pY29sb24g dGhhdCBmb3JtIGEgb25lIGxldmVsIHBhdGggY29tcG9uZW50LCBvcHRpb25h bGx5IGZvbGxvd2VkDQogICBieSBhIHF1ZXJ5LiAgSW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gMi41IG9mIFtSRkMzOTg2XSwgdGhlIGRhdGENCiAgIHNo b3VsZCBmaXJzdCBiZSBlbmNvZGVkIGFzIG9jdGV0cyBhY2NvcmRpbmcgdG8g dGhlIFVURi04IGNoYXJhY3Rlcg0KICAgZW5jb2RpbmcgW1JGQzM2MjldOyB0 aGVuIG9ubHkgdGhvc2Ugb2N0ZXRzIHRoYXQgZG8gbm90IGNvcnJlc3BvbmQg dG8NCiAgIGNoYXJhY3RlcnMgaW4gdGhlIHVucmVzZXJ2ZWQgc2V0IG9yIHRv IHBlcm1pdHRlZCBjaGFyYWN0ZXJzIGZyb20gdGhlDQogICByZXNlcnZlZCBz ZXQgc2hvdWxkIGJlIHBlcmNlbnQtZW5jb2RlZC4gIFRoaXMgc3BlY2lmaWNh dGlvbiBzdWdnZXN0cw0KICAgb25lIGFsbG93YWJsZSBleGNlcHRpb24gdG8g dGhhdCBydWxlIGZvciB0aGUgImlkIiBhdHRyaWJ1dGUsIGFzDQogICBzdGF0 ZWQgbGF0ZXIgaW4gdGhpcyBzZWN0aW9uLiAgTm90ZSB0aGF0IGlmIGEgVVJJ IGRvZXMgY2FycnkNCiAgIGNoYXJhY3RlcnMgb3V0c2lkZSBvZiB0aGUgQVND SUkgY2hhcmFjdGVyIHNldCBhIGNvbnZlcnNpb24gdG8gYW4NCiAgIEludGVy bmF0aW9uYWxpemVkIFJlc291cmNlIElkZW50aWZpZXIgKElSSSkgZGVmaW5l ZCBpbiBbUkZDMzk4N10gbWF5DQogICBiZSBjb25zaWRlcmVkLiAgR3JhbW1h ciBydWxlcyAidW5yZXNlcnZlZCIgYW5kICJwY3QtZW5jb2RlZCIgaW4gdGhl DQogICBQS0NTIzExIFVSSSBzcGVjaWZpY2F0aW9uIGJlbG93IGFyZSBpbXBv cnRlZCBmcm9tIFtSRkMzOTg2XS4gIEFzIGENCiAgIHNwZWNpYWwgY2FzZSwg bm90ZSB0aGF0IGFjY29yZGluZyB0byBBcHBlbmRpeCBBIG9mIFtSRkMzOTg2 XSwgYSBzcGFjZQ0KICAgbXVzdCBiZSBwZXJjZW50LWVuY29kZWQuDQoNCiAg IFRoZSBQS0NTIzExIHNwZWNpZmljYXRpb24gaW1wb3NlcyB2YXJpb3VzIGxp bWl0YXRpb25zIG9uIHRoZSB2YWx1ZSBvZg0KICAgYXR0cmlidXRlcywgYmUg aXQgYSBtb3JlIHJlc3RyaWN0aXZlIGNoYXJhY3RlciBzZXQgZm9yIHRoZSAi c2VyaWFsIg0KICAgYXR0cmlidXRlIG9yIGZpeGVkIHNpemVkIGJ1ZmZlcnMg Zm9yIGFsbW9zdCBhbGwgdGhlIG90aGVycywgaW5jbHVkaW5nDQogICAidG9r ZW4iLCAibWFudWZhY3R1cmVyIiwgYW5kICJtb2RlbCIgYXR0cmlidXRlcy4g IEhvd2V2ZXIsIHRoZQ0KICAgUEtDUyMxMSBVUkkgbm90YXRpb24gZG9lcyBu b3QgaW1wb3NlIHN1Y2ggbGltaXRhdGlvbnMgYXNpZGUgZnJvbQ0KICAgcmVt b3ZpbmcgZ2VuZXJpYyBhbmQgUEtDUyMxMSBVUkkgZGVsaW1pdGVycyBmcm9t IGEgcGVybWl0dGVkDQogICBjaGFyYWN0ZXIgc2V0LiAgV2UgYmVsaWV2ZSB0 aGF0IGJlaW5nIHRvbyByZXN0cmljdGl2ZSBvbiB0aGUNCiAgIGF0dHJpYnV0 ZSB2YWx1ZXMgY291bGQgbGltaXQgdGhlIFBLQ1MjMTEgVVJJIHVzZWZ1bG5l c3MuICBXaGF0IGlzDQogICBtb3JlLCBwb3NzaWJsZSBmdXR1cmUgY2hhbmdl cyB0byB0aGUgUEtDUyMxMSBzcGVjaWZpY2F0aW9uIHNob3VsZCBub3QNCiAg IGFmZmVjdCBleGlzdGluZyBhdHRyaWJ1dGVzLg0KDQogICBBIFBLQ1MjMTEg VVJJIHRha2VzIHRoZSBmb3JtIChmb3IgZXhwbGFuYXRpb24gb2YgQXVnbWVu dGVkIEJORiwgc2VlDQogICBbUkZDNTIzNF0pOg0KDQoNCg0KDQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1 ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAg IEphbnVhcnkgMjAxNQ0KDQoNCiAgcGsxMS1VUkkgICAgICAgICAgICAgPSAi cGtjczExOiIgcGsxMS1wYXRoIFsgIj8iIHBrMTEtcXVlcnkgXQ0KICA7IFBh dGggY29tcG9uZW50IGFuZCBpdHMgYXR0cmlidXRlcy4gIFBhdGggbWF5IGJl IGVtcHR5Lg0KICBwazExLXBhdGggICAgICAgICAgICA9IFsgcGsxMS1wYXR0 ciAqKCI7IiBwazExLXBhdHRyKSBdDQogIHBrMTEtcGF0dHIgICAgICAgICAg ID0gcGsxMS10b2tlbiAvIHBrMTEtbWFudWYgLyBwazExLXNlcmlhbCAvDQog ICAgICAgICAgICAgICAgICAgICAgICAgcGsxMS1tb2RlbCAvIHBrMTEtbGli LW1hbnVmIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLWxpYi12 ZXIgLyBwazExLWxpYi1kZXNjIC8NCiAgICAgICAgICAgICAgICAgICAgICAg ICBwazExLW9iamVjdCAvIHBrMTEtdHlwZSAvIHBrMTEtaWQgLw0KICAgICAg ICAgICAgICAgICAgICAgICAgIHBrMTEtc2xvdC1kZXNjIC8gcGsxMS1zbG90 LW1hbnVmIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLXNsb3Qt aWQgLyBwazExLXYtcGF0dHINCiAgOyBRdWVyeSBjb21wb25lbnQgYW5kIGl0 cyBhdHRyaWJ1dGVzLiAgUXVlcnkgbWF5IGJlIGVtcHR5Lg0KICBwazExLXFh dHRyICAgICAgICAgICA9IHBrMTEtcGluLXNvdXJjZSAvIHBrMTEtcGluLXZh bHVlIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICBwazExLW1vZHVsZS1u YW1lIC8gcGsxMS1tb2R1bGUtcGF0aCAvDQogICAgICAgICAgICAgICAgICAg ICAgICAgcGsxMS12LXFhdHRyDQogIHBrMTEtcXVlcnkgICAgICAgICAgID0g WyBwazExLXFhdHRyICooIiYiIHBrMTEtcWF0dHIpIF0NCiAgOyBSRkMgMzk4 NiBzZWN0aW9uIDIuMiBtYW5kYXRlcyBhbGwgcG90ZW50aWFsbHkgcmVzZXJ2 ZWQgY2hhcmFjdGVycw0KICA7IHRoYXQgZG8gbm90IGNvbmZsaWN0IHdpdGgg YWN0dWFsIGRlbGltaXRlcnMgb2YgdGhlIFVSSSBkbyBub3QgaGF2ZQ0KICA7 IHRvIGJlIHBlcmNlbnQtZW5jb2RlZC4NCiAgcGsxMS1yZXMtYXZhaWwgICAg ICAgPSAiOiIgLyAiWyIgLyAiXSIgLyAiQCIgLyAiISIgLyAiJCIgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICInIiAvICIoIiAvICIpIiAvICIqIiAv ICIrIiAvICIsIiAvICI9Ig0KICBwazExLXBhdGgtcmVzLWF2YWlsICA9IHBr MTEtcmVzLWF2YWlsIC8gIiYiDQogIDsgIi8iIGFuZCAiPyIgaW4gdGhlIHF1 ZXJ5IGNvbXBvbmVudCBNQVkgYmUgdW5lbmNvZGVkIGJ1dCAiJiIgTVVTVA0K ICA7IGJlIGVuY29kZWQgc2luY2UgaXQgZnVuY3Rpb25zIGFzIGEgZGVsaW1p dGVyIHdpdGhpbiB0aGUgY29tcG9uZW50Lg0KICBwazExLXF1ZXJ5LXJlcy1h dmFpbCA9IHBrMTEtcmVzLWF2YWlsIC8gIi8iIC8gIj8iIC8gInwiDQogIHBr MTEtcGNoYXIgICAgICAgICAgID0gdW5yZXNlcnZlZCAvIHBrMTEtcGF0aC1y ZXMtYXZhaWwgLyBwY3QtZW5jb2RlZA0KICBwazExLXFjaGFyICAgICAgICAg ICA9IHVucmVzZXJ2ZWQgLyBwazExLXF1ZXJ5LXJlcy1hdmFpbCAvIHBjdC1l bmNvZGVkDQogIHBrMTEtdG9rZW4gICAgICAgICAgID0gInRva2VuIiAiPSIg KnBrMTEtcGNoYXINCiAgcGsxMS1tYW51ZiAgICAgICAgICAgPSAibWFudWZh Y3R1cmVyIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1zZXJpYWwgICAgICAg ICAgPSAic2VyaWFsIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1tb2RlbCAg ICAgICAgICAgPSAibW9kZWwiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxp Yi1tYW51ZiAgICAgICA9ICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIgIj0iICpw azExLXBjaGFyDQogIHBrMTEtbGliLWRlc2MgICAgICAgID0gImxpYnJhcnkt ZGVzY3JpcHRpb24iICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxpYi12ZXIg ICAgICAgICA9ICJsaWJyYXJ5LXZlcnNpb24iICI9IiAxKkRJR0lUIFsgIi4i IDEqRElHSVQgXQ0KICBwazExLW9iamVjdCAgICAgICAgICA9ICJvYmplY3Qi ICI9IiAqcGsxMS1wY2hhcg0KICBwazExLXR5cGUgICAgICAgICAgICA9ICJ0 eXBlIiAiPSIgKCAicHVibGljIiAvICJwcml2YXRlIiAvICJjZXJ0IiAvDQog ICAgICAgICAgICAgICAgICAgICAgICAgInNlY3JldC1rZXkiIC8gImRhdGEi ICkNCiAgcGsxMS1pZCAgICAgICAgICAgICAgPSAiaWQiICI9IiAqcGsxMS1w Y2hhcg0KICBwazExLXNsb3QtbWFudWYgICAgICA9ICJzbG90LW1hbnVmYWN0 dXJlciIgIj0iICpwazExLXBjaGFyDQogIHBrMTEtc2xvdC1kZXNjICAgICAg ID0gInNsb3QtZGVzY3JpcHRpb24iICI9IiAqcGsxMS1wY2hhcg0KICBwazEx LXNsb3QtaWQgICAgICAgICA9ICJzbG90LWlkIiAiPSIgMSpESUdJVA0KICBw azExLXBpbi1zb3VyY2UgICAgICA9ICJwaW4tc291cmNlIiAiPSIgKnBrMTEt cWNoYXINCiAgcGsxMS1waW4tdmFsdWUgICAgICAgPSAicGluLXZhbHVlIiAi PSIgKnBrMTEtcWNoYXINCiAgcGsxMS1tb2R1bGUtbmFtZSAgICAgPSAibW9k dWxlLW5hbWUiICI9IiAqcGsxMS1xY2hhcg0KICBwazExLW1vZHVsZS1wYXRo ICAgICA9ICJtb2R1bGUtcGF0aCIgIj0iICpwazExLXFjaGFyDQogIHBrMTEt di1hdHRyLW5tLWNoYXIgID0gQUxQSEEgLyBESUdJVCAvICItIiAvICJfIg0K ICA7IFBlcm1pdHRlZCB2YWx1ZSBvZiBhIHZlbmRvciBzcGVjaWZpYyBhdHRy aWJ1dGUgaXMgYmFzZWQgb24NCiAgOyB3aGV0aGVyIHRoZSBhdHRyaWJ1dGUg aXMgdXNlZCBpbiB0aGUgcGF0aCBvciBpbiB0aGUgcXVlcnkuDQogIHBrMTEt di1wYXR0ciAgICAgICAgID0gMSpwazExLXYtYXR0ci1ubS1jaGFyICI9IiAq cGsxMS1wY2hhcg0KICBwazExLXYtcWF0dHIgICAgICAgICA9IDEqcGsxMS12 LWF0dHItbm0tY2hhciAiPSIgKnBrMTEtcWNoYXINCg0KDQoNClBlY2hhbmVj ICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDgsIDIwMTUgICAgICAg ICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgICAgSmFudWFy eSAyMDE1DQoNCg0KICAgVGhlIFVSSSBwYXRoIGNvbXBvbmVudCBjb250YWlu cyBhdHRyaWJ1dGVzIHRoYXQgaWRlbnRpZnkgYSByZXNvdXJjZQ0KICAgaW4g YSBvbmUgbGV2ZWwgaGllcmFyY2h5IHByb3ZpZGVkIGJ5IENyeXB0b2tpIHBy b2R1Y2Vycy4gIFRoZSBxdWVyeQ0KICAgY29tcG9uZW50IGNhbiBjb250YWlu IGEgZmV3IGF0dHJpYnV0ZXMgdGhhdCBtYXkgYmUgbmVlZGVkIHRvIHJldHJp ZXZlDQogICB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgVVJJIHBh dGguICBBdHRyaWJ1dGVzIGluIHRoZSBwYXRoDQogICBjb21wb25lbnQgYXJl IGRlbGltaXRlZCBieSAnOycgY2hhcmFjdGVyLCBhdHRyaWJ1dGVzIGluIHRo ZSBxdWVyeQ0KICAgY29tcG9uZW50IHVzZSAnJicgYXMgYSBkZWxpbWl0ZXIu DQoNCiAgIEJvdGggcGF0aCBhbmQgcXVlcnkgY29tcG9uZW50cyBtYXkgY29u dGFpbiB2ZW5kb3Igc3BlY2lmaWMNCiAgIGF0dHJpYnV0ZXMuICBTdWNoIGF0 dHJpYnV0ZSBuYW1lcyBNVVNUIE5PVCBjbGFzaCB3aXRoIGV4aXN0aW5nDQog ICBhdHRyaWJ1dGUgbmFtZXMuICBOb3RlIHRoYXQgaW4gYWNjb3JkYW5jZSB3 aXRoIFtCQ1AxNzhdLCBwcmV2aW91c2x5DQogICB1c2VkIGNvbnZlbnRpb24g b2Ygc3RhcnRpbmcgdmVuZG9yIGF0dHJpYnV0ZXMgd2l0aCBhbiAieC0iIHBy ZWZpeCBpcw0KICAgbm93IGRlcHJpY2F0ZWQuDQoNCiAgIFRoZSBnZW5lcmFs ICcvJyBkZWxpbWl0ZXIgTVVTVCBiZSBwZXJjZW50LWVuY29kZWQgaW4gdGhl IHBhdGgNCiAgIGNvbXBvbmVudCBzbyB0aGF0IGdlbmVyaWMgVVJJIHBhcnNl cnMgbmV2ZXIgc3BsaXQgdGhlIHBhdGggY29tcG9uZW50DQogICBpbnRvIG11 bHRpcGxlIHNlZ21lbnRzLiAgSXQgTUFZIGJlIHVuZW5jb2RlZCBpbiB0aGUg cXVlcnkgY29tcG9uZW50Lg0KICAgRGVsaW1pdGVyICc/JyAgTVVTVCBiZSBw ZXJjZW50LWVuY29kZWQgaW4gdGhlIHBhdGggY29tcG9uZW50IHNpbmNlDQog ICB0aGUgUEtDUyMxMSBVUkkgdXNlcyBhIHF1ZXJ5IGNvbXBvbmVudC4gIERl bGltaXRlciAnIycgTVVTVCBiZSBhbHdheXMNCiAgIHBlcmNlbnQtZW5jb2Rl ZCBzbyB0aGF0IGdlbmVyaWMgVVJJIHBhcnNlcnMgZG8gbm90IHRyZWF0IGEg aGFzaCBhcyBhDQogICBiZWdpbm5pbmcgb2YgYSBmcmFnbWVudCBpZGVudGlm aWVyIGNvbXBvbmVudC4gIEFsbCBvdGhlciBnZW5lcmljDQogICBkZWxpbWl0 ZXJzIE1BWSBiZSB1c2VkIHVuZW5jb2RlZCAoJzonLCAnWycsICddJywgYW5k ICdAJykgaW4gdGhlDQogICBQS0NTIzExIFVSSS4NCg0KICAgVGhlIGZvbGxv d2luZyB0YWJsZSBwcmVzZW50cyBtYXBwaW5nIGJldHdlZW4gdGhlIFBLQ1Mj MTEgVVJJIHBhdGgNCiAgIGNvbXBvbmVudCBhdHRyaWJ1dGVzIGFuZCB0aGUg UEtDUyMxMSBBUEkgc3RydWN0dXJlIG1lbWJlcnMgYW5kIG9iamVjdA0KICAg YXR0cmlidXRlcy4gIEdpdmVuIHRoYXQgUEtDUyMxMSBVUkkgdXNlcnMgbWF5 IGJlIHF1aXRlIGlnbm9yYW50IGFib3V0DQogICB0aGUgUEtDUyMxMSBzcGVj aWZpY2F0aW9uIHRoZSBtYXBwaW5nIGlzIGEgcHJvZHVjdCBvZiBhIG5lY2Vz c2FyeQ0KICAgY29tcHJvbWlzZSBiZXR3ZWVuIGhvdyBwcmVjaXNlbHkgYXJl IHRoZSBVUkkgYXR0cmlidXRlIG5hbWVzIG1hcHBlZA0KICAgdG8gdGhlIG5h bWVzIGluIHRoZSBzcGVjaWZpY2F0aW9uIGFuZCB0aGUgZWFzZSBvZiB1c2Ug YW5kDQogICB1bmRlcnN0YW5kaW5nIG9mIHRoZSBVUkkgc2NoZW1lLg0KDQog ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVVJJIGNvbXBvbmVu dCBwYXRoICAgfCBBdHRyaWJ1dGUgICAgICAgICAgIHwgQXR0cmlidXRlICAg ICAgICAgICAgfA0KICAgfCBhdHRyaWJ1dGUgbmFtZSAgICAgICB8IHJlcHJl c2VudHMgICAgICAgICAgfCBjb3JyZXNwb25kcyBpbiB0aGUgICB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 IFBLQ1MjMTEgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgc3BlY2lmaWNhdGlvbiB0 byAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgfCBpZCAgICAgICAgICAgICAgICAgICB8IGtleSBpZGVudGlm aWVyIGZvciAgfCAiQ0tBX0lEIiBvYmplY3QgICAgICB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgb2JqZWN0ICAgICAgICAgICAgICB8IGF0dHJp YnV0ZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgfCBsaWJyYXJ5LWRlc2NyaXB0aW9uICB8IGNoYXJhY3Rlci1zdHJp bmcgICAgfCAibGlicmFyeURlc2NyaXB0aW9uIiB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgZGVzY3JpcHRpb24gb2YgdGhlICB8IG1lbWJlciBv ZiBDS19JTkZPICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBs aWJyYXJ5ICAgICAgICAgICAgIHwgc3RydWN0dXJlLiAgSXQgaXMgYW4gfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCBVVEYtOCBzdHJpbmcuICAgICAgICB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCiAgIHwgbGlicmFyeS1tYW51ZmFjdHVyZXIgfCBJRCBv ZiB0aGUgQ3J5cHRva2kgIHwgIm1hbnVmYWN0dXJlcklEIiAgICAgfA0KDQoN Cg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwg MjAxNSAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAg ICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICB8ICAgICAgICAgICAgICAgICAg ICAgIHwgbGlicmFyeSAgICAgICAgICAgICB8IG1lbWJlciBvZiB0aGUgICAg ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51ZmFjdHVy ZXIgICAgICAgIHwgQ0tfSU5GTyBzdHJ1Y3R1cmUuICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBJdCBp cyBhbiBVVEYtOCAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICB8IHN0cmluZy4gICAgICAgICAgICAg IHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBsaWJyYXJ5 LXZlcnNpb24gICAgICB8IENyeXB0b2tpIGxpYnJhcnkgICAgfCAibGlicmFy eVZlcnNpb24iICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwg dmVyc2lvbiBudW1iZXIgICAgICB8IG1lbWJlciBvZiBDS19JTkZPICAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgIHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQogICB8IG1hbnVmYWN0dXJlciAgICAgICAgIHwgSUQg b2YgdGhlIHRva2VuICAgICB8ICJtYW51ZmFjdHVyZXJJRCIgICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51ZmFjdHVyZXIgICAgICAg IHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBDS19UT0tFTl9JTkZP ICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICB8IHN0cnVjdHVyZS4gIEl0IGlzIGFuIHwNCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg VVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQogICB8IG1vZGVsICAgICAgICAgICAgICAgIHwgdG9rZW4gbW9k ZWwgICAgICAgICB8ICJtb2RlbCIgbWVtYmVyIG9mICAgIHwNCiAgIHwgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgQ0tf VE9LRU5fSU5GTyAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgfCBzdHJ1Y3R1cmUuICBJdCBpcyBh biB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICB8IFVURi04IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgfCBvYmplY3QgICAgICAgICAgICAgICB8 IGRlc2NyaXB0aW9uIChuYW1lKSAgfCAiQ0tBX0xBQkVMIiBvYmplY3QgICB8 DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgb2YgdGhlIG9iamVjdCAg ICAgICB8IGF0dHJpYnV0ZS4gIEl0IGlzIGFuIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwgVVRGLTggc3Ry aW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8IHNlcmlhbCAgICAgICAgICAgICAgIHwgY2hhcmFjdGVyLXN0cmluZyAg ICB8ICJzZXJpYWxOdW1iZXIiICAgICAgIHwNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCBzZXJpYWwgbnVtYmVyIG9mICAgIHwgbWVtYmVyIG9mICAg ICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHRoZSB0 b2tlbiAgICAgICAgICAgfCBDS19UT0tFTl9JTkZPICAgICAgICB8DQogICB8 ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 IHN0cnVjdHVyZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KICAgfCBzbG90LWRlc2NyaXB0aW9uICAgICB8IHNsb3QgZGVz Y3JpcHRpb24gICAgfCAic2xvdERlc2NyaXB0aW9uIiAgICB8DQogICB8ICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IG1l bWJlciBvZiAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwgQ0tfU0xPVF9JTkZPICAgICAg ICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgfCBzdHJ1Y3R1cmUuICBJdCBpcyBhbiB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IFVURi04 IHN0cmluZy4gICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KICAgfCBzbG90LWlkICAgICAgICAgICAgICB8IENyeXB0b2tpLWFzc2ln bmVkICAgfCBkZWNpbWFsIG51bWJlciBvZiAgICB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgIHwgdmFsdWUgdGhhdCAgICAgICAgICB8ICJDS19TTE9U X0lEIiB0eXBlICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBp ZGVudGlmaWVzIGEgc2xvdCAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IHNsb3QtbWFudWZh Y3R1cmVyICAgIHwgSUQgb2YgdGhlIHNsb3QgICAgICB8ICJtYW51ZmFjdHVy ZXJJRCIgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBtYW51 ZmFjdHVyZXIgICAgICAgIHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0KICAg fCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fCBDS19TTE9UX0lORk8gICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IHN0cnVjdHVyZS4gIEl0 IGlzIGFuIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgVVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IHRva2VuICAgICAgICAgICAg ICAgIHwgYXBwbGljYXRpb24tZGVmaW5lZCB8ICJsYWJlbCIgbWVtYmVyIG9m ICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBsYWJlbCwgYXNz aWduZWQgICAgIHwgdGhlIENLX1RPS0VOX0lORk8gICAgfA0KICAgfCAgICAg ICAgICAgICAgICAgICAgICB8IGR1cmluZyB0b2tlbiAgICAgICAgfCBzdHJ1 Y3R1cmUuICBJdCBpcyBhbiB8DQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICAg W1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoN CiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBpbml0aWFsaXphdGlvbiAg ICAgIHwgVVRGLTggc3RyaW5nLiAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQogICB8IHR5cGUgICAgICAgICAgICAgICAgIHwgb2Jq ZWN0IGNsYXNzICh0eXBlKSB8ICJDS0FfQ0xBU1MiIG9iamVjdCAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg IHwgYXR0cmlidXRlICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQoNCiAgICBUYWJsZSAxOiBNYXBwaW5nIGJldHdlZW4gVVJJ IHBhdGggY29tcG9uZW50IGF0dHJpYnV0ZXMgYW5kIFBLQ1MjMTENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcGVjaWZpY2F0aW9uIG5hbWVzDQoN CiAgIFRoZSBxdWVyeSBjb21wb25lbnQgYXR0cmlidXRlICJwaW4tc291cmNl IiBzcGVjaWZpZXMgd2hlcmUgdGhlDQogICBhcHBsaWNhdGlvbiBvciBsaWJy YXJ5IHNob3VsZCBmaW5kIHRoZSBub3JtYWwgdXNlcidzIHRva2VuIFBJTiwg dGhlDQogICAicGluLXZhbHVlIiBhdHRyaWJ1dGUgcHJvdmlkZXMgdGhlIG5v cm1hbCB1c2VyJ3MgUElOIHZhbHVlIGRpcmVjdGx5LA0KICAgaWYgbmVlZGVk LCBhbmQgdGhlICJtb2R1bGUtbmFtZSIgYW5kICJtb2R1bGUtcGF0aCIgYXR0 cmlidXRlcyBtb2RpZnkNCiAgIGRlZmF1bHQgc2V0dGluZ3MgZm9yIGFjY2Vz c2luZyBQS0NTIzExIHByb3ZpZGVycy4gIEZvciB0aGUgZGVmaW5pdGlvbg0K ICAgb2YgYSAibm9ybWFsIHVzZXIiLCBzZWUgW1BLQ1MxMV0uDQoNCiAgIFRo ZSBBQk5GIHJ1bGVzIGFib3ZlIGlzIGEgYmVzdCBlZmZvcnQgZGVmaW5pdGlv biBhbmQgdGhpcyBwYXJhZ3JhcGgNCiAgIHNwZWNpZmllcyBhZGRpdGlvbmFs IGNvbnN0cmFpbnRzLiAgVGhlIFBLQ1MjMTEgVVJJIE1VU1QgTk9UIGNvbnRh aW4NCiAgIGR1cGxpY2F0ZSBhdHRyaWJ1dGVzIG9mIHRoZSBzYW1lIG5hbWUg aW4gdGhlIFVSSSBwYXRoIGNvbXBvbmVudC4gIEl0DQogICBtZWFucyB0aGF0 IGVhY2ggYXR0cmlidXRlIG1heSBiZSBwcmVzZW50IGF0IG1vc3Qgb25jZSBp biB0aGUgUEtDUyMxMQ0KICAgVVJJIHBhdGguICBBc2lkZSBmcm9tIHRoZSBx dWVyeSBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwNCiAg IGR1cGxpY2F0ZSAodmVuZG9yKSBhdHRyaWJ1dGVzIE1BWSBiZSBwcmVzZW50 IGluIHRoZSBVUkkgcXVlcnkNCiAgIGNvbXBvbmVudCBhbmQgaXQgaXMgdXAg dG8gdGhlIFVSSSBjb25zdW1lciB0byBkZWNpZGUgb24gaG93IHRvIGRlYWwN CiAgIHdpdGggc3VjaCBkdXBsaWNhdGVzLg0KDQogICBUaGUgd2hvbGUgdmFs dWUgb2YgdGhlICJpZCIgYXR0cmlidXRlIFNIT1VMRCBiZSBwZXJjZW50LWVu Y29kZWQgc2luY2UNCiAgIGl0IGlzIHN1cHBvc2VkIHRvIGJlIGhhbmRsZWQg YXMgYXJiaXRyYXJ5IGJpbmFyeSBkYXRhLg0KDQogICBUaGUgImxpYnJhcnkt dmVyc2lvbiIgYXR0cmlidXRlIHJlcHJlc2VudHMgdGhlIG1ham9yIGFuZCBt aW5vcg0KICAgdmVyc2lvbiBudW1iZXIgb2YgdGhlIGxpYnJhcnkgYW5kIGl0 cyBmb3JtYXQgaXMgIk0uTiIuICBCb3RoIG51bWJlcnMNCiAgIGFyZSBvbmUg Ynl0ZSBpbiBzaXplLCBzZWUgdGhlICJsaWJyYXJ5VmVyc2lvbiIgbWVtYmVy IG9mIHRoZSBDS19JTkZPDQogICBzdHJ1Y3R1cmUgaW4gW1BLQ1MxMV0gZm9y IG1vcmUgaW5mb3JtYXRpb24uICBWYWx1ZSAiTSIgZm9yIHRoZQ0KICAgYXR0 cmlidXRlIE1VU1QgYmUgaW50ZXJwcmV0ZWQgYXMgIk0iIGZvciB0aGUgbWFq b3IgYW5kICIwIiBmb3IgdGhlDQogICBtaW5vciB2ZXJzaW9uIG9mIHRoZSBs aWJyYXJ5LiAgSWYgdGhlIGF0dHJpYnV0ZSBpcyBwcmVzZW50IHRoZSBtYWpv cg0KICAgdmVyc2lvbiBudW1iZXIgaXMgUkVRVUlSRUQuICBCb3RoICJNIiBh bmQgIk4iIE1VU1QgYmUgZGVjaW1hbA0KICAgbnVtYmVycy4NCg0KICAgU2xv dCBJRCBpcyBhIENyeXB0b2tpLWFzc2lnbmVkIG51bWJlciB0aGF0IGlzIG5v dCBndWFyYW50ZWVkIHN0YWJsZQ0KICAgYWNyb3NzIFBLQ1MjMTEgbW9kdWxl IGluaXRpYWxpemF0aW9ucy4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBjZXJ0YWlu DQogICBsaWJyYXJpZXMgYW5kIG1vZHVsZXMgd2hpY2ggcHJvdmlkZSBzdGFi bGUgc2xvdCBpZGVudGlmaWVycy4gIEZvcg0KICAgdGhlc2UgY2FzZXMsIHdo ZW4gdGhlIHNsb3QgZGVzY3JpcHRpb24gYW5kIG1hbnVmYWN0dXJlciBJRCBp cyBub3QNCiAgIHN1ZmZpY2llbnQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYSBz cGVjaWZpYyByZWFkZXIsIHRoZSBzbG90IElEIE1BWSBiZQ0KICAgdXNlZCB0 byBpbmNyZWFzZSB0aGUgcHJlY2lzaW9uIG9mIHRoZSB0b2tlbiBpZGVudGlm aWNhdGlvbi4gIEluIG90aGVyDQogICBzY2VuYXJpb3MsIHVzaW5nIHRoZSBz bG90IElEcyBpcyBsaWtlbHkgdG8gY2F1c2UgdXNhYmlsaXR5IGlzc3Vlcy4N Cg0KICAgQW4gZW1wdHkgUEtDUyMxMSBVUkkgcGF0aCBhdHRyaWJ1dGUgdGhh dCBkb2VzIGFsbG93IGZvciBhbiBlbXB0eQ0KICAgdmFsdWUgbWF0Y2hlcyBh IGNvcnJlc3BvbmRpbmcgc3RydWN0dXJlIG1lbWJlciBvciBhbiBvYmplY3Qg YXR0cmlidXRlDQogICB3aXRoIGFuIGVtcHR5IHZhbHVlLiAgTm90ZSB0aGF0 IGFjY29yZGluZyB0byB0aGUgUEtDUyMxMQ0KDQoNCg0KUGVjaGFuZWMgJiBN b2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg VGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIw MTUNCg0KDQogICBzcGVjaWZpY2F0aW9uIFtQS0NTMTFdLCBlbXB0eSBjaGFy YWN0ZXIgdmFsdWVzIGluIGEgUEtDUyMxMSBBUEkNCiAgIHByb2R1Y2VyIG11 c3QgYmUgcGFkZGVkIHdpdGggc3BhY2VzIGFuZCBzaG91bGQgbm90IGJlIE5V TEwNCiAgIHRlcm1pbmF0ZWQuDQoNCjMuNC4gIFBLQ1MjMTEgVVJJIFNjaGVt ZSBRdWVyeSBBdHRyaWJ1dGUgU2VtYW50aWNzDQoNCiAgIEFuIGFwcGxpY2F0 aW9uIE1BWSBhbHdheXMgYXNrIGZvciBhIFBJTiBieSBhbnkgbWVhbnMgaXQg ZGVjaWRlcyB0by4NCiAgIFdoYXQgaXMgbW9yZSwgaW4gb3JkZXIgbm90IHRv IGxpbWl0IFBLQ1MjMTEgVVJJIHBvcnRhYmlsaXR5IHRoZSAicGluLQ0KICAg c291cmNlIiBhdHRyaWJ1dGUgdmFsdWUgZm9ybWF0IGFuZCBpbnRlcnByZXRh dGlvbiBpcyBsZWZ0IHRvIGJlDQogICBpbXBsZW1lbnRhdGlvbiBzcGVjaWZp Yy4gIEhvd2V2ZXIsIHRoZSBmb2xsb3dpbmcgcnVsZXMgU0hPVUxEIGJlDQog ICBmb2xsb3dlZCBpbiBkZXNjZW5kaW5nIG9yZGVyIGZvciB0aGUgdmFsdWUg b2YgdGhlICJwaW4tc291cmNlIg0KICAgYXR0cmlidXRlOg0KDQogICBvICBp ZiB0aGUgdmFsdWUgcmVwcmVzZW50cyBhIGxvY2FsIGFic29sdXRlIHBhdGgg dGhlIGltcGxlbWVudGF0aW9uDQogICAgICBTSE9VTEQgdXNlIGl0IGFzIGEg UElOIGZpbGUgY29udGFpbmluZyB0aGUgUElOIHZhbHVlDQoNCiAgIG8gIGlm IHRoZSB2YWx1ZSBjb250YWlucyAifDxhYnNvbHV0ZS1jb21tYW5kLXBhdGg+ IiB0aGUNCiAgICAgIGltcGxlbWVudGF0aW9uIFNIT1VMRCByZWFkIHRoZSBQ SU4gZnJvbSB0aGUgb3V0cHV0IG9mIGFuDQogICAgICBhcHBsaWNhdGlvbiBz cGVjaWZpZWQgd2l0aCBhYnNvbHV0ZSBwYXRoICI8YWJzb2x1dGUtY29tbWFu ZC0NCiAgICAgIHBhdGg+Ii4gIE5vdGUgdGhhdCBjaGFyYWN0ZXIgInwiIHJl cHJlc2VudGluZyBhIHBpcGUgZG9lcyBub3QgaGF2ZQ0KICAgICAgdG8gYmUg cGVyY2VudCBlbmNvZGVkIGluIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhl IFBLQ1MjMTEgVVJJLg0KDQogICBvICBpZiB0aGUgdmFsdWUgcmVwcmVzZW50 cyBhIFVSSSBpdCBTSE9VTEQgYmUgdHJlYXRlZCBhcyBhbiBvYmplY3QNCiAg ICAgIGNvbnRhaW5pbmcgdGhlIFBJTi4gIFN1Y2ggYSBVUkkgbWF5IGJlICJm aWxlOiIsICJodHRwczoiLCBhbm90aGVyDQogICAgICBQS0NTIzExIFVSSSwg b3Igc29tZXRoaW5nIGVsc2UuDQoNCiAgIG8gIGludGVycHJldCB0aGUgdmFs dWUgYXMgbmVlZGVkIGluIGFuIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCB3 YXkNCg0KICAgSWYgYSBVUkkgY29udGFpbnMgYm90aCAicGluLXNvdXJjZSIg YW5kICJwaW4tdmFsdWUiIHF1ZXJ5IGF0dHJpYnV0ZXMNCiAgIHRoZSBVUkkg U0hPVUxEIGJlIHJlZnVzZWQgYXMgaW52YWxpZC4NCg0KICAgVXNlIG9mIHRo ZSAicGluLXZhbHVlIiBhdHRyaWJ1dGUgbWF5IGhhdmUgc2VjdXJpdHkgcmVs YXRlZA0KICAgY29uc2VxdWVuY2VzLiAgU2VjdGlvbiA3IHNob3VsZCBiZSBj b25zdWx0ZWQgYmVmb3JlIHRoaXMgYXR0cmlidXRlIGlzDQogICBldmVyIHVz ZWQuICBTdGFuZGFyZCBwZXJjZW50IGVuY29kaW5nIHJ1bGVzIFNIT1VMRCBi ZSBmb2xsb3dlZCBmb3INCiAgIHRoZSBhdHRyaWJ1dGUgdmFsdWUuDQoNCiAg IEEgY29uc3VtZXIgb2YgUEtDUyMxMSBVUklzIE1BWSBtb2RpZnkgZGVmYXVs dCBzZXR0aW5ncyBmb3IgYWNjZXNzaW5nDQogICBhIFBLQ1MjMTEgcHJvdmlk ZXIgb3IgcHJvdmlkZXJzIGJ5IGFjY2VwdGluZyBxdWVyeSBjb21wb25lbnQN CiAgIGF0dHJpYnV0ZXMgIm1vZHVsZS1uYW1lIiBhbmQgIm1vZHVsZS1wYXRo Ii4iDQoNCiAgIFByb2Nlc3NpbmcgdGhlIFVSSSBxdWVyeSBtb2R1bGUgYXR0 cmlidXRlcyBTSE9VTEQgZm9sbG93IHRoZXNlIHJ1bGVzOg0KDQogICBvICBh dHRyaWJ1dGUgIm1vZHVsZS1uYW1lIiBTSE9VTEQgY29udGFpbiBhIGNhc2Ut aW5zZW5zaXRpdmUgUEtDUyMxMQ0KICAgICAgbW9kdWxlIG5hbWUgKG5vdCBw YXRoIG5vciBmaWxlbmFtZSkgd2l0aG91dCBzeXN0ZW0gc3BlY2lmaWMNCiAg ICAgIGFmZml4ZXMuICBTdWNoIGFmZml4IGNvdWxkIGJlIGFuICIuc28iIG9y ICIuRExMIiBzdWZmaXgsIG9yIGENCiAgICAgICJsaWIiIHByZWZpeCwgZm9y IGV4YW1wbGUuICBOb3QgdXNpbmcgc3lzdGVtIHNwZWNpZmljIGFmZml4ZXMg aXMNCiAgICAgIGV4cGVjdGVkIHRvIGluY3JlYXNlIHBvcnRhYmlsaXR5IG9m IFBLQ1MjMTEgVVJJcyBhbW9uZyBkaWZmZXJlbnQNCiAgICAgIHN5c3RlbXMu ICBBIFVSSSBjb25zdW1lciBzZWFyY2hpbmcgZm9yIFBLQ1MjMTEgbW9kdWxl cyBTSE9VTEQgdXNlDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAg IEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICAgW1BhZ2Ug OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBV UkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAgICAg IGEgc3lzdGVtIG9yIGFwcGxpY2F0aW9uIHNwZWNpZmljIGxvY2F0aW9ucyB0 byBmaW5kIG1vZHVsZXMgYmFzZWQNCiAgICAgIG9uIHRoZSBuYW1lIHByb3Zp ZGVkIGluIHRoZSBhdHRyaWJ1dGUuDQoNCiAgIG8gIGF0dHJpYnV0ZSAibW9k dWxlLXBhdGgiIFNIT1VMRCBjb250YWluIGEgc3lzdGVtIHNwZWNpZmljIGFi c29sdXRlDQogICAgICBwYXRoIHRvIHRoZSBQS0NTIzExIG1vZHVsZSwgb3Ig YSBzeXN0ZW0gc3BlY2lmaWMgYWJzb2x1dGUgcGF0aCB0bw0KICAgICAgdGhl IGRpcmVjdG9yeSBvZiB3aGVyZSBQS0NTIzExIG1vZHVsZXMgYXJlIGxvY2F0 ZWQuICBGb3Igc2VjdXJpdHkNCiAgICAgIHJlYXNvbnMsIGEgVVJJIHdpdGgg YSByZWxhdGl2ZSBwYXRoIGluIHRoaXMgYXR0cmlidXRlIFNIT1VMRCBiZQ0K ICAgICAgcmVqZWN0ZWQuDQoNCiAgIG8gIHRoZSBVUkkgY29uc3VtZXIgTUFZ IHJlZnVzZSB0byBhY2NlcHQgZWl0aGVyIG9mIHRoZSBhdHRyaWJ1dGVzLCBv cg0KICAgICAgYm90aC4gIElmIHVzZSBvZiBhbiBhdHRyaWJ1dGUgcHJlc2Vu dCBpbiB0aGUgVVJJIHN0cmluZyBpcyBub3QNCiAgICAgIGFjY2VwdGVkIGEg d2FybmluZyBtZXNzYWdlIFNIT1VMRCBiZSBwcmVzZW50ZWQgdG8gdGhlIHBy b3ZpZGVyIG9mDQogICAgICB0aGUgVVJJLg0KDQogICBvICBpZiBlaXRoZXIg b2YgdGhlIG1vZHVsZSBhdHRyaWJ1dGVzIGlzIHByZXNlbnQsIG9ubHkgdGhv c2UgbW9kdWxlcw0KICAgICAgZm91bmQgbWF0Y2hpbmcgdGhlc2UgcXVlcnkg YXR0cmlidXRlcyBTSE9VTEQgYmUgdXNlZCB0byBzZWFyY2ggZm9yDQogICAg ICBhbiBlbnRpdHkgcmVwcmVzZW50ZWQgYnkgdGhlIFVSSS4NCg0KICAgbyAg dXNlIG9mIHRoZSBtb2R1bGUgYXR0cmlidXRlcyBkb2VzIG5vdCBzdXBwcmVz cyBtYXRjaGluZyBvZiBhbnkNCiAgICAgIG90aGVyIFVSSSBwYXRoIGNvbXBv bmVudCBhdHRyaWJ1dGVzIHByZXNlbnQgaW4gYSBVUkkuDQoNCiAgIG8gIHNl bWFudGljcyBvZiB1c2luZyBib3RoIGF0dHJpYnV0ZXMgaW4gdGhlIHNhbWUg VVJJIHN0cmluZyBpcw0KICAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMg YnV0IHN1Y2ggdXNlIFNIT1VMRCBiZSBhdm9pZGVkLiAgQXR0cmlidXRlDQog ICAgICAibW9kdWxlLW5hbWUiIGlzIHByZWZlcnJlZCB0byAibW9kdWxlLXBh dGgiIGR1ZSB0byBpdHMgc3lzdGVtDQogICAgICBpbmRlcGVuZGVudCBuYXR1 cmUgYnV0IHRoZSBsYXR0ZXIgbWF5IGJlIG1vcmUgc3VpdGFibGUgZm9yDQog ICAgICBkZXZlbG9wbWVudCBhbmQgZGVidWdnaW5nLg0KDQogICBvICBhIFVS SSBNVVNUIE5PVCBjb250YWluIG11bHRpcGxlIG1vZHVsZSBhdHRyaWJ1dGVz IG9mIHRoZSBzYW1lDQogICAgICBuYW1lLg0KDQogICBVc2Ugb2YgdGhlIG1v ZHVsZSBhdHRyaWJ1dGVzIG1heSBoYXZlIHNlY3VyaXR5IHJlbGF0ZWQgY29u c2VxdWVuY2VzLg0KICAgU2VjdGlvbiA3IHNob3VsZCBiZSBjb25zdWx0ZWQg YmVmb3JlIHRoZXNlIGF0dHJpYnV0ZXMgYXJlIGV2ZXIgdXNlZC4NCg0KICAg QSB3b3JkICJtb2R1bGUiIHdhcyBjaG9zZW4gb3ZlciB3b3JkICJsaWJyYXJ5 IiBpbiB0aGVzZSBxdWVyeQ0KICAgYXR0cmlidXRlIG5hbWVzIHRvIGF2b2lk IGNvbmZ1c2lvbiB3aXRoIHNlbWFudGljYWxseSBkaWZmZXJlbnQNCiAgIGxp YnJhcnkgYXR0cmlidXRlcyB1c2VkIGluIHRoZSBVUkkgcGF0aCBjb21wb25l bnQuDQoNCjMuNS4gIFBLQ1MjMTEgVVJJIE1hdGNoaW5nIEd1aWRlbGluZXMN Cg0KICAgVGhlIFBLQ1MjMTEgVVJJIGNhbiBpZGVudGlmeSBQS0NTIzExIHN0 b3JhZ2Ugb2JqZWN0cywgdG9rZW5zLCBzbG90cywNCiAgIG9yIENyeXB0b2tp IGxpYnJhcmllcy4gIE5vdGUgdGhhdCBzaW5jZSBhIFVSSSBtYXkgaWRlbnRp ZnkgZm91cg0KICAgZGlmZmVyZW50IHR5cGVzIG9mIGVudGl0aWVzIHRoZSBj b250ZXh0IHdpdGhpbiB3aGljaCB0aGUgVVJJIGlzIHVzZWQNCiAgIG1heSBi ZSBuZWVkZWQgdG8gZGV0ZXJtaW5lIHRoZSB0eXBlLiAgRm9yIGV4YW1wbGUs IGEgVVJJIHdpdGggb25seQ0KICAgbGlicmFyeSBhdHRyaWJ1dGVzIG1heSBl aXRoZXIgcmVwcmVzZW50IGFsbCBvYmplY3RzIGluIGFsbCB0b2tlbnMgaW4N CiAgIGFsbCBDcnlwdG9raSBsaWJyYXJpZXMgaWRlbnRpZmllZCBieSB0aGUg VVJJLCBhbGwgdG9rZW5zIGluIHRob3NlDQogICBsaWJyYXJpZXMsIG9yIGp1 c3QgdGhlIGxpYnJhcmllcy4NCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZh dCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUg UEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0K DQoNCiAgIFRoZSBmb2xsb3dpbmcgZ3VpZGVsaW5lcyBjYW4gaGVscCBhIFBL Q1MjMTEgVVJJIGNvbnN1bWVyIChlZy4gYW4NCiAgIGFwcGxpY2F0aW9uIGFj Y2VwdGluZyBQS0NTIzExIFVSSXMpIHRvIG1hdGNoIHRoZSBVUkkgd2l0aCB0 aGUgZGVzaXJlZA0KICAgcmVzb3VyY2UuDQoNCiAgIG8gIHRoZSBjb25zdW1l ciBNVVNUIGtub3cgd2hldGhlciB0aGUgVVJJIGlzIHRvIGlkZW50aWZ5IFBL Q1MjMTENCiAgICAgIHN0b3JhZ2Ugb2JqZWN0KHMpLCB0b2tlbihzKSwgc2xv dChzKSwgb3IgQ3J5cHRva2kgcHJvZHVjZXIocykuDQoNCiAgIG8gIGlmIHRo ZSBjb25zdW1lciBpcyB3aWxsaW5nIHRvIGFjY2VwdCBxdWVyeSBjb21wb25l bnQgbW9kdWxlDQogICAgICBhdHRyaWJ1dGVzIG9ubHkgdGhvc2UgUEtDUyMx MSBwcm92aWRlcnMgbWF0Y2hpbmcgdGhlc2UgYXR0cmlidXRlcw0KICAgICAg U0hPVUxEIGJlIHdvcmtlZCB3aXRoLiAgU2VlIFNlY3Rpb24gMy40IGZvciBt b3JlIGluZm9ybWF0aW9uLg0KDQogICBvICBhbiB1bnJlY29nbml6ZWQgYXR0 cmlidXRlIGluIHRoZSBVUkkgcGF0aCBjb21wb25lbnQsIGluY2x1ZGluZyBh DQogICAgICB2ZW5kb3Igc3BlY2lmaWMgYXR0cmlidXRlLCBTSE9VTEQgcmVz dWx0IGluIGFuIGVtcHR5IHNldCBvZg0KICAgICAgbWF0Y2hlZCByZXNvdXJj ZXMuICBUaGUgY29uc3VtZXIgU0hPVUxEIGNvbnNpZGVyIHdoZXRoZXIgYW4g ZXJyb3INCiAgICAgIG1lc3NhZ2UgcHJlc2VudGVkIHRvIHRoZSB1c2VyIGlz IGFwcHJvcHJpYXRlIGluIHN1Y2ggYSBjYXNlLg0KDQogICBvICBhbiB1bnJl Y29nbml6ZWQgYXR0cmlidXRlIGluIHRoZSBVUkkgcXVlcnkgU0hPVUxEIGJl IGlnbm9yZWQuICBUaGUNCiAgICAgIGNvbnN1bWVyIFNIT1VMRCBjb25zaWRl ciB3aGV0aGVyIGEgd2FybmluZyBtZXNzYWdlIHByZXNlbnRlZCB0bw0KICAg ICAgdGhlIHVzZXIgaXMgYXBwcm9wcmlhdGUgaW4gc3VjaCBhIGNhc2UuDQoN CiAgIG8gIGFuIGF0dHJpYnV0ZSBub3QgcHJlc2VudCBpbiB0aGUgVVJJIHBh dGggYnV0IGtub3duIHRvIGEgY29uc3VtZXINCiAgICAgIG1hdGNoZXMgZXZl cnl0aGluZy4gIEVhY2ggYWRkaXRpb25hbCBhdHRyaWJ1dGUgcHJlc2VudCBp biB0aGUgVVJJDQogICAgICBwYXRoIGZ1cnRoZXIgcmVzdHJpY3RzIHRoZSBz ZWxlY3Rpb24uDQoNCiAgIG8gIGEgbG9naWNhbCBleHRlbnNpb24gb2YgdGhl IGFib3ZlIGlzIHRoYXQgYW4gZW1wdHkgVVJJIHBhdGggbWF0Y2hlcw0KICAg ICAgZXZlcnl0aGluZy4gIEZvciBleGFtcGxlLCBpZiB1c2VkIHRvIGlkZW50 aWZ5IHN0b3JhZ2Ugb2JqZWN0cyBpdA0KICAgICAgbWF0Y2hlcyBhbGwgYWNj ZXNzaWJsZSBvYmplY3RzIGluIGFsbCB0b2tlbnMgcHJvdmlkZWQgYnkgYWxs DQogICAgICBQS0NTIzExIEFQSSBwcm9kdWNlcnMgZm91bmQgaW4gdGhlIHN5 c3RlbS4NCg0KICAgbyAgbm90ZSB0aGF0IHVzZSBvZiBQSU4gYXR0cmlidXRl cyBtYXkgY2hhbmdlIHRoZSBzZXQgb2Ygc3RvcmFnZQ0KICAgICAgb2JqZWN0 cyB2aXNpYmxlIHRvIHRoZSBjb25zdW1lci4NCg0KICAgbyAgaW4gYWRkaXRp b24gdG8gcXVlcnkgY29tcG9uZW50IGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0 aGlzDQogICAgICBkb2N1bWVudCwgdmVuZG9yIHNwZWNpZmljIHF1ZXJ5IGF0 dHJpYnV0ZXMgbWF5IGNvbnRhaW4gZnVydGhlcg0KICAgICAgaW5mb3JtYXRp b24gYWJvdXQgaG93IHRvIHBlcmZvcm0gdGhlIHNlbGVjdGlvbiBvciBvdGhl ciByZWxhdGVkDQogICAgICBpbmZvcm1hdGlvbi4NCg0KICAgQXMgbm90ZWQg aW4gU2VjdGlvbiA2LCB0aGUgUEtDUyMxMSBzcGVjaWZpY2F0aW9uIGlzIG5v dCBjbGVhciBhYm91dA0KICAgaG93IHRvIG5vcm1hbGl6ZSBVVEYtOCBlbmNv ZGVkIFVuaWNvZGUgY2hhcmFjdGVycyBbUkZDMzYyOV0uICBUaG9zZQ0KICAg d2hvIGRpc2NvdmVyIGEgbmVlZCB0byB1c2UgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBBU0NJSSByZXBlcnRvaXJlDQogICBzaG91bGQgYmUgY2F1dGlvdXMs IGNvbnNlcnZhdGl2ZSwgYW5kIGV4cGVuZCBleHRyYSBlZmZvcnQgdG8gYmUg c3VyZQ0KICAgdGhleSBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcgYW5kIHRo YXQgZmFpbHVyZSB0byBkbyBzbyBtYXkgY3JlYXRlDQogICBib3RoIG9wZXJh dGlvbmFsIGFuZCBzZWN1cml0eSByaXNrcy4gIEl0IG1lYW5zIHRoYXQgd2hl biBtYXRjaGluZw0KICAgVVRGLTggc3RyaW5nIGJhc2VkIGF0dHJpYnV0ZXMg KHNlZSBUYWJsZSAxKSB3aXRoIHN1Y2ggY2hhcmFjdGVycywNCiAgIG5vcm1h bGl6aW5nIGFsbCBVVEYtOCBzdHJpbmdzIGJlZm9yZSBzdHJpbmcgY29tcGFy aXNvbiBtYXkgYmUgdGhlDQogICBvbmx5IHNhZmUgYXBwcm9hY2guICBGb3Ig ZXhhbXBsZSwgZm9yIG9iamVjdHMgKGtleXMpIGl0IG1lYW5zIHRoYXQNCiAg IFBLQ1MjMTEgYXR0cmlidXRlIHNlYXJjaCB0ZW1wbGF0ZSB3b3VsZCBvbmx5 IGNvbnRhaW4gYXR0cmlidXRlcyB0aGF0DQogICBhcmUgbm90IFVURi04IHN0 cmluZ3MgYW5kIGFub3RoZXIgcGFzcyB0aHJvdWdoIHJldHVybmVkIG9iamVj dHMgaXMNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJl cyBKdWx5IDgsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hl bWUgICAgICAgICAgICAgSmFudWFyeSAyMDE1DQoNCg0KICAgdGhlbiBuZWVk ZWQgZm9yIFVURi04IHN0cmluZyBjb21wYXJpc29uIGFmdGVyIHRoZSBub3Jt YWxpemF0aW9uIGlzDQogICBhcHBsaWVkLg0KDQozLjYuICBQS0NTIzExIFVS SSBDb21wYXJpc29uDQoNCiAgIENvbXBhcmlzb24gb2YgdHdvIFVSSXMgaXMg YSB3YXkgb2YgZGV0ZXJtaW5pbmcgd2hldGhlciB0aGUgVVJJcyBhcmUNCiAg IGVxdWl2YWxlbnQgd2l0aG91dCBjb21wYXJpbmcgdGhlIGFjdHVhbCByZXNv dXJjZSB0aGUgVVJJcyBwb2ludCB0by4NCiAgIFRoZSBjb21wYXJpc29uIG9m IFVSSXMgYWltcyB0byBtaW5pbWl6ZSBmYWxzZSBuZWdhdGl2ZXMgd2hpbGUN CiAgIHN0cmljdGx5IGF2b2lkaW5nIGZhbHNlIHBvc2l0aXZlcy4gIFdoZW4g d29ya2luZyB3aXRoIFVURi04IHN0cmluZ3MNCiAgIHdpdGggY2hhcmFjdGVy cyBvdXRzaWRlIHRoZSBBU0NJSSBjaGFyYWN0ZXIgc2V0cywgc2VlIGltcG9y dGFudA0KICAgY2F2ZWF0cyBpbiBTZWN0aW9uIDMuNSBhbmQgU2VjdGlvbiA2 Lg0KDQogICBUd28gUEtDUyMxMSBVUklzIGFyZSBzYWlkIHRvIGJlIGVxdWFs IGlmIFVSSXMgYXMgY2hhcmFjdGVyIHN0cmluZ3MNCiAgIGFyZSBpZGVudGlj YWwgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNi4yLjEgb2YgW1JGQzM5ODZd LCBvciBpZiBib3RoDQogICBmb2xsb3dpbmcgcnVsZXMgYXJlIGZ1bGZpbGxl ZDoNCg0KICAgbyAgc2V0IG9mIGF0dHJpYnV0ZXMgcHJlc2VudCBpbiB0aGUg VVJJIGlzIGVxdWFsLiAgTm90ZSB0aGF0IHRoZQ0KICAgICAgb3JkZXJpbmcg b2YgYXR0cmlidXRlcyBpbiB0aGUgVVJJIHN0cmluZyBpcyBub3Qgc2lnbmlm aWNhbnQgZm9yDQogICAgICB0aGUgbWVjaGFuaXNtIG9mIGNvbXBhcmlzb24u DQoNCiAgIG8gIHZhbHVlcyBvZiByZXNwZWN0aXZlIGF0dHJpYnV0ZXMgYXJl IGVxdWFsIGJhc2VkIG9uIHJ1bGVzIHNwZWNpZmllZA0KICAgICAgYmVsb3cN Cg0KICAgVGhlIHJ1bGVzIGZvciBjb21wYXJpbmcgdmFsdWVzIG9mIHJlc3Bl Y3RpdmUgYXR0cmlidXRlcyBhcmU6DQoNCiAgIG8gIHZhbHVlcyBvZiBwYXRo IGNvbXBvbmVudCBhdHRyaWJ1dGVzICJsaWJyYXJ5LWRlc2NyaXB0aW9uIiwN CiAgICAgICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIsICJtYW51ZmFjdHVyZXIi LCAibW9kZWwiLCAib2JqZWN0IiwNCiAgICAgICJzZXJpYWwiLCAic2xvdC1k ZXNjcmlwdGlvbiIsICJzbG90LW1hbnVmYWN0dXJlciIsICJ0b2tlbiIsDQog ICAgICAidHlwZSIsIGFuZCBxdWVyeSBjb21wb25lbnQgYXR0cmlidXRlICJt b2R1bGUtbmFtZSIgTVVTVCBiZQ0KICAgICAgY29tcGFyZWQgdXNpbmcgYSBz aW1wbGUgc3RyaW5nIGNvbXBhcmlzb24gYXMgc3BlY2lmaWVkIGluDQogICAg ICBTZWN0aW9uIDYuMi4xIG9mIFtSRkMzOTg2XSBhZnRlciB0aGUgY2FzZSBh bmQgdGhlIHBlcmNlbnQtZW5jb2RpbmcNCiAgICAgIG5vcm1hbGl6YXRpb24g YXJlIGJvdGggYXBwbGllZCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2LjIu MiBvZg0KICAgICAgW1JGQzM5ODZdLg0KDQogICBvICB2YWx1ZSBvZiBhdHRy aWJ1dGUgImlkIiBNVVNUIGJlIGNvbXBhcmVkIHVzaW5nIHRoZSBzaW1wbGUg c3RyaW5nDQogICAgICBjb21wYXJpc29uIGFmdGVyIGFsbCBieXRlcyBhcmUg cGVyY2VudC1lbmNvZGVkIHVzaW5nIHVwcGVyY2FzZQ0KICAgICAgbGV0dGVy cyBmb3IgZGlnaXRzIEEtRi4NCg0KICAgbyAgdmFsdWUgb2YgYXR0cmlidXRl ICJsaWJyYXJ5LXZlcnNpb24iIE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGENCiAg ICAgIHNwZWNpZmljIHNjaGVtZS1iYXNlZCBub3JtYWxpemF0aW9uIHBlcm1p dHRlZCBieSBTZWN0aW9uIDYuMi4zIG9mDQogICAgICBbUkZDMzk4Nl0uICBU aGUgdmFsdWUgTVVTVCBiZSBzcGxpdCBpbnRvIGEgbWFqb3IgYW5kIG1pbm9y IHZlcnNpb24NCiAgICAgIHdpdGggY2hhcmFjdGVyICcuJyAoZG90KSBzZXJ2 aW5nIGFzIGEgZGVsaW1pdGVyLiAgTGlicmFyeSB2ZXJzaW9uDQogICAgICAi TSIgTVVTVCBiZSB0cmVhdGVkIGFzICJNIiBmb3IgdGhlIG1ham9yIHZlcnNp b24gYW5kICIwIiBmb3IgdGhlDQogICAgICBtaW5vciB2ZXJzaW9uLiAgUmVz dWx0aW5nIG1pbm9yIGFuZCBtYWpvciB2ZXJzaW9uIG51bWJlcnMgTVVTVCBi ZQ0KICAgICAgdGhlbiBzZXBhcmF0ZWx5IGNvbXBhcmVkIG51bWVyaWNhbGx5 Lg0KDQoNCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBp cmVzIEp1bHkgOCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNj aGVtZSAgICAgICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBvICB2YWx1 ZSBvZiBhdHRyaWJ1dGUgInNsb3QtaWQiIE1VU1QgYmUgcHJvY2Vzc2VkIGFz IGEgc3BlY2lmaWMNCiAgICAgIHNjaGVtZS1iYXNlZCBub3JtYWxpemF0aW9u IHBlcm1pdHRlZCBieSBTZWN0aW9uIDYuMi4zIG9mIFtSRkMzOTg2XQ0KICAg ICAgYW5kIGNvbXBhcmVkIG51bWVyaWNhbGx5Lg0KDQogICBvICB2YWx1ZSBv ZiAicGluLXNvdXJjZSIsIGlmIGRlZW1lZCBjb250YWluaW5nIHRoZSBmaWxl bmFtZSB3aXRoIHRoZQ0KICAgICAgUElOIHZhbHVlLCBNVVNUIGJlIGNvbXBh cmVkIHVzaW5nIHRoZSBzaW1wbGUgc3RyaW5nIGNvbXBhcmlzb24NCiAgICAg IGFmdGVyIHRoZSBmdWxsIHN5bnRheCBiYXNlZCBub3JtYWxpemF0aW9uIGFz IHNwZWNpZmllZCBpbg0KICAgICAgU2VjdGlvbiA2LjIuMiBvZiBbUkZDMzk4 Nl0gaXMgYXBwbGllZC4gIElmIHZhbHVlIG9mIHRoZSAicGluLQ0KICAgICAg c291cmNlIiBhdHRyaWJ1dGUgaXMgYmVsaWV2ZWQgdG8gYmUgb3ZlcmxvYWRl ZCB0aGUgY2FzZSBhbmQNCiAgICAgIHBlcmNlbnQtZW5jb2Rpbmcgbm9ybWFs aXphdGlvbiBTSE9VTEQgYmUgYXBwbGllZCBiZWZvcmUgdGhlIHZhbHVlcw0K ICAgICAgYXJlIGNvbXBhcmVkIGJ1dCB0aGUgZXhhY3QgbWVjaGFuaXNtIG9m IGNvbXBhcmlzb24gaXMgbGVmdCB0byB0aGUNCiAgICAgIGFwcGxpY2F0aW9u Lg0KDQogICBvICB2YWx1ZSBvZiBhdHRyaWJ1dGUgIm1vZHVsZS1wYXRoIiBN VVNUIGJlIGNvbXBhcmVkIHVzaW5nIHRoZSBzaW1wbGUNCiAgICAgIHN0cmlu ZyBjb21wYXJpc29uIGFmdGVyIHRoZSBmdWxsIHN5bnRheCBiYXNlZCBub3Jt YWxpemF0aW9uIGFzDQogICAgICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2LjIu MiBvZiBbUkZDMzk4Nl0gaXMgYXBwbGllZC4NCg0KICAgbyAgd2hlbiBjb21w YXJpbmcgdmVuZG9yIHNwZWNpZmljIGF0dHJpYnV0ZXMgdGhlIGNhc2UgYW5k IHBlcmNlbnQtDQogICAgICBlbmNvZGluZyBub3JtYWxpemF0aW9uIGFzIHNw ZWNpZmllZCBpbiBTZWN0aW9uIDYuMi4yIG9mIFtSRkMzOTg2XQ0KICAgICAg U0hPVUxEIGJlIGFwcGxpZWQgYmVmb3JlIHRoZSB2YWx1ZXMgYXJlIGNvbXBh cmVkIGJ1dCB0aGUgZXhhY3QNCiAgICAgIG1lY2hhbmlzbSBvZiBzdWNoIGEg Y29tcGFyaXNvbiBpcyBsZWZ0IHRvIHRoZSBhcHBsaWNhdGlvbi4NCg0KMy43 LiAgR2VuZXJhdGluZyBQS0NTIzExIFVSSXMNCg0KICAgV2hlbiBnZW5lcmF0 aW5nIFVSSXMgZm9yIFBLQ1MjMTEgcmVzb3VyY2VzIHRoZSBleGFjdCBzZXQg b2YNCiAgIGF0dHJpYnV0ZXMgdXNlZCBpbiBhIFVSSSBpcyBpbmhlcmVudGx5 IGNvbnRleHQgc3BlY2lmaWMuICBBIFBLQ1MjMTENCiAgIFVSSSB0ZW1wbGF0 ZSBbUkZDNjU3MF0gc3VwcG9ydCBNQVkgYmUgcHJvdmlkZWQgYnkgYSBVUkkg Z2VuZXJhdGluZw0KICAgYXBwbGljYXRpb24gdG8gbGlzdCBVUklzIHRvIGFj Y2VzcyB0aGUgc2FtZSByZXNvdXJjZShzKSBhZ2FpbiBpZiB0aGUNCiAgIHRl bXBsYXRlIGNhcHR1cmVkIHRoZSBuZWNlc3NhcnkgY29udGV4dC4NCg0KNC4g IEV4YW1wbGVzIG9mIFBLQ1MjMTEgVVJJcw0KDQogICBUaGlzIHNlY3Rpb24g Y29udGFpbnMgc29tZSBleGFtcGxlcyBvZiBob3cgUEtDUyMxMSB0b2tlbiBv YmplY3RzLA0KICAgdG9rZW5zLCBzbG90cywgYW5kIGxpYnJhcmllcyBjYW4g YmUgaWRlbnRpZmllZCB1c2luZyB0aGUgUEtDUyMxMSBVUkkNCiAgIHNjaGVt ZS4gIE5vdGUgdGhhdCBpbiBzb21lIG9mIHRoZSBmb2xsb3dpbmcgZXhhbXBs ZXMsIG5ld2xpbmVzIGFuZA0KICAgc3BhY2VzIHdlcmUgaW5zZXJ0ZWQgZm9y IGJldHRlciByZWFkYWJpbGl0eS4gIEFzIHNwZWNpZmllZCBpbg0KICAgQXBw ZW5kaXggQyBvZiBbUkZDMzk4Nl0sIHdoaXRlc3BhY2UgU0hPVUxEIGJlIGln bm9yZWQgd2hlbiBleHRyYWN0aW5nDQogICB0aGUgVVJJLiAgQWxzbyBub3Rl IHRoYXQgYWxsIHNwYWNlcyBhcyBwYXJ0IG9mIHRoZSBVUkkgYXJlIHBlcmNl bnQtDQogICBlbmNvZGVkLCBhcyBzcGVjaWZpZWQgaW4gQXBwZW5kaXggQSBv ZiBbUkZDMzk4Nl0uDQoNCiAgIEFuIGVtcHR5IFBLQ1MjMTEgVVJJIG1pZ2h0 IGJlIHVzZWZ1bCB0byBQS0NTIzExIGNvbnN1bWVycy4gIFNlZQ0KICAgU2Vj dGlvbiAzLjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gc2VtYW50aWNzIG9m IHN1Y2ggYSBVUkkuDQoNCiAgICAgcGtjczExOg0KDQoNCg0KDQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1 ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAg IEphbnVhcnkgMjAxNQ0KDQoNCiAgIE9uZSBvZiB0aGUgc2ltcGxlc3QgYW5k IG1vc3QgdXNlZnVsIGZvcm1zIG1pZ2h0IGJlIGEgUEtDUyMxMSBVUkkgdGhh dA0KICAgc3BlY2lmaWVzIG9ubHkgYW4gb2JqZWN0IGxhYmVsIGFuZCBpdHMg dHlwZS4gIFRoZSBkZWZhdWx0IHRva2VuIGlzDQogICB1c2VkIHNvIHRoZSBV UkkgZG9lcyBub3Qgc3BlY2lmeSBpdC4gIE5vdGUgdGhhdCB3aGVuIHNwZWNp ZnlpbmcNCiAgIHB1YmxpYyBvYmplY3RzLCBhIHRva2VuIFBJTiBtYXkgbm90 IGJlIHJlcXVpcmVkLg0KDQogICAgIHBrY3MxMTpvYmplY3Q9bXktcHVia2V5 O3R5cGU9cHVibGljDQoNCiAgIFdoZW4gYSBwcml2YXRlIGtleSBpcyBzcGVj aWZpZWQgZWl0aGVyIHRoZSAicGluLXNvdXJjZSIgYXR0cmlidXRlLA0KICAg InBpbi12YWx1ZSwgb3IgYW4gYXBwbGljYXRpb24gc3BlY2lmaWMgbWV0aG9k IHdvdWxkIGJlIHVzdWFsbHkgdXNlZC4NCiAgIE5vdGUgdGhhdCAnLycgaXMg bm90IHBlcmNlbnQtZW5jb2RlZCBpbiB0aGUgInBpbi1zb3VyY2UiIGF0dHJp YnV0ZQ0KICAgdmFsdWUgc2luY2UgdGhpcyBhdHRyaWJ1dGUgaXMgcGFydCBv ZiB0aGUgcXVlcnkgY29tcG9uZW50LCBub3QgdGhlDQogICBwYXRoLCBhbmQg dGh1cyBpcyBzZXBhcmF0ZWQgYnkgJz8nIGZyb20gdGhlIHJlc3Qgb2YgdGhl IFVSSS4NCg0KICAgICBwa2NzMTE6b2JqZWN0PW15LWtleTt0eXBlPXByaXZh dGU/cGluLXNvdXJjZT0vZXRjL3Rva2VuDQoNCiAgIFRoZSBmb2xsb3dpbmcg ZXhhbXBsZSBpZGVudGlmaWVzIGEgY2VydGlmaWNhdGUgaW4gdGhlIHNvZnR3 YXJlIHRva2VuLg0KICAgTm90ZSBhbiBlbXB0eSB2YWx1ZSBmb3IgdGhlIGF0 dHJpYnV0ZSAic2VyaWFsIiB3aGljaCBtYXRjaGVzIG9ubHkNCiAgIGVtcHR5 ICJzZXJpYWxOdW1iZXIiIG1lbWJlciBvZiB0aGUgIkNLX1RPS0VOX0lORk8i IHN0cnVjdHVyZS4gIEFsc28NCiAgIG5vdGUgdGhhdCB0aGUgImlkIiBhdHRy aWJ1dGUgdmFsdWUgaXMgZW50aXJlbHkgcGVyY2VudC1lbmNvZGVkLCBhcw0K ICAgcmVjb21tZW5kZWQuICBXaGlsZSAnLCcgaXMgaW4gdGhlIHJlc2VydmVk IHNldCBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlDQogICBwZXJjZW50LWVuY29k ZWQgc2luY2UgaXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCBhbnkgc3ViLWRl bGltaXRlcnMNCiAgIHVzZWQuICBUaGUgJyMnIGNoYXJhY3RlciBhcyBpbiAi VGhlIFNvZnR3YXJlIFBLQ1MjMTEgU29mdHRva2VuIiBNVVNUDQogICBiZSBw ZXJjZW50LWVuY29kZWQuDQoNCiAgICAgcGtjczExOnRva2VuPVRoZSUyMFNv ZnR3YXJlJTIwUEtDUyUyMzExJTIwU29mdHRva2VuOw0KICAgICAgICAgICAg bWFudWZhY3R1cmVyPVNuYWtlJTIwT2lsLCUyMEluYy47DQogICAgICAgICAg ICBtb2RlbD0xLjA7DQogICAgICAgICAgICBvYmplY3Q9bXktY2VydGlmaWNh dGU7DQogICAgICAgICAgICB0eXBlPWNlcnQ7DQogICAgICAgICAgICBpZD0l NjklOTUlM0UlNUMlRjQlQkQlRUMlOTE7DQogICAgICAgICAgICBzZXJpYWw9 DQogICAgICAgICAgICA/cGluLXNvdXJjZT0vZXRjL3Rva2VuX3Bpbg0KDQog ICBUaGUgbmV4dCBleGFtcGxlIGNvdmVycyBob3cgdG8gdXNlIHRoZSAibW9k dWxlLW5hbWUiIHF1ZXJ5IGF0dHJpYnV0ZS4NCiAgIENvbnNpZGVyaW5nIHRo YXQgdGhlIG1vZHVsZSBpcyBsb2NhdGVkIGluIC91c3IvbGliL2xpYm15cGtj czExLnNvLjENCiAgIGZpbGUsIHRoZSBhdHRyaWJ1dGUgdmFsdWUgaXMgIm15 cGtjczExIiwgbWVhbmluZyBvbmx5IHRoZSBtb2R1bGUgbmFtZQ0KICAgd2l0 aG91dCB0aGUgZnVsbCBwYXRoLCBhbmQgd2l0aG91dCB0aGUgcGxhdGZvcm0g c3BlY2lmaWMgImxpYiIgcHJlZml4DQogICBhbmQgIi5zby4xIiBzdWZmaXgu DQoNCiAgICAgcGtjczExOm9iamVjdD1teS1zaWduLWtleTsNCiAgICAgICAg ICAgIHR5cGU9cHJpdmF0ZQ0KICAgICAgICAgICAgP21vZHVsZS1uYW1lPW15 cGtjczExDQoNCg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAg ICAgICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICBb UGFnZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtD UyMxMSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoN CiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBjb3ZlcnMgaG93IHRvIHVzZSB0 aGUgIm1vZHVsZS1wYXRoIiBxdWVyeQ0KICAgYXR0cmlidXRlLiAgVGhlIGF0 dHJpYnV0ZSBtYXkgYmUgdXNlZnVsIGlmIGEgdXNlciBuZWVkcyB0byBwcm92 aWRlDQogICB0aGUga2V5IHZpYSBhIFBLQ1MjMTEgbW9kdWxlIHN0b3JlZCBv biBhIHJlbW92YWJsZSBtZWRpYSwgZm9yDQogICBleGFtcGxlLiAgR2V0dGlu ZyB0aGUgUElOIHRvIGFjY2VzcyB0aGUgcHJpdmF0ZSBrZXkgaGVyZSBpcyBs ZWZ0IHRvDQogICBiZSBhcHBsaWNhdGlvbiBzcGVjaWZpYy4NCg0KICAgICBw a2NzMTE6b2JqZWN0PW15LXNpZ24ta2V5Ow0KICAgICAgICAgICAgdHlwZT1w cml2YXRlDQogICAgICAgICAgICA/bW9kdWxlLXBhdGg9L21udC9saWJteXBr Y3MxMS5zby4xDQoNCiAgIEluIHRoZSBjb250ZXh0IHdoZXJlIGEgdG9rZW4g aXMgZXhwZWN0ZWQgdGhlIHRva2VuIGNhbiBiZSBpZGVudGlmaWVkDQogICB3 aXRob3V0IHNwZWNpZnlpbmcgYW55IFBLQ1MjMTEgb2JqZWN0cy4gIEEgUElO IG1pZ2h0IHN0aWxsIGJlIG5lZWRlZA0KICAgaW4gdGhlIGNvbnRleHQgb2Yg bGlzdGluZyBhbGwgb2JqZWN0cyBpbiB0aGUgdG9rZW4sIGZvciBleGFtcGxl Lg0KICAgU2VjdGlvbiA3IHNob3VsZCBiZSBjb25zdWx0ZWQgYmVmb3JlIHRo ZSAicGluLXZhbHVlIiBhdHRyaWJ1dGUgaXMNCiAgIGV2ZXIgdXNlZC4NCg0K ICAgICBwa2NzMTE6dG9rZW49U29mdHdhcmUlMjBQS0NTJTIzMTElMjBzb2Z0 dG9rZW47DQogICAgICAgICAgICBtYW51ZmFjdHVyZXI9U25ha2UlMjBPaWws JTIwSW5jLg0KICAgICAgICAgICAgP3Bpbi12YWx1ZT10aGUtcGluDQoNCiAg IEluIHRoZSBjb250ZXh0IHdoZXJlIGEgc2xvdCBpcyBleHBlY3RlZCB0aGUg c2xvdCBjYW4gYmUgaWRlbnRpZmllZA0KICAgd2l0aG91dCBzcGVjaWZ5aW5n IGFueSBQS0NTIzExIG9iamVjdHMgaW4gYW55IHRva2VuIGl0IG1heSBiZQ0K ICAgaW5zZXJ0ZWQgaW4gaXQuDQoNCiAgICAgcGtjczExOnNsb3QtZGVzY3Jp cHRpb249U3VuJTIwTWV0YXNsb3QNCg0KICAgVGhlIENyeXB0b2tpIGxpYnJh cnkgYWxvbmUgY2FuIGJlIGFsc28gaWRlbnRpZmllZCB3aXRob3V0IHNwZWNp ZnlpbmcNCiAgIGEgUEtDUyMxMSB0b2tlbiBvciBvYmplY3QuDQoNCiAgICAg cGtjczExOmxpYnJhcnktbWFudWZhY3R1cmVyPVNuYWtlJTIwT2lsLCUyMElu Yy47DQogICAgICAgICAgICBsaWJyYXJ5LWRlc2NyaXB0aW9uPVNvZnQlMjBU b2tlbiUyMExpYnJhcnk7DQogICAgICAgICAgICBsaWJyYXJ5LXZlcnNpb249 MS4yMw0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgYW4gYXR0 cmlidXRlIHZhbHVlIHdpdGggYSBzZW1pY29sb24uICBJbg0KICAgc3VjaCBj YXNlIGl0IE1VU1QgYmUgcGVyY2VudC1lbmNvZGVkLiAgVGhlIHRva2VuIGF0 dHJpYnV0ZSB2YWx1ZSBNVVNUDQogICBiZSByZWFkIGFzICJNeSB0b2tlbjsg Y3JlYXRlZCBieSBKb2UiLiAgTG93ZXIgY2FzZSBsZXR0ZXJzIE1BWSBiZQ0K ICAgdXNlZCBpbiBwZXJjZW50LWVuY29kaW5nIGFzIHNob3duIGJlbG93IGlu IHRoZSAiaWQiIGF0dHJpYnV0ZSB2YWx1ZQ0KICAgYnV0IG5vdGUgdGhhdCBT ZWN0aW9ucyAyLjEgYW5kIDYuMi4yLjEgb2YgW1JGQzM5ODZdIHJlYWQgdGhh dCBhbGwNCiAgIHBlcmNlbnQtZW5jb2RlZCBjaGFyYWN0ZXJzIFNIT1VMRCB1 c2UgdGhlIHVwcGVyY2FzZSBoZXhhZGVjaW1hbA0KICAgZGlnaXRzLiAgTW9y ZSBzcGVjaWZpY2FsbHksIGlmIHRoZSBVUkkgc3RyaW5nIHdhcyB0byBiZSBj b21wYXJlZCB0aGUNCiAgIGFsZ29yaXRobSBkZWZpbmVkIGluIFNlY3Rpb24g My42IGV4cGxpY2l0bHkgcmVxdWlyZXMgcGVyY2VudC1lbmNvZGluZw0KICAg dG8gdXNlIHRoZSB1cHBlcmNhc2UgZGlnaXRzIEEtRiBpbiB0aGUgImlkIiBh dHRyaWJ1dGUgdmFsdWVzLiAgQW5kIGFzDQogICBleHBsYWluZWQgaW4gU2Vj dGlvbiAzLjMsIGxpYnJhcnkgdmVyc2lvbiAiMyIgTVVTVCBiZSBpbnRlcnBy ZXRlZCBhcw0KICAgIjMiIGZvciB0aGUgbWFqb3IgYW5kICIwIiBmb3IgdGhl IG1pbm9yIHZlcnNpb24gb2YgdGhlIGxpYnJhcnkuDQoNCiAgICAgcGtjczEx OnRva2VuPU15JTIwdG9rZW4lMjUlMjBjcmVhdGVkJTIwYnklMjBKb2U7DQog ICAgICAgICAgICBsaWJyYXJ5LXZlcnNpb249MzsNCiAgICAgICAgICAgIGlk PSUwMSUwMiUwMyVCYSVkZCVDYSVmZSUwNCUwNSUwNg0KDQoNCg0KUGVjaGFu ZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAxNSAgICAg ICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgICBKYW51 YXJ5IDIwMTUNCg0KDQogICBJZiB0aGVyZSBpcyBhbnkgbmVlZCB0byBpbmNs dWRlIGxpdGVyYWwgIiU7IiBzdWJzdHJpbmcsIGZvciBleGFtcGxlLA0KICAg Ym90aCBjaGFyYWN0ZXJzIE1VU1QgYmUgZXNjYXBlZC4gIFRoZSB0b2tlbiB2 YWx1ZSBNVVNUIGJlIHJlYWQgYXMgIkENCiAgIG5hbWUgd2l0aCBhIHN1YnN0 cmluZyAlOyIuDQoNCiAgICAgcGtjczExOnRva2VuPUElMjBuYW1lJTIwd2l0 aCUyMGElMjBzdWJzdHJpbmclMjAlMjUlM0I7DQogICAgICAgICAgICBvYmpl Y3Q9bXktY2VydGlmaWNhdGU7DQogICAgICAgICAgICB0eXBlPWNlcnQNCg0K ICAgVGhlIG5leHQgZXhhbXBsZSBpbmNsdWRlcyBhIHNtYWxsIEEgd2l0aCBh Y3V0ZSBpbiB0aGUgdG9rZW4gbmFtZS4gIEl0DQogICBNVVNUIGJlIGVuY29k ZWQgaW4gb2N0ZXRzIGFjY29yZGluZyB0byB0aGUgVVRGLTggY2hhcmFjdGVy IGVuY29kaW5nDQogICBhbmQgdGhlbiBwZXJjZW50LWVuY29kZWQuICBHaXZl biB0aGF0IGEgc21hbGwgQSB3aXRoIGFjdXRlIGlzIFUrMjI1DQogICB1bmlj b2RlIGNvZGUgcG9pbnQsIHRoZSBVVEYtOCBlbmNvZGluZyBpcyAxOTUgMTYx IGluIGRlY2ltYWwsIGFuZA0KICAgdGhhdCBpcyAiJUMzJUExIiBpbiBwZXJj ZW50LWVuY29kaW5nLg0KDQogICAgIHBrY3MxMTp0b2tlbj1OYW1lJTIwd2l0 aCUyMGElMjBzbWFsbCUyMEElMjB3aXRoJTIwYWN1dGU6JTIwJUMzJUExOw0K ICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0KICAgICAgICAg ICAgdHlwZT1jZXJ0DQoNCiAgIEJvdGggdGhlIHBhdGggYW5kIHF1ZXJ5IGNv bXBvbmVudHMgTUFZIGNvbnRhaW4gdmVuZG9yIHNwZWNpZmljDQogICBhdHRy aWJ1dGVzLiAgQXR0cmlidXRlcyBpbiB0aGUgcXVlcnkgY29tcG9uZW50IE1V U1QgYmUgZGVsaW1pdGVkIGJ5DQogICAnJicuDQoNCiAgICAgcGtjczExOnRv a2VuPW15LXRva2VuOw0KICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmlj YXRlOw0KICAgICAgICAgICAgdHlwZT1jZXJ0Ow0KICAgICAgICAgICAgdmVu ZG9yLWFhYT12YWx1ZS1hDQogICAgICAgICAgICA/cGluLXNvdXJjZT0vZXRj L3Rva2VuX3Bpbg0KICAgICAgICAgICAgJnZlbmRvci1iYmI9dmFsdWUtYg0K DQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50 IG1vdmVzIHRoZSAicGtjczExIiBVUkkgc2NoZW1lIGZyb20gdGhlIHByb3Zp c2lvbmFsIHRvDQogICBwZXJtYW5lbnQgVVJJIHNjaGVtZSByZWdpc3RyeS4N Cg0KICAgVGhlIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSBpcyBhcyBmb2xsb3dz Og0KDQogICAgICBVUkkgc2NoZW1lIG5hbWU6IHBrY3MxMQ0KDQogICAgICBV Ukkgc2NoZW1lIHN0YXR1czogcGVybWFuZW50DQoNCiAgICAgIFVSSSBzY2hl bWUgc3ludGF4OiBzZWUgU2VjdGlvbiAzLjMNCg0KICAgICAgVVJJIHNjaGVt ZSBzZW1hbnRpY3M6IHNlZSBTZWN0aW9uIDENCg0KICAgICAgRW5jb2Rpbmcg Y29uc2lkZXJhdGlvbnM6IHNlZSBTZWN0aW9uIDMuMw0KDQogICAgICBBcHBs aWNhdGlvbnMvcHJvdG9jb2xzIHRoYXQgdXNlIHRoaXMgVVJJIHNjaGVtZSBu YW1lOiBmb3IgZ2VuZXJhbA0KICAgICAgaW5mb3JtYXRpb24sIHNlZSBTZWN0 aW9uIDEuICBMaXN0IG9mIGtub3duIGNvbnN1bWVycyBvZiB0aGUNCg0KDQoN ClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICAgRXhwaXJlcyBKdWx5IDgsIDIw MTUgICAgICAgICAgICAgICAgIFtQYWdlIDE2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAg ICAgSmFudWFyeSAyMDE1DQoNCg0KICAgICAgUEtDUyMxMSBVUkkgaW5jbHVk ZSBHbnVUTFMsIEdub21lLCBwMTEta2l0LCBTb2xhcmlzIDExIGFuZCBoaWdo ZXIsDQogICAgICBPcGVuU0MsIE9wZW5Db25uZWN0LCBhbmQgRnJlZUlQQS4N Cg0KICAgICAgSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczogTi9B DQoNCiAgICAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiBzZWUgU2VjdGlv biA3DQoNCiAgICAgIENvbnRhY3Q6IHNlZSBBdXRob3JzJyBBZGRyZXNzZXMg c2VjdGlvbg0KDQogICAgICBBdXRob3IvQ2hhbmdlIENvbnRyb2xsZXI6IHNl ZSBBdXRob3JzJyBBZGRyZXNzZXMgc2VjdGlvbg0KDQogICAgICBSZWZlcmVu Y2VzOiBzZWUgUmVmZXJlbmNlcyBzZWN0aW9uDQoNCjYuICBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgUEtDUyMxMSBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IHNwZWNpZnkgYSBjYW5vbmljYWwgZm9y bSBmb3INCiAgIHN0cmluZ3Mgb2YgY2hhcmFjdGVycyBvZiB0aGUgQ0tfVVRG OENIQVIgdHlwZS4gIFRoaXMgcHJlc2VudHMgdGhlDQogICB1c3VhbCBmYWxz ZSBuZWdhdGl2ZSBhbmQgZmFsc2UgcG9zaXRpdmUgKGFsaWFzaW5nKSBjb25j ZXJucyB0aGF0DQogICBhcmlzZSB3aGVuIGRlYWxpbmcgd2l0aCB1bm5vcm1h bGl6ZWQgc3RyaW5ncy4gIEJlY2F1c2UgYWxsIFBLQ1MjMTENCiAgIGl0ZW1z IGFyZSBsb2NhbCBhbmQgbG9jYWwgc2VjdXJpdHkgaXMgYXNzdW1lZCwgdGhl c2UgY29uY2VybnMgYXJlDQogICBtYWlubHkgYWJvdXQgdXNhYmlsaXR5Lg0K DQogICBJbiBvcmRlciB0byBpbXByb3ZlIHRoZSB1c2VyIGV4cGVyaWVuY2Us IGFwcGxpY2F0aW9ucyB0aGF0IGNyZWF0ZQ0KICAgUEtDUyMxMSBvYmplY3Rz IG9yIGxhYmVsIHRva2VucyBTSE9VTEQgbm9ybWFsaXplIGxhYmVscyB0bw0K ICAgTm9ybWFsaXphdGlvbiBGb3JtIEMgKE5GQykgW1VBWDE1XS4gIEZvciB0 aGUgc2FtZSByZWFzb24gUEtDUyMxMQ0KICAgbGlicmFyaWVzLCBzbG90cyAo dG9rZW4gcmVhZGVycyksIGFuZCB0b2tlbnMgU0hPVUxEIG5vcm1hbGl6ZSB0 aGVpcg0KICAgbmFtZXMgdG8gTkZDLiAgV2hlbiBsaXN0aW5nIFBLQ1MjMTEg bGlicmFyaWVzLCBzbG90cywgdG9rZW5zLCBhbmQvb3INCiAgIG9iamVjdHMs IGFuIGFwcGxpY2F0aW9uIFNIT1VMRCBub3JtYWxpemUgdGhlaXIgbmFtZXMg dG8gTkZDLiAgV2hlbg0KICAgbWF0Y2hpbmcgUEtDUyMxMSBVUklzIHRvIGxp YnJhcmllcywgc2xvdHMsIHRva2VucywgYW5kL29yIG9iamVjdHMsDQogICBh cHBsaWNhdGlvbnMgTUFZIHVzZSBmb3JtLWluc2Vuc2l0aXZlIFVuaWNvZGUg c3RyaW5nIGNvbXBhcmlzb24gZm9yDQogICBtYXRjaGluZywgYXMgdGhvc2Ug bWlnaHQgcHJlLWRhdGUgdGhlc2UgcmVjb21tZW5kYXRpb25zLiAgU2VlIGFs c28NCiAgIFNlY3Rpb24gMy41Lg0KDQo3LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhlcmUgYXJlIGdlbmVyYWwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIFVSSSBzY2hlbWVzIGRpc2N1c3NlZA0KICAgaW4gU2Vj dGlvbiA3IG9mIFtSRkMzOTg2XS4NCg0KICAgRnJvbSB0aG9zZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucywgU2VjdGlvbiA3LjEgb2YgW1JGQzM5ODZdIGFw cGxpZXMNCiAgIHNpbmNlIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRo ZSBzYW1lIFBLQ1MjMTEgVVJJIHdpbGwgYWx3YXlzDQogICBpZGVudGlmeSB0 aGUgc2FtZSBvYmplY3QsIHRva2VuLCBzbG90LCBvciBhIGxpYnJhcnkgaW4g dGhlIGZ1dHVyZS4NCg0KICAgU2VjdGlvbiA3LjIgb2YgW1JGQzM5ODZdIGFw cGxpZXMgc2luY2UgYnkgYWNjZXB0aW5nIHF1ZXJ5IGNvbXBvbmVudA0KICAg YXR0cmlidXRlcyAibW9kdWxlLW5hbWUiIG9yICJtb2R1bGUtcGF0aCIgdGhl IGNvbnN1bWVyIHBvdGVudGlhbGx5DQogICBhbGxvd3MgbG9hZGluZyBvZiBh cmJpdHJhcnkgY29kZSBpbnRvIGEgcHJvY2Vzcy4NCg0KICAgU2VjdGlvbiA3 LjUgb2YgW1JGQzM5ODZdIGFwcGxpZXMgc2luY2UgdGhlIFBLQ1MjMTEgVVJJ IG1heSBiZSB1c2VkIGluDQogICB3b3JsZCByZWFkYWJsZSBjb21tYW5kIGxp bmUgYXJndW1lbnRzIHRvIHJ1biBhcHBsaWNhdGlvbnMsIHN0b3JlZCBpbg0K DQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkg OCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAg ICAgICAgICBKYW51YXJ5IDIwMTUNCg0KDQogICBwdWJsaWMgY29uZmlndXJh dGlvbiBmaWxlcywgb3Igb3RoZXJ3aXNlIHVzZWQgaW4gY2xlYXIgdGV4dC4g IEZvcg0KICAgdGhhdCByZWFzb24gdGhlICJwaW4tdmFsdWUiIGF0dHJpYnV0 ZSBzaG91bGQgb25seSBiZSB1c2VkIGlmIHRoZSBVUkkNCiAgIHN0cmluZyBp dHNlbGYgaXMgcHJvdGVjdGVkIHdpdGggdGhlIHNhbWUgbGV2ZWwgb2Ygc2Vj dXJpdHkgYXMgdGhlDQogICB0b2tlbiBQSU4gaXRzZWxmIG90aGVyd2lzZSBp cy4NCg0KICAgVGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBw cm92aWRlIG1lYW5zIHRvIGF1dGhlbnRpY2F0ZQ0KICAgZGV2aWNlcyB0byB1 c2VyczsgaXQgb25seSBhbGxvd3MgdG8gYXV0aGVudGljYXRlIHVzZXJzIHRv IHRva2Vucy4NCiAgIEluc3RlYWQsIGxvY2FsIGFuZCBwaHlzaWNhbCBzZWN1 cml0eSBhcmUgZGVtYW5kZWQ6IHRoZSB1c2VyIG11c3QgYmUNCiAgIGluIHBv c3Nlc3Npb24gb2YgdGhlaXIgdG9rZW5zLCBhbmQgc3lzdGVtIGludG8gd2hv c2Ugc2xvdHMgdGhlIHVzZXJzJw0KICAgdG9rZW5zIGFyZSBpbnNlcnRlZCBt dXN0IGJlIHNlY3VyZS4gIEFzIGEgcmVzdWx0LCB0aGUgdXN1YWwgc2VjdXJp dHkNCiAgIGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyBub3JtYWxpemF0aW9u IGRvIG5vdCBhcmlzZS4gIEZvciB0aGUgc2FtZQ0KICAgcmVhc29uLCBjb25m dXNhYmxlIHNjcmlwdCBpc3N1ZXMgYWxzbyBkbyBub3QgYXJpc2UuICBOb25l dGhlbGVzcywgaXQNCiAgIGlzIGJlc3QgdG8gbm9ybWFsaXplIHRvIE5GQyBh bGwgc3RyaW5ncyBhcHBlYXJpbmcgaW4gUEtDUyMxMSBBUEkNCiAgIGVsZW1l bnRzLiAgU2VlIGFsc28gU2VjdGlvbiA2Lg0KDQo4LiAgUmVmZXJlbmNlcw0K DQo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0g IEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJ bmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBS RkMgMjExOSwgU1REIDE0LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMzYyOV0g IFllcmdlYXUsIEYuLCAiVVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0 IG9mIElTTw0KICAgICAgICAgICAgICAxMDY0NiIsIFJGQyAzNjI5LCBTVEQg NjMsIE5vdmVtYmVyIDIwMDMuDQoNCiAgIFtSRkMzOTg2XSAgQmVybmVycy1M ZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZv cm0NCiAgICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTog R2VuZXJpYyBTeW50YXgiLCBSRkMgMzk4NiwgU1REDQogICAgICAgICAgICAg IDY2LCBKYW51YXJ5IDIwMDUuDQoNCiAgIFtSRkM1MjM0XSAgQ3JvY2tlciwg RC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgN CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMgNTIz NCwgU1REIDY4LCBKYW51YXJ5IDIwMDguDQoNCjguMi4gIEluZm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KICAgW0JDUDE3OF0gICBTYWludC1BbmRyZSwgUC4s IENyb2NrZXIsIEQuLCBhbmQgTS4gTm90dGluZ2hhbSwNCiAgICAgICAgICAg ICAgIkRlcHJlY2F0aW5nIHRoZSAiWC0iIFByZWZpeCBhbmQgU2ltaWxhciBD b25zdHJ1Y3RzIGluDQogICAgICAgICAgICAgIEFwcGxpY2F0aW9uIFByb3Rv Y29scyIsIFJGQyA2NjQ4LCBCQ1AgMTc4LCBKdW5lIDIwMTIuDQoNCiAgIFtQ S0NTMTFdICAgUlNBIExhYm9yYXRvcmllcywgIlBLQ1MgIzExOiBDcnlwdG9n cmFwaGljIFRva2VuIEludGVyZmFjZQ0KICAgICAgICAgICAgICBTdGFuZGFy ZCB2Mi4yMCIsIEp1bmUgMjAwNC4NCg0KICAgW1JGQzM5ODddICBEdWVyc3Qs IE0uIGFuZCBNLiBTdWlnbmFyZCwgIkludGVybmF0aW9uYWxpemVkIFJlc291 cmNlDQogICAgICAgICAgICAgIElkZW50aWZpZXJzIChJUklzKSIsIFJGQyAz OTg3LCBKYW51YXJ5IDIwMDUuDQoNCiAgIFtSRkM0Mzk1XSAgSGFuc2VuLCBU LiwgSGFyZGllLCBULiwgYW5kIEwuIE1hc2ludGVyLCAiR3VpZGVsaW5lcyBh bmQNCiAgICAgICAgICAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgZm9y IE5ldyBVUkkgU2NoZW1lcyIsIFJGQyA0Mzk1LA0KICAgICAgICAgICAgICBG ZWJydWFyeSAyMDA2Lg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAg ICAgIEV4cGlyZXMgSnVseSA4LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFn ZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMx MSBVUkkgU2NoZW1lICAgICAgICAgICAgIEphbnVhcnkgMjAxNQ0KDQoNCiAg IFtSRkM2NTcwXSAgR3JlZ29yaW8sIEouLCBGaWVsZGluZywgUi4sIEhhZGxl eSwgTS4sIE5vdHRpbmdoYW0sIE0uLA0KICAgICAgICAgICAgICBhbmQgRC4g T3JjaGFyZCwgIlVSSSBUZW1wbGF0ZSIsIFJGQyA2NTcwLCBNYXJjaCAyMDEy Lg0KDQogICBbVUFYMTVdICAgIERhdmlzLCBNLiwgRWQuLCBXaGlzdGxlciwg Sy4sIEVkLiwgYW5kIFVuaWNvZGUgQ29uc29ydGl1bSwNCiAgICAgICAgICAg ICAgIlVuaWNvZGUgU3RhbmRhcmQgQW5uZXggIzE1IC0gVW5pY29kZSBOb3Jt YWxpemF0aW9uIEZvcm1zLA0KICAgICAgICAgICAgICBWZXJzaW9uIFVuaWNv ZGUgNy4wLjAiLCBKdW5lIDIwMTQuDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0K DQogICBKYW4gUGVjaGFuZWMNCiAgIE9yYWNsZSBDb3Jwb3JhdGlvbg0KICAg NDE4MCBOZXR3b3JrIENpcmNsZQ0KICAgU2FudGEgQ2xhcmEgIENBIDk1MDU0 DQogICBVU0ENCg0KICAgRW1haWw6IEphbi5QZWNoYW5lY0BPcmFjbGUuQ09N DQogICBVUkk6ICAgaHR0cDovL3d3dy5vcmFjbGUuY29tDQoNCg0KICAgRGFy cmVuIEouIE1vZmZhdA0KICAgT3JhY2xlIENvcnBvcmF0aW9uDQogICBPcmFj bGUgUGFya3dheQ0KICAgVGhhbWVzIFZhbGxleSBQYXJrDQogICBSZWFkaW5n ICBSRzYgMVJBDQogICBVSw0KDQogICBFbWFpbDogRGFycmVuLk1vZmZhdEBP cmFjbGUuQ09NDQogICBVUkk6ICAgaHR0cDovL3d3dy5vcmFjbGUuY29tDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K UGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgICBFeHBpcmVzIEp1bHkgOCwgMjAx NSAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQo= ---559023410-475718409-1420658027=:8929-- From nobody Sun Jan 11 12:38:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C401A00E4; Thu, 8 Jan 2015 10:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpKqE8w1aJdg; Thu, 8 Jan 2015 10:01:44 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEBB1A8AE2; Thu, 8 Jan 2015 10:01:42 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y9HOg-000HkZ-Uq; Thu, 08 Jan 2015 13:01:26 -0500 Date: Thu, 08 Jan 2015 13:01:17 -0500 From: John C Klensin To: Jan Pechanec Message-ID: <7A38C32D6DB867E71E8F90B4@JcK-HP8200.jck.com> In-Reply-To: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Sun, 11 Jan 2015 12:38:23 -0800 Cc: Darren J Moffat , Stef Walter , ietf@ietf.org, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:01:46 -0000 --On Wednesday, January 07, 2015 11:16 -0800 Jan Pechanec wrote: > On Sat, 3 Jan 2015, Jan Pechanec wrote: > > hi, I haven't received any other comments on the draft > recently (I know the LC already ended on Dec 29 though) so I > think I can file changes discussed and drafted in this thread > as draft 18 on Friday. Thank you all for feedback, I really > appreciate it. > > one more change for the draft 18 (v2 attached) is to spell > "NFC" and reference the Unicode Annex on normalization based > on comments from Jaroslav and Christian. >... Jan, I don't have a lot of time to spend on this and am not an expert on either X.509 or PKCK (#11 or otherwise). At least the first may be unfortunate, but it is what it is. While I think the changes you have made are definitely improvements, this i18n stuff is complicated. As with Security, there is a completely inadequate supply of magic pixie dust that can be thrown at problems to make them go away. "Normalize to NFC" (with spelling-out and references) is a vast improvement or "use [valid] UTF-8" but there are many other issues. You have noted some and omitted others. For example, case-independent matching is a very simple and completely deterministic issue for ASCII (one essentially just masks off one bit within a certain range), it can get very messy if one tries to be sensitive to different locales that have different conventions about what to do with diacritical marks when lower-case characters are converted to upper case. There are Unicode "CaseFold" rules that are at least self-consistent but which contain wjat amount to exceptions for some language contexts (e.g., for dotless "i") but they are wildly unpopular in some places. We used to joke that, every time we tried to carefully examine a new script and set of languages for IDN-related purposes, it was like turning over rocks with vipers hiding under them. Each new script or language context turned up a different set of difficult issues -- the only surprise what what sort of creatures crawled out, not whether there would be creatures there. The joke has gone out of fashion, but the realities that inspired it survive. Part of this is an inherent problem with trying to create a universal character set -- languages and writing systems are diverse enough that any "one size fits all" model or set of decision rules is guaranteed to be deeply problematic and upsetting for some people (and legitimately so) while developing too many script-specific (or language-specific) rules or exceptions is almost certain to upset those who feel a need for simpler approaches that can be incorporated into generic software. For your reading pleasure, draft-klensin-idna-5892upd-unicode70 discusses one set of cases in which application of different rules and criteria led to a conclusion that may be just right for some communities but that is definitely problematic for others. I don't know how far in explaining this your document should go. I would urge, as I think I did before, some fairly strong warnings that, at least until the issues are clarified in PKCS#11 itself, one should be very certain one knows what one is doing (and what the consequences of one's choices will be) if one decides to move beyond the safety and general understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire. That sort of warning should supplement your NFC language, not replace it-- neither is a substitute for the other. Whether you incorporate it or not, your I-D should not assume that, by saying "NFC", you have somehow resolved the full range of issues in this area, any more than saying "UTF-8" did. For more information, you might have a look at some of the PRECIS work, notably draft-ietf-precis-framework. I also remain convinced that the best place to fix this is in the PKCS#11 spec itself. One is always at a disadvantage when trying to work around an inadequate specification in a different specification that has to depend on it and your work is no exception. I wish there were whatever liaison arrangements between the IETF and others (presumably notably RSA) to be sure that happened or at least there was clear awareness on the PKCS side of the deficiencies. Happy New Year, john From nobody Sun Jan 11 12:38:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF15C1A007D; Thu, 8 Jan 2015 10:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCG53B3OcTZk; Thu, 8 Jan 2015 10:45:50 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB591A006C; Thu, 8 Jan 2015 10:45:50 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t08IjhEK010828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2015 18:45:44 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t08Ijfoq005708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Jan 2015 18:45:42 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t08IjeR4005670; Thu, 8 Jan 2015 18:45:41 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Jan 2015 10:45:40 -0800 Date: Thu, 8 Jan 2015 10:45:38 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: John C Klensin In-Reply-To: <7A38C32D6DB867E71E8F90B4@JcK-HP8200.jck.com> Message-ID: References: <20141231070328.GK24442@localhost> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <20150102030130.GN24442@localhost> <7A38C32D6DB867E71E8F90B4@JcK-HP8200.jck.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: X-Mailman-Approved-At: Sun, 11 Jan 2015 12:38:24 -0800 Cc: Darren J Moffat , Stef Walter , ietf@ietf.org, =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , saag@ietf.org, Nikos Mavrogiannopoulos Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:45:52 -0000 On Thu, 8 Jan 2015, John C Klensin wrote: >> On Sat, 3 Jan 2015, Jan Pechanec wrote: >> >> hi, I haven't received any other comments on the draft >> recently (I know the LC already ended on Dec 29 though) so I >> think I can file changes discussed and drafted in this thread >> as draft 18 on Friday. Thank you all for feedback, I really >> appreciate it. >> >> one more change for the draft 18 (v2 attached) is to spell >> "NFC" and reference the Unicode Annex on normalization based >> on comments from Jaroslav and Christian. >>... > >Jan, > >I don't have a lot of time to spend on this and am not an expert >on either X.509 or PKCK (#11 or otherwise). At least the first >may be unfortunate, but it is what it is. hi John, I very much appreciate time you already spent on this. Please see my comments inline. >While I think the changes you have made are definitely >improvements, this i18n stuff is complicated. As with Security, >there is a completely inadequate supply of magic pixie dust that >can be thrown at problems to make them go away. "Normalize to >NFC" (with spelling-out and references) is a vast improvement or >"use [valid] UTF-8" but there are many other issues. You have >noted some and omitted others. For example, case-independent >matching is a very simple and completely deterministic issue for >ASCII (one essentially just masks off one bit within a certain >range), it can get very messy if one tries to be sensitive to >different locales that have different conventions about what to >do with diacritical marks when lower-case characters are >converted to upper case. There are Unicode "CaseFold" rules I understand from the previous discussion that the topic is a very complex one and that my draft needed to acknowledge that. <...> >I don't know how far in explaining this your document should go. >I would urge, as I think I did before, some fairly strong >warnings that, at least until the issues are clarified in >PKCS#11 itself, one should be very certain one knows what one is >doing (and what the consequences of one's choices will be) if >one decides to move beyond the safety and general understanding >of the ASCII/ ISO 646/ IA5 letter and digit repertoire. That >sort of warning should supplement your NFC language, not replace >it-- neither is a substitute for the other. Whether you >incorporate it or not, your I-D should not assume that, by >saying "NFC", you have somehow resolved the full range of issues >in this area, any more than saying "UTF-8" did. I understand that. The note about spelling NFC was on top of the first changes I incorporated. I don't know if you saw those, I know there were many emails and your time you could spend on this is very limited. So, in section on URI matching, I tried to be very explicit and based the warning I added on one of your comments from the previous discussion: + As noted in Section 6, the PKCS#11 specification is not clear about + how to normalize UTF-8 encoded Unicode characters [RFC3629]. Those + who discover a need to use characters outside the ASCII repertoire + should be cautious, conservative, and expend extra effort to be sure + they know what they are doing and that failure to do so may create + both operational and security risks. It means that when matching + UTF-8 string based attributes (see Table 1) with such characters, + normalizing all UTF-8 strings before string comparison may be the + only safe approach. For example, for objects (keys) it means that + PKCS#11 attribute search template would only contain attributes that + are not UTF-8 strings and another pass through returned objects is + then needed for UTF-8 string comparison after the normalization is + applied. do you suggest a stronger warning than that? more on that was incorporated into a new Internationalization Condiderations section, based on new text drafted by Nico: +6. Internationalization Considerations + The PKCS#11 specification does not specify a canonical form for + strings of characters of the CK_UTF8CHAR type. This presents the + usual false negative and false positive (aliasing) concerns that + arise when dealing with unnormalized strings. Because all PKCS#11 + items are local and local security is assumed, these concerns are + mainly about usability. + + In order to improve the user experience, applications that create + PKCS#11 objects or label tokens SHOULD normalize labels to + Normalization Form C (NFC) [UAX15]. For the same reason PKCS#11 + libraries, slots (token readers), and tokens SHOULD normalize their + names to NFC. When listing PKCS#11 libraries, slots, tokens, and/or + objects, an application SHOULD normalize their names to NFC. When + matching PKCS#11 URIs to libraries, slots, tokens, and/or objects, + applications MAY use form-insensitive Unicode string comparison for + matching, as those might pre-date these recommendations. See also + Section 3.5. and a new paragraph was also added to the existing Security Considerations section: + The PKCS#11 specification does not provide means to authenticate + devices to users; it only allows to authenticate users to tokens. + Instead, local and physical security are demanded: the user must be + in possession of their tokens, and system into whose slots the users' + tokens are inserted must be secure. As a result, the usual security + considerations regarding normalization do not arise. For the same + reason, confusable script issues also do not arise. Nonetheless, it + is best to normalize to NFC all strings appearing in PKCS#11 API + elements. See also Section 6. I think these new paragraphs convey the message that users should very careful when using characters outside ASCII, and what to do to mitigate problems that can arise from such use. Do you think more should be said in the draft itself? >For more information, you might have a look at some of the >PRECIS work, notably draft-ietf-precis-framework. > >I also remain convinced that the best place to fix this is in >the PKCS#11 spec itself. One is always at a disadvantage when >trying to work around an inadequate specification in a different >specification that has to depend on it and your work is no >exception. I wish there were whatever liaison arrangements >between the IETF and others (presumably notably RSA) to be sure >that happened or at least there was clear awareness on the PKCS >side of the deficiencies. last week I did contact OASIS PKCS 11 TC which is where PKCS#11 moved to since 2013. However, even if the issue is going to be fixed there I don't think it will be in new version 2.40 which is close to be published. Happy New Year to you, too. best regards, Jan. -- Jan Pechanec From nobody Sun Jan 11 14:26:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723D1A1ACA; Sun, 11 Jan 2015 14:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSb0tHmOCn6E; Sun, 11 Jan 2015 14:26:43 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CB91A1ABE; Sun, 11 Jan 2015 14:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1421015203; x=1452551203; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BHTviDyf27a9J/9mRUpZMXReUee/InSl2sUK0g9Y8oU=; b=QuwpZQ79U2kId1/7MTFigPy9CRPI2sDnwmmHtniwcfKTcDiuR9EuL38E 85VF+/tI84LxIZjUHdom3/VvPSmGT6POLjE/XPzWrT8Mx+cDRhdHQHco0 aiZSSV5GhY5cE2FnxUyiWVSVO/PhT4WDxSgW7+Tv8/bLQ5qwfdRDARoWH Q=; X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="300747240" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2015 11:26:41 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.148]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 12 Jan 2015 11:26:41 +1300 From: Peter Gutmann To: Jan Pechanec , "ietf@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) Thread-Index: AdAt7aueiIQsDpJZRV+GYQnIBrYzUA== Date: Sun, 11 Jan 2015 22:26:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 22:26:49 -0000 Jan Pechanec writes:=0A= =0A= >I would urge, as I think I did before, some fairly strong warnings that, a= t=0A= >least until the issues are clarified in PKCS#11 itself, one should be very= =0A= >certain one knows what one is doing (and what the consequences of one's=0A= >choices will be) if one decides to move beyond the safety and general=0A= >understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire.=0A= =0A= I'd go even further than that and just mandate MUST ASCII. This is a simpl= e=0A= means of pointing to a PKCS #11 object, not a universal means of communicat= ing=0A= abstract concepts in any language known to man. We've already gone from=0A= "specify a path to load a PKCS #11 module" to something that's fast heading= =0A= towards being Turing-complete, if it isn't already. The amount of code nee= ded=0A= to parse and process all of this is getting frightening, not to mention the= =0A= semantics of dealing with all of this (is anyone really going to care who t= he=0A= manufacturer of their HSM is when they attach to it?). The result is going= to=0A= be a bunch of partial, incompatible implementations with applications needi= ng=0A= to perform probing to see which attributes the driver they're talking to=0A= supports if they go beyond anything but the basics.=0A= =0A= Peter.=0A= From nobody Sun Jan 11 14:32:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88761A1AFA; Sun, 11 Jan 2015 14:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y-K9JhYgdsl; Sun, 11 Jan 2015 14:32:41 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id D20D91A039F; Sun, 11 Jan 2015 14:32:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1F3F476A2; Sun, 11 Jan 2015 22:32:39 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E51874769D; Sun, 11 Jan 2015 22:32:39 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id DF29F8004B; Sun, 11 Jan 2015 22:32:39 +0000 (GMT) Received: from usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 11 Jan 2015 17:28:31 -0500 Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sun, 11 Jan 2015 17:28:31 -0500 From: "Salz, Rich" To: Peter Gutmann , Jan Pechanec , "ietf@ietf.org" , "saag@ietf.org" Date: Sun, 11 Jan 2015 17:28:30 -0500 Thread-Topic: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) Thread-Index: AdAt7aueiIQsDpJZRV+GYQnIBrYzUAAACjdQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 22:32:43 -0000 > I'd go even further than that and just mandate MUST ASCII.=20 I don't know if the IETF is "allowed" to do that any more, but +1 for the r= easons you list. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Sun Jan 11 20:54:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE551A8844; Sun, 11 Jan 2015 20:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAKrMJnGDMxi; Sun, 11 Jan 2015 20:54:14 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D5E531A87F1; Sun, 11 Jan 2015 20:54:14 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 420212005CF2C; Sun, 11 Jan 2015 20:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tS/vru6vW6LPRu rQ0mBxO0mQksw=; b=DjMnJYZCczxxCwifHmqBpOXhUEfbVD2iUnOngiAj3Z2zfl 5qPGWVFpiM7TmejzL0iDclP0/SlBVAf8OedSRamba3WyFkb3pzpIp6Y8d7pYc/l3 r5H1ELlfofOYm2SbHgoXIoOAvlEoqrEwLonW0m5PpQEg45Y2h5j4/G3HD3hCE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id C72742005CF07; Sun, 11 Jan 2015 20:54:13 -0800 (PST) Date: Sun, 11 Jan 2015 22:54:13 -0600 From: Nico Williams To: "Salz, Rich" Message-ID: <20150112045411.GD16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" , "ietf@ietf.org" , Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 04:54:16 -0000 On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote: > > I'd go even further than that and just mandate MUST ASCII. > > I don't know if the IETF is "allowed" to do that any more, but +1 for > the reasons you list. I'm not sure if the IESG will agree to that, and I'm not sure if the IETF will agree to that (well, this is an IETF LC, so we're finding out). The shepherd can probably give us a sense of the IESG, and we can always come back and make it fit what the IESG wants. As for myself, I'd rather we do something like this: - note that PKCS#11 used to be just-use-8 - note that what used to interop did because of local conventions (what locales systems and/or user sessions use) - note that PKCS#11 _now_ says use-UTF-8 with no further advice - [therefore] note that a) US-ASCII is most likely to interop, b) where non-US-ASCII is needed then UTF-8 is most likely to interop (and is required by the latest PKCS#11 spec), c) where UTF-8 is used then one should normalize to NFC on create and lookup (and possibly use form-insensitive string matching). I can't see the harm in any of those. Requiring US-ASCII when PKCS#11 doesn't does strike me as a bit too pessimistic, but I'd be fine with RECOMMENDing it. Nico -- From nobody Sun Jan 11 20:56:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1DE1A87F1; Sun, 11 Jan 2015 20:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqP6TScwoe1G; Sun, 11 Jan 2015 20:56:29 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B7B341A883C; Sun, 11 Jan 2015 20:56:29 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 73ADB2F406A; Sun, 11 Jan 2015 20:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Bkkt1k7DsLIALK 8VTgGYTGXl81U=; b=S8qvz2qu2mcRnZcV//lr+NZQ9fBB9XaQ/pCoKVIkNvDfGw mbW/Awt2qi6KKPgtrNg8+wGkaGVA8dd/8eD1cpnz5FfS7j7J6rHskFv8o6O4Dmvw voWI7C3/NOh2SHkFP2FMM6jYdkI2T8Yhp0D6GCaSVcdLLB+WDDZHk3fNOHljA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id F15E92F4065; Sun, 11 Jan 2015 20:56:28 -0800 (PST) Date: Sun, 11 Jan 2015 22:56:28 -0600 From: Nico Williams To: "Salz, Rich" Message-ID: <20150112045627.GE16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" , "ietf@ietf.org" , Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 04:56:31 -0000 Do we need a liason to the OASIS PKCS#11 TC? From nobody Mon Jan 12 00:39:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12EB1A1B2E; Mon, 12 Jan 2015 00:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeCF4QTUvDDS; Mon, 12 Jan 2015 00:39:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168881A1B2A; Mon, 12 Jan 2015 00:39:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YAaXC-0007CQ-7F; Mon, 12 Jan 2015 08:39:38 +0000 Date: Mon, 12 Jan 2015 09:39:39 +0100 Message-ID: From: Randy Bush To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF Disgust , saag Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 08:39:43 -0000 > I'd go even further than that and just mandate MUST ASCII. This is a simple > means of pointing to a PKCS #11 object, not a universal means of communicating > abstract concepts in any language known to man. We've already gone from > "specify a path to load a PKCS #11 module" to something that's fast heading > towards being Turing-complete, if it isn't already can you say "attack surface?" http://www.cs.dartmouth.edu/~sergey/langsec/ randy From nobody Mon Jan 12 02:56:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AF21A8A97; Mon, 12 Jan 2015 02:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE27PLiItSBM; Mon, 12 Jan 2015 02:56:44 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9621A89BB; Mon, 12 Jan 2015 02:56:43 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id l89so16977634qgf.12; Mon, 12 Jan 2015 02:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i9Xfbo5e9Udfs4kzaozY05EHdhESk/CBw3YL/Omrgks=; b=UQwRCi+cMQiOMnoihs+RZB3F09WsSyGuBFyr//5IizDMavAQgZTgPsBHyqON1FSi// Vfbns7zPAnjHS/T92U0pW1XriJCudIKu6ELaOS94d5ot+oG1bgwL6nhcMkuogZ4KsKKi txb6w5882uGU1UUNP9O4BGkhMki3po4GeJHw1ONbw8lzkhGmEXh0edHmytInoB65Mh8M tBfoOEK1S9gEKHp29+C8KaUM57fZCTNduwuRkUK77aMCFmLNDFatl0STxK+RwCuuv0UV W3NPfilO/tznBjR9w5e7c+EAkFLh7gH1FCVhb1ba9OkP3689Z8lkowk6evT5BEoig1aP 9u1Q== MIME-Version: 1.0 X-Received: by 10.224.55.197 with SMTP id v5mr48013538qag.59.1421060203048; Mon, 12 Jan 2015 02:56:43 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.222.136 with HTTP; Mon, 12 Jan 2015 02:56:42 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 12 Jan 2015 11:56:42 +0100 X-Google-Sender-Auth: 1VeGLmpzgZmCjxPMGnuD0Gsa0lE Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "ietf@ietf.org" , Jan Pechanec , "saag@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 10:56:55 -0000 On Sun, Jan 11, 2015 at 11:26 PM, Peter Gutmann wrote: >>I would urge, as I think I did before, some fairly strong warnings that, at >>least until the issues are clarified in PKCS#11 itself, one should be very >>certain one knows what one is doing (and what the consequences of one's >>choices will be) if one decides to move beyond the safety and general >>understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire. > I'd go even further than that and just mandate MUST ASCII. This is a simple > means of pointing to a PKCS #11 object, not a universal means of communicating > abstract concepts in any language known to man. Correct, but that can be done by the OASIS PKCS #11 group, not by IETF. Here the draft proposes a way to expose PKCS #11 objects/tokens as a URI. It cannot mandate the format of the PKCS #11 attributes a module will contain. regards, Nikos From nobody Mon Jan 12 06:56:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BB91AC3A9; Mon, 12 Jan 2015 06:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VImE6xSO7b4Z; Mon, 12 Jan 2015 06:56:07 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88D1A924B; Mon, 12 Jan 2015 06:56:07 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6241928584; Mon, 12 Jan 2015 14:56:06 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4F96528580; Mon, 12 Jan 2015 14:56:06 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 3191C8003C; Mon, 12 Jan 2015 14:56:06 +0000 (GMT) Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 12 Jan 2015 09:54:24 -0500 Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 12 Jan 2015 09:54:24 -0500 From: "Salz, Rich" To: Nico Williams Date: Mon, 12 Jan 2015 09:54:23 -0500 Thread-Topic: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) Thread-Index: AdAuJCIQKQ95ct+4TqeVvwCth36L1AAU3BVQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675F93@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045627.GE16323@localhost> In-Reply-To: <20150112045627.GE16323@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" , "ietf@ietf.org" , Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:56:09 -0000 > Do we need a liason to the OASIS PKCS#11 TC? Interesting idea. You volunteering? :) I'd nominate Peter. Also because one of the main drivers in that WG is Tim= Hudson, the next island over... -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Mon Jan 12 07:39:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECAA1AC3D5; Mon, 12 Jan 2015 07:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZKtcw-7IpoZ; Mon, 12 Jan 2015 07:39:10 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6E61AC3B1; Mon, 12 Jan 2015 07:39:10 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YAh53-0007gs-65; Mon, 12 Jan 2015 10:39:01 -0500 Date: Mon, 12 Jan 2015 10:38:56 -0500 From: John C Klensin To: Randy Bush , Peter Gutmann Message-ID: <093CDA9253B966EE8D1304C1@JcK-HP8200.jck.com> In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: IETF Disgust , saag Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:39:13 -0000 --On Monday, January 12, 2015 09:39 +0100 Randy Bush wrote: >> I'd go even further than that and just mandate MUST ASCII. >> This is a simple means of pointing to a PKCS #11 object, not >> a universal means of communicating abstract concepts in any >> language known to man. We've already gone from "specify a >> path to load a PKCS #11 module" to something that's fast >> heading towards being Turing-complete, if it isn't already > > can you say "attack surface?" > > http://www.cs.dartmouth.edu/~sergey/langsec/ Randy, As I'm certain you know but others reading this probably don't, this is symptomatic of an extremely general problem with i18n. As with "more security" or "more privacy", "internationalization good, ASCII-only bad" can easily pass from a legitimate and important issue and goal into slogans and political correctness. The problem is almost identical to the security one: doing things well is hard, retrofitting into something that wasn't designed with security/i18n in mind is _much_ harder, and there is a permanent shortage of both pixie dust and magical invocations with sufficient power to solve the problems. As with protocols designed without security, taking something that was designed for ASCII and with no thought for i18n issues, either becomes a matter of very careful analysis or, as you suggest, crude efforts to retrofit something don't solve the i18n problems and, as you point out, often broaden the attack surface. We really need to get better at asking whether a given piece of protocol actually needs characters outside the ASCII repertoire and, if it does, to find the expertise and make the investments needed to get it right. Security-related protocols that increase the security risks, whether in the name of i18n or something else, do not appear to me to be the way we should be going. It is clear to me that investment hasn't been made here. It is almost as clear that the problem lies with the PKCS specs and not with this particular document. What to do about it is another matter, but it seems to me that "ASCII only until PKCS#11 itself is adequately revised" is a plausible possibility. best, john From nobody Mon Jan 12 09:13:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B331A702A; Mon, 12 Jan 2015 09:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXhvcjSsTz8v; Mon, 12 Jan 2015 09:13:03 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8621AC3EE; Mon, 12 Jan 2015 09:13:03 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D810621DE65; Mon, 12 Jan 2015 09:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mQNB9BzIKCxx3O 7nc9QnBzZAfVA=; b=fdR2lMEV+IRVzHjLgF2TZL6qYCAWUGcZFYZVgQkl8whZIp SEd5RdI4fGvsw175F8p2lKCw9n9pkr/0Z3gur36ehrG/Q7vHSW/mZiCjc8g6Z6+a UXcvQvG8MNfuJh4Nv8SNqFd46QlhBmBP3PCkhSgN+RliUJBO/boXHz9tsVwdI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id 49E7121DE57; Mon, 12 Jan 2015 09:13:02 -0800 (PST) Date: Mon, 12 Jan 2015 11:13:01 -0600 From: Nico Williams To: "Salz, Rich" Message-ID: <20150112171259.GI16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045627.GE16323@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675F93@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675F93@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" , "ietf@ietf.org" , Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 17:13:05 -0000 On Mon, Jan 12, 2015 at 09:54:23AM -0500, Salz, Rich wrote: > > Do we need a liason to the OASIS PKCS#11 TC? > > Interesting idea. You volunteering? :) Not if it meant having to be a member of the TC. Otherwise: maybe. > I'd nominate Peter. Also because one of the main drivers in that WG > is Tim Hudson, the next island over... That seems fair :) Also, IIUC Peter has participated in the TC, and certainly he has participated here. Nico -- From nobody Mon Jan 12 09:18:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AD31ACCF5; Mon, 12 Jan 2015 09:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIzSHL8PGCaN; Mon, 12 Jan 2015 09:18:18 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406511ACCDE; Mon, 12 Jan 2015 09:18:18 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0CHGmrG009153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jan 2015 17:16:49 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CHGmNH028525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jan 2015 17:16:48 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CHGmhY028518; Mon, 12 Jan 2015 17:16:48 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 09:16:47 -0800 Date: Mon, 12 Jan 2015 09:16:46 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nikos Mavrogiannopoulos In-Reply-To: Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: "ietf@ietf.org" , "saag@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 17:18:20 -0000 On Mon, 12 Jan 2015, Nikos Mavrogiannopoulos wrote: >On Sun, Jan 11, 2015 at 11:26 PM, Peter Gutmann > wrote: >>>I would urge, as I think I did before, some fairly strong warnings that, at >>>least until the issues are clarified in PKCS#11 itself, one should be very >>>certain one knows what one is doing (and what the consequences of one's >>>choices will be) if one decides to move beyond the safety and general >>>understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire. >> I'd go even further than that and just mandate MUST ASCII. This is a simple >> means of pointing to a PKCS #11 object, not a universal means of communicating >> abstract concepts in any language known to man. > >Correct, but that can be done by the OASIS PKCS #11 group, not by >IETF. Here the draft proposes a way to expose PKCS #11 objects/tokens >as a URI. It cannot mandate the format of the PKCS #11 attributes a >module will contain. hi Nikos, I agree with Nico that RECOMMENDed for ASCII use in labels would be fine. I'm gonna leave the new text for the new draft 18 discussing issues with the PKCS#11 spec not being clear about how to normalize UTF-8 encoded Unicode characters, and what is our recommendation with regard to that. I will revisit it today and send a new version draft for draft 18 here. J. -- Jan Pechanec From nobody Mon Jan 12 12:01:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4D1ACDF7; Mon, 12 Jan 2015 12:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_KZx30oyE-Y; Mon, 12 Jan 2015 12:01:26 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37E51ACDB1; Mon, 12 Jan 2015 12:01:02 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0CK0Avm010717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jan 2015 20:00:11 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CK09cI003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jan 2015 20:00:10 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CK08O0012954; Mon, 12 Jan 2015 20:00:08 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 12:00:08 -0800 Date: Mon, 12 Jan 2015 12:00:07 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: Stef Walter , Nikos Mavrogiannopoulos , "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 20:01:37 -0000 On Sun, 11 Jan 2015, Peter Gutmann wrote: >Jan Pechanec writes: > >>I would urge, as I think I did before, some fairly strong warnings that, at >>least until the issues are clarified in PKCS#11 itself, one should be very >>certain one knows what one is doing (and what the consequences of one's >>choices will be) if one decides to move beyond the safety and general >>understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire. > >I'd go even further than that and just mandate MUST ASCII. This is a simple >means of pointing to a PKCS #11 object, not a universal means of communicating >abstract concepts in any language known to man. We've already gone from hello Peter, thank you for the feedback, I've made it RECOMMENDED to use US-ASCII only for labels/names but as noted by others, we cannot really make it REQUIRED and still support the PKCS#11 spec use of UTF-8. >"specify a path to load a PKCS #11 module" to something that's fast heading >towards being Turing-complete, if it isn't already. The amount of code needed >to parse and process all of this is getting frightening, not to mention the >semantics of dealing with all of this (is anyone really going to care who the >manufacturer of their HSM is when they attach to it?). The result is going to for tokens that are guaranteed unique, combination of the manufacturer ID string and the token serial number makes the token identification unique which may be important when used from the configuration files, for example (on a command line though, I'd rather use a token name and be warned if there are more of those of the same name). I've just filed draft 18 which addresses issues discussed on the use of characters outside of the US-ASCII character set. The diff is as follows: http://www.ietf.org/rfcdiff?url1=draft-pechanec-pkcs11uri-17&url2=draft-pechanec-pkcs11uri-18 best regards, Jan. -- Jan Pechanec From nobody Mon Jan 12 13:38:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330F21ACDE7; Mon, 12 Jan 2015 13:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3qD26z3NrSW; Mon, 12 Jan 2015 13:38:32 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7000F1AC3E4; Mon, 12 Jan 2015 13:38:32 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0CLcMo3003666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jan 2015 21:38:23 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CLcLBF021352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Jan 2015 21:38:21 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0CLcLY8010513; Mon, 12 Jan 2015 21:38:21 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 13:38:20 -0800 Date: Mon, 12 Jan 2015 13:38:16 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: ietf@ietf.org Message-ID: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: Darren.Moffat@oracle.com, Stef Walter , Nikos Mavrogiannopoulos , saag@ietf.org Subject: [saag] Last Call: (The PKCS#11 URI Scheme) to Proposed Standard: new draft 18 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:38:34 -0000 hi, the new draft draft-pechanec-pkcs11uri-18.txt addresses comments on the use of UTF-8 in labels and names. The issue is that the PKCS#11 specification does not comment on normalization of the UTF-8 encoded Unicode characters, it just says "UTF-8". So, it is RECOMMENDed now in draft 18 to use US-ASCII only but enough information is provided as to what SHOULD be done if characters outside of US-ASCII need to be used. link to a diff from the previous draft version 17 is as follows: https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-18.txt best regards, Jan. -- Jan Pechanec From nobody Mon Jan 12 15:36:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9541ACE07; Mon, 12 Jan 2015 15:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrlKJaXvvspz; Mon, 12 Jan 2015 15:36:25 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA3B1ACE04; Mon, 12 Jan 2015 15:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1421105785; x=1452641785; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z2n3yF0OIDnW6t3oXpr8J5JH/uZlcH+qu55m6zD5jG8=; b=xWXIDLYcWXFeYpXoCUJaZ3Pr8A1mh/LCTxwHS92KWjfGo0dixxUOqI92 NGDCsi6v4tksI5sdF6jmIZ1v6KjCJ2jvDPvIlE0YfDChIoi0tJfUKcJe6 DtGANGvo/I/twZq3JQ2A6NtkmFF57VyE27TsqPuc23317y6t4TeQzjYba g=; X-IronPort-AV: E=McAfee;i="5600,1067,7679"; a="81409320" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2015 15:36:24 -0800 X-IronPort-AV: E=Sophos;i="5.07,745,1413270000"; d="scan'208";a="882646541" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Jan 2015 15:36:24 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 12 Jan 2015 15:36:22 -0800 Message-ID: <54B45A75.1050503@qti.qualcomm.com> Date: Mon, 12 Jan 2015 17:36:21 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Nico Williams References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> In-Reply-To: <20150112045411.GD16323@localhost> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "saag@ietf.org" , Jan Pechanec , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 23:36:27 -0000 On 1/11/15 10:54 PM, Nico Williams wrote: > On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote: > > >>> I'd go even further than that and just mandate MUST ASCII. >>> >> >> I don't know if the IETF is "allowed" to do that any more, but +1 for >> the reasons you list. >> > I'm not sure if the IESG will agree to that... Given that this particular member of the IESG has (successfully) argued vehemently for ASCII-only on multiple occasions in the recent past, I would say that your worries on that score are overdone. :-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Jan 12 16:09:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1591ACE2A; Mon, 12 Jan 2015 16:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL5--xMnOmMF; Mon, 12 Jan 2015 16:09:00 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08D1ACE29; Mon, 12 Jan 2015 16:09:00 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 122D031805D; Mon, 12 Jan 2015 16:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=vqbI3wNkMYcHIq 2NQOy3YNwqR+c=; b=dLAzNFx64WiQubXYy3UD3fwl9EmvCw59KW3j/wmARReX/K H81bP8hdwiN9PY7EA1OO6BCWpTajCiDyF4Kk4/hYRifgm0ItuWo2TVqYiTXbkWlo wSr2/SzuIslukML/hzwmLGV6Lyd0jNo46cxy6QScrBOtrbIatumThYWQkjdSg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 82DEE31805C; Mon, 12 Jan 2015 16:08:59 -0800 (PST) Date: Mon, 12 Jan 2015 18:08:59 -0600 From: Nico Williams To: Pete Resnick Message-ID: <20150113000854.GW16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B45A75.1050503@qti.qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" , Jan Pechanec , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:09:02 -0000 On Mon, Jan 12, 2015 at 05:36:21PM -0600, Pete Resnick wrote: > On 1/11/15 10:54 PM, Nico Williams wrote: > > >On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote: > > > >>>I'd go even further than that and just mandate MUST ASCII. > >>I don't know if the IETF is "allowed" to do that any more, but +1 for > >>the reasons you list. > >I'm not sure if the IESG will agree to that... > > Given that this particular member of the IESG has (successfully) > argued vehemently for ASCII-only on multiple occasions in the recent > past, I would say that your worries on that score are overdone. :-) Well alright. I'd love to see a set of guidelines for I18N activities. When should we try to support Unicode, and when should we not? Is it one of those "I know it when I see it" kinds of guidelines? That wouldn't be useful enough :( Mind you, IIRC PKCS#11 didn't even say anything about ASCII before. Token labels and such used to be fixed-sized octet strings containing character data. Jan can correct me if I'm wrong. I'm not sure even saying "ASCII-only" would necessarily be safe in that case... Fortunately the OASIS PKCS11 TC has clarified that these are UTF-8; unfortunately they left other I18N details out. Nico -- From nobody Mon Jan 12 16:47:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9472F1ACE3F; Mon, 12 Jan 2015 16:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 733FsOTrdoG5; Mon, 12 Jan 2015 16:47:22 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1A3A1ACE4B; Mon, 12 Jan 2015 16:47:21 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0D0k0d3015111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 00:46:01 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0D0jxDC007548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2015 00:46:00 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t0D0jwof029416; Tue, 13 Jan 2015 00:45:58 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 16:45:58 -0800 Date: Mon, 12 Jan 2015 16:45:57 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20150113000854.GW16323@localhost> Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> <20150113000854.GW16323@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: Pete Resnick , "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:47:25 -0000 On Mon, 12 Jan 2015, Nico Williams wrote: >On Mon, Jan 12, 2015 at 05:36:21PM -0600, Pete Resnick wrote: >> On 1/11/15 10:54 PM, Nico Williams wrote: >> >> >On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote: >> > >> >>>I'd go even further than that and just mandate MUST ASCII. >> >>I don't know if the IETF is "allowed" to do that any more, but +1 for >> >>the reasons you list. >> >I'm not sure if the IESG will agree to that... >> >> Given that this particular member of the IESG has (successfully) >> argued vehemently for ASCII-only on multiple occasions in the recent >> past, I would say that your worries on that score are overdone. :-) > >Well alright. I'd love to see a set of guidelines for I18N activities. > >When should we try to support Unicode, and when should we not? Is it >one of those "I know it when I see it" kinds of guidelines? That >wouldn't be useful enough :( > >Mind you, IIRC PKCS#11 didn't even say anything about ASCII before. >Token labels and such used to be fixed-sized octet strings containing >character data. Jan can correct me if I'm wrong. I'm not sure even >saying "ASCII-only" would necessarily be safe in that case... > >Fortunately the OASIS PKCS11 TC has clarified that these are UTF-8; >unfortunately they left other I18N details out. hi Nico, the PKCS#11 specification says those strings are UTF-8 back in the last version that is still current (2.20) from 2004 (didn't check earlier versions). I don't think that OASIS PKCS11 TC has made any changes in that area to upcoming 2.40 and issues of normalization have never been brought up there either; I talked about it to Valerie Fenwick, one of the chairs of OASIS PKCS11 TC. I think that saying that characters from US-ASCII set SHOULD be used for labels and names since the PKCS#11 spec is not clear about the normalization should be safe here. which is what I did in draft 18 I've filed today and it contains the changes on how to deal with UTF-8 which have been discussed in the last couple of weeks. https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-18.txt cheers, Jan. -- Jan Pechanec From nobody Mon Jan 12 16:59:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387931A8826; Mon, 12 Jan 2015 16:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1O0WE3EJnVN; Mon, 12 Jan 2015 16:59:15 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 02FAF1A8746; Mon, 12 Jan 2015 16:59:15 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id B373C10060; Mon, 12 Jan 2015 16:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ph8gkIoCFoh3LW Z3d0k3xkA6ogo=; b=dQ1ZICR2vXnxmz5eRMZQwsDSzEx1btJn6z/i8VidWClJxo CZPucea0/xw848Rk6OlSeGKrsFWQeqMkrBtbIrJ5kaDG1GT1e5KYdVH4lyXEedG2 2RA8uQTVU9EQyKhVQzly6B7jFZ4kagzHIiaFyATCwKJAAvflApt8LaPgEcg2I= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 3F85E10059; Mon, 12 Jan 2015 16:59:14 -0800 (PST) Date: Mon, 12 Jan 2015 18:59:13 -0600 From: Nico Williams To: Jan Pechanec Message-ID: <20150113005909.GY16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> <20150113000854.GW16323@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Pete Resnick , "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 00:59:16 -0000 On Mon, Jan 12, 2015 at 04:45:57PM -0800, Jan Pechanec wrote: > On Mon, 12 Jan 2015, Nico Williams wrote: > >unfortunately they left other I18N details out. > > hi Nico, the PKCS#11 specification says those strings are > UTF-8 back in the last version that is still current (2.20) from 2004 > (didn't check earlier versions). [...] Huh. Why did I remember octet strings?? Version 2.01 (1997) did have plain octet strings with no character set nor codeset defined. But still, 2004 is pretty late. > I think that saying that characters from US-ASCII set SHOULD > be used for labels and names since the PKCS#11 spec is not clear about > the normalization should be safe here. Yes. Nico -- From nobody Mon Jan 12 17:08:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF11A884F; Mon, 12 Jan 2015 17:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95AijsfWqe-8; Mon, 12 Jan 2015 17:07:59 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0051A8836; Mon, 12 Jan 2015 17:07:59 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0D16eC8000556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 01:06:41 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t0D16dwd008935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Jan 2015 01:06:40 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0D16djo021174; Tue, 13 Jan 2015 01:06:39 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jan 2015 17:06:39 -0800 Date: Mon, 12 Jan 2015 17:06:38 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Nico Williams In-Reply-To: <20150113005909.GY16323@localhost> Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> <20150113000854.GW16323@localhost> <20150113005909.GY16323@localhost> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: Cc: Pete Resnick , "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 01:08:12 -0000 On Mon, 12 Jan 2015, Nico Williams wrote: >On Mon, Jan 12, 2015 at 04:45:57PM -0800, Jan Pechanec wrote: >> On Mon, 12 Jan 2015, Nico Williams wrote: >> >unfortunately they left other I18N details out. >> >> hi Nico, the PKCS#11 specification says those strings are >> UTF-8 back in the last version that is still current (2.20) from 2004 >> (didn't check earlier versions). [...] > >Huh. Why did I remember octet strings?? Version 2.01 (1997) did have >plain octet strings with no character set nor codeset defined. But >still, 2004 is pretty late. it is, and version 2.30 from 2009 still under the control of RSA Labs was only ever draft. Version 2.40 seems to be very close from becoming a new version though. -- Jan Pechanec From nobody Mon Jan 12 19:41:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58001A8A01; Mon, 12 Jan 2015 19:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idBl119rjwEr; Mon, 12 Jan 2015 19:41:18 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662281A8872; Mon, 12 Jan 2015 19:41:18 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YAsLq-0009xY-BE; Mon, 12 Jan 2015 22:41:06 -0500 Date: Mon, 12 Jan 2015 22:41:01 -0500 From: John C Klensin To: Nico Williams , Pete Resnick Message-ID: <178010D0AA50AAB454E23D84@JcK-HP8200.jck.com> In-Reply-To: <20150113000854.GW16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akama i.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> <20150113000854.GW16323@localhost> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ietf@ietf.org, saag@ietf.org, Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 03:41:21 -0000 --On Monday, January 12, 2015 18:08 -0600 Nico Williams wrote: >> Given that this particular member of the IESG has >> (successfully) argued vehemently for ASCII-only on multiple >> occasions in the recent past, I would say that your worries >> on that score are overdone. :-) > > Well alright. I'd love to see a set of guidelines for I18N > activities. So would we all. RFC 2277 was supposed to provide some guidance but is now badly obsolete in many different ways, including exhibiting how little we knew about some things at the time. We have, I hope, learned a lot, but see below. > When should we try to support Unicode, and when should we not? > Is it one of those "I know it when I see it" kinds of > guidelines? That wouldn't be useful enough :( Let me suggest a general way of thinking about things -- maybe not quite a "guideline". Especially for security-type protocols, make sure there is a substantive reason, presumably connected to users and user experience, for it to be necessary to go beyond ASCII. I really do mean "necessary": if it is just a good idea in principle or a maybe-nice-to-have or "maybe someone will want this some day", skip it because adding i18n capabilities _will_ make correct and predictable implementations more difficult and _will_ increase the number and range of attack opportunities. > Mind you, IIRC PKCS#11 didn't even say anything about ASCII > before. Token labels and such used to be fixed-sized octet > strings containing character data. Jan can correct me if I'm > wrong. I'm not sure even saying "ASCII-only" would > necessarily be safe in that case... And that reinforces my view that the real, underlying, problem here has to be fixed in PKCS#11, not in anything the IETF puts on top of it. Only they can fix the problems; we can, at best, mitigate the damage. > Fortunately the OASIS PKCS11 TC has clarified that these are > UTF-8; unfortunately they left other I18N details out. It appears to me that what they have said puts their level of understanding of the various issues somewhat behind where we were when RFC 2277 was written in 1997. john From nobody Tue Jan 13 14:36:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1791A9068; Tue, 13 Jan 2015 14:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4yzWJOGXlVW; Tue, 13 Jan 2015 14:36:32 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1663D1B2A1B; Tue, 13 Jan 2015 14:36:32 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id CC41E58406E; Tue, 13 Jan 2015 14:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Bf8kBY4AQamY2c mLJ2ueO/4VdG4=; b=nDcEQ0MVkhYnZtHMb/TLI+OCXjGHktRM8JVNgW67DvQn+u Vcg1VU13TMGXeRjgE/e4PN8zCMi52sC71tzrlPgJINFDi17+wycsqrWVPY5n6s6l jQFhWoAfkODkRfXxUzae/AVMhWQFB9fr2XG92aimlY2DwyB1cOd9TWnJEHsjg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 3994F584065; Tue, 13 Jan 2015 14:36:31 -0800 (PST) Date: Tue, 13 Jan 2015 16:36:30 -0600 From: Nico Williams To: John C Klensin Message-ID: <20150113223619.GD16323@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AAF5744C@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E67@USMBX1.msg.corp.akamai.com> <20150112045411.GD16323@localhost> <54B45A75.1050503@qti.qualcomm.com> <20150113000854.GW16323@localhost> <178010D0AA50AAB454E23D84@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <178010D0AA50AAB454E23D84@JcK-HP8200.jck.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: ietf@ietf.org, Pete Resnick , saag@ietf.org, Jan Pechanec Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call)) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 22:36:33 -0000 On Mon, Jan 12, 2015 at 10:41:01PM -0500, John C Klensin wrote: > --On Monday, January 12, 2015 18:08 -0600 Nico Williams > wrote: > > Well alright. I'd love to see a set of guidelines for I18N > > activities. > > So would we all. RFC 2277 was supposed to provide some guidance > but is now badly obsolete in many different ways, including > exhibiting how little we knew about some things at the time. We > have, I hope, learned a lot, but see below. > > > When should we try to support Unicode, and when should we not? > > Is it one of those "I know it when I see it" kinds of > > guidelines? That wouldn't be useful enough :( > > Let me suggest a general way of thinking about things -- maybe > not quite a "guideline". Especially for security-type > protocols, make sure there is a substantive reason, presumably > connected to users and user experience, for it to be necessary > to go beyond ASCII. I really do mean "necessary": if it is just > a good idea in principle or a maybe-nice-to-have or "maybe > someone will want this some day", skip it because adding i18n > capabilities _will_ make correct and predictable implementations > more difficult and _will_ increase the number and range of > attack opportunities. Yes, I18N is all about UIs and the UX. Clearly, if a character string isn't a UI element, and is never a visible aspect of the UX, then it is a great candidate for being made US-ASCII only. Indeed, we *should* make all such strings US-ASCII only. That much is obvious, and whether or not something is part of the UI is an objective measure with relatively little room for doubt. But there are UI elements that could reasonably be constrained to US-ASCII (because the world over, people manage to deal with US-ASCII character strings in various parts of their UIs). The tricky part is deciding what UI elements (or things leaking into them) qualify. For example, a "manufacturer" name in PKCS#11 could reasonably be constrained to US-ASCII only. Right? Well, maybe a French -say- manufacturer might object. An interesting distinction here might be: name or identifier? Identifiers (appearing in UIs) -> US-ASCII. Names -> Unicode. Token and object labels seem a lot like identifiers in the use cases I expect. But I can't be certain that they would never be expected to contain names. Manufacturer names really are names, no? These are decisions that we can make that can anger people who are not participating here today. > > Mind you, IIRC PKCS#11 didn't even say anything about ASCII > > before. Token labels and such used to be fixed-sized octet > > strings containing character data. Jan can correct me if I'm > > wrong. I'm not sure even saying "ASCII-only" would > > necessarily be safe in that case... > > And that reinforces my view that the real, underlying, problem > here has to be fixed in PKCS#11, not in anything the IETF puts > on top of it. Only they can fix the problems; we can, at best, > mitigate the damage. Yes. But look, PKCS#11 is a thing with a low count of character strings. Mostly things will be looked for with equivalence semantics, and form-insensitive Unicode string comparison will do for that (at the expense of having the code for it), as will plain old octet string comparison (because we can expect happy input method output form agreement accidents). I think Jan's text is fine. I don't mean to belabor this thread. I'm now only commenting on the more general matter of when we should be happy to settle for less than the full I18N treatment. > > Fortunately the OASIS PKCS11 TC has clarified that these are > > UTF-8; unfortunately they left other I18N details out. > > It appears to me that what they have said puts their level of > understanding of the various issues somewhat behind where we > were when RFC 2277 was written in 1997. Yes, but it's also fair to note the above, that this is the sort of case where a low-effort I18N ("say UTF-8; say nothing about anything else") seems likely to be good enough for most implementors and users. Nico -- From nobody Thu Jan 15 11:40:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79E71B31BE; Thu, 15 Jan 2015 11:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeoWv9G1a2g1; Thu, 15 Jan 2015 11:40:11 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB891B31C6; Thu, 15 Jan 2015 11:40:05 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0FJdvEx019019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2015 19:39:58 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0FJdujd002077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jan 2015 19:39:56 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0FJdtYe002061; Thu, 15 Jan 2015 19:39:55 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Jan 2015 11:39:55 -0800 Date: Thu, 15 Jan 2015 11:39:54 -0800 (PST) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: ietf@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: Darren.Moffat@oracle.com, Stef Walter , Nikos Mavrogiannopoulos , saag@ietf.org Subject: Re: [saag] Last Call: (The PKCS#11 URI Scheme) to Proposed Standard: new draft 19 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:40:12 -0000 On Mon, 12 Jan 2015, Jan Pechanec wrote: hello, a new draft was filed, draft-pechanec-pkcs11uri-19.txt, which addresses IANA comments on the registration template. Changes from the previous version 18 are as follows: https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-19.txt regards, Jan. > hi, the new draft draft-pechanec-pkcs11uri-18.txt addresses >comments on the use of UTF-8 in labels and names. The issue is that >the PKCS#11 specification does not comment on normalization of the >UTF-8 encoded Unicode characters, it just says "UTF-8". So, it is >RECOMMENDed now in draft 18 to use US-ASCII only but enough >information is provided as to what SHOULD be done if characters >outside of US-ASCII need to be used. > > link to a diff from the previous draft version 17 is as >follows: > >https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-18.txt > > best regards, Jan. > > -- Jan Pechanec From nobody Thu Jan 15 14:58:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2C1A8998 for ; Thu, 15 Jan 2015 14:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-IbHK8VursF for ; Thu, 15 Jan 2015 14:58:28 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D71A8FD6 for ; Thu, 15 Jan 2015 14:58:27 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 6521D9A400D for ; Thu, 15 Jan 2015 17:58:17 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id cWtstXsahBiy for ; Thu, 15 Jan 2015 17:57:56 -0500 (EST) Received: from [192.168.2.101] (pool-173-79-205-14.washdc.fios.verizon.net [173.79.205.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 38A509A4003 for ; Thu, 15 Jan 2015 17:57:56 -0500 (EST) From: Russ Housley Content-Type: multipart/signed; boundary=Apple-Mail-18-673834260; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 15 Jan 2015 17:57:45 -0500 References: To: IETF SAAG Message-Id: <68AAB8A4-D60D-4B02-A7F8-24713D5A1B44@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] Fwd: CFP - NIST Workshop on Elliptic Curve Cryptography Standards X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:58:30 -0000 --Apple-Mail-18-673834260 Content-Type: multipart/alternative; boundary=Apple-Mail-17-673834211 --Apple-Mail-17-673834211 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Workshop on Elliptic Curve Cryptography Standards > June 11-12, 2015 >=20 > Call for Papers >=20 > The National Institute of Standards and Technology (NIST) will host a = Workshop on Elliptic Curve Cryptography Standards at NIST headquarters = in Gaithersburg, MD on June 11-12, 2015. The workshop will provide a = venue to engage the cryptographic community, including academia, = industry, and government users to discuss possible approaches to promote = the adoption of secure, interoperable and efficient elliptic curve = mechanisms. >=20 > NIST solicits papers, presentations, case studies, panel proposals, = and participation from any interested parties, including researchers, = systems architects, vendors, and users. >=20 > The full Call for Papers and workshop details are available at the = workshop website: http://www.nist.gov/itl/csd/ct/ecc-workshop.cfm >=20 > =20 >=20 --Apple-Mail-17-673834211 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Workshop on = Elliptic Curve Cryptography Standards
June 11-12, = 2015

Call for Papers

The = National Institute of Standards and Technology (NIST) will host a Workshop on Elliptic = Curve Cryptography Standards at NIST headquarters in = Gaithersburg, MD on June 11-12, 2015.  The workshop will provide a = venue to engage the cryptographic community, including academia, = industry, and government users to discuss possible approaches to promote = the adoption of secure, interoperable and efficient elliptic curve = mechanisms.

NIST solicits papers, presentations, case studies, = panel proposals, and participation from any interested parties, = including researchers, systems architects, vendors, and = users.

The full Call for Papers and workshop details are = available at the workshop website:  > RECOMMENDed now in draft 18 to use US-ASCII only but enough >> information is provided as to what SHOULD be done if characters >> outside of US-ASCII need to be used. >> >> link to a diff from the previous draft version 17 is as >> follows: >> >> https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-18.txt >> >> best regards, Jan. >> >> > From nobody Wed Jan 28 11:24:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55C11A0077; Wed, 28 Jan 2015 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbFKPw3IwVHl; Wed, 28 Jan 2015 11:24:30 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1701A0072; Wed, 28 Jan 2015 11:24:30 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id k14so22493257wgh.8; Wed, 28 Jan 2015 11:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qLZFtoF5cVt6+ZzxYCeEezLlaUEGAnPhhgdRj5HoWa4=; b=eBSgZ8d7iObKcejv1Cwhtg87ROqoFv1jXZMOgywDqJnrouOqrD0OC6xjAVJuUQHwu9 Y2fsFRS/jwL4WIWaLd9gTcyot4XsQrzYCGeRAf7wIk0E4iITCqv8K5bTNYOoL+T+WSX1 SqqRvv+h/2Bin3RR8AnxbvHCu8Q+52v2Hat/7KBdKOFZmNT9h4LgcKlAdlZXaYz+JdPn P6JhP8l9egN85orRR4ezOpzg3bZBTCyNz86C3A8w/M1U0CidkdIuuduu6tjmDu4vwBVm 4X6D0qOvvYlFP1qIaNDIONvNOUJ8fPcR0BC68lQd7ulMTa2GbDDwd11pco2TUk1+qNHj 3vPA== MIME-Version: 1.0 X-Received: by 10.194.78.97 with SMTP id a1mr10600846wjx.104.1422473068741; Wed, 28 Jan 2015 11:24:28 -0800 (PST) Received: by 10.194.236.106 with HTTP; Wed, 28 Jan 2015 11:24:28 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 20:24:28 +0100 Message-ID: From: Daniel Migault To: saag@ietf.org, apps-discuss@ietf.org, ops-area@ietf.org Content-Type: multipart/alternative; boundary=047d7bfcf7d0f70bf1050dbb5141 Archived-At: Cc: Time Zone Data Distribution Service Subject: [saag] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 19:24:32 -0000 --047d7bfcf7d0f70bf1050dbb5141 Content-Type: text/plain; charset=UTF-8 Dear Friends and Colleagues, Our document describing Time Zone Data Distribution Service [1] is close to be finalized and we would like to proceed to cross area review. We would greatly appreciate to get review by February 11. Best Regards, Daniel and Eliot [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bfcf7d0f70bf1050dbb5141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Friends and Colleagues,

<= /div>
Our document describing Time Zone Data Distribution Service [1] is c= lose to be finalized and we would like to proceed to cross area review.
We would greatly appreciate to get review by February 11.<= br>
Best Regards,

Daniel and Eliot

[1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05
=

--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--047d7bfcf7d0f70bf1050dbb5141-- From nobody Wed Jan 28 12:17:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0D1A00EA for ; Wed, 28 Jan 2015 12:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4tpgMzCZTs7 for ; Wed, 28 Jan 2015 12:17:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51A81A016A for ; Wed, 28 Jan 2015 12:17:28 -0800 (PST) Received: from [192.168.2.105] ([79.246.42.45]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LsChr-1XXr21293X-013zLc for ; Wed, 28 Jan 2015 21:17:26 +0100 Message-ID: <54C943D3.3080807@gmx.net> Date: Wed, 28 Jan 2015 21:17:23 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GZ6bkFsCd4EEzqHj0c95L7h+sRz1nlZyRUKXrSoyvrl0scvlXP+ rNxxBveBon3RxffFzl/YhK7IVSsgoVHBjPZRPGrJRIHY9dBeZu7F7eoWolqQT/ebT2BoeRP IZkOZWrN1f04P74ahAysNWvmtXrFgNL1WjJjdkmlVQbx5Z1PqVTPGdvPoLZMmAQMsTZIxoy ZdQAvvWUSYzjsIRhNnp6w== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [saag] Internet Draft: draft-boesch-idxp-idpef-00.txt: Standardized Parameterization of Intrusion Detection Entities (IDPEF) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 20:17:35 -0000 Dear Community, Efficiency of Intrusion Detection Systems (IDS) depends on their configuration and coverage of services. The coverage depends on used IDS with currently vendor-specific configurations. In case of usage of multiple systems the operations could become complex. Individual Communication between management interface and the IDS entities results that current multi-vendor IDS architectures do not interact with each other. They are independent coexistent. The Internet Draft defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from a Manager to an Analyzer. The created Intrusion Detection Parametrization Exchange Format (IDPEF) is intended to be a standard data format to parametrize IDS. The development of this open standardized format and the Intrusion Detection Message Exchange Format (IDMEF) will be enable in combination interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal IDS implementation. The most obvious place to implement IDPEF is in the data channel between a Manager and an Analyzer of an IDS within this data channel where the Manager sends the configuration parameters to the Analyzers. But there are other places where the IDPEF can be useful: - Combination of specialized IDS like application-IDS with server-IDS, WLAN-IDS and network-IDS to one functional interacting meta-IDS. - Management of different IDS vendors with one central management interface. - Interaction of different IDS by using IDPEF and IDMEF. - Parametrization backups and restore of parametrized IDS entities. - For a communication between a Manager and a Manager in a multi-stage management architecture. I am happy to invite you to give me feedback, suggestions, notations, hints, recommendations, etc. to improve the Internet Draft. Also comments to the purpose or intention of the format are welcome. The initial version of the Internet Draft could be found at: http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt I looking forward to a lively discussion. Kind regards, B.-C. Boesch From nobody Thu Jan 29 18:13:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCB31A88D9; Thu, 29 Jan 2015 18:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQKMyhyJzmYf; Thu, 29 Jan 2015 18:13:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C11A88D8; Thu, 29 Jan 2015 18:13:43 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 44B96F984; Thu, 29 Jan 2015 21:13:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1B4A0201D1; Thu, 29 Jan 2015 21:13:40 -0500 (EST) From: Daniel Kahn Gillmor To: Daniel Migault , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 29 Jan 2015 21:13:36 -0500 Message-ID: <874mr9aucv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 02:13:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Daniel and Elliot-- On Wed 2015-01-28 14:24:28 -0500, Daniel Migault wrote: > Our document describing Time Zone Data Distribution Service > [1] is close to > be finalized and we would like to proceed to cross area review. > > We would greatly appreciate to get review by February 11. [...] > [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05 Thanks for your work on this. This is the first time i've seen this draft; apologies for not looking at it earlier. I'm only subscribed to saag@ietf.org (and ietf-privacy, which is idle lately, but i've included here because some of my review touches on privacy), so this post might not make it through to tzdist@ietf.org -- feel free to forward it as needed. I did a quick skim here with my security and privacy hats on, and have a few comments: (privacy) Privacy Considerations section is missing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D There is *no* "Privacy Considerations" section in the draft at all. Please read RFC 6973 for guidance in conducting a privacy review of the protocol. The act of querying these servers leaks something about the location of the person doing the query, at least, and may leak information about other locations that they're interested in. It's also possible that regular attempts to query this information will provide a linkable trail of the user, which could then be (mis)used without their knowledge or permission. Here's an attempt at a quick analysis, though i haven't thought through the protocol in detail. I hope you'll do your own analysis, and you're welcome to take any of mine: Implausibly: if the average user is interested in 5 timezones, and there are 774 known zones ("find /usr/share/zoneinfo -type f | wc"), and those interests were evenly distributed across the zones for every users, then the set of requests to update an individual's preferred timezones yields nearly 50 bits of entropy, far more than enough to distinguish every individual human from each other. More plausibly: timezone interest is probably less than 5 for most people, and it isn't evenly distributed: the people who are interested in Americas/New_York are more likely to be interested in Americas/Los_Angeles than in Arctic/Longyearbyen. But anyone with an unusual set of TZs can probably be identified (perhaps uniquely) by any provider they talk to just by what TZs they ask for. Since =C2=A74.1.4 says "Clients SHOULD poll for changes, using an appropria= te conditional request, at least once a day", a malicious provider intent on surveilling its users and with a mechanism to do so would have a daily checkin. I imagine this as some kind of background system service looking for updates. the daily checkin could be used to track a user's movements around the network, if their device is not stationary. The time of checkin could also be used as a linking mechanism, if the machine polls with rigid regularity. Are there strategies that someone interested in preserving their anonymity from a tzdata provider should take to remain anonymous? If so, what are they? (privacy) HTTP pipelining? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Clients requesting multiple unusual TZs together are more easily identifiable to servers, than clients who request only one. Should clients request all their interested TZs at once, or spread out their polling updates over time? HTTP pipelining is clearly more efficient; but what are the privacy implications if you have a system service that does this? (privacy) HTTP Cookies? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The choice of HTTP transport also allows for servers to set cookies in clients -- should clients accept and re-transmit cookies from the server? What are the privacy implications? (privacy) Tracking via ETag? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Also, conditional requests seem to be encouraged via the use of an ETag header. It looks to me like a provider who wants to track its users individually (even in the absence of cookies) could use a cache of personalized ETags to do so. For example, the first time any client requests TZ X (with no If-None-Match request header), the server mints a new ETag Y, generates a new client ID Z, and records: * Client ID Z * the requested TZ X * the new ETag Y * the time of issuance * the IP address * any other interesting metadata When a request comes in for TZ X with an If-None-Match: Y header, the server can link the two requests and record them both with client ID Z. When the underlying data for the TZ actually changes, the server mints a new ETag (for the new version of TZ X), but associates it with the same client ID Z. (privacy) Logging policy for distribution servers? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is also no mention of recommended logging policy for the servers, no attempt to address data minimization or the risks to trackable users based on normal server logs. (privacy) Authenticated clients are trackable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D the Security Considerations section says: Servers MAY require some form of authentication or authorization of clients (including secondary servers) to restrict which clients are allowed to access their service, or provide better identification of errant clients. As such, servers MAY require HTTP- based authentication as per [RFC7235]. Clients who make authenticated connections to servers are eminently trackable by those servers. What are the privacy implications for those clients? (privacy) network observers tracking clients =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Someone passively observing the network could also potentially track the clients of a given server via traffic analysis, even if the server is not cooperating. First, the attacker could get a stash of all the data that the server has, noting the size of each zone under each supported format. When a new request is made for a zone, the attacker can observe the size of the query and the size of the response and guess with high probability which zone was requested. If the clients poll once a day on a schedule (i.e. exactly every 86400 seconds) then the network observer may be able to track updates and determine when a client interested in a particular zone does an update. What mechanisms could a client (and server?) use to frustrate such a network-based attacker to keep a given client's identity anonymous? (security/privacy) HTTP redirection =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What if the server sends an HTTP redirection (e.g. via HTTP response 301 or 302) -- should the client follow it? What if it is to a cleartext HTTP resource? What are the security and privacy consequences of following these redirections off-origin? (security) Consequences of accepting bad TZ updates? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D I'm glad that the Security Considerations recognizes that reliable TZ data is vital -- but no example is given of what a data compromise might look like. Is it worth providing a couple of examples of bad outcomes? are we talking about missed appointments? or crashing software? or something else? (security) why not require TLS on both sides? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D you've got that the service MUST operate over https, but the clients only SHOULD try https first. Why allow for cleartext access at all? Why not say that both clients and servers MUST support HTTPS? I see https://tools.ietf.org/wg/tzdist/trac/ticket/7 suggests that there is consensus that you don't want "mandatory to use", but i don't know where the discussion is, or why you don't want it. (security) Provider-to-Provider TLS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Connections between "Secondary Providers" and "Root Providers" seem different from the connections between Clients and Providers. If you can't mandate HTTPS for all clients for some reason, what about at least mandating that the caching infrastructure requires TLS for all provider-to-provider connections? The secondary provider will need a TLS stack anyway (as a server), so it should be able to do TLS on the upstream side. (security) DNS compromise leaves only cleartext =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a network-based attacker can filter network traffic, they can simply drop all outbound _timezones._tcp.example.com DNS queries, and then when the client gives up, they can allow through (or provide their own, if DNSSEC isn't involved) responses to _timezone._tcp.example.com. This immediately puts the network attacker in the position of being able to dictate timezone information to a client willing to fall back to cleartext. (security) no-DNSSEC fallback checks are ambiguous =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The Security Considerations currently say: In the absence of a secure DNS option, clients SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, clients SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. What does "matches" mean here? the second sentence suggests that it means "shares some sort of a suffix with" -- but which part? If i query for an SRV of _timezones._tcp.tz.example.com, and it replies with an FQDN of bar.example.com, is that OK? what about x.y.z.bar.example.com? If DNSSEC isn't available, the attacker can still point this response to any IP address of their choice, right? What does "verify with the user" mean if this is a TZdata service, which is presumably running automatically on the computer to keep this information up-to-date? most such services have no user interaction at all. If there is a UI, what options would the user be given in such a case? Is this a popup dialog box that says "you asked for timezone data updates from tz.example.com -- is it ok to get it from whatever.example instead?" What users can make sense of this dialog? What information would a fully-technically-cognizant user (a deep wizard) use to answer it sensibly? What would a normal user use? If DNSSEC *is* available, is it OK if the record points outside the zone? what if it points to a non-signed zone? (security) Conflicts between Providers? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The draft implies that a client might fetch data from multiple providers. What should the client do if two providers provide conflicting information about the same TZ? (security) use examples of certificate validation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The combination of SRV records and X.509 certificate validation and (maybe) DNSSEC is a tricky subject. you've referenced RFC 6125, but i don't think that's enough. Do you mean to suggest that the certificate should use a SRVName subjectAltName (RFC4985)? or should it use a DNSName subjectAltName with the name sent in the SRV query? or a DNSName subjectAltName with the FQDN returned in the SRV response? Providing an example would make it clearer what you mean. For example: =20 If a client looks up SRV for _timezones._tcp.example.com, and gets a response of tz.example.net, then the certificate should (a) be valid, and (b) have either a subjectAltName DNSName of tz.example.net or a subjectAltName SRVName of _timezones._tcp.example.com (or both). (please adjust to taste, i don't mean to tell you what the right choice is here, it's an ugly problem) (security) Statically-signed data vs. transport security =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D The security of the transmission process seems to rely entirely on transport security. If there is a compromise in transmission between the Root provider and the secondary provider, or a compromise of any provider, the client has no way of knowing that they're getting bad data. tzdata changes infrequently enough that it seems like it could be signed with an offline key, making compromise of running systems much less fruitful. But this only works if the client can verify the offline signature. Have you considered any mechanism that the client could use to verify the tz update based on data itself, without depending solely on transport security? I see this question tangentially raise here: https://www.ietf.org/mail-archive/web/tzdist/current/msg00102.html but it's answered only in the "we still need TLS" way (which i agree with). Is any work done (or planned) on providing signed/verifiable data? (security) TLS best-practices? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D I'm glad that you've got TLS as a MUST for servers. Is it worth making a normative reference to the UTA's TLS best-practices document? https://tools.ietf.org/html/draft-ietf-uta-tls-bcp Sorry this got long, and that this is more in the form of questions than patches. I hope i haven't repeated too much of what the tzdist WG has already discussed -- please feel free to point me to relevant discussions that i may have missed. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUyujRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcf70P/2orOEYqSFmiXmaPs87Vxc8d jZ+ME5gUZr7yB5VTUs0NlNuBXvvhyXyAuH0pWS+9MUNfOklGcX4PDw0BSjuRt1bH gNNE1E5AN8Iq/eYxaY0UIfsaf5DAaIQV8PBzaMhq85os+IQgEUpRqInap0ydcbyK gQo0zY6DHww4b5ukAERrJ47XEqltsfVbAzlxK/OIAzpU/Rbzfojnyl7nq/CfcuAx 2xdfv3PJEFwbH2sLRTfGwWizFQZzF8/HW80BrXqJTN7bE2vS8GsPsm2c7PclrefH pcFd0V+pDoeK071PvUh1P607+SONaB796298Wb/7iHLLEDBAxs+UlJ+7q3WiVYmn vLIqN5IT43ho2E+/hX1N4QNRUYb9WRYdY6vUjh+XhU/mwRW5lj6yRLBMp8Quzdol 2Y7YKGWKxpPcieCgsBeL9M75EPW4D8y1BANibUDe1cxHhiD2FbUaZjgbItWRCJB9 tvKdpe2E0ibyV/8+9dzwS9PxKI3C0EqK/BGsZB97WE86c+UATRF7GNhq/hti06/B uuFoKS4RN9QZlwvGvlBz/bsdzTpFb4PVRdBYr8rT8DxloBc1pU/rv/K5S0/uzLep J249KehyliMvdB2+lR3km+ON585ShImYQgK9V2wLlk0UcPlZGnmQWafk4AlnBrph KK0P3BRD4oVYyCHtT+90 =zICu -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 29 21:25:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38BD1A1B55; Thu, 29 Jan 2015 21:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIqM19h-_xtc; Thu, 29 Jan 2015 21:25:04 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882FF1A00F1; Thu, 29 Jan 2015 21:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16900; q=dns/txt; s=iport; t=1422595504; x=1423805104; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=50Cv2Rr0bZqLZpkKieCidl8fBH3MR47saCkP3r9P+nM=; b=TwDda1gbsqeoXwB4cjif+HXbbTjOw8rGU05ooD4IYTZXeQsxED9arr69 Otwi6HAl/3ElD/86jfqcqG1jY4/0DEirUAdRv3b3f3WPGhABSPBTr71eu 3nlX/JJeJxvdLvAQQTIc2eXUuMilJyjKH+qQhTkXi7/HrPIS7TyUUKFzI o=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4BABHFctU/xbLJq1RAwaDWFmDAcFnhSdKAoFgAQEBAQF9hAwBAQEDASNWBQsLGAkhAgIPAkYGAQwBAwICAQGIIAgNwCSWEgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKDoUPCgEBCgJDBwmCX4FBBZBPgSlPhVeBFzaCS4IgIYU/gnyDPSKCAhyBUT0ELQGBAwcXBoEaAQEB X-IronPort-AV: E=Sophos;i="5.09,490,1418083200"; d="asc'?scan'208";a="327720086" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Jan 2015 05:25:00 +0000 Received: from [10.61.163.62] ([10.61.163.62]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0U5P02B013561; Fri, 30 Jan 2015 05:25:00 GMT Message-ID: <54CB15AB.40400@cisco.com> Date: Fri, 30 Jan 2015 06:24:59 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Daniel Migault , saag@ietf.org, ietf-privacy@ietf.org References: <874mr9aucv.fsf@alice.fifthhorseman.net> In-Reply-To: <874mr9aucv.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tedwcJbXj0VSKr8Q9cGWlQilhXIOUrICK" Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 05:25:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tedwcJbXj0VSKr8Q9cGWlQilhXIOUrICK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Daniel for your prompt review. The working group and draft editor shall address your comments prior to advancing this document.=20 N.B., some discussion has already occurred in this area, even though it is not covered in the draft. Eliot On 1/30/15 3:13 AM, Daniel Kahn Gillmor wrote: > Hi Daniel and Elliot-- > > On Wed 2015-01-28 14:24:28 -0500, Daniel Migault wrote: >> Our document describing Time Zone Data Distribution Service >> [1] is close= to >> be finalized and we would like to proceed to cross area review. >> >> We would greatly appreciate to get review by February 11. > [...] >> [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05 > Thanks for your work on this. This is the first time i've seen this > draft; apologies for not looking at it earlier. > > I'm only subscribed to saag@ietf.org (and ietf-privacy, which is idle > lately, but i've included here because some of my review touches on > privacy), so this post might not make it through to tzdist@ietf.org -- > feel free to forward it as needed. > > I did a quick skim here with my security and privacy hats on, and have = a > few comments: > > (privacy) Privacy Considerations section is missing > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > There is *no* "Privacy Considerations" section in the draft at all. > Please read RFC 6973 for guidance in conducting a privacy review of the= > protocol. The act of querying these servers leaks something about the > location of the person doing the query, at least, and may leak > information about other locations that they're interested in. It's als= o > possible that regular attempts to query this information will provide a= > linkable trail of the user, which could then be (mis)used without their= > knowledge or permission. > > Here's an attempt at a quick analysis, though i haven't thought through= > the protocol in detail. I hope you'll do your own analysis, and you're= > welcome to take any of mine: > > Implausibly: if the average user is interested in 5 timezones, and ther= e > are 774 known zones ("find /usr/share/zoneinfo -type f | wc"), and thos= e > interests were evenly distributed across the zones for every users, the= n > the set of requests to update an individual's preferred timezones yield= s > nearly 50 bits of entropy, far more than enough to distinguish every > individual human from each other. > > More plausibly: timezone interest is probably less than 5 for most > people, and it isn't evenly distributed: the people who are interested > in Americas/New_York are more likely to be interested in > Americas/Los_Angeles than in Arctic/Longyearbyen. But anyone with an > unusual set of TZs can probably be identified (perhaps uniquely) by any= > provider they talk to just by what TZs they ask for. > > Since =C2=A74.1.4 says "Clients SHOULD poll for changes, using an appro= priate > conditional request, at least once a day", a malicious provider intent > on surveilling its users and with a mechanism to do so would have a > daily checkin. I imagine this as some kind of background system servic= e > looking for updates. the daily checkin could be used to track a user's= > movements around the network, if their device is not stationary. The > time of checkin could also be used as a linking mechanism, if the > machine polls with rigid regularity. > > Are there strategies that someone interested in preserving their > anonymity from a tzdata provider should take to remain anonymous? If > so, what are they? > > > (privacy) HTTP pipelining? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > Clients requesting multiple unusual TZs together are more easily > identifiable to servers, than clients who request only one. Should > clients request all their interested TZs at once, or spread out their > polling updates over time? HTTP pipelining is clearly more efficient; > but what are the privacy implications if you have a system service that= > does this? > > (privacy) HTTP Cookies? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The choice of HTTP transport also allows for servers to set cookies in > clients -- should clients accept and re-transmit cookies from the > server? What are the privacy implications? > > > (privacy) Tracking via ETag? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > Also, conditional requests seem to be encouraged via the use of an ETag= > header. It looks to me like a provider who wants to track its users > individually (even in the absence of cookies) could use a cache of > personalized ETags to do so. > > For example, the first time any client requests TZ X (with no > If-None-Match request header), the server mints a new ETag Y, generates= > a new client ID Z, and records: > > * Client ID Z > * the requested TZ X > * the new ETag Y > * the time of issuance > * the IP address > * any other interesting metadata > > When a request comes in for TZ X with an If-None-Match: Y header, the > server can link the two requests and record them both with client ID Z.= > > When the underlying data for the TZ actually changes, the server mints = a > new ETag (for the new version of TZ X), but associates it with the same= > client ID Z. > > > (privacy) Logging policy for distribution servers? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > There is also no mention of recommended logging policy for the servers,= > no attempt to address data minimization or the risks to trackable users= > based on normal server logs. > > (privacy) Authenticated clients are trackable > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > the Security Considerations section says: > > Servers MAY require some form of authentication or authorization of > clients (including secondary servers) to restrict which clients are > allowed to access their service, or provide better identification of= > errant clients. As such, servers MAY require HTTP- based > authentication as per [RFC7235]. > > Clients who make authenticated connections to servers are eminently > trackable by those servers. What are the privacy implications for thos= e > clients? > > > (privacy) network observers tracking clients > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Someone passively observing the network could also potentially track th= e > clients of a given server via traffic analysis, even if the server is > not cooperating. First, the attacker could get a stash of all the data= > that the server has, noting the size of each zone under each supported > format. > > When a new request is made for a zone, the attacker can observe the siz= e > of the query and the size of the response and guess with high > probability which zone was requested. > > If the clients poll once a day on a schedule (i.e. exactly every 86400 > seconds) then the network observer may be able to track updates and > determine when a client interested in a particular zone does an update.= > > What mechanisms could a client (and server?) use to frustrate such a > network-based attacker to keep a given client's identity anonymous? > > > (security/privacy) HTTP redirection > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What if the server sends an HTTP redirection (e.g. via HTTP response 30= 1 > or 302) -- should the client follow it? What if it is to a cleartext > HTTP resource? What are the security and privacy consequences of > following these redirections off-origin? > > > (security) Consequences of accepting bad TZ updates? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > I'm glad that the Security Considerations recognizes that reliable TZ > data is vital -- but no example is given of what a data compromise migh= t > look like. Is it worth providing a couple of examples of bad outcomes?= > are we talking about missed appointments? or crashing software? or > something else? > > (security) why not require TLS on both sides? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > you've got that the service MUST operate over https, but the clients > only SHOULD try https first. Why allow for cleartext access at all? > Why not say that both clients and servers MUST support HTTPS? > > I see https://tools.ietf.org/wg/tzdist/trac/ticket/7 suggests that ther= e > is consensus that you don't want "mandatory to use", but i don't know > where the discussion is, or why you don't want it. > > > (security) Provider-to-Provider TLS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Connections between "Secondary Providers" and "Root Providers" seem > different from the connections between Clients and Providers. If you > can't mandate HTTPS for all clients for some reason, what about at leas= t > mandating that the caching infrastructure requires TLS for all > provider-to-provider connections? The secondary provider will need a > TLS stack anyway (as a server), so it should be able to do TLS on the > upstream side. > > > (security) DNS compromise leaves only cleartext > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > If a network-based attacker can filter network traffic, they can simply= > drop all outbound _timezones._tcp.example.com DNS queries, and then whe= n > the client gives up, they can allow through (or provide their own, if > DNSSEC isn't involved) responses to _timezone._tcp.example.com. > > This immediately puts the network attacker in the position of being abl= e > to dictate timezone information to a client willing to fall back to > cleartext. > > > > (security) no-DNSSEC fallback checks are ambiguous > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > The Security Considerations currently say: > > In the absence of a secure DNS option, clients SHOULD check that the= > target FQDN returned in the SRV record matches the original service > domain that was queried. If the target FQDN is not in the queried > domain, clients SHOULD verify with the user that the SRV target FQDN= > is suitable for use before executing any connections to the host. > > What does "matches" mean here? the second sentence suggests that it > means "shares some sort of a suffix with" -- but which part? If i quer= y > for an SRV of _timezones._tcp.tz.example.com, and it replies with an > FQDN of bar.example.com, is that OK? what about x.y.z.bar.example.com?= > If DNSSEC isn't available, the attacker can still point this response t= o > any IP address of their choice, right? > > What does "verify with the user" mean if this is a TZdata service, whic= h > is presumably running automatically on the computer to keep this > information up-to-date? most such services have no user interaction at= > all. > > If there is a UI, what options would the user be given in such a case? > Is this a popup dialog box that says "you asked for timezone data > updates from tz.example.com -- is it ok to get it from whatever.example= > instead?" What users can make sense of this dialog? What information > would a fully-technically-cognizant user (a deep wizard) use to answer > it sensibly? What would a normal user use? > > If DNSSEC *is* available, is it OK if the record points outside the > zone? what if it points to a non-signed zone? > > > (security) Conflicts between Providers? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The draft implies that a client might fetch data from multiple > providers. What should the client do if two providers provide > conflicting information about the same TZ? > > (security) use examples of certificate validation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > The combination of SRV records and X.509 certificate validation and > (maybe) DNSSEC is a tricky subject. you've referenced RFC 6125, but i > don't think that's enough. > > Do you mean to suggest that the certificate should use a SRVName > subjectAltName (RFC4985)? or should it use a DNSName subjectAltName > with the name sent in the SRV query? or a DNSName subjectAltName > with the FQDN returned in the SRV response? > > Providing an example would make it clearer what you mean. For example:= > =20 > If a client looks up SRV for _timezones._tcp.example.com, and gets a= > response of tz.example.net, then the certificate should (a) be valid= , > and (b) have either a subjectAltName DNSName of tz.example.net or a > subjectAltName SRVName of _timezones._tcp.example.com (or both). > > (please adjust to taste, i don't mean to tell you what the right choice= > is here, it's an ugly problem) > > (security) Statically-signed data vs. transport security > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The security of the transmission process seems to rely entirely on > transport security. > > If there is a compromise in transmission between the Root provider and > the secondary provider, or a compromise of any provider, the client has= > no way of knowing that they're getting bad data. > > tzdata changes infrequently enough that it seems like it could be signe= d > with an offline key, making compromise of running systems much less > fruitful. But this only works if the client can verify the offline > signature. > > Have you considered any mechanism that the client could use to verify > the tz update based on data itself, without depending solely on > transport security? > > I see this question tangentially raise here: > > https://www.ietf.org/mail-archive/web/tzdist/current/msg00102.html > > but it's answered only in the "we still need TLS" way (which i agree > with). Is any work done (or planned) on providing signed/verifiable > data? > > > (security) TLS best-practices? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > I'm glad that you've got TLS as a MUST for servers. Is it worth making= > a normative reference to the UTA's TLS best-practices document? > > https://tools.ietf.org/html/draft-ietf-uta-tls-bcp > > > > > Sorry this got long, and that this is more in the form of questions tha= n > patches. I hope i haven't repeated too much of what the tzdist WG has > already discussed -- please feel free to point me to relevant > discussions that i may have missed. > > --dkg --tedwcJbXj0VSKr8Q9cGWlQilhXIOUrICK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUyxWrAAoJEIe2a0bZ0noz4V8IAIw7bVpzCi8snT0repFWqt4b ZZSCJ1tME1nwxwjpksu+9YITFpuCMlRxsk8Yu80prskgDpcr7orWrJ93mkp1UD9g EaMBgpN1siVvcPtfF03LNvGpiYjqQzVXJ37L00koCOGsAMCcRr39kdOIvaTBkNS/ 37r0hlVGnZ0f0Cm7gI2LksF9PIoIdRytbe3i0a2o2aINtODFsZE496okAI4ock6Q 6WVsSC8vOdZydSRPkl2DUyvTNCdaqJiKDwCuh2iFcalpy8GW9DRCF32KkN0urQEq AxTxZt6Vk68euDJzJjsWWvCm7CqMM0qO/ifmvSORfeWmCtJTlTcrN4606SXy6XI= =86Y8 -----END PGP SIGNATURE----- --tedwcJbXj0VSKr8Q9cGWlQilhXIOUrICK-- From nobody Fri Jan 30 13:21:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1431A9132; Fri, 30 Jan 2015 13:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA2x73-avNsm; Fri, 30 Jan 2015 13:20:53 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C89061A872D; Fri, 30 Jan 2015 13:20:52 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5C21FF984; Fri, 30 Jan 2015 16:20:49 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 473CF201D1; Fri, 30 Jan 2015 16:20:48 -0500 (EST) From: Daniel Kahn Gillmor To: Lester Caine , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear In-Reply-To: <54CBC609.4010309@lsces.co.uk> References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Jan 2015 16:20:48 -0500 Message-ID: <87egqcq827.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 21:20:59 -0000 On Fri 2015-01-30 12:57:29 -0500, Lester Caine wrote: > On 30/01/15 02:13, Daniel Kahn Gillmor wrote: >> Clients requesting multiple unusual TZs together are more easily >> identifiable to servers, than clients who request only one. Should >> clients request all their interested TZs at once, or spread out their >> polling updates over time? HTTP pipelining is clearly more efficient; >> but what are the privacy implications if you have a system service that >> does this? > > I've cherry picked here since the one thing that seems to have been > missed is that the main target for tzdist is to provide a mirror of the > TZ data. This is a complete set of tz information, and if my own > distribution method is followed many of the 'security and tracking' > risks being listed can never arise? The specification i read seemed to encourage clients to pick up specific zones of interest, not the full set of data. And the draft certainly makes allowances for fetching specific sections (by time, by space) of the TZ info. So i'm not sure if what you call "my own distribution method" is intended to be the normal use case. If it is, maybe that needs to be highlighted specifically in the draft? Is there some set of client profiles (or use cases, if you prefer) that are clearly distinct, with different implications? Can we identify them? > The clients computer has a local copy of TZ, and any local processing is > done against that copy. On a regular basis they ask tzdist if there has > been an update to the version of TZ they are using. If yes then all of > the are pulled down. A monitoring tap has no idea where the client is? > The only know that someone has updated from v to v+1 of the TZ data? Yep, this is a useful approach for keeping inside a broader anonymity set (but hm, timing issues might still be a concern). However, systems using this approach are really solving the general problem of "how to i get the latest version/updates of $X" where $X is anything digital: software updates already fulfil this role on modern operating systems. A deployed system on the Internet today that doesn't have a software update mechanism is probably bound for trouble -- if it *does* have a software update mechanism, why not suggest using that for the TZ info? Debian systems just pull in a new version of the tzdata package during system updates, for example. I haven't checked, but i would assume that Microsoft Update and Apple's Software Update would treat TZ data the same way that they treat other system updates. Is that not the case? Given that the all-tzdata-as-a-software-update mechanism is already available, I sort of assumed that this draft was intended for systems that don't already have such a mechanism. > Client using subsets of the data such as embedded devices will be asking > for a specific timezone, but that traffic will be within a local > network. We know already where they are so we don't need any cleaver > processing to hide the fact that we are in that physical location? I've > just posted about local servers providing a specific subset of data - > within the building it's serving - o you already have an even better > idea of location than timezone :) Are embedded devices guaranteed to be as stationary as you're making them out to be? Some embedded devices are embedded in cars or mobile telephones. Their motion within and between timezones seems like something that would have serious privacy implications, if their queries are linkable over time. > As with just about any system, accessing the data can be abused exposing > other information. We do need to identify what are 'secure' ways of > accessing the data and what ars insecure, but not exposing anything that > could not be deduced by other means anyway. To kickstart a privacy considerations section, it might help to work from a concrete example (though clearly that won't be an exhaustive review). How about: Consider an internet-connected bedside alarm clock (i think this counts an embedded device) that i take with me when i travel. It updates itself (using NTP?) to keep it on-time, and it uses this proposed mechanism to make sure it's got the TZ up-to-date. What should this device do as a client of this service? What are the privacy implications of these choices? How do the privacy considerations change for the client with respect to a passive or active network observer, as compared to the Provider itself? --dkg From nobody Sat Jan 31 04:08:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7091A8981; Sat, 31 Jan 2015 04:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXan1nkyvecX; Sat, 31 Jan 2015 04:08:31 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7E61A897F; Sat, 31 Jan 2015 04:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17881; q=dns/txt; s=iport; t=1422706110; x=1423915710; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1KVFOt8ajqKjhyAsZJKm0HnSmC+r3GjYbKMePB9BGLM=; b=BQMhpb8m/AafxAwhPYgYVtUV/R4vIR3znAfj1bfikLn9oZhdyFCKogq5 wRV1rMEYE4zaG6I2XFfo7xP61U25xDOSNyzXO20+Tyu5yTGa9nK9ug7Hr 6Q1zWh3Jtr8slCJUd+KOZBraCNfCOieSssjCUbKLrfHTp/U5Fb0vmAFKr 4=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxBAAExcxU/xbLJq1SAwaDWFmDAcFuhSdKAoFUAQEBAQF9hAwBAQEDASNVAQULCxgJFgsCAgkDAgECAUUGAQwBAwICAQGIIAgNvTGVUQEBAQEBAQEBAQEBAQEBAQEBAQEBAReKDoUPCgEBCgJDBwmCX4FBBY0egzeBK0+FV4EXNoJNgiMhhUSCfIM9IoICHIFRPQQtAYEDBxcGgRoBAQE X-IronPort-AV: E=Sophos;i="5.09,496,1418083200"; d="asc'?scan'208";a="329268116" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 31 Jan 2015 12:08:27 +0000 Received: from [10.61.210.210] ([10.61.210.210]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0VC8QId001257; Sat, 31 Jan 2015 12:08:26 GMT Message-ID: <54CCC5BA.9090101@cisco.com> Date: Sat, 31 Jan 2015 13:08:26 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Daniel Migault , saag@ietf.org, ietf-privacy@ietf.org References: <874mr9aucv.fsf@alice.fifthhorseman.net> In-Reply-To: <874mr9aucv.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GwCnLvMHQCjb2P3hDUk4T0w9PrJ0F2S0d" Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 12:08:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GwCnLvMHQCjb2P3hDUk4T0w9PrJ0F2S0d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, Thanks again for this review. I think there are several categories of issues that you've raised, and I'd like to break them out. The first is the easy category: that which has been raised before and considered. There is only one issue in that category as to whether or not everything should run atop TLS. That issue need not be reconsidered, EXCEPT in as much as you have clarified the context (c2s versus s2s). There is another category of that which really must change. Most (if not all) of what you mark as security is in this category. The downgrade attack that is possible in the current text also does not match my understanding of the consensus of the working group. That is- either a client uses HTTP or it uses HTTPS, but it may not "try" HTTPS first, and then back off to HTTP. "Do. Do not. There is no try." The other issues break down into two groups, I think. Authenticated sessions versus unauthenticated sessions. Because authentication is allowed, and because we do not specify a provisioning mechanism, likely there will be linkage between services. But we should also be mindful of what mitigations are truly available to us with regard to the other functions. Eliot On 1/30/15 3:13 AM, Daniel Kahn Gillmor wrote: > Hi Daniel and Elliot-- > > On Wed 2015-01-28 14:24:28 -0500, Daniel Migault wrote: >> Our document describing Time Zone Data Distribution Service >> [1] is close= to >> be finalized and we would like to proceed to cross area review. >> >> We would greatly appreciate to get review by February 11. > [...] >> [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05 > Thanks for your work on this. This is the first time i've seen this > draft; apologies for not looking at it earlier. > > I'm only subscribed to saag@ietf.org (and ietf-privacy, which is idle > lately, but i've included here because some of my review touches on > privacy), so this post might not make it through to tzdist@ietf.org -- > feel free to forward it as needed. > > I did a quick skim here with my security and privacy hats on, and have = a > few comments: > > (privacy) Privacy Considerations section is missing > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > There is *no* "Privacy Considerations" section in the draft at all. > Please read RFC 6973 for guidance in conducting a privacy review of the= > protocol. The act of querying these servers leaks something about the > location of the person doing the query, at least, and may leak > information about other locations that they're interested in. It's als= o > possible that regular attempts to query this information will provide a= > linkable trail of the user, which could then be (mis)used without their= > knowledge or permission. > > Here's an attempt at a quick analysis, though i haven't thought through= > the protocol in detail. I hope you'll do your own analysis, and you're= > welcome to take any of mine: > > Implausibly: if the average user is interested in 5 timezones, and ther= e > are 774 known zones ("find /usr/share/zoneinfo -type f | wc"), and thos= e > interests were evenly distributed across the zones for every users, the= n > the set of requests to update an individual's preferred timezones yield= s > nearly 50 bits of entropy, far more than enough to distinguish every > individual human from each other. > > More plausibly: timezone interest is probably less than 5 for most > people, and it isn't evenly distributed: the people who are interested > in Americas/New_York are more likely to be interested in > Americas/Los_Angeles than in Arctic/Longyearbyen. But anyone with an > unusual set of TZs can probably be identified (perhaps uniquely) by any= > provider they talk to just by what TZs they ask for. > > Since =C2=A74.1.4 says "Clients SHOULD poll for changes, using an appro= priate > conditional request, at least once a day", a malicious provider intent > on surveilling its users and with a mechanism to do so would have a > daily checkin. I imagine this as some kind of background system servic= e > looking for updates. the daily checkin could be used to track a user's= > movements around the network, if their device is not stationary. The > time of checkin could also be used as a linking mechanism, if the > machine polls with rigid regularity. > > Are there strategies that someone interested in preserving their > anonymity from a tzdata provider should take to remain anonymous? If > so, what are they? > > > (privacy) HTTP pipelining? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > Clients requesting multiple unusual TZs together are more easily > identifiable to servers, than clients who request only one. Should > clients request all their interested TZs at once, or spread out their > polling updates over time? HTTP pipelining is clearly more efficient; > but what are the privacy implications if you have a system service that= > does this? > > (privacy) HTTP Cookies? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The choice of HTTP transport also allows for servers to set cookies in > clients -- should clients accept and re-transmit cookies from the > server? What are the privacy implications? > > > (privacy) Tracking via ETag? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > Also, conditional requests seem to be encouraged via the use of an ETag= > header. It looks to me like a provider who wants to track its users > individually (even in the absence of cookies) could use a cache of > personalized ETags to do so. > > For example, the first time any client requests TZ X (with no > If-None-Match request header), the server mints a new ETag Y, generates= > a new client ID Z, and records: > > * Client ID Z > * the requested TZ X > * the new ETag Y > * the time of issuance > * the IP address > * any other interesting metadata > > When a request comes in for TZ X with an If-None-Match: Y header, the > server can link the two requests and record them both with client ID Z.= > > When the underlying data for the TZ actually changes, the server mints = a > new ETag (for the new version of TZ X), but associates it with the same= > client ID Z. > > > (privacy) Logging policy for distribution servers? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > There is also no mention of recommended logging policy for the servers,= > no attempt to address data minimization or the risks to trackable users= > based on normal server logs. > > (privacy) Authenticated clients are trackable > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > the Security Considerations section says: > > Servers MAY require some form of authentication or authorization of > clients (including secondary servers) to restrict which clients are > allowed to access their service, or provide better identification of= > errant clients. As such, servers MAY require HTTP- based > authentication as per [RFC7235]. > > Clients who make authenticated connections to servers are eminently > trackable by those servers. What are the privacy implications for thos= e > clients? > > > (privacy) network observers tracking clients > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Someone passively observing the network could also potentially track th= e > clients of a given server via traffic analysis, even if the server is > not cooperating. First, the attacker could get a stash of all the data= > that the server has, noting the size of each zone under each supported > format. > > When a new request is made for a zone, the attacker can observe the siz= e > of the query and the size of the response and guess with high > probability which zone was requested. > > If the clients poll once a day on a schedule (i.e. exactly every 86400 > seconds) then the network observer may be able to track updates and > determine when a client interested in a particular zone does an update.= > > What mechanisms could a client (and server?) use to frustrate such a > network-based attacker to keep a given client's identity anonymous? > > > (security/privacy) HTTP redirection > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What if the server sends an HTTP redirection (e.g. via HTTP response 30= 1 > or 302) -- should the client follow it? What if it is to a cleartext > HTTP resource? What are the security and privacy consequences of > following these redirections off-origin? > > > (security) Consequences of accepting bad TZ updates? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > I'm glad that the Security Considerations recognizes that reliable TZ > data is vital -- but no example is given of what a data compromise migh= t > look like. Is it worth providing a couple of examples of bad outcomes?= > are we talking about missed appointments? or crashing software? or > something else? > > (security) why not require TLS on both sides? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > you've got that the service MUST operate over https, but the clients > only SHOULD try https first. Why allow for cleartext access at all? > Why not say that both clients and servers MUST support HTTPS? > > I see https://tools.ietf.org/wg/tzdist/trac/ticket/7 suggests that ther= e > is consensus that you don't want "mandatory to use", but i don't know > where the discussion is, or why you don't want it. > > > (security) Provider-to-Provider TLS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Connections between "Secondary Providers" and "Root Providers" seem > different from the connections between Clients and Providers. If you > can't mandate HTTPS for all clients for some reason, what about at leas= t > mandating that the caching infrastructure requires TLS for all > provider-to-provider connections? The secondary provider will need a > TLS stack anyway (as a server), so it should be able to do TLS on the > upstream side. > > > (security) DNS compromise leaves only cleartext > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > If a network-based attacker can filter network traffic, they can simply= > drop all outbound _timezones._tcp.example.com DNS queries, and then whe= n > the client gives up, they can allow through (or provide their own, if > DNSSEC isn't involved) responses to _timezone._tcp.example.com. > > This immediately puts the network attacker in the position of being abl= e > to dictate timezone information to a client willing to fall back to > cleartext. > > > > (security) no-DNSSEC fallback checks are ambiguous > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > The Security Considerations currently say: > > In the absence of a secure DNS option, clients SHOULD check that the= > target FQDN returned in the SRV record matches the original service > domain that was queried. If the target FQDN is not in the queried > domain, clients SHOULD verify with the user that the SRV target FQDN= > is suitable for use before executing any connections to the host. > > What does "matches" mean here? the second sentence suggests that it > means "shares some sort of a suffix with" -- but which part? If i quer= y > for an SRV of _timezones._tcp.tz.example.com, and it replies with an > FQDN of bar.example.com, is that OK? what about x.y.z.bar.example.com?= > If DNSSEC isn't available, the attacker can still point this response t= o > any IP address of their choice, right? > > What does "verify with the user" mean if this is a TZdata service, whic= h > is presumably running automatically on the computer to keep this > information up-to-date? most such services have no user interaction at= > all. > > If there is a UI, what options would the user be given in such a case? > Is this a popup dialog box that says "you asked for timezone data > updates from tz.example.com -- is it ok to get it from whatever.example= > instead?" What users can make sense of this dialog? What information > would a fully-technically-cognizant user (a deep wizard) use to answer > it sensibly? What would a normal user use? > > If DNSSEC *is* available, is it OK if the record points outside the > zone? what if it points to a non-signed zone? > > > (security) Conflicts between Providers? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The draft implies that a client might fetch data from multiple > providers. What should the client do if two providers provide > conflicting information about the same TZ? > > (security) use examples of certificate validation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > The combination of SRV records and X.509 certificate validation and > (maybe) DNSSEC is a tricky subject. you've referenced RFC 6125, but i > don't think that's enough. > > Do you mean to suggest that the certificate should use a SRVName > subjectAltName (RFC4985)? or should it use a DNSName subjectAltName > with the name sent in the SRV query? or a DNSName subjectAltName > with the FQDN returned in the SRV response? > > Providing an example would make it clearer what you mean. For example:= > =20 > If a client looks up SRV for _timezones._tcp.example.com, and gets a= > response of tz.example.net, then the certificate should (a) be valid= , > and (b) have either a subjectAltName DNSName of tz.example.net or a > subjectAltName SRVName of _timezones._tcp.example.com (or both). > > (please adjust to taste, i don't mean to tell you what the right choice= > is here, it's an ugly problem) > > (security) Statically-signed data vs. transport security > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > The security of the transmission process seems to rely entirely on > transport security. > > If there is a compromise in transmission between the Root provider and > the secondary provider, or a compromise of any provider, the client has= > no way of knowing that they're getting bad data. > > tzdata changes infrequently enough that it seems like it could be signe= d > with an offline key, making compromise of running systems much less > fruitful. But this only works if the client can verify the offline > signature. > > Have you considered any mechanism that the client could use to verify > the tz update based on data itself, without depending solely on > transport security? > > I see this question tangentially raise here: > > https://www.ietf.org/mail-archive/web/tzdist/current/msg00102.html > > but it's answered only in the "we still need TLS" way (which i agree > with). Is any work done (or planned) on providing signed/verifiable > data? > > > (security) TLS best-practices? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > I'm glad that you've got TLS as a MUST for servers. Is it worth making= > a normative reference to the UTA's TLS best-practices document? > > https://tools.ietf.org/html/draft-ietf-uta-tls-bcp > > > > > Sorry this got long, and that this is more in the form of questions tha= n > patches. I hope i haven't repeated too much of what the tzdist WG has > already discussed -- please feel free to point me to relevant > discussions that i may have missed. > > --dkg --GwCnLvMHQCjb2P3hDUk4T0w9PrJ0F2S0d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUzMW6AAoJEIe2a0bZ0nozK5wIAKs/Ho6g3bgw4VBSeXNQXLYT vqgg7WM8XGS8jRKW0liP8b0WxlMG/9oZ/tfL049Q6ikdJKr7j9dO8bHD1Z4BaMrV P/xpe7hjaErCtV7/oZDG377/BNap0tVg39/Fy2fPJaWCoAgXodGjnfpCa4aaqzpf lqZNPVlDdgWkxbIcTVcmqy+ZSRKBojasWj64okXrloQ1KJ78hAaSKCMY7f++jxLt E2U9z1Qvt5XAQV3KwAWvGBUGBREJlR6V4aISbvQg7Gcy6o+8lCZwJ5alUp7sb4EQ 0IWX65zYSbkUAJcrJYaDgscvdJdNI3GmP3YOcIRq24DoOLxqwCz2YrW7Q3ldm/M= =ACsC -----END PGP SIGNATURE----- --GwCnLvMHQCjb2P3hDUk4T0w9PrJ0F2S0d-- From nobody Sat Jan 31 08:05:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5B1A1B28; Sat, 31 Jan 2015 00:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w0hcZ9I2iaP; Sat, 31 Jan 2015 00:15:20 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 74BFA1A882D; Sat, 31 Jan 2015 00:15:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9C3BEA60089; Sat, 31 Jan 2015 00:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bjp3yOkSmGR; Sat, 31 Jan 2015 00:15:19 -0800 (PST) Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3B2E5A60085; Sat, 31 Jan 2015 00:15:19 -0800 (PST) Message-ID: <54CC8F13.6060808@cs.ucla.edu> Date: Sat, 31 Jan 2015 00:15:15 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Lester Caine , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> In-Reply-To: <87egqcq827.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 31 Jan 2015 08:05:04 -0800 Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 08:15:21 -0000 Daniel Kahn Gillmor wrote: > Given that the all-tzdata-as-a-software-update mechanism is already > available, I sort of assumed that this draft was intended for systems > that don't already have such a mechanism. My impression is that the tzdist protocol is also intended to supplement those operating system updates, or in the long run to replace them. In practice these OS updates are sometimes delayed or deferred, and I think the hope is partly that such problems would occur less often with tzdist. Privacy ought to easier for this usage of tzdist, as network observers shouldn't be able to learn more about full tzdata updates than they can for any other OS update. > Consider an internet-connected bedside alarm clock Given your comments, I'd think that any such alarm clock should get the entire tz database, just as an OS update would. This would preserve privacy better than having the alarm clock query only about updates to America/Los_Angeles and Europe/Paris. From nobody Sat Jan 31 08:05:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D281A9123 for ; Fri, 30 Jan 2015 09:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9_j5p6qhi8m for ; Fri, 30 Jan 2015 09:57:34 -0800 (PST) Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803861A911A for ; Fri, 30 Jan 2015 09:57:32 -0800 (PST) Received: (qmail 14736 invoked by uid 89); 30 Jan 2015 17:57:30 -0000 Received: by simscan 1.3.1 ppid: 14729, pid: 14732, t: 0.0812s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 30 Jan 2015 17:57:30 -0000 Message-ID: <54CBC609.4010309@lsces.co.uk> Date: Fri, 30 Jan 2015 17:57:29 +0000 From: Lester Caine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> In-Reply-To: <874mr9aucv.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 31 Jan 2015 08:05:04 -0800 Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 17:57:36 -0000 On 30/01/15 02:13, Daniel Kahn Gillmor wrote: > Clients requesting multiple unusual TZs together are more easily > identifiable to servers, than clients who request only one. Should > clients request all their interested TZs at once, or spread out their > polling updates over time? HTTP pipelining is clearly more efficient; > but what are the privacy implications if you have a system service that > does this? I've cherry picked here since the one thing that seems to have been missed is that the main target for tzdist is to provide a mirror of the TZ data. This is a complete set of tz information, and if my own distribution method is followed many of the 'security and tracking' risks being listed can never arise? The clients computer has a local copy of TZ, and any local processing is done against that copy. On a regular basis they ask tzdist if there has been an update to the version of TZ they are using. If yes then all of the are pulled down. A monitoring tap has no idea where the client is? The only know that someone has updated from v to v+1 of the TZ data? Client using subsets of the data such as embedded devices will be asking for a specific timezone, but that traffic will be within a local network. We know already where they are so we don't need any cleaver processing to hide the fact that we are in that physical location? I've just posted about local servers providing a specific subset of data - within the building it's serving - o you already have an even better idea of location than timezone :) As with just about any system, accessing the data can be abused exposing other information. We do need to identify what are 'secure' ways of accessing the data and what ars insecure, but not exposing anything that could not be deduced by other means anyway. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk From nobody Sat Jan 31 08:05:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3861A8771 for ; Fri, 30 Jan 2015 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eizkSFfsVB-P for ; Fri, 30 Jan 2015 15:02:01 -0800 (PST) Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01961A8761 for ; Fri, 30 Jan 2015 15:02:00 -0800 (PST) Received: (qmail 10125 invoked by uid 89); 30 Jan 2015 23:01:46 -0000 Received: by simscan 1.3.1 ppid: 10094, pid: 10118, t: 1.4656s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 30 Jan 2015 23:01:45 -0000 Message-ID: <54CC0D4D.7000406@lsces.co.uk> Date: Fri, 30 Jan 2015 23:01:33 +0000 From: Lester Caine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> In-Reply-To: <87egqcq827.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 31 Jan 2015 08:05:06 -0800 Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 23:02:09 -0000 On 30/01/15 21:20, Daniel Kahn Gillmor wrote: > On Fri 2015-01-30 12:57:29 -0500, Lester Caine wrote: >> On 30/01/15 02:13, Daniel Kahn Gillmor wrote: >>> Clients requesting multiple unusual TZs together are more easily >>> identifiable to servers, than clients who request only one. Should >>> clients request all their interested TZs at once, or spread out their >>> polling updates over time? HTTP pipelining is clearly more efficient; >>> but what are the privacy implications if you have a system service that >>> does this? >> >> I've cherry picked here since the one thing that seems to have been >> missed is that the main target for tzdist is to provide a mirror of the >> TZ data. This is a complete set of tz information, and if my own >> distribution method is followed many of the 'security and tracking' >> risks being listed can never arise? > > The specification i read seemed to encourage clients to pick up specific > zones of interest, not the full set of data. And the draft certainly > makes allowances for fetching specific sections (by time, by space) of > the TZ info. So i'm not sure if what you call "my own distribution > method" is intended to be the normal use case. If it is, maybe that > needs to be highlighted specifically in the draft? > > Is there some set of client profiles (or use cases, if you prefer) that > are clearly distinct, with different implications? Can we identify > them? If you have not been following the development of tzdist then you will have missed some of the debate on just how limited the charter of the workgroup is. ;) The basic premiss should be to get updates to TZ data out in a timely manor. Some of the other applications are then built on that. Servicing devices that are not powerful enough to handle a suitable security software should not be blocked simply because it may be a security risk. But it should be used within a suitable environment? >> The clients computer has a local copy of TZ, and any local processing is >> done against that copy. On a regular basis they ask tzdist if there has >> been an update to the version of TZ they are using. If yes then all of >> the are pulled down. A monitoring tap has no idea where the client is? >> The only know that someone has updated from v to v+1 of the TZ data? > > Yep, this is a useful approach for keeping inside a broader anonymity > set (but hm, timing issues might still be a concern). > > However, systems using this approach are really solving the general > problem of "how to i get the latest version/updates of $X" where $X is > anything digital: software updates already fulfil this role on modern > operating systems. A deployed system on the Internet today that doesn't > have a software update mechanism is probably bound for trouble -- if it > *does* have a software update mechanism, why not suggest using that for > the TZ info? Debian systems just pull in a new version of the tzdata > package during system updates, for example. I haven't checked, but i > would assume that Microsoft Update and Apple's Software Update would > treat TZ data the same way that they treat other system updates. Is > that not the case? This is EXACTLY the problem that tzdist is chartered to solve, and the current draft does at least provide a basis to achieve that. Again since you have not been following you will have missed a lot of detail on just why the current methods result in missed meetings and other conflicts. The starting point which HAS now been developed in the current draft is to provide a versioning system where by historic material can be published against a publisher/version and later users can download the matching data set and ask for a current change set from that data. > Given that the all-tzdata-as-a-software-update mechanism is already > available, I sort of assumed that this draft was intended for systems > that don't already have such a mechanism. The current system is unusable so tzdist provides a means of providing a mechanism that works. Material being published currently becomes unusable when the TZ data set used to create it is simply scrapped for a new one. >> Client using subsets of the data such as embedded devices will be asking >> for a specific timezone, but that traffic will be within a local >> network. We know already where they are so we don't need any cleaver >> processing to hide the fact that we are in that physical location? I've >> just posted about local servers providing a specific subset of data - >> within the building it's serving - o you already have an even better >> idea of location than timezone :) > > Are embedded devices guaranteed to be as stationary as you're making > them out to be? Some embedded devices are embedded in cars or mobile > telephones. Their motion within and between timezones seems like > something that would have serious privacy implications, if their queries > are linkable over time. There are numerous problems with mobile devices not the least working out just what time one should be using, but once your calendering system starts moving through several timezones, it make sense to move from a single zone system to one using a full dataset? You don't know where you will be next week. Original draft of tzdist required a complete resync every time you changed server after a change of location ... currently the only question when a mobile device regains an internet connection is 'has pub/ver been updated'. CURRENTLY mobile devices have an abysmal mess of versions of TZ data, which tzdist is the ideal solution to clear up! VTIMEZONE currently needs identifiable data simply because of the mess in distributed TZ, so fix one and the 'privacy risk' of the other is unnecessary :) >> As with just about any system, accessing the data can be abused exposing >> other information. We do need to identify what are 'secure' ways of >> accessing the data and what ars insecure, but not exposing anything that >> could not be deduced by other means anyway. > > To kickstart a privacy considerations section, it might help to work > from a concrete example (though clearly that won't be an exhaustive > review). How about: > > Consider an internet-connected bedside alarm clock (i think this counts > an embedded device) that i take with me when i travel. It updates > itself (using NTP?) to keep it on-time, and it uses this proposed > mechanism to make sure it's got the TZ up-to-date. I have 80 networked devices in the house here. I would expect to have a local tzdist service on the local network just as I have a local NTP service. If the job was being done properly then the timezone information would simply be part of time service, but that is a different debate. For now the clocks have to be told what timezone and where to find any DST information. If I move my clock to a new location it would be nice if the local time/tzdist service provided a 'local' time so the clock updates? We will then be on a local hotel or office network? So do we need to 'hide' the location? > What should this device do as a client of this service? What are the > privacy implications of these choices? How do the privacy > considerations change for the client with respect to a passive or active > network observer, as compared to the Provider itself? If I ask the client for his location via a GPS location in order to sort out his current timezone do I need to worry about 'privacy'? I currently have to do this simply because offset supplied via the browser is useless and if I can't get a timezone that way I have to ask the client to provide one! I have to keep their information private, but that is the general transmission security problem? Is asking for the TZ data for a location any different to asking for the opening times of activities at that location? But I view being able to ask for the TZ data matching an historic data set where the publisher of that data does not match my own cached TZ data as not a privacy risk. Anybody intercepting it has no idea why I'm asking for it. It WOULD be a lot less of a security risk if we simply has ONE publisher of TZ data which contained the full historic set of data, but that is outside the charter of the workgroup! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk From nobody Sat Jan 31 08:05:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236CB1A88F9 for ; Sat, 31 Jan 2015 01:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV3iYjxF5P6j for ; Sat, 31 Jan 2015 01:17:42 -0800 (PST) Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A41A8907 for ; Sat, 31 Jan 2015 01:17:42 -0800 (PST) Received: (qmail 5539 invoked by uid 89); 31 Jan 2015 09:17:39 -0000 Received: by simscan 1.3.1 ppid: 5531, pid: 5536, t: 0.0734s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 31 Jan 2015 09:17:39 -0000 Message-ID: <54CC9DB3.6040500@lsces.co.uk> Date: Sat, 31 Jan 2015 09:17:39 +0000 From: Lester Caine User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paul Eggert , Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> In-Reply-To: <54CC8F13.6060808@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 31 Jan 2015 08:05:06 -0800 Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 09:17:45 -0000 On 31/01/15 08:15, Paul Eggert wrote: >> Consider an internet-connected bedside alarm clock > > Given your comments, I'd think that any such alarm clock should get the > entire tz database, just as an OS update would. This would preserve > privacy better than having the alarm clock query only about updates to > America/Los_Angeles and Europe/Paris. As already stated, some devices such as central heating controllers would not need a processor capable of the sort of processing power needed to handle that, but would benefit immensely simply from switching DST setting at the right time. If that needs a 'son of tzdist' specification then OK but it's those sorts of devices that the 'NOT' requirements of the charter are directly addressing? Given that the sort of processing power available today is probably making that a thin argument, but a substantial number of 'internet ready' processors do not have a large spare storage capacity even given how small the TZ database can be compacted ( and don't have leap-second capable clocks ;) ) many of these are already active on the internet. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk From nobody Sat Jan 31 14:34:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BEE1A0381; Sat, 31 Jan 2015 14:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU-k96JVDzjt; Sat, 31 Jan 2015 14:34:48 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC581A01A9; Sat, 31 Jan 2015 14:34:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A186CA60050; Sat, 31 Jan 2015 14:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-LXI6sV68ic; Sat, 31 Jan 2015 14:34:47 -0800 (PST) Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 20482A6002A; Sat, 31 Jan 2015 14:34:47 -0800 (PST) Message-ID: <54CD5886.7020409@cs.ucla.edu> Date: Sat, 31 Jan 2015 14:34:46 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lester Caine , Daniel Kahn Gillmor , saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear References: <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> In-Reply-To: <54CC9DB3.6040500@lsces.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Time Zone Data Distribution Service Subject: Re: [saag] [Tzdist] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 22:34:49 -0000 Lester Caine wrote: > some devices such as central heating controllers > would not need a processor capable of the sort of processing power > needed to handle that Even the lowliest central heating controller can easily handle the entire tz database, if only to discard unneeded parts as they're received. We're talking kilobytes here, not gigabytes or even megabytes.